AI 编程工具的背面：写代码的人快了，读代码的人没跟上

最近跟几个朋友聊天，发现一个共同的困扰：

团队用 AI 编程工具之后，每个人的开发速度明显上去了。

但另一件事不太对劲：

代码审查的量在暴涨，质量在走弱。

不是审查的人不认真。 而是"生成速度"和"审阅速度"之间，出现了一个结构性缺口。

速度不对称

传统开发模式下，一个人写一段代码需要的时间，大致是：

理解需求 → 设计实现 → 写代码 → 自测 → 提交。

这个过程里，"写代码"本身可能只占 30%-40% 的时间。 其余时间花在思考和验证上。

现在，AI 把"写代码"的时间砍掉了一大半。

但是，思考和验证的时间没有被砍掉。

结果就是：

代码变多了，但深度理解没有同步提升。 提交频率变高了，但每段代码背后的"设计意图"反而更模糊了。

这对审查者意味着什么？

意味着他们面对的，是更多代码、更模糊意图、更少上下文。

这不是审查者变懒了，而是审查这件事的难度在系统性上升。

AI 写代码的三种质量问题

我观察下来，AI 生成的代码大致有三类毛病：

1. 表面正确，底层错误

代码能跑，测试能过，逻辑看起来也没毛病。

但它选择的数据结构不对。 或者它的错误处理路径有问题。 或者它引入了一个和项目整体架构风格不兼容的依赖。

这类问题最难审查，因为只看 diff 几乎看不出来。 你需要对整个系统有全局理解，才能在代码里闻到"哪里不对劲"。

2. 正确但多余

AI 经常做的一件事是"过度实现"。

你让它写一个列表渲染，它顺手给你加了排序、分页、空状态、骨架屏。 你说"好像只用到列表渲染"，它说"但是写都写了"。

这类代码的坏处不是功能有问题，而是：它增加了维护负担。 未来任何一个人改这段代码，都得先理解"为什么这里多了一个排序逻辑"。

3. 正确但不对齐

同一个项目里，A 用 AI 生成的代码风格和 B 用 AI 生成的，可能完全不一样。

A 的函数式风格，B 的面向对象风格。 A 的 RESTful 设计，B 的 RPC 风格。

每个单拿出来都没错。 但混在一起，整个项目的一致性在瓦解。

代码债的生成方式变了

以前的技术债，是"故意妥协"的结果。

时间不够，先这么写，以后再改。 需求不确定，先硬编码，以后再抽象。 人手不够，先不写测试，以后再补。

这些东西是"有意识的债"。 你知道欠了债，你知道欠在哪里，你也有一个大概的还债计划。

AI 时代的代码债不同。

它是"无意识的债"。

写的人不知道这段代码有问题。 审查的人来不及找出问题。 系统在悄悄积累一种更难追踪、更隐蔽的质量退化。

而且最麻烦的是：你不知道问题在哪里。

你只知道代码在变多。 你只知道改动在变快。 但你没有一个清晰的"债表"。

一个可能的解法框架

坦白说，这个问题没有银弹。

但我看到一些团队在尝试的方向，我觉得值得讨论：

1. 把 AI 生成的门槛提高，而不是降低

有些团队现在反过来做：AI 生成的代码，不是直接提交，而是先通过一层的自动检查。

不仅是 lint 和 test。 还包括：和项目现有代码风格的一致性检查、不必要的依赖引入告警、复杂度突变告警。

2. 在 AI 和代码审查之间加一层"意图注释"

让 AI 在生成代码的同时，生成一段注释：

"这段代码的设计意图是什么、为什么选择这种实现方式、有哪些已知的假设。"

这不会消除审查负担，但会大幅降低审查者的认知成本。

3. 重新定义"Done"的标准

以前"写完代码"就是完成。 现在可能需要在团队层面达成一个新的共识：

"写完代码 + 写完意图文档 + 通过更严格审查"才算完成。

这会让交付变慢。但如果做得好，能在源头上控制代码债的生成速度。

最后

AI 让写代码的门槛降到了历史最低。

但读代码、审查代码、维护代码的门槛，本质上没有被降低。

这个不对称如果不被正视， 我们可能会在未来几年， 看到一大批"写得很快、但没人愿意维护"的代码库。

而那不是 AI 的错。 是我们用 AI 的方式，还没有跟上。

互动

你的团队在用 AI 编程工具吗？代码审查的压力有没有变大？你们是怎么处理的？