CoT 是近几年大模型"变聪明"最核心的底层机制之一，是 Self-Consistency、Tree of Thoughts、Graph of Thoughts、ReAct、Agent 的共同基石。
这篇文章我们就把 CoT 彻底拆开：
- 它为什么有效？背后的直觉和论文是什么？
- 它有哪几类？怎么用？
- 它的进化版------Self-Consistency、ToT、GoT、ReAct 又是怎么一步步长出来的？
- 我们用 Python + 真实案例，手写一个可运行的 CoT 推理器。
目录
- 一、先从一个"翻车案例"说起
- 二、CoT 是什么：一句话定义 + 学术起源
- 三、为什么 CoT 有效？三层直觉解释
- 四、CoT 的三大流派
- 五、CoT 的进化家族树
- 六、实战：手写一个可运行的 CoT 推理器
- 七、三个真实案例：数学题 / 复杂 SQL / 代码 Bug 定位
- 八、CoT 的适用边界与常见坑位
- 九、工程化：CoT 在生产环境如何落地
- 十、总结
一、先从一个"翻车案例"说起
让我们用一道小学三年级应用题热热身：
题目：食堂有 23 个苹果。如果他们用了 20 个做午饭，又买了 6 个，现在有多少个苹果？
正确答案：23 - 20 + 6 = 9。
你把这个题目丢给 GPT-3 （2022 年 CoT 论文发表前的版本），它的回答可能是：
答案是 27。嗯？ 27 怎么来的？模型其实没"算"，它是根据"23、20、6"这三个数字的某种联想直接蒙了一个。
现在我们在 Prompt 末尾加一句魔法咒语：
arduino
Let's think step by step.
（让我们一步一步思考）同一个模型的输出就变成了：
ini
食堂原来有 23 个苹果。
他们用了 20 个做午饭，所以还剩 23 - 20 = 3 个。
然后又买了 6 个，所以现在有 3 + 6 = 9 个。
答案是 9。模型没变，参数没变，只是多了一句咒语，正确率从"蒙"变成了"对"。
这就是 CoT 的魔力。而这一句看似平淡的 Let's think step by step，是 Google DeepMind & 东京大学 2022 年那篇论文里最经典的发现。
二、CoT 是什么：一句话定义 + 学术起源
2.1 一句话定义
思维链（Chain of Thought, CoT）是一种引导大模型在给出最终答案之前，先显式输出中间推理步骤的 Prompt 技巧。
关键词是 "显式输出中间步骤"------让模型"想出声"，而不是"闷头蒙一个答案"。
2.2 学术起源（两篇必读的里程碑论文）
| 时间 | 论文 | 核心贡献 | 通俗理解 |
|---|---|---|---|
| 2022.01 | Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（Wei et al., Google） | 提出 Few-shot CoT：给模型几个"带推理过程的示例"，它会模仿着先推理再回答 | 手把手教几遍，它学会了 |
| 2022.05 | Large Language Models are Zero-Shot Reasoners（Kojima et al.） | 发现 Zero-shot CoT ：不用示例，一句 Let's think step by step 就能激活推理 |
一句咒语就够 |
从此，CoT 从"trick"变成了大模型应用的标配方法论。
2.3 一张图看懂 CoT 做了什么
┌────────────────────────┐ ┌────────────────────────┐
│ 直接问答（No CoT） │ │ CoT 推理 │
├────────────────────────┤ ├────────────────────────┤
│ │ │ │
│ 问题 ──▶ 模型 ──▶ 答案│ │ 问题 ──▶ 模型 │
│ │ │ │ │
│ （一步到位，易出错） │ │ ▼ │
│ │ │ 推理步骤 1 │
│ │ │ ▼ │
│ │ │ 推理步骤 2 │
│ │ │ ▼ │
│ │ │ 推理步骤 N │
│ │ │ ▼ │
│ │ │ 最终答案 │
└────────────────────────┘ └────────────────────────┘三、为什么 CoT 有效？三层直觉解释
3.1 第一层（直觉）：给模型"算草稿"的空间
回想一下你做应用题的经历：
- 不让打草稿 ：光用脑子算
23 - 20 + 6，容易算错 - 允许打草稿：一步一步写下来，几乎不会错
大模型面临同样的问题。每次生成一个 Token，它的"算力"都是有限的。让它一次性蹦出答案，相当于逼它在脑子里算；让它先写出推理过程，相当于给了它一张演草纸。
3.2 第二层（机制）：把计算分散到更多 Token 上
模型是一个"超级联想接龙"机器，一次预测一个 Token，基于之前所有 Token 的概率分布。
这意味着：
- 直接答：模型只有 1 个 Token 的"思考空间"
- 先推理再答 ：模型有 几十到几百个 Token 的思考空间，而且每个后续 Token 都能"看到"之前的推理，基于它继续推
你可以把模型想象成一个**"只能靠前面说过的话来决定后面说什么"的人**------让他多说几句中间思考，他后面说出的答案就会更严谨。
3.3 第三层（数学/训练机制）：激活训练语料中的"推理路径"
大模型训练语料里，有大量这样的文本：
erlang
问题：...
解题过程：
第一步，...
第二步，...
因此，答案是 ...数学题解、编程教程、学术论文------到处都是这种结构。
当你在 Prompt 里加入"一步一步思考"时，等于触发了模型在训练语料中学到的"推理模式"，它会自动切换到"解题答辩腔"而不是"聊天腔"。
这也解释了为什么 CoT 对小模型几乎无效 ------小模型的训练语料和参数量不足以学到复杂的推理模式。业内的共识是：CoT 的收益随模型规模呈"涌现（Emergent）"关系，通常在 ~62B 参数以上才显著起效。
四、CoT 的三大流派
按"你要给模型多少指导"排序，CoT 有三种用法：
4.1 Zero-shot CoT：最简单的魔法咒语
不给任何示例，只加一句话。
text
问题：食堂有 23 个苹果，用了 20 个做午饭，又买了 6 个，现在有多少个？
请一步一步思考。咒语变体（都有效）：
Let's think step by step.让我们一步一步思考。请先分析问题，再给出答案。Before giving the final answer, work through the problem step by step.请先写出推理过程（Reasoning），再写出最终答案（Answer）。
✅ 优点 ：零成本、万能、改一行就上线 ❌ 缺点：推理风格不可控，输出长度不稳定
4.2 Few-shot CoT：给模型几个"带推理"的示例
给 2~8 个示范，模型会严格模仿其结构。
text
问题：停车场有 3 辆车，又开进来 2 辆。现在有几辆？
推理：停车场原来有 3 辆车。又开进来 2 辆，所以现在有 3 + 2 = 5 辆。
答案：5
问题：Leah 有 32 块巧克力，她姐姐有 42 块。她们一共吃了 35 块后还剩多少？
推理：两人一共有 32 + 42 = 74 块巧克力。吃了 35 块，剩 74 - 35 = 39 块。
答案：39
问题：食堂有 23 个苹果，用了 20 个做午饭，又买了 6 个，现在有多少？
推理：模型看到前面的推理格式，会乖乖按 "推理：... 答案：..." 的模式续写。
✅ 优点 ：推理格式严格可控，适合批量任务 ❌ 缺点：占 Token 贵；示例写错了会带歪模型
4.3 Auto-CoT：让模型自己给自己造示例
流程是：
- 对大量问题先用 Zero-shot CoT 生成推理链
- 通过聚类选出"有代表性 & 质量较好"的若干条
- 把这些自动生成的示例，拼接成 Few-shot CoT 的示例池
适合你有一个大题库、想自动化批量优化 Prompt 的场景。
4.4 三者对比
| 流派 | 是否需要人工示例 | Token 成本 | 可控性 | 适用场景 |
|---|---|---|---|---|
| Zero-shot CoT | ❌ 不需要 | 🟢 最低 | 🟡 中 | 快速验证、通用任务 |
| Few-shot CoT | ✅ 需要 2~8 个 | 🔴 高 | 🟢 高 | 推理格式严格、批量任务 |
| Auto-CoT | ⚪ 半自动 | 🟡 中 | 🟢 高 | 有题库、需自动化优化 |
五、CoT 的进化家族树
CoT 开启了"让模型会思考"的方向，之后一连串进化版工作爆发。了解这张家族树，你就能看懂绝大多数 Agent 论文。
scss
┌────────────────┐
│ Chain of │
│ Thought (CoT)│
└────────┬───────┘
│
┌──────────────────────┼────────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌────────────────┐ ┌────────────────┐
│ Self- │ │ Least-to-Most │ │ Tree of │
│ Consistency │ │ Prompting │ │ Thoughts (ToT)│
│ (多采样投票) │ │ (先拆再推) │ │ (推理树搜索) │
└───────┬───────┘ └────────────────┘ └────────┬───────┘
│ │
└─────────────────┐ ┌──────────────────┘
▼ ▼
┌────────────────────┐ ┌───────────────────┐
│ Graph of Thoughts │ │ ReAct │
│ (推理图，可回环) │ │ (思考+行动+观察循环)│
└────────────────────┘ └───────────────────┘
│
▼
┌──────────────────┐
│ Agent / AutoGPT │
│ (全自动闭环) │
└──────────────────┘下面一个一个说清楚。
5.1 Self-Consistency（自一致性）：多采样投票
核心思想 ：同一个问题跑 N 次 CoT，取出现次数最多的答案（多数投票）。
为什么有效？推理链是随机的（temperature > 0 时每次不一样），但正确答案往往只有一个，错误答案千奇百怪。所以多跑几次投票，正确答案会"脱颖而出"。
python
from collections import Counter
def self_consistency(question: str, n: int = 5) -> str:
chains = [llm(question + "\n请一步一步思考。", temperature=0.8)
for _ in range(n)]
answers = [extract_answer(c) for c in chains] # 从每条链里抽取最终答案
return Counter(answers).most_common(1)[0][0]代价 ：N 倍 Token 成本。适用：数学、逻辑、分类这类"答案离散且可比较"的任务。
5.2 Least-to-Most（从易到难）：先拆解再求解
核心思想 ：让模型先把大问题拆成一系列小子问题，然后依次解决，每一步答案作为下一步输入。
两阶段 Prompt 范式：
text
# 阶段 1：分解
原问题：一列火车从 A 到 B 共 600 公里，前 2 小时速度 100 公里/时，
之后减速为 80 公里/时，问总共需要多少小时？
请不要直接回答，先把这个问题分解成更简单的子问题。模型输出：
text
子问题 1：前 2 小时走了多少公里？
子问题 2：剩余路程是多少？
子问题 3：剩余路程按 80 公里/时，还需要几小时？
子问题 4：总时间 = 2 + 子问题 3 的答案。
text
# 阶段 2：逐个求解（每次把上一题的答案带入下一题）适合结构清晰但步骤多的复杂题------比 Zero-shot CoT 稳定得多。
5.3 Tree of Thoughts（ToT）：推理不是链，是树
核心思想 ：CoT 是一条线，但很多问题其实可以走不同路径 。Tree of Thoughts 让模型在每一步生成多个候选思路 ，然后像下棋一样搜索+剪枝，选出最优路径。
经典场景：24 点游戏（给 4 个数字，用加减乘除凑出 24）。
ini
[ 4, 9, 10, 13 ]
/ | \
4+9=13 9-4=5 13-9=4
[13,10,13] [5,10,13] [4,10,13]
/ \
10+13=23 ...
[13,23]
...- 每一步生成多个中间状态（分支）
- 用模型自己评估"这个分支还有希望吗"（启发式评估）
- 无希望的剪枝，有希望的继续展开
ToT 把 LLM 从"一条道走到黑"变成了"会回溯、会选路"的推理引擎，但实现复杂度高、Token 成本高，通常只在高价值任务（代码搜索、数学证明）里用。
5.4 Graph of Thoughts（GoT）：思路可回环、可合并
核心思想：ToT 是树（不能回头），GoT 是图（可以复用、合并中间结论）。
比如做一篇文章摘要：
- 先让模型分别提炼 3 段的摘要（3 个节点）
- 再让模型对比它们，合并成一个整体摘要（合并节点）
- 再让模型根据整体摘要，反过来修订每一段的摘要（回环）
GoT 更贴近人类真实的思考过程------思路会跳跃、合并、推翻重来。 适合写作、复杂决策等非线性任务。
5.5 ReAct（Reasoning + Acting）：思考 + 行动 + 观察 循环
核心思想 ：CoT 只让模型"在脑子里想"，ReAct 允许模型调用外部工具（搜索、计算器、API、数据库），把"观察结果"拼接回推理链。
yaml
Thought 1: 我需要知道 2026 年北京奥运会开幕的准确日期
Action 1: search("2026 北京冬奥会 开幕日期")
Observation 1: 2026 年冬奥会在米兰-科尔蒂纳举办，不在北京
Thought 2: 上面搜索有误，重新确认
Action 2: search("2022 北京冬奥会 开幕式 日期")
Observation 2: 2022 年 2 月 4 日
Thought 3: 用户问的是哪次？我需要再确认...
Answer: 2022 年北京冬奥会开幕式为 2022 年 2 月 4 日这就是现代 AI Agent 的骨架------LangChain、AutoGPT、OpenAI Function Calling + Tools 本质上都是 ReAct 的工程实现。
六、实战：手写一个可运行的 CoT 推理器
光看理论不够，我们来撸代码。下面这个 Python 类封装了 Zero-shot CoT / Few-shot CoT / Self-Consistency 三种模式。
6.1 基础客户端
python
# pip install openai
from openai import OpenAI
from collections import Counter
from typing import Optional
import re
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", # 百炼示例
)
def llm(prompt: str, system: str = "你是一位严谨的推理助手。",
temperature: float = 0.0) -> str:
resp = client.chat.completions.create(
model="qwen-plus",
messages=[
{"role": "system", "content": system},
{"role": "user", "content": prompt},
],
temperature=temperature,
)
return resp.choices[0].message.content6.2 CoT 推理器封装
python
class CoTReasoner:
"""思维链推理器，支持 Zero-shot / Few-shot / Self-Consistency。"""
ZERO_SHOT_SUFFIX = (
"\n\n请严格按以下格式输出：\n"
"推理过程：\n<一步一步的推理>\n"
"最终答案：<一句话的简洁答案>"
)
def __init__(self, temperature: float = 0.0):
self.temperature = temperature
# ---------- 1. Zero-shot CoT ----------
def zero_shot(self, question: str) -> dict:
prompt = f"问题：{question}{self.ZERO_SHOT_SUFFIX}"
raw = llm(prompt, temperature=self.temperature)
return self._parse(raw)
# ---------- 2. Few-shot CoT ----------
def few_shot(self, question: str, examples: list[dict]) -> dict:
demo = "\n\n".join(
f"问题：{ex['q']}\n推理过程：\n{ex['r']}\n最终答案：{ex['a']}"
for ex in examples
)
prompt = f"{demo}\n\n问题：{question}\n推理过程：\n"
raw = llm(prompt, temperature=self.temperature)
return self._parse(raw)
# ---------- 3. Self-Consistency ----------
def self_consistency(self, question: str, n: int = 5) -> dict:
results = []
for _ in range(n):
prompt = f"问题：{question}{self.ZERO_SHOT_SUFFIX}"
raw = llm(prompt, temperature=0.8) # 必须打高温才有多样性
results.append(self._parse(raw))
answers = [r["answer"] for r in results if r["answer"]]
if not answers:
return {"answer": None, "reasoning": "所有采样都未能解析"}
best = Counter(answers).most_common(1)[0][0]
# 选择一条命中 best 答案的推理过程作为代表
best_reasoning = next(r["reasoning"] for r in results
if r["answer"] == best)
return {"answer": best, "reasoning": best_reasoning,
"all_answers": answers}
# ---------- 解析工具 ----------
@staticmethod
def _parse(raw: str) -> dict:
reasoning = answer = ""
m1 = re.search(r"推理过程：\s*(.+?)最终答案：", raw, re.DOTALL)
m2 = re.search(r"最终答案：\s*(.+)", raw, re.DOTALL)
if m1:
reasoning = m1.group(1).strip()
if m2:
answer = m2.group(1).strip().split("\n")[0]
return {"reasoning": reasoning, "answer": answer, "raw": raw}
if __name__ == "__main__":
reasoner = CoTReasoner()
q = "食堂有 23 个苹果，用了 20 个做午饭，又买了 6 个，现在有多少个苹果？"
# 方式 1：Zero-shot
print("=== Zero-shot CoT ===")
print(reasoner.zero_shot(q))
# 方式 2：Few-shot
examples = [
{"q": "停车场有 3 辆车，又开进来 2 辆，现在有几辆？",
"r": "原来 3 辆 + 新来 2 辆 = 5 辆。", "a": "5"},
{"q": "Leah 有 32 块糖，姐姐有 42 块，吃掉 35 块后还剩多少？",
"r": "32 + 42 = 74 块，吃 35 块后 74 - 35 = 39 块。", "a": "39"},
]
print("\n=== Few-shot CoT ===")
print(reasoner.few_shot(q, examples))
# 方式 3：Self-Consistency
print("\n=== Self-Consistency (n=5) ===")
print(reasoner.self_consistency(q, n=5))运行后你会看到三种模式都能给出正确答案 9，但：
- Zero-shot 推理简洁，偶尔格式会飘
- Few-shot 推理严格按示例风格，非常稳定
- Self-Consistency 在有歧义的难题上准确率更高，但慢 5 倍
6.3 工程化建议
上面代码在生产环境还需要加：
- 超时 + 重试（LLM 偶尔抽风）
- Token 预算控制（防止推理链无限长）
- 答案规范化 （
"九"、"9"、"9 个"都应归一化） - 日志埋点（记录每次推理链用于后续分析/训练）
七、三个真实案例：数学题 / 复杂 SQL / 代码 Bug 定位
7.1 案例一：数学题（经典场景）
题目：小明 8:00 出发步行去爷爷家，速度 50 米/分钟。走 12 分钟后爸爸骑车追，速度 200 米/分钟。追上后爸爸带小明继续骑车，小明坐车的路程是走路路程的 5 倍。小明几点到爷爷家？
❌ No CoT Prompt：
请直接给出小明到达爷爷家的具体时间。→ 常见错误输出："8:30" 或 "8:40"
✅ CoT Prompt：
markdown
#问题#
（题目原文）
#要求#
1. 先分步推理，把问题拆成"追上时刻 → 剩余路程 → 剩余时间"三个子问题
2. 每一步给出算式和结果
3. 最后一行给出"最终答案：X 点 Y 分"→ 模型正确输出：追上在 8:16，此时小明走了 800 米；坐车需再走 4000 米，耗时 20 分；到达 8:36。
7.2 案例二：复杂 SQL（程序员最实用场景）
需求：
查询近 30 天内，连续 3 天都有下单的用户 ID 及他们的订单总数。
❌ 直接让模型写 SQL： 很可能写出"简单统计 30 天订单"的 SQL，漏掉"连续"的难点。
✅ CoT 提示：
markdown
请基于 `orders(user_id, order_time, amount)` 表，写一个 SQL 满足需求。
#需求#
查询近 30 天内，连续 3 天都有下单的用户 ID 及订单总数。
#思考步骤#
1. 先过滤出近 30 天的订单
2. 按 user_id + 下单日期去重，得到"用户-活跃日期"表
3. 判断"连续 3 天"：常见技巧是用 `ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY date)` ，
再用 `date - ROW_NUMBER` 得到分组键；同一组内日期差相等
4. 找出在同一分组键下出现 >=3 次的 user_id
5. 回到原表统计这些用户的总订单数
请按以上步骤依次思考，每一步写出中间 SQL 片段，最后拼接成最终 SQL。→ 模型会按部就班写出正确的、带 ROW_NUMBER 技巧的 SQL，并给出每一步的中间产物。对程序员来说，CoT 是最好的"SQL 家教"。
7.3 案例三：代码 Bug 定位
场景：
java
public Integer getTop1Price(List<Order> orders) {
return orders.stream()
.sorted(Comparator.comparing(Order::getPrice).reversed())
.findFirst()
.map(Order::getPrice)
.orElse(0);
}线上偶发 NPE，让 AI 帮你定位。
❌ No CoT：
这段代码为什么会 NPE？→ 模型可能说"Order 为 null" 或"list 为 null"，但不一定切中。
✅ CoT：
markdown
请排查下面代码可能抛 NPE 的所有具体路径。
要求：
1. 从"参数为 null"到"流操作内部"再到"装箱拆箱"，逐层排查
2. 每一条可能路径给出：① 触发条件 ② 具体异常行 ③ 修复建议
3. 最后按风险等级给出一个排查清单
代码：
（贴代码）→ 模型会系统列出：
orders == null→.stream()NPE- 某个
Order == null→Comparator.comparing(...)内部 NPE Order.getPrice()返回Integer且为 null →.reversed()比较时 NPE.map(Order::getPrice)拿到 null → 最终orElse(0)能兜底，但如果调用方期望非空还是有问题
对于老工程师做疑难排查，CoT 是"免费的 on-call 同事"。
八、CoT 的适用边界与常见坑位
8.1 什么时候 CoT 没用甚至有害？
| 场景 | 问题 | 建议 |
|---|---|---|
| 简单事实性查询（"北京今天星期几"） | 推理过程纯属浪费 Token | 别用 |
| 创作类任务（写诗、起名字） | 推理会把创意框死 | 别用，直接生成 |
| 要求极低延迟（在线客服实时回复） | CoT 让输出长度 ×5~10 | 用精简版 CoT 或 No CoT |
| 模型太小（< 10B 参数） | 推理能力不足，会产生"看似合理实则错误"的推理链 | 换大模型或用外部工具 |
| 封闭域分类（情感、标签） | 输出就一个词，没啥可推的 | 直接 Few-shot 即可 |
8.2 常见坑位
| 症状 | 原因 | 解决 |
|---|---|---|
| 推理过程很长但答案还是错 | "幻觉式推理"------看起来有条理，其实中间步骤在胡编 | 加 Self-Consistency；关键步骤改用工具调用（ReAct） |
| 答案和推理过程矛盾 | 模型在"答案"阶段重新蒙了一个 | Prompt 明确要求"答案必须由推理过程直接得出"；用代码解析推理链最后一句 |
| 推理链格式飘忽，无法解析 | 没用固定分隔词 | 强制要求 推理过程： 最终答案： 这种关键词，解析器按正则抓 |
| Self-Consistency 没效果 | temperature=0 → 5 次输出一样 | temperature 调到 0.7~1.0 才有采样多样性 |
| 推理链无限长，超出上下文 | 模型陷入自我怀疑循环 | 在 Prompt 里加"推理步骤不超过 5 步" |
| Few-shot 示例带坏了模型 | 示例本身写错了 / 风格不一致 | 示例要精挑细选，最好人工 review 过的 "gold sample" |
九、工程化：CoT 在生产环境如何落地
作为工程师，光写 Prompt 不够，还要想落地。
CoT 的四种落地姿态：
arduino
┌────────────────────────────────────────────────────────┐
│ 姿态一：直接暴露给用户（带推理过程的回答） │
│ 适合：教育、医疗问答、代码讲解 │
│ 特点：用户看得见"思考过程"，信任感强 │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ 姿态二：推理过程对用户隐藏，只返回最终答案 │
│ 适合：API 服务、结构化数据提取 │
│ 特点：后端做 CoT + 解析，只暴露 answer 字段 │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ 姿态三：推理过程作为"审计日志"落库 │
│ 适合：金融风控、合规决策 │
│ 特点：满足"决策可解释"监管要求 │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ 姿态四：CoT + 工具调用（升级为 ReAct / Agent） │
│ 适合：数据分析、运维自动化、客服工单 │
│ 特点：模型"思考一步，调一个工具"，闭环解决复杂问题 │
└────────────────────────────────────────────────────────┘十、总结
10.1 一张图总结 CoT 心法
arduino
┌────────────────────────────┐
│ 思维链（CoT）的五个等级 │
└────────────┬───────────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
L1 魔法咒语 L2 少样本学习 L3 多链投票
"让我们一步 给 2~8 个示例 Self-Consistency
一步思考" 让模型模仿 N 次采样取众数
│ │ │
└────────┬───────────┴───────────┬────────┘
▼ ▼
L4 结构化推理 L5 行动闭环
ToT / GoT： ReAct / Agent：
推理变成搜索 思考 + 工具 + 观察核心口诀：
- 简单题：能不用 CoT 就不用（省钱）
- 复杂题：一句魔法咒语先起效，再迭代升级
- 重要题：Self-Consistency 多采样投票，提升置信度
- 需要事实：上 ReAct，让模型查资料而不是硬想
- 要落地：推理过程结构化 + 解析 + 日志，这才叫工程化
10.2 写在最后
CoT 看似只是一句"让我们一步一步思考"，但它揭示的是大模型与人类思考之间最重要的一座桥梁：
思考不是一次输出，而是一段过程。
当你真正理解了这一点，你会发现 Prompt 工程、RAG、Agent、Tool Use------这些看起来很花哨的技术，本质上都在做同一件事：给模型留出思考的时间和空间。