ReviewBench：面向 AI 代码审查的开源基准

基于智能体的代码审查正在成为开发流程中不可或缺的一环。它帮助你审查 Pull Request，捕捉潜在问题，并在代码上线前判断哪些问题值得关注。

但现有 AI 审查工具的质量很难量化，你需要了解某个审查工具的强项，才能判断它是否真正有帮助。不同工具表现各异：有的能发现更多问题，有的误报较少，有的擅长捕捉关键缺陷，有的则能挖掘更多细枝末节的改进点。在你的工作流中，代码审查可能需要承担不同的职能。

因此，理解不同审查工具之间的实际差异至关重要：它们能捕获什么、漏掉什么，以及在各种权衡中如何取舍。优秀的代码审查基准应反映真实 Pull Request 的多样性，涵盖广泛的审查发现，并支持按严重程度、类别及精确率/召回率偏好进行细致拆解。对于正在构建代码审查智能体的团队而言，基准还应提供离线信号，以可靠地预测变更是否可能提升生产环境体验。现有基准往往在标签质量、覆盖度以及对真实世界代码审查的代表性之间做出妥协，未能提供将上述要素结合起来的严谨且可复现的评估方法论。

为填补这一空白，我们构建了 ReviewBench，一个新的代码审查离线基准，现已开放使用。该基准模拟了 GitHub 上超过 1 亿条真实 Pull Request 的语言、仓库规模及大小分布。它采用多来源黄金数据集和统一的评估标准，并经过资深工程师独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot 代码审查（CCR）的离线评估在预测生产实验方向方面变得更加有效，让我们更有信心相信测量到的改进反映了用户层面的实际收益。

本文将详细介绍 ReviewBench 的构建方式、如何确立可靠的事实基准与评分机制，以及如何接入你自己的代码审查系统并提交结果。

1

我们构建了什么

一个面向 AI 代码审查智能体的、贴近现实且全面的基准

103.9M

GitHub Pull Requests

分析语言、仓库规模及变更形态的分布。

代表性的基准语料库

涵盖 19 种语言中的 219 个公开 Pull Request，分布贴合 GitHub 全局数据，同时保留了实质性的代码审查案例。

多来源黄金标准集

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

结构化发现

每个发现均标记了严重度和类别，支持按用户需求切片分析。

严重度

• 严重
• 中等
• 轻微

类别

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

评估指标

使用四项指标衡量已知问题和新发现问题的表现。

• 基于基准的精确率（Grounded Precision）
• 基于基准的召回率（Grounded Recall）
• 增强型精确率（Augmented Precision）
• 增强型召回率（Augmented Recall）

客观评估

客观衡量改进效果并跨不同 Agent 进行比较，帮助用户选择最契合自身需求的审查工具。

2

如何确保持续可信

从评估准则到专家验证再到生产环境检查，形成可审计的完整链路

公开评估准则

为所有发现提供统一的显式标准。

人工标注的开发集

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

校准后的评分器

与人类判断保持一致。

统一标注

所有来源采用相同标准。

公开一致性数据

专家对基准质量进行的审计。

端到端可审计

96.6% 一致性

发布前，资深工程师独立对黄金标准集中的阳性样本进行了标注。

预测生产环境的离线信号

将基准测试的结果变化与在线实验进行对比验证。

• 改进通常会在在线实验中显现
• 退化通常也会在在线实验中显现

这些卡片之间的连线由 JavaScript 绘制。ReviewBench 一览 1 我们构建了什么 一个真实、全面的 AI 代码评审 agent 基准 1.039 亿 GitHub pull request 按语言、仓库规模和变更形态分析分布。 代表性基准语料库 覆盖 19 种语言的 219 个公开 pull request，在保留实质性评审案例的前提下对齐 GitHub 整体分布。 多来源黄金集 人类评审员；前沿 LLM；静态分析 结构化发现 每条发现都标注了严重程度和类别，可按用户需求切分数据。 严重程度：Critical Medium Low 类别：Correctness Security Reliability Maintainability Testing ...... 评估指标 四项指标同时衡量已知问题和新增发现的问题。 Grounded precision；Grounded recall；Augmented precision；Augmented recall 客观评估 客观衡量改进幅度并在不同 agent 之间对比，帮助用户选出最适合自己的评审工具。 2 我们如何保证可信度 从评分标准到专家验证再到生产验证，全链路可审计 公开评分标准 所有发现都遵循同一套明确标准。 人工标注开发集 资深工程师建立 ground truth。 校准后的评分器 与人类判断保持一致。 统一标注 所有来源采用同一标准。 公开一致性 专家审计基准质量。 端到端可审计 96.6% 一致性 发布前由资深工程师独立标注黄金真阳性。 能预示生产表现离线信号 基准结果与线上实验对照验证。 改进通常会在线上体现；退化也会在线上体现 关联：GitHub pull request → 代表性基准语料库。 关联：代表性基准语料库 → 多来源黄金集。 关联：多来源黄金集 → 结构化发现。 关联：结构化发现 → 评估指标。 关联：评估指标 → 客观评估。 关联：公开评分标准 → 人工标注开发集。 关联：人工标注开发集 → 校准后的评分器。 关联：校准后的评分器 → 统一标注。 关联：统一标注 → 公开一致性。

ReviewBench 的工作原理

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

1. 代表性的 pull request，而非演示集

我们对 1.039 亿个 GitHub Pull Request 进行了分析，以描绘真实世界代码审查工作量的分布特征。ReviewBench 包含来自 187 个公开开源仓库的 219 个 Pull Request，涵盖 19 种编程语言，其语言分布与仓库规模分布与 GitHub 整体情况高度吻合。完整的基准数据集已公开提供。

我们对上述分布做出了一项刻意调整：尽管语言类型和仓库规模直接镜像 GitHub 现状，但 Pull Request 的大小权重向可审查的中段及长尾倾斜。这一做法减少了微小单文件变更的过度代表性，同时保留了更具实质内容的多文件 Pull Request，而代码审查的质量恰恰在这些场景中最为关键。

语料库快照：

2. 广泛发现 Ground Truth 基准，独立评判

无论是人类还是模型，单一审查者都无法发现 Pull Request 中所有值得注意的问题。为了构建更广泛、更可靠的黄金标准 Ground Truth 发现集合，我们遵循三阶段流程：

• 从多样化来源收集候选发现。 我们从真实的人类审查员、通过作者后续提交推断出的问题、确定性分析工具，以及跨不同模型家族的多个前沿 LLM 中收集发现。
• 对重叠发现进行语义去重。 我们将指向同一底层问题的发现合并在一起，从而在不允许不同来源的共识人为抬高黄金标准集合、或使其依赖于任何单一来源盲区的前提下，拓宽覆盖范围。
• 在统一评分标准下验证发现。 发现的来源不决定其正确性：一项发现只有在其真实、相关且非琐碎时，才计为真阳性。我们使用 Claude Sonnet 5 作为 LLM 评判器，对所有提交应用一致的评估评分标准。出于透明度和可复现性考虑，我们公布了评估标准及用于执行该标准的评判器。

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

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

• 基线精确率、召回率和 F1 分数仅使用黄金集（gold-set）中的现有标签。它们提供严格的同口径对比：在已知问题中，智能体找到了多少？其发现的结果中有多少比例与已知问题匹配？
• 增强精确率、召回率和 F1 分数还会评估那些在黄金集中没有对应项的发现。评审员独立判断这些未匹配发现是真阳性还是假阳性，从而让那些发现了黄金集未覆盖的有效问题的评审者也能获得认可。

随着审查智能体能力的提升，这种区分变得愈发重要。固定的黄金集难免会随系统发现更多其创建者未曾预料的问题而变得不完整。增强指标使 ReviewBench 能够识别这种能力，而非自动予以惩罚。由于增强召回率的分母会根据每个智能体的发现情况进行扩展，我们将基线召回率作为系统间对比的核心指标，并将增强指标作为各系统的额外诊断参考。

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

不存在单一通用的最佳审查体验。部分开发者可能希望只关注关键问题，而另一些人则同样看重低严重性、非破坏性的发现。有人偏好更广泛的覆盖范围，有人则优先追求高精确率和低噪音。还有人可能有特定需求，如侧重安全或隐私的审查。

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

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

发布前，我们邀请了几位未参与基准数据集构建的资深工程师，从零开始独立重新标注每一条 ground-truth finding。他们对真/误报的判断与 ReviewBench 的标注一致率达到 96.6%。每次评估所用的基准数据集、judge 和 matcher 都有版本管理，因此结果可以在同一基准配置下相互比较，并在基准变更后重新验证。我们还公开了验证方法、一致性测量和已知的有效性威胁，让读者能看到基准质量是如何评估的，以及哪些地方仍存在不确定性。

探索 ReviewBench

ReviewBench 研究预览版现已通过 ReviewBench 网站上线，你可以在上面浏览完整基准、比较各个 code review agent，也可以接入自己的 agent 进行评估和迭代。

借助 ReviewBench，你可以：

• 浏览完整的基准数据集。ReviewBench 完整数据集公开可用，包括 pull request、findings、标签以及严重性和类别标注。你可以确切看到系统在什么内容上被评估，并复现基准结果。
• 在排行榜上比较各个系统。各 code review agent 在完整基准数据上的评估结果统一发布在公共排行榜上，支持按整体表现、严重性、类别以及不同 precision–recall 偏好查看。
• 接入自己的 agent 持续优化。完整基准数据集、评估方法、LLM judge prompt、judge 模型配置和自助 runner 均已公开，你可以评估自己的 code review agent，查看它的长处与不足，并在同一基准配置下持续迭代。

我们如何使用 ReviewBench

我们利用 ReviewBench 对 Copilot code review（CCR）的多个迭代版本进行评估，建立了一套一致的方式来衡量进展、发现回归问题并优先处理具有潜力的改进。随着时间推移，这帮助我们持续优化产品。ReviewBench 的一个关键价值在于，它能为产品变更在生产环境中的预期表现提供早期的离线信号。在 A/B 测试之前通过 ReviewBench 评估的实验显示，离线结果的变化方向与后续生产环境中的表现高度一致。

最近一次轻量级（lite-tier）实验具体展示了这一规律。我们引入了多模型集成评审（multi-model ensemble review），它将多个独立模型运行的结果合并为一份评审报告，而非依赖单次运行。ReviewBench 预测该方法将带来更高的精确率、召回率和评论量，同时降低单次评审成本。

为了对比离线和生产环境的结果，我们使用了相应的在线指标。解决率（Addressed rate）作为精确率的在线对应指标，指 LLM 判定 CCR 评论促使开发者做出相应代码变更的比例，判定依据包括差异（diff）、讨论线程、反应、解决状态及评审后的代码。对于召回率，我们衡量的是仍需多少人工评审工作。

在线 A/B 测试的结果与 ReviewBench 的预测方向一致：相较于生产环境的对照组，解决率（精确率）上升了 8.0%，召回率上升了 13.6%，评论量增加了 61%，而单次评审成本下降了 8.0%。

然而，仅看评论量无法反映评论质量。关键发现（critical findings）与轻微琐碎意见（nits）有着本质区别。ReviewBench 在严重等级评估中也捕捉到了这一点：它预测关键评论数量将增加 227%（在线实际为 262%），并预测了向中度评论增多、琐碎意见减少的整体转变趋势，这与在线结果相符。

这为我们在运行生产实验之前提供了一个快速且可重复的信号。在线实验仍然是衡量用户影响的最终标准，但 ReviewBench 帮助我们更自信地判断哪些变更值得进入生产环境测试。

如何提交你的评估结果

1. 在 ReviewBench 网站上通过 GitHub 账号登录。
2. 注册你的 agent。提供容器镜像、配置文件以及你的模型密钥。裁判系统由我们提供。
3. 在测试集上试用。针对 25 个 PR 的测试集运行，查看每个 PR 的详细信息，并随着配置调优反复测试。
4. 进行最终运行。准备好后，运行完整的 219 个 pull requests（共三轮），由与其他所有条目相同的裁判打分。
5. 发布到排行榜。你的分数在维护者审核并批准提交之前保持私有。仅当分数超过该 agent 当前的排行榜分数，或这是该 agent 的首次上榜条目时，分数才会公布到排行榜。