AI 代码审查：它能抓到什么，又会漏掉什么

代码审查是语言模型最自然的用武之地之一。输入是文本，任务是仔细阅读，而疲惫的人类审查员在漫长一天结束时设下的标准也并非高不可攀。把一个模型扔到 pull request 上，它产出的评论会和一位用心的工程师留下的几乎一模一样。问题不在于 AI 审查是否让人觉得有用——它确实有用——而在于它能否抓到真正重要的东西，以及它留下的评论是否值得花时间去读。本文将逐一梳理 AI 审查能可靠抓到什么、会在哪里悄悄失手，以及如何把它嵌入到真实的工作流程中。

AI 审查员真正能抓到什么

AI 审查最擅长的领域，是那种局部的、机械性的层面——人类觉得无聊因而草草掠过的部分。差一错误、未处理的 null 情况、参数顺序写反、可能失败的调用缺少错误处理、忘记关闭资源的循环、编译器抓不到的变量名拼写错误——这些都正好落在它的射程之内。模型读到第两百条评论时，依然和第一条一样耐心地逐行阅读，而这恰恰是人类注意力开始涣散的地方。

它在表层一致性上也很出色：命名与周围代码不符、同一个函数用两种不同的方式做一件事、注释与下方代码已经对不上。这些都是实实在在的改进，而且比人类审查员来得更快、更统一。

它会在哪里悄悄失手

失败之处比成功之处更耐人寻味，因为它们从输出里看不出来。最重要的一点是架构判断力。AI 审查员读的是 diff，而不是整个系统。它不知道这个模块下个季度就要废弃，不知道这个模式是为匹配某个外部约束而刻意选择的，也不知道它建议的那个"聪明"的简化会破坏三个文件之外的某个假设。它评估的是眼前的这处改动，而真正的审查很大程度上关乎的是这处改动究竟该不该存在。

第二个悄无声息的失败是意图。一个理解代码"应该"做什么的审查员，能看出它在某些细微之处做了别的事。模型只能从代码和描述中推断意图，所以一处内部自洽但解决了错误问题的改动会一路畅通无阻。代码是正确的，只是它在错误的事情上正确。

自信却错误的评论

最快侵蚀信任的失败模式，是那种自信满满却又错误的评论。模型会标出一个根本不存在的"bug"，建议一个会引入真实 bug 的"修复"，或者坚称一个完全安全的模式很危险。这些读起来都和正确的评论一样权威，因为流畅与准确并不相关。一个信任工具的初级工程师可能会老老实实地去"修"本来能工作的代码；而一个资深工程师则学会了对工具打折扣，这又慢慢地把它正确的评论也变成了噪音。

实用的防御手段在于框定方式。把 AI 评论当作待评估的建议，绝不当作必须服从的裁决。代码的责任始终在作者身上。一条作者两秒钟就能驳回的评论是廉价的；一条引发不必要改动的评论则代价高昂。把工具调向更少、更高置信度的评论，通常胜过把它调向"什么都抓"。

信噪比问题

决定 AI 审查能否在团队中存活下来的最大单一因素，是评论的数量。一个在 pull request 上留下四十条评论、其中大多是琐碎风格建议的审查员，会训练所有人把整条评论串一并折叠、看都不看——包括那两条真正要紧的。噪音不只是浪费时间；它会主动掩盖信号。"多抓一点"的本能，正是扼杀这个工具的本能。

成功的团队对范围毫不留情。他们把 AI 审查员对准它强大而可靠的类别——正确性、错误处理、明显的安全失误——并明确压制那些它噪音很大、或已有现成工具做得更好的类别。格式问题交给 linter；让 AI 审查员去评论格式，无非是一个更慢、更不可预测的 linter 罢了。

它对人类审查员意味着什么

还有一个更微妙、值得点明的影响：AI 审查员会改变人类关注的对象。如果所有人都假定模型抓住了机械性的 bug，人类审查员就会漂向更高层次的关切——设计、意图、契合度。这大体是好事，因为那恰恰是人类增值最多、模型增值最少的地方。但这取决于模型确实可靠地抓住了机械层面，也取决于人们没有过度信任它。风险在于出现一道缝隙：人类以为 AI 检查过了，而 AI 的检查其实很肤浅。

这正是诸如 NIST AI 风险管理框架（NIST AI Risk Management Framework）之类的风险框架反复强调的同一课：明确系统中每一部分各自负责什么，并让人类监督的程度与出错后果相匹配。一个拼写错误溜过去是廉价的；一处有缺陷的授权改动因为所有人都以为有人盯着而溜过去，则不然。

如何用好它

行之有效的部署方式，是把 AI 审查当作第一道筛查，而非审查本身。它在人类查看之前运行，清掉机械性的问题，把一份更干净的 diff 交给人类去思考。它被限定在自己的强项之内，被调成产出少量高置信度评论，并以让作者放心驳回的方式来框定。没有人仅凭一个 AI 的批准就合并代码，也没有人把一条 AI 评论当作定论。

至关重要的是，人类审查并不会消失。模型负责那个受益于不知疲倦关注的层面；人类负责那个受益于理解系统、意图与权衡取舍的层面。这样使用，二者就是互补而非冗余。一旦把 AI 审查当作人类判断的替代品，它就会一边看似抬高标准、一边悄悄拉低标准。

总结

AI 代码审查在局部的、机械性的层面上确实有用——null 检查、错误处理、明显的失误——而在架构、意图，以及判断一处改动究竟该不该存在这些方面，则确实薄弱。它最危险的产出是那种自信却错误的评论，最常见的失败是把真正的信号淹没在琐碎的噪音里。把它限定在强项之内，调成少量高置信度评论，框定为建议而非裁决，并把模型无法提供的那部分判断留给人类审查。做到这些，它就能加快审查、抓住疲惫的人类会漏掉的东西。跳过这些，你花在和工具争辩上的时间，会比它节省的还要多。