90% 代码 AI 写、人效只提升 60%——字节跳动洪定坤在火山引擎 Force 大会的 AI Coding 实战反思

> 类别：tip · 2026-06-24 > 原文链接：https://mp.weixin.qq.com/s/mdmaAyUIvxE8WT_GEbF2wQ

事件内容

2026 年 6 月 23 日，火山引擎 Force 大会在北京举行。字节跳动技术副总裁洪定坤做了《AI Coding 的实践与探索》主题分享。这一次他刻意避开自家产品 TRAE 的功能介绍，转而讲一年来的实战数据、踩过的坑和正在推进的工程化路径。

一年增长曲线（字节整体）：

AI 代码贡献率增长 6 倍多。
AI Coding 相关 tokens 消耗增长 5 倍，且仍在高速增长。
AI 代码合入率增长超 2 倍。

TRAE 团队的对照数据（过去半年，字节内部做 AI Coding 工具的「自吃狗粮」团队）：

90%+ 的代码由 AI 生成。
人均需求吞吐率提升 60%（达到 1.6 倍）。
Token 日均消耗 5.6 万亿，相比去年增长 50 倍。

900 次实验：

选 3 个主流 Coding 模型 × 3 个主流 Agent 框架，两两组合。
用相同的真实业务需求和 Prompt 各跑 100 次。
单跑结果：所有组合功能正确率都超过 80%。
加 Harness 后：正确率从 80% 接近 90%；可交付性（UI 易用性、可靠性、可维护性、性能、兼容性）从 40-60 分不及格水平提升到 80 分。

三大挑战（演讲中明确点名）：

1. 过度重视单一指标。洪定坤直言，一些团队把 AI 代码贡献率定成 KPI 去卷，是失真的——「AI 写代码的速度，起码是人的 10 倍以上，当 90% 的代码都由 AI 产出之后，那其实带来的效率应该远远不止 60% 这么简单，它应该是几倍甚至一个数量级的提升」。 2. Vibe Coding 的虚假快感。900 次实验显示，Vibe Coding 在「功能正确」上超过 80%，但在「可交付性」上随机性极强——异常处理不规范、不复用已有组件、改动影响历史功能、不符合团队工程规范。 3. 协作的真空地带。他举了一个真实例子：一个产品同学用 Vibe Coding 做出能跑的功能页面，但研发看完说需要排期几天。原因不是写得不好，而是性能、扩展性、权限都没考虑。

三大方向（字节内部正在做）：

1. 指标：找到衡量 AI 是否真正全局提升交付效率的指标，而非单一代码贡献率。 2. 治理：通过 Harness（context 工程、架构约束、团队知识沉淀到 Memory、技术债梳理）让 Vibe Coding 走向真正的软件工程。 3. 协作：用「原型驱动开发 + 系统化 AI Development + 组织化建设」让产品、设计、运营、研发在统一架构、规范和交付流程下合作。

最后，洪定坤宣布了一个重要产品动作：TRAE Work 即将推出，并与火山引擎一起集成到 TRAE 的企业版中。

深度剖析

这篇分享值得反复读，因为它可能是 2026 年中文互联网对「AI Coding 实际工程化」最诚实的一份一手反思。它的价值不在结论，在论证。

第一层：它提出了一个反共识数据。

国内大厂对外宣传 AI Coding 时，普遍倾向于讲「AI 写代码占比」「采纳率」「代码生成量」这类指标。洪定坤却以字节自己最激进的 TRAE 团队数据为例：90% 代码 AI 写，人效只提升 60%——这是「1.6 倍」与「10 倍」的差距。

这种反共识数据的重要意义在于，它迫使行业重新定义「AI Coding 提升的到底是什么」：

如果只看代码生成量，那是 10 倍。
如果看「人均需求吞吐率」（功能从需求到上线的端到端速度），那是 1.6 倍。
中间差的 8 倍，去了哪里？

洪定坤的答案是：去了异常处理、回归测试、代码评审、知识沉淀、上下文工程、架构约束这些「基建」上。

第二层：它把 Harness 从「概念」翻译成「基建清单」。

演讲中最务实的一段是 900 次实验的对比：同样 9 种模型+框架组合，只加 Harness，可交付性就从 40-60 分拉到 80 分。这等于把 Harness 的边际效用做了一次量化呈现。

而他列的 Harness 清单也很具体——「context 工程、架构约束、团队知识沉淀到 Memory、技术债梳理」——这四件事是几乎所有国内大厂在 2025 年下半年才开始系统投入的。字节把他们列成「AI Coding 能否落地的真正决定性因素」，等于承认了：

> 模型组合的正确率从 80% 到 90% 是边际改进； > 而 Harness 让可交付性从 60 到 80 分是结构性改进。

这与中国大模型公司（如 Qwen、Coder-Kit 等）目前「比拼模型榜单成绩」的宣传重点形成对比——洪定坤实际上是在说：真正的瓶颈不在模型，在 Harness。

第三层：它提出了「Vibe Coding 进入软件工程」的具体路径。

900 次实验是「坏消息」：Vibe Coding 在真实业务里是不够的。900 次实验又是「好消息」：当 Harness 介入后，可交付性是显著可拉升的。

字节给出的三件事——原型驱动开发、系统化 AI Development、组织化建设——本质上是用 AI 重新设计研发流程：

原型驱动：把 PRD 静态文档改成 AI 生成的动态可交互原型，让产品、设计、研发在同一个东西上对齐。
系统化 AI Development：AI 参与从 Spec 编写、Browser Use 验证、Bugfix、提交到上线的全流程。
组织化建设：把 AI Coding 实践沉淀成内部标准、工具、技能，避免依赖「会写 Prompt 的高水平个体」。

第四层：它从组织视角回应了「人人都是程序员」的协作难题。

产品同学用 Vibe Coding 写出来的功能页面，研发看完说「还是需要排期几天」——这个故事的真相是：代码生成门槛下降，不等于系统复杂度下降。

洪定坤没有给出激进答案（「让所有人直接 commit」），也没有给出保守答案（「非工程师写的代码不能上」），而是提出中间路径：

> 让不同角色更合理、更有效地参与代码生产，每个人都能发挥价值，但产出要进入统一的架构、规范和交付流程，最终把整体效率提升。

这个表述的工程含义是明确的：CI/CD、权限、code review、架构约束这些不能因为「AI 能写代码」而取消，反而要更刚性。

值得关注的原因

1. 字节是中国 AI Coding 落地最深的公司之一（TRAE 团队 Token 日均 5.6 万亿），洪定坤作为技术副总裁的数据是一手数据，不像二次报道可能有修饰。他的「1.6 倍 vs 10 倍」反共识数据点，是 2026 年公开渠道里极少数的「不报喜」AI Coding 实战评估。 2. 从「指标」到「治理」到「协作」的三层框架，给企业 AI Coding 落地提供了一个可直接抄的清单。它不是抽象口号，是可以映射到具体团队改造的工程动作。 3. 确认了 Harness 是 2026 年下半年 AI Coding 的核心战场。模型正确率的天花板已经接近（80% 到 90% 是小改进），真正的杠杆在 Harness、可交付性、组织能力。 4. TRAE Work 与火山引擎 TRAE 企业版的集成，意味着字节要把内部 AI Coding 工程化能力「卖给企业」——这是从内部工具到企业 SaaS 的关键一跳。 5. 与海外形成对照。OpenAI 06-25 发布的《How agents are transforming work》报告称 Codex 在内部「99.8% 输出 token 由其产生」，与洪定坤的「90% 代码 AI 写、人效只提升 60%」是两个不同维度的数据——前者强调「AI 写得多」，后者强调「人效提升得没那么多」。两个数据放在一起读，才能看到完整的画面。

风险与待观察

演讲数据本身需要警惕修辞。洪定坤演讲是公开场合，且涉及自家产品 TRAE 的推广，他有意无意地回避了「人效 60%」背后的具体归因（是模型瓶颈？是 Harness 缺失？是组织结构？）。观众需要把这当成「问题列表」，而非「答案列表」。
「正确率从 80% 到 90%」是单点实验的内部结论。900 次实验是在字节内部一个具体业务需求上做的，跨业务、跨团队、跨行业是否一致，未经验证。
TRAE Work 的商业化前景。字节把 AI Coding 卖给企业这条路，目前有 GitHub Copilot、Cursor、Claude Code 等强敌，TRAE Work 能否在企业市场取得一席之地仍是未知数。
「Vibe Coding 进入软件工程」的中间路径是否可持续。洪定坤的方案本质是「让 Vibe Coding 在 Harness 下变得可控」，但 Harness 的搭建需要大量人力（context 工程、知识沉淀、架构约束都是脏活）。中小公司能不能抄作业，是个开放问题。
「人人都是程序员」的协作命题仍在演化。演讲没有给出激进方案，但也没有否定激进方案的真实需求。如果未来模型能力继续指数级提升，研发评审的瓶颈可能从「代码评审」转移到「架构评审」，字节的组织设计是否仍然适配，是另一个长周期问题。

结论：洪定坤这场演讲是一份 2026 年中国 AI Coding 工程化的「清醒时刻」。它不像宣传材料那样报喜，也不像怀疑者那样悲观，而是用一手数据划定了下一阶段工程团队真正该投入精力的地方——Harness、治理、可交付性，而不是更多模型、更多 token、更多代码贡献率。