AI代码审查崩了：800行PR没人敢细看

你的团队代码审查流程，是为"人类逐行手写代码"的世界设计的。

在那个世界里，一个200行的PR意味着200行的人类判断。审查者的工作是检验这份判断：抓bug、强规范、传知识。审查速度匹配编码速度，一切运转良好。

现在，一个开发者一下午能生成800行代码。PR里是800行AI输出，轻量编辑。审查者的工作没变，工作量变了。

规模上去之后，某个环节一定会崩。这就是那个环节——而解决方案不是"审查得更仔细"。

为什么代码审查曾经有效

要理解哪里在崩，先看为什么曾经有效。

隐含的模型很简单：写代码的人理解代码。审查者不需要从零推导——只需要检查作者漏了什么、规范偏了多少、双向传递知识。

作者责任制让这套机制运转。审查者留言"我们这里不用useEffect做数据获取"，作者学到东西。下个PR就用上了。几个月下来，团队规范通过累积的审查反馈从 senior 传到 junior。

审查速度匹配作者速度。一个开发者一周提3个PR，产生的审查工作量1-2个审查者能深度处理。比例是稳的。

AI介入后，这些假设全都不成立了。

AI怎么改变了计算逻辑

体量

有AI助手辅助的开发者，单日代码产出显著增加。自报数据和已发表的生产力研究差异很大——复杂任务2倍，专注生成类工作最高10倍——但方向性结论一致：单开发者产出量实质性上升。

以前一周提3个PR的开发者，现在可能提15个。审查积压增长速度超过审查能力。审查者面临选择：花更多时间审查（牺牲自己的开发工作），或者草草带过。

大多数团队最后是混合策略：部分PR深度审，大部分浅度审。哪些PR被浅度审是不可预测的。规范违规就这样漏过去。

责任扩散

"AI写的"是一种全新的、真正复杂的责任情境。

开发者仍然负责——是他们提交的PR。但他们可能并没有深度理解每一行。不是从零手敲的；是提示词生成后接受的。他们对代码为什么这样写的 mental model，比逐行手打时要浅。

审查者能感觉到。惯常的问题——"作者这里怎么想的？"——变得更难回答。"他们让AI实现X"这个答案，帮不了你评估方案是否靠谱。

模式不一致性增加

人类开发者偏离规范是渐进、不一致的。开发者A偶尔忘记校验输入；开发者B有时跳过Prisma的字段选择。这些偏差有模式、可预测、可针对性反馈。

AI生成的代码没有这种一致性。同样的提示词，不同时间可能生成不同结构。一个PR里，前半部分用一种错误处理模式，后半部分换另一种——不是因为开发者故意切换，而是因为两次AI补全的上下文不同。

审查者无法建立对"作者习惯"的预期。每个PR都是新鲜的随机性来源。

知识传递断裂

代码审查曾是团队学习的主要渠道。junior 从 senior 的反馈中学；senior 从解释自己的审查决策中学。

AI介入后，反馈循环断了。开发者不再从"我写错了，被指出，改正"中学习，而是从"AI生成了，我接受，被指出，我让AI改"中学习。中间少了一层内化。

更隐蔽的是：审查者自己的学习也在衰减。审查人类代码时，你会看到多种解题思路，对比优劣，形成判断。审查AI代码时，你只看到一种思路——AI的——而且往往是最常见的、最平庸的那种。

问题不是审查本身，是审查的时机

当前的崩溃指向一个结论：事后审查（post-implementation review）对AI生成代码是错位的。

800行已经生成，沉没成本已发生。审查者要么接受（承担风险），要么要求重写（打击作者积极性，消耗双倍时间）。两种选择都糟。

需要的是事前治理（pre-implementation governance）：在代码生成之前，就定义好边界。

事前治理长什么样

不是更重的流程，是更早的决策点。

具体做法因团队而异，但核心结构是：在开发者打开编辑器之前，先回答几个问题——这个功能该存在吗？边界情况有哪些？用什么模式？AI生成时哪些是必须人工检查的？

这些决策从"审查时被迫面对"移到"编码前主动澄清"。AI生成的代码被约束在预定义的框架内，审查者的工作从"猜测作者意图"变成"验证是否符合约定"。

责任也重新清晰：开发者对事前决策负责，AI对生成效率负责，审查者对框架合规负责。

最后

代码审查不是坏了，是用错了地方。它是为人类手写代码时代设计的质量闸门，现在被强行安在AI生成管道末端。

真正的修复不是加固闸门，是把质量控制前移——在代码还不存在的时候。