AI Code Review 的质量，不能靠评论数量衡量

给一个 Pull Request（PR，代码合并请求）开启 AI Code Review，很快就能收到一批审查意见。

有的指出潜在的空指针、权限漏洞和异常处理问题；有的建议修改变量命名、调整代码风格、补充注释。如果模型足够积极，一次审查可能生成十几条甚至几十条评论。

但评论多，真的代表审查质量高吗？

假设两个 AI Reviewer 审查同一个 PR。第一个只发现了两处问题，其中一处可能导致严重的数据错误；第二个提出了十条建议，却大多涉及命名和代码风格。

站在研发团队的角度，第一个工具可能更有价值。毕竟，每条评论都需要开发者阅读、判断，有时还要修改代码。

还有一种更有意思的情况：如果 AI 发现了一处真实缺陷，但评测标准答案里没有记录，这条发现应该算对还是算错？

最近，GitHub 发布了 ReviewBench：一个面向 AI Code Review Agent 的开放评测基准，尝试回答这些问题。

我觉得这项工作值得关注。随着 AI 逐渐参与代码审查，团队需要知道工具究竟发现了多少真实问题、遗漏了哪些重要缺陷，又制造了多少额外工作。

而要回答这些问题，首先得有一套可靠的评测方法。

评价一个 Coding Agent 的代码修改能力，可以准备一组任务，让 Agent 修改代码，再通过测试和其他验证手段检查结果。

Code Review 的评测则更复杂。

假设一个 PR 中有三处已知缺陷，我们把它们作为标准答案，让不同 AI Reviewer 分别审查。

Reviewer A 找到了其中两处，Reviewer B 找到了全部三处。按照已知缺陷的覆盖情况，B 显然更好。

但如果 A 还额外发现了一处真实的权限漏洞，而这处问题并未记录在标准答案里呢？

如果严格依赖固定答案，A 的新发现可能被当成误报。

这里暴露出代码审查评测的一个困难：我们很难提前穷尽一份代码里所有值得指出的问题。

真实的人工 Code Review 也是如此。不同审查者会关注不同类型的问题，有人擅长发现逻辑错误，有人熟悉安全风险，还有人特别关注系统的异常处理和可维护性。

因此，一套好的评测机制需要同时解决两个问题：尽可能准确地建立已知缺陷集合，也要允许 Reviewer 发现集合之外的真实问题。

ReviewBench 的设计正是围绕这两件事展开的。

首先是评测样本。

GitHub 分析了约 1.039 亿个 PR 的分布特征，包括编程语言、仓库规模和代码修改量。在此基础上，从 187 个公开仓库中选取了 219 个真实 PR，覆盖 19 种编程语言。

这里有一个设计细节：GitHub 没有完全按照平台上 PR 的大小比例采样，而是适当提高了中大型修改的权重，避免大量只有少量代码变化的 PR 主导评测。

这使得 ReviewBench 更适合观察复杂代码审查的能力，但也意味着它并不完全等同于 GitHub 上的真实 PR 分布。

更关键的是，GitHub 怎么知道这些 PR 里究竟有哪些问题？

如果只依靠原始 PR 中的人工评论，可能遗漏许多当时没有被发现的缺陷。只依靠某个大模型生成标准答案，同样存在模型自身的能力盲区。

因此，GitHub 从多个来源收集候选问题：

收集之后，还要做语义去重。

例如，人工 Reviewer 和静态分析工具都指出同一个空指针风险，不能因为两者使用了不同描述，就把它算成两个问题。

随后，GitHub 使用统一的评判规则检查候选问题是否真实、相关且具有实际意义，并采用 Claude Sonnet 5 作为评判模型。

最终，这些发现形成了一组可用于评测的标准答案，也就是 Ground Truth（真实问题的评估依据）。

这套数据和对应的评测实现已经放在 ReviewBench 开源仓库中，包括 PR 样本、问题标注、评判规则和相关代码。

不过，模型参与构建标准答案，又带来一个问题：怎么证明评判模型本身可靠？

GitHub 邀请未参与数据集建设的资深工程师，对标准答案中的问题重新进行独立判断。人工判断与原有标注的一致率为 96.6%。

这个数字说明，在这组已标注问题上，两者具有较高的一致性。它不能证明标准答案已经覆盖全部真实缺陷，也不能被理解为 AI Code Review 工具的准确率。

我觉得这里最值得借鉴的，是 GitHub 没有直接拿一个模型的输出当作最终答案，而是通过多来源收集、统一评判和人工复核，尽量降低单一信息源带来的偏差。

有了标准答案，接下来就可以评估 Reviewer 的表现了。

通常我们会关注两个指标。

Precision（精确率）衡量 AI 提出的审查意见中，有多少被认定为有效。Recall（召回率）衡量已知的有效问题中，有多少被 AI 找到了。

如果一个工具几乎不发表意见，它可能误报很少，但也容易漏掉重要缺陷；如果一个工具对所有可疑代码都发表意见，它可能覆盖更多问题，却会产生大量噪声。

ReviewBench 设计了两组指标，分别称为 Grounded 和 Augmented。每组都包含 Precision、Recall 和 F1，F1 用于综合衡量精确率和召回率。

为了说明它们的区别，我们看一个简化的例子。

假设一个 PR 已知有两处缺陷，而 AI Reviewer 提出了三条意见：

如果按照 Grounded 指标评估，只有 A 命中了已有标准答案。B 虽然是有效问题，但没有匹配到标准答案，仍会影响精确率的计算。

Augmented 指标则会进一步判断未匹配的 B 和 C 是否真实有效。如果评判模型确认 B 是有效缺陷，就可以给予这条新发现相应的认可，而 C 仍被视为无效评论。

这样一来，AI 的额外发现就不会因为标准答案不完整而被一律当作错误。

这是 ReviewBench 很有价值的一处设计。

不过，也不能因此简单认为 Augmented 的分数一定更适合比较不同工具。

特别是 Augmented Recall：由于每个 Reviewer 可能发现不同的新问题，它参与计算的问题总数也会变化。因此，GitHub 仍然把 Grounded Recall 作为跨系统比较的主要指标，Augmented 指标更多用于补充分析单个系统的表现。

完整的指标定义和评测方式可以查看 ReviewBench 的公开实现与文档。

这种设计体现了一种值得关注的取舍：固定标准答案让不同工具能够公平比较，扩展判断则让评测有机会识别此前未知的有效问题。

两者都需要保留。

当然，Augmented 的新发现仍由模型参与判断，并不能保证每个新发现都是真正成立的缺陷。所以评判规则、人工校准以及对新增问题的抽查，仍然是这套方法的重要组成部分。

评测基准设计得再好，也要面对一个问题：在 Benchmark 上取得更好的分数，能不能带来实际的研发收益？

GitHub 在官方文章的线上实验部分介绍了一次 Copilot Code Review 的改进实验。

这次改动采用多模型组合审查，让多个模型分别分析代码，然后汇总结果，而非只依赖一次模型执行。

ReviewBench 的离线结果预测，这种方案可以提高精确率和召回率，发现更多问题，同时降低单次审查成本。

GitHub 随后进行了线上 A/B 实验。相对生产环境中的对照组，观察到以下结果：

此外，离线评测预测，Critical 级别的严重问题评论数量将增加 227%，线上观察到的增幅为 262%。

从这些数字看，离线评测与线上实验呈现了相同方向的变化。这说明 ReviewBench 至少在这次实验中，对产品改动提供了有价值的提前判断。

但具体指标仍要谨慎理解。

例如，GitHub 所说的评论处理率，是使用模型结合代码 Diff、评论讨论、解决状态和后续代码，判断一条 AI 评论是否促使开发者修改了代码。

它是一个有参考价值的线上信号，但无法证明每一条被处理的评论都对应真实缺陷，也不能直接当成缺陷修复成功率。

线上召回指标也有自己的衡量方式，涉及 AI 审查之后还需要多少额外的人工审查，不能简单等同于离线基准中的 Grounded Recall。

同样，评论数量增加 61%，也不代表真实缺陷增加了 61%。Critical 评论增多，还需要结合发现的实际有效性来评价。

所以我觉得，ReviewBench 的意义不在于一次实验中某个指标提高了多少，而在于 GitHub 建立了一个可以持续使用的反馈过程。

模型或审查策略发生变化，可以先在统一基准上检查缺陷发现率、误报和成本，再进入真实研发流程，通过线上反馈判断是否真的改善了使用效果。

离线评测帮助筛选值得尝试的方案，线上实验负责检验这些判断。两者之间仍可能存在差异，也需要不断校准。

读完 ReviewBench，我想到一个很实际的问题。

现在接入 AI Code Review 并不困难。无论是直接使用现成工具，还是在 CI 中运行 Coding Agent，都可以相对容易地生成代码审查意见。

但工具运行了多少次、发出多少评论、消耗多少 Token，这些数据很容易统计。真正难的是证明审查有没有帮助团队改善代码质量。

如果让一个团队开始建立 AI Code Review 的评估机制，我倾向于先做一套小规模、可持续维护的验证方法。

首先，从真实历史 PR 建立评测样本。

不用一开始就准备几百个案例。可以先选取几十个具有代表性的历史 PR，覆盖常见业务逻辑、异常处理、权限检查、数据修改等类型。

结合历史人工 Review、后续缺陷修复和测试结果，整理一组经过确认的问题。对于一时无法确定的问题，保留待复核状态，不必强行标注正确或错误。

然后让 AI Reviewer 在这些 PR 上重新审查，看看它能够找到多少已知问题，还产生了哪些新的发现。

这里可以直接借鉴 ReviewBench 的思路：已知问题用于稳定比较，新发现则单独评判，避免因为标准答案不完整而低估工具的能力。

其次，把发现能力和审查噪声分开看。

不要只统计评论数量，至少需要知道哪些评论是真实有效的、哪些属于误报、哪些重要缺陷被遗漏了。

还可以根据问题严重程度进行区分。一条会造成权限绕过的有效评论，与一条可有可无的命名建议，对工程质量的价值显然不同。

如果一个 Reviewer 总是生成大量低价值评论，即使召回率有所提高，也可能不适合直接接入高频开发流程。

最后，用真实研发反馈持续校准。

历史 PR 可以帮助快速比较不同方案，但真实上线后，仍然需要观察开发者如何处理建议、被确认的问题是否修复、审查等待和人工判断成本有没有变化。

对于风险较高的模块，还应该关注某些关键类型的缺陷是否持续遗漏。

这套机制没有必要一开始就建设得很复杂。先有一小批可信样本，能够稳定对比不同版本的 Reviewer，再逐步积累真实使用反馈，比只依靠工具自身的成功率或评论数做判断更可靠。

当然，GitHub 的 ReviewBench 也有边界。

219 个开源 PR 不可能覆盖所有企业内部代码和业务规则，公开的数据集与评判方式也可能被特定工具针对性优化。模型参与构建和评判标准答案，始终存在判断偏差。

这也是为什么团队自己的业务代码、历史缺陷和实际使用反馈仍然有价值。

随着 Coding Agent 承担越来越多代码生成和修改工作，AI Code Review 的重要性也会提高。团队需要更加认真地回答：它到底帮我们发现了什么？漏掉了什么？为了发现这些问题，又增加了多少额外的审查工作？

我认为 ReviewBench 提供了一个不错的研究起点。它让 AI Code Review 的评估从简单统计评论数量，进一步覆盖真实缺陷、误报、严重程度和实际使用反馈。

对研发团队来说，最值得投入的，是建立一套可以持续验证审查质量、发现能力短板并指导工具改进的方法。

当 AI Reviewer 发生变化时，我们至少能够拿出证据，判断它究竟变好了多少，又在哪些地方退步了。