独立评估AI代码审查工具的实战方法：20个真实PR验证法

每款 AI 代码审查工具都会发一篇满是精确数字的博客文章。"准确率 98%，召回率 87%，线上 bug 减少 40%。"我第一次在真实仓库上运行其中一款工具、收到 30 条评论、其中 25 条是迂腐或错误的之后，就不再相信那些数字了。

供应商的基准测试是供应商自己挑选的评测，在供应商自己挑选的仓库上、用供应商自己写的评分标准来评判。不是没用，但仅此而已。以下是我自己的仓库上决定某个工具是否值得在 CI 中占有一席之地之前，自己跑的方法。

取 20 个已经经过真实人工审查评论的已合并 PR。不要挑肥拣瘦。你想要的是混合：难看的紧急修复、长期的重构、小巧的单行修改。把工具跑在每个 PR 的 diff 上，然后把它的每一条标记分成三个桶：

Real：工具发现了人类审查员会——或应该——发现的问题。

Noise：技术上跟代码相关，但不值得评论。风格上的小挑剔、作者有意忽略的建议。

Wrong：主动给出的坏建议。如果照着做会引入 bug 或安全漏洞。

就这样。不要按评分标准打分。让人类像审查 PR 一样审查工具的输出。

你真正学到的东西

比公开的准确率重要得多的两个数字：

Bad-advice rate（坏建议率）（wrong / total flags）。这是危险的那个。标记出了真实竞态条件、但同时也自信地建议了一个引入更糟糕问题的修复方案的工具，具有负价值，因为你的工程师会不假思索地盖章通过。

Triage burden（分类负担）（noise + wrong）/ total。每条标记都要花时间决定是否采纳。如果只有 40% 的标记是真实的，你的高级工程师就是在替工具做分类。

在其中一个仓库上跑这个测试花了我一个下午。它立刻筛掉了shortlist上的两款产品，并改变了我配置幸存那款的方式。

几乎所有的严重失误都是配置或上下文问题，而不是模型问题。在全仓库上下文上表现良好的工具，在指向单个文件 diff 时崩溃了，因为它看不到调用方的代码。"过度审查"的那款被调优成标记一切，而这种追逐正在打断我团队的讨论线索。默认值是为营销演示调优的，不是为你的审查文化。

用默认配置跑一次 DIY 评测，然后再用工具指向你实际的 CI 设置和你的 PR 风格跑一次。第二次运行才是真正告诉你答案的那个。

在自我选择的基准上发布一个数字很容易。做好那份繁琐的工作——检查一个工具是否真的帮助了你的特定团队、在你的特定 PR 上——才值得你花时间。