字节跳动承认了：AI写了90%的代码，但效率只涨了60%

2026年7月，零一万物创始人李开复公开表态：AI编程已经超过人的能力，很多公司90%以上的代码由AI生成。

这番话引发了广泛传播。但它只说对了一半——对的那半是"AI确实写了90%的代码"。被刻意省略的另一半，来自字节跳动火山引擎Force大会上的真实数据。

字节技术副总裁洪定坤在同一个会场公布了一组内部数据：TRAE团队超过90%的代码由AI写出。与此同时——团队的人均需求吞吐率只提升了60%。

90%的AI代码产出，换来了60%的效率提升。

这30%的缺口去哪了？

三大黑洞，吃掉了效率增量

字节团队做了一个非常残酷的实验。

选三个主流AI编程模型和三个主流Agent框架，两两组合，用一个真实的中等复杂度需求重复跑100次。只看"功能是否基本正确"这一项，所有组合的正确率都超过80%。

但一旦把评判标准从"能跑"升级到"能用"——加入UI易用性、可靠性、可维护性、性能、兼容性这些维度——分数立刻断崖。

AI写的代码能跑通测试，但生产环境的崩溃率是人工代码的十几倍。AI写出来的界面能显示数据，但用户体验烂到需要重做。AI能批量生成几千行代码，但三个月后当需求变更的时候，没有一个人敢改——因为没人真正理解AI当初为什么要那么写。

这是第一个黑洞：AI写"对"了，但没写好。

第二个黑洞来自GitClear的研究数据。他们追踪了过去六年的代码质量变化趋势，发现随着AI编程工具的流行，代码重复率已从2020年的约3.3%攀升到2026年的7.1%。翻了一倍多。

原因很反直觉：AI更倾向于"新增代码块"，而不是建议删除、重构或移动既有代码。当一段逻辑已经过时，AI不会说"这可以删掉"——它直接在新的请求下给你写一段新的。旧的还在那。AI像一个永远只会往房间里添家具的助手。沙发坏了？再给你搬一个进来。至于原来的旧沙发占着空间，它不管。

几个月下来，代码库里的"幽灵代码"越积越多。编译能过，跑起来也行，但工程师每次改需求都像在雷区走路。

第三个黑洞最致命，也是最被忽视的。

某金融科技公司全面接入AI编程工具后，月均代码产量从2.5万行飙升到25万行。翻了整整十倍。然后发生了什么？没什么。代码写好了，堆在那，等着审。

AI用5分钟生成了1000行代码。一个有经验的工程师需要40分钟才能勉强审完——而且这1000行里可能只有100行是真正有用的，剩下900行是冗余、过度设计或压根用不上的分支逻辑。但你不能不审。因为100行里可能有5行藏着高危漏洞。

目前这家公司积压了超过100万行尚未完成审查的AI生成代码。

写代码，第一次变成了整个软件开发链条里最轻松的一环。

真正的瓶颈，从"写"变成了"审"。

一个残酷推论：人越多的团队，AI效率越打折

如果把字节的这组数据拆得更细，会发现一个更扎心的规律。

TRAE团队是一个成熟团队。他们有完善的代码规范、沉淀多年的架构文档、清晰的分工和评审流程。AI在这样的团队里只能贡献60%的效率提升。

而在一个三五个人的小组里，情况完全相反。小团队没有复杂的评审流程，没有多级架构约束，没有跨团队依赖。AI生成代码，开发者看一眼，能用就直接上线。效率提升远超60%。

这意味着什么？意味着AI编程对"大公司病"不但没有治疗作用，反而在放大病痛。大公司最耗时的环节——跨团队拉齐、层层审批、技术评审、兼容性测试——AI一个都帮不上忙。而小公司最大的短板——人力不足、编码速度慢、开发周期长——AI恰好全补上了。

这是AI编程最深的矛盾：它让小团队更快，但也是大团队效率提升的天花板。它给创业者插上了翅膀,却给大厂中层加上了镣铐。

如果这个推论成立，那2026年之后，软件行业的竞争格局可能被彻底改写。过去大厂靠"人多资源多"碾压小团队。未来，如果一个十人团队配五个AI Agent能达到过去五十人的产能，大厂的规模优势还剩什么？

90%和60%之间夹着一个真相

字节的数据之所以重要，不是因为它告诉我们AI有多厉害。恰恰相反，它告诉了我们AI在最真实的生产场景下有多不够用。

90%的代码AI写，说明AI确实承担了编码的体力劳动。这很了不起。

但只换来60%的效率提升，说明真正耗时间的不是"把代码敲出来"这个动作。而是理解需求、设计架构、评审代码、排Bug、做兼容、写测试、处理边界情况——这些环节AI一个都没加速。

更讽刺的是，有些环节AI甚至在降速。因为AI生成的代码比人工代码更难理解和维护，所以评审时间变长了。因为AI生成代码时隐含了大量未被声明的前提假设，所以排Bug的时间变长了。因为AI写了大量"看起来对但经不起推敲"的代码，所以测试覆盖率反而需要更高。

你用AI省下的编码时间，加倍花在了之后的质量控制上。

不是AI不够强，是软件工程的瓶颈不在编码上

有一句话在字节内部分享会后被反复传播："AI解决的是'怎么写'，拦在项目前头的永远是'写什么'和'为什么这样写'。"

这才是90%和60%之间那30%缺口的真正答案。

软件工程的复杂度，从来不是"代码怎么写"的技术问题。是"需求怎么理解"的沟通问题、"架构怎么设计"的判断问题、"变更怎么管理"的组织问题。

AI在这些问题上没有任何优势。它不知道你的业务上下文，不理解你的团队内部的政治边界，不关心你的技术债务已经堆到了什么程度。

它只会写代码。

而写代码这件事，在整个软件工程的时间分布里，本来就不是占比最大的环节。

2026年之后的效率账该怎么算

李开复说很多公司90%的代码由AI生成，这是事实。但他在同一段采访里没有展开的一个关键问题是：这90%的代码里，有多少真正上线了？有多少在半年后不需要重写？有多少因为安全漏洞被撤回？

如果答案不乐观，那90%这个数字不是骄傲的资本，是危险的信号。

字节的真实数据给了所有人一个清醒的参照系。不要只看AI写了多少，要看团队交付了多少。不要只看编码速度快了多少，要看从需求提出到稳定上线的端到端时间缩短了多少。

当AI编程的泡沫数据被拆穿的那天，真正有价值的不是"谁用AI写了最多的代码"，而是"谁用AI真正做完了最多的项目"。

你公司现在的AI代码生成率是多少并不重要。

重要的是：你敢不敢把这些代码的数量和上线后的Bug数量放在同一张表里给老板看？