上周三晚上十一点，一个做了七年开发的朋友发了条消息：「哥们，我们组这个月AI生成了四万多行代码，但版本发布比上个月还晚了三天。」

这不是个案。MIT和宾夕法尼亚大学的研究人员今年5月在NBER发了一篇工作论文，追踪了十万名开发者。结论很刺眼：AI编程工具让代码行数变成了原来的17.3倍，但实际发布的软件版本只提升了30%。

17倍的代码，30%的软件。

中间的差值去哪了？

不是AI写得慢，是人审不过来

安托万是我认识的一个后端架构师。他们团队年初全面接入了Claude Code，刚上手那阵子，所有人都很兴奋。一个登录模块，以前两个人写三天，现在一个人加AI，半天搞定。

但两个月后，问题冒出来了。

「AI一天能给十几个PR，每个PR少则三四百行，多则一两千行。」他说，「我们组就三个能做深度审查的人，根本审不过来。」

他们做了个统计：AI提的PR中，平均审查延迟从年初的4小时拉长到了现在的26小时。有将近三分之一的PR因为排队太久，合并进去的时候已经和其他代码产生了冲突，又要额外花时间修。

Cursor今年春季的报告证实了这个趋势不是孤例。未经人工逐行审核就自动进入提交的AI代码，从年初到现在增长了超过5倍。不是因为这些代码质量高到不需要审，而是因为——审不过来了。

Anthropic自己的数据更直接。Claude Code的代码可运行率确实在提升，开放式任务的可用率半年内从54%冲到了76%。但另一个指标在报警：AI代码在被接受后60分钟内保留在代码库的比例，从76%升到了81%。这个数字看起来是好事，但你反过来看——有近20%的AI代码，提交之后很快就被回滚或替换掉了。

代码多了，但「有用的代码」没多

MIT那篇论文里藏着一个更深的发现。

研究人员把代码产出拆成两类：样板代码和核心逻辑代码。样板代码——配置文件、依赖声明、路由注册、重复的CRUD——增长了23倍。核心逻辑代码只增长了2.7倍。

AI在疯狂生产你不应该手写的东西，但它没有在解决你真正需要解决的问题。

这就解释了为什么代码17倍、软件只多三成。多出来的那十几倍代码，大部分是AI替你生成的「胶水」。胶水多了，系统确实能跑起来，但系统复杂度也同步膨胀。

Stack Overflow 2025年开发者调查印证了这一点。66%的开发者表示AI编程最大的痛点是「几乎对但不完全对」——AI给你的代码看起来像模像样，跑起来也没报错，但它处理边界条件的方式是错的、它的异常处理路径是漏的、它的性能假设是不成立的。你要花时间去发现这些问题，发现之后要花更多时间去修。

45%的开发者认为调试AI代码比调试自己写的更耗时。

管理债务：一个没人讨论的隐形杀手

代码审查的拥堵只是表面现象。更深层的问题在管理层面。

去年底，一家中型SaaS公司做了一个尝试：三个月内，所有业务代码全部由AI生成，工程师只做审查和架构决策。

结果让CTO失眠。

「第三个月月末我要做一个架构评审，我问团队某个微服务的数据库连接池配置为什么设成了50。没人能回答。最后翻了三个月前的AI对话记录，发现是Claude在第一次生成代码的时候自己决定的，后面所有迭代都在这个基础上继续改，但从来没有人去质疑过这个数字。」

这不是技术债，这是知识债。

当一个团队里80%的代码是AI写的，而工程师只在审查层面介入时，系统是怎么运作的、某个决策为什么这样做、哪些地方埋了假设——这些隐性知识正在从团队中消失。

Anthropic在自己的内部报告中也承认了这一点。他们的一位员工说，自己已经快五个月没亲手写过一行代码了。这听起来很酷，但细想是可怕的：如果连做出AI编程工具的人自己都不写代码了，那未来谁来理解系统？

Cursor的报告里有一个数据很能说明问题：AI代码行数的基尼系数高达0.77。意思是，极少数人用AI产出了绝大部分代码。P99开发者的代码产出是中位用户的46倍。

但这些超级产出的代码，有多少被真正理解、被妥善维护？没人统计过。

另一个容易被忽略的数据来自Google。他们在今年的Cloud Next大会上透露，Google内部新代码的AI生成比例已经达到75%——从2024年底的25%、2025年秋的50%一路攀升。但与此同时，Google工程师用在代码审查和调试上的时间同比增加了42%。

这不是巧合。当AI帮你省下了写代码的时间，这些时间没有变成你的空闲时间——它们变成了更多代码审查的时间、更多调试的时间、更多因为你没亲手写所以看不懂的代码需要你花时间去理解的时间。

写代码的边际成本降到零之后，审查和维护的边际成本反而升上去了。

你的团队，正在经历什么

软件工程有一句老话：写代码只占开发总时间的10%到20%。

AI编程工具确实把写代码这件事加速了。但理解需求、设计架构、评审代码、联调集成、修复缺陷、维护系统——这些事情没有加速，甚至因为代码量暴增而变得更重了。

一个具体的例子。去年一家做支付系统的团队统计过一组数据：AI编程工具全面接入前，平均每个需求从PRD到上线的总时长是8.2天。接入半年后，代码编写从3.1天降到了1.6天。但需求澄清从1.2天变成了1.9天——因为AI生成的需求拆解常常过于机械，反而催生了更多回炉讨论。代码评审从0.8天变成了2.1天——因为AI吐出来的代码量太大了。联调测试从1.5天变成了1.3天——变化不大。

总的来看，端到端交付时长从8.2天变成了7.3天，只快了11%。代码编写环节加速了48%，但被其他环节的膨胀吃掉了大半。

一个来自德国咨询公司adesso的2026年GenAI影响报告显示，使用AI做软件开发的企业中，有21%实现了超过26%的生产力提升——相当于一个五人团队多出了一个虚拟成员。但34%的企业表示「缺乏技能」制约了进一步扩展，38%觉得「合规要求」是瓶颈。

AI让你写得快，但不能让你理解得快、决策得快、协作得快。

上周那个发消息的朋友最后说了一句话：「我们现在最大的瓶颈不是写代码的速度。是理解代码的速度。」

方向对了。AI编程的下半场，比的不是谁产出多，比的是谁能审得过来、管得清楚、睡得着觉。

不管你的团队现在AI代码占比是多少，有三个迹象值得你留意：审查队列是不是在积压、技术决策记录是不是越来越薄、出问题之后是不是越来越难定位到根因。这三样东西比代码行数更能告诉你，你的AI编程是在加速还是在添乱。