代码写得比人审得快，这是眼下不少团队的真实处境。于是有人动了念头：干脆让AI来审。卡内基梅隆大学和微软的一篇新论文，给出了一个不太好听的答案——最好的AI代码审查员，也只能在它给出的前5条评论里，抓住71.9%的已知bug。

这个数字来自他们新构建的评测集 CRBugBench。研究团队没有沿用过去的做法，而是搭了1,800个代码审查任务，每一个都对应一次真实提交：这次提交引入了一个bug，而且这个bug已经被人类确认并修复过。

打开网易新闻 查看精彩图片

评测方式也做了调整。Agent在沙箱里审查原始改动，再由AI裁判判断它给出的前几条发现里，有没有点中那个bug。这套流程绕开了旧基准的一个老毛病——拿AI的表现去对标人类的评论，而人类的评论本身可能只是吹毛求疵，也可能压根没发现真正的bug。

五个月，涨了24个百分点

成绩单上最亮眼的是 claude-opus-5，前5条评论命中71.9%的bug。作为对照，五个月前的 opus-4.6 这个数字是47.7%。短短五个月，提升了超过24个百分点，进步速度确实可观。

但论文同时给出了另一组数据，值得所有打算把审查工作交给AI的团队停下来想一想。在某一家公司的私有代码仓库上，同一个Agent的表现最多下滑了25.5%。原因不难理解：这些仓库里的bug，往往需要结合项目本身的上下文才能判断，而不是看一段孤立的改动就能识别。

换句话说，公开基准上的高分，未必能平移到你自己的代码库里。越是大型的、依赖大量背景知识的改动，Agent越容易看走眼。

该把它放在什么位置

论文给出的建议很克制：把审查Agent和人类审查员放在一起用，而不是让它取代谁。同时，把你仓库自己的知识喂给它——尤其是面对大型改动或强上下文依赖的改动时，这一点更关键。

71.9%这个数字，放在"能不能替代人类"这个问题下，显然还不够。它意味着每五个已知bug里，就有一个多没被前5条评论点出来。对于把代码质量当生命线的团队来说，这个漏网比例不是可以忽略的误差。

但换个角度看，五个月从47.7%到71.9%的爬升曲线，也说明这类工具的能力边界还在快速外扩。真正务实的做法，或许不是纠结"AI能不能审代码"，而是想清楚它在你的流程里该站在哪个位置——是当第一道筛子，还是当那个帮你查漏的副手。

至少从这份论文的数据看，现在就把人类审查员请出流程，还早了点。