CoT 深度：从 Zero-shot 到 Tree-of-Thought

flowchart LR
  A["CoT 深度：从 Zero-shot 到 Tree-of-Thought"]
  A --> B["分类：基础概念"]
  A --> C["关键词：AI"]
  A --> D["关键词：CoT"]
  A --> E["关键词：推理"]
  A --> F["关键词：Tree-of-Thought"]

模型不会因为你喊「加油」就变聪明，但会因为你喊「一步一步想」而假装变聪明——而很多时候，假装就够了。

这篇文章会讲什么

你已经会用「请分步推理」这类 Prompt，但 CoT（Chain-of-Thought，思维链）远不止一句咒语：它经历了从提示技巧到训练范式的完整进化，还衍生出树搜索、图结构、过程奖励与蒸馏等一整条技术线。

读完本文，你能把 Zero-shot / Few-shot / 结构化 / ToT / GoT / 推理模型 放在同一张地图里，知道什么时候该用哪种、成本大概涨多少、以及 2026 年仍要警惕哪些反直觉坑。若你刚读完 Context Engineering，本篇正好回答：编排好上下文之后，推理过程本身该如何设计。

先说结论：CoT 是推理脚手架，不是“更长就更聪明”

关于 CoT，最常见的两个误解分别是：

只要让模型“想久一点”，答案就一定更好；
只要把推理过程打印出来，我们就更知道它为什么答对。

这两个判断都不稳。CoT 的真实价值是：

在需要多步拆解的问题上，给模型一个更稳定的中间推理路径；
在需要检查过程的问题上，把部分中间态外显出来，便于验证；
在训练阶段，把“过程正确”也纳入优化目标。

但它也有明确代价：

token 变多
延迟变长
简单任务上可能反而更啰嗦、更易幻觉
外显的推理文本不一定忠实反映内部决策

所以更成熟的理解不是“CoT = 让模型多想想”，而是：

CoT = 在合适的问题上，为模型搭一段可控的推理脚手架。

脚手架搭对了，模型更稳；搭错了，只会让系统更慢、更贵、更自信地错。

1. CoT 进化史：从 prompt trick 到训练范式

先看定义：CoT 几年内从「写在提示里的脚手架」变成了「刻在权重里的默认行为」。

时间线速览

时期	里程碑	意味着什么
2022	Wei et al. 提出 Chain-of-Thought prompting	多步算术、常识推理可用示例推理链撬动
2023	Zero-shot CoT：「Let’s think step by step」	不写示例也能触发中间推理（Kojima 等）
2023–2024	Tree-of-Thought、Graph-of-Thought	线性链条 → 分支搜索 / 图上的合并与回溯
2024–2025	推理内化：o1、o3、DeepSeek-R1、PRM	训练阶段学「先想再答」，甚至开源推理链
2026	CoT 成为事实上的标配	产品侧默认长思考；研究侧转向何时有害与忠实度

认知升级：三个阶段

[ 阶段 A：提示工程 ]     Few-shot 示例里夹带推理步骤
        ↓
[ 阶段 B：零样本触发 ]   一句指令激活「分步」行为
        ↓
[ 阶段 C：训练内化 ]     RL / 蒸馏 / PRM 把「过程」写进模型能力

为什么是「进化」而不是换名字

早期 CoT 是外挂在 prompt 上的格式：模型本来就会生成 token，你只是诱导它把中间态写出来。到了推理模型阶段，目标函数开始显式偏好「能导向正确答案的过程」——过程从可读文本，扩展到内部状态与奖励信号。对外仍可能展示链式文本，也可能只展示摘要；但优化对象已经变了。

小结：从 trick 到范式，分界线在于：推理过程是否进入训练信号，而不在于最终用户是否看见每一步。

2. Zero-shot CoT vs Few-shot CoT

先看定义：Zero-shot 靠一句触发语省示例；Few-shot 用完整「题解」做示范——前者便宜、后者稳。

Zero-shot CoT

做法：在问题后追加一句，例如 Let’s think step by step（英文任务）或明确的中文指令「请逐步推理」。
特点：无需构造示例，token 成本最低，适合快速 A/B 与线上灰度。
细节：同一指令放在问题前还是问题后、用英文还是中文，对不同模型可能有细微差异——值得用评测集做一次网格搜索，而不是抄一句就上线。

Few-shot CoT

做法：在上下文里放若干 (问题 → 逐步推理 → 答案) 的完整演示。
特点：对题型对齐要求高（示例与目标任务越像越好），但通常比零样本更稳，尤其在中小模型上。
细节：示例里的推理风格会「传染」：若示例啰嗦，模型往往更啰嗦；若示例跳步，模型也可能学会跳步——示例即产品文档。

对比表

维度	Zero-shot CoT	Few-shot CoT
效果	大模型上常显著增益；小模型波动大	示例质量好时通常更强、更可复现
成本	极低（+一句）	高（多段示例占用 context）
适用	通用推理、快速试验、多语言混合	固定题型（考试、表格推理、领域格式）
风险	易「空泛分步」不落地	示例错误会级联污染

经典数据：GSM8K 上的量级跃迁

小学数学文字题基准 GSM8K 常被用来展示 CoT 的威力：在代表性设置下，标准提示与加入 CoT（含 zero-shot 触发或 few-shot 链）之间的准确率差距，文献与复现中常出现约 18% → 58% 量级的提升（具体数字随模型规模、解码温度、是否用工具而波动）。请把这两个数字理解成**「从几乎不可用 → 可以认真谈产品」**的信号，而不是刻舟求剑的绝对值。

3. Structured CoT：给推理加「模板」

先看定义：把「随便想」改成「按栏目填表」，降低跑偏与跳步。

固定步骤格式

通用骨架可写成四段，便于模型自检与人工抽查：

1. 识别：题目在问什么？已知/未知？
2. 分析：可用公式、约束、边界条件？
3. 推导：按步计算，每步一句依据
4. 结论：答案 + 单位 + 是否验算

适合特定领域的定制 CoT 模板

领域模板的关键不是「更华丽」，而是把不可省略的审查点写死。下面三张表可直接改成 System Prompt 或用户侧表单的栏目说明。

场景	结构化栏目（示例）
法律分析	争点归纳 → 要件检视 → 判例/条文引用 → 风险与不确定性
代码 Review	变更意图 → 正确性 → 性能与安全 → 风格与可测性 → 建议优先级
数据分析	数据口径 → 假设 → 图表/统计量 → 因果边界 → 可行动结论

示例段落：法律分析 Structured CoT（缩略）

【争点】用户主张合同解除是否成立？
【要件】约定解除条件 / 法定解除事由是否满足？
【依据】条文与类案摘要（若有检索工具则注明来源）
【风险】事实未清之处、举证责任、程序风险
【结论】倾向性意见 + 需补充材料清单

小结：结构化 CoT 的本质是 把「可检查性」设计进输出格式——对合规、审计、教学场景尤其友好；代价是输出更长，需在 UI 上做折叠与分段展示，并在 Context Engineering 层面预留 token budget。

4. Tree-of-Thought (ToT)：推理的分支搜索

先看定义：不再押一条直线，而是生成多条中间思路，评估再剪枝，像粗粒度的思维树搜索。

原理

分支：对同一子问题生成多条候选「下一步」。
评估：用模型自评、启发式或投票给每条边打分。
回溯/扩展：保留高分路径，继续展开或回到上层换路。
输出：在叶节点或满足停止条件时汇总最优答案。

与线性 CoT 的对比（ASCII）

线性 CoT（一条道走到黑）：

Q ──► s1 ──► s2 ──► s3 ──► A

Tree-of-Thought（同一层可多选，可回头）：

              ┌─► s2a ──► ...
        ┌─► s1┼─► s2b ──► ...
Q ──────┤       └─► (剪枝)
        └─► s1' ──► ...

适用：复杂规划、博弈、需要回溯的问题

适合	不适合
复杂规划、谜题、博弈类多步决策	简单事实问答、短文本分类
需要显式探索与可解释分支	延迟敏感、极低成本场景
「第一步选错后面全错」的任务	已有闭式算法可替代时（应直接调用代码）

局限：成本是线性 CoT 的 N 倍

调用次数与候选数近似相乘，成本常为线性 CoT 的 N 倍（N = 分支因子 × 深度 × 评估次数）。工程上必须：

限制分支宽度与最大深度；
对重复子问题做缓存（memoization）；
评估用轻量打分（如小模型或规则）而非每次都上最强模型。

5. Graph-of-Thought (GoT)：推理的图结构

先看定义：ToT 是「树」，GoT 是「图」——允许合并、聚合、循环，表达力更强，系统更复杂。

允许推理步骤间的合并、分裂、循环

树结构强制每个中间节点只有一个父节点；现实任务里常出现：

合并：两条独立推理路径得到同一中间结论，应汇合而非复制两份。
分裂：一个结论需要拆到多个并行子任务再汇总。
循环：发现错误后回到某节点重写（refinement），而不是永远向下生长。

用 ASCII 表示「合并」与「迭代」：

   path A ──┐
            ├──► 合并节点 M ──► 下游
   path B ──┘

   草稿 C0 ──► 批评/打分 ──► 修订 C1 ──► …（允许回到 C0）

比 ToT 更灵活但更复杂

特性	ToT	GoT（典型设想）
拓扑	树（单父节点）	图（多对多、可汇合）
操作	扩展、剪枝	+ 合并不同路径的结论、精炼节点
典型收益	分支探索	多源信息融合、迭代精炼
典型代价	高 API 成本	更高编排与状态管理复杂度

研究状态和实用性

研究侧：GoT 类工作证明「图上的推理步骤」对需要综合多子结论的任务有表达优势；论文与原型多，统一框架与最佳实践仍在演化。
产品侧（2026）：多数落地仍选 线性 CoT + 少量重试/投票 或 ToT 的简化版；全功能 GoT 更像研究管线或高价值分析场景选项，需自研 orchestration、状态存储与可视化。

一句话收束：除非你的问题天然是「多源 DAG」或要强合并，否则优先把线性 CoT 做稳，再评估 ToT/GoT 是否值得吞成本。

6. CoT 在训练中的内化：Reasoning Models

先看定义：当「推理过程」进入损失函数与奖励，CoT 就从提示词变成了模型能力。

o1 / o3：训练时学会「先想再答」

直觉：在训练（含 RL 类信号）中鼓励长程、有依据的推导，推理时分配更多「思考预算」。
用户体验：最终答案前常有一段不可见或简化的推理；产品强调可靠性与难题，而非纯 token 单价。
与提示 CoT 的关系：提示 CoT 仍可用于格式约束或轻量任务；难题更多依赖内化策略而非仅靠一句「step by step」。

DeepSeek-R1：开源推理链的代表路径

意义：展示开源权重 + 可观测推理风格的路径，便于二次训练与本地化部署。
工程注意：蒸馏与微调时要防止过拟合表面格式而没学到真实推理；评测应同时看最终准确率与过程是否合理。

Process Reward Models：按步骤打分

做什么：对每一步（而非仅最终答案）打分，训练「过程好」的策略；经典讨论见 Let’s Verify Step by Step 等文献（见延伸阅读）。
价值：减轻「答案蒙对、过程胡写」；与 Outcome RM 常组合使用。
坑：步骤边界如何切分、错误步骤是否局部可修正，都会影响 PRM 的信噪比。

CoT Distillation：大模型的 CoT 蒸馏给小模型

做什么：用大模型生成的高质量推理链监督小模型，让小模型学会分步样式与中间技巧。
收益：小模型在特定任务上可接近「大模型 + 长 prompt」的体验。
风险：容量不足时学会冗长套话而非可靠推理——需课程学习、难例筛选与工具兜底。

一个 2026 年很重要的现实：不是所有模型都鼓励“完整外显思维链”

前沿模型越来越多地把详细推理留在内部思考里，对外只给简化解释、关键依据或结构化结论。这背后有三个现实原因：

安全与滥用：完整过程可能暴露不必要的策略细节；
忠实度问题：外显文字不一定等于真实内部推理；
产品体验：用户通常想要的是可靠结论，不是几百行“自言自语”。

所以在产品里，常见的更优做法不是强求“把每一步都打印出来”，而是：

对用户展示简短理由摘要；
对系统内部保留验证用的结构化中间态；
对可计算问题直接调用工具或代码执行，而不是让模型硬写长篇 CoT。

7. CoT 的反直觉发现

先看定义：CoT 不是免费午餐——简单题、小模型、忠实度与边界研究都在泼冷水。

CoT 对简单任务可能有害（增加 hallucination）

部分研究显示：在不需要多步的任务上强行走 CoT，可能增加 hallucination（编造中间事实）或拉长错误路径。
实践：用路由策略——分类器或轻量规则判断「是否需要分步」，再决定是否启用 CoT；对确定性计算优先 code interpreter。

小模型的 CoT 效果不稳定

原因：参数不足以支撑可靠「自我监督式」中间符号操作；示例噪声伤害更大。
实践：更短的结构化模板、更强约束的 JSON 输出、或直接用工具做确定性计算；避免盲目堆 few-shot 长链。

「Thinking」tokens 的 faithfulness 问题

模型打印出来的推理未必等于真实内部计算；可能存在 事后合理化（confabulation）。
含义：不要用 CoT 文本做安全关键证明；审计场景要交叉验证（代码执行、检索、规则引擎）。
2026 仍开放：更严格的「过程—结论」一致性评测与干预方法在快速迭代。

2026 研究：CoT 的局限边界在哪里

研究热点包括：何时该禁用 CoT、过程奖励与结果奖励的最优混合、忠实度评测协议、以及多模态 CoT（图、表、代码混排）的可扩展性。行业侧则更关心：在固定延迟与成本下，哪类任务值得上 ToT/投票/PRM——本质是边际收益曲线问题，而非「越复杂越好」。

工具优先，还是 CoT 优先？

先看定义：只要问题能被确定性工具解决，通常先上工具；CoT 更适合“需要拆解但无法直接程序化”的部分。

问题类型	更优先的手段	原因
大数计算、单位换算、SQL 聚合	工具 / 代码执行	确定性强，语言推理易错
多步数学文字题	CoT + 验算工具	先拆解，再用工具兜底
法务/策略分析	Structured CoT + 检索	需要解释过程与依据
复杂规划	ToT / 受限搜索	第一条路径未必最优

工程上最常见的坏味道，是让模型先写一大段 CoT，最后再去调工具“确认一下”。顺序更稳的做法往往是：先判断问题能否程序化验证，再决定需要多深的语言推理。

8. 实战指南：何时用哪种 CoT

先看定义：先问「任务是否需要多步 + 是否承担得起 token」，再选最便宜的够用方案。

决策表：任务类型 → 推荐 CoT 变体

任务类型	首选	备选	备注
通用数学题、逻辑题	Zero-shot CoT 或短结构化	Few-shot（题型固定时）	验算/工具兜底
固定格式业务（审批、法务初稿）	Structured CoT	Few-shot + 模板	强可检查性
复杂规划、谜题、博弈	ToT（限分支）	多采样 + 投票	严控宽度/深度
多源信息综合、迭代精炼	GoT 或分块线性 CoT + 汇总	ToT	全 GoT 成本高
低延迟简单问答	不用 CoT	直接答	减少幻觉路径
可程序化验证的问题	工具优先	CoT 只做解释层	不要拿语言模拟计算器
教小模型推理	CoT 蒸馏 + 课程学习	PRM 辅助	防套话

成本-收益分析（心智模型）

收益 ≈ 任务「可分解度」 × 模型能力 − 冗长带来的错误面
成本 ≈ (prompt 长度 + 生成步数 + 分支数 × 评估) × 单价

策略	预期成本	预期收益峰值场景
Zero-shot CoT	最低	大模型、通用推理
Few-shot CoT	中（示例长）	题型固定、要可复现
Structured CoT	中–高（输出长）	合规、审计、交付物
ToT	高	易走错第一步的规划题
GoT	很高	多源合并、迭代精炼

实操建议：从 Zero-shot → 结构化 → Few-shot 逐级加成本；仅当线性路径反复失败时，再引入 ToT 的窄搜索；GoT 留给真正需要合并多子图的问题。上线前用同一批 hold-out对比「无 CoT / 线性 / ToT」，用数据说话而不是信仰。

核心概念速查

概念	一句话
Chain-of-Thought (CoT)	让模型输出中间推理步骤以提升多步任务表现
Zero-shot CoT	不加示例，仅用语句（如逐步思考）触发分步行为
Few-shot CoT	用带推理链的示例教会题型与格式
Structured CoT	用固定栏目/模板约束推理过程，便于检查与落地
Tree-of-Thought (ToT)	多路径生成与评估，分支搜索式推理
Graph-of-Thought (GoT)	推理步骤构成图，支持合并、循环等更 rich 拓扑
PRM	对推理步骤打分的过程奖励模型
CoT Distillation	用大模型推理链教小模型模仿推理样式与步骤
Faithfulness	模型声称的推理是否真实反映其决策依据（常存疑）

写于 2026：CoT 已是默认能力，选型比「会不会写 Let’s think step by step」更重要——省 token、控分支、验忠实。