我为什么回头读 CoT
CoT 现在已经像常识一样存在了，很多人随手就会写一句“think step by step”。但我回头读原论文时，反而想搞清楚一个更基础的问题：它到底是一个 prompt 技巧，还是早期 reasoning model 的雏形？
我的理解是，CoT 的价值不在于让模型输出一堆看起来像推理的文字，而在于给复杂任务留出中间状态。没有这些中间状态，模型更像是直接从问题跳到答案；有了中间状态，它至少有机会把算术、常识和符号操作拆开处理。
论文里的核心直觉
这篇论文的启发很直接：一方面，算术推理经常需要自然语言理由或中间步骤；另一方面，大语言模型已经表现出 few-shot in-context learning 的能力。把两者放在一起，就是在 prompt 的示例里写出“问题、推理步骤、答案”的完整样子，让模型模仿这种解题格式。
它的实现其实很朴素：不训练、不改模型，只是在 few-shot exemplars 中加入思维链。作者强调 CoT 有几个好处：可以把多步问题拆成中间步骤；可以给人一个观察模型行为的窗口；可以用于数学、常识和符号推理；而且只需要足够大的现成语言模型就能触发。
这里要注意一句话：足够大的模型。原论文里 CoT 的收益有明显的规模门槛，小模型可能生成很流畅但完全不对的推理链。这个现象到今天仍然值得记住，因为“会写推理文本”和“真的推对了”不是一回事。
不是所有任务都需要 CoT
论文里一个很有意思的观察是：越复杂的问题，CoT 收益越明显。GSM8K 这类多步数学题提升大；单步计算任务提升很小，甚至可能变差。
这和工程直觉是一致的。如果问题本身只需要一步查询或一步分类，强行让模型解释十步，反而是在增加噪音和成本。很多线上系统后来会做“是否需要推理”的路由，本质上也是这个判断：简单任务别过度思考，复杂任务才分配更多 test-time compute。
我现在怎么看 CoT
我不太把 CoT 当成“让模型变聪明”的魔法。它更像是一种很便宜的接口设计：把内部本来可能隐式发生的分解过程，用文本形式外显出来。
这个外显有两个价值。第一，它给模型更多生成空间，避免一步跳错。第二，它给工程系统一个可检查的过程材料，虽然这个过程不一定忠实，但至少可以被截断、投票、验证或交给工具。
它的问题也很明显
CoT 不保证推理路径正确。更麻烦的是，有时候路径错了，答案也会跟着错；有时候路径看起来很合理，答案却只是偶然正确。它提供的是一个窗口，不是模型真实内部计算的完整解释。
部署上还有成本问题。长 CoT 会消耗 token，也会拉长延迟。到 2025 年以后，很多 reasoning model 已经通过 long-CoT SFT、reasoning RL、distillation 等方式显式支持 thinking 模式，小模型也能表现出一部分推理能力。但我还是会把 CoT 看成基础概念：后面的 Self-Consistency、ToT、ReAct、LATS，很多都在回答同一个问题：中间步骤生成出来以后，怎么搜索、怎么验证、怎么行动。
小结
CoT 最重要的提醒是：复杂问题不要急着要最终答案，先让模型拥有可操作的中间状态。
但它不是可靠性的终点。工程上真正要做的是判断什么时候需要 CoT，什么时候应该短答，什么时候应该让工具验证，什么时候应该用多路径采样或搜索来抵消单条推理链的脆弱性。