如果你最近在团队里感受到一种奇怪的现象——写代码的人越来越轻松，审代码的人越来越痛苦——那你并不是一个人。

AI 写代码的速度飙升，GitHub Copilot、Gemini、Claude 等工具让从业十几年的老工程师都不得不承认：“生产力确实变强了。”但现实却没想象中那么爽：PR 数量暴增、改一个 Bug 带来三个新 Bug、“看着能跑”的代码实际上很多冗余，以及最后那 30% 的工程细节变成团队里最耗时的部分。

而承担这一切压力的，往往是负责 Code Review 的资深工程师。

近来，Google Chrome & Gemini 工程师 Addy Osmani 在一档播客中拆解了这种现象，而他的观点让许多开发者产生强烈共鸣：“AI 是在提升产能，但也把代码审查推成了新的瓶颈点。”

你看到的是能跑的 Demo，资深工程师看到的是“技术债定时炸弹”

Addy Osmani 表示，AI 在 UI、业务流程、样板代码等部分极其高效，一些初级开发者甚至能凭几句提示词就让界面跑起来，看似功能完备——但这往往都是“假象”：

例如，不清晰的系统边界、未处理的边界条件、弱耦合被 AI 生成的强耦合替代，或者安全、鉴权、API Key、环境配置全都空着，运维集成也欠缺考虑，更过情况下 AI 生成的逻辑还缺乏一致性，可维护性也很差。

正如 Addy Osmani 所说：“你能得到一个看起来 ‘能用’ 的系统，但内部结构根本经不起推敲。”这些问题最终都会在 Code Review 阶段暴露，于是资深工程师不得不花更长的时间去拆解 AI 生成的逻辑。

这与最近开发者调查的趋势相符：使用率上涨，但信任度在下降。

据了解，Google DORA 的最新报告显示：

l 开发者对 AI 编码的好感度，从两年前的 70% 掉到 60%

l 30% 的开发者表示对 AI 代码“几乎不信任”

换句话说，大家都在用，但大家也都心虚。

AI 帮写 70%，但剩下最难的 30% 砸在你头上

基于这种现象，Addy Osmani 提出了一个概念：“70% 的问题”。

AI 能帮你快速生成 70% 的代码——界面、流程、类结构、基本逻辑。但剩下的 30%，包括业务边界、异常处理、稳定性要求、系统适配、长期维护性、性能优化、隐蔽 Bug 等种种问题，全部需要人来解决。

最可怕的是，当你试图修改 AI 写出的代码时，还很可能进入一种“连锁”模式：

你修一个 Bug → 触发另一个 Bug → 你让 AI 来修→ AI 修好了，但又带来两个新 Bug → 再修，又有 Bug——一整个循环往复。

Addy Osmani 把这称为：“two steps back（向前一步，向后两步）模式”。因此，他强调一定要有可回滚机制、要能检查变量、状态，最重要的是，开发者必须亲自准备好修改代码库，而不是把一切交给 AI，否则代码库将变成“无法维护的黑箱”。

批判性思维被侵蚀？开发者可能越来越不会写代码

除此之外，Addy Osmani 担心的另一件事是：过度依赖 AI，会让开发者失去理解代码与犯错学习的能力。

为此，他建议开发团队可以尝试：“AI Free Sprint Day —— 不用 AI 写代码的一天。”目的就是让工程师保持解题能力和系统思考能力，而不是把所有细节都概括为提示词喂给 AI。

同时，他建议还可以建立一种“决策记录文件”。具体来说，就是由 AI 在每个任务完成后总结关键决策，然后记录踩坑点、设计取舍，以此形成可溯源的知识文件。这个文件既帮助 AI 下次生成更好，也帮助人类重新学习自己的思路。

要突破“AI 的 70% 限制”，核心是：上下文工程

Addy Osmani 强调，有一个容易被忽视但极其关键的能力是：上下文工程。简单来说就是：你能把多少有用信息喂给 AI，它的代码质量就能提升多少。

当然，上下文不仅包括对话历史，还包括：系统提示、文档、项目结构与规范、接入外部系统的方式、配置文件、Markdown、示例代码等等。

如今，很多 AI 工具已经能自动加载文档、URL、代码目录，因此上下文工程比以前更容易做到。所以，“别停留在 Prompt & Pray（写了就祈祷）模式，要尽量把所有相关信息都塞进上下文窗口里。”

此外，他还强调测试的重要性：测试是 AI 编码的“安全网”，也可作为训练 AI 的反馈信号。但同样，人类必须能理解 AI 生成的测试：

“如果你的团队测试覆盖率不好，你可能会说：‘让 AI 来写测试吧。’这没问题，但必须有人仔细 Review。如果你觉得仅靠提示词就解决所有问题——那我真的很担心你。”

AI 真能让生产力翻倍吗？真实数据：没有你想的那么夸张

尽管网上有人吹嘘 AI 加持下“生产力能提升 5 倍、10 倍”，但 Addy Osmani 看过 Google 内部调查、AI 生成代码行数统计、自我感知效率等各种数据，他得出的结论是：AI 提升编码效率远不到 2 倍。

而那些声称 AI 能提升 5、6 倍的人，通常满足一个条件：正在做一个全新的项目，而不是维护已有的旧系统——这样一来，没有技术债、没有历史包袱，复杂度也低，AI 的提升效果自然好看。

那么把 AI 放在真实世界呢？

Addy Osmani 明确指出：“即使 AI 让你能多完成 20% 工作量……但我们也开始看到一个副作用：代码审查量爆炸。”可关键问题是，这类的代码审查通常依赖资深工程师，而他们不仅数量有限、时间有限，其审查模式也尚未适应 AI 暴增的代码量。

结果就是：初级工程师“写得越来越快”、AI 生成代码“量越来越大”、PR 队列越来越长，而资深工程师的审查压力也在呈指数级上升。

“Code Review 正在变成新的瓶颈，而我们还没有找到应对这场变化的最佳模式。”

但并非全是坏消息：AI 能成为最佳“学习伙伴”

观察下来，Addy Osmani 表示，他最推荐 AI 的一点反而不是用来写代码，而是：

l 帮你理解老系统

l 形成完整、系统的“心智模型”

l 作为你专属的学习与思考伙伴

“系统里总会存在你遗漏的部分，而 AI 能帮助你快速补齐思维节点。”

Addy Osmani 透露，目前一些 AI 工具公司正在研究“主动式 AI 代码建议”，也就是类似“预测你下一步要写什么”，提前给出方案。但他也坦言，这类工具还需要几年才能达到真正可日常使用的成熟度。