为什么我用便宜的模型来做审核

一般的认知里，拆解任务应该用高级模型，执行任务用低一级的，而审核必须是高级模型。

而我目前常用的组合：

• 拆解任务：opus-5.5-high
• 执行任务：opus-5.5-medium
• 审核：gpt-6.1-sol-high

大部分人第一眼就会说：你让 gpt-6.1-sol 这个高中生来审核研究生 opus-5.5 的作业？你扯淡呢！

但是从我两千多个任务的实践数据看，如果搭配适当的硬门禁、Skill 和 prompt：高级模型拆解任务、高级模型执行、低一级的模型审核，是更有性价比的组合。

我这里不是说高级模型审核不行，而是强调性价比。但前提是任务成功率和质量必须保证，否则省钱就没有了意义。

数据来源：任务编排工具 Kander

大卡是指模型判定为难度较大或风险较高（跨模块、改协议等）的任务卡，其余为小卡。

下面是 Kander 统计的实际数据（截至 2026-10-29）。

执行：任务卡被审核打回的情况

打回指一轮审核发现了必须处理的问题；大卡占比越高，任务整体越难。

审核：各审核模型的表现

可以看出，gpt-6-astra 发现必修问题的概率最高，必修问题被驳回的比例最低。

但有个问题是 gpt-6-astra 做审核时，规则和后来用 gpt-6.1-sol 不同，所以数据只能大致参考。

按 OpenAI 官方 API 定价，gpt-6-astra 的单价是 gpt-6.1-sol 的 5 倍。 第三方测评中，同一任务的实际花费约为 4.5 倍。 性价比差距还是很明显的。

上述任务数据中，超过 1900 个来自 https://quicktui.ai/ 这个商业产品。

~

为什么任务没做好

首先，假如没有审核环节，任务跑偏主要出在两个环节：

• 计划
• 执行

第一步模型根据需求创建执行计划时，就可能已经跑偏了。最常见的两个原因：

• 需求的细节不明确
• 需求过于复杂

~

如何获得清晰的执行目标

需求的细节不明确很容易理解，因为我们在描述需求时，通常都是一个抽象描述，不可能所有细节都考虑到。而这些模糊地带如果在计划里没有明确，那么模型在执行时就可能按照训练数据执行，而出来的结果就有可能与预期不符。

所以在讨论需求时，应该用高级模型，并且使用适当的提示词，让模型能够从接近计划落地的角度去提出问题，并要求我们确认。以前很火的 superpowers skill 其实就是用来解决这个问题，要求模型不断追问，直到对需求没有疑问。

现在随着模型能力发展，很多 skill 的能力已经内置在模型或者 Agent Harness 中了，我们可以充分利用起来。

比如在 Codex 中讨论需求，我都会开启 plan 模式。这个模式下，gpt-6-astra 会提出更多问题，很多时候也是督促我进行思考。

如果用 fable-5.1 或者 opus-5.5，我通常会加一句 prompt：将任务目标和我沟通清楚，确定目标的细节和验收标准。

通常和模型沟通几轮后，双方都对目标和计划有了明确的认知。这时候，就可以开始创建计划了。

~

拆解复杂的任务

有时候，我们的需求过于复杂，如果用单个任务来完成，那么会话上下文就会变得很大，中途可能多次触发自动压缩。要知道压缩上下文必然是有损的，这也会损害任务执行的质量。而且过于复杂的任务，在审核时也更困难。最好的选择还是将复杂任务拆解为一系列更简单的任务。

但拆解也是有规则的。基本原则应该是：

• 每个任务应该都是单一的目标。
• “目标”是指用户能单独验收的结果。

用一个真实任务来讲：

QuickTUI 是一个手机远程控制电脑里 Agent 的工具，其中 App 提供了一个快捷工具栏。工具栏上有两个工具，分别叫快速回答和 D-Pad。快速回答就是展示五个按钮，对应数字 1 到 5，选择后就给 Agent 发送具体数字和回车；而 D-Pad 则是九宫格面板，上面提供了四个方向键和两三个常用键。

由于这两个功能是不同时期加入的，用了各自的实现。现在为了统一风格和操作体验，需要重构为一个基础的浮动层组件，然后再派生出两个组件。

对于这个任务，其实就有三个目标：

• 一个公共的浮动层组件，就算内容为空也是可以单独验收的。比如可以拖动、可以锁定等等。
• 基于浮动层组件的快速回答组件。
• 基于浮动层组件的 D-Pad 组件。

最终这个任务被拆分为了三个子任务，形成了一个任务组。

本质上这和人类解决问题的思路一致：将复杂的任务拆分为更简单更容易完成的任务。

不管用什么能力的模型，这一步都是任务成功率和质量的前提。这个环节用高级模型，是最有价值的。

~

创建可验收的计划

有各种各样的 skill 可以帮助我们创建执行计划，比如 superpowers 里就用 spec + plan 的文件组合。 但从现在看，superpowers 这一套实在有点过于繁重，可以考虑使用一个简化的任务文件模板，让 Agent 填写。

## 目标

任务目标的概述。

## 预期的成果

任务应该达成的结果：

- 结果 1
- 结果 2

## 验收标准

[ ] 验收条目 1
[ ] 验收条目 2
[ ] 验收条目 3

## 任务执行

这个模板很简单，但最重要的就是【验收标准】这一部分。

这里每一个条目，都应该是单一可验证的。只要整组条目都验收通过，那么任务的质量就有了基本的保障。

下面是刚刚提到那个真实需求的其中一个任务验收清单：

[ ]  client/protocol/ui-flow-design-tokens.yml  有 token  shortcutPickerPanel , 暗色  rgba(35,41,35,0.4) , 亮色 rgba(255,255,255,0.4) 。
...
...
[ ]  client/protocol/ui-flow-terminal.yml  用一个通用 renderer 描述两个 picker。
[ ]  client/protocol/ui-flow-terminal.yml  写明三种布局、网格空位、panel 背景、入场顺序与 300 ms 总时长规则。
[ ] iOS 与 Android 上, d-pad 打开时按键依次跳出, 不再整体缩放。
[ ] iOS 与 Android 上, 未锁定时点 d-pad 的按键, 被点按键的弹跳可见。
[ ] iOS 与 Android 上, 未锁定时点背景空白处或网格空位, panel 不关闭, 也不发送。

这里我只摘录了几条，第一条是机械验收，理论上用脚本就可以判断。而后面几条虽然需要读代码来判断，但涉及的代码范围也极小，没有复杂逻辑。

上面的验收条目看上去较多，但每一个条目的验收标准都非常明确，要么通过要么不通过。

正是这种简单清晰的验收清单，让我选择 gpt-6.1-sol 来审核。从实践结果看，成功率和质量也是完全可以接受的。

~

避免执行跑偏

虽然一般认知里，执行任务的模型可以低一级，毕竟都有文档和验收标准了嘛，总能大差不差。

但是从实践看，低一级模型最大的问题就是跑偏和错漏：

• 原本的目标是 A，结果跑成了 A- 或者 A+
• 原本的目标有 A1、A2、A3，结果只做了 A1 和 A3

虽然这些问题在后面的审核阶段都能发现，然后要求执行 Agent 返工。但是从我大量实践看，这会导致任务循环次数和耗时显著增加。

文章最前面的数据也可以看出，使用 deepseek，swe-2 等模型执行的任务卡，平均打回次数是 1.00+，远超 opus-5.5 的 0.78。gpt-5.6-sol 平均打回 0.84 次，和 opus-5.5 差距不大，但 72% 的卡至少被打回一次，而 opus-5.5 只有 61%。

从数据看，更理想的选择是用高级模型做执行，降低跑偏和错漏的概率。

~

如何审核？

前面说了用高级模型来执行，但目前最高级的模型也会跑偏和错漏，因此审核阶段必不可少。

那么如何审核呢？

有一种不推荐的做法，就是在任务执行的会话里，让 Agent 对任务进行审核。执行任务的会话里做审核，只适合机械检查。具体内容可以参考这篇文档：Give Claude a check to run。

而需要判断的审核，一定要开一个新的会话来做。至于这个会话是单独的 Agent 还是 Sub-Agent，并不重要。

开了新会话后，只能把任务文档里关于目标和验收的部分告知新会话，然后指定要审核什么位置的代码（通常是 git commit）。这里绝对不要把任务执行过程相关的内容发到新会话中，否则依然会污染上下文。

还是回到前文的真实任务验收清单：明确的验收标准，是用低一级模型做审核的前提条件。

如果没有验收清单，那么用 gpt-6.1-sol 去审核 opus-5.5 的成果，可能就会出现下面的情况：

• 不认同 opus-5.5 的产出，即便产出原本是正确的
• 发现不了执行中错过的任务内容和跑偏的细节

用低一级模型审核高级模型的产出，不是不可行，而是要有硬性的标准。

用高级模型审核，除了成本因素，还有一个问题就是高级模型更容易追究边界条件。这一点在 gpt-6-astra 上特别明显。所以只要我们能够用硬性约束保证任务交付质量可以接受，那么选择低一级的模型不但能带来显著的成本优势，还能加快任务交付。

~

审核闭环

审核有了结果，然后呢？

这时候就应该把结果返回给执行 Agent，让执行 Agent 做以下事情：

• 确认反馈的问题确实存在，并且应该处理
• 修复发现的问题

这里有一个关键步骤：确认反馈的问题确实存在，并且应该处理。

如果执行阶段是低一级的模型，有可能无脑就认同了，或者给出错误的决策，而高级模型在这个步骤犯错的几率更小。

从 Kander 项目收集的实际数据看，审核意见有 6.2% 被驳回，15.5% 被延后（延后的都是非阻塞建议），执行模型必须有能力进行判定，哪些必须修、哪些不用处理。这也是我认为执行阶段应该用高级模型的原因。

如果不做这一步，那么就会出现一种情况：

• 审核发现一个本不用处理或者根本就是不存在的问题
• 执行立刻开始修
• 修完再审又发现问题，又修

这个问题在用 gpt-6-astra 做审核时尤其明显。从数据看 gpt-6-astra 每次审核反馈 1.69 个必修问题，而 gpt-6.1-sol 反馈 1.09 个，原因主要还是 gpt-6-astra 会找出更多极端的边界情况。

但要注意，即便是 opus-5.5，也有 61% 的任务卡至少被打回一次。所以审核这个环节必不可少。

~

回到小标题：审核闭环

一个任务从拆解到最后交付，过程是：

拆解任务 --> 执行任务 --> 审核 --> 交付
               ^            |
               |            |
               +- 发现问题 -+

执行和审核的循环，我称之为审核闭环。

能够通过审核闭环的任务，至少证明任务文档中列出的所有验收标准都已经通过，有了基本的质量保证。

~

完整的编排系统

一个完整的编排系统，涉及很多环节：

• 适当的 skill 和 prompt
• 任务模板
• 任务报告模板
• 控制任务执行流程的脚本

一篇文章没法全部讲完，感兴趣的朋友可以看看：任务编排工具 Kander

回到文章最开头的论点：只要有适当的工具，低一级模型做审核是更有性价比的选择。