一名代码审查 Agent 多报了十个问题，究竟是能力更强，还是给开发者多制造了十次无效打断？10 月 5 日，GitHub 发布开放评测 ReviewBench，把这道产品难题拆成精确率和召回率：既看系统漏掉多少已知问题，也看它新报的问题有多少成立。真正值得注意的不是又多了一个排行榜，而是代码审查终于不再只奖励“找得多”。
ReviewBench 收录 219 个真实公开 PR，来自 187 个开源仓库。GitHub 称，它先分析 1.039 亿个 PR 的语言、仓库规模和改动形态，再据此构造覆盖 19 种已识别语言的评测集。公开清单还保留了一条语言为 unknown 的任务。样本并非对全站 PR 等比例抽样：GitHub 主动减少极小改动，增加更适合完整审查的中大型 PR。换句话说，它代表的是“值得交给审查系统处理的工作”，不是 GitHub 上所有改动的缩影。
固定答案会惩罚真正的新发现
传统做法先列出一组已知缺陷，再检查 Agent 找回了多少。它适合比较召回率，却会制造一个悖论：如果 Agent 找到 golden set 之外的真实 bug，这条发现反而会被当成误报，或者根本不计分。
ReviewBench 先把人工评论、模型审查结果、Copilot code review 和静态分析结果汇总，按“事实正确、与改动相关、值得作者处理”的统一标准标记，再合并指向同一根因的重复发现。候选 Agent 提交结果后，LLM matcher 判断它是否命中已有发现；没有匹配上的新发现，再交给 Claude Sonnet 5 判断真伪。
由此产生两套指标。Grounded precision 和 recall 只计算已知 golden set，便于不同系统使用同一把尺子比较。Augmented precision 则把裁判认可的新发现加入有效结果，同时把裁判否决的新发现计为噪声。Augmented recall 也给新发现加分，但它的分母会随每个 Agent 的新发现变化，因此官方方法文档明确要求：跨系统排名仍以 grounded recall 为主，augmented 指标只作补充诊断。
这个设计把代码审查的真实冲突写进了分数。高召回系统可以多抓问题，却必须为无效评论付出精确率代价；偏保守的系统噪声更低，也会暴露漏报。团队还可按严重度、问题类别和 Fβ 权重重新排序结果，不必假设所有开发流程都需要同一种审查风格。
219 个 PR 更真实，golden set 仍主要由模型发现
公开仓库让这套评测比只发布排行榜更容易审计。每个任务固定 base 和 head commit，候选 Agent 看到的是收到审查反馈前的代码；25 个 PR 的小测试集覆盖 352 条真阳性，完整集则公开全部 219 个任务及 golden 文件。仓库的对齐检查确认测试集包含 36 条高严重度、134 条中严重度和 182 条低严重度发现。
但“多源 golden set”不等于“以人工评论为主”。按 10 月 5 日发布快照逐文件统计，4,632 条已标记发现中有 2,623 条真阳性；其中 1,391 条来自通用 LLM reviewer，1,185 条来自 Copilot code review，人工评论只有 39 条，确定性工具只有 8 条。多源降低了单一系统盲区，却没有让各类来源占据相近权重。
这并不自动削弱数据价值。模型产生的候选问题经过统一规则判断，公开文件还保留问题位置、严重度、类别、来源和判定理由，外部团队能够追查一条发现为何计分。它改变的是正确解读：ReviewBench 测量的是一套经工程师校准、再由模型规模化执行的审查标准，而不是“开发者历史评论的平均意见”。
此前两类基准恰好说明这个选择的取舍。SWE-PRBench 用 350 个 PR 的真实人工评论作为 ground truth，适合研究模型能找回多少人类已指出的问题，却仍要用 LLM judge 完成匹配与判分。c-CRAB 则把人工审查意见转成可执行测试，验证更硬，但天然聚焦能被测试表达的已知问题。ReviewBench 接受模型参与 golden set，换来更广的问题覆盖，并用 augmented 指标容纳超出固定答案的新发现。
96.6% 一致率校准了裁判，没有消除裁判
GitHub 披露，未参与数据集构建的资深工程师重新标注 ground-truth findings，TP/FP 判断与 ReviewBench 的一致率为 96.6%；人工审计还纠正了 47 条被错误标为真阳性的发现。严重度标签在三级尺度上相差不超过一级的比例为 98.7%，但完全一致只有 62.9%；类别完全一致率为 79.7%。这组结果支持 Claude 裁判在“问题是否成立”上较稳定，也暴露严重度与类别本来就更依赖团队口味。
博客称复核覆盖每条 ground-truth finding，但公开材料没有单独列出 96.6% 计算所用的发现数量、逐类分层、混淆矩阵或置信区间。更重要的是，Claude Sonnet 5 同时参与 corpus 分类和未匹配发现的判定，语义匹配也由 LLM 完成。裁判若漏掉一个匹配，grounded 得分会变成 augmented 得分；若它又误判新发现，系统还会多一次错分。GitHub 通过固定版本、公开提示词和人工复核降低漂移，但无法让模型裁判变成客观仪器。
公开完整题库也带来另一层边界：参评者可以在 219 个 PR 上反复调参，最终提交虽然重新运行三轮，却仍面对已知任务。它适合衡量固定工作负载上的工程改进，不足以单独证明系统能泛化到企业私有仓库、团队约定或未来代码。GitHub 既建设基准，也经营 Copilot code review；其“离线变化能预示线上实验”的证据来自自家产品实验。官方给出的一个例子中，离线评测正确预测了精确率、召回率和评论量的变化方向，但完整对应数据并未公开到足以让外部团队独立复算。
团队应该把它当成诊断仪，而不是采购分数
对代码审查团队，最有用的做法不是追逐一个总分，而是先确定能容忍的打扰成本。需要阻止高风险合并时，可提高高严重度问题的召回权重；开发者已被机器人评论淹没时，应优先看 augmented precision、每个 PR 的评论量，以及误报集中在哪些类别。Grounded recall 适合看版本迭代是否漏掉已知问题，novel TP 数量则用来发现系统是否真的越过了旧答案。
ReviewBench 把真实 PR、公开语料和可运行评分管线放到了一起，也把“多报就是更强”的简单叙事拆开了。它下一步真正需要证明的，不是排行榜能否继续扩充，而是同一套裁判在不同模型家族、私有代码与团队审查文化中是否仍然稳定，以及离线分数能否由 GitHub 之外的团队复现为更少漏报和更少噪声。
