现在，我们团队里有个怪现象。写代码的人，感觉越来越轻松。但是审代码的人，却越来越痛苦。这事儿，不只我们遇到，很多地方都是这样。
AI写代码，速度确实快。GitHub Copilot、Gemini、Claude这些工具，连干了十几年的老工程师都不得不承认：“生产力确实变强了。”但是，事情没我们想的那么好。现实情况是，提交的代码数量暴增。改一个Bug，结果带来三个新Bug。有些代码看起来能跑，其实里面很多多余的东西。最后，有30%的工程细节，成了团队里最耗时的部分。
这些压力，基本都压在了负责代码审查的资深工程师身上。他们得为这些“看着能跑”的代码负责。
最近，Google Chrome和Gemini的工程师Addy Osmani在一个播客里，拆解了这个现象。他的观点，让许多开发者产生强烈共鸣：“AI提高了生产力，但是把代码审查，变成了新的瓶颈。”
AI写的代码，好看不好用
AI在UI界面、业务流程、重复的样板代码方面，效率非常高。一些初级开发者，甚至只要几句提示词，就能让一个界面跑起来。看起来，功能都齐活了。但是，这往往只是“假象”。
比如，AI写的代码，系统边界不清楚。它可能把用户管理和订单处理的代码混在一起。这样，一个地方出问题，另一个地方也受影响。后期修改，要动的地方就很多。这是它的工作原理：AI倾向于把相关的东西一股脑塞进去，不管它们是不是真的应该紧密结合。
而且，它没处理好各种边界情况。比如，用户输入一个空的手机号，或者输入一个超长的地址。AI写的程序，可能直接报错，或者逻辑混乱。它很少考虑这些极端情况。结果，代码在特定条件下就会出Bug，让用户体验很差。
再比如，本来应该是松散连接的模块，AI却写成了紧密连接。订单和库存两个模块，按理说应该各自独立。它们只通过接口交流。但是AI可能把它们紧密地耦合在一起。这样，你改库存模块的一小部分，就得小心会不会影响到订单模块。这就像在拆一个乐高积木，结果发现所有积木都被胶水粘死了，动一个就可能毁掉整个。
还有，安全、鉴权、API秘钥，这些关键部分，AI常常是空的。它不会帮你把这些配置好。环境配置也考虑不周。运维集成，AI也常常忽略。它写的代码，逻辑还可能不一致。今天这么写，明天换个地方又那么写。可维护性？根本谈不上。
Addy Osmani说得对：“你得到一个看起来‘能用’的系统，但它内部结构根本经不起检查。”这些问题，最后都在代码审查阶段暴露出来。所以，资深工程师不得不花更多时间，去一层层剥开AI生成的逻辑。他们得找到AI埋下的所有坑。
这和最近的开发者调查结果一样：大家用AI的越来越多，但是对AI的信任度却在下降。
Google DORA的最新报告就显示：开发者对AI编码的好感度，从两年前的70%，下降到了60%。还有30%的开发者说，他们“几乎不信任”AI的代码。
换句话说，大家都在用AI，但是用的时候都心虚。就像用一个看起来很漂亮，但是随时可能散架的家具。大家都怕它坏掉，而且随时准备去修补。
AI只帮你搞定70%，剩下30%更难
Addy Osmani提出了一个“70%问题”的概念。这个概念很有道理。AI能很快帮你写70%的代码。比如，界面、基本流程、类的结构、简单逻辑，这些它做得又快又好。它帮你省去了很多重复劳动。
但是，还有30%的代码。这些是最难的部分。业务边界、异常处理、系统稳定、长期维护、性能优化、隐藏的Bug，这些都需要人来解决。AI在这方面往往无能为力。它很难理解一个复杂业务的深层逻辑，也无法预判所有可能出现的异常情况。这剩下的30%，才是真正体现工程师价值的地方，也是最耗费心力的部分。
而且，你尝试修改AI写的代码时，可能会出问题。你修一个Bug，结果又出现新Bug。你让AI修，它修好了，但又带来新的Bug。这是一个循环。Addy Osmani叫它“向前一步，向后两步”。这就像你在玩一个推箱子游戏，每推一步，就会发现前面又多了一个箱子。
所以，一定要有回滚机制。当你改动AI代码时，如果出现问题，能马上回到之前的版本。而且，要能检查变量、检查状态。你要清楚AI在每个步骤都做了什么。最重要的是，开发者要亲自准备好修改代码。不要把所有事都交给AI。不然，代码库就会变成一个“黑箱子”，没人能维护。你看不懂它的逻辑，也不敢轻易修改。
别让AI废了你的思考能力
我最担心的，还不是代码本身。而是我们这群写代码的人。过度依赖AI，会让我们变笨。开发者会失去理解代码的能力。也会失去从错误中学习的能力。这就像你长期使用导航开车，最后连家门口的路都不认识了。我们正在逐渐丧失独立解决问题、系统性思考的能力。
为此，Addy Osmani建议开发团队可以尝试：“AI无代码日”。比如，一个冲刺周期里，规定有一天大家都不用AI写代码。目的就是让工程师保持解决问题的能力。也能保持系统性思考的能力。这就像去健身房锻炼我们的大脑肌肉，防止它萎缩。我们不是把所有细节都变成提示词喂给AI，而是要自己去思考。
比如，当你要实现一个复杂功能时，先自己画个流程图，写出伪代码。然后不依靠AI，自己把核心逻辑实现出来。这样可以帮你巩固基础知识，也能发现自己思维上的盲点。
另外，他还建议建立一个“决策记录文件”。AI完成任务后，可以总结关键决策。比如，哪里踩了坑，设计时做了什么取舍。这份文件既能帮助AI下次生成更好的代码。而且，它还能帮助我们重新学习自己的思考过程。这是它的工作原理：先让AI总结它做了什么，然后人来记录和理解这些决策背后的逻辑。这样，你就能看到AI是怎么“思考”的，也能对比自己的思路。
AI写得好不好，看你给它多少信息
有一个很重要的能力，很多人没注意。这就是“上下文工程”。它决定了AI生成代码的质量。
你给AI的信息越多、越有用，它生成的代码质量就越高。这就像给学生考试，你把所有的参考资料都给它，它考出来的成绩自然更好。
上下文不只是你跟AI的聊天记录。它还包括系统提示、文档、项目结构、代码规范。而且，接入外部系统的方法、配置文件、Markdown文档、高质量的示例代码，这些都算。这些信息越多，AI就越能理解你的真实意图和项目背景。
现在很多AI工具，能自动加载文档、链接、代码目录。所以，给AI提供上下文，比以前容易了。你不需要手动复制粘贴所有内容。这是它的工作原理：AI工具会扫描你给定的资源，然后把它们纳入自己的“知识库”中。
所以，不要只写几句提示词，然后就祈祷AI能理解。要把所有相关信息，都塞进AI的上下文窗口里。这样可以帮你更快地得到高质量代码。比如，你要AI写一个用户登录模块，你除了告诉它功能需求，还可以把项目现有的用户表结构、认证接口文档、错误处理规范都给它。AI会结合这些信息，生成更符合你项目实际情况的代码。
另外，测试也很重要。测试是AI写代码的“安全网”。它也能给AI反馈，让它下次写得更好。但是，人必须能看懂AI写的测试。你不能说：“团队测试覆盖率不好，让AI来写测试吧。”这样没问题，但必须有人仔细检查。如果你觉得只靠提示词，就能解决所有问题，那我真的为你担心。因为AI写的测试，可能只覆盖了它理解的常见路径，而漏掉了那些关键的边界或异常情况。
AI没让你效率翻倍，反而让审查工作加倍
网上有人说，AI能让效率提高5倍、10倍。但是，Addy Osmani看过Google内部数据，他得出结论：AI让编码效率提高，远不到2倍。
那些说效率很高的人，通常在做全新的项目。新项目没有历史问题，没有技术债。复杂度也低。这样，AI的效果看起来自然好。就像给AI一个干净的画板，它当然能很快画出漂亮的画。
但是，在真实世界呢？我们大部分时间都在维护那些已经运行了好几年的、错综复杂的旧系统！Addy Osmani明确指出：“即使AI让你能多完成20%工作量，但我们也开始看到一个副作用：代码审查量爆炸。”
而且，代码审查，依赖资深工程师。他们数量有限，时间有限。他们审查代码的模式，还没适应AI带来的代码量。资深工程师需要花时间去理解AI代码的内在逻辑，去发现那些隐藏的“技术债”。这比审查人类写的代码，可能还要费劲。
结果是，初级工程师用AI写得越来越快。AI生成的代码越来越多。待审查的代码排起了长队。资深工程师的审查压力，也呈指数级上升。他们每天面对堆积如山的代码，身心俱疲。
Code Review正在变成新的瓶颈。我们还没找到最好的应对方法。这就像在一条高速公路上，入口的车越来越多，但是收费站却没有增加。最终导致的是整个系统的拥堵。
AI是个好老师，帮你学习旧系统
但是，AI也有好的一面。Addy Osmani表示，他最推荐AI，不是用来写代码。而是用它帮你理解旧系统。
系统里总有你没注意到的地方。AI能帮助你快速补齐这些空白。它可以帮你形成完整、系统的思考模型。这就像你给AI一份系统文档，它能帮你快速提取核心概念，甚至帮你画出架构图。
而且，它也能作为你专属的学习伙伴和思考伙伴。当你对某个模块不理解时，你可以直接问AI。它能给你详细解释。帮你理解一个你不熟悉的模块。比如，你接手了一个老项目，面对一堆陌生的代码。你可以把相关代码片段喂给AI，让它解释这段代码的功能、逻辑和它可能存在的风险。这样，你可以很快对系统形成一个整体的认识，而不是一点点地去啃。
Addy Osmani透露，目前一些AI工具公司正在研究“主动代码建议”。就是AI预测你下一步要写什么，然后提前给出方案。但是，他说这些工具，还需要几年才能达到真正能日常使用的成熟度。所以，现在我们更应该关注如何把AI当作一个学习和辅助工具，而不是完全依赖它来完成所有工作。
