知识点思维导图
29 个知识节点
Prompt Engineering（06） - 思维链与推理提示
读完后，你应能完成以下任务：
- 绘制“Prompt Engineering（06） - 思维链与推理提示 / 先看一道模型「会算错」的题”的关键对象与数据流，解释“因为你逼它「直接给答案」——它没有列式、没有中间步骤，相当于让一个人不许打草稿、心算多步运算，自然容易出错。”，并用源码位置、日志或 Trace 标注证据。
- 为“Prompt Engineering（06） - 思维链与推理提示 / 为什么「一步步思考」就有效”设计正常与异常输入，验证“它生成文字是「一个词接一个词」往外蹦的，没有独立的「打草稿区」。”，输出首个偏差位置与回归测试结果。
- 实现“Prompt Engineering（06） - 思维链与推理提示 / 三种写法”的最小代码或配置，检验“适合绝大多数场景，一句话成本几乎为零，先试它准没错。”，输出命令、结果与 Diff，并说明不适用边界。
本章目标：掌握让模型分步推理的技巧，显著提升逻辑、数学、复杂判断类任务的准确率。
一、先看一道模型「会算错」的题
来一道小学应用题，直接问模型：
小明有 5 个苹果，他买了 3 袋，每袋 4 个，然后送给朋友 6 个。他现在有几个苹果？
请直接给出答案。
你会发现模型有时会脱口而出一个错的数字，比如：
9 个
明明是个简单题，为什么会错？因为你逼它「直接给答案」——它没有列式、没有中间步骤，相当于让一个人不许打草稿、心算多步运算，自然容易出错。
现在我们只加一句话：
小明有 5 个苹果，他买了 3 袋，每袋 4 个，然后送给朋友 6 个。他现在有几个苹果？
让我们一步步思考。
模型这次会这样答：
让我们一步步算：
1. 原有 5 个。
2. 买了 3 袋，每袋 4 个，共 3 × 4 = 12 个。
3. 现在有 5 + 12 = 17 个。
4. 送出 6 个，剩 17 - 6 = 11 个。
答案：11 个。
正确了。就加了五个字「让我们一步步思考」，答案就从错变对。 这就是思维链（Chain of Thought，简称 CoT）。
二、为什么「一步步思考」就有效
打个比方：让你心算 23 × 47，容易错；但给你纸笔列竖式，一步步算，基本不会错。
模型也是一样。它生成文字是「一个词接一个词」往外蹦的，没有独立的「打草稿区」。当你要求它直接给答案，它就是在「心算」——一步到位，错误率高。
而当你让它「一步步思考」，它会先把推理过程一行行写出来，每一步都基于上一步的结果。这相当于给了它一张草稿纸：
- 把一个复杂问题，拆成了若干个简单小问题；
- 每一步只做一点点，做错的概率大大降低；
- 后面的步骤能「看到」前面写出来的中间结果，顺着推下去。
一句话记住：让模型把思考写出来，它就不用「心算」，而是在「打草稿」——草稿越清楚，答案越靠谱。
三、三种写法
3.1 写法一：Zero-shot CoT（最简单，最常用）
不给任何示例，直接在问题后面加一句「触发推理」的话。这是性价比最高的技巧，记住几句万能咒语：
让我们一步步思考。
请先分析，再给出结论。
Let's think step by step.
适合绝大多数场景，一句话成本几乎为零，先试它准没错。
3.2 写法二：Few-shot CoT（给带推理过程的示例）
把第 05 章的 few-shot 和 CoT 结合：示例里不光给「答案」，还给出「怎么推出这个答案」的过程。模型会模仿你的推理方式。
问：停车场有 12 辆车，开走了 4 辆，又来了 7 辆。现在有几辆？
答：先算开走后：12 - 4 = 8 辆；再算开来后：8 + 7 = 15 辆。答案是 15 辆。
问：书架上有 20 本书，借出 8 本，又还回 3 本。现在有几本？
答：先算借出后：20 - 8 = 12 本；再算还回后：12 + 3 = 15 本。答案是 15 本。
问：果园有 30 棵树，砍掉 5 棵，又种了 9 棵。现在有几棵？
答：
模型会照着示例的推理格式，一步步算出 34 棵。适合你想让模型按特定推理套路来、或者推理步骤有固定结构时用。
3.3 写法三：引导式分步（你来规定步骤）
当任务有明确的分析框架时，直接把步骤列给它，让它逐项填：
请评估这个创业点子是否值得做，按以下步骤分析：
第一步：这个点子解决了谁的什么痛点？
第二步：现有的替代方案是什么？它比替代方案好在哪？
第三步：最大的风险是什么？
第四步：综合以上，给出「值得做 / 不值得做 / 需要更多信息」的结论。
点子：做一个帮宠物主人预约上门美容的 App。
这种写法控制力最强——你不仅让它推理，还规定了从哪几个角度推理，特别适合分析、评估、决策类任务。
四、多候选、自洽与投票
单次分步推理仍可能在早期走错方向。对答案可规范化、错误代价较高的任务，可以独立生成多个候选，只提取每个候选的最终答案，再按多数结果或确定性验证器选择。这个方法通常叫 self-consistency，自洽指多个独立推理路径是否收敛到同一个结论。
多候选不是简单重复同一次确定性调用。需要允许一定采样差异，并在投票前把 11、答案是 11 等表达归一化。代码生成、事实问答和开放式建议没有可靠的多数真值，多个候选可能共享同一个错误；这类任务应使用测试、检索证据或规则校验，而不是把票数当正确性。
五、适用与不适用
适合用 CoT：
- 数学/计算：多步运算、应用题。
- 逻辑推理：推断、排除、条件判断。
- 多步任务：需要分阶段、前后依赖的问题。
- 复杂决策/分析：要权衡多个因素再下结论。
- 代码调试：让它先分析代码逻辑，再找 Bug。
不必用（甚至别用）：
- 简单事实问答：「中国的首都是哪？」——加「一步步思考」纯属啰嗦，还可能画蛇添足。
- 要求输出简洁/结构化时：CoT 会带出一大段推理过程。如果你只想要最终的 JSON 或一个数字，推理过程反而是干扰（解决办法见下一节）。
- 纯创作类：写诗、起名，靠的是发散不是推理。
- 对延迟/成本敏感：CoT 会生成更多文字，更慢更贵。简单任务不值当。
六、想要推理又想要简洁？两全其美的技巧
CoT 的副作用是输出一大堆推理过程。如果你既要它「想清楚」、又只想拿到「干净的最终答案」，有两招：
招数一：让它先推理，最后单独给结论
请一步步分析后，在最后用「最终答案：」开头单独给出结论。
这样你的程序只要抓「最终答案：」后面那部分就行。
招数二：让它「内部思考」，只输出结果
请在心里一步步推理，但只输出最终答案，不要展示推理过程。
注意：招数二会牺牲一部分 CoT 的准确率收益（因为它没真把过程写出来），但比完全不推理强。要最高准确率就用招数一，要最干净输出且能接受准确率略降就用招数二。
七、一个「直接问错 vs 加 CoT 对」的完整对比
来个稍微绕的逻辑题：
有三个人 A、B、C。已知：
- A 不是医生。
- B 不是老师，也不是医生。
- 三人分别是医生、老师、律师中的一个，各不相同。
请问谁是医生？
直接问（不加引导）模型可能脱口而出，有概率答错（比如随口说 A）。
加 CoT（加「让我们一步步推理」）：
让我们一步步推理：
1. B 不是老师也不是医生，所以 B 只能是律师。
2. A 不是医生，律师已被 B 占了，所以 A 只能是老师。
3. 剩下 C，那 C 就是医生。
答案：C 是医生。
逻辑链条清清楚楚，每一步都能验证。这类「需要排除推理」的题，CoT 的提升尤其明显。
八、常见错误
- 简单题也硬加 CoT：事实问答、打招呼也来一句「一步步思考」，又啰嗦又慢。
- 要简洁输出却用了 CoT，又没收口：结果模型吐一大段推理，把你要的 JSON 淹没了。记得用第五节的收口技巧。
- 步骤定得太死或互相矛盾：引导式分步时，规定的步骤本身不合理，反而把模型带沟里。
- 以为 CoT 能消除所有错误：它能显著降低出错率，但不是万能的。关键结果仍要核对。
- Few-shot CoT 的示例推理写错了：模型会模仿错误的推理方式，越学越偏。
九、最佳实践
- 先试 Zero-shot CoT：一句「让我们一步步思考」成本最低，多数推理任务直接见效。
- 按任务选写法：要套固定推理格式用 Few-shot CoT；有明确分析框架用引导式分步。
- 推理与输出分离：需要干净结果时，让它「先推理、最后单独给结论」，程序只取结论部分。
- 只在该用时用：简单、事实型、创作型任务别滥用，省时省钱。
- 关键结论仍要验证：CoT 提升的是概率，不是保证。
- 和格式控制配合：CoT + 「最终答案用指定格式输出」是稳定拿结构化推理结果的黄金组合。
十、本章小结
- 思维链（CoT）= 让模型把推理过程一步步写出来，相当于给它一张草稿纸，避免「心算出错」。
- 三种写法：Zero-shot CoT（加一句咒语）、Few-shot CoT（给带推理的示例）、引导式分步（你规定步骤）。
- 适合数学、逻辑、多步、决策类任务；简单事实问答和纯创作不用。
- 想要推理又要简洁？让它「先推理、最后单独给结论」。
- 核心心法：让模型把思考写出来，它就不再心算，而是打草稿。
下一章讲控制输出格式——如何让模型稳定吐出 JSON、表格这类「程序能直接用」的结构化结果。
十一、配套 Demo
见 提示词工程-demo/06-demo/：一组对照提示词，同一道需要推理的题给了「直接问」和「加思维链」两个版本。你可以拿任意 AI 工具各跑几次，亲眼看看准确率的差别。
十二、动手实践：demo：思维链对照实验（直接问 vs 加思维链）
这个 Demo 不用写代码。目的：让你亲眼看到「让我们一步步思考」对推理准确率的影响。
12.1 怎么用
- 打开任意 AI 对话工具。
- 每组都有 A（直接问）和 B（加思维链）两个版本。
- 每个版本各跑 3 次（模型有随机性，跑一次说明不了问题）。
- 数一数：A 版本错了几次，B 版本错了几次。
提示：用「新对话」分别跑 A 和 B，避免上一次的回答影响下一次。
12.2 实验组 1：应用题（含多步运算）
A · 直接问
小明有 5 个苹果，他买了 3 袋，每袋 4 个，然后送给朋友 6 个。
他现在有几个苹果？请直接给出答案，不要过程。
B · 加思维链
小明有 5 个苹果，他买了 3 袋，每袋 4 个，然后送给朋友 6 个。
他现在有几个苹果？让我们一步步思考。
✅ 正确答案：11 个（5 + 3×4 − 6 = 11）。 👉 观察：A 版本「直接给答案」时更容易算错；B 版本列出步骤后基本都对。
12.3 实验组 2：逻辑推理（排除法）
A · 直接问
有三个人 A、B、C，分别是医生、老师、律师中的一个，各不相同。
已知：A 不是医生；B 不是老师，也不是医生。
谁是医生？直接回答。
B · 加思维链
有三个人 A、B、C，分别是医生、老师、律师中的一个，各不相同。
已知：A 不是医生；B 不是老师，也不是医生。
谁是医生？请一步步推理后再回答。
✅ 正确答案：C 是医生（B 只能是律师 → A 只能是老师 → C 是医生）。 👉 观察：A 版本有概率随口答错；B 版本推理链清晰，几乎不会错。
12.4 实验组 3：又要推理、又要干净输出
如果你既想让它想清楚、又只想拿一个干净答案，用这个写法：
有三个人 A、B、C，分别是医生、老师、律师中的一个，各不相同。
已知：A 不是医生；B 不是老师，也不是医生。
谁是医生？
请先一步步推理，最后用「最终答案：」开头单独给出结论。
👉 这样你的程序只要抓「最终答案：」后面那部分即可——兼顾准确率和可用性。
12.5 你应该观察到的结论
- 需要多步计算或推理的题，加一句「让我们一步步思考」，准确率明显提升。
- 推理过程被「写出来」，相当于给了模型草稿纸，避免心算出错。
- 如果只想要干净结果，让它「先推理、最后单独给结论」，两全其美。
反向验证：拿一个简单事实题（如「中国的首都是哪？」）试试加 CoT，你会发现纯属多余——这印证了第 06 章说的「简单事实问答不用 CoT」。
十三、总结
- 先看一道模型「会算错」的题：因为你逼它「直接给答案」——它没有列式、没有中间步骤，相当于让一个人不许打草稿、心算多步运算，自然容易出错。
- 为什么「一步步思考」就有效：它生成文字是「一个词接一个词」往外蹦的，没有独立的「打草稿区」。
- 三种写法：适合绝大多数场景，一句话成本几乎为零，先试它准没错。
- 多候选、自洽与投票：对答案可规范化、错误代价较高的任务，可以独立生成多个候选，只提取每个候选的最终答案，再按多数结果或确定性验证器选择。
- 适用与不适用：要求输出简洁/结构化时：CoT 会带出一大段推理过程。
- 想要推理又想要简洁？两全其美的技巧：CoT 的副作用是输出一大堆推理过程。
学完自测
选择所有正确答案；提交后逐项核对判断依据。