GitHub 发布 ReviewBench：面向 AI 代码审查的开放基准

我们推出 ReviewBench，这是一个面向代码审查智能体的基准测试，基于具有代表性的 GitHub 拉取请求、多来源真实标注、校准评估以及与生产环境对齐的指标构建。

2026 年 10 月 5 日

|

11 分钟

• 分享：

智能体代码审查正成为开发流程中不可或缺的一环。它帮助你检查拉取请求、发现问题，并在代码发布前判断哪些内容值得关注。

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

因此，理解审查器之间究竟如何比较就变得很重要：不同系统能捕捉什么、会遗漏什么，以及它们做出了哪些权衡。一个好的代码审查基准测试应当反映真实拉取请求的多样性，涵盖广泛的审查发现，并支持按严重程度、类别以及精确率-召回率偏好进行有意义的细分。对于构建代码审查智能体的团队来说，该基准测试还应提供一个离线信号，可靠地追踪相关改动是否可能改善生产环境中的体验。现有基准测试往往在标签质量、覆盖范围以及真实世界代码审查的代表性之间做出取舍，留下了一个空白，缺少一种严谨且可复现的评估方法将这些要素整合起来。

我们构建了 ReviewBench，一个全新的代码审查离线基准测试，以填补这一空白，它今天即可供你使用。它遵循 GitHub 上超过 1 亿个真实拉取请求所体现的语言、仓库规模和拉取请求规模分布。它使用多来源黄金集和一致的评估标准，并已由资深工程师独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot 代码审查（CCR）的离线评估已能更有效地预判生产实验的方向，让我们更有信心认为所测得的改进反映了对用户有意义的提升。

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

ReviewBench 一览

我们构建了什么

一个面向 AI 代码审查智能体的真实、全面的基准测试

1.039 亿

GitHub 拉取请求

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

具有代表性的基准语料库

涵盖 19 种语言的 219 个公开拉取请求，与 GitHub 整体分布保持一致，同时保留实质性的审查案例。

多来源黄金集

• 人类审查者
• 前沿 LLM
• 静态分析

结构化发现

每条发现都标注了严重程度和类别，支持按用户需求定制切片。

严重程度

• 严重
• 中等
• 低

类别

• 正确性
• 安全性
• 可靠性
• 可维护性
• 测试
• ......

评估指标

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

• 有依据的精确率
• 有依据的召回率
• 增强精确率
• 增强召回率

客观评估

客观地衡量改进并在各智能体之间进行比较。帮助用户选择最符合其需求的审查者。

我们如何保持其可信度

从评分标准到专家验证与生产检查的可审计链条

已发布的评分标准

对所有发现采用同一套明确标准。

人工标注的开发集

由资深工程师确立基准真值。

经过校准的评分器

与人类判断保持一致。

统一标注

对所有来源采用同一标准。

已发布的一致性

对基准质量的专家审计。

端到端可审计

96.6% 一致性

资深工程师在发布前独立标注了黄金真阳性样本。

可预判生产表现的离线信号

基准变化会与线上实验进行对照检查。

• 改进往往会在线上显现
• 回归往往也会在线上显现

ReviewBench 如何运作

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

1. 具有代表性的拉取请求，而非演示集

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

我们对这一分布做了一处刻意的调整：语言和仓库规模直接镜像 GitHub，而拉取请求规模则向可审查的中段和长尾加权。这减少了微小、单文件改动的过度占比，同时保留了更具实质内容的多文件拉取请求——在这些请求中，审查质量最为关键。

语料库快速概览：

2. 广泛的基准真值发现，独立评判

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

• 从多样来源收集候选发现。我们从真实人类审查者、由作者后续提交推断出的问题、确定性分析工具，以及跨模型家族的多个前沿 LLM 中收集发现。
• 对重叠发现进行语义去重。我们合并指向同一底层问题的发现，在扩大覆盖范围的同时，避免各产出方之间的一致性人为夸大黄金集，也避免使其依赖于任何单一来源的盲区。
• 在统一评分标准下验证发现。发现的来源并不决定其是否正确：只有当一项发现真实、相关且非琐碎时，才计为真阳性。我们使用 Claude Sonnet 5 作为 LLM 评分器，对所有提交应用一致的评估标准。为保证透明性和可复现性，我们同时发布评估标准和用于应用该标准的评判器。

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

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

• 基于真值的精确率、召回率和 F1 分数仅使用现有的黄金集标签。它们提供严格的、同类可比的比较：在我们已知的问题中，智能体发现了多少，其发现中又有多少比例匹配到了已知问题？
• 增强精确率、召回率和 F1 分数还会评估那些与黄金集中任何内容都不匹配的发现。评判器会独立判断这些未匹配的发现是真正的阳性还是假阳性，从而让评审者因黄金集中没有任何生产者提出的有效问题而获得认可。

随着评审代理能力越来越强，这一区别变得更加重要。固定的黄金集不可避免地会随着系统发现其创建者未曾预料到的问题而变得不完整。增强指标让 ReviewBench 能够识别这种行为，而不是自动对其进行惩罚。由于增强召回率会根据每个代理发现的内容扩大分母，我们使用有依据的召回率作为跨系统比较的主要指标，并将增强指标作为额外的单系统诊断指标。

4. 针对不同评审偏好的可配置评估

并不存在单一普遍最优的评审体验。一些开发者可能只想关注关键问题，而另一些人也看重较低严重性、非破坏性的发现。有些人偏好更广泛的覆盖范围，而另一些人则优先考虑精确率和最小噪声。还有些人可能有专门需求，例如以安全或隐私为重点的评审。

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

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

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

探索 ReviewBench

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

使用 ReviewBench，你可以：

• 探索完整基准数据集。 完整的 ReviewBench 数据集已公开，包括拉取请求、发现、标签、严重性和类别标注。这让你能够准确检查系统是在什么数据上被评估的，并复现基准结果。
• 在排行榜上比较系统。 使用完整基准数据评估的代码评审代理结果会发布在同一个排行榜上，并提供整体性能、严重性、类别以及不同精确率–召回率偏好的视图。
• 带上你自己的代理并爬山优化。 完整基准数据集、评估方法、LLM 评判器提示、评判器模型配置以及自助运行器均已公开，因此你可以评估自己的代码评审代理，检查其优势与差距，并在相同基准配置下迭代。

我们如何使用 ReviewBench

我们使用 ReviewBench 来评估 Copilot 代码审查（CCR） 的历次迭代，从而获得一种一致的方式来衡量进展、发现回归并确定有前景的变更的优先级。随着时间的推移，这帮助我们改进了产品。ReviewBench 最有价值的好处之一是，它能在离线阶段提前给出信号，预示产品变更在生产环境中的可能表现。在 A/B 测试之前用 ReviewBench 评估的实验中，离线变化的方向始终与之后在生产环境中看到的结果一致。

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

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

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

然而，仅凭评论数量并不能反映评论质量。更多关键发现与低严重性的小问题意义截然不同。ReviewBench 的严重性级别评估也捕捉到了这一点：它预测关键评论将增加 227%，而线上实际为 262%，同时还预测了同样更广泛的趋势，即中等评论增多、小问题减少。

这让我们在运行生产实验之前就能获得快速且可重复的信号。在线实验仍然是衡量用户影响的最终标准，但 ReviewBench 让我们更有信心判断哪些变更值得投入生产实验。

如何提交你自己的运行结果

1. 在 ReviewBench 网站上使用 GitHub 登录。
2. 注册你的 agent。 提供一个容器镜像、你的配置以及你自己的模型密钥。我们提供评判器。
3. 在测试集上试用。 针对一个包含 25 个 PR 的测试集运行，查看每个 PR 的详细信息，并在调整配置时反复运行。
4. 进行最终运行。 当你准备好时，运行完整的 219 个拉取请求集合（三轮），由与其他所有参赛作品相同的评判器评分。
5. 发布到排行榜。 在维护者审查并批准提交之前，你的分数保持私密。只有当分数超过该 agent 当前的排行榜分数，或者这是该 agent 首次进入排行榜时，分数才会发布到排行榜。

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

致谢

ReviewBench 是 GitHub 和 Microsoft 通力合作的成果。我们感谢参与构建它的研究人员和工程师：他们设计了方法论、整理了 pull request、构建了黄金集和评估流水线，并让这个基准测试成为任何人都可以运行的工具。

作者

Michelle 负责开发和评估用于代码审查的智能体 AI 系统，专注于仓库级上下文检索、审查与修复质量，以及对 AI 代码审查工具的严格基准测试。

Alejandro 的工作专注于评估编码智能体，改进其对代码变更和仓库上下文的推理方式，并优化模型质量、覆盖率、延迟和 token 成本。

相关文章

密钥保护必须与软件同步扩展

开发者并非变得愈发粗心，而是被甩在了后面。那些让开发者能够创造更多软件的工具，也应当承担起更多保护软件的工作。

我们也做新闻通讯

在我们的双周开发者专属新闻通讯中，发现技巧、技术指南和最佳实践。