自 OpenAI 的 ChatGPT 横空出世至今，各种 AI 大模型百花齐放、百家争鸣。按照用途可以分为两类：
- 对话类：即通过文字、语音、图片或者视频输入来给模型下达指令，然后模型按照指令以文字的形式将回答输出给用户；
- 生成类：目前 AI 界已经实现语音、图片和视频的生成式 AI，输入方式不变，输出方式以这些类型为主体。
AI 的诞生为人们的工作生活都提供了极大的便利。在工作中，即使不会编程，也可以通过 AI 来生成一些可以提高工作效率的脚本，比如：
- 整理 Excel 数据
- 进行数据分析
- 根据预设条件进行简历筛选
- ……
但是大多数情况下，人们发现 AI 返回的结果并没有达到预期，甚至会出现严重的幻觉（也就是瞎编乱造）。这种问题通常是因为人们在给大模型发送提示词时，输入的内容往往会过于泛化或者没有问到点子上，举两个例子：
- 本来想结合实际业务写一个可维护性好、可读性强的自定义 Hook，但是因为还没有使用过自定义 Hook，所以直接提问「自定义 React Hook 怎么写？」，从而只得到一个入门级别的 demo
- 有两个抽屉，其中一个侧滑框 A 要展示在侧滑框 B 的上面，但是现在 A 设置了
z-index:9999却没有效果，本来想问为什么及如何解决，但是最终千言万语汇成了一句「CSS 中如何将一个弹窗设置在顶层？」
那对于这两个被“精简”了的问题来说，Gemini 是这样回答的：
反面示范
可以看到 Gemini 给我们讲解了自定义 Hook 的基础用法，但是实际上我们这里可能是想再问得具体一点，比如：「自定义 React Hook 怎么写？以及如何做到让该 Hook 的可维护性好、可读性强并且返回的值符合当前的业务场景？」
为什么会写这个问题，是因为一些新手在看完文档或者相关入门资料以后，第一反应是按照这些资料中写的 demo 原模原样写的抄一遍，这就导致写得业务大概率和实际场景不符，demo 中返回了一个函数，他也跟着返回一个函数，但实际上直接返回值更合理。
看看，是不是比之前好很多了，这就是提问的智慧！
OpenAI 官方提供的 Prompt 编写文档！
为了能让我们写出有效的、能让大模型理解的提示词，OpenAI 官方也推出了「提示词工程」说明书，也算是为使用 ChatGPT 出了一个提示词标准。
可以看到官方为我们提供了6个标准：
-
Write clear instructions 写下清晰的提示
- 问题要携带关键信息
- 要定义好背景角色
- 对于问题的不同部分，可以使用分隔符进行区分
- 有条理、有次序的指定完成任务所需要的步骤
- 提供例子，让大模型有参考对象
- 指定回答的长度，也就是字数
-
Provide reference text 提供参考文字
- 让模型使用指定的文本进行回答。说简单点，就是类似于让 Kimi Chat 帮你读一本书，你喂它一本书，它将书中的内容给你概括起来
- 让模型在回答时可以引用问题中的内容。
-
Split complex tasks into simpler subtasks 将复杂的任务拆分为更简单的子任务
- 使用意图分类来识别与用户查询最相关的指令
- 对于需要很长对话的内容，总结或者过滤以前的对话（更合理的方式看下一条）
- 分段总结长文档并递归构建完整摘要（个人理解也适用于上一条）
-
Give the model time to “think” 给模型时间“思考”
- 在做一些判断性问题时，可以让模型先在给出结论之前制定自己的解决方案
- 有一些引导性场景下，模型回答问题时的推导过程可能不适合与用户分享。这个时候可以使用内心独白或者一系列查询的方式来隐藏模型的推理过程
- 在询问模型时检查是否有遗漏什么内容。也就是说，对于一些长文本的内容，大多数情况下需要我们多次提问才可以得到最准确最完整的答案
-
Use external tools 使用外部工具
- 使用基于嵌入的搜索实现高效的知识检索
- 使用代码执行来执行更准确的计算或调用外部API
- 授予模型访问特定功能的权限
-
Test changes systematically 系统地测试及变更优化
- 官方这里提供了一个：参考黄金标准答案评估模型输出
我们可以根据文档中提出的这6个原则写一个自动生成 prompt 的 AI 应用，这样也可以轻松搞定提示词了。
写在最后
提示词的编写套路其实大同小异，掌握好主要的几个关键点就可以写得大差不差。而最便捷的方式就是花点时间用这些方法去定制化一个自动生成 prompt 的 AI 应用，之后的工作就是润润提示词就可以了。
附思维导图：
