分步输出的校验是怎么做的？每一步都讲透

在流水线里用大模型逐步产出结果——先抽取、再归纳、后成稿——每一步都可能引入小偏差，单靠最后一步把关常常来不及。步骤校验的思路是给每一步加一道闸门，本文以 DeepSeek 的多步任务为例，把闸门讲透。

校验卡在哪个环节最划算

卡在源头最划算：第一步抽取错了，后面全盘皆错。所以校验优先级从前往后递减，越靠近源头查得越细，越靠近成稿越只查整体一致性。把关动作前重后轻，人力才花在刀刃上。

每步的校验标准怎么定

• 抽取步：字段是否齐全、数值有没有抄错。
• 归纳步：要点是否覆盖输入、有没有夹带原文没有的内容。
• 成稿步：风格是否统一、与前面步骤的结论是否一致。

标准要写成可判定的句式，「要点齐全」太虚，「不少于五条且每条含一个数字」才好执行。

校验失败后的重试写法

重试别只发一句「不对，重来」，要把错在哪一并说清：「第二条与原文不符，请只修正该条」。带错误说明的重试比盲目的原样重发有效得多，通常一两次就能过闸。扣子的工作流里，这类判断和回传可以用条件分支直接搭出来。

分步与一次成稿的校验差别

• 分步：闸门多、单步简单，适合长链路和高要求场景。
• 一次成稿：只查终稿，快但错得隐蔽，适合低风险轻任务。
• 折中方案：关键步骤单独设闸，其余一次过。

推演深度与每步预算的配合见思考预算和提示是怎么配合的？从原理到落地；长任务的闸门节奏见长任务的检查点提示是怎么设的？；步骤顺序怎么排见多条件提示的顺序有讲究吗？机制细节全梳理；列表类步骤的稳定性见长列表输出的稳定性是怎么保的？。

闸门的执行者可以分三档：模型自查、另一个实例互查、程序硬校验，成本与可靠性各有取舍。格式类指标交给程序最划算——正则、字段数、类型判断都是确定性规则，机器做机器擅长的事；内容类指标交给另一个实例，让它对着原文逐条核对并输出结论加理由，比同会话自查更敢说真话；自查也不是没用，让它输出前先列「我可能错在哪」，能把粗错拦掉一层。三档组合是常规配置：程序卡硬格式，互查卡内容，自查做预处理。重试也要设上限，同一闸门连续三次不过就落告警转人工，告警信息带上闸门名与失败原因，接手的人不用从头排查。标准要随步骤版本化，步骤改了标准跟着改，不然闸门卡的是过时的要求；重试提示里附上原文相关片段，省得模型凭记忆修正，越修正越偏。

三档执行者各卡一段，成本与可靠性不同。

步骤校验布防表

• 源头步：细查，字段与数值逐项过。
• 中段步：查覆盖与夹带。
• 成稿步：查风格与前后一致。

闸门设在哪里，比闸门设多严更值得先想。

闸门记录也要沉淀：每次通过与否、失败原因、重试次数都落表，攒起来就能看出哪一步最常卡壳，提示优化的优先级自然浮出水面，数据驱动的闸门调优比凭感觉挪闸门可靠。落表字段不用多，时间、步骤、原因三列起步，先跑起来再逐步加；每月回看一次卡壳榜，前两名必处理，榜上有名的步骤先改提示再改标准，顺序别反。

换个问法再问步骤校验三句

• 每一步都人工查太累怎么办？：让模型自查再人工抽查，或用程序校验格式类硬指标。
• 自查和互查哪种更可靠？：换一个会话让另一个实例对着原文查，比同一会话自查更容易发现问题。
• 校验标准要写进提示吗？：要，写成可判定的验收句式，模型才知道往哪个方向自查。

留一个判断给你：先找链路里最贵的错误会发生在哪，闸门就设在它前面。