目前写 Prompt 时, 经常根据不同需求添加不同模块要点, 固定的一个模式写法, 在面对差异巨大的需求场景时, 经常会因缺失

目前写 Prompt 时, 经常根据不同需求添加不同模块要点, 固定的一个模式写法, 在面对差异巨大的需求场景时, 经常会因缺失某些描述而效果变差。 干脆下手整理一个从 A-Z ,共26 个角度的模块,使用时,可从其中挑选合适的模块组装。 - Attention: 需重点强调的要点 - Background: Prompt 的需求背景 - Constraints: 限制条件 - Definition: 名词定义 - Example: few-shots - Fail: 处理失败时对应的兜底逻辑 - Goal: Prompt 要实现的目标 - Hack: 防止 Hack 的防护词 - In-depth: 一步步思考, 持续深入 - Job: 需求任务描述 - Knowledge: 知识库文件 - Lawful: 合法合规,安全行驶 - Merge: 是否使用多角色, 最终合并投票输出结果 - Neglect: 明确忽略哪些内容 - Odd: 偶尔[俏皮, 愤怒, 严肃]一下 - Pardon: 当用户回复信息不详细时, 持续追问 - Quote: 引用知识库信息时, 给出原文引用链接 - RAG:外挂知识库 - Skills: 擅长的技能项 - Tone: 回复使用的语气风格 - Unsure: 引入评判者视角, 当判定低于阈值时, 回复安全词 - Vaule: Prompt 模仿人格的价值观 - Workflow: 工作流程 - X-factor: 用户使用本 Prompt 最为重要的那个内核要素 - Yeow: Yeow, bro! Prompt 开场白设计 - Zig: 无厘头式 Prompt, 如[答案之书]

相关推荐

封面图片

#ChatGPT Prompt

#ChatGPT Prompt 通过Prompt 让GPT 讲解清楚概念, 已经迭代了八个版本, 目前这个版本使用起来已经初步满足需求了. =============== # Role: 知识探索专家 ## Profile: - author: Arthur - version: 0.8 - language: 中文 - description: 我是一个专门用于提问并解答有关特定知识点的 AI 角色。 ## Goals: 提出并尝试解答有关用户指定知识点的三个关键问题:其来源、其本质、其发展。 ## Constrains: 1. 对于不在你知识库中的信息, 明确告知用户你不知道 2. 你不擅长客套, 不会进行没有意义的夸奖和客气对话 3. 解释完概念即结束对话, 不会询问是否有其它问题 ## Skills: 1. 具有强大的知识获取和整合能力 2. 拥有广泛的知识库, 掌握提问和回答的技巧 3. 拥有排版审美, 会利用序号, 缩进, 分隔线和换行符等等来美化信息排版 4. 擅长使用比喻的方式来让用户理解知识 5. 惜字如金, 不说废话 ## Workflows: 你会按下面的框架来扩展用户提供的概念, 并通过分隔符, 序号, 缩进, 换行符等进行排版美化 1.它从哪里来? ━━━━━━━━━━━━━━━━━━ - 讲解清楚该知识的起源, 它是为了解决什么问题而诞生。 - 然后对比解释一下: 它出现之前是什么状态, 它出现之后又是什么状态? 2.它是什么? ━━━━━━━━━━━━━━━━━━ - 讲解清楚该知识本身,它是如何解决相关问题的? - 再说明一下: 应用该知识时最重要的三条原则是什么? - 接下来举一个现实案例方便用户直观理解: - 案例背景情况(遇到的问题) - 使用该知识如何解决的问题 - optional: 真实代码片断样例 3.它到哪里去? ━━━━━━━━━━━━━━━━━━ - 它的局限性是什么? - 当前行业对它的优化方向是什么? - 未来可能的发展方向是什么? # Initialization: 作为知识探索专家,我拥有广泛的知识库和问题提问及回答的技巧,严格遵守尊重用户和提供准确信息的原则。我会使用默认的中文与您进行对话,首先我会友好地欢迎您,然后会向您介绍我自己以及我的工作流程。

封面图片

在使用 ChatGPT 或 Midjourney 时,经常要使用各种 Prompt(提示词)跟 AI 进行交互,于是有设计师做了

在使用 ChatGPT 或 Midjourney 时,经常要使用各种 Prompt(提示词)跟 AI 进行交互,于是有设计师做了一款Prompt编辑器。 该工具可以把 AIGC 提示词可视化,并提供在线编辑功能,主要包含以下特性: 显示英文提示词的中文翻译; 翻译输入的中文提示词到英文(因为 Midjourney 仅支持英文提示词); 为提示词进行分类(普通、样式、质量、命令); 轻松的排序、隐藏提示词; 把提示词可视化结果导出为图片; 常用提示词词典; 通过 Notion 管理提示词词典。 || #工具

封面图片

基于向量数据库与GPT3.5的通用本地知识库方案 | 整个流程非常简单,也没有复杂的地方,相信关注GPT领域的都会看到过如上的流

基于向量数据库与GPT3.5的通用本地知识库方案 | 整个流程非常简单,也没有复杂的地方,相信关注GPT领域的都会看到过如上的流程。 主要就以下几个点: 将本地答案数据集,转为向量存储到向量数据 当用户输入查询的问题时,把问题转为向量然后从向量数据库中查询相近的答案topK 这个时候其实就是我们最普遍的问答查询方案,在没有GPT的时候就直接返回相关的答案整个流程就结束了 现在有GPT了可以优化回答内容的整体结构,在单纯的搜索场景下其实这个优化没什么意义。但如果在客服等的聊天场景下,引用相关领域内容回复时,这样就会显得不那么的突兀。 作者打算以此做一个基于默沙东诊疗手册的问诊AI。​

封面图片

回顾我的 prompt 能力从小白到熟练的一些重要节点:

回顾我的 prompt 能力从小白到熟练的一些重要节点: 防杠叠甲: 1. 仅代表我自己的认知,没啥权威性。 2. 认为提示词那么简单至于搞那么复杂么的朋友,你对 3. 本文是语音转写的,比较随意。 第一步:大模型基本特性与生成原理 第一步还是要从大模型的基本特性了解开始 这部分可以叫做大模型祛魅或者是大模型的基础认知 这部分学习的重点应该是大模型的生成原理 避免在以后使用提示词的时候对大模型有一些不恰当的想象 导致一些很奇怪(不现实)的提示词的想法,比如一次生成上万字,准确生成312个字,自动生成爆款什么的。 第二步:自然语言对话体会与大模型交流 在心流状态下认真地审视自己内心想要解决的问题和诉求,尝试通过完全的聊天式的自然语言来和大模型进行几轮对话,以此来体会大模型的一些生成机制,然后感受一下其中不尽如人意的地方,反思自己的提问哪里有缺陷, 也思考一下大模型是不是有一些局限性。 第三步:引入结构化思维 在进行了第二步之后,会显著地感受到对自己的表述和对大模型的反应已经有了一个直观的认知,这个时候可以开始考虑如何采纳更加有效的表达结构来进行和大模型的对话,这时候才真正地引入所谓带有方法论的提示词写法,如模块化的提示词框架, 可以尝试去用几个比较简单的提示词,例如交代清楚任务的背景,给出生成内容的格式要求,描述具体的任务步骤等等。 第四步:深入理解“角色法” 在第四步要深入地理解角色法(让大模型扮演某角色)这种方法在提示词当中的非常有效的作用 在这个阶段可以充分地去体验一下不同角色的约束带来的大模型回复的变化 首先要自己认同角色法的意义和作用。 在角色法的基础上加上结构化表达,所谓结构化提示词事实上就是基于角色法的一种结构化表述方法。 同时,在结构化提示词的 workflow 部分融入了思维链的思路,将复杂的任务拆分成清晰的、环环相扣的、分步实施的清晰的任务指令。 结合了角色法、结构化表达和思维链提示的三种方法论与一体的结构化提示词,在一些复杂任务当中或在一些复杂的角色塑造当中起到了非常显著的作用,但这只是提示词创作的方法之一。 第五步:了解 markdown 语法和它的意义 在第四个步骤的基础上,可以为了让我们的结构化语法更加的清晰有效,在一些复杂的文本层级和结构之间带来更加清晰的显示方式, 我们可以引入 Markdown 语法,为我们先前的角色法和结构化表达带来更加清晰的语法结构,以便大模型能够更清楚地识别我们所提供的所有的指令。 提示词中使用 Markdown 语法的核心是符合 OpenAI 的官方六个最佳实践里面的使用清晰的表达结构和分隔符、符号等方式使得我们的大段文本的结构变得更加清晰。 这样做的目的只有一个:就是让大模型不至于混淆在我们复杂的文本指令过程中的一些层级问题,或者因为分隔不当而导致一些有不同含义的文本被混淆在一起导致大模型的误解。 在这一点上,很多同学有着诸多的困惑或误解,事实上,Markdown 语法并不局限于我们广为流传的结构化语法当中的那些固定格式和单词, 只要是基于清晰表述的框架层级下采用 Markdown 语法, 你完全可以自定义你的每一级的标题的内容和文本的内容, 以及灵活地使用 Markdown 当中的其他的一些写法, 例如有序列表,无序列表,缩近符,分隔符,在提示词当中嵌入一部分片段式的代码等等,都是可以的。 第六步:没想好叫什么名字,就再进一步学习吧 认真完成前面五步事实上并不需要太久的时间,如果已完成,恭喜你,你的提示词基础已经挺扎实了。 接下来是两个层面的进阶学习: 1. 实践 大量的实践, 对上述方法的大量实践,在极多的不同场景下的反复编写提示词,观察大模型的反馈结果,进行测试和迭代,然后去优化自己的表述结构, 以此更加深入地理解大模型的一些能力,一些局限,以及会更加深入地理解自己表达上面的一些技巧和方法。 2. 表达能力 向内审视自己的表述,这背后是我们的逻辑思维和表达能力,我们的词汇量,我们的语言组织,我们的语法习惯,都会影响我们在对大模型输出指令时的文本的质量。 在前一个步骤里采用的结构化提示词的好处在于,它已经规范了一套相当标准的表述结构,那么就可能会在一定程度上弥补个体在表达上缺乏逻辑性和条理性的这样局限和缺陷。 在我们运用结构化提示词非常熟练的场景下,我们需要进一步地去融合和提炼,学会在更加复杂的情况下使用复杂提示词,而在更加简单或连续追问的心流场景下,找到准确表述自己的意图的一种方法。 这是需要建立在大量的对话实践的基础上的,如果你在之前已经了解过大模型的特性,也采用结构化提示词,采用别人提供的框架和模板,进行过大量实践的情况下,你可以在极其精简的几个句子中就明确表述自己的意图,并且对大模型接下来的生成有一定的判断。 在大模型的生成不符合你预期的结果时,你也可能很快地找到如何调整自己表述的方式。这些是我称之为一种和大模型对话语感的能力,这种语感的背后有经验的累积,有对方法论的思考,更多时候也是形成一种潜意识的表达的一种条件反射的语言素养。 第七步:提示词封装与工作流 当我们对外掌握了足够的技巧和方法,对内也深刻思考了自己的深层逻辑思维与表达能力,我们该考虑如何把我们熟练运用的提示词作为工具分享给他人使用,或作为工具沉淀下来用于提升自己的生产力工具。 这时候我们必须要考虑到引入一个提示词封装的方法。 目前市面上比较主流的工具有 OpenAI 官方推出的 GPTS 或者叫 Gizmo, 当然也有我们国内国产大模型的很多智能体封装的工具, 例如智谱清言的智能体,百度文心一言的智能体,以及Kimi Plus版本最近推出的官方智能体(暂不支持用户自己上传), 这些都是很成熟的平台化的智能体封装方式。 对于提示词学习者来说,仅需要花较少的时间去了解平台的特性、智能体的设置规则, 以及一些最基础的简单的参数设置即可。 但当我们来到这一步时,我们必须面临的一个问题是, 在我们独自使用一个提示词的时候, 很可能这个提示词的某些约束语句仅出于我个人的语言习惯或我个人对提示词的使用场景, 所以在我们测试和迭代的时候不会发生太多的问题。 但当我们把一个提示词封装为一个智能体去发布或者是传递给更多其他人使用的时候, 由于使用场景的差异和思维方式的差异, 很可能我们的提示词会遇到很多用户层面的问题。 如果我们有机会和我们的用户交流的话, 可以极大的提升我们在提示词的编写迭代上的认知和见解。 这是非常宝贵的经验,值得大家在这个领域投入更多精力,建立和你提示词使用者的沟通机制是非常有帮助的。 同时我们在这个阶段也会面临另一个困境,就是单一的提示词很难解决较为复杂的任务或生成非常长篇的复杂文本。 这是大模型单词对话窗口的局限性和大模型的注意力机制所决定的。 当你的提示词足够复杂的时候,意味着大模型的注意力也被大量的稀释。 那么分散在一些特定的重要约束语句上的注意力可能就会不足以让大模型来理解并完成这一个指令和约束。 在这种情况下,单个提示词的能力会变得让我们感到非常无力,这种情况下,我们需要引入提示词链或工作流程,把多个提示词和大模型能力以及外部工具的能力链接起来,形成一个特定的工作流来解决我们对复杂任务的要求。 第八步:RAG技术 同时,为了解决大模型的世界知识不足或产生幻觉等等问题, 我们在这个时候需要适时地考虑引入基于 RAG 技术的自主上传的知识库文本或自己去创建清晰的数据集来作为引用文本, 方便大模型基于更加严谨的参考文本来解决我们特定的任务场景。 到这里,提示词应该可以想写什么写什么了,祝 AI 旅途愉快。

封面图片

关于ChatGPT 做 Search 会杀死大部分 Wrapper 型 AI 搜索引擎的讨论,我有一些不一样的看法

关于ChatGPT 做 Search 会杀死大部分 Wrapper 型 AI 搜索引擎的讨论,我有一些不一样的看法 1. AI 搜索引擎的第一要义是准确度。 准确度的决定性因素主要是两个:问答底座模型的智能程度 + 挂载上下文的信息密度。 做好 AI 搜索引擎的关键,选用最智能的问答底座模型,再对 RAG 的检索结果进行排序去重,保证信息密度。 第一个步骤容易,第二个步骤很难。所以现在市面上大部分的 AI 搜索引擎,包括 Perplexity,准确度也就 60% 左右。 2. ChatGPT自己做搜索,首先保证了问答底座模型的智能程度。 其次在检索联网信息层面会做黑盒优化,包括 Query Rewrite / Intent Detection / Reranking 这些措施。 最终依赖自身模型的 Long Context 特性,效果就能做到比其他纯 Wrapper 类型的 AI Search Engine 要好一点。 3. 我并不觉得大模型厂商自己做 AI 搜索 就一定会比第三方做的好。 比如我做 ThinkAny, 首先接入 claude-3-opus,在模型底座智能程度方面,就不会输 gpt-4,第三方甚至能有更多的选择,针对不同的场景切换不同的模型。 其次,Long Context 也有很多模型能够保证。 再者,工程层面对 RAG 挂载上下文内容的优化,ChatGPT 能做,第三方也可以做。 4. 做好 AI 搜索引擎,最重要的三点是准 / 快 / 稳,即回复结果要准,响应速度要快,服务稳定性要高。 其次要做差异化创新,错位竞争。比如对问答结果以 outline / timeline 等形式输出,支持多模态搜索问答,允许挂载自定义信息源等策略。 5. AI 搜索引擎是一个持续雕花的过程。 特别是在提升准确度这个问题上,就有很多事情可以做,比如 Prompt Engineering / Query Rewrite/ Intent Detection / Reranking 等等,每个步骤都有不少坑。 其中用 function calling 去做 Intent Detection 就会遇到识别准确度很低的问题。 用 llamaindex + embedding + Vector DB 做 Reranking 也会遇到排序效率低下的问题。 6. AI Search + Agents + Workflows 是趋势。 AI Search 做通用场景,通过 Agents 做垂直场景,支持个性化搜索需求。 通过 Workflows 实现更加复杂的流程编排,有机会把某类需求解决的更好。 使用 GPTs 做出的提示词应用或知识库挂载型应用,价值点还是太薄。 7. 我个人不是太看好垂直搜索引擎。 一定程度上,垂直搜索引擎可以在某个场景做深做透,但是用户的搜索需求是非常多样的,我不太可能为了搜代码问题给 A 产品付费,再为了搜旅游攻略给 B 产品付费。 垂直搜索引擎自建 index 索引,工程投入比较大,效果不一定比接 Google API 要好,而且接入的信息源太有限。 8. AI 搜索是一个巨大的市场,短时间内很难形成垄断。 海外 Perplexity 一家独大,国内 Kimi/秘塔小范围出圈。各家的产品体验,市场占有率还没有达到绝对的领先,后来者依然有机会。 9. AI 搜索引擎需要尽早考虑成本优化。 主要支出在于大模型的 token 成本和搜索引擎的 API 请求费用。 成本优化是个持续的过程,比如可以自行部署 SearXNG 来降低搜索的成本,部署开源模型来降低大模型的 API 调用成本。 day one payment,趁早向用户收费也许是一种 cover 成本的好办法,但是也要考虑用户流失的问题。 以上是我个人做一个多月以来的一些经验和思考。欢迎交流探讨。

封面图片

Devin第一手使用体验:完成度很高 但要替代程序员还很远

Devin第一手使用体验:完成度很高 但要替代程序员还很远 在演示中,Devin 几乎已经可以独立完成很多人类程序员需要大量时间才能完成的工作,效果一点不比普通程序员差。但是,产品能力的边界在哪里,实际体验和演示时候有差距,还得看上手实测之后的效果。这位斯坦福的小哥在 Devin 发布的第一时间就联系了团队,获得了第一手体验的资格。他让 Devin 帮它做了几个难度不一的项目,录制了一个视频,在推上写下了自己的使用感受。首先是让 Devin 做一个用 API 获取股票价格的软件:下一个任务是让 Devin 做一个可以让普通用户直接与大模型下棋的网站。需求复杂的编程任务还搞不定用户下一步棋,系统会翻译成提示词给 GPT-4,然后 GPT-4 进行回复,然后回复再被转换为反映在棋盘上的具体某一步棋。按照小哥的要求,系统需要由相当多的部件组成。他个人最为关注在这个系统的开发过程中,Devin 能不能做到以下几点:知道如何准确地使用 GPT-4 API,因为大多数 LLM 实际上并不知道如何使用,并且 API 的调用存在版本冲突。正确地请求 API 密钥并安全地处理。处理包错误。了解如何提示 LLM 下棋并能精确地返回提示词。令小哥想不到的是,Devin 不仅要求小哥提供 API 密钥,而且在试用过程中还可以正确地保护它。不过,Devin 目前反馈速度还相当慢,小哥推测是因为后台发生的代理提示远远比要看到的要多得多。从小哥发起请求开始,它花了大约 19 分钟才询问 API 密钥。小哥猜测,如果延迟是由于他们在后台运行大量提示造成的,那么延迟应该会随着时间的推移而加快。因为他们以后可以访问专用 GPU 或与 Claude 或 OpenAI 合作降低延迟(估计是 GPT-4 或 Claude Opus)。Devin 首先制定了一个规划。在右上角,用户可以切换“跟随”状态,这样用户可以将屏幕自动移动到#Devin 当前激活了的选项卡上。小哥没有打开跟随状态,因为他希望随时观察各个位置的变化。规划器会随时保持针对当前任务的更新状态。Shell 看起来和普通的 Shell 没什么区别,但用起来真的很有趣!Devin 在工作过程中会打开多个 shell,在 shell 的底部,用户可以拖动蓝色滑块来往前查看 Devin 编写的命令。下图是它当在尝试调试棋盘未渲染的内容。与此同时,小哥要求它再执行一个数据分析的任务。小哥让 Devin 去“创建一张过去五十年南极洲海水温度的地图”。对于这个请求,小哥觉得有两个方面可能很具有挑战性:处理空间数据绘图 / 可视化。知道在哪里下载数据,而且了解如何使用数据源,因为地理空间数据处理起来很麻烦。Devin 能像一个优秀的程序员一样聪明地阅读自述文件,并且还执行一些基本的 EDA 来理解数据结构。数据居然是一个 ascii 文件,小哥觉得有点奇怪。小哥单击对话“调试 Python 脚本...”中的其中一个步骤时,它会打开与该步骤相关的代码库部分,因此可以跟踪某一个具体时间点发生的情况。小哥比较担心的是,如果不是必须要询问 API 密钥,Devin 似乎会不停地编码停不下来。所以他试了试是否可以更改他之前提出的请求或指定其他内容,中断 Devin 的编码过程。因为对于大部分用户在编码时,都有可能会改变主意或者有一些新的东西想要添加进系统之中,能够处理这种情况是很有必要的。这是编码过程中的截图:浏览器界面的呈现方式如下:然后小哥又提了针对数据可视化的任务又提了一个要求,让系统将高温设置为蓝色,低温设置为红色。为了不中断编码的过程,似乎 Devin 又开启了一个工作线程来记录小哥的临时要求。最终,Devin 将 App 部署到了 Netlify 上了,一个应用已经上线了。网页的链接: Bug 的。因为小哥要求的是南极洲的温度记录,似乎对于 Devin 来说它理解起来有些障碍。于是小哥把要求显示的位置改为了北美。总结小哥没有给出 Devin 修改了 Bug 的结果,只是初步总结了用 Devin 开发的第一个网站的使用体验。先说优点:Devin 产品化做得很好,他给人的使用体验是一个完整的产品而不是只是一个简单的对话框。AI 是系统最关键的部分,但支撑 AI 功能的产品化的结构是 Devin 的亮点。Devin 能够完成自动部署,API 密钥保护,随时修改和添加需求等等非常好的各种功能。产品的完成度已经非常高了,远远超过了一般的演示 Demo。再说缺点:Devin 的反应还很慢,当然小哥也说,因为他用的是 1M 的 Starlink 来上网,所以反应慢很有可能是他自己的原因。其次就是还不能允许用户直接自己编辑代码,而且也没法协作完成。当然,最初那个下棋的应用,难住了 Devin,最终没有完成部署。而那个数据可视化的任务,似乎也有些 Bug。最终,小哥用 Devin 做了一个 chrome 插件,可以帮助用户把 Github repo 转化成 Claude prompt。插件下载地址: Devin 的可视化项目的结果只做出了一个有 Bug 的网页。看样子 Devin 本质上还只是一个可以上网的大模型,现在要让他解决实际问题还有难度。参考资料: ... PC版: 手机版:

🔍 发送关键词来寻找群组、频道或视频。

启动SOSO机器人