字节说 TRAE 团队 90% 代码 AI 写的，可吞吐只涨了 60%，这个差我天天在还
哈喽，我是飞飞。
先说个我自己天天发生的画面。我把一个改造任务丢给 Claude Code，按个回车去倒水，回来屏幕上已经哗哗刷出十几个文件的改动，绿一片红一片，看着特别猛，像是半小时的活它三十秒就干完了。
那一瞬间我是有点爽的。但这两年用下来，我越来越清楚一件事：它写出来这么多，跟我今天真正交付了多少，根本是两码事。
这几天火山引擎开 Force 大会，字节跳动技术副总裁洪定坤分享了一组字节内部的数据，正好把我心里这个模糊的体感，给量化出来了。
90% 和 60%，这是两个完全不同的东西
洪定坤说的那组数，核心是这么两句：字节的 TRAE 团队，过去半年里 90% 以上的代码由 AI 生成；但同一个团队，人均需求吞吐量只提升了大约 60%。
我第一次看到这两个数摆一起，心里咯噔一下，因为它说中了一个特别容易被忽略的事。很多人会下意识把这两个数字当成一回事，觉得「AI 都写了九成代码了，那效率不得翻几倍」。可它们压根不是一个维度的东西。
90% 衡量的是「AI 写了多少」。你这个仓库里的代码，敲键盘这件事有多少是机器替你干的。
60% 衡量的是「你真正交付了多少」。需求从提出到上线，一个人单位时间里能吞下多少个，这是落到业务上的产出。
一个说的是生产线吐了多少零件，一个说的是最后装出了多少台能跑的车。把九成的代码交给 AI 写，离「我效率翻倍」中间，还隔着一道又宽又深的沟。这道沟，就是 90% 减 60% 那剩下的部分。
我得先说清楚我的立场，免得被当成又一篇唱衰 AI 编程的。我自己是重度依赖 AI 写代码的人，我整条写作流水线，十几个 skill，全押在 Claude Code 上。AI 确实让我写得快多了，这点我一点不否认。我想戳的，是「代码贡献率」这个让人特别容易上头的指标。
我每天省下的，是手速；没省下的，是脑力
为什么写了 90% 的代码，吞吐才涨 60%？洪定坤给的解释我很认同：单纯盯着代码生成数量这一个指标，会失真。真实工程里，代码能不能交付、可不可靠、好不好维护、性能撑不撑得住，这些维度都得算进去，而它们恰恰不是「多写代码」能解决的。
这套话拿我自己每天的活一对照，几乎严丝合缝。
AI 一秒蹦出十几个文件的改动，省掉的是我打字的时间。这部分确实省了，而且省得很爽。可它一动手，我后面真正费时间的活才开始。我得逐个 review 它写得到底对不对，得反复跟它对齐它有没有真的听懂我要什么，更多时候是收拾它莽着改之后留下的烂摊子。
举个我印象最深的。前阵子我有个七千行的 SpringBoot 老项目，要从 Java 迁到 Kotlin。这种活听着特别适合丢给 agent，量大、机械、有套路。我也是这么想的，结果一个迁移任务，我跟它来回改了几十次。它会把一段逻辑迁得语法上挑不出错，但把原来某个边界判断悄悄改了味道；它会自作主张引一个我项目里压根没用的写法；它会在我没盯着的地方，留一个跑起来才炸的坑。
每一次来回，省的都是我打字，费的都是我动脑。我得逐段读它迁的逻辑，想清楚它哪里偏了，得判断这个改动到底能不能收，还是得整段推倒重来，得把它理解错的意图一句句重新校准回来。这部分脑力，一秒都省不掉，反而因为它写得太快、改得太多，我兜底的负担比从前自己一行行敲的时候更重了。它越能写，我越得睁大眼睛盯。
所以字节那个 90% 对 60% 的剪刀差，我一看就懂。敲键盘的手速 AI 能整个包圆，可动脑子兜底这件事它一点都帮不上，甚至还在给我加量。
字节那批模型对比实验，戳的也是同一件事
洪定坤还提到一个我觉得特别实在的发现。字节内部拿多个模型、配上几套主流的 Agent 框架，反复去测同一个需求。结果是，代码的正确率普遍能超过 80%，听着挺漂亮。但只要把维度往「可交付性、可靠性、可维护性、性能」上一拉，分数就明显往下掉。
这个落差跟 90% 对 60% 是一回事，只是换了个角度说。「正确率 80%」是又一个看着光鲜的单一指标，跟「代码贡献率」一个性质。它告诉你 AI 写的东西大概率没语法错、能跑，但没告诉你它好不好维护、靠不靠谱、上了量会不会崩。
我自己用 Claude Code 也是这个体感。它给我的代码，单看「能不能跑」这一项，及格率是很高的。可一旦我要把它真正合进项目、要对它后面的可靠性负责，那 80% 和「我敢直接上线」之间的距离，全得我自己用脑力去填。
别让「AI 写了多少行」变成你团队的 KPI
把这事想透之后，我对怎么看 AI Coding 的指标，多了个判断，分享给你。
如果你或者你的团队在衡量 AI 编程的收益，千万别只盯着「AI 写了多少代码」「代码贡献率涨了几倍」这种数。据火山引擎披露，过去一年字节的 AI 代码贡献率涨了大概 6 倍、token 消耗涨了大概 5 倍。这些数字很有视觉冲击力，发出来一片惊呼。可它们衡量的是「机器替你敲了多少键」，不是「你团队多交付了多少东西」。
真正该盯的是后面那个数：单位时间里，需求从提出到稳定上线，到底多吞下了几个。这个数涨了，才是真省了时间。这个数没动，哪怕 AI 把你 99% 的代码都写了，你的人也还是被卡在 review、对齐、兜底这些动脑子的环节里，省下来的那点打字时间填不平这道沟。
可以拿这条当个判断法则搬走用：评估任何一个 AI 编程工具值不值，别看它能帮你写多少，看它能不能帮你省下兜底的脑力。能省手速的工具满地都是，能真正分担「判断对不对、靠不靠谱」这部分的，才是真值钱的。我现在掂量要不要为一个活动用更贵的模型，过的也是这杆秤。
我特别认洪定坤那句单一指标会失真。在一个 AI 一秒能蹦出十几个文件的时代，最容易骗到自己的，就是看着满屏的改动，以为自己今天产出了很多。
最后想问问你：你或者你们团队现在是用什么衡量 AI 写代码的产出的，是看它写了多少行，还是看真正交付了多少个需求？这两个数，在你那儿差得大吗？评论区聊聊，我挺好奇别人是怎么卡这道沟的。