ReviewBench 是 GitHub 给 AI 代码审查智能体准备的一套离线考卷。2026 年 10 月 5 日，GitHub 在官方博客发布这套开放基准：它先分析了 1.039 亿个真实 pull request 的分布，再从 187 个公开开源仓库中选出 219 个 PR、覆盖 19 种语言，让不同的代码审查智能体在同一套标准答案和评分规则下，比谁漏报少、谁误报少、谁更能抓住严重问题。ReviewBench 目前为研究预览，完整数据集公开，任何团队都可以把自己的审查智能体送去考试并提交成绩。
标准答案不是一个人拍的
代码审查难评测，根源在标准答案本身：同一个 PR，人类审查者、静态分析工具和不同的大模型，各自能发现的问题集合并不重合，漏掉任何一方的视角，考卷就会系统性偏向某类审查者。ReviewBench 的金标集走多来源路线：候选问题同时来自真实人类审查意见、从作者后续提交里反推的问题、确定性分析工具和多个前沿大模型；重叠的问题先做语义去重，再统一按一份公开的评分标准判定真伪——一条问题只有真实、相关且不琐碎才算数，与它来自哪个来源无关。担任裁判的是 Claude Sonnet 5，评分标准和裁判配置一并公开。全部问题都标注了严重程度（严重、中等、低）和类别（正确性、安全、可靠性、可维护性、测试等）。发布前，未参与构建的资深工程师独立重标了全部金标问题，与基准的一致率达 96.6%。
新指标给"标准答案之外的新发现"留了位置
传统基准只对着固定答案算精确率和召回率，审查者发现了一个答案里没有的真问题，反而会被记成误报。ReviewBench 因此准备了两组指标：一组只认金标集内的已知问题，用于跨系统严格对比；另一组会让裁判独立判断未命中金标的新发现到底是真是假，真发现可以得分。结果还可以按严重程度和类别切片，并通过 Fβ 权重在"宁可多报、别漏严重问题"和"少打扰、低噪声"之间调整偏好，排行榜随之重新排序——因为对代码审查来说，没有一种偏好适合所有团队。
离线分数能不能预示线上效果，GitHub 拿自己做了实验
这套基准先在 GitHub 内部用于迭代 Copilot 代码审查。博客给了一个完整对照案例：一次多模型集成审查的实验中，ReviewBench 预判精确率、召回率和评论量都会上升、单次审查成本下降；随后的线上 A/B 测试同向验证——被开发者采纳的评论比例上升 8.0%，召回率上升 13.6%，评论量上升 61%，单次审查成本下降 8.0%。严重问题评论量离线预判增加 227%，线上实际增加 262%，连问题的严重程度分布都对上了。
想送考的团队流程已经开放：用 GitHub 账号登录 ReviewBench 网站，登记智能体的容器镜像、配置和自己的模型密钥，先在 25 个 PR 的测试集上反复调，再跑满 219 个 PR、三轮的正式成绩，维护者审核后才上榜，且只有刷新自己已有成绩时才会替换。AI 代码审查正在变成编程工作流的默认环节，从 Codex 的快速迭代到各类审查机器人，工具越来越多，但此前行业缺的恰恰是一把公开、统一、还能区分严重程度的尺子。ReviewBench 把裁判标准、数据集和送考通道全部公开，接下来要看的是：主流审查工具敢不敢把自己的分数挂出来。
