首位「提示词指南」作者：1500 篇论文浓缩 5 招，让 AI 说人话

摘要：过去两年，相关论文暴涨 40 倍，累计超 1,500 篇——每一篇都在追问：怎样写 prompt，才能让 AI 说人话、答得准？

你问它写段代码，它回你三页解释；

你让它写份报告，它却像在参加作文比赛。

AI 越来越强，但我们和它的对话，却越来越像“鸡同鸭讲”。

问题不是模型不行，而是你不会说“它的语言”。

这正是提示词工程（Prompt Engineering）存在的理由。

过去两年，相关论文暴涨 40 倍，累计超 1,500 篇——每一篇都在追问：怎样写 prompt，才能让 AI 说人话、答得准？

这场浪潮，是一个年轻人提前引爆的：

Sander Schulhoff，甚至在 2022 年 11 月 30 日 ChatGPT 上线前两个月，就写出全球第一本提示词工程指南 “Learn Prompting”，至今触达 300 万+ 用户。

2025 年 6 月，他联合 OpenAI、Google 等 6 家机构，完成一次划时代的研究：

汇总 1,500 篇论文 + 社区技巧；实测 200+ 技法，逐项 AB 测试；最终筛出 5 套适用于所有场景的提示词打法。

Prompt，早已经不是小技巧，而是你能否用好 AI 的分水岭。

本文将详细解读这 5 套提示词打法的来龙去脉：

你将看到：

我们先从第一个问题开始：

在正式拆解之前，Sander 先回答了一个最常见、也最被忽视的问题：

“现在不是连自然语言都能直接用了，Prompt 这套东西是不是已经没用了？”

他的回答很直接：

提示词工程一点也没过时，反而比以前更重要。

这句话背后，有三个他在采访中重点澄清的误解。

❶ 误解一：大模型都能理解自然语言了，还用提示词干嘛？

很多人以为，只要模型越来越聪明，用户只需“随口一说”就能得出好结果。

但 Sander 指出，这是一个误会——你说得清楚，不代表模型一定明白你想干什么。

就算你觉得提示词写得完美，模型也可能没抓住你的意图。

为什么？因为模型不会“推测你的上下文”，它只能根据你写的每一个词去“猜测”要完成的任务。

❷ 误解二：提示词不过是凑几个关键词，能有多大差别？

Sander 提出了一组非常关键的测试数据：

我们只调整了一下表达方式，准确率就从 10% 提升到 90%。

这句话非常震撼。意思是：

不是模型变了，不是数据变了，只是换了个说法，输出质量就完全不一样。

这说明，提示词不是“装饰”，而是决定你结果好不好的关键因素。

❸ 误解三：提示词太复杂，普通人用不上

Sander 非常明确地强调：

我们就是要找出那些普通人也能用、而且能反复成功的方法。

他认为，一套好提示词结构，不该是写给软件工程师的，而是像“模板”那样，能被反复套用。

比如他说：像加上一句“我们一步步来想想”，这种简单句就能大幅提升回答条理。

也就是说：写 prompt，不是比谁更专业，而是比谁更接地气。

Sander 在访谈中透露，他们花了 3 个月时间，从1500 多篇论文、提示词社区经验和上百轮实测中，最终只留下了 5 套最常见、最稳定、最管用的提示法。

这些提示词结构不是某个模型特有的，也不是程序员专属，而是几乎适用于所有主流模型、所有基础任务的通用打法。

他说：我们想找的是那种无论任务、领域、使用者是谁都能用的技巧。

下面就是这 5 套被他称为最有效提示技巧：

Sander 提出：“与其让模型凭空写，不如先给一个例子”。

比如你希望 AI 写出跟你风格一致的邮件内容，而不是输出一篇官方腔模板邮件：

如果要写后续邮件，让模型看看你之前邮件的风格。

这时候，最简单有效的做法，就是先贴一个你写过的邮件，接着说：“按这个风格，再帮我写一封”。

这种少样本提示（few-shot）方法的好处是：模型会自动从例子里提取语言风格、语气、段落结构，而不用你一句句解释。

就像 Sander 提到的：“与其说格式是 XML、还是问答式，不如直接给它看一段例子，让它照着做。”

✅ 技法二：任务拆解（Decomposition）

很多复杂任务，其实不该一句话问完。

比如你想让 AI 处理一个“汽车退货”的流程，它可能回答不全、跳过关键步骤。

Sander 提出了一种分步式思路：

我们把任务拆成三个小任务，每个都做了个智能体，

最后让它们协同工作。

判断客户是否符合退货政策；检查车辆状态是否完好；写一封合理的拒信或通过信。

然后告诉模型：“请先判断第 1 点，再继续处理第 2 点……最后输出一封信。”

这种方式的本质是：别指望 AI 一步到位，而是像项目经理一样，一步步布置任务。

Sander 把这叫做“子任务 + 代理协调”的组合打法。

✅ 技法三：自我批评（Self-Critique）

有时你会发现，AI 第一次的回答不够准确。但你直接修改它，它却“听不懂”你的反馈。

Sander 给出了一种巧妙方法：

做法是：先提示 AI 回顾自己的输出，找出不合逻辑或表达不清的地方，然后根据它自己提的改进建议，来写新版。

这其实利用了模型“评估自己比改别人更擅长”的特点——它更擅长“给出建议”，而不是直接替你改。

你可以这样写提示词：

结果是：去掉背景信息，模型准确率立刻下降。

Sander 总结说：AI 最怕的信息是不够。不是多了出错，而是少了答偏。

✅ 技法五：提示集成（Ensembling）

如果你发现一个 prompt 不够稳，那就别只用一个。

Sander 分享了一个类似“专家投票”的方法：

我们用不同提示词测试同一模型，最后投票选择最佳输出。

然后让 AI 综合输出，或者你手动选一个效果最佳的。

Sander 特别提到，做推理任务时，“专家混合提示”非常有效，因为不同提示会触发不同的思维路径。

本节小结：

Sander 最后总结：它们的价值，不是写得花哨，而是让模型知道该怎么做。

很多人对提示词有效的原因理解是换个说法模型刚好听懂了，但这其实是误解。

Sander 在访谈中明确指出：

这不是运气，而是你帮模型建立了正确的“期待”——它知道你想要什么。

换句话说，提示词不是用来"忽悠 AI "的，而是让它明白你想要什么。

他把这个过程，拆成了三个核心影响点：

① 明确“该回答什么”

AI 模型最容易出错的第一个环节，不是答不对，而是压根没明白你问的重点在哪。

Sander 举了一个例子：

“比如你说“能帮我看看这个吗”，模型根本不知道你指的是哪一段内容。”

这时，只要你加一段背景说明，比如“这是我们上周写的用户增长报告”，准确率就会明显提升。

这就是前一节说的 Additional Context（上下文）和 Instructions Before Input（先讲清楚），其实本质作用就是：告诉模型“你现在要解决的，是哪件事”。

② 约定“该怎么回答”

即使模型理解了你的问题，它也可能输出一大堆废话。

Sander 解释：

模型的默认行为是"输出冗长内容"或 "容易偏离目标"，

除非你明确限制它。

为什么会这样？因为模型的训练目标不是答得短或答得准，而是最大化“像人”一样说话。很多时候，它宁可说得多，也不想冒“说错”的风险。

所以，你要告诉它我要的是什么格式，才能避免它兜圈子。

这就是“一步步来”和“角色扮演”能发挥作用的关键：

③ 降低“不确定感”

Sander 提到一个非常实用的思路：模型出错的最大原因，其实是不确定你要它干嘛。

这句话很关键。

AI 本质上是个预测机器。如果它对你的输入不确定，就容易答偏、答模糊、甚至胡说。

所以提示词不是在加要求，而是在减少它的犹豫空间。你给得越明确，它出错的空间就越小。

Sander 特别强调了提示词的“组合效应”：

“只要组合使用其中 2~3 个提示技巧，模型“胡说八道”的几率就能下降七成以上。”

这些技巧之所以有效，并不是因为模型更聪明，而是因为你说得更清楚了。

用一句话做了总结：

很多人以为，提示词就是一句一句地对话——试错、重写、再换说法，好像在和 AI “磨合”。

但 Sander 一上来就把这类方式单独拎出来定义了一个名字：

现在大多数人做的提示词，其实更像是在‘调试’。

什么意思？

你输入一句话，发现 AI 答偏了，就再加一句说明；还是不行，就换个方式重问。这一套 “边试边改”的提示方式，Sander 称之为：

“Chat-based prompting.”（对话式提示）

这种方式非常适合日常使用者（C端），比如你在 ChatGPT/DeepSeek 上问问题、让它生成文案、帮你写点代码，它回答得不对你就继续调。

但——问题来了。

做 AI 产品靠这种方式调提示，行不通。

实际上，AI 产品的团队没法每次都调来调去，他们需要的是稳定、可复用、能预期结果的提示结构。

对话调试可以临时修，但企业产品必须一次写好。

Sander 特别强调，“聊天式调试”是个人技巧，“提示产品”是产品设计的一部分：

开发产品里的提示，不是靠技巧取巧，而是要搭建可靠、能大规模运行的输入方式。

这也是为什么 Sander 在调研中，重点关注了Granola、Replit、Bolt 等 AI 工具公司：

这些团队都不是靠“ChatGPT/DeepSeek 那一套”对话来试错，而是提前搭建好提示模块，像写说明书一样，把背景信息、指令、格式要求等内容都写在固定框架里。

以硅谷知名的 AI 笔记公司 Granola 为例，他们的 prompt 模板是这样的：

你是一位高级数据分析专家，当前任务如下：- 背景信息：{{业务场景描述}}- 数据格式：{{表格字段说明}}- 输出要求：以 markdown 格式给出回答，并在最后附上一段总结请按上述要求完成任务。

再看 AI编程公司 Replit，他们的 AI Code解释功能用的提示不是怎么问，而是固定搭好的模块+变量：

Please explain the following code in simple terms:{{code_snippet}}

每一条 prompt，都是提前写好、结构清晰的“产品输入口”，用户看不见，但每次点击时 AI 就是按这个来执行。

你调 prompt，他们在建提示系统

主持人在对话中问得很精准：

在产品中使用提示，为什么往往效果更稳？

Sander 给的回答很简单：

因为你不是在想“这次怎么行”，而是在设计“每次都行”。

这就是关键区别。

你在 ChatGPT/DeepSeek 里，是提问的人；

在产品里，是提示框架的设计师。

你要做的，不是找到一句说法让它答得准，而是搭出一个稳定的问法模板，不管谁用都能用。

本节小结：

Prompt 工程的分水岭，不是用不用技巧，而是你是在调提示，还是在设计提示。

日常用 AI，就像调菜的口味，不对就重做；

但做 AI 产品，就像经营餐厅——每道菜都有标准配方，保证谁点都是一个味儿。

这就是提示词工程，从耍小技巧走向“工程化”的第一步。

请假设你是某某领域专家，比如资深数学教授……

请你表现得更加严谨/认真/专业……

如果答错了，你会被处罚/得不到奖励……

很多人以为，这类“角色扮演式提示”能提高 AI 的输出质量。甚至有不少平台把这种写法，打包成了“高效提示指南”。

但在这场访谈中，Sander 直接戳破了这些方法的'假象'。

角色扮演提示：效果微乎其微

主持人问了这样一个问题：有哪些被广泛使用、但其实效果很差的提示方法？

Sander 的回答：一个例子是“角色扮演提示”。虽然很多人觉得好用，比如“你是资深数据分析师”，但数据并不支持它的有效性。

他提到，团队对这一类提示做了成体系的 A/B 测试：

分别用“普通问法”和“加角色扮演”的问法来让 AI 完成任务；对比模型输出的正确率和稳定性；

结果发现：几乎没有显著差异。

换句话说，这种“你是专家”的提示，更像是心理安慰，并不会真正让 AI 表现更好。

威胁 / 奖励式提示：AI 并不理解你的情绪

另一个被提及的误区，是“激励性提示”：

如果你做对了，我给你奖励。

如果你搞砸了，你就失业了。

很多用户以为“给 AI 加压力”，它就会更认真。但在 Sander 看来：

“这些提示词假设 AI 懂得“惩罚”或“奖励”的概念，但实际上它不懂——它只是根据你输入的词来猜下一个词。”

AI 不会因为你恐吓它就认真起来，也不会因为你说有奖金就更聪明。它根本没有那种感受机制。

它只是在分析你的句子，然后用最常见的逻辑生成回复。

所以，这种“请认真点”“好好干活”式的说法，其实并不会让结果更靠谱。

实验证据：这些写法，试了反而会降低效果

Sander 分享了他们团队的实验细节：

“我们把角色扮演、恐吓、奖励这类技巧加到提示词中，发现结果要么没有提升，有时候甚至还更差。”

这是一个关键点：很多看起来合理的写法，其实只是你在多加废话。

尤其是在生成类任务中，加了这些花哨提示，反而会“干扰”模型的重点，让它更容易跑偏。

甚至有时候，会让模型答得更离谱。

你在输入一句 prompt，但实际上，你不是在“提问”，而是在传递一份“任务书”。

很多人误以为提示词只是“话术”，但 Sander 指出，它其实是人和 AI 协作的接口语言，一套完整的操作说明。

Prompt 的三个核心作用

Sander 在访谈中明确指出，真正有效的提示，具备三种“隐藏功能”：

协调器（coordinator）：把不同任务目标捋清楚，告诉模型主线在哪；筛选器（filter）：从你的输入信息中抓取重点，避免答偏；执行计划（execution plan）：告诉模型要输出什么、顺序如何、格式长啥样。比如下面这个提示：你是一位项目经理，需要对以下日报做总结：1）概括主要进展；2）识别潜在风险；3）生成三句话报告，发给 CEO。日报如下：{{文本内容}}

这段话不是问问题，而是在交代任务：

这就是提示作为“协议”的具体表现。

主持人在听到这番话后追问了一个关键点：所以你是说，Prompt 其实是一种“接口”？

Sander 给出确认：对，把提示想象成你在设计一个界面，只不过这个界面不是按钮，而是语言。

他进一步解释道：

提示工程的重点不再是“说得巧”，而是“用语言设计流程”。

这句话非常重要——

你写 prompt，不是为了让 AI 感觉“你说得真聪明”，而是为了让它像流程图一样跑通任务。

从技巧到工程：Prompt 的下一步是“结构化 + 模板化”

Sander 也谈到了提示工程的未来：未来，团队会越来越多采用提示模板、版本管理、结构化测试。

这意味着：

这种变化已经在发生。