最近看到一篇论文，标题挺冲的：《The End of Code Review: Coding Agents Supersede Human Inspection》。核心论点是，AI编程Agent已经强到可以替代人类代码审查了——把审查拆成四个功能（缺陷检测、风格执行、知识传递、意识提升），然后逐一证明Agent都能做，结论就是人多余了。

这个论证结构很工整。但读完之后我总觉得哪里不对。

后来想明白了：它把代码审查当成一个检测过程，但审查真正值钱的部分，发生在检测之外。

"我不理解"本身就是发现

一个有经验的工程师看diff，说了一句"我没看懂这里"——这个困惑本身就是审查最有价值的产出。

它意味着代码和读代码的人之间出现了断裂。可能是抽象层级不对，可能是命名不表意，可能是整段逻辑的思路不连贯。困惑不是审查者的能力问题，而是代码的可理解性出了问题。

大模型给不了你这个信号。它永远能"处理"你喂进去的代码，永远能生成一段听上去合理的解释。但它不会因为"看不懂"而皱眉。在生产环境待过的人都知道，那些上线后出事的代码，很多时候不是逻辑错了，而是写得太绕，绕到没人愿意再看第二遍，绕到出了问题没人敢动。

我们以前有次上线后一个支付回调偶发超时，排查了两天。最后发现是三个月前的一次重构里，有个同事把重试逻辑加了但忘了加超时上限——线程池被打满了。那段代码语法完全正确，逻辑在"正常情况"下也能跑。任何AI工具都查不出问题，因为重试逻辑本身没有bug。

是另一个同事在审查的时候随口问了一句："这个重试有没有上限？"当时没人当回事。上线后才意识到那个问题有多关键。

该不该改，比改得对不对更重要

代码审查中最值钱的判断，往往不是"这里有bug"，而是"这个改动真的需要存在吗？"

见过一种场景：审查者看到同事为了修一个问题改了300行代码，第一反应不是"改得对不对"，而是"这300行真的需要吗？会不会只是在治标，三个月后还得回来？"

这种对改动本身的质疑，是代码审查的核心功能之一。那篇论文完全没有涉及这个维度——它预设了被审查的改动是必要的，审查的目的只是验证正确性。

但做过生产系统的人理解，代码审查经常是最后一个（有时甚至是唯一一个）有人停下来想一想"这件事到底该不该做"的环节。

还有一种情况更微妙：代码改对了，但改错了地方。该加在B模块的逻辑被加在了A模块，因为A模块改起来更方便。正确性没问题，但系统的演进方向被悄悄掰歪了。这种判断需要理解业务优先级、团队状态、系统未来半年的走向——这些东西不在代码仓库里。

还有一种能力特别容易被忽略：看出"不在那里的东西"。API契约改了但错误处理没跟上，新逻辑加了但降级方案没配，参数类型变了但调用方没通知。心理学上管这叫"缺席盲视"（absence blindness）——大模型在这类失败上表现尤其差，因为它的注意力天然集中在"存在的文本"上。工具审查的是你提交的东西，而一个经历过几次生产事故的审查者，注意的是你漏掉的东西。

谁写的代码，影响你怎么审

代码审查中有一个被低估的变量：审查者对作者的了解。

一个新来的同事第一次改核心支付模块，和一个十年老手做常规重构，审查的颗粒度完全不同。这不是偏见，而是基于上下文的注意力分配——审查者会根据"谁、改了什么、什么时候改的"来动态调整审视强度。

这不是什么理论，这就是人的本能判断。你看到小李第一次碰鉴权模块，自然会多看两眼；看到老王在做他擅长的性能优化，可能扫一眼就过了。这种动态调节让审查效率最高——有限的注意力用在刀刃上。

AI看到的只是一个diff。它不知道这个人在团队里的位置、擅长什么、上次出过什么问题。那篇论文把所有diff都当作等价输入来处理——这在工程上恰恰是最不合理的假设。

审查是双向的，不是单向传递

代码审查中有一种场景很常见：审查者问了一个问题，作者解释了，审查者说"原来如此"，然后作者想了想，自己把代码改了。

这个过程里，双方都学到了东西。审查者理解了作者的思路，作者通过被提问发现了自己没想清楚的地方。这种共同认知活动产生的共享理解，不是AI生成一段摘要就能替代的。

那篇论文把知识传递定义为"信息从一个人到另一个人"。但代码审查里的知识传递更像是两个人一起把一个模糊的东西搞清楚——讨论过程中产生的新理解，双方事先都不拥有。有时候审查者提出的问题，作者自己也没想过，但一问出来，双方都觉得"确实应该改"。这种化学反应是工具给不了的。

不在仓库里的上下文

"上周这个服务刚出过事故。""下游那个团队下个月要废弃这个接口。""法务说这个字段不能再记日志了。"

审查者脑子里装着大量这类信息，多到他们自己可能都没意识到。这些上下文影响着审查判断，但永远不会出现在diff里。大模型假设代码仓库就是全部上下文——它从来不是。

我见过一种最典型的场景：一段代码在技术层面完全没问题，但审查者因为知道最近刚出过类似的事故，格外敏感，多提了几个边界case的问题。这种"因为最近出过事所以格外小心"的直觉，是一种无法被形式化的经验。AI没有"上周"的概念。

批准意味着什么

最后说说责任。当你知道自己名字挂在审批记录上、出了问题要一起扛的时候，审查的方式是不一样的。这不是合规的形式主义，是真正的skin in the game。

AI签批一个PR不承担后果，也没有动力去较那个真。我见过不少团队在上了AI辅助审查之后，人类审查者的参与度明显下降——"反正AI已经看过了"成了一个心理安全网。但问题是，AI看的是代码本身，而你要为这段代码在生产环境里的行为负责。这两个视角之间有一道不小的沟。

Adaptive Capacity Labs那篇文章里有一句话我印象很深：替代论的套路总是同一个——先把人的工作拆成可量化的功能，再证明机器能做每一项，然后宣布人多余了。但人真正值钱的地方，恰恰在于跨功能的整合能力。

代码审查也是。它同时是一个检测过程、一个协调过程、一个理解过程和一个治理过程。AI可以帮你做检测，但后面三个，目前还只能靠人。

写到这里，我自己也在想：五年后这些判断还成立吗？可能有些会被推翻。但至少在今天，如果有人跟你说"代码审查可以完全交给AI了"，我建议你反问一句——你说的审查，是找bug，还是做判断？