AI 让写代码快了 30%，为什么软件交付反而更难了？

2025 年 5 月 28 日，SegmentFault 上一篇帖子在开发者圈引爆了讨论。

一位国内开发者写了一篇文章叫《用 AI 写更好的代码，但更慢了》。核心发现只有一个：AI 让写代码快了 30%，但整个软件的交付速度没有同步提升，甚至变得更难预测。

这不是一个人的感受。越来越多的技术团队正在经历同样的悖论。

一个团队的血泪审计

腾讯云开发者社区记录了一个典型案例。

某国内团队在使用 AI 编程工具半年后，做了一次全面的技术债务审计，结果让所有人沉默：

• 代码总量 23000 行，AI 贡献了 18000 行
• 过去 3 个月发生 7 次线上故障，其中 5 次的根源直接追踪到 AI 生成的代码
• 70% 的 AI 代码在新功能扩展时需要推倒重写
• 团队本以为 AI 帮忙省了 2 个人月，实际上多花了 1.5 个人月给 AI 代码擦屁股

团队的资深架构师直接摔了键盘：“我原来是做架构设计的，现在成 AI 的全职保姆了。它写一堆看似能跑的屎山，我得给它改错、重构、加测试、写文档、查漏洞。我不是在用 AI 提效，我是在给 AI 打工。”

数字不会说谎。省下的 2 个人月是"写代码"的账，多花的 1.5 个人月是"改代码"的账。合在一起，净亏损 1.5 个人月。

这不是 AI 的失败，这是我们使用 AI 的方式出了问题。

三个被忽略的成本

审查成本：代码对了，但"为什么对"你不知道

AI 生成的代码初看没问题——逻辑通顺，格式工整，命名规范。但你真的敢直接合进主分支吗？

一位技术 Leader 在阿里云开发者社区写道：“AI 可以帮你把代码写出来，但它不会自动替你承担工程责任。代码只是软件系统的一部分，一个真正可交付的软件还要考虑异常处理、边界条件、性能瓶颈、安全漏洞、向后兼容、监控告警。”

AI 没有帮你考虑这些。它只是生成了一段"看起来能跑"的代码。而审查这段代码是否真的能跑、会不会在边界条件下炸、有没有埋下安全漏洞，所需的精力往往比从头自己写还要大。

为什么更大？因为你不仅要理解代码做了什么，还要理解 AI 为什么会这么写。

你自己写代码时，每一个决策的"为什么"是内化的——这个 if 写成 >= 是因为需要包含边界值，这个锁放在这里是因为并发场景下 X 和 Y 不能交错。AI 写的代码呢？"为什么这里用了 >=？是 AI 理解了我的需求？还是随机采样的结果？还是误解了需求但恰好对了？"你必须逐一判断。

学术上这叫 program comprehension（程序理解）。一个程序员理解一段代码的时间，正比于这段代码的意图复杂度，而不是语法复杂度。你自己写的代码，意图复杂度接近零——你就是意图的来源。AI 写的代码，意图复杂度是满的——你必须逆向工程那个并不存在的"AI 为什么要这么写"。

更讽刺的是，AI 代码的结构往往是"对的"——语法正确，风格整洁。这种表面的规整性恰恰麻痹了审查者。你自己的代码如果有一个 hack，你会警觉——因为你知道自己偷懒了。AI 的代码看着规规矩矩，反而让你放松警惕，以为"它想清楚了"。

编码和交付之间的断层

软件开发从来不只是写代码。

一个完整的交付流程是：需求分析 → 架构设计 → 编码 → 测试 → 代码审查 → 集成 → 部署 → 运维。AI 目前主要加速的是"编码"这一个环节。

一位 CTO 打了个形象的比方：“就像你把炒菜的速度提升了 30%，但买菜、洗菜、切菜、摆盘、上菜的速度都没变。客人不会因为你炒菜快了就觉得上菜快了。”

软件交付也是一样的逻辑。打字快了，不等于交付快了。

"先试后想"的陷阱

以前写一个功能，你需要先想清楚架构再动手。现在呢？让 AI 先生成一版，看看效果再说。

这种模式短期内看起来效率极高——不用想，先出东西。但长期来看，它在系统性积累技术债务。代码是快了，但架构乱了。功能是上了，但系统复杂度指数级上升。

一位技术负责人这样描述：“AI 让’动手’的门槛降到了零，但拉高了’思考’的要求。以前你不会写的东西就不敢动，现在 AI 帮你写出来了，你以为问题解决了，其实只是把问题从代码层面转移到了架构层面。”

数据不会说谎

SonarSource 的全球研究显示，到 2026 年 75% 的技术决策者将面临中度到严重的技术债务危机，比 2025 年增加了 25 个百分点。

中山大学与阿里巴巴的联合研究给出了更直接的证据：大多数 AI 模型在 75% 的代码维护任务中会破坏原本正常的代码功能。

两组数据拼在一起，揭示了"快了 30% 但交付更慢"为什么不是悖论而是必然：AI 加速了代码的产出，但没有加速对代码质量的把控。产出越快，质量越低，技术债积累越快，下一轮迭代就越慢。

阿里云开发者社区一篇文章总结得最精炼：“AI 编程解决的是’写得快’，不是’交付稳’。代码可以生成，工程不可省略。”

当门槛降到零：Vibe Coding 的繁荣与陷阱

如果说上面的讨论还是在"有经验的工程师使用 AI"的语境下展开的，那 vibe coding 则是把这个问题的危险程度又抬升了一个数量级。

为什么 Vibe Coding 火了

第一，Demo 经济和社交媒体的完美匹配。

AI 能在 30 分钟内给你一个"看起来能跑"的东西。而"看起来能跑"恰好是录一段 60 秒短视频所需的一切——登录页面、几个 CRUD 操作、一个好看的 UI。Twitter/X 上充斥着"我用 AI 一天做了个 SaaS"的帖子，展示的全部是 happy path。

没有一条展示的是：这个登录在 10 个并发下会不会丢 session，那个文件上传在文件超过 2G 时是静默失败还是直接 OOM。

Demo 和产品之间的差距，以前只有工程师知道。现在 AI 让非工程师也能触达 Demo 阶段，但他们不知道 Demo 之后是什么。这不是他们的错——他们没经历过运维凌晨三点被叫醒的感觉。

第二，"看起来对了"的欺骗性比"编译过了"更强。

传统编程的反馈循环是：写代码 → 编译/解释 → 报错 → 修。每个报错都是对你心智模型的修正。

Vibe coding 的反馈循环是：描述需求 → AI 生成 → 看 UI 截图 → 功能跑通了 → 发推。

"功能跑通了"意味着 happy path 通了。但没有任何反馈告诉你：输入 2000 个字符会怎样、并发写同一条记录会怎样、网络断了会怎样、数据迁移失败回滚策略是什么。传统开发中编译器、类型系统、linter、测试框架组成的负反馈网络，在 vibe coding 里被整个绕过了。

第三，门槛降到零之后，第一批涌进来的一定是"不知道自己不知道什么"的人。

有经验的工程师知道一个管理系统的上线意味着什么——nginx 配置、JDK 版本兼容、路径问题、配置区分环境、数据库连接池参数、日志轮转、监控告警、备份策略、灰度发布。

一个五年经验的工程师看到一个 AI 生成的项目，脑子里自动弹出 15 个"这玩意上生产会炸"的风险点。但一个第一次"写代码"的人，心智模型里甚至没有"生产环境"这个概念。在他们看来，localhost:3000 上跑通了 = 做完了。

这不是能力问题，是认知框架还没有建立。

部署：那层纸捅破了才知道疼

AI 写的代码默认运行在一个"完美环境"里。这个环境没有操作系统差异，没有网络拓扑，没有权限问题，没有防火墙，磁盘永不写满，内存永不泄漏，时间永远是 UTC+8。

但真实世界不是这样的。

你写了个管理系统，AI 帮你把配置文件写死在了 D:\config\app.conf。在本机跑得飞起。但服务器是 Linux——没有 D 盘。JDK 版本是 17 而不是你本机的 21，那个新 API 不存在。数据库连接池的默认参数在你本机 SSD 上没事，到了服务器上机械盘 + 远端数据库，连接数直接打满。开发环境的密钥写在代码里，上生产需要走配置中心但你根本不知道什么是配置中心。

传统软件工程里，写代码可能只占 20% 的工作量。剩下 80% 是：

• 搞清楚"要做的东西到底是什么"（需求）
• 搞清楚"改动应该放在哪一层"（架构）
• 搞清楚"这东西在生产上会不会炸"（运维心智）
• 搞清楚"一年后别人能不能看懂"（可维护性）
• 搞清楚"数据错了怎么恢复"（容灾）

而这 80% 的能力，不可能通过 prompt 获得。它只能通过被生产环境毒打过来获得。凌晨三点被 P0 告警叫醒，翻遍日志发现是一个 AI 生成的正则表达式在特定输入下进入了灾难性回溯吃满了 CPU——这种经历会让一个人永远记住什么叫"看起来能跑 ≠ 能跑"。

Excel 让所有人都能建财务模型。一个刚毕业的分析师能半个小时拉一个看起来很专业的现金流预测。但一个在投行干了十年的 MD 看一眼就知道：你永续增长率假设和行业基准差了两个标准差，折旧摊销的 tax shield 没考虑新税法，WACC 计算用的是账面值而不是市场值。

工具降低了操作门槛，但判断力门槛纹丝不动。Vibe coding 对软件工程做的，就是 Excel 对财务建模做的事。

终极软肋：出了 bug 怎么办

这让我想到了 vibe coding 最致命的软肋——生产故障的响应链路被系统性地拉长了。

两条链路

传统开发的故障响应链路是这样的：

生产告警 → 看日志 → 脑子里定位到模块 → 定位到代码行 → 修 → 上线

这个链条能短到 5-10 分钟，不是因为程序员聪明，而是因为代码的逻辑在他脑子里的投影是完整的。他写那段代码的时候，脑子里反复推演过：这个 if 为什么写成 >= 而不是 >，这个锁为什么放在这里，这个 SQL 索引走的是什么。当告警响起来的时候，他甚至不需要看代码，脑子里直接弹出候选列表——“大概率是那个 Limit 条件在极端情况下没有命中索引”。

Vibe coding 的链路是这样的：

生产告警 → 看日志（还不一定看得懂） → 组织 prompt 描述现象 → 
AI 从头读代码 → AI 推测（可能错误） → 生成修复 → 
看不懂修复逻辑 → 跑一下试试 → 好像好了？ → 
但其实改出了另一个 bug → 循环

这不是 30% 的效率差异，这是数量级的差异。一个本来 5 分钟能定位的 bug，经过两层转述（人→AI→代码）变成 2 小时还不一定修对。

三层信息损耗

第一层：现象描述。

一个经验丰富的工程师看日志 NullPointerException at line 247，脑子里已经浮现出是哪条数据链路、哪个上游服务没传这个字段、或者哪个并发场景下对象被提前回收了。

一个 vibe coder 看同样的日志，只能截图发给 AI：“报这个错了，帮我修一下”。AI 不知道这个 null 在真实流量里的分布——是凌晨零点跑批独有，还是某个地区的数据源格式特殊，还是某个第三方回调的 payload 不按文档来。

第二层：上下文重建。

传统程序员不需要"重建上下文"——上下文一直在脑子里。AI 每次对话都要从零开始读代码、理解逻辑、做推断。你每一次修 bug 都是一次冷启动。

第三层：验证盲区。

AI 生成修复后，vibe coder 没有能力判断这个修复是否正确。不是不想判断，是没有判断所必需的因果模型。他不知道改了这个 null check 之后，下游依赖这个 null 做空值判断的函数会不会行为变了。

传统程序员能在大脑里做符号执行——“如果这里返回空列表了，那边那个循环就不会进，那个状态就不会更新，等下个请求来的时候状态就是脏的”。这个能力不是天赋，是被线上事故反复训练出来的条件反射。AI 目前不具备，而 vibe coding 的使用者也没有。

心里没底

你说的"心里有底"，是软件工程里最被低估的价值。

一个亲手打磨过代码的人，出 bug 的时候，马上知道大概对应哪段逻辑，能根据复现操作精准找到可能的故障点。这种底气的来源不是文档、不是注释、不是测试覆盖率，而是代码在脑子里有一个活着的、可运行的、可推理的投影。

AI 写的代码，vibe coder 看不懂。有限的测试下确实没问题。一旦上生产出了 bug，又得从头和 AI 描述问题，AI 从头读代码，分析一个多小时都不一定精准定位，甚至对描述的 bug 都不一定能真正理解。

问题转述给第三者，和直接承接问题开始处理，这是两种完全不同的排障效率。

L3 自动驾驶的教训

这个困境让我想到了自动驾驶行业的"接管问题"。

L2 辅助驾驶：人开车，车辅助。人的注意力全程在线，随时纠正车的错误。L4 全自动驾驶：车自己开，出了事车的责任，人不用管。L3 是最危险的——车自己开，但要求人在几秒钟内完成接管。

人类的注意力结构根本做不到这一点。当你不参与驾驶过程超过几分钟，你的情境感知就会完全消退。你以为你在监督 AI，实际上你只是坐在驾驶座上发呆。然后紧急情况发生，你需要在三秒内理解路况、判断危险、做出决策。没有人能做到。

自动驾驶行业已经在达成共识：要么 L2（人主导），要么 L4（车主导），L3 是死亡地带。

Vibe coding 在软件工程里制造的，就是 L3。

AI 开车，但出 bug 的时候需要人来接管。问题是，接管的人根本不在司机的座位上——他没开过这段代码，不知道路况，不了解车况，甚至连仪表盘都看不懂。

传统的 AI 辅助编程是 L2——人主导，AI 辅助。AI 写好代码，有经验的工程师审查、理解、承担工程责任。但当这个模式延伸到"不会写代码的人用 AI 做软件"的时候，就滑入了 L3——AI 主导写，人名义上负责，实际没有接管能力。

软件工程是不是也适用同一规律？要么人主导（AI 做 Reviewer），要么 AI 主导且承担工程责任（目前做不到），中间的"AI 写人审"可能是一个过渡性的幻觉。

Vibe Coding 真正的用武之地

说了这么多，不是要唱衰 AI 编程。而是要知道边界在哪。

Vibe coding 不适合生产级系统，但它确实打开了一个以前完全不存在的市场：

这个长尾市场以前根本不存在，因为开发成本太高。AI 把它打开了，这是真实的价值。

稀缺性的转移

这篇文章讨论的所有问题，最终指向同一个结论：

AI 让软件工程中最稀缺的资源，从"能写代码的人"变成了"能判断什么代码不该写的人"。

以前衡量一个工程师价值的角度很单一：能不能把这个功能实现出来。现在实现的门槛趋近于零，价值就转移到了更上游的位置——能不能判断这个功能值不值得做、改动应该放在系统的哪个层次、引入的复杂度能不能被未来的团队承载。

会用 AI 写代码已经不值得炫耀了。

能在 AI 写了 18000 行代码之后，还敢拍胸脯说"这系统我负责，上生产我心里有底"——这才是行业里真正稀缺、真正值钱的能力。

而能判断 AI 代码在凌晨三点会不会把你叫醒的工程师，他们的身价，才刚刚开始涨。