AI 代码审查太吵，会让真问题被忽略

一年前，我们给每个 PR 都启用了 AI reviewer。上个月，我们关掉了它的大部分检查。不是因为它说错了，而是因为它太吵了。噪声会让代码审查工具逐渐失去效力。

这种退化是可以预见的

第一周：大家会认真读每一条评论。第三周：bot 指出第 41 行有个格式小问题、第 88 行可能出现 null，还对一个变量名提出了疑问。三条里有两条都是无关紧要的细枝末节。到了第六周，你直接滚到页面底部，看看它有没有阻止合并，其余内容一概跳过。

这就是陷阱。bot 没有骗你。它只是对每份 diff 都运行自己知道的所有检查，而其中大多数检查的 precision 都很低。于是，信噪比不断下降，直到这些评论成了没人留意的背景。

然后，它抓到了一个真正的问题——却没有人读那条评论。

在这里，precision 比 recall 更重要

对 review bot 来说，recall 是个错误的优化目标。你不需要它找出所有问题；你需要的是，它说出来的每件事都值得你停下来看看。一个每次发言有 80% 概率说对的 bot，大家会读它的评论。一个每次发言只有 40% 概率说对的 bot，则会逐渐把大家训练成忽略它的人。

关键在于减少低置信度规则的触发。代码风格上的小问题应该交给 linter，而不是写进 PR 评论。对代码意图的猜测应该作为建议提出，而不是放进阻止合并的讨论线程。bot 默认应该保持安静，只有发现能通过机械检查确认、且置信度很高的问题时，才应该明确发声。

高置信度检查从哪里来

经过筛选后能留下来的检查，都有客观依据。它们说的不是“这里可能不安全”，而是“代码返回 200，但契约规定的是 201”——这是一个事实，可以对照机器可读的信息源核验。这类检查的误报率接近零，所以 bot 一旦发声，就确实有问题。

对于 API 变更，这项检查就是契约漂移检查。它在本地运行成本很低，却是人类靠肉眼无法可靠检查的事情。我们保留了这项检查，去掉了那些针对变量名的评论。

打开你的 review bot 的历史记录，按规则统计：人类有多频繁地反驳或忽略它。命中率最低的规则，最先关闭。最终，你会得到一个只在五分之一的 PR 上发表评论、而不是每个 PR 都发表评论的 bot——而当它真的发表评论时，大家会认真读。

一个没人读的 reviewer，比没有 reviewer 更糟，因为它会制造出“已经有人检查过了”的错觉。你上一次认真读完 AI reviewer 留下的每条评论，是什么时候？

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。