Pull request这个机制快20岁了，比很多现在死守它的程序员的工龄都长。审查代码这件事，看起来像软件工程里永远不会变的一环，其实不然。Google直到2006年前后才开始内部推代码审查，早年的Windows软件出货时，可没经过今天这种层层审核。说到底，代码审查是我们自己发明出来的手段，为的是在集成前抓住缺陷、带一带新人、打破知识孤岛——结果走着走着，在很多团队里就变成了合规仪式、守门表演，甚至是纯粹走过场。

现在的问题是：审查卡在了合并前的唯一一个节点上。你问任何人代码审查在哪一步，答案几乎本能地蹦出来：就在合并之前。不是前面，也不是后面，管你提交里塞了多少改动，就卡在流水线那个固定的位置。在ThoughtWorks这样把主干开发、测试驱动开发和结对编程当信仰的团队里，审查的收益其实在结对过程中就持续兑现了，不需要等几周后有人终于打开一个500行diff。只要测试足够，流水线变绿就已经传达了很多信号。

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

但这个“不要把审查只押在合并前”的说法算不上新鲜。真正缺的，是一个推着你不得不改的外力。而这个外力现在来了——当能自动生成代码的智能体一个下午就能吐出一整个功能时，你真正该在意的漏洞就不在最后的diff里了，而在开发者向工具表达意图的那一刻。等到diff出现，你审查的已经是几小时前那个决定留下的后果，值好几千个token。

这正是为什么有人喊出“代码审查卡在了合并上，AI是那个把它推到上游的强制函数”。当机器成为写代码的主力，审查的重心必须前移，移到意图被锁定的地方——可能是范围描述、明确的排除项、验收标准，甚至直接藏在开发者给AI agent输入的提示里。你得去读那些artifact，去捋清prompt对话中的决策树，而不是再像过去一样盯着一个拼盘diff找补丁。

我们正在重新发明代码审查，就像20年前发明它时那样。只不过这一次，问题的规模已经变了，而解决思路不是退回手工逐行读码，而是把质量决策重新安插回它本该站立的位置——在代码被写出来之前。