ReviewBench：面向 AI 代码审查的开放基准
智能体代码审查（Agentic Code Review）正在成为开发流程中不可或缺的一环。它帮你检查 PR、发现问题，在代码上线前判断哪些值得关注。但现有 AI 审查工具的质量很难衡量，你得先了解一个审查器的强项，才能判断它对你是否有用。有的审查器能发现更多问题，有的噪音更少；有的擅长抓关键缺陷，有的则会给出一些小的改进建议。在你的工作流里，代码审查可能承担不同的职责。正因如此，搞清楚不同审查器之间到底怎么对比就很重要：它们各自能发现什么、会漏掉什么、做了哪些取舍。
一个好的代码审查基准应该反映真实 PR 的多样性，覆盖广泛的审查结果类型，并支持按严重程度、类别以及精确率-召回率的偏好做有意义的细分。对于构建代码审查智能体的团队来说，基准还应该提供一个离线信号，能够可靠地追踪某些改动是否有可能改善生产环境中的体验。
现有基准往往在标签质量、覆盖范围和真实场景代表性之间做取舍，导致缺少一套严谨、可复现的评估方法把这些要素整合起来。为此我们构建了 ReviewBench——一个新的代码审查离线基准，今天起即可使用。
它以 GitHub 上超过 1 亿条真实 PR 为参照，遵循相同的语言、仓库规模和 PR 规模分布。它采用多来源的黄金集和统一的评估标准，并经过资深工程师独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot 代码审查（CCR）的离线评估能更有效地预判生产实验的方向，让我们更有信心地认为，所测得的改进确实为用户带来了实质性收益。
本文将介绍 ReviewBench 是如何构建的、它如何建立可靠的真值与评分机制，以及如何接入你自己的代码审查系统并提交结果。
本文术语定义
Benchmark（基准）：用统一的评分方法，在一组相同的 pull request 上测试代码审查工具的标准化评估。
Finding（发现）：代码审查过程中发现的一个具体问题。
Golden set（黄金集）：每个 pull request 经过验证的已知问题集合，作为参照，用来判断审查工具发现了什么、遗漏了什么。
Precision（精确率）：审查工具提出的问题中，真正有效的比例。精确率越高，噪音越少。
Recall（召回率）：已知的有效问题中，审查工具找到的比例。召回率越高，覆盖越全。
F1 score（F1 分数）：一个兼顾精确率和召回率的综合分数，两者权重相同。
Fβ score（Fβ 分数）：F1 的变体，可以根据你的审查偏好，给精确率或召回率更高的权重。
ReviewBench 概览
1 我们做了什么
打造一个贴近实际、覆盖全面的 AI 代码审查智能体基准。
1.039 亿个 GitHub pull request
按语言、仓库规模和变更形态分析其分布。
有代表性的基准语料库
219 个公开 pull request，覆盖 19 种语言，分布对齐 GitHub 整体情况，同时保留了有实质审查价值的案例。
多来源黄金集
汇集人工审查者、前沿大语言模型、静态分析工具的发现。
每条发现都标注了严重程度和类别，方便用户按需筛选。
| 严重程度 | 类别 |
|---|---|
| 严重 | 正确性 |
| 中等 | 安全性 |
| 低 | 可靠性、可维护性、测试…… |
评估指标
四个指标，同时衡量已知问题和新发现的问题。
- Grounded precision（有据精确率）
- Grounded recall（有据召回率）
- Augmented precision（增强精确率）
- Augmented recall（增强召回率）
客观评估
客观衡量改进幅度，在不同智能体之间做对比。
帮用户选出最符合自己需求的审查工具。
2 我们如何保证可信度
从评分标准到专家验证、再到生产环境检查，全流程可审计。
- 公开的评分标准：所有发现适用同一套明确标准。
- 人工标注的开发集：由资深工程师确立基准事实。
- 校准过的评分器：与人类判断保持一致。
- 统一标注：不同来源使用同一套标准。
- 公开的一致性数据：由专家审计基准质量。
端到端可审计，一致率 96.6%。发布前由资深工程师独立标注标准答案中的真正例。离线信号能预判生产环境表现。基准测试的变化会与线上实验对照验证。改进通常会在线上体现，退化同样如此。用 JavaScript 绘制卡片之间的箭头连接。ReviewBench 速览
1 我们构建了什么
面向 AI 代码审查智能体的真实、全面的基准测试
1.039 亿个 GitHub 拉取请求
按语言、仓库规模和变更形态分析分布。
代表性基准语料库
219 个公开拉取请求，覆盖 19 种语言，与 GitHub 整体分布对齐，同时保留有实质审查价值的案例。
多来源黄金集
人工审查者；前沿大语言模型；静态分析
结构化发现
每条发现都标注了严重程度和类别，支持按用户需求切分。
严重程度：严重
中
低
类别：正确性
安全性
可靠性
可维护性
测试
……
评估指标
四项指标同时衡量已知问题和新发现的问题。
有据精确率；有据召回率；增强精确率；增强召回率
客观评估
客观衡量改进效果，并在不同智能体之间横向比较。帮助用户挑选最契合自身需求的审查工具。
2 我们如何保证可信
一条从评分标准到专家验证再到生产检验的可审计链路
公开的评分标准
对所有发现采用统一明确的评判标准。
人工标注的开发集
由资深工程师确立基准真值。
经校准的评分器
与人类判断保持一致。
统一标注
所有来源使用同一标准。
公开的一致性数据
由专家审计基准质量。
端到端可审计
96.6% 一致性
发布前，资深工程师独立标注了黄金集真阳性样本。
离线信号可预示线上表现
基准测试的变化会与线上实验进行对照检验。
改进通常会在线上体现出来；退化通常也会在线上体现出来
关联：GitHub 拉取请求 → 代表性基准语料库。
关联：代表性基准语料库 → 多来源黄金集。
关联：多来源黄金集 → 结构化发现。
关联：结构化发现 → 评估指标。
关联：评估指标 → 客观评估。
关联：公开的评分标准 → 人工标注的开发集。
关联：人工标注的开发集 → 经校准的评分器。
关联：经校准的评分器 → 统一标注。
连接方式：从统一标注到达成一致发布。
ReviewBench 是如何工作的
我们的基准测试基于五条原则：
1. 有代表性的拉取请求，而不是随意拼凑的演示集
我们分析了 1.039 亿个 GitHub 拉取请求，以刻画代码审查工作负载的真实分布。ReviewBench 收录了来自 187 个公开开源许可仓库的 219 个拉取请求，覆盖 19 种语言，其语言和仓库规模分布与 GitHub 整体高度一致。完整的基准数据集已公开。
我们对这一分布做了一处有意调整：语言和仓库规模直接对齐 GitHub，而拉取请求的规模则向可审查的中等和长尾部分倾斜。这样可以减少微小、单文件改动占比过高的问题，同时保留更实质性的多文件拉取请求——在这些请求上，审查质量最为关键。
语料库快照：
2. 广泛的真实答案发现，独立评判
任何单一审查者，无论是人还是模型，都无法识别出拉取请求中所有值得发现的问题。为了构建更广泛、更可靠的真实答案黄金集，我们采用三阶段流程：
从多种来源收集候选发现。 我们从真实人类审查者、作者后续提交中推断出的问题、确定性分析工具，以及跨模型家族的多个前沿大语言模型中收集发现。
对重叠发现进行语义去重。 我们将指向同一底层问题的发现合并，从而扩大覆盖范围，同时不让多个来源的一致意见人为膨胀黄金集，也不让黄金集依赖于任何单一来源的盲区。
在统一标准下验证发现。 一个发现是否正确，不取决于它来自哪里：只有当它真实、相关且非琐碎时，才被计为真阳性。我们使用 Claude Sonnet 5 作为大语言模型评分器，对所有提交应用一致的评估标准。为了透明和可复现，我们公开了评估标准以及用于执行该标准的评判器。
3. 同时衡量已知问题和新增发现的指标
大多数基准测试报告的是针对固定黄金集的精确率和召回率。
ReviewBench 报告两组共六项指标：基于金标集（gold set）的精确率、召回率和 F1 分数只使用已有的金标标签。它们提供严格的、同类可比的对比：在我们已知的问题中，智能体找到了多少？它的发现中有多大比例匹配到了已知问题？增强精确率、召回率和 F1 分数还会评估那些与金标集中任何内容都不匹配的发现。评判器独立判断这些未匹配的发现是真阳性还是假阳性，让评审者能够因为发现金标集中没有任何产出者提出的有效问题而获得认可。随着代码审查智能体能力越来越强，这种区分变得越来越重要。固定的金标集不可避免地会变得不完整，因为系统会发现其创建者未曾预料到的问题。增强指标让 ReviewBench 能够识别这种行为，而不是自动惩罚它。由于增强召回率会根据每个智能体发现的内容扩大分母，我们用基于金标集的召回率作为跨系统对比的主要指标，把增强指标作为额外的单系统诊断指标。
4. 针对不同审查偏好的可配置评估
不存在一种普遍最优的代码审查体验。有些开发者可能只想关注关键问题，而另一些人同样看重严重性较低、不造成破坏的发现。有些人偏好更广的覆盖范围，另一些人则优先考虑精确率和最小的噪音。还有人可能有专门需求，比如以安全或隐私为重点的审查。ReviewBench 允许按严重性和类别切分结果，精确率和召回率则捕捉不同的操作偏好。用户还可以调整 Fβ 分数中的 β，把更多权重放在召回率上以获得更广覆盖，或放在精确率上以降低噪音。当这些偏好改变时，排行榜会相应重新排名，帮助用户找到最符合其审查优先级的系统。
5. 内部审计与可复现评估
发布之前，我们请未参与构建基准数据集的资深工程师从头开始独立重新标注每一个真值发现。
这些真假阳性判断与 ReviewBench 的一致率达到 96.6%。每次评测所用的基准数据集、评判模型和匹配器都带有版本标记，因此可以在相同的基准配置下比较结果，基准变更时也能重新验证。我们还会公开验证方法、一致率数据和已知的有效性风险，让读者了解基准质量是如何评估的、哪些地方还有不确定性。
探索 ReviewBench
ReviewBench 的研究预览版现已通过 ReviewBench 网站开放，你可以浏览完整基准、比较各种代码审查智能体，也可以接入自己的智能体来评测和迭代。
使用 ReviewBench，你可以：
浏览完整基准数据集。 完整的 ReviewBench 数据集已公开，包括拉取请求、发现项、标签、严重程度和类别标注。你可以据此查看被评测系统的具体内容，并复现基准结果。
在排行榜上比较不同系统。 使用完整基准数据评测的代码审查智能体，其结果会发布在统一排行榜上，支持按总体表现、严重程度、类别，以及不同精确率-召回率偏好等维度查看。
接入自己的智能体并持续优化。 完整的基准数据集、评测方法、LLM 评判提示词、评判模型配置和自助运行工具都已公开，你可以评测自己的代码审查智能体，查看它的优势和短板，并在同一基准配置下反复迭代。
我们如何使用 ReviewBench
我们用 ReviewBench 评测了多个版本的 Copilot 代码审查（CCR），从而获得一套一致的方法来衡量进展、发现性能回退，并确定哪些改进值得优先投入。长期下来，这帮助我们持续优化了产品。
ReviewBench 最有价值的一点，是它能在改动上线之前，提前给出一个离线信号，预示这次产品变更在生产环境可能表现如何。在 A/B 测试之前用 ReviewBench 评估的多次实验中，离线结果指向的方向，与后来在生产环境看到的结果始终一致。
最近的一次轻量级实验，正好印证了这套更宏观的规律。我们引入了一种多模型集成审查机制：不再依赖单次运行，而是把几个独立模型的结果汇总成一份审查意见。ReviewBench 预测，这种做法的精确率、召回率和评论数量都会提升，单次审查成本则会下降。为了对比离线和生产环境的结果，我们使用对应的线上信号。在线侧与精确率对应的指标是「已解决率」——即大语言模型判断 CCR 的评论是否促使开发者做出了相应代码修改的比例，判断依据包括 diff、评论线程、表情回应、解决状态以及审查后的代码。至于召回率，我们衡量的是仍需要多少额外的人工审查。线上 A/B 测试的走向与 ReviewBench 的预测一致：相比对照组，已解决率（对应精确率）上升了 8.0%，召回率上升了 13.6%，评论数量上升了 61%，同时单次审查成本下降了 8.0%。
不过，单看评论数量并不能反映评论质量。一条严重问题的评论和一条低优先级的小建议，意义完全不同。ReviewBench 的严重程度分级评估也捕捉到了这一点：它预测严重评论会增加 227%，线上实际增加 262%，同时中等级别评论变多、小建议变少的趋势也一致。这样一来，我们就能在生产实验之前，先拿到一个快速且可复现的信号。线上实验仍然是衡量用户影响的最终标准，但 ReviewBench 让我们更有把握判断哪些改动值得拿到线上去验证。
如何提交你自己的运行结果
- 用 GitHub 登录 ReviewBench 网站。
- 注册你的 agent。提供容器镜像、配置文件和自己的模型密钥。评判器由我们提供。
- 在测试集上试跑。用 25 个 PR 组成的测试集跑一轮，查看每个 PR 的详细结果，边调配置边反复运行。
- 跑最终成绩。准备好之后，跑完整的 219 个 PR（共三轮），由和其他所有参赛者相同的评判器打分。
- 发布到排行榜。在维护者审核通过之前，你的分数一直保持私密。
只有当分数超过该 agent 当前的排行榜成绩，或者这是该 agent 首次上榜时，分数才会发布到排行榜上。我们邀请你体验 ReviewBench，评估你自己的系统，质疑我们的假设，和我们一起改进这个基准测试。我们期待与研究人员和开发者合作，让代码审查评测更加开放、可靠、实用，最终推动 AI 代码审查向前发展。
致谢
ReviewBench 是 GitHub 和 Microsoft 跨团队协作的成果。感谢参与建设的研究人员和工程师：他们设计了评测方法，筛选了 pull request，构建了黄金数据集和评测流水线，让这个基准测试人人都能上手运行。