字节 AI 代码贡献率涨了 6 倍，但能交付的只有四到六成

先说一个我看完愣了一下的数字。

过去一年，字节跳动的 AI 代码贡献率涨了 6 倍多。同一时间，AI Coding 上的 token 消耗涨了 5 倍，代码合入率也翻了不止 1 倍。听到这儿你大概会跟我一样，下意识觉得，这家公司的研发效率应该是坐着火箭往上窜了吧。

结果他们自己跳出来泼了盆冷水。

6 月 23 日火山引擎那场 Force 大会上，字节跳动技术副总裁洪定坤做了个分享，题目叫《AI Coding 的实践与探索》。他没讲产品，讲的是踩坑。其中有一张图，看得我后背有点发凉。

那是 TRAE 团队自己过去半年的数据。TRAE 你可能知道，就是字节那个做 AI 编程的工具，团队自己当然是最激进的，过去半年里超过 90% 的代码都是 AI 写的。九成。然后呢，人均需求吞吐率提升了多少？

60%。也就是 1.6 倍。

你品一下这个落差。AI 写代码的速度，保守说也是人的 10 倍以上吧。90% 的代码都交给它了，按理说效率得是几倍、甚至一个数量级地往上翻。结果落到真实的交付上，只有 1.6 倍。

10 倍的输入，1.6 倍的产出。中间那一大截，蒸发了。

洪定坤说得很直白，单一的代码贡献率这个指标，会失真。我看到这句的时候是真的有点感慨，因为这事儿我天天在工位上跟它打照面。

坦率讲，过去一年我见过太多团队，把 AI 代码贡献率当成 KPI 在冲。这个指标有个魔力，它涨得快，数字一好看人就容易飘，觉得自己站在时代前列了，生产力起飞了。但你要是真坐下来扒一扒，会发现生成的代码量和真正交付出去的价值，根本不是一回事。

字节这张图最狠的地方，是它把这个落差量化了出来。

我接着往下看，看到了那个更扎心的实验。

他们挑了一个豆包要上线的真实需求，难度中等，让用户在创作页面里做视频的预览和调整。不算简单，也没难到天上去，就是日常那种活儿。然后他们找了 3 个主流的 Coding 模型，配 3 个主流的 Agent 框架，两两组合，用同一个 prompt、同一个需求，每种组合各跑 100 次，总共 900 次。

900 次。这个样本量是认真的，不是 demo 级别的随手一试。

第一列结果，绿色那列，看的是跑出来的东西能不能用、功能对不对。所有组合都超过了 80% 的正确率。还行吧，挺让人满意的。要是只看这一列，你大概会得出结论，AI 写代码已经很能打了。

但他们把目光往右边挪了挪。

右边那几列，是 UI 易用性、交互、可靠性、可维护性、性能、兼容性。就是一个东西能不能真上线，得过的那些关。结果一看，所有组合在这些维度上的得分，相比正确率出现了断崖式的下跌。从原来的不及格水平，40 到 60 分之间，普遍卡在那儿。

而且表现得极其随机。有的代码异常处理写得稀烂，有的压根没去复用仓库里现成的组件，自己又造了一遍轮子，有的改着改着把历史功能给搞坏了，有的实现方式完全不符合团队的工程规范。

我看到这段的时候，没绷住，笑了一下。倒不是嘲笑，是那种太熟悉了的苦笑。

这不就是 vibe coding 嘛。

vibe coding 这个词过去一两年特别火，翻成人话就是凭感觉写代码，你有个想法，跟 AI 聊两句，它吐一版出来，你跑一下，不对就再改，改到看起来能用为止。轻、快、爽。我也曾经信过这个，觉得这就是未来的开发方式。

但洪定坤那句话点得特别准，他说软件工程本质是一种平衡的艺术，要满足业务，也要控制复杂度，要快也要稳，既要局部跑得通，也要全局可维护。而 vibe coding 给你的，往往只是那个能跑起来的、看着像样的版本。功能对，但离上线交付，差着十万八千里。

绿色那一列的 80%，是 vibe coding 的高光。右边那几列的 40 到 60，是它的真相。

说到这儿我得插一句，这两年有个词叫 harness 被炒得很热，就是给 AI 搭那层让它真正能干活的脚手架。大家一聊 harness 就往 Agent 框架、工具调用上想，觉得框架越花哨越好。这块我平时接触得多一点，所以洪定坤接下来讲的东西，我特别有共鸣。

他说，真正决定 AI 能不能落地的，往往不是那些花哨的框架，而是更基础、更不性感的工程问题。上下文工程，架构约束，团队的知识有没有沉淀进 memory 里，过去的技术债有没有人去梳理。他管这个叫基建。

然后他甩出了第二张图。

还是那 9 种模型加框架的组合，但这次把基建、把 harness 那层东西结合了进去。横坐标是正确率，纵坐标是可交付性。结果，正确率从 80% 爬到了接近 90%，这个提升不算夸张。但纵坐标那个可交付性，从原来 40 到 60 分的不及格，普遍拉到了 80 分。

同样的模型，同样的框架，就因为底下那层基建做扎实了，可交付性直接从勉强及格不了，跳到了能打的水平。

洪定坤那句总结我得原样抄给你，他说，你感觉 vibe coding 快了，但如果不把这些基建做好，实际未必快，甚至会慢。

感觉快了，可能慢了。

这话我太认同了。我自己搭东西的时候最深的体会就是，让模型吐出第一版代码是最不值钱的那一步，真正吃时间的是后面，是让它吐出来的东西能塞进现有的架构、能跟别的模块咬合上、能扛住线上的各种破事。前面省下来的那点时间，常常在后面加倍还回去。你以为自己抄了近道，结果绕了远路。

文章里还有个特别小、但我觉得特别戳的真实例子。

有个产品同学跑去找洪定坤，说我有个需求，自己用 vibe coding 已经做出来了，页面能看，流程能跑，结果拿给研发，研发说还得排期，可能还要几天。她特别不理解，为啥不能直接给我代码仓库权限，我自己提交，不就上线了吗？

后来他们认真看了那段代码，能跑是能跑，但性能不行，扩展性没考虑，还有权限安全问题。

我看到这儿，又笑了一下，但这次笑里带着点复杂。

因为这个场景，是真的越来越多了。AI 把写代码的门槛打了下来，产品、设计、运营，谁都能把想法变成代码了，这是个好事，沟通更直接，验证更快。但门槛降了，不代表系统的复杂度降了。代码要进既有架构，要跟现有模块配合，要考虑一堆你看不见的东西。

所以一边不能说除了工程师别人写的代码都不能用，那太傲慢；另一边也真不能谁写出来谁就直接往线上推，那是灾难。这中间的那道坎，洪定坤说是协作关系的重新洗牌。每个人都能生产代码了，但这些产出怎么汇进统一的架构、规范和交付流程里，这是个全新的、还没解的题。

我盯着这个产品同学的故事看了好一会儿。

你能怪她吗？怪不了。她看到的是一个能跑的页面，一个肉眼可见已经完成了的东西，凭什么还要等好几天？这个困惑太合理了。但研发看到的是另一层，是那段代码塞进线上系统之后会引爆的一连串问题。两个人站在同一段代码前面，看到的是两个完全不同的世界。

这种错位，我觉得才是 AI Coding 这一年真正暴露出来的东西。不是模型不够强，模型已经很强了，80% 的正确率摆在那儿。是我们整个研发协作的范式，还没追上模型的能力。

洪定坤后面也讲了字节自己在试的一些解法。比如原型驱动开发，过去是文档驱动，产品写 PRD，设计画图，研发写方案，一层层往下传，但文档里读着都合理的东西，做出来分歧大得很。现在 AI 把做原型的成本打下来了，能直接做出一个可交互的、跟真实场景高度拟合的动态原型，大家围着这个能点能动的东西去讨论，共识来得快多了。

还有他们在搞的系统化 AI Development，核心意思是别让 AI 只待在写代码这一个环节。他放了段视频，AI 根据需求先写 spec，写完代码之后自己用 browser use 的能力打开浏览器验证功能对不对，不对就自己 bugfix，确认没问题了自动提交、自动发布。让 AI 从写代码这一个齿轮，咬进研发流程的每一个齿轮里去。

这个方向我是真的觉得有点子牛逼。因为它戳中的正是前面那个落差的根子，10 倍的生成速度之所以只换来 1.6 倍的效率，就是因为 AI 只快了写代码这一段，后面的验证、联调、规范检查、上线，全是人在用传统方式吭哧吭哧地推。你只给整条流水线里的一道工序装了发动机，其他工序还在用手摇，整体的速度当然提不起来。

让我顺一下他们这套思路的内核。第一，别再盯着代码贡献率这种单一指标了，去找能衡量全局交付效率的指标。第二，治理，用更稳的方式让 vibe coding 长成真正的软件工程。第三，把上下游所有角色都拉进来好好协作。指标、治理、协作。这三个词单拎出来都挺朴素的，甚至有点无聊，但恰恰是这些不性感的东西，决定了那 6 倍的代码贡献率最后能不能真的变成产品价值。

顺带提一个数字，TRAE 现在 token 日均消耗到了 5.6 万亿，比去年涨了 50 倍。用户也在泛化，越来越多非技术背景的人在用它干日常的活儿，所以他们又推了个 TRAE Work，要跟火山引擎一起塞进 TRAE 企业版里。这部分官方味儿重一点，我就不展开了，感兴趣可以去看演讲全文。

我真正想跟你唠的，是那个 1.6 倍。

这阵子 AI 编程的叙事，铺天盖地都是 10 倍程序员、一个人顶一个团队、代码这门手艺要消失了。说真的，我每次刷到这种标题都有点恍惚，因为它跟我每天在工位上看到的景象对不上。我看到的更多是，模型确实能飞快地吐出一大坨能跑的代码，然后一群人围着这坨代码，花更多的时间去 review、去重构、去补那些它没考虑到的边界、去把它硬塞进系统里。

热闹是真热闹，但热闹不等于高效。

字节这个分享之所以让我想专门写一篇，是因为它太诚实了。一家把 AI Coding 推到 90% 渗透率的公司，没有站在台上喊我们效率提升了 10 倍，而是老老实实把那张 1.6 倍的图摆出来，告诉你中间的水分在哪儿、怎么把它挤出去。这种诚实，比一万句 AI 重塑软件工程的口号有用得多。

我一直觉得，AI 写代码这件事，最大的误区不是高估了模型，而是低估了交付。我们太容易被那个能跑起来的 demo 骗到了，一个东西在屏幕上动起来了，会给人一种它已经完成了 90% 的错觉。但真做过工程的人都知道，能跑只是起点，从能跑到能上线、能维护、能扛住线上流量，那剩下的 10%，往往要花掉 90% 的力气。

万能青年旅店有句词我特别喜欢，是谁来自山川湖海，却囿于昼夜厨房与爱。AI 写代码这事儿现在也有点这个味道，它来自一个宏大到要颠覆整个行业的叙事，最后却囿于异常处理、组件复用、权限安全这些昼夜厨房般琐碎的工程细节里。而恰恰是这些琐碎，决定了它到底是个炫技的玩具，还是个真能干活的工具。

所以如果你也在团队里推 AI Coding，我自己不成熟的一点感受是，别太早为那个代码贡献率的数字高兴。那个数字涨得越快，你越要回头看看右边那几列，看看可交付性还在不在及格线上。AI 已经把写代码这件事变简单了，但它同时把另一件事变得前所未有地重要，就是你那层基建、你那套协作、你对交付质量的那道把关，到底扎不扎实。

模型负责把代码写出来。能不能把它变成产品，还是人的事。

至少现在，还是。