推理类提示工程（CoT 全家桶）

「让模型一步步想」是提示工程里最高价值的一类技巧。从最朴素的 Zero-shot CoT 到思维树、自我精炼、退一步提示，再到推理模型时代「该不该手写 CoT」的范式转变——本文把推理类提示一次讲透，每个方法都给出原理、模板、适用边界与失效场景。

为什么「思考」能提升正确率？

Transformer 是固定深度的网络：一次前向只有有限的计算量。让模型直接输出答案，相当于强迫它在「读完题」到「吐出答案」之间用固定的算力解决任意难度的问题。而让它先生成推理文字，等于把计算摊开在时间维度上——每生成一个中间 token 都是一次额外的前向计算，串起来就形成了「可变深度」的有效计算。

一句话本质：CoT 用「生成更多中间 token」换「更多串行计算」，把单步映射变成多步推理。这也解释了为什么 CoT 对组合推理、数学、多跳问答有效，对简单事实查询无效（后者不需要额外计算）。

这条原理是后面所有变体的共同地基，也是推理模型（o1/R1）「长思维链 + test-time compute」的理论来源，见 推理模型与慢思考。

一、Chain-of-Thought 家族

Zero-shot CoT

最简单：在问题后加一句触发语。

问题：食堂有 23 个苹果，午餐用了 20 个，又买了 6 个，现在有几个？
让我们一步步思考。

• 触发语经典版是 "Let's think step by step"；中文「让我们一步步思考」「请逐步推理」同样有效。
• 研究发现触发语的具体措辞会影响效果（"Let's work this out step by step to be sure we have the right answer" 等更长的引导在某些基准上更好）。
• 失效场景：简单问题上反而可能因「过度思考」引入错误；小模型上 CoT 几乎无效甚至有害（这是涌现能力）。

Few-shot CoT

在示例里展示完整推理过程，而非只给「输入→答案」：

Q：罗杰有 5 个网球，又买了 2 筒，每筒 3 个，共几个？
A：罗杰原有 5 个。2 筒 × 3 个 = 6 个。5 + 6 = 11。答案是 11。

Q：（你的真实问题）
A：

• 比 Zero-shot CoT 更强、更可控（能规定推理风格和格式），代价是占用上下文、需要人工写示例。
• 示例质量 > 数量：错误或风格混乱的示例会把模型带偏。

Auto-CoT

人工写 few-shot 示例成本高。Auto-CoT 自动化：对问题库聚类、每簇选代表问题用 Zero-shot CoT 自动生成推理链，组成 few-shot 示例池。核心思想是用多样性采样规避单个示例的错误传染。工程上现在更多被「直接用强模型批量生成 + 过滤」取代。

二、提升可靠性：采样与搜索

自洽性（Self-Consistency）

对同一问题用带温度的采样生成多条 CoT 路径，对最终答案投票取多数：

同一问题采样 N=20 条推理 ──► 提取各自的最终答案 ──► 多数投票

• 原理：不同推理路径可能各自在不同地方出错，但正确答案更容易成为多数（错误是分散的，正确是收敛的）。
• 是「推理时计算换正确率」的最朴素形式，N 越大越准但成本线性涨。
• 要求答案可归一化比较（数学答案、选项）；开放式生成无法直接投票，需配评分。
• 进阶：Universal Self-Consistency 用 LLM 当裁判从多条回答里选最一致的，适用于无法精确匹配答案的场景。

思维树（Tree of Thoughts, ToT）

把推理建成树：每个节点是一个「想法（thought）」，模型生成多个候选分支、对每个分支自评打分、用 BFS/DFS 搜索 + 剪枝，支持回溯。

        问题
       /  |  \
    想法A 想法B 想法C   ← 生成候选
     |    ✗    |       ← 评估剪枝（B 被淘汰）
   A1 A2     C1 C2

• 适合需要探索和试错的任务：24 点游戏、填字、规划。
• 代价极高（节点数 × 每节点多次调用），生产中少用，更多是「推理能力上限」的研究探针。

思维图（Graph of Thoughts, GoT）

把 ToT 的树推广成图——想法之间可以聚合、回环、复用，表达更复杂的依赖。理论更强但工程复杂度更高，实用性有限，面试知道「ToT 的图泛化」即可。

三、问题分解类

Least-to-Most（由简至繁）

两阶段：先让模型把难题分解成由易到难的子问题，再依次求解，且后面的子问题可以用前面的答案。对需要泛化到「比示例更难」的组合问题特别有效，缓解 CoT「一步错步步错」。

Plan-and-Solve

针对 Zero-shot CoT「漏步骤/算错」的改进：提示分两段——「先理解问题并制定计划，再按计划执行」。比单纯「一步步思考」更强调先规划后执行的结构。

Step-Back Prompting（退一步）

先让模型抽象出更高层的原理/概念，再用原理解答具体问题：

原问题：理想气体在温度变为 2 倍、体积变为 8 倍时压强如何变化？
退一步：这道题背后的物理原理是什么？ → 理想气体定律 PV=nRT
再解答：用该定律推导……

适合知识密集、容易在细节上翻车的题——先锚定大方向再算细节，显著降低推理跑偏。

四、自我改进类

Self-Refine（自我精炼）

同一个模型扮演三角色循环：生成 → 自我反馈 → 按反馈修订，直到满意或到轮数上限。无需额外训练，靠模型自己挑自己的错。

• 有效前提：模型有能力发现自己的错误。在有外部信号（代码能否跑通、数学能否验证）时增益明显；纯靠模型「自评」时，研究表明自我纠错可能无效甚至变差（模型对自己的错误同样盲目，甚至把对的改错）。
• 面试高分点：自我纠错的有效性高度依赖「能否获得可靠的外部反馈」——这也是为什么数学/代码上 self-refine 有用、开放问答上常常没用。

Reflexion

把自我反思沉淀成语言记忆：Agent 尝试任务失败后，用语言总结「为什么失败、下次怎么改」，写入记忆，下次尝试时带着这条反思。是 self-refine 的「跨回合记忆」版本，连接到 Agent 的 记忆系统 与 Agent 基础。

五、推理模型时代：范式转变（最新）

o1/R1/Qwen3-thinking 这类推理模型把长思维链内化到训练里（RL + 可验证奖励，见 DeepSeek 专题），提示工程随之改变：

传统模型	推理模型
要手动加「一步步思考」	不要手写 CoT，模型自己会想
few-shot CoT 示例提升明显	few-shot 可能反而干扰，零样本更好
要拆解步骤喂给模型	给清晰目标和约束，让它自己拆
温度/采样需精调	官方建议温度区间（如 R1≈0.6），别贪心

给推理模型写提示的要点：

• 说清目标、约束、评判标准，把「想」的过程交给模型；
• 不要在 prompt 里塞一堆 CoT 示例和「请逐步思考」，可能打断它的原生推理；
• 复杂任务可以明确「先分析需求，再给方案」，但不必规定具体推理步骤；
• 仍可叠加 self-consistency（多采样投票）进一步提升难题准确率。

趋势判断：随着推理模型普及，「教模型怎么想」的提示技巧价值下降，「说清要什么」的需求工程价值上升。但理解 CoT 家族仍是必修——它解释了推理模型为何有效，也仍是非推理模型的主力手段。

方法选型速查

任务特征	推荐方法
简单事实/分类	不用 CoT，直接答
数学/逻辑/多步	Zero/Few-shot CoT
要更高准确率、可投票	Self-Consistency
比示例更难的组合问题	Least-to-Most
知识密集易翻车	Step-Back
有外部验证（代码/数学）	Self-Refine / Reflexion
需大量探索试错	ToT（成本允许时）
用的是推理模型	给目标+约束，别手写 CoT

高频追问

Q：CoT 一定能提升效果吗？ 不是。它对需要多步计算的任务有效，对简单查询无益甚至有害（过度思考引入错误）；且是涌现能力，小模型上基本无效。对推理模型则不需手动加。判断标准：这道题「需不需要打草稿」。

Q：Self-Consistency 和 ToT 的区别？ Self-Consistency 是「多条独立路径 + 终点投票」，路径之间不交互、实现简单；ToT 是「带评估和回溯的结构化搜索」，节点间有父子关系、可剪枝可回溯，能力更强但成本高一个量级。前者工程常用，后者多在研究。

Q：模型能可靠地自我纠错吗？ 取决于反馈来源。有外部可验证信号（代码跑测试、数学验算、检索核对）时，self-refine/Reflexion 增益明显；纯靠模型「自我评判」时，研究显示常常无效甚至把正确答案改错——因为模型对自己的盲点同样盲。别迷信无外部信号的自我纠错。

Q：为什么对 o1/R1 不该写「让我们一步步思考」？ 它们已通过 RL 训练内化了长思维链，会自主展开推理。再叠加人工 CoT 提示或 few-shot 推理示例，可能干扰其原生推理路径、甚至降低效果。正确做法是给清晰目标和约束，把推理过程交还给模型。

Q：Step-Back 为什么有效？ 先抽象出高层原理再解题，相当于给推理「锚定正确的大方向」，避免一头扎进细节算错。本质是一种「先检索正确的知识框架，再做演绎」的两阶段策略，对知识密集型题目尤其有效。

Q：这么多变体，工程上实际常用哪些？ 非推理模型场景：Zero/Few-shot CoT 打底，难题加 Self-Consistency，知识题加 Step-Back，可验证任务加 Self-Refine。ToT/GoT 多用于研究或极少数高价值离线任务。推理模型场景：基本只需写清需求 + 可选多采样投票。