让 AI 一步步想也在增加计算机会

修订于 2026-10-16。

让 AI 一步步思考，是一个很容易复制的建议。更难回答的是：这句话究竟改善了什么，多花的时间和计算有没有带来收益？

我的判断是，中间步骤同时提供了两样东西：可以继续使用的解题状态，以及更多计算机会。把效果全归结为教会了模型一种方法，会漏掉后面这一半。

这个区别会影响实际工作。换一个模型，原来有效的提示词可能需要重测；多写一页推理，也需要检查结果有没有变好。

一 中间步骤让模型有机会继续计算

数出 strawberry 里有三个 r，对人很简单。对语言模型来说，输入会先经过分词，得到的 token 可能对应一个字、词的一部分，或者更长的片段。具体边界取决于分词器和输入形式。

把单词按字母列出来，提供了一份更容易逐项检查的表示：

s - t - r - a - w - b - e - r - r - y

这改变了模型接下来能使用的上下文，也增加了生成步骤。单凭一次答对，无法区分表示变化和额外计算各自贡献了多少。

对自回归 Transformer，每生成一个新 token，模型都要执行新的计算，并把已有内容作为后续生成的条件。中间结果留在上下文里，后面的计算就有了可以接着使用的状态。

多生成 token 会增加计算，但计算增加能换来多少正确率，需要实际测量。把中间状态写下来，也给后续步骤提供了检查和修正的对象。

比如处理一批订单，先列明数量、单价和运费，再算总额，至少让每一项都有了可核对的位置。如果只给最后一个数字，出了错还得回头追。这里的表示方式本身就有用途，不能把所有改善都归给多算了几步。

反过来，答案写得很长，也可能一直围着同一个错误打转。模型会继续使用已经生成的内容，其中既有有用的状态，也可能有错误前提。让它把结论再解释一遍，与给它一个可以纠错的新事实，是两种不同的干预。

所以我看中间过程，先问它留下了什么可复用、可核对的东西。只是把同一句判断换几种说法，消耗了更多计算，也未必推进了解题。

二 三项研究说明了不同的事情

2023 年，Wang 等人在 Towards Understanding Chain-of-Thought Prompting 中修改了示例里的推理步骤。在其测试设置下，即便示例推理无效，多项指标仍能达到有效 CoT 示例表现的八到九成；问题相关性和步骤顺序的影响更大。

这说明，示例中每一步的正确性，并不能单独解释提示效果。实验研究的是提示中的示例，不能据此推断模型自己生成的推理内容也无关紧要。

2024 年，Let’s Think Dot by Dot 在两个算法任务上展示了更特别的结果：经过专门训练的 Transformer，可以利用没有语义的填充 token，完成直接回答时做不好的任务。学会使用这些填充符需要特定、密集的监督。

这提供了一个具体例子：额外 token 的收益可以来自计算本身。给普通聊天模型追加一串省略号，能否得到同样效果，得另外验证。

Merrill 和 Sabharwal 的 The Expressive Power of Transformers with Chain of Thought 则从理论上研究中间生成步骤的作用。在论文规定的模型与计算假设下，允许更多中间步骤，可以扩展 Transformer 能表达的问题范围。

三项工作分别讨论示例、填充 token 和理论表达力。放在一起，它们提醒我：分析推理效果，既要看中间写了什么，也要看多用了多少计算。

这里还有一个实验设计上的区别。给模型一份错误示例，是在改变输入；训练模型利用填充符，是在改变它已经学到的能力；理论证明则讨论特定条件下的表达能力。它们回答的问题相关，干预的位置却不同。实际使用某个模型时，仍然要确定哪一个条件和自己的任务相符。

这也影响我们怎样解释失败。如果换一份示例，答案就变了，应先查示例里的信息和排列方式。如果延长生成后仍在重复错误，应检查有没有提供新信息、工具结果或可执行的验证。把这些变化都叫作更会思考，会让排查失去方向。

三 推理模型也需要按任务测试提示词

DeepSeek 的两个模型很容易混在一起。R1-Zero 展示了直接通过强化学习、无需先做监督微调，就能形成长推理行为的可能性；R1 则加入了冷启动数据和监督微调阶段。官方模型说明

模型具备了长推理能力，也不能直接推出逐步思考指令已经失效。DeepSeek 的官方使用建议，就对数学问题推荐加入逐步推理指令。

提示词里要不要示例，要不要要求展开步骤，应该放到具体任务里比较。某个模型、某类题上的经验，可以作为起点；换了版本，还要看它是否继续有效。

多次采样也一样。自洽性方法会生成多条推理路径，再汇总答案，原论文在多项推理基准上观察到了收益。Self-Consistency 论文

投票和验证器解决的是不同问题。投票统计候选答案的一致性；测试程序或规则检查器则检验候选是否满足条件。前者可能一起犯错，后者也可能漏检。多采几次是否合算，要看新增的正确结果能否抵得上成本和延迟。

假设原来生成一个候选，现在改成生成五个，再从里面选一个。应该记录的是最终交付答案的正确率，以及生成和筛选的总成本。只看五个候选里有没有正确答案，会把挑选答案的困难省略掉。真实系统最后得交出去一个结果，选择过程也属于系统能力的一部分。

如果用测试来筛选代码，也要检查测试覆盖了什么。候选能通过已有测试，是一条有用的信息；新增边界条件后是否仍能通过，是下一项要测的能力。模型生成和测试筛选可以互相补充，测试集本身则需要维护。

四 把提示词改动放进评测回路

我做内部 AI 应用时，遇到过提示词里的示例把相近问法带偏的情况。那次让我更在意一个问题：调整之后，究竟是哪一类问题变好了，哪一类又变差了？

靠几次聊天很难看出来。更实用的办法，是保留一组真实业务问题，写清楚预期答案或判断标准，再比较改动前后的结果。模型、提示词和工具一起变动时，这份记录尤其有用。

评测集也要维护。业务事实更新、用户问法变化、我们围绕旧题反复调优之后，都要补新案例。它的价值在于让判断有依据。

例如做一个内部问答系统，可以先选一批正常提问，再加入缺少条件、说法含糊、前提错误和系统无权回答的问题。预期行为也要分别写清：有的需要查数据，有的需要追问，有的应当说明无法判断。最后只统计答对了多少题，会漏掉系统有没有在该停下来的地方停下。

比较提示词时，尽量保留相同的模型版本、工具权限、输入信息和输出要求。一次只改一个主要因素，才容易追到原因。有随机性的生成需要重复运行，并记录失败案例；想继续调提示词，可以另留一批题做最后检查，减少只对熟悉样本有效的情况。

效率也可以落到读者能判断的指标上：多少请求达到了要求，平均花费多少，等待时间多长，是否增加人工复核。一个方案准确率略高，但慢到无法用于交互，可能更适合离线处理。用途先确定，计算预算才有比较的依据。

能运行测试、核对数据或检查约束的任务，可以把验证接到生成之后，再比较直接回答、展开步骤和多次采样的效果。对开放问题，则要保留人工评审，检查推理是否可靠、内容是否有用。

我更愿意花时间积累这些问题和判断标准。提示词是一项可以更换的方案，评测回路能帮助我们决定什么时候该换，以及换成什么。