AI写代码快三倍，但发布还是那么慢：MIT这项研究戳破了谁的幻觉？

你有没有这种感觉——团队里每个人都用上了AI编程助手，每天看着代码仓库里新增的修改记录像瀑布一样滚动，项目却还是那个速度，甚至更慢了。

MIT的一组研究人员还真把这种感觉量化了。根据《金融时报》报道的这项研究，他们追踪了软件团队从写代码到审查再到发布的完整生产流程。结论很有意思：AI让开发者创建或编辑的文件数量暴增近300%，但最终真正发布的产品只提升了约30%。

这个数字差得有点离谱，不是吗？

说实话，我第一眼看到这组数据的时候，脑子里冒出的第一个念头是：那些天天吹嘘"AI编程革命已经到来"的厂商，是不是该出来解释一下？

300%的效率幻觉：我们到底在加速什么

先把这个300%说清楚。研究人员定义的"编辑"包括了创建新文件、修改现有代码行这类基础操作。在这个环节，AI确实展现出了惊人的能力——Copilot、Cursor这类工具确实让程序员敲键盘的频率大幅下降，代码补全、批量重构、自动化生成让"产出"看起来非常可观。

我自己最近也重度使用了几款主流AI编程工具。在写一些工具脚本、数据处理这种边界清晰的代码时，AI确实能让我在一个小时内完成以前需要一天的工作量。但这里有个关键词：边界清晰。

研究数据显示的300%增量，大概率就集中在这种场景——程序员用AI快速生成代码骨架、批量修改格式、把伪代码直接转成可执行文件。这些工作量大，但技术含量相对低，本质上是在加速"体力活"。

问题在于，软件工程从来不只是体力活。

从150%到30%：价值去了哪里

研究人员在审查阶段发现了第一个明显的"漏斗收窄"——编辑效率的增益在这里从300%跌到了150%。这意味着什么？

审查阶段（Code Review）是人类工程师判断代码质量、安全性、可维护性的关键环节。AI可以快速生成代码，但它无法替你判断这段代码是否符合产品长期的技术债务管理策略，是否与现有架构理念兼容，是否存在潜在的边界条件漏洞。

我之前跟一家中型互联网公司的技术负责人聊过，他们去年全面推广了AI编程工具。这位负责人的原话是："代码产出确实多了，但bug也多了，review的时间反而拉长了。"

审查阶段的150%听起来也还不错，但如果你仔细想想这背后的代价——review轮次增加、沟通成本上升、返工率提高——实际的价值转化可能更接近于零。

而真正让我震惊的是最终发布环节的数据：只有30%的增益。

这意味着什么？意味着团队辛辛苦苦用AI加速产出的那300%的代码，最终能够进入产品、触达用户的，只有其中的一小部分。大量的工作被消耗在某个环节，没有变成最终价值。

真正的瓶颈：那些AI至今搞不定的事

研究人员在报告里点出了几个关键瓶颈，我认为是整篇文章最有价值的部分：

产品判断。AI不知道用户真正需要什么，不知道这个功能优先级应该排在第几位，不知道产品经理脑子里的那个"酷炫交互"到底是用户真实诉求还是产品经理的个人审美。这种判断需要业务理解、市场洞察和跨部门沟通，AI目前只能扮演执行者的角色。

人类协调。一个产品从代码到发布，需要后端、前端、测试、安全、法务等多个角色的配合。这里有大量的沟通成本、依赖关系管理、风险评估。AI可以加速个体的工作，但很难加速组织层面的协作。我见过太多项目delay不是因为编码慢，而是因为"等某个人确认"、"等某个环境部署"、"等某次评审排期"。

测试与质量保障。自动生成的代码能不能通过测试？边界条件覆盖了吗？安全漏洞修复了吗？这些环节需要的是严谨的测试用例设计和持续的质量把关。AI生成代码的速度越快，测试环节的压力反而可能越大——因为你需要验证的东西变多了。

发布流程与合规。特别是对于金融、医疗、企业级这类对稳定性要求极高的领域，发布流程本身就有一套复杂的审批和验证机制。这不是技术问题，是业务流程和风险控制问题。

说白了，AI在加速的是编码这一环，而软件工程大部分的复杂性和不确定性恰恰不在编码本身。

我们应该怎么看待这个数字

MIT的这项研究并不是要否定AI编程工具的价值。300%的编辑效率提升放在任何一个行业都是革命性的。但我认为它真正戳破的是一个认知误区：把"代码产出"等同于"产品价值"。

我个人判断，AI编程工具接下来的真正挑战，不是继续提高生成代码的速度，而是想办法把自己嵌入到整个生产漏斗里——帮助人类更好地做产品判断、更好地做测试设计、更好地做发布决策。这需要的不只是模型能力的提升，更需要产品形态和交互模式的根本性变革。

对于正在使用AI编程工具的团队，我有几点建议：

第一，把AI定位为效率工具而非替代工具。用它处理那些重复性高、边界清晰的工作，但不要让它替你做产品判断。

第二，重新审视你的瓶颈在哪里。很多时候真正拖慢项目的不是编码速度，而是review排期、测试环境、发布审批这些环节。把AI的效率增益浪费在已经被瓶颈卡住的地方，是没有意义的。

第三，建立新的协作模式。当团队产出速度大幅提升时，配套的review流程、质量门禁、发布机制都需要重新设计。否则你会发现，AI让每个人都跑得更快了，但整个团队还是在走原来的速度。

AI确实在改变软件工程。但改变的方式可能和很多人想象的不太一样——它不是让软件开发变得更快，而是让软件工程中那些被掩盖的问题更早地暴露出来。

研究团队最后那句话我很喜欢：大量额外工作未能转化为最终产品。这不是AI的失败，而是给我们提了一个醒——技术永远只是手段，最终的价值始终取决于人类如何定义问题、如何判断优先级、如何在复杂的组织环境中达成共识。

工具变快了，但产品判断力、跨部门协调能力、对用户需求的洞察——这些人类独有的能力，在AI时代反而变得更稀缺、更重要了。

这大概才是这项研究最值得我们思考的地方。