CoT，不只是“让模型一步步思考”

很多人第一次接触 Chain-of-Thought（CoT，思维链），会把它理解成一句提示词：“请一步步思考。” 这句话确实可能有效，但它只说到了表面。真正重要的是：为什么把中间步骤写出来会提高复杂任务的成功率？什么时候会因为推理太长反而更慢、更贵，甚至把错误一路放大？

一句话理解：CoT 是一种推理提示与推理组织方式。它让模型先生成中间步骤，再基于这些步骤形成结论，相当于为复杂问题增加一张可读写的“草稿纸”。

1. 没有 CoT 时，模型为什么容易“跳答案”

大语言模型按 token 逐个生成文本。面对简单事实或很短的任务，它可以直接从输入模式中给出答案；但当问题包含多个条件、先后顺序、隐藏约束或多次计算时，直接输出结论很容易漏掉某一步。

例如，题目同时包含“初始数量、减少数量、后来增加数量”，模型如果没有把中间状态写下来，可能只捕捉到其中两个数字，或者把运算顺序弄反。CoT 的价值就在于把原本容易被压缩掉的过程展开。

需要强调：“草稿纸”是帮助理解的比喻。可见的推理文字不一定等于模型内部真实计算过程，也不应被当作绝对可靠的审计记录。

2. CoT 的核心机制：把复杂问题拆成小问题

标准 Prompt 往往只给输入和输出目标；CoT 则在答案前增加一个中间层：先识别条件，再形成步骤，最后汇总结论。这样做会把一个难以直接预测的长距离问题，改造成多个更局部、更容易匹配和验证的小问题。

• 任务分解：把“一次答对全部”改成“逐步处理一个局部目标”。

• 显式状态：把中间数值、假设和结论写进上下文，后续步骤可以直接复用。

• 模式激活：数学解题、逻辑分析、代码调试等推理文本在训练数据中具有稳定结构，示例能帮助模型复用这种结构。

• 局部校验：每一步都更容易检查，必要时可以调用计算器、搜索、代码执行或规则引擎核验。

3. Zero-shot CoT 与 Few-shot CoT

CoT 最常见的实现形式有两种。Zero-shot CoT 不提供完整示例，只通过“先分步分析，再给结论”一类指令触发推理；Few-shot CoT 则在 Prompt 中给出若干“问题—推理步骤—答案”的完整样例，让模型模仿格式。

Zero-shot CoT：低成本起步

请先完成必要的分析和校验，再输出最终结论。
要求：
1. 识别题目中的已知条件和目标；
2. 按步骤处理存在依赖的部分；
3. 检查关键约束是否满足；
4. 最终只输出结论和简要依据。

它适合快速验证任务是否能从分步推理中获益。优点是 Prompt 短、维护简单；缺点是不同模型对指令的理解和输出稳定性差异较大。

Few-shot CoT：用示例固定思路与格式

示例：
问题：仓库有 10 箱货，运走 3 箱，又到货 5 箱。现在有多少箱？
分析：先计算运走后的数量 10-3=7，再加上到货 5，得到 12。
答案：12 箱。
新问题：{用户问题}
请沿用相同的分析方式和输出格式。

Few-shot CoT 更适合规则固定、需要稳定格式的业务，例如财务校验、故障排查、规则计算和标准化评审。但示例会占用上下文，也需要定期维护，避免示例本身存在错误或过时。

4. Self-Consistency：不要只相信第一条推理链

基础 CoT 通常只生成一条路径。如果这条路径早期出现错误，后续步骤很可能沿着错误前提继续推导。Self-Consistency 的做法是：对同一个问题采样多条不同推理路径，再根据最终答案进行多数投票。

它的直觉很简单：正确答案往往可以通过多种合理路径得到，而随机错误不一定会反复收敛到同一个结果。原始研究在多项算术和常识推理基准上观察到明显提升，但它的代价也很直接——调用次数、输出 token、整体延迟和费用都会增加。

工程建议：先在离线测试集上比较 1 次、3 次、5 次采样的收益曲线。不要默认采样越多越好；当准确率提升趋于平缓时，应停止增加调用。

5. 从一条链到多条路：Tree of Thoughts

CoT 是一条从头走到尾的路径。一旦早期方向选错，通常只能继续往下写。Tree of Thoughts（ToT）把中间“思路”组织成树：模型生成多个候选，评估哪些值得继续，必要时回退，再探索其他分支。

ToT 更适合需要规划、搜索和试错的问题，例如 24 点、复杂排程、创意方案搜索和多步骤决策。但它比普通 CoT 更重，需要额外的候选生成、评分与搜索控制，生产系统必须设置最大深度、分支数和超时。

6. ReAct：推理不能只在语言里打转

当问题依赖外部事实、实时数据或精确计算时，仅靠模型内部记忆继续写 CoT 可能产生幻觉。ReAct 把“思考”和“行动”交替起来：先判断下一步需要什么信息，再调用搜索、知识库、数据库或工具，读取结果后更新计划。

• 思考：确定当前缺少什么信息，以及下一步要验证什么。

• 行动：调用检索、计算器、代码执行、业务 API 或数据库。

• 观察：读取真实返回结果，而不是继续凭语言补全。

• 更新：根据新证据修正假设、计划和最终答案。

这类结构是很多 Agent 系统的基础。它的重点不是输出一篇更长的“思考作文”，而是把关键不确定性转换成可执行、可验证的动作。

7. CoT 的四个主要局限

局限一：token、费用与延迟都会上升

推理链越长，输出 token 越多；多路径策略还会把一次调用变成多次调用。对于客服闲聊、简单分类、字段提取等任务，启用长 CoT 往往只会拖慢系统。

局限二：错误会累积传导

CoT 能减少“直接跳答案”的错误，但不能保证每一步正确。解决办法不是单纯要求模型“再认真一点”，而是把关键步骤变成可核验的结构：算术交给计算器，事实交给检索，规则交给确定性代码。

局限三：可见推理不一定忠实

研究发现，不同模型、不同任务中，可见 CoT 对最终答案的影响程度差异很大。有时模型确实依赖中间链条，有时它可能先形成答案，再生成一段听起来合理的解释。因此，在审计、合规和高风险决策中，不能只因为“理由写得很完整”就认为结论可信。

局限四：简单问题会被过度推理

“1+1 等于几”“把这段话分类为正面或负面”“从文本中提取手机号”都不需要长推理。让模型展开几十步分析，不但没有收益，还可能引入无关细节和新的错误。

8. 哪些场景适合 CoT，哪些场景应直接回答

判断标准不是问题看起来“长不长”，而是：答案是否依赖多个连续步骤？中间状态是否能被验证？如果任务本质是查事实、做分类、提字段，就没有必要开启长推理。

高风险任务要特别处理：医疗、法律、金融、风控等场景，即使使用 CoT，也必须结合权威数据、规则校验、工具结果和人工复核。模型的文字推理不能替代专业责任。

9. 生产环境如何落地：动态路由 + 工具核验 + 简洁输出

真正可用的系统通常不会对所有请求统一加一句“请一步步思考”。更合理的做法是先判断任务复杂度，再选择不同策略：

• 简单任务：直接回答，限制输出长度。

• 普通多步任务：启用基础 CoT，并要求检查关键约束。

• 高价值推理任务：使用多路径、自我一致性或验证器。

• 依赖外部事实：使用 ReAct，调用搜索、知识库或业务工具。

• 高风险任务：输出结论前增加规则校验和人工确认。

推荐的输出契约

最终答复请使用以下结构：
结论：一句话说明结果。
关键依据：列出 2～4 条可核查依据。
不确定性：说明缺失数据或仍需验证的部分。
下一步：给出可执行的核查或处理建议。

这类输出方式既保留推理带来的质量提升，又避免向用户展示冗长、不稳定或包含敏感信息的完整思考链。

10. 如何评测 CoT：不要只看最终准确率

一个策略即使让准确率提高 2%，也可能把费用和延迟提高 5 倍。上线前应建立固定测试集，对比直接回答、基础 CoT、Self-Consistency 等方案。

• 最终准确率：答案是否正确，关键约束是否满足。

• 路径稳定性：相同输入多次运行，结论是否一致。

• 成本：平均输入和输出 token、工具调用次数、缓存命中率。

• 延迟：平均延迟、P95 延迟、超时比例。

• 核验能力：关键计算和事实是否经过工具验证。

• 错误可定位性：失败后能否判断是检索错、工具错、步骤错还是最终汇总错。

11. 上线前检查清单

最实用的原则：复杂问题才启用推理；关键步骤尽量使用工具核验；面向用户只提供结论、关键依据和可检查信息。

总结：CoT 是推理工具，不是正确答案保证书

CoT 的价值，在于把复杂问题的中间状态显式化，让模型可以分解任务、复用前文并逐步检查。Zero-shot CoT 适合快速起步，Few-shot CoT 适合固定任务；Self-Consistency 用多路径投票提升稳定性，ToT 适合搜索和规划，ReAct 则把推理与外部工具连接起来。

但 CoT 同样会增加 token、延迟和费用，中间步骤可能出错，可见文字也不一定忠实反映模型真实计算。工程上最重要的不是“让模型写得更长”，而是：正确路由任务、验证关键步骤、限制成本，并让最终输出保持简洁、可核查。