AI代码审查发出更多评论，不等于找到更多独立缺陷。同一个问题被换三种说法指出，评论数增加了，覆盖范围却没变。评估审查助手时，至少要分开看评论是否有效、已知问题漏了多少，以及人要花多少时间核实和处理。

GitHub的ReviewBench为这个问题提供了公开评测资料。本篇不复述排行榜，而是用一组已经人工标记的合成问题，解释分母和去重单位为什么重要。示例没有调用任何审查模型，也不是官方评测器的复现。Read in English。

先看清ReviewBench提供了什么

Google News收录了GitHub于2026年10月5日发布的介绍。它讨论基于真实PR的代码审查评测、多来源参考问题及grounded与augmented两组指标。这是公开基准项目的发布资料，不是本文完成的模型测评，也不把它称为同行评审论文。

项目仓库公开了PR语料、参考问题与评测相关材料，完整集合包含219个PR。使用结果前应核对语料、判断规则和版本，而不是把数据规模、人工一致性或某个榜单名次直接换算成自己仓库的可靠性。

接下来所有A、B、C、D都代表虚构问题编号，不是模型名称。讨论的是一种可审计的计数方法；官方ReviewBench的语义匹配、问题判断和评分规则需要按项目实现核对。

五条评论，可能只覆盖两个问题

设参考集合里有四个已知问题A、B、C、D。审查者甲输出五条评论：A、A、B，以及两条已判定无效的noise。按这个教学设定，三条评论指向真实问题，但独立问题只覆盖A和B，C与D仍未被发现。

如果问“发出的评论有多少条有效”，答案是3/5；如果问“四个已知问题覆盖多少”，答案是2/4。分子看起来接近，单位却不同：前者数评论，后者数问题。用3除以4来声称覆盖75%，就把重复指摘变成了不存在的新发现。

再设审查者乙输出A、B、C，以及五条无效评论，共八条。它覆盖3/4已知问题，按评论计的有效比例却只有3/8。单看评论数量无法判断优劣；单看其中一个比例，也会掩盖另一个方向的取舍。

用明确标签复现计数

下面的代码只用已知编号做精确统计。noise已经由示例作者判为无效；代码没有理解自然语言，也不能替代真正的缺陷确认。示例假设参考集合和评论列表非空；空输出时的精确率应单独约定如何报告，不能随意填一个数。

# Synthetic, pre-labeled findings; not the ReviewBench evaluator.
from fractions import Fraction as F

gold = {"A", "B", "C", "D"}
review_a = ["A", "A", "B", "noise1", "noise2"]
review_b = ["A", "B", "C"] + [f"noise{i}" for i in range(5)]

def summarize(reports):
    matched_comments = sum(x in gold for x in reports)
    found = set(reports) & gold
    return matched_comments, F(matched_comments,len(reports)), F(len(found),len(gold))

a = summarize(review_a)
b = summarize(review_b)
assert len(review_a) == 5
assert a[0] == 3
assert a[1] == F(3,5)
assert a[2] == F(1,2)
assert len(set(review_a) & gold) == 2
assert len(review_b) == 8
assert b[1] == F(3,8)
assert b[2] == F(3,4)
print("Synthetic finding counts verified")

本地检查通过，得到甲的评论有效比例3/5、已知问题覆盖率1/2，乙分别为3/8和3/4。这里刻意不计算一个“综合胜负分数”，因为没有给出误报、漏报和人工处理成本的偏好。

同样不能把这个函数包装成ReviewBench兼容评分器。真实评论可能定位到不同代码行，却描述同一根因；也可能文字相似，却分别对应两个独立缺陷。字符串相等在示例中足够，在真实审查中远远不够。

去重应该围绕根因与修复

把同一个越界问题在函数入口和调用处各说一次，是否算重复，需要看它们是否属于同一根因、是否通过同一修复消失，以及各自是否提供了独立的必要信息。仅靠行号去重容易漏掉重复，按关键词去重又可能误合并不同问题。

一个可检查的标注记录可以包含：问题编号、触发条件、受影响行为、证据位置、建议修复范围，以及它与其他评论的关系。保留争议项，不强迫每条评论立即归入确定真或确定假。

审阅时还要防止“措辞更长”获得额外信用。多补充一段说明可能降低理解成本，但它没有自动增加缺陷覆盖率。评论质量、覆盖率和解释清晰度可以分别观察，不必挤进同一个计数。

参考集合之外，不自动等于误报

真实PR的参考问题集合很难保证穷尽。一条没有匹配到旧标签的评论，可能是无效噪声，也可能指出了原先遗漏的问题。应保留“未匹配”与“已确认无效”的区别，不能让匹配器直接替代判断。

这正是阅读grounded与augmented指标时值得注意的地方：固定参考集合与新增发现解决的是不同问题。官方方法的具体扩充与判断规则应以资料为准；本文合成代码没有实现新增问题审核。

如果把每个系统自己发现的新增问题加入各自分母，跨系统比较又会遇到口径问题。报告至少应说明参考集合是否固定、新发现如何确认、何时更新版本，以及旧结果能否按同一套标签重算。

平均表现不能替代关键类别检查

一个审查助手可能擅长发现简单测试遗漏，却对并发状态或错误恢复路径较弱。把所有问题汇总成一个平均比例，会让数量多的简单类别遮住数量少但重要的失误。选型时应查看与自己代码最相关的类别。

同样要记录PR大小、语言与可获得上下文。只给diff的任务，与允许读取相关实现和测试的任务并不相同；模型版本、提示词和工具配置变化，也会影响结果。没有这些条件，分数很难解释。

对外部排行榜，先用它筛选值得进一步检查的候选，而不是把第一名当作所有项目的保证。GitHub既发布基准也开发审查产品，这种背景值得知晓，但不能仅据此认定数据正确或错误；仍应检查公开方法与可复现证据。

把人工处理量记在同一份记录里

无效评论会消耗阅读与驳回时间；有效评论也需要核实和修复。可以在有授权的实际试验中记录每次PR的有效问题、重复评论、争议项、遗漏，以及人工处理过程。评论被点击或回复，不等于问题已经被修复。

没有人工时间数据时，不要用评论数乘一个随意设定的分钟数，声称节约了多少工时。先保存未知，再通过同类任务与同样完成标准建立可比较记录。本文没有真实仓库试验，因此不提供效率增长结论。

此前环境式AI的任务验收讨论如何保留执行证据。本篇进一步要求：审查结果本身也要有稳定的计数单位和可复查标签，不能只凭输出看起来丰富就宣布有效。

先约定分母，再看排名

如果要对比两个AI审查系统，先固定PR与版本、参考问题、去重规则和需要观察的类别，再查看覆盖和噪声。保留真实失败与待议项，比只展示一张总分截图更有助于判断它是否适合你的工作流。

若这组可复现计数和问题标注方法帮你更清楚地评估AI代码审查，欢迎通过文末支持区自愿支持。

来源与补发说明

经Google News找到并核对10月5日GitHub原文和官方项目仓库。两幅图与A/B合成示例为原创教学内容；本地计数检查通过，未执行官方基准或比较真实产品。本篇保留2026年10月19日16:00文章日期，实际于当日稍后补发。