AI让写代码变快，但交付成本没降

用AI生成一个完整的认证流程，包括数据库结构、API路由和单元测试，不到半分钟就能完成。把一个混乱的组件重构成干净的React Hooks，也只需要一段提示词。写代码这件事，看起来已经接近免费了。

但一个“简单”功能从开发到上线仍然要花三周。这中间的落差，几乎每个用AI写代码的团队都遇到过。问题不在于AI生成的代码不能跑，而在于代码从生成到进入生产环境之间，还有大量没有被计算进“写代码”这个环节的工作。

写代码从来不是软件工程里最贵的部分

有人做过一个典型的实验：用AI工具生成一个功能，代码干净、格式整齐，当天下午就提交了合并请求。看起来效率提升了十倍。然后真正的工作开始了。同事花了两天审查这段代码，不是因为代码写错了，而是AI在缓存逻辑里引入了一个微妙的边界情况，两个人一开始都没看明白。部署之后，这段代码又弄坏了一个AI根本不知道存在的遗留系统。接下来的一周，团队都在调试、回滚，把这段“完美”的AI代码改写成能适应真实生产环境的样子。

这个经历说明了一件事：敲键盘写代码，一直是整个流程里最便宜的一环。AI把这一环变得更便宜之后，总成本并没有等比例下降，因为成本转移到了别的地方。

经济学里有个概念叫杰文斯悖论：技术进步提高了某种资源的使用效率，结果这种资源的总消耗量反而增加了。AI让写代码变便宜，团队并没有因此闲下来，而是被要求写更多的代码。以前一周做一个功能，现在同样的时间管理层希望看到五个功能。但软件工程的瓶颈从来不是打字速度，也不是语法。瓶颈是对上下文的理解。AI不知道你们公司三年前为什么选了这套架构，不知道某个微服务为什么脆弱，也不知道两年前离职的那位开发者脑子里装着什么业务逻辑。

成本转移到了三个很少被衡量的地方

第一是审查与信任成本。读代码比写代码难得多。人类写的代码，你可以直接问对方为什么这么写。AI写的代码，你得先逆向理解它的逻辑，才能决定是否信任它。很多团队现在花在审查上的时间，已经超过了以前花在写代码上的时间。

第二是上下文债务。AI是一个出色的短跑选手，但不是一个好的架构师。它能把一个函数写得很好，但不理解这个函数会如何影响仓库里其他五万行代码。AI生成的代码，集成成本非常高。

第三是维护账单。生成代码便宜，维护生成的代码很贵。AI经常写出技术上正确但习惯上别扭的代码，制造出人类难以理解的抽象。六个月后，总得有人去读它。

如果代码便宜了，优化方向就得换

继续优化打字速度已经没有意义。应该把精力放在决策上。

不要直接让AI“把这个功能建出来”，而是让它“给出三种架构方案”。把省下来的时间用来判断哪种方案更适合你们的具体情况。

保护资深开发者的审查能力。当AI能生成上千行代码时，资深开发者的大脑是这些代码进入生产环境前的最后一道关卡。给他们留出足够的审查时间，而不是把审查当成顺手做的事。

把AI用在删除旧代码上，而不是只用来添加新代码。让AI去梳理混乱的遗留系统、补上缺失的测试、重构老模块。用它的速度来降低维护负担，而不是继续堆高维护负担。

AI没有让软件工程变得更容易，它把工作从“写代码”变成了“编辑代码”。编辑代码需要对系统有更深的理解，而不是更浅。如果你不理解AI为你生成的代码，你就不拥有这段代码，是这段代码拥有你。积累下来的债务，迟早要还。

写代码已经变成了一种商品。真正有价值的是判断该建什么、它如何融入整体、以及如何保证它安全。你不需要成为一个打字更快的程序员，你需要成为一个更好的系统思考者。