AI 写代码越来越快,为什么软件交付却没有变快?

但从现状看，代码产出确实比以前多了，每天都能看到各种 AI 生成的方案和代码。然而，需求的吞吐效率并没有想象中好，CR 的人更是痛苦——AI 生成海量代码，评审根本看不过来。

到底是 AI 成了人类的打工仔，还是人被 AI 裹挟了？

三份报告，拼出一个有点扎心的真相

最近看了一些同行的分享，如果你把这三件事拼在一起，逻辑就非常清晰了。

第一件事，是快手的实践。 快手把 AI 引入团队工作流后，发现了一个现象：个人用 AI 提效非常明显，但这不等于团队的交付周期变短。为什么？因为当大家都能光速生成代码时，评审、协作、对齐和验收，瞬间就成了新的“堵车点”。

第二件事，是 Jellyfish 的一份数据分析。 他们调研了 447 家公司、大概 5 万名工程师，试图搞明白：换个更好的模型、用个更好的工具，到底能给团队效率带来多大变化？ 结论很反直觉：模型和工具的差异，只能解释工程团队吞吐量差异的不到 1%。 （这里得严谨点说一句，这只是特定研究的统计结果，不代表模型没用，也不能把合并了多少行代码直接等同于赚了多少钱。但至少说明，光靠换工具，救不了整体效率。）

第三件事，是 Anthropic 的研究。 现在各种 Agent 干活越来越猛，但人类的时间去哪了？报告里说，人类依然要花大量时间给 AI 提供输入、阅读 AI 的结果、以及做最终的判断。

这三件事串起来看，真相就浮出水面了：既然写代码已经不是最耗时的环节，那在整个研发流程里，到底什么才是真正卡脖子的新瓶颈？

瓶颈到底转移到哪了？

过去一两年，大家天天都在卷：哪个模型写代码更牛？哪款 AI Coding 工具最顺手？甚至公司内部，也在考核 AI 代码采用率有多高。

大家都在疯狂优化“生产能力”。但现实是，代码生成提速了，需求依然在排队，线上出了事还得靠人去查日志。

而且我发现，事情正在往失控的方向发展：当越来越多的 AI 代码上线之后，未来能读懂这些代码的人，可能会越来越少。

这其实说明了一个挺残酷的事实：继续死磕代码生成能力，未必是整个研发体系里收益最大的方向。因为 AI 确实把“生产代码”的成本打下来了，但“软件交付”的成本，从来就不只有敲键盘写代码。

你仔细盘盘你们团队的日常：

• 搞懂业务到底要什么（经常反复横跳）。
• 盘清楚技术方案和约束。
• 解决跨系统依赖（最烦的环节，经常被别的部门卡住）。
• 验证代码逻辑和业务逻辑。
• 评审变更，评估风险（大佬永远没空）。
• 部署上线，盯监控，处理突发异常。
• 确认最终业务结果到底对不对。

AI 能加速的，其实只有中间偏后的某几个点。如果前面的沟通、后面的验收没变，整体速度就是快不起来。甚至因为 AI 产出变多了，原本用来“消化”这些产出的中间层（比如初级开发和评审人），反而变得更忙了。

别再用“生成了多少行代码”骗自己了

既然瓶颈变了，衡量 AI 价值的标准就得跟着变。

不要只盯着“省了多少敲键盘的时间”，如果你真的想看清 AI 在团队里的真实价值，不妨换这三个维度去观察（注意，这只是个建议框架，不是行业金标准）：

你去看吧，很多团队第一项数据非常漂亮，但第二项和第三项惨不忍睹。

写在最后

聊这些，不是为了证明 AI 不行，也不是为了制造焦虑。

我只是觉得，在这个人人都在喊“AI 要取代程序员”的节点上，我们反而应该冷静下来看清楚：AI 究竟改变了软件工程的哪一部分？

它加速了局部的执行，但并没有自动重构整个交付系统。如果等待、协调、验证的流程不改，AI 带来的那点速度增量，很快就会被新的瓶颈吃掉。

所以，下次当老板再问你“上了 AI 之后，效率怎么没变”时，你可以把这篇文章发给他。

真正的提效，不是给每个人配一把更快的刀，而是重新设计整个厨房的出菜动线。