第3章 给思考留一张草稿纸——CoT

小a的报表任务出了岔子。它要把三个月的销售数据按地区汇总、再算环比、再挑出异常项——模型一步到位，直接给了一个数字，结果怎么都对不上账。小a抱着试试看的心态，在 prompt 后面加了一句“让我们一步一步来”，重跑，数字居然对上了。

他把两次输出并排贴在屏幕上，越看越困惑。

“这是……我碰巧把提示词写对了？”他问老z。

老z没有直接回答，把同样的问题敲了两遍——一遍要求直接答，一遍要求列步骤。然后他问：“你加的那句话，到底让模型多做了什么？”

“多想了？”小a试探着说。

“对，这是关键。”老z说，“但‘多想’也有很多种，而且不是每种都值得。本章讨论推理提示、思考预算和停止原因；不把可见的推理文本，误当成对模型内部过程的完整揭示。”

先把名字对齐

中文术语	英文全称或缩写	本书工作定义	不等于什么
推理	reasoning	多约束任务中的中间计算、搜索或控制过程	已被证明正确的答案
思维链	Chain-of-Thought, CoT	输出或提示中的中间推理步骤方法	模型内部状态的完整转录
推理强度／预算	reasoning effort／budget	特定 API 对推理资源或输出预算的控制项	跨厂商统一质量刻度
停止原因	stop reason／finish reason	响应结束时供调用方选择控制流的状态	回答质量评分

中文技术语境常把 inference 和 reasoning 都译作“推理”。本书用“模型推理／推断”指固定参数执行一次生成，用“推理”指本章的中间计算与控制过程；两者不是同一个层次。

3.1 推理过程能带来什么

小a把报表问题又跑了一遍，这次他盯着模型输出的每一步看。模型先列出三个月各自的地区汇总，再算环比，最后标出异常——每一步都看得见。

“为什么把过程写出来，答案就更准？”他问。

“你可以把它想成做心算的人。”老z说，“心算一口气算到底，中间错一步就全错；但如果在草稿纸上把每一步都写下来，每一步都只做一小段，错在哪一眼就能看到。研究中常把让模型生成中间步骤的做法，称为 Chain-of-Thought（CoT）。”

比喻：草稿纸

心算 vs 列竖式。草稿纸让每一步都可检查，错误不再滚雪球；模型把中间步骤写出来，道理一样。

“那我可以要求模型把所有思考都输出，来保证正确吗？”小a问。

“不能。”老z摇头，“原始 CoT 论文报告了在其测试的算术、常识与符号推理任务上，以示例提示生成中间步骤可以改善表现。但这是方法和实验范围内的事实，不意味着每个任务都应要求长篇思维链。可见步骤也可能是事后合理化或包含错误；有些服务会保留隐藏推理而只提供摘要或最终答案。正确性仍要由答案、证据和外部验证判断。”

“那为什么写步骤能减少出错？‘多想’本身应该不是万能的。”小a问。

“关键是把长错误拆成短错误。”老z说，“一口气算到底，中间错一步，后面的每一步都建立在错的基础上；分步写下来，每步只承担一小段计算，错的那一步更容易被单独发现。工程上有价值的不在步骤数量，而在每步有没有可检查的输入输出——步骤列了一堆、中间量却全不可核验，和一步到位没有区别。”

“那写步骤有没有副作用？”

“有。输出变长，token 和耗时随之增加；同一任务还可能跑出不同的中间路径，有些对，有些绕远路。”老z说，“CoT 改善的是多约束任务的平均表现，不保证每次都对。它把错误从‘藏在结果里’变成‘出现在某一步’，方便定位，但定位之后仍要修。结构对比是这样的：”

一步到位：输入 ──> 直接给最终数字（错在哪一步无从查起）
分步草稿：输入 ──> 汇总 ──> 环比 ──> 异常标记 ──> 结论（每步可检查）

“那什么任务适合留草稿，什么任务不适合？”小a问。

“看两点：步骤数量，和中间步骤是否可核验。”老z说，“步骤多、每步都有明确输入输出的任务，比如多轮计算、代码排障、计划拆解，适合分步；步骤少、答案在常识范围内的任务，分步只是增加输出。有没有收益，用一个固定样本先跑一轮就知道，不用凭感觉定。”

“那模型本身不支持输出思考文本呢？”

“那就别要求它‘想’。”老z说，“有些模型把推理留在内部，只给最终答案或一段简短摘要。这种情况下，把验证放在答案上，而不是试图从外部逼出中间步骤。CoT 依赖模型的输出能力，不是所有模型都能配合。”

“那分步输出会不会让回答更难读？”

“会。步骤多了，结论反而被埋在后面。”老z说，“所以提示里通常会把‘先给结论、再附步骤’写成明确的格式要求，让读取方不靠翻找。草稿纸是给执行用的，展示顺序是给读者用的，两者可以不同。”

要点

CoT 是方法，不是保证。它改善某些任务的表现，但可见的思考不等于正确的思考。

3.2 三种“留草稿”的方式

报表任务告一段落，小a在整理排查笔记时发现，自己其实用过好几种“让模型多想”的办法。他把笔记本摊给老z看。

“工程上常见三种，按场景选，别混着用。”老z在屏幕上列了一张表：

做法	机制	适合场景	主要代价
显式提示	在指令中要求分解、检查或列假设	过程需要对人可见	输出变长，可能暴露无关细节
结构化分解	程序把任务拆为计划、执行、验证阶段	步骤和验收条件明确	编排复杂，阶段间会丢信息
推理模型预算	API 为推理 token 或 effort 提供控制项	难度变化大、需要按成本治理	提供方语义不同，费用和延迟增加

“这三张表，是不是越往下越高级？”小a看着表格问。

“不是。这是工程分类，不是能力等级表。”老z合上屏幕，“某个模型或 API 是否支持推理控制、控制项如何命名，必须查对应版本的官方文档。”

“那这三种方式各自最容易翻车在哪？”小a问。

“各有一个典型坑。”老z列了一张表：

方式	典型翻车	识别信号
显式提示	要求“逐步思考”后输出变长，步骤里却掺着无关自白	步骤数量多，可检查的中间量少
结构化分解	阶段之间交接丢信息，执行阶段忘了验证阶段的前提	计划、执行、验证各说各话
推理模型预算	字段名和语义随厂商变，跨厂商对不上账	同一种“高”配置，两家用量和结果差很多

“那混着用行不行？”

“混用要盯住一件事：同一轮里谁在主导。”老z说，“显式提示和结构化分解叠在同一轮里，模型可能既按文本要求又按程序阶段走，两套指令打架。程序层面的阶段划分和提示层面的措辞要分开——程序管流程，提示管表达，别在一条消息里同时下达两套指令。”

“那什么时候优先用结构化分解？”小a追问。

“当阶段的验收条件本身是确定性的。”老z说，“比如‘先选数据源、再生成查询、再跑结果、再核对’，每阶段产出一个可检查的中间物——查询文本、返回行数、对账差异。这类任务里，程序把阶段划分写死，比让模型自由发挥更稳，因为每一环都能在代码里校验。”

“那显式提示适合什么时候？”

“适合过程需要给人看的场景。”老z说，“比如排查报告要让同事复核，步骤写在回答里，比藏在内部状态里更容易追。代价是输出变长、可能暴露无关细节——留给人的是‘能看的过程’，留给程序的是‘能查的产物’。”

“那推理模型预算这种呢？”

“它把决策交还给 API 的实现。”老z说，“你只指定一个档位或预算上限，模型内部决定怎么花——这个过程对应用不可见，也不受提示词控制。适合难度变化大、想按成本治理但又不想自己拆步骤的场景。代价是黑盒：看不到内部怎么分配，只能从输出和 usage 里间接推断。”

“那这三种方式能嵌套吗？”

“能，但嵌套要分层。”老z说，“比如外层用结构化分解定义阶段，内层某个阶段里用显式提示要求拆步骤——两层各管各的，不冲突。嵌套失败通常发生在同一层叠加：一个阶段里既要求‘逐步思考’，又塞进一段固定模板。分层嵌套可以，同层叠加要避免。”

3.3 思考预算是一种资源约束

下午，小a顺手把“让我们一步一步来”也加到了报表任务的正式代码里。老z路过看了一眼，皱起眉头：“你知道这么做的代价吗？”

“代价？”小a没反应过来。

“‘多想一点’通常意味着更多生成或内部计算，从而增加时间、token 用量或两者。”老z说，“你可以把思考预算想成一张草稿纸的配额——配额越多，能算的越复杂，但纸也越贵。”

“那给谁多配，给谁少配？”小a问。

“预算应跟着任务风险走。”老z说，“格式转换、简单检索等确定性工作，优先交给程序；涉及多约束推演、代码修改或安全判断时，才值得给模型更高预算，并以验证结果确认收益。一个实用策略是设定总预算：每轮最大输出、总轮数、最长等待时间和失败后的降级路径。只提高单次思考强度而不限制循环次数，仍可能让任务无限消耗资源。”

“那预算给多了会怎样？除了贵。”

“贵只是明面的一层。”老z说，“另一层是过度思考：模型在简单任务上也列一堆假设，输出变长、延迟上升，还可能把本来清楚的结论包装得瞻前顾后。预算不是‘给得越多越稳’，而是‘和任务的复杂度匹配’——给少了不够，给多了浪费，中间那条线要靠实测找。”

“给少了呢？”

“给少了通常是‘思路正确但没写完’。”老z说，“模型可能在最后一步截断——中间步骤写了，结论没给出。这种输出像半成品，比直接给错更考验处理：保留未完成状态继续补充，还是重跑一次给更多预算，是两个不同的分支，不能当同一个结果存。”

“那预算有没有‘单次’和‘任务级’的区别？”

“有，而且容易混。”老z说，“单次预算管一次模型调用，任务级预算管整个多步流程——一次 CoT 用了大半，后续步骤就得降档或提前收尾。只设单次预算、不设任务级预算，多步任务照样可能总账超支，这跟 Agent 循环里的总轮数限制是一个道理。”

“那超支之后往哪降级？”

“按可接受的下限走。”老z说，“降档到低预算重跑、改用确定性程序、还是停下来问人，取决于任务还能不能接受更差的输出。降级路径要在预算耗尽之前就定义好，别等耗尽时现场决定。”

“那思考预算和输出长度是同一个东西吗？”

“不是。输出长度限制管的是可见文本，思考预算管的是模型在内部或外部花掉的推理资源。”老z说，“有些 API 里两者是分开的字段，有些会把内部推理 token 单独计数。别用输出上限去限制思考——把思考上限设低，模型可能连步骤都写不完；把输出上限设低，可能结论被截断。两者要各自设、各自查。”

要点

思考是资源，不是免费午餐。预算跟着任务风险走，并要有总预算兜底，否则会无限消耗。

3.4 停止原因是控制流信号

第二天，小a在调试时翻到模型返回的原始字段，里面有个 stop_reason。他盯着这个字段看了半天，去问老z：“这玩意是干嘛的？”

“模型响应常带有停止原因，名称因 API 而异。”老z说，“应用不能把‘收到文本’简单等同于‘成功完成’。常见语义包括：正常结束、工具调用、长度限制、内容或策略限制、中止或超时。”

小a盯着列表看了半天：“那停止原因是‘对错’吗？”

“不是。停止原因不是质量评分。”老z说，“正常结束的回答仍可能错；长度截断也不该被拼接后冒充完整答案。它的职责是让调用方选择继续、补救、降级或失败退出。”

“那‘工具调用’作为停止原因，是什么意思？”小a追问。

“意思是模型这一轮的输出里包含了一个或多个工具调用请求，它在等宿主执行完再把结果带回来。”老z说，“这不是‘回答结束’，而是‘轮次交接’——循环还要继续。把‘工具调用’当成‘完成’，循环就会在模型提出请求时错误地停下，任务只做了一半。”

停止原因	含义	调用方通常的下一步
正常结束	模型给出了最终文本	进入完成处理（但仍需验证内容）
工具调用	模型请求执行工具	执行工具，带结果进入下一轮
长度限制	输出达到上限被截断	标记为未完成，不能当完整答案
内容/策略限制	触发了内容过滤	降级或换任务表达
中止/超时	外部取消或超时	标记中断，保留部分结果

“那‘长度限制’和‘正常结束’怎么区分？”小a问。

“看停止原因字段，不要靠猜。”老z说，“有些 API 在正常结束时返回 stop，在截断时返回 length 或 max_tokens——这两个字段值不同，处理方式也不同。截断的输出不能拼接后存成‘成功’，因为它可能在句子中间断开，语义不完整。UI 应把它标成未完成，让用户知道这条回答不完整。”

“那如果程序忽略停止原因，会怎样？”小a问。

“每种忽略都有一个具体后果。”老z列了一张反例表：

忽略的停止原因	后果
把 length 当正常结束	半句话存成完整答案，后续校验全错位
把 tool_use 当完成	循环提前停下，工具请求没人执行
把 error 当正常停止	失败被静默吞掉，任务卡在错误状态
把正常结束当必然正确	跳过验证，错误结论直接进入下游

“那收到停止原因之后，程序是在做一次分发？”小a问。

“对。停止原因进一个分发器，每种原因对应一个分支。”老z画了一张图：

响应结束 ── stop ──────> 验证内容 → 完成处理
         ├─ tool_use ────> 执行工具 → 结果回写 → 下一轮
         ├─ length ──────> 标记未完成 → 补采或降级
         ├─ 内容限制 ────> 换表达 → 重试或停止
         └─ 中止／超时 ──> 保留部分结果 → 报告状态

“这个分发器写在哪一层？”

“宿主应用层，不是模型层。”老z说，“模型只负责返回一个终止信号；怎么响应它——继续、补救、降级还是退出——由宿主根据当前任务上下文决定。停止原因不携带‘对错’，只告诉宿主‘这轮是怎么结束的’，剩下的分支判断属于宿主。”

“那停止原因是一个任务只有一个吗？”

“不是。停止原因是‘这一次响应’的结束信号，不是‘整个任务’的结论。”老z说，“一个多轮任务里，每一轮响应都有自己的停止原因——前几轮可能是 tool_use，最后一轮才是 stop。把‘最后响应是 stop’当成‘整个任务成功’，会漏掉前面几轮到底发生了什么。要判断任务级结果，得把每轮的停止原因连起来看。”

“那停止原因缺失或为空呢？”

“当成未知处理，别当成正常结束。”老z说，“字段为空可能是协议差异、版本差异或服务端问题；填一个默认值悄悄通过，等于把未知塞进了判断链路。未知的停止原因要走显式的‘无法判定’分支，而不是静默归类到成功。”

“那要不要把停止原因原样透传到 UI？”

“要透传，但要让用户看得懂。”老z说，“length 这类原始值适合日志，界面里标成‘回答被截断’更清楚。把原始值和分析后的状态分开存，两层都有，排查和展示都不缺材料。显示要转译，存储要保真。”

要点

停止原因是控制流信号——告诉程序“下一步该干嘛”，不是“这回答对不对”。

3.5 质量、成本和验证的关系

报表任务上线前，小a拿着一张写满数字的纸来找老z：“我测了一下，让模型多想，准确率是高了，但每次都慢两倍、贵三倍。预算到底该设多少？”

“别默认‘越高越好’，把它写成一个明确的取舍。”老z敲出一段示意：

任务风险高且可验证 → 增加推理预算，并执行验证
任务简单且结果可校验 → 限制预算，优先确定性程序
结果不可验证         → 降低自动化权限，要求说明不确定性

“这个阈值能抄作业吗？”小a看了看自己的项目。

“不能。这是一条工程观点。”老z说，“真正的阈值应由你的延迟目标、价格、失败代价和离线评测决定。不要用单个漂亮示例，推断某档预算对所有任务更好。”

“那怎么测才不算‘单个漂亮示例’？”小a问。

“把任务样本固定下来，按维度打分。”老z说，“至少分三层：结果对不对（测试通过、数值吻合、引用存在）、成本多少（token、延迟）、失败长什么样（哪种停止原因、哪个假设错了）。用一组样本跑出分布，而不是用一条跑出结论；预算调高一档，三个维度都没有明显改善，那档预算就不值得付。”

“验证手段是不是也分强弱？”

“分。最强的是确定性校验——测试通过、数值对上、命令返回码为 0；中间一档是证据核验——引用了来源、能追踪到原始数据；最弱的是模型自评——它说‘我觉得没问题’。”老z说，“自评可以当提示词里的自检步骤，不能当验收依据。验收强度决定自动化能开多高：结果能被确定性校验的任务才适合高自动化，只能靠自评的任务要把权限降下来。”

“那这三种验证，能不能列个对照？”小a问。

“可以。”老z列了一张表：

验证手段	强度	适合任务	局限
确定性校验	强	测试通过、数值核对、命令返回码	需要可执行的定义
证据核验	中	引用可追溯、来源可查	需维护证据索引
模型自评	弱	内部自检、兜底	不能当验收依据

“那这些数据谁来记录？”

“宿主记录，不是模型报告。”老z说，“token 用量、延迟、停止原因来自响应元数据；正确与否来自校验器。让模型自报‘我觉得我答对了’，只会把验证混进生成里。”

“那评测的频率呢？”

“跟着改动走。”老z说，“提示词改一句、预算档位换一档、模型版本升一次，都值得重跑同一组样本。评测不是上线前的仪式，而是每次变动的对照实验——不重跑就上线，等于靠上次的印象做决定。”

3.6 把“思考”接入一个可验证流程

小a决定把报表任务彻底改造一遍。他不再要求模型“想清楚”，而是让每一步都产出可检查的东西：先列假设，再选数据，再算，再核对。

“更稳妥的做法，不是要求无边界的长篇推理，而是让每一阶段都有可检查的产物：假设、计划、执行结果和验证结论。”老z看完他的新设计说，“它们可以由模型生成，也可以由确定性程序产生；关键是后续步骤不得把前一阶段的猜测当事实。”

任务 → 写出假设 → 选择证据或工具 → 得到结果 → 检查验收条件 → 结论
                  └── 不可用/超时 ──> 降级、澄清或停止

“那草稿纸上的内容，是不是都该存下来？”小a问。

“不一定。”老z说，“可见的中间文本有审阅价值，但也会泄露不必要内容、占用上下文并诱导后续步骤锚定错误前提。对需要审计的系统，记录‘使用了哪些证据、调用了什么工具、为何停止’，通常比保存冗长的自由文本推理更有用。”

示意： 排查一个测试失败时，先把“环境变量缺失”列为假设，再读取配置、运行相关测试；两项证据均不支持时，应丢弃该假设，而不是为了保持叙事连贯继续修改代码。

“那‘草稿’和‘结论’在流程里怎么区分？”小a问。

“按是否被后续步骤消费来分。”老z说，“草稿是候选，谁都可以推翻；结论是被证据支持、进入下一步或最终输出的东西。流程里要有一道明确的状态升级：假设从‘候选’升到‘采用’，必须有过证据支持；没有证据支撑的假设停在候选区，不进结论。这一步升级如果由模型自己说了算，就等于把验证和生成混在了一起。”

“那验证失败之后呢？”

“验证失败是一种结果，不是一场事故。”老z说，“它意味着当前假设不成立，流程回到‘选下一个假设’或‘升级给人’，同时保留失败记录——下次再遇到同类问题，可以直接跳过已知不成立的路径。把失败当成流程里的一条分支，而不是让循环原地打转，验证才有意义。”

“那要存下来的‘可检查产物’有哪些？”小a问。

“够回答三类问题就够。”老z说，“用了什么假设、调用了什么工具、为什么停止——这三件事分别对应草稿、证据和停止原因。存下它们，事后能回答‘它当时基于什么做出这个结论’；只存最终答案，就只能看到结论，看不到过程。”

“那自由文本的推理存不存？”

“看审计需求，不是默认存。”老z说，“长文本推理占存储、可能泄露信息，还容易在后续步骤里把‘想过的’当成‘验证过的’。存‘发生了什么’比存‘它想了什么’更接近事实——前者可核验，后者是模型自己说的。”

“那‘升级给人’在流程里算什么？”

“一条正常的转移。”老z说，“当假设穷尽、证据互相矛盾、或需要权限判断时，流程停下来，把草稿、证据和候选假设交给人来定。它和‘验证失败’一样是流程的分支，不是异常——分支越多，系统越不需要在信息不足时硬猜。”

“那草稿和证据的版本怎么管？”

“跟着流程走。”老z说，“假设被修改、被推翻、被采用，都留一条记录；证据引用哪份文件、哪个工具返回，也写明来源。这样当结论被质疑时，能回答‘这个假设是什么时候、基于什么改成现在这样的’。草稿可以乱，版本线不能断。”

3.7 budget 是控制流的一部分

上线前最后一件事，小a想给不同厂商配置思考强度，却发现每个厂商的参数名都不一样。他翻着文档，无奈地问老z：“我调 reasoning_effort，是不是就能跨厂商统一？”

“不能。”老z说，“reasoning_effort、thinking token 或内部 budget 的字段名和可见性由 API 定义；官方 reasoning 指南将 reasoning controls 作为特定接口能力，而非通用协议。应用应记录实际传出的字段、模型版本和最终 usage，不能把不同提供方的‘高’视为同一资源量。”

收到任务 → 按风险选预算 → 请求模型
  → 正常结束：验证答案与证据
  → length：保留未完成状态，决定补充或降级
  → timeout／aborted：停止本轮并报告状态
  → tool call：先执行、回传结果，再决定下一轮

“所以预算真正的价值，是让我能‘控制’而不是‘祈求’？”小a忽然抓住了什么。

“对。”老z点头，“正常路径是预算内得到可验证结论。两个反例是输出到达长度上限，以及高 effort 仍建立在错误假设上：前者不能伪装成完整答案，后者说明预算只改变资源配置。工程上应把预算集中给难且可验证的步骤；代价是需要评测与监控，不可验证的高风险结论应降低自动执行权限。”

“那不同厂商之间的‘高’，能直接比吗？”小a问。

“不能直接比。”老z说，“A 家的高 effort 可能是更多内部推理 token，B 家的同名参数可能只影响回答措辞。跨厂商可比的是测出来的结果，不是参数名——用同一组任务、同一套评分跑两家的‘高’，比较的是产出，不是配置。记录请求时把实际字段名、模型版本、usage 一起存，换厂商才有对照基线。”

“那预算在请求里怎么体现？”

“至少三层：请求参数（effort 或 thinking budget）、限制项（最大输出、最大轮数）、最终 usage 回执。”老z说，“前两层在请求发出前可配置，第三层只有响应回来才知道。把‘配置的预算’和‘实际的消耗’分开记账——两者对不上，往往是降级、重试或缓存命中在起作用，查起来就有线索了。”

“那预算配置应该写在代码里还是提示词里？”

“代码里。”老z说，“预算是对资源上限的承诺，属于宿主控制范围；写进提示词，等于让模型决定自己的消耗上限。预算字段留在请求装配层，提示词只表达任务意图，两者分层，出问题才好定位。”

“那思考强度要不要跟任务类型绑定？”

“可以绑定，但要留出例外。”老z说，“比如按任务路由默认档位，复杂任务调高、简单任务调低；但遇到‘默认档位下验证失败’的情况，允许下一轮提升档位重试。绑定的是起点，不是上限——固定的默认值，配合有记录的重试，比写死的单一档位更稳。”

“那跨厂商迁移时，预算这块要重配吗？”

“几乎都要。”老z说，“字段名、可见性、费用结构都不通，直接把 A 家的配置照搬到 B 家，多数情况是空的、被忽略的，或者语义完全不同。迁移时的对照基准是同一组评测任务的实测结果，不是参数值。”

“那如果厂商只给‘低、中、高’三档，怎么设默认值？”

“用离线任务把三档各跑一遍，看哪个档位落在成本与正确性的交点上。”老z说，“档位不是评分标准，只是入口；真正的判断依据是你那组任务上的实测分布。厂商给的是旋钮，你给的是刻度。”

小结

思维链让模型"先想后答"——把隐式的中间推理显式化成文本步骤,从而在多约束任务里分步处理,而不是一口气给出结论。这种方法的价值不在"让模型变聪明",而在于让推理过程变得可审查:你能看到模型在哪一步做了什么假设,在哪一步走了岔路。推理强度或推理预算这类参数控制的是模型愿意花多少"思考资源",调高它确实可能帮模型处理更复杂的问题,但同样可能让它更慢、更贵,却不一定更准——预算买的是机会,不是正确性。

这里要分清两件事。第一,中间过程是工作材料,不是事实本身:模型"想"出来的步骤仍然是概率生成的,它可能想得很流畅却想错了,所以推理过程要配外部验证,不能当成已验证的结论。第二,停止原因(stop reason)是控制流的输入,不是一句废话:模型因为 stop 结束、因为 length 被截断、因为 tool_use 要调用工具、还是因为 error 出错,对应着完全不同的下一步处理。还有一个中文特有的坑——"推理"这个词同时指 inference(用固定参数做推断)和 reasoning(中间计算过程),两者在英文里是不同的词,在本章讨论的完全是后者。

"留草稿"的三种方式——显式提示、结构化分解、推理模型预算——是工程分类,不是能力等级表,各有各的典型翻车:显式提示可能输出变长而可检查的中间量没变多;结构化分解可能在阶段间丢信息;推理预算受厂商字段语义约束,跨厂商对不上账。混用时要盯住同一轮里谁在主导,别让两套指令打架。预算跟着任务风险走,并且要有总预算兜底;给多了会过度思考,给少了会在最后一步截断——截断的中间产物要保留未完成状态,不能和完整答案混存。

停止原因最终落到宿主的一个分发器:每种原因对应一个分支,继续、补救、降级还是退出由宿主按任务上下文决定,停止原因本身不携带对错。验证的强度决定自动化能开多高——确定性校验、证据核验、模型自评三层依次减弱,能被确定性校验的任务才适合高自动化。预算的记账要分开:配置的预算、限制项、实际的 usage 回执是三层信息,跨厂商比较看同一组任务上的实测结果,而不是参数名。把草稿、验证、停止原因和实际消耗各自存清,一套 CoT 流程才既看得见,也算得清账。

动手核验

选择一个有确定答案的小任务，分别以“直接回答”和“列出假设后回答”运行。提前写下评分规则，例如测试是否通过、计算是否正确、引用是否存在。记录输出长度、耗时和得分，而不是只凭主观印象选择提示词。