AI Coding 的实践与探索

字节跳动的 AI Coding 实测：代码贡献率涨了 6 倍，但故事没那么简单

在最近的火山引擎 FORCE 大会上，字节跳动技术副总裁洪定坤分享了一组挺吓人的数据：过去一年，字节内部 AI 代码贡献率增长了 6 倍，Token 消耗增长了 5 倍。

但数字背后有个很有意思的反转——TRAE 团队（字节的 AI 编程工具团队）代码超过 90% 由 AI 生成，可人均需求吞吐率只提升了 60%。

这个数字值得玩味。90% 的 AI 生成率，换来的是 60% 的人效提升——也就是说，AI 写代码确实快，但「能跑的代码」和「能交付的代码」之间，还有一道不小的鸿沟。

字节做了 900 次实验，发现一个挺扎心的事实：主流 Coding 模型组合的代码正确率能超过 80%，但可交付性（就是说这代码能不能真正用到生产环境）只有 40-60 分。

什么叫可交付性？就是代码不光要能跑，还得考虑错误处理、边界条件、代码规范、可维护性……这些事情 AI 目前还做得不太好。

字节的解决方案是上「基建」——把 Harness（他们的 CI/CD 和工程效能平台）和 AI Coding 工具深度整合。效果好不好？结合 Harness 基建之后，可交付性提升到了 80 分。

这个结论其实挺重要的：AI Coding 不是单纯堆模型能力就能解决问题的，工程基建、代码治理、协作规范，这些「脏活累活」反而是提升实际生产力的关键。

AI 降低编程门槛这件事，已经是共识了。一个没写过什么代码的产品经理，现在可以让 AI 帮她写一个简单的数据看板。一个刚入职的新人，可以用 AI 快速理解一个复杂项目的代码结构。

但门槛降低之后，新的问题跟着来了：

**代码治理**：大家都用 AI 生成代码，代码风格不统一、依赖管理混乱、安全漏洞不知不觉被引入——这些问题在字节这样的大团队里会被放大。

**协作模式**：当 AI 能写大部分代码，人类的角色变成「审查者」和「指挥者」，这要求团队重新定义协作流程。

**指标设计**：如果继续用「代码行数」「提交次数」这类传统指标衡量程序员的工作量，AI 时代就完全失真了。字节也在探索新的指标体系。

字节在探索一种叫「原型驱动开发」的新模式。思路是这样的：先用 AI 快速生成一个可交互的原型（可能就是一个能跑的 Demo），拿去给产品经理、设计师、甚至用户看，拿到反馈之后再反过来指导正式开发。

这个模式的厉害之处在于：它把「需求理解」这个最耗时的环节给前置了。传统开发流程里，往往是代码都写得差不多了，才发现「哦原来产品经理想要的不是这个」。原型驱动开发等于把试错成本降到了最低。

这些能力已经被沉淀到了 TRAE（字节的 AI 编程工具）里。目前 TRAE 日均 Token 消耗 5.6 万亿，过去一年增长了 50 倍。

除了 TRAE 本身的代码生成能力，字节还在推 TRAE Work——一个让 AI 真正进入日常开发工作流的工具。具体能干什么呢？

这些功能听起来不性感，但恰恰是开发工作中最耗时间、最容易被忽视的部分。把一个功能的代码写完只花了 2 小时，但写测试、写文档、改 Bug、应对 Code Review 的反馈，可能要再花 6 小时。TRAE Work 瞄准的就是这「隐形 6 小时」。

字节的这组数据，其实是给整个行业提供了一个难得的「内部视角」。大部分公司谈 AI Coding，都在谈「我们的模型多厉害」「代码正确率多高」。但字节用自己在生产环境里的真实数据，告诉大家：正确率高不等于能交付，Token 消耗大涨不等于人效大涨。

这个认知挺重要的。它意味着 AI Coding 的竞争，不会只是模型能力的竞争，而是「模型 + 工程基建 + 协作规范 + 指标体系」的全套能力的竞争。

对于正在考虑引入 AI Coding 工具的中小团队，字节的经验也值得参考：别只盯着代码生成准确率，先把工程基建（CI/CD、代码规范、测试框架）做扎实，再把 AI 工具接进去——效果会好得多。