最近几个月，一个趋势在我身边越来越明显：团队里用 Cursor、Copilot、Claude Code 的人越来越多，但大家聊的不再是"AI 生成的代码有多好"，而是"review AI 代码有多累"。

一个同事上周跟我吐槽：以前 review 同事的代码，至少能理解他的思路，知道为什么这么写。现在 review AI 生成的代码，逻辑上没毛病，但总觉得哪里不对——命名风格不统一，错误处理过度防御，有些地方用了团队从没用过的设计模式，还有些地方莫名其妙地绕了一圈。

他说了一句让我印象很深的话："我感觉自己不是在 review 代码，是在面试一个永远不累的实习生。"

这句话点破了一个很多人还没意识到的事情：AI 编码工具正在把工程师的核心工作从"写代码"变成"审代码"，而大部分团队还没有为这个转变做好准备。

代码审查量在暴增，但审查能力没跟上

先说一个最直观的数据。Cursor 官方说他们的用户已经有超过 50% 的代码是 AI 生成的。我自己团队的感受也差不多——一个中等复杂度的需求，以前可能写两天，现在用 AI 辅助，大半天就能出初稿。

但"出初稿"和"能上线"之间，隔着一道巨大的鸿沟。

以前代码是人写的，reviewer 和 author 共享同一套思维模型。你看到一段代码，能猜到作者为什么这么写——可能是因为性能考虑，可能是因为之前的 bug 修复，也可能纯粹是个人习惯。这种共享上下文让 review 效率很高，很多时候扫一眼就知道有没有问题。

AI 生成的代码完全不同。它没有上下文，没有历史包袱，没有"上次这个接口超时了所以加了个缓存"这种隐性知识。它生成的代码是基于训练数据中的"最佳实践"——但你的项目不是最佳实践的场景，你的项目有自己的约定、自己的技术债、自己的妥协。

结果就是：review AI 代码需要比 review 人的代码花更多精力。你得逐行确认它的假设是否正确，它的错误处理是否符合团队的约定，它引入的第三方库是否真的需要，它的性能特征是否在你的业务场景下成立。

代码产出速度提升了 2 倍，但 review 的工作量可能增加了 3 倍。这个剪刀差，很多团队还没有意识到。

从写代码到审代码，是两种完全不同的能力

写代码是一种建设性能力——你知道要做什么，然后用代码把它实现出来。重点在于构建、组织、表达。

审代码是一种批判性能力——你得理解别人的意图，找出潜在的缺陷，评估方案的取舍。重点在于质疑、分析、判断。

这两种能力需要的思维方式是不同的。写代码的时候，你在一条路上往前走；审代码的时候，你得同时考虑多条可能的路径，然后判断当前选择的是不是最优的。

大部分工程师在前五年的职业生涯里，主要训练的是写代码的能力。审代码？那不就是看看有没有 bug 吗？

不是的。好的代码审查至少包含四个层次：

第一层：正确性。这段代码做的事情是对的。逻辑没有错误，边界条件考虑到了。

第二层：一致性。这段代码和项目的整体风格、约定、架构决策是一致的。不会引入新的范式，不会让后来的维护者困惑。

第三层：可维护性。这段代码在六个月后还能被理解和修改。命名清晰，抽象合理，没有过度工程也没有过度简化。

第四层：系统影响。这段代码对整个系统的影响是什么。性能、安全、向后兼容、部署风险，都在考虑范围内。

AI 生成的代码通常能通过第一层检查——它的逻辑大多是对的。但第二到第四层，是 AI 的盲区。它不了解你团队过去三年积累的技术债，不知道某个接口其实有隐藏的限流策略，不清楚某个模块正准备重构所以不应该新增依赖。

这些判断，目前只有人能来做。

团队结构会怎么变

如果"审代码"成为工程师的主要工作，团队结构必然要跟着调整。

我观察到的第一个变化是：初级工程师的成长路径被压缩了。以前，初级工程师通过写大量代码来积累经验——踩坑、修 bug、被 review、改进。现在 AI 把写代码的门槛降低了，初级工程师可以直接产出"看起来还行"的代码，但缺少了"从零开始构建"这个训练过程。就像一个学生用计算器做算术——答案是对的，但数感没有建立起来。

这不是说初级工程师没用了，而是说他们的学习曲线需要重新设计。可能需要刻意安排一些"不用 AI"的训练任务，就像学开车时先练手动挡一样。

第二个变化是：高级工程师的价值在急剧放大。AI 时代，能写代码的人（或者说能借助 AI 快速出活的人）变多了，但能做高质量代码审查的人还是那些。一个优秀的高级工程师，能在 review 中发现 AI 代码里隐藏的假设错误、架构冲突和安全隐患，这种能力的价值比以前更大了。

第三个变化是：团队需要建立新的知识传递机制。以前 code review 本身就是一种知识传递——高级工程师通过 review 把经验传递给初级工程师。现在如果大量代码是 AI 生成的，review 的重心从"教你怎么写"变成了"告诉你为什么不能这么写"，传递的知识类型变了，效率也可能下降。

几个实践层面的建议

我不是来说问题的，也分享几个我在实践中觉得有用的做法。

建立 AI 代码的专项 review checklist。不同于人工代码的 review 重点，AI 生成的代码需要额外关注：是否引入了不必要的依赖（AI 喜欢用库解决问题），错误处理是否过度防御（AI 倾向于给每个操作都加 try-catch），命名是否符合团队约定（AI 的命名经常和项目上下文脱节），以及最关键的——是否有更简单的实现方式（AI 有时候会把简单问题复杂化）。

控制 AI 代码的单次提交粒度。一个人一天用 AI 生成了 2000 行代码然后一次性提交，这种 review 是灾难性的。建议拆成更小的提交，每个提交聚焦一个具体的变更意图，这样 reviewer 才能有效评估。

投资团队的技术决策文档。AI 不了解你团队为什么选了这个技术栈、为什么做了这个架构决策、哪些技术债是有意保留的。把这些写成文档，一方面帮助 AI 工具更好地理解上下文（如果你用的是支持项目上下文的工具），另一方面也是给新人的一本"团队使用手册"。

定期做 AI 代码的质量复盘。每个月回顾一下：AI 生成的代码在线上出了什么问题？有哪些隐藏的缺陷是 review 时没发现的？这些复盘能帮团队逐渐建立对 AI 代码特征的集体认知。

这件事的本质

说到底，AI 编码工具带来的不是效率问题，而是认知分配问题。

以前，写代码和审代码是同一个人（或同一类人）在做。你的编码能力和审查能力是同步成长的。现在 AI 把编码的部分接管了一大半，但审查的部分完全留给了人。如果团队和个人不主动调整，就会出现一个尴尬的局面：代码越出越快，质量控制的瓶颈却越来越大。

这不是 AI 的错，也不是工程师的错。这是技术变革带来的结构性调整，每个团队都会经历，只是早晚的问题。

我的判断是：未来两三年，"代码审查能力"会成为工程师考核中权重越来越高的指标。那些能把 AI 当工具用好、同时能把好质量关的工程师，会比现在更稀缺，也更有价值。