90%的代码交给 AI，效率只提升 60%——字节 VP 揭穿了 AI 编程最大的幻觉

6 月底的火山引擎 FORCE 原动力大会上，字节跳动技术副总裁洪定坤公开了一个大多数 AI 厂商会选择埋起来的数字：字节内部的 TRAE 团队，如今超过 90% 的代码由 AI 生成，但人均需求吞吐只提升了 60%。

把这两个数字放在一起看，故事就反转了。AI 写的代码翻了十倍，每个工程师多产出的却只有半个单位左右。这中间的落差，是对 2026 年企业级 AI 编程市场最诚实的描述——而几乎没有一个在这个市场里卖东西的人，愿意谈它。

这不是在唱衰 AI 编程。它确实有用。但对任何真金白银投入这场转型的公司来说，真正要紧、也更难回答的问题是：当代码量涨了十倍、实际交付却几乎没动，价值到底去哪了？

这个问题的答案，决定了一笔 AI 投资究竟会复利增长，还是悄悄变成一笔负债。

几乎所有人都在用错误的方式衡量

大多数组织的本能，是用那些好数的东西来衡量 AI 的采用情况：AI 生成了多少行代码、多少比例的提交用了 AI、消耗了多少 Token、部署了多少个席位。

这些数字放进董事会 PPT 里很好看，但跟“工作有没有变快”几乎毫无关系。

关于这一点，最严谨的证据来自研究机构 METR。他们做了一项随机对照试验——就是新药临床试验用的那套方法——对象是在自己极其熟悉的代码库里工作的资深开源开发者。

开发者们预测 AI 会让他们快大约 24%。试验结束后，他们以为自己快了大约 20%。而实际上，当被允许使用 AI 工具时，他们完成任务的时间反而长了 19%。

最值得警惕的不是“变慢”这件事本身——它对场景很敏感。而是感知与现实之间那 39 个百分点的落差。

真正在干活的人，根本意识不到工具在拖慢自己，反而坚信它在帮忙。2025 年开发者对 AI 工具的采用率达到了 84%，但正面评价从 70% 跌到 60%，对输出准确性的信任从 43% 跌到 33%。

整个行业正在加深对一类自己越来越不信任的工具的依赖，而指引这一切的那个“生产力提升”信号，按最严谨的研究来看，并不可靠。

对一个 CTO 来说，这是第一个不舒服的结论：如果你的工程师觉得自己效率大幅提升了，这种“感觉”不是证据。它甚至可能是反证。

“能跑”不等于“能交付”

字节披露的第二个数据，更接近问题的机制。TRAE 团队用三个主流编码模型配三个框架，把同一个需求跑了 900 次。功能正确率稳定在 80% 以上。

但当他们从可维护性、性能、兼容性这些“决定代码能不能真正上线”的维度去打分时，分数直接腰斩。

这正是每一场 Demo 都会丢掉的那个区别。“它能跑”和“它能进生产环境”是两个完全不同的命题，中间隔着一大堆不性感的工作。

一个有 80% 概率写出功能正确代码的模型确实令人印象深刻，但在有真实质量标准的系统里，它离“可部署”还差得远。

纵向数据印证了这一点。arXiv 上一项针对 AI 生成代码的大规模实证研究，追踪的不是代码有没有通过初次评审，而是它被合并之后会发生什么。

研究发现，存活下来的、由 AI 引入的问题数量持续累积，到 2026 年 2 月已经超过 10 万个，最终沉淀成一笔可观的维护负担。

另一项 Harness 在 2026 年对 700 名工程从业者的调研显示，69% 使用 AI 编码工具的团队，经常遇到 AI 生成代码带来的部署问题。

不同来源指向同一个模式：AI 大幅降低了“生产代码”的边际成本，却几乎不保证代码的集成度、架构合理性和长期可维护性。

你在生成那一刻感受到的速度，是向未来借来的——账单会在之后某个 Sprint 里、由别人来还。

字节是怎么解决的，以及为什么这件事重要

洪定坤演讲里真正应该让任何一个操盘者比头条数字更在意的，是下面这部分。

在识别出这个落差之后，TRAE 团队加上了他们称之为 “Harness” 的东西——上下文工程、架构约束，以及把团队知识沉淀成 AI 真正能用的形式。

可交付性的分数，从 40–50 分一路拉到了 80 分。

模型没有变。变的是模型周围的基建。而真正的生产力，一直就藏在这里。

这件事重新定义了整个对话。企业级 AI 编程的瓶颈，从来不是模型的原始能力，而是组织有没有建起那套外围系统——上下文、约束、沉淀下来的知识——好让一个有能力的模型，产出真正能交付的东西。

大多数公司完全跳过了这一步：部署工具、看着代码量飙升、然后因为看板是绿的，就断定 AI 起作用了。

而可交付性的缺口，会在两个季度后，以一笔没人能追溯来源的技术债形式显现。

同一个故事，写在整个企业层面

代码层面成立的事，在 AI 部署的整体层面同样成立，而宏观数据更加触目惊心。

MIT 的 NANDA 项目在那份被广泛引用的企业生成式 AI 研究里发现，大约只有 5% 的 AI 试点项目实现了快速的营收增长，绝大多数都停滞了，对损益表几乎没有可衡量的影响。

研究者把原因说得很直白：核心问题不是 AI 模型的质量，而是工具和组织双方的“学习鸿沟”。

通用工具在企业里会卡住，因为它们不会从特定的工作流中学习、也不会适配它。

财务上的清算已经开始。到 2026 年年中，多篇报道描述了一波企业级的“AI 账单震惊”——Token 账单膨胀，回报却跟不上。

据报道，微软部分出于成本考虑取消了大部分 Claude Code 的 License；某家公司因为没有设置用量上限，单月烧掉了据称 5 亿美元。

当上市公司的生产力宣称被对照到它们自己的财报时，落差再次出现。

摩根大通声称开发者生产力节省了约 10%，但 2025 年实际薪酬支出增长了约 6%、员工人数还在上升；摩根士丹利报告生产力提升约 20%，而薪酬支出增长了 12%。

生产力存在于新闻稿里。它还没有出现在利润表上。

但 MIT 数据里最重要的那个数字，指向的是解法而非问题：由外部伙伴主导的部署，成功率达到 66%，而纯内部自建只有 33%。

而贯穿所有研究的一致发现是——从试点走向生产，大约 80% 的工作量是数据工程、治理、工作流集成和度量基建，而不是选模型。

什么才会真正复利

把所有证据放在一起，结论很难回避。

真正跑在前面的公司，不是那些拿到了最好模型的。到 2026 年，前沿模型的获取已经接近于一种商品。

跑在前面的，是那些建起了底层那一层的公司：让模型理解组织真实运作方式的上下文工程、让生成代码保持可交付的架构约束、让输出可审计的治理，以及证明这一切到底有没有用的度量体系。

这是不性感的基建。它放不进发布会的 Slide 里。

但它恰恰就是字节 “Harness” 代表的工作，恰恰是 MIT 数据里那成功的 5% 所投入的工作，也恰恰是大多数企业在抢着上报采用率时跳过的工作。

90/60 这个问题，不是反对在软件里用 AI 的论据。它反对的是把 AI 当成一个“装上去”的东西，而不是一个“围绕它重新设计”的东西。

2026 年真正把这件事想透的组织，会悄悄拿走那些别人还在用 Token 数量衡量的生产力红利。

90% 和 60% 之间的差距，不是技术的失败。

它精确地标出了那些还没做的工程与组织工作的体量——也精确地标出了，对任何愿意去做这件事的人来说，价值究竟在哪里。

本文引用的数据来自：字节跳动火山引擎 FORCE 原动力大会（2026 年 6 月）的公开披露、METR 关于开发者生产力的随机对照试验、MIT NANDA 项目关于企业生成式 AI 的研究报告、Harness 2026 年工程从业者调研，以及 arXiv 上关于 AI 生成代码的纵向研究。