GitHub 发布代码审查 AI Agent 评测基准 ReviewBench

代理式代码审查正在成为开发流程中不可或缺的一环。它帮助你检查 Pull Request、发现问题、在代码合并前判断哪些问题值得注意。

但现有 AI 审查工具的质量很难衡量，你需要先了解一个审查工具的优势，才能判断它是否对你有帮助。有的审查工具发现的问题更多，有的产生的噪音更少，有的更擅长捕获关键问题，而有的则侧重于发现较小的改进。在不同的工作流中，你可能需要代码审查承担不同的职责。

因此，理解各审查工具的实际差异非常重要：它们分别能发现什么、遗漏什么，以及它们做出了怎样的权衡。一个好的代码审查基准应该反映真实 Pull Request 的多样性，覆盖广泛的审查发现，并支持按严重程度、类别和精确率-召回率偏好进行有意义的拆分。对于正在构建代码审查代理的团队，基准还应提供一个离线信号，可靠地追踪某项改动是否可能改善生产环境中的体验。现有基准往往在标签质量、覆盖率和对真实代码审查的代表程度之间做出取舍，这留下了一个空白——需要一种将以上要素整合在一起的严格且可复现的评估方法。

我们构建了 ReviewBench，这是一个新的代码审查离线基准，用于弥合上述空白，现在已经可供使用。它以 GitHub 上超过 1 亿个真实 Pull Request 为建模基础，在语言、仓库规模和规模分布上与 Pull Request 保持一致。它使用多来源黄金集和一致的评估规则，并经由资深工程师独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot 代码审查（CCR）的离线评估在预测生产实验方向上变得更加有效，这让我们更有信心相信，测得的改进确实反映了对用户有意义的收益。

在这篇文章中，我们将介绍 ReviewBench 是如何构建的、如何建立可靠的真实标签和评分体系，以及如何接入你自己的代码审查系统并提交结果。

AI 代码审查代理的真实感、综合性的基准

按语言、仓库规模和变更形态分析分布。

有代表性的基准语料库

来自 19 种语言的 219 个公开 Pull Request，与 GitHub 全局分布对齐，同时保留实质性审查案例。

多来源黄金集

每项发现都标注了严重程度和类别，支持用户自定义切片。

四项指标衡量已知和新发现的问题

客观衡量改进效果并在各代理之间比较，帮助用户选择最适合自身需求的审查工具。

如何保证可信度

从规则到专家验证和生产检查的完整可审计链条。

一套适用于所有发现物的明确标准

由资深工程师建立真实标签的人工标注开发集，与人类判断对齐，所有来源采用相同标准，专家审计基准质量，发布前由资深工程师独立标注黄金真阳性。

能预测生产效果的离线信号

基准变动会对照在线实验进行检验，改进往往也会在线上显现，退化同样往往也会在线上显现。

ReviewBench 的工作原理

我们的基准围绕五个原则构建：

1. 有代表性的 Pull Request，而非演示集

我们分析了 1.039 亿个 GitHub Pull Request，以刻画真实世界代码审查工作负载的分布。ReviewBench 包含来自 187 个公共开源许可仓库的 219 个 Pull Request，涵盖 19 种语言，其语言和仓库规模分布与 GitHub 总体高度吻合。完整基准数据集公开可用。

我们对这一分布做了一项有意的调整：虽然语言和仓库规模直接反映 GitHub 的分布，但 Pull Request 规模向可审查的中等规模和尾部倾斜。这减少了对微小单文件变更的过度代表，同时保留了更有实质性意义的多文件 Pull Request——正是这些场景中审查质量最为关键。

快速语料库快照：

2. 广泛的真实标签发现，由独立判断

无论是人类还是模型，没有任何单一审查者能够识别 Pull Request 中所有值得发现的问题。为了构建更广泛、更可靠的黄金集真实标签发现，我们遵循三阶段流程：

收集来自分来源的候选发现。 我们从真实的人类审查者、从作者后续提交中推断的问题、确定性分析工具以及多个前沿 LLM（跨模型家族）中收集发现。

语义去重重叠的发现。 我们合并识别相同底层问题的发现，在不因生产者之间的一致性而人为膨胀黄金集、也不依赖任何单一来源的盲点的情况下扩大覆盖范围。

在共享规则下验证发现。 发现的来源并不决定其是否正确：一项发现只有当它是真实的、相关的且非琐碎的，才算作真阳性。我们使用 Claude Sonnet 5 作为 LLM 评判器，对所有提交应用一致的评估规则。为保证透明度和可复现性，我们发布了评估规则以及用于执行评判的评判器。

3. 衡量已知和新发现问题的指标

大多数基准仅针对固定黄金集报告精确率和召回率。ReviewBench 报告两类共六个指标：

Grounded 精确率、召回率和 F1 分数 仅使用现有黄金集标签。它们提供了严格的同类对比：对于我们已经知道的问题，代理找到了多少？它的发现中有多少比例与已知问题匹配？

Augmented 精确率、召回率和 F1 分数 还评估与黄金集中任何内容都不匹配的发现。评判器独立判断那些不匹配的发现是真阳性还是假阳性，允许审查者因发现黄金集中没有任何生产者提出的有效问题而获得认可。

这一区别在审查代理变得更能干时变得更加重要。固定黄金集不可避免地会变得不完整，因为系统会发现其创建者未曾预料到的问题。Augmented 指标让 ReviewBench 能够认可这种行为，而不是自动惩罚它。由于 augmented 召回率根据每个代理发现的内容扩展了分母，我们使用 grounded 召回率作为跨系统比较的主要指标，而将 augmented 指标作为每个系统的附加诊断。

4. 可配置的评估以适应不同审查偏好

不存在单一普遍最优的审查体验。有些开发者可能只想关注关键问题，而有些则也看重低严重程度、非阻塞性的发现。有些偏好更广泛的覆盖，而有些则优先考虑精确率和最低噪音。还有些可能有特殊需求，例如专注于安全或隐私的审查。

ReviewBench 允许按严重程度和类别对结果进行切片，而精确率和召回率则捕捉不同的操作偏好。用户还可以调整 Fβ 分数中的 β 值，以更看重召回率（更广泛覆盖）或精确率（更低噪音）。随着这些偏好的变化，排行榜会相应重新排名，帮助用户识别最符合其审查优先级的系统。

5. 内部审计且可复现评估

发布前，我们请未参与基准数据集构建的资深工程师从头独立重新标注每个真实标签发现。他们的真/假阳性判断与 ReviewBench 的一致性达到了 96.6%。我们对每次评估中使用的基准数据集、评判器和匹配器进行版本管理，因此可以在相同的基准配置下比较结果，并在基准变化时重新验证。我们还发布了验证方法、一致性测量和已知的有效性威胁，因此读者可以看到基准质量是如何评估的，以及不确定性在哪里。

ReviewBench 的研究预览版现已通过 ReviewBench 网站提供，你可以探索完整基准、比较代码审查代理，并引入你自己的代理进行评估和迭代。

借助 ReviewBench，你可以：

探索完整基准数据集。 完整的 ReviewBench 数据集公开可用，包括 Pull Request、发现、标签、严重程度和类别注释。这允许你精确检查系统评估的内容，并复现基准结果。

在排行榜上比较系统。 使用完整基准数据评估代码审查代理的结果发布在公共排行榜上，提供整体性能、按严重程度、按类别以及不同精确率-召回率偏好的视图。

引入你自己的代理并迭代优化。 完整基准数据集、评估方法、LLM 评判器提示词、评判器模型配置和自助运行器均公开可用，因此你可以评估你自己的代码审查代理、检查其优势和差距，并针对相同基准配置进行迭代。

我们如何使用 ReviewBench

我们使用 ReviewBench 来评估 Copilot 代码审查（CCR）在多次迭代中的表现，这为我们提供了衡量进展、发现退化并优先考虑有前景改动的一致方法。随着时间的推移，这帮助我们改进了产品。ReviewBench 最有价值的优势之一是，它能在产品改动投入生产之前提供一个早期的离线信号，预测该改动在生产中的表现如何。在使用 ReviewBench 进行 A/B 测试之前的实验中，离线变动始终与后来在生产中看到的方向一致。

最近的一个 lite 层实验提供了一个具体例子，说明了这种更广泛模式。 我们引入了一种多模型集成审查，将几个独立的模型运行组合成一次审查，而不是依赖单次运行。ReviewBench 预测这将带来更高的精确率、召回率和评论量，同时降低每次审查的成本。

为了比较离线和生产结果，我们使用对应的在线信号。已处理率（addressed rate）是我们用于精确率对应的在线指标，即 CCR 评论中 LLM 判断促使开发者做出相应代码更改的百分比，判断依据包括 diff、对话线程、反应、解决状态和审查后的代码。对于召回率，我们衡量仍然需要多少额外的人工审查。

在线 A/B 测试的变动方向与 ReviewBench 预测一致：已处理率（精确率）上升了 8.0%，召回率上升了 13.6%，评论量上升了 61%，而每次审查的成本下降了 8.0%，均相对于生产对照组。

然而，仅凭评论量并不能反映评论质量。更多关键发现与低严重程度的 nit 意味着截然不同的东西。ReviewBench 的严重程度级别评估也捕捉到了这一点：它预测关键评论增加 227%，而线上实际为 262%，以及同样的更广泛转变——更多中等评论和更少 nit 评论。

这为我们提供了在运行生产实验之前快速且可重复的信号。在线实验仍然是衡量用户影响的最终标准，但 ReviewBench 让我们更有信心确定哪些改动值得在那里进行测试。

如何提交你自己的运行

在 ReviewBench 网站上使用 GitHub 登录。

注册你的代理。 提供容器镜像、你的配置和你自己的模型密钥。我们提供评判器。

在测试集上尝试。 针对包含 25 个 PR 的测试集运行，获取每个 PR 的详细结果，并在调整配置时重复运行。

执行最终运行。 准备好后，运行完整的 219 个 Pull Request（三个轮次），由与其他所有提交相同的评判器评分。

发布到排行榜。 你的分数在维护者审核并批准提交之前保持私密。只有当分数超过代理当前的排行榜分数，或者这是该代理首次进入排行榜时，分数才会发布到排行榜。

我们邀请你探索 ReviewBench、评估你自己的系统、挑战我们的假设，并帮助我们改进基准。我们很高兴与研究者和实践者合作，使代码审查评估更加开放、可靠和有用——并最终推动 AI 代码审查向前发展。

ReviewBench 是 GitHub 和 Microsoft 团队的共同努力。我们感谢构建它的研究者和工程师：设计方法论的人、整理 Pull Request 的人、构建黄金集和评估管道的人，以及让任何人都能运行基准的人。

Michelle 开发和评估代码审查的代理式 AI 系统，专注于仓库级上下文检索、审查和修复质量，以及 AI 代码审查器的严格基准测试。

Alejandro 的工作专注于评估编码代理、改进它们推理代码变更和仓库上下文的方式，以及优化模型质量、覆盖范围、延迟和 token 成本。

AI 正在改变开发者的工作方式。以下是三项值得强化的技能。

学会引导 AI 代理、批判性地审查它们的输出，并将技术判断保持在工作流的中心。

GitHub Copilot 初学者应用：如何使用画布构建自定义工作流

用简单的英语描述你需要的界面，然后让代理构建一个你们都可以使用和更新的实时界面——这样你就能少花时间适应工具，多花时间完成工作。

当聊天是错误的 UI 时

当开发者需要一个比聊天框更具体的东西时该怎么办？答案是画布。