前几天看完字节的技术副总洪定坤在Force大会上的分享，我觉得终于有人说出了AI Coding的现状。

过去一年，字节的AI代码贡献率增长了6倍，tokens消耗增长了5倍。听起来AI Coding已经成功了。

但实际情况是：在他们TRAE的团队里，超过90%的代码由AI生成，而人均需求吞吐率只提升了60%。

代码多了好几倍，但真正交付出去的需求只多了60%？这中间发生了什么？

1️⃣ 字节发现了一个核心问题：正确率≠可交付性

字节做了900次实验，测了主流Coding模型的真实表现，结论让人意外：代码正确率超80%——但可交付性只有40-60分。

正确的代码，不一定是能交付的代码。

代码能跑，不代表它符合工程规范。能跑，不代表它通过了完整的测试集。能跑，也不代表它能安全部署到生产环境。

"正确率"是个好看的指标，但它只量了这件事的一半。

2️⃣ Harness基建是真正的分水岭

字节的解法是：把Harness和AI Coding接在一起，接了Harness之后，可交付性从40-60分提升到了80分。

这个提升不是靠换了更强的模型，也不是靠更好的提示词——是靠把AI生成的代码嵌进了完整的工程交付流程。

大多数公司推AI Coding，装了个Copilot插件就算完了，但那只是开始。

3️⃣ 单一指标是最危险的陷阱

洪定坤在演讲里提了一个警告：过度关注单一指标，数据会失真。

TRAE团队的例子就是证明——代码AI生成率超90%，但需求吞吐率只提升60%。

如果你只看"AI写了多少代码"，你会觉得效率翻了好几倍。如果你看"交付了多少需求"，你会看到另一个答案。

"AI代码生成率提升X%"是一个容易汇报给老板的数字，但它量的是投入，不是产出。

真正应该量的是需求交付吞吐率——这个数字才会告诉你AI Coding有没有真正帮到你。

4️⃣ 字节实验给出的3个信号，可以直接参考

换指标：
把"AI代码贡献率"换成"需求交付吞吐率"。
前者量投入，后者量产出。
汇报的时候用后者，内部决策的时候也用后者。

基建先行：
别急着推全员AI Coding，先把测试、评审、部署这条链路搭好。
AI生成的代码质量可以很高，但没有基建接住，可交付性会停在40分。

小规模实验，拿真实数据：
字节用900次实验才摸清楚可交付性的真实水位。一次就推到全公司，拿到的大概率是失真的数据。

现在很多公司说自己在推AI Coding，其实是在推一个漂亮的投入指标。

字节花了一年、900次实验、烧了大量tokens，才真正搞清楚AI Coding的瓶颈在哪里。

这个瓶颈不是模型不够聪明。

是你的工程基建、协作方式和指标体系没跟上。