正在加载，请稍候
50 个基准 PR 的对照实测：便宜档 0.20 美元找出 69 个缺陷、精度 74%；旗舰档 5.66 美元找出 92 个、精度 96%。分层审查怎么划、门禁阈值怎么设，本文给出四步路由规则。
同一批 50 个公开基准 PR、同一个提示词：便宜档找出 69 个经验证缺陷、精度 74%、总成本 0.20 美元；旗舰档找出 92 个、精度 96%、总成本 5.66 美元。
这组对照实测于 2026 年 9 月 14 日公开。23 个缺陷的差距，由约 28 倍价差换来——对正在给 CI 加审查环节的团队来说，这是一道要当场算清的题。
把价格摊到缺陷上：旗舰档多找出的 23 个缺陷，对应约 5.46 美元的增量支出，单个约 0.24 美元。单看这一项，几乎没有讨论空间。
贵的是另一端。一个漏到生产的缺陷，账上有回滚窗口、热修工时、客户侧影响面三项。若它落在一条支付路径或一次权限校验上，修复代价很容易从一个下午膨胀到一周。
审查算力属于边际开销，漏检属于尾部风险。两类成本必须分开记账，否则永远算不准该把钱压在哪一档。站内此前的 AI 编程真实瓶颈复盘 也指向同一个结论：决定成败的很少是模型单价。
工程侧的支出正在从"能跑就行"变成硬指标。阿里 Qoder Cloud Agents 的发布复盘引用了 LangChain 对 1340 名从业者的调查：89% 的组织已给智能体配上可观测能力，在已经上线的团队里这个比例到 94%。审查流水线同理——一旦进了生产，它就不再是可选项。
全量走便宜档，是把支出压到最低的做法。50 个 PR 花 0.20 美元，折算到每月上千个 PR 的仓库，也就是个位数美元的量级。
代价是 74% 的精度：大约每 3 到 4 条意见里就有 1 条误报。开发者对误报的耐心消耗很快，两周之后就会开始无脑点掉。
旗舰档的 96% 精度意味着约每 25 条才有 1 条误报，但 5.66 美元/50 PR 的单价不适合无差别铺开。
折中做法是把审查拆成两段：第一段用便宜档全量初筛，只输出结构化缺陷与置信度；第二段把高危目录和灰区片段交给旗舰档复核。
按 50 个 PR 里 6 个高危来算，初筛 0.20 美元加复核约 0.68 美元，总花费不到 1 美元，却能覆盖旗舰档 92 个缺陷中的绝大部分。关于智能体会话追踪与成本控制的排查思路给出了同样的判断：把昂贵调用留给真正需要判断力的那一步。
PR 量级被智能体拉高之后，维护期怎么接住这些改动是另一个问题，站内有一篇 388 个 PR 的拆解 可以对照着看。
分层的另一半是门禁。同一套置信度门槛套在所有目录上，结果一定是要么放行太多、要么天天堵车。
建议按目录与风险等级设三档：阻断合入、留评论不阻断、仅写入报告。鉴权、权限、加密、支付、序列化这类安全相关 diff 归入阻断档，且必须由旗舰档确认过才允许通过。
文档、多语言资源、纯样式目录只做记录；业务逻辑目录留评论不阻断，由 code owner 拍板。安全 diff 的分级方式可以参照站内 开源合规的三条审查线 里的做法。
下面这张预算表可以直接照抄，按自己仓库的 PR 体量调整比例即可：
| PR 分档 | 典型特征 | 便宜档比例 | 旗舰档比例 | 单 PR 成本上限 | 误报容忍线 |
|---|---|---|---|---|---|
| 低 | < 50 行，文档 / 样式 / 测试 | 100% | 0% | 0.005 美元 | 仅记录，不阻断 |
| 中 | 50–300 行，业务逻辑 | 100% 初筛 | ≤ 10% 灰区片段 | 0.02 美元 | ≤ 30%，评论不阻断 |
| 高 | 鉴权 / 支付 / 并发 / 序列化 | 100% 初筛 | 100% 复核 | 0.15 美元 | ≤ 5%，命中即阻断 |
| 超大体量 | > 800 行或跨 20 个文件 | 拆分后按中档处理 | 按子块判定 | 0.30 美元 | ≤ 5%，拆分后重跑 |
教训一：全量上旗舰档，支出会跟着 PR 数一起涨。按 5.66 美元 / 50 个 PR 折算，月均 1200 个 PR 的仓库，仅审查一项每月约 136 美元。
这个绝对额不算高，但它是线性的：PR 数翻倍支出翻倍，而收益在高危目录之外递减得很快。更常见的结局是团队发现这笔钱换不来更快的反馈，于是把阻断全改成评论，审查环节名存实亡。所以预算表里那列"单 PR 成本上限"要当真。
教训二：全量走便宜档，漏掉的往往是安全类缺陷。74% 精度下的漏检并不随机分布，它集中在跨文件的鉴权与并发语义上——单看一个文件无害，几处改动叠起来才成问题。
这类判断依赖跨文件推理，低价档在长上下文上的判定衰减最明显。把安全相关 diff 排除在复核范围之外，等于把最贵的那类缺陷留在门外。
顺带一个 2026 年的旁证：GitHub 工程师在 2026 年 9 月 17 日发布的复盘里提到，用智能体在约 14.5 周内把运行时重写为 832,378 行 Rust，分 128 个 PR 增量合入主干，文中专门留了一节讲大规模代码审查。当生成速度被智能体拉高一个量级，审查就是新的瓶颈。全自动化的边界在哪里，站内 全自动工厂的 5 个工程教训 里有更细的账；把这笔账算成趋势的，则可以看 AIcoding 进入「算总账」阶段 那篇。
能用，但通常不划算。生成阶段吃长上下文与工具调用，审查阶段要的是稳定判定和低误报，两者对模型的要求并不重合。把生成用的高配额度优先留给高危 diff 复核，单位成本更低。
拆成两个独立 job。job A 用便宜档跑全量、产出结构化报告，必须跑完；job B 只消费报告里标记为需升级的片段。两个 job 各自设 token 上限与超时，避免复核阶段把流水线拖到几十分钟。
盯两个指标：漏到生产的缺陷数除以审查总支出，以及阻断意见里的真阳性率。按季度看趋势，别用"提了多少条意见"当成绩。
会，尤其在同一个文件上连续误报三次之后。这也正是分层的目的：让低精度那一档只负责提示风险，把"是否阻断"的判断权交给高精度那一档。
如果你们正在为审查预算做取舍，可以带着过去两个季度的生产缺陷数与 CI 里的审查支出，走 联系我们 做一次半小时的成本盘点；同类评审流水线的改造记录整理在 案例库。