两款 AI 代码审查基准测评结论相反

Google 搜索"最佳 AI 代码审查工具"，结果顶部全是厂商软文。大多数文章把自己的产品排第一，用功能列表而非数据支撑排名。这个 SERP 上真正公布了方法的只有两个页面放在一起读会发现，它们对谁是赢家得出了完全相反的结论。

两个评估，两种胜者

LinearB 的基准测试在两个阶段共测量了 16 个 bug，对每个审查者在四个维度上打分：能力、清晰度、可配置性、开发者体验。报告称 LinearB 产生了最佳的信噪比，并将状态性（statefulness）置于前台——即能够在后续提交使某条评论过时后撤回或修改它。在那篇报告的叙述中，CodeRabbit 捕获了最多的总问题，但产生了大量噪音，反复标记同一模式而不提供上下文。GitHub Copilot 给出了一致的相关建议，但上下文较浅，缺少多文件推理能力。Graphite Diamond 在检测方面表现最弱。

DeepSource 的对比用不同的工具测量了类似的类别。他们在 OpenSSF CVE Benchmark（一个包含 200+ 真实生产漏洞的公开数据集）上运行每个工具，并公布 F1 分数。DeepSource 报告了最高的 F1——84.51%。在那篇报告的叙述中，CodeRabbit 的 F1 仅为 36.19%。DeepSource 指出，Greptile 自我报告的 82% 检出率来自内部基准测试——5 个代码库中 50 个 PR，并非独立验证。

两个厂商、两种方法、两个胜者，而且两份报告都把自己的产品排第一。这是正常的，不应该成为否定任何一个页面的理由。这恰恰是应该去读方法而非胜者的理由。

这两种评估无法直接比较。LinearB 的数据集是内部构建的，bug 列表和评分标准在一份可下载的白皮书中。DeepSource 的数据集是公开的，但它是一个安全语料库：OpenSSF CVE 评分的是审查者是否能检测到真实记录的漏洞。这是一个不同的问题——审查者是否写出了清晰、可用的评论。同一款工具可能在信噪比上胜出，但在针对安全语料库的 F1 上落后，因为这两个指标惩罚的是不同的失败模式。

两个基准测试的一致之处

把两个页面并排阅读是值得的，因为它们在某些方面并不分歧。两个页面独立地得出了相同的维度——区分有用审查者和噪音审查者的维度。

信噪比。两个页面都把它作为决定性质量。一 个审查者找到了 90% 的问题但淹没在每个 PR 数百条评论中，比找到 70% 但只说一次的那个要差。LinearB 称之为"最好的审查者用更少的话说了更多"。DeepSource 将其放在方法论部分的标题附近。这个指标实际上并非关于模型是否捕获了 bug。它关乎信任。开发者会停止阅读他们已经学会忽略的评论，一旦这种情况发生，审查者就在每个 PR 中添加噪音而没有任何贡献。

跨提交的状态性。Pull request 在提交之间会发生变化。把每次提交当作全新开始处理的审查者会让开发者重新争论他们已经解决的问题。LinearB 直接测量了这一点：那些在修复后撤回过时评论并修正意见的审查者，在开发者体验上得分明显更高。那些在每次提交时从零开始的工具在审查时间上付出代价，因为一个本应关闭线程的修复只是开启了一个新线程。

可配置性。两个页面都独立提出了这一点。团队对冗长程度和标准有不同的容忍度，允许团队通过配置调整规则、语气和执行的审查者能融入现有工作流，而非要求改变工作流。LinearB 特别指出，YAML 定义的规则和斜杠命令与更流畅的开发者体验相关。这是高度重视自身编码标准的团队应该密切关注的轴。它区分了适应你规则的工具和将通用规则应用于所有人的工具。这个类别中的审查者，包括 Kodus在内，将规则和信号置于原始发现数量之上——这正是两个基准测试都标记为决定工具是否被采用的可配置性轴。

到首次有用信号的时间。LinearB 测量从 PR 打开到第一条正确、可操作评论的平均时间。快速但错误的评论比慢速但正确的评论更糟，这就是这个指标存在的原因：它防止厂商以牺牲准确性为代价优化响应速度。这在你自己的工作流中计时是一个真正有用的做法，因为它告诉你开发者在审查者做出他们信任的事情之前需要等待多久。

你不会从这两个页面得到一个胜者，也不应该期待一个。你得到的是一个内部评估审查者的检查清单。让厂商回答三个两个已发布报告都隐含的问题。

数据集是什么，你能检查它吗？ DeepSource 给你的是 OpenSSF CVE。LinearBay 给你的是白皮书中包含的 16 个 bug 内部列表。一个无法验证方法的数据只是营销，不是证据。注意这两者都没有排名一个发布者本身也是参赛者的独立基准；那是一个独立的、更高的门槛，我在这个 feed 早期的一篇文章中报道的一个探索性 arXiv 基准试图通过针对独立标注工作流而非厂商自身产品对审查者评分来达到这个门槛。

哪个指标，它惩罚什么？ F1 同时惩罚假阳性和假阴性，这就是为什么安全语料库中的数字与 DevEx 风格评估存在差异。让指标与你购买它来对抗的失败模式相匹配。如果你在假阳性上损失的时间比漏掉的 bug 更多，先优化精确率。如果漏掉的 bug 会进入生产环境，就重视召回率。

审查者是有状态可配置的，还是每次重启然后大喊大叫？ 在这个维度上，两个对胜者有分歧的竞争者完全达成一致。这项一致是两份文档中最具可迁移性的发现，因为它预测了一个工具在你的审查周期中如何表现，而不管哪个厂商恰好在其自身基准测试中排名第一。

更广泛的模式值得命名。生成变得快速和廉价，市场上充斥着审查者。验证得到了相反的待遇。大多数营销仍然针对输出量优化，而非输出是否值得阅读。包含方法的两个排名页面是例外，它们独立得出相同结论：精简的审查、更少的评论、你控制的规则、以及一个记得自己说过什么的审查者。竞争对手之间的这种趋同比任何胜者声明都更有价值。

标注：2026 年 9 月根据上面链接的 LinearB 和 DeepSource 页面核对了声明。