让验证速度追上生成速度

当产出量超过验证吞吐，只有三个选项：扩验证容量、降 agent 速率、降质量标准，且不能默认发生。

当 agent 的产出量超过你的验证吞吐，只有三个选项：扩验证系统容量、降 agent 产出速率、降质量标准。没有第四个。最危险的是让它默认发生——没人数过吞吐，也没人声明放宽了什么，只是 review 从细看变成扫一眼。

剪刀差已经出现

数据是一致的：Google DORA 研究发现团队采用 AI 越多交付稳定性越降，超过三分之一的开发者对 AI 代码缺乏信任；METR 的对照实验里，资深开源开发者在自家成熟项目上用 AI 辅助反而慢 19%（预期快 25%），额外时间耗在 prompting、等待、读输出和纠正上；百余模型的安全测试显示 AI 生成代码约 45% 引入已知安全缺陷，且模型「让代码跑起来」的能力大幅增长、「让代码安全」的能力基本持平，差距在拉大。bytebytego-verification

原因不是模型不够强，而是成本结构反转：写代码从慢环节变成快环节，验证成为瓶颈。而且 AI 的错误类型——安全缺陷、重复代码——恰好是类型检查和 happy-path 测试的盲区。另一个体量问题：AI 倾向产出更大的 diff，注意力被摊薄，5000 行的 PR 最后换来一句 "looks good to me"。

按反馈时延匹配验证层级

完整链条是静态 → 单元 → 集成 → 运行时 → 基线 → 端到端 → 人工。层数不固定，深度由风险决定：低风险改动跑前两层就够，涉及资金、权限或不可逆副作用的必须走到端到端加人工。

匹配原则是反馈时延决定自主迭代频率：

秒级反馈（编译、类型检查、单测）支撑高频自主迭代。agent 能在一次循环里试错几十次，前提是每次几秒内得到判定。
分钟级反馈（集成测试、契约测试、浏览器自动化）覆盖更真实的行为，代价是迭代频率下降一个量级。
人工判断只留给机器判不了的问题：意图是否合理、取舍是否可接受。把人工放在能自动判定的环节上，是用最贵的资源做最便宜的事。

前移，并检查假修复

Shift Left：同类检查尽量前移。编辑器里或 commit 时发现缺陷，成本远低于 review 时和生产时。能静态查的不要等到运行时，能在 CI 查的不要等到灰度。

同时要防假修复：验证的是根因已消除，不是错误信号消失。agent 在「让测试变绿」这件事上很有创造力，典型手法包括删掉报错的日志、把日志级别从 error 降到 debug、吞掉异常、放宽断言阈值。评审时盯这几类 diff，看到测试断言被改动，先问为什么。

可行动性判据

验证信号只报告开发者能采取行动的问题。一条每次都红、没人知道该改什么的告警等于没有告警，它的真实作用是训练团队忽略这个面板。持续监控误报率并调阈值——高频误报侵蚀信任后，真警告会被一并忽略。

速度、精度、覆盖三者不可兼得，必须显式声明取舍。不要默认全要，那只会导致慢、漏且不被信任的组合。选哪个取决于变更的风险等级：高风险变更放弃速度，探索性原型可以放弃覆盖。

同一套判据也适用于评估集本身，而这里省下的不是精度，是吞吐。OpenAI 整理 SWE-bench Verified 时，从 2294 个原始任务里随机抽出 1699 个，招 93 名精通 Python 的开发者逐条核查五件事：问题描述是否清晰、测试是否覆盖边界条件、测试是否稳定、参考 patch 是否引入新错误、难度是否合理。最终只留下 500 个，被核查的任务淘汰约 71%。高淘汰率同时买到信噪比和预算：评估成本随之下降约 80%。这一项不能忽略——复杂 Agent 任务单条要跑数分钟到数小时，用前沿模型完整跑完一个评估集往往是数千美元量级的 token 费用。ai-agent-book 砍掉判不准的用例，和「review 从细看变成扫一眼」不是一回事：前者改了用例的验收定义并留下记录，后者什么都没改，只是少看了。

验证信号本身也有噪声

两个加固手段：变异测试（生成代码变体跑同一测试套件，测试没红说明测试集漏检）和属性测试（断言不变式而非具体样例）。AI 引入的缺陷常绕开手写样例，靠不变式更容易兜住。

最后是测量本身的可靠性。Anthropic 量化过 agentic coding eval 的基础设施噪声：最宽裕与最严配置之间差 6 个百分点（p<0.01），而 leaderboard 前几名常常只差几个点。资源限制会改变 eval 实际测的东西——紧限制奖励精简策略，宽限制奖励暴力重型策略，混在一个分数里不加区分会掩盖差异。建议同时指定保底分配与硬 kill 阈值两个参数，把资源配置当一等实验变量记录；leaderboard 差距低于 3 个点应持怀疑态度，直到配置被记录并匹配。anthropic-infra-noise

同一把尺子也要拿来量你自己的分差。有限样本上的成功率自带抽样误差，标准误约为 sqrt(p(1-p)/n)：100 个用例、成功率 70% 时，95% 置信区间大约是 70% ± 9 个百分点。所以「新模型 73%、旧模型 70%」根本不足以支持切换——它整段落在噪声里。ai-agent-book

比较两个配置要做配对分析：逐题记录谁胜出，用 McNemar 检验或配对 bootstrap 判定差异，而不是把两个独立测得的成功率相减；配对的意思是两组共享同一批任务和同一批随机条件。由于 Agent 每次运行本身也会变，每个配置至少跑 3–5 个随机种子，报告均值和波动范围，单次运行只够用来筛方向。如果预期收益只有 2–3 个百分点，而评估集只有几十题，正确动作是先扩样本——标准误按 1/sqrt(n) 收缩，靠这点分差跑不出结论。并行验证多个假设时还要防多重比较：收紧显著性阈值，或者对正向结果独立复跑。分差超过噪声、配对分析成立、且能复现，才值得据此换模型或发布改动。ai-agent-book

还有一条容易忘的清理规则：每个强约束都要过双目的检验——同时服务质量与交付流动，两者都不服务的约束应当移除。约束会自己堆积腐化。