AI 代码审查：衡量有用发现，而不是评论数量

GitHub 十月发布的 ReviewBench 文章，为选择代码审查工具提供了一个思考起点。用自拟的小练习分清可复现的缺陷、遗漏的问题和无效评论。

三个月免费开放 · 至 2027 年 1 月 10 日（日本时间），所有文章均可阅读全文。

这篇近期文章提出了什么问题

Michelle Zhou 和 Alejandro Carderera de Diego 于 2026-10-05 发布了 GitHub 的 ReviewBench 文章 ↗，介绍基于真实拉取请求与经过验证的发现来评估 AI 审查工具的方法。值得学习的问题很直接：哪些评论能帮助你避免缺陷？

下文是我们自拟的练习，不是对该基准的复刻，也不是某个模型的成绩报告。你可以选择一个小型命令行工具，而不必用大型生产代码库起步。

假设有一个 CSV 支出解析器，输入日期、金额和类别。请先自己写明期望行为：拒绝格式错误的金额、保留合法的负数调整，并报告无法解析的行号。亲自确定要求，才有独立判断答案的依据。

对每条审查评论，要求给出具体位置、触发问题的输入、期望行为和实际行为。“这里可能出错”只是一个假设；能展示错误结果的最小输入才是证据。如果评论建议重构，要问清它解决什么维护问题，不能把个人偏好悄悄记为已确认缺陷。

调查期间保留原始改动。先接受所有建议，会让你难以分辨哪条评论确实有用，哪条反而引入了新问题。审查工具的自信程度不能代替复现。

刻意制作三个有缺陷的解析器版本：一个错误地拒绝合法负数，一个丢失输入行号，一个错误处理空金额。再准备一个符合既定要求的正常对照版本。这些是自拟示例，不是安全攻击或厂商测试用例。

记录已确认的发现、工具漏掉的已知问题，以及无效或无关评论。评论很多的工具，仍可能遗漏你最在意的行为；评论少的工具，可能提出一条关键警告，也可能只是没发现缺陷。应分清这些情况，而不是只按评论数量选胜者。

保持改动与设置一致，重复审查两次，记录哪些发现仍能复现。这个小练习不足以证明全面可靠性，但能让你在依赖它审查更大改动前，发现措辞或随机性带来的影响。

把原理，切开来看

编辑示意图生成的产出只是候选结果。通过预先定义的检查后，才算完成。

GitHub 的当前使用文档 ↗说明如何请求和重新发起 Copilot 审查。默认情况下，评论式审查不计入批准要求；可选的自动批准属于另一项配置。这里引用的是 2026-10-11 核查的动态文档，并非另一篇刚发布的博客。

练习中，在复现问题之后、接受修复之前，保留一次人工判断。对修改后的解析器重跑示例，并检查差异。通过这三个用例，只能证明与这些用例相关的行为，其他行为仍未得到验证。

用一页表格记录每条评论的位置、复现输入、结论、严重程度和后续动作。对没有收到评论的每个预设缺陷，也补上一行。最后写出一个保留该工具的理由，以及一个仍需额外检查的场景。这样能建立具体的审查习惯，而不必声称自己复现了公开排行榜。

读懂之后，再动手试一次。