上周跟一个带前端团队的朋友聊天，他说了一句话让我印象很深："现在最痛苦的不是写代码，是看代码。"

他的团队半年前全面推了 AI 编码助手。效率确实上来了——以前一周的活，现在两天就能干完。但代码审查（Code Review）的压力也跟着翻了三倍。以前每天审查两三百行，现在动辄上千行。审查者的时间没变，代码量却暴增了。

更麻烦的是，AI 生成的代码有一个特点：看着都对，但你不一定知道它为什么这么写。

这不是个案。我最近跟几个做技术管理的朋友聊过，发现一个共同的焦虑——AI 在加速代码生产，但质量把关的那道门，还是靠人肉。这道门正在被冲垮。

审查的瓶颈不是态度，是带宽

过去十几年，代码审查是软件工程里最被推崇的实践之一。它有效的核心前提是：代码作者能解释自己的思路，审查者通过提问和质疑来发现潜在问题。这是一场人与人的对话，有来有回。

AI 生成的代码打破了这个前提。

审查者面对的不再是一个能解释"我为什么这么写"的同事，而是一堆看起来合理但没人能完全解释意图的代码。你问 AI 为什么这么实现，它可以给你一个事后合理化的解释，但那个解释未必反映真实的决策过程——因为它根本没有"决策过程"，它只是在做概率预测。

结果就是：代码量暴涨，但审查者能真正理解的代码量反而在下降。

一个朋友跟我说过一个真实场景：他们团队的 AI 生成了一个认证模块的代码，审查通过了，上线后才发现一个权限检查的遗漏。不是审查者粗心，是他缺少判断这段代码是否完整的上下文。AI 写了五种路径的处理逻辑，看起来面面俱到，但漏了一种跟业务强相关的边界条件。这种遗漏，人看不出来，AI 更不知道。

"看着都对"是最大的陷阱

AI 生成的代码有一个显著特征：它倾向于产出"平均水平"的代码。语法正确、风格一致、命名规范、能跑通基本测试。但它有几个盲区：

架构合理性。AI 不了解你的系统全貌。它写出来的代码在局部是对的，但可能跟你现有的架构方向冲突。比如它可能引入了一个不必要的抽象层，或者在你已经有一套错误处理机制的情况下又建了一套。

隐式耦合。AI 生成的代码可能跟你系统中其他模块产生微妙的依赖关系，而这种依赖在代码审查的局部视角下看不出来。

安全边界。这是最危险的。AI 对安全的理解是泛化的——它知道要防 SQL 注入、XSS，但不知道你的金融系统里某个字段的值域限制背后是合规要求。

长期可维护性。AI 不关心六个月后谁来维护这段代码。它生成的代码可能用了一个冷门的库、一个即将废弃的 API，或者一种在团队里没有其他人熟悉的模式。

这些盲区叠加起来，形成了一个尴尬的局面：审查者逐行看，根本看不过来；不逐行看，又放心不下。

老办法不管用了

传统代码审查有几个隐含假设，现在都不成立了。

第一个假设，代码量和审查能力是匹配的。一个资深工程师每天审查两三百行代码，给出高质量的反馈。当代码量翻了三到五倍，这个模型就崩了。人的阅读速度和理解速度是有上限的。

第二个假设，代码是人写的。审查者可以通过代码风格、提交历史、commit message 来判断作者的意图和水平。AI 生成的代码没有这些人类线索，审查者失去了很多判断依据。

第三个假设，审查本身是学习过程。好的代码审查不只是找 bug，更是知识传递的渠道——资深工程师通过 review 把经验传给初级工程师。但当代码是 AI 写的，审查变成了"帮 AI 检查作业"，这个教育功能就断了。

那怎么办

我观察了一些团队的做法，有几个方向值得聊。

审查 spec，而不是审查 code。这个思路是：与其逐行读 AI 生成的代码，不如把精力放在审查"需求描述"和"验收标准"上。当实现可以在几分钟内完成，真正值钱的是定义问题的能力。如果 AI 正确理解了需求，生成的代码大概率不会偏太远；如果需求本身就是一笔糊涂账，审查代码就是在做无用功。

这要求工程师在写 prompt 和定义 spec 上花更多时间，而不是在逐行读代码上花时间。

让 AI 审查 AI。用 AI 工具做第一层审查——检查风格一致性、类型安全、常见的反模式、已知的安全漏洞。这不是完美方案，但至少把机械性的工作从人身上卸下来了。人的精力集中在 AI 不擅长的维度：架构合理性、业务逻辑、边界条件。

分层审查。不是所有代码都值得同等强度的审查。AI 生成的 CRUD 代码、UI 组件、测试用例——这些可以让 AI 辅助审查。核心业务逻辑、安全相关代码、架构变更——这些必须由人来把关。区分什么值得人看、什么可以委托给机器，这是一种新的工程判断力。

审查者的角色要转型。过去审查者是"质检员"，逐行检查代码质量。未来审查者更像是"架构审计员"——不一定看每一行，但要看整体的决策是否合理。重点从"这段代码写得对不对"变成"AI 是否理解了需求，实现方向是否正确"。

还有一个没人谈的问题

上面说的都是怎么应对当前的审查压力。但我更担心的是一个长期问题：AI 生成的代码，对团队中初级成员的成长有什么影响？

过去，初级工程师的成长路径是：写代码 → 被审查 → 改代码 → 再被审查。这个过程痛苦，但有效。你在反复修改中理解了系统、积累了判断力。

现在如果初级工程师大量使用 AI 生成代码，然后提交审查，他其实跳过了最核心的学习环节——自己写、自己犯错、自己理解为什么错。

代码审查本来是资深工程师传递经验的主要通道。如果审查变成了"帮 AI 检查作业"，这个传承机制就断了。这不是工具的问题，是工具改变了学习路径，而大部分人还没意识到。

我的判断是：AI 编码工具会让高级工程师更强——他们可以更快地产出和审查代码。但可能会让初级工程师的成长变慢——因为最核心的"写-错-改-学"循环被短路了。

这不是工具的 bug，是需要团队有意识地去设计新的成长路径。也许未来初级工程师的成长方式不再是"大量写代码"，而是"大量审查 AI 代码"——通过理解 AI 的输出、发现 AI 的错误来建立判断力。这条路是否走得通，现在还说不准。

最后说两句

AI 改变了代码的生产方式，但没有改变代码需要被理解这个事实。一个不理解自己代码库的团队，在出 bug 的时候只能抓瞎——而 AI 不会帮你 debug 生产环境里那些诡异的时序问题。

代码审查的终极目的不是"发现 bug"，而是确保团队对代码库保持共同的理解和掌控力。当 AI 能生成无限多的代码时，真正稀缺的不再是写代码的能力，而是理解代码的能力。

审查不是瓶颈，理解才是。