3.3 思维链与推理提示何时有用、何时有害
一句话结论：「逐步思考」不是万能咒语。它之所以有效，是因为给了模型中间产物来安放推理；它之所以有害，是因为这些中间产物会进入上下文、抢占注意力、并可能自我强化错误。
读这篇之前
需要先读 3.1（三件套）和 2.1（模型预测下一个 Token）。这一篇讲的是"方法层"——怎么把模型的推理过程引导出来。
一、先看全景：提示词的三层结构
在讲思维链之前，先把位置摆清楚。生产级提示词分三层：[原文 707]
| 层 | 管什么 | 具体内容 |
|---|---|---|
| 结构层 | 骨架 | Role / Directive / Context / Exemplars / Format / Style |
| 方法层 | 怎么思考 | System Prompt、Role Playing、Few-shot、CoT、ToT、ReAct、APE |
| 输出工程层 | 让回答可直接用 | 结构化、解析、验证 |
这一篇属于方法层。七个技术的全景对照：[原文 707]
| 技术 | 一句话说明 | 适用场景 |
|---|---|---|
| System Prompt | 模型行为的"操作系统" | 所有 Agent 的基础 |
| Role Playing | 让模型扮演特定角色 | 专业领域输出 |
| Few-shot | 给几个示例引导输出 | 格式固定、模式明确 |
| CoT | 「请逐步思考」——展示推理过程 | 数学、逻辑、多步推理 |
| ToT | 探索多条路径再选最优 | 规划、决策、创意 |
| ReAct | Thought→Action→Observation 循环 | 工具调用、Agent 主循环 |
| APE | 让模型自动生成和优化提示词 | 批量优化、自动化 |
注意 CoT 和 ReAct 的区别：CoT 只在"想"的层面展开推理；ReAct 把"想"和"做"串成循环。前者是提示技巧，后者是 Agent 的运行时结构（第 10 章详述）。
二、思维链为什么有效
思维链（Chain-of-Thought, CoT）的做法很简单：要求模型先写出推理过程，再给答案。
为什么这有效？回到 2.1 的机制：模型在逐个 Token 生成。每一个 Token 都是基于"目前已有的全部 Token"算出来的。
这意味着：
模型后面输出的内容，能"看到"前面输出的内容。
如果你直接要答案，模型只有一次机会"在心里算完"——而这个"心里"其实是它在生成答案那几个 Token 时的隐式计算。
如果你要求它先写推理，它就把"中间计算"变成了显式的文本。这些文本成了后续生成答案时的依据。相当于给它一张草稿纸。
这三层好处：
| 好处 | 机制 |
|---|---|
| 减少一次跳跃的跨度 | 把"复杂推理"分解成多个小步，每步只依赖前一步 |
| 中间结果可复用 | 前面算出的中间值，后面可以直接引用 |
| 可检查 | 推理过程写出来了，你（或者下一次调用）能核对 |
第三条在 Agent 场景里尤其有价值：推理过程是给"校验"用的。工具层、审核者、甚至模型自己（3.4 的自检）都可以看这段推理。
三、什么时候它有害
CoT 被广泛滥用，所以危害那一面少有人讲。四种典型情况：
情况一：任务本身不需要推理
如果任务是格式转换（把 Markdown 转 JSON）、信息抽取（从文本里找字段）、简单分类（正面/负面），推理过程完全是浪费——它不产生有用信息，只占 Token。
更糟的是：多余的推理可能引入新的错误。 模型在"想"的过程中可能自己编出一个不存在的约束，然后按那个错约束执行。
情况二：推理过程被写进上下文，抢占注意力
2.2 讲过：上下文是"半台检索引擎"，信噪比下降会让准确率下降。每一段推理都是额外的噪声，在长任务里不断累积。
情况三：错误会被"自我强化"
这是最隐蔽的危害。如果模型在推理第 2 步就得出一个错误结论，第 3-5 步都会基于这个错误继续推。而且因为推理"看起来完整"，最终答案反而更自信、更难被质疑。
相比"直接给个错答案"，"给了详细推理的错答案"更危险——因为它欺骗性更强（2.3 的"过度自信"）。
情况四：它会让输出不再是合法 JSON
3.2 讲过：输出要被程序读，就必须结构稳定。而 CoT 天然是自由文本——如果你让它"先推理再输出 JSON"，它很容易把推理混进 JSON 里。
解决方式：把推理放进 schema 的一个字段里。
{ "thought": "……推理过程……", "action": "call_tool", "tool_name": "..." }
这正是 ReAct 的标准做法：Thought 是结构化的一个字段，不是游离在外的散文。
四、四类推理技术怎么选
| 技术 | 做法 | 成本 | 什么时候用 |
|---|---|---|---|
| 无推理 | 直接给答案 | 1× | 格式转换、抽取、简单分类 |
| CoT | 先写推理再答 | 2-5× | 数学、逻辑、多步判断 |
| ToT（思维树） | 探索多条路径，评估后选最优 | 10×+ | 规划、决策、需要比较方案 |
| ReAct | 想→做→看→再想 | 取决于轮数 | 需要与外部交互 |
一条实用判据：
先测"无推理"能不能达到要求。能，就不要加推理。
因为推理的成本是真实的（Token、延迟、噪声），而收益只在"确实需要多步推导"时才出现。
ToT 值不值得
ToT 的思路是"生成多个候选路径，评估后选最好的"。它确实能提升复杂规划的质量，但成本是数量级的（要生成多条、还要评估）。
建议：先用 CoT，效果不够再考虑 ToT。绝大多数 Agent 任务用不到 ToT。
五、让推理有用的四个写法
如果决定用推理，不要只写"请逐步思考"。要给它结构：
| 写法 | 效果 |
|---|---|
| 指定步骤 | 「先列依据 → 再给结论 → 最后说明不确定性」 |
| 要求引用 | 「每条结论必须指出依据来自材料哪一段」 |
| 要求反例 | 「指出你的推理中哪一步最可能出错」 |
| 要求自检 | 「结论与依据冲突时，以依据为准并重述结论」 |
第三条特别有用：要求模型指出自己最薄弱的一环，能让它更早发现问题，也能让你知道哪里需要人工复核。
第四条是 3.4 讲的自检基础。
一个反面写法
❌ 请仔细思考，逐步分析，认真推理，确保答案正确。
这四项要求都是形容词，没有提供任何结构。它甚至可能增加模型啰嗦的倾向，而不提升准确率。
六、四种推理技术展开：CoT / ToT / ReAct / APE
上一节给了选择建议，这一节把四种技术的机制讲清楚，方便你判断什么时候该换。
CoT（思维链）：一条路走到底
模型沿一条推理路径往前走，每步基于前一步。优点是便宜、直接；缺点是一旦中间某步错了，后面全部继承，而且它自己不会回头。
适合：有明确解法的推导（算术、逻辑、按规则判断）。
ToT（思维树）：分叉、评估、回溯
把 CoT 从"一条线"改成"一棵树"：[原文 707]
┌─ 方案A ─┬─ A1 ─ 评估 7.5 ← 选这条
起点 ───────┤ └─ A2 ─ 评估 6.0
├─ 方案B ──── B1 ─ 评估 5.5
└─ 方案C ──── C1 ─ 评估 4.0
它做三件事：生成多个候选 → 逐个评估 → 沿最优路径继续。所以它能"回头"，不会一条错路走到黑。
代价也很明确：成本和延迟成倍增长（要多生成、多评估）。原文列的适用场景是规划、决策、创意——正是那些"没有唯一正确路径、需要比较"的任务。[原文 707]
判据：如果任务失败的主要原因是"选错了方向"而不是"算错了细节"，ToT 值得试；如果只是"算错"，CoT 就够。
ReAct：把想和做串成循环
ReAct 的形态是 Thought → Action → Observation 循环（1.1 已详述）。它和 CoT 的本质区别：
| CoT | ReAct | |
|---|---|---|
| 推理依据 | 只有模型自己写出的文本 | 文本 + 外部真实结果 |
| 能不能获得新信息 | 不能 | 能 |
| 属于 | 提示技巧 | 运行时结构 |
所以 ReAct 不是"更好的 CoT"，而是加了外部输入的 CoT。这也是为什么它需要工具。
APE（自动提示优化）
APE 的思路是：让模型自己生成、评估、挑选提示词，而不是人来手写。[原文 707]
它的适用场景很具体：批量优化、自动化场景——比如你有 500 个抽取任务，逐个手调提示词不现实。
但要注意：APE 优化的是"在这个评测集上表现最好的提示词"，而评测集本身的质量决定了它优化的方向。没有好的评测集，APE 只会帮你更快地过拟合（第 13 章评估）。
七、一个成本对照，帮你决定要不要加推理
把四种方案的成本与收益放进一张表，方便做取舍：
| 方案 | 相对成本 | 相对延迟 | 收益出现的前提 |
|---|---|---|---|
| 无推理 | 1× | 1× | 任务简单 |
| CoT | 2~5× | 2~5× | 需要多步推导 |
| ToT | 10×+ | 10×+ | 需要比较方案 |
| ReAct | 取决于轮数 | 取决于轮数 | 任务需要外部信息 |
这张表的用法：从最上面一行试起，每往下走一行，都要有"上一行明确做不到"的证据。这和 1.4 的复杂度阶梯是同一个思路——复杂度必须被证明有必要。
八、动手：一个能让推理真正有用的模板
"请逐步思考"没用。有用的是给它结构。
一个经过验证的推理模板
在回答前，按以下三步写下你的推理：
① 【依据】从材料中找出支持什么结论的原文（引用原句）
② 【推理】从依据到结论的逻辑（不超过 3 步，每步可检验）
③ 【结论】一句话给出答案，并标明置信度（高/中/低）
若依据不足，结论写「依据不足」并把置信度设为低。
规则：
- 第 ② 步中任何一步如果只是"常识推测"，要明确标注「推测」
- 不允许在第 ③ 步引入第 ①② 步没有的信息
为什么这个模板有效
| 结构 | 作用 |
|---|---|
| 依据在前 | 强制先找证据（对抗幻觉，2.3） |
| 推理限制 3 步 | 步数少则每步可检查 |
| 标注"推测" | 让不确定的部分显形 |
| 禁止结论引入新信息 | 防止"结论比依据多" |
| 允许"依据不足" | 给合法退路 |
一个反例对比
差：「请思考后回答这个合同有没有风险」
→ 它会给一段"可能存在的风险"清单，看着专业但没有指向原文
好：「先引用合同原文，再说明为什么这条对买方不利」
→ 每条都能核查
这个模板适用于所有"需要判断"的场景——不只是合同审查。
九、常见误区
误区一：所有任务都加「逐步思考」。
格式转换、信息抽取这类任务加了只会变慢变差。
误区二：推理越长越准确。
超过必要长度的推理会引入噪声，也可能编造约束。
误区三：看到推理过程合理，答案就一定对。
推理可能从第 2 步就错了，后面全是在错误基础上自洽。
误区四：CoT 和 ReAct 是一回事。
不是。CoT 是纯思考；ReAct 是思考+行动+观察的循环，是 Agent 的运行时结构。
误区五：推理过程可以省掉不留。
在 Agent 里，推理过程是重要的诊断依据——出问题时，它是唯一能让你看出"它在想什么"的线索。建议保存在轨迹里（第 10.5 可观测性）。
十、推理长度与准确率的关系
一个常见的直觉是"想得越多越准"。实际不是线性的。
| 推理长度 | 准确率（多步推理任务） |
|---|---|
| 无推理直接答 | 中低 |
| 简短推理（2-5 步） | 最高 |
| 冗长推理（20+ 步） | 回落到中 |
为什么会回落：
| 原因 | 说明 |
|---|---|
| 幻觉累积 | 步数越多，中途编造的概率越大 |
| 注意力稀释 | 关键依据被淹没（5.2） |
| 自我强化 | 前面错了后面顺着错（3.3 已述） |
实践结论：推理要有"够用就好"的边界。
可以在提示词里加：
- 推理步骤不超过 5 步
- 每步只写必要的一句话
- 超过 5 步说明任务该拆分了
最后一句很有用：它把"想不清楚"转化为"任务需要拆分"这个可行动信号。
十一、下一篇
方法层讲完了。现在回到结构层里那个最特殊、也最容易被写坏的部分：系统提示。
它是模型看到的第一个东西，优先级最高，也最容易变成一坨没人敢改的怪物。下一篇讲怎么写，以及它的典型失败模式。