夜雨聆风AI 代码占比 94%，人效只提升 60%——字节的这组数据，戳破了多少公司的自我感觉良好
原文来源：
- 洪定坤演讲全文：https://www.cnblogs.com/volcengine-developer/articles/18947887
- 极客公园深度报道：https://www.163.com/dy/article/L09B703L05119FMA.html
字节跳动技术副总裁洪定坤在火山引擎大会上说了一组数据，很多人看完第一反应是"好真实"，但我觉得大多数人其实没读懂它真正刺痛的地方在哪里。
TRAE 团队过去半年，超过 90% 的代码由 AI 产出，但人均需求吞吐率只提升了 60%。
这两个数字放在一起，是一道算术题，也是一记警钟。
一、这组数字到底说明了什么
先把直觉上的错误纠正掉。很多人看到"90% 的代码是 AI 写的"，下意识会算：AI 写代码比人快 10 倍，90% 的代码都是 AI 产出的，那效率至少应该提升 5 倍甚至 10 倍。结果只有 1.6 倍，这说明 AI 不行？
不对。这个直觉犯了一个基本的工程错误：把局部加速当成了系统加速。
洪定坤在演讲里直接给出了答案：一个典型的软件开发过程中，写代码可能大概占不到 40% 的工作量。而且，越复杂的应用，代码工作的占比越少。
剩下那 60% 是什么？理解需求、写技术方案、环境搭建、联调、测试、Review、部署、运维、Debug、压测……这次洪定坤自己用 TRAE 三天开发"积流成江"应用，85% 的代码是 AI 写的，但他在演讲里坦承：发布前还额外花了一个完整周末做压测、运维和各种杂活，"其实到昨天还在做一些压测"。
所以 60% 的提升，不是 AI 能力不够，而是加速只发生在整条链路的一个环节上。
这让我想到一个经典的工程学结论：阿姆达尔定律（Amdahl's Law）。系统的整体加速比，受限于不可并行化部分的比例。即使把可加速的部分优化到极致，整体收益也有硬上限。现在的 AI Coding 就是这个处境——写代码这个环节被压缩到了极限，但系统整体的瓶颈已经转移到别处了。
这意味着，下一阶段 AI Coding 的核心战场，不是让模型把代码写得更好，而是让 AI 进入那 60% 还没被覆盖的环节。洪定坤把这个方向叫做"从 AI Coding 到 AI Development"——AI 不只管写代码，要成为整个研发链路的调度者，从需求管理、设计还原、Debug，一直打通到部署上线。
二、AI 代码贡献率这个 KPI，正在害很多公司
现在有一种很常见的管理动作：追踪团队的 AI 工具使用量——消耗了多少 Token，AI 代码占比多少，采纳率多少。
洪定坤的数据直接反驳了这种做法。
当你把 AI 代码贡献率当成 KPI，团队就会去优化这个数字本身。结果是什么？大量简单的、模板式的代码交给 AI 批量生成，这些代码占比高，但单行价值低。真正需要深度工程判断的部分，反而因为"让 AI 先生成一版"的惯性，被草草处理。
这是一种典型的“指标替代目标”的管理陷阱。Goodhart 定律说得很清楚：当一个指标变成目标，它就不再是一个好指标了。AI 代码占比本来只是一个观测量，一旦变成考核项，它就开始被优化，然后失去了它原本想反映的意义。
更应该看什么？洪定坤没有直接给出答案，但逻辑是清楚的：**从结果层面看，需求从提出到上线的周期缩短了多少，线上质量有没有提升，工程师把多少时间从重复劳动里解放出来用于真正的设计决策**——这些才是 AI 是否真正提升了生产力的信号。
三、功能能跑通，和能上线，之间有一道真实的鸿沟
字节内部做了一个实验：三个主流 Coding 模型、三个 Agent 框架，两两组合成 9 种方案，针对同一个真实需求，每组跑 100 次，共 900 次。
结论是两段的：
第一段，功能正确率——所有组合都超过了 80%。AI 把功能写"对"的能力，已经过了及格线，这一点无需争议。
第二段，工程质量——UI 不符合规范、组件没有复用、安全权限处理缺失、性能有问题、防御性编程基本缺席——评分普遍在 40 到 60 分之间，不及格。
这两段结论放在一起，精确地描述了当前 AI Coding 的能力边界：**AI 能写出"能跑"的代码，但写不出"能活"的代码。**
"能跑"和"能活"的区别在哪里？
能跑，是指在理想路径下，功能按预期执行。能活，是指代码在真实生产环境里——用户输入了意外数据、网络中断、并发量突然上来、第三方服务挂了——系统还能优雅地处理，不崩溃，不泄露数据，并且后续的工程师还能看懂、维护、扩展它。
Vibe Coding 天然偏向"能跑"。它的工作方式是：描述需求 → AI 生成 → 跑通 → 下一个。这个循环里缺少一个关键环节：**对异常路径和工程质量的主动审查**。防御性编程、异常处理、组件复用——这些在 Demo 里看不出差别，但在生产里决定系统寿命。
洪定坤在演讲里说了一句很诚实的话："哪怕 85% 的代码都是 AI 写的，但仍然是我在驱动整个过程……人是非常重要的。"他还提到，昨天晚上突然出了一个 bug，AI 找起来也有难度，最后是他和 AI 一起完成的。
这不是谦虚，这是一个严肃的工程判断。
四、真正卡住 AI Coding 落地的，不是模型，是基建
行业里关于 AI Coding 的讨论，很大一部分集中在"用哪个模型"、"用 Single Agent 还是 Multi Agent"、"角色怎么设计"。字节的结论是：**这些当然重要，但不是真正的瓶颈。**
洪定坤把真正的瓶颈叫做"基建"——上下文工程、架构约束、团队知识沉淀、历史技术债梳理。
这听起来不性感，但数据是硬的：同样的模型和框架组合，把这些基建结合进去重跑实验，工程质量评分从 40~60 分直接拉到了 80 分左右。
为什么基建这么关键？因为 AI 生成代码的质量上限，取决于它能读到多少有效的上下文。
给 AI 一个边界模糊、规范缺失的代码库，它生成的东西也会边界模糊。给 AI 一个清晰的架构约束文档、一套明确的组件使用规范、一份梳理过的历史技术债地图，它生成的代码质量就会显著不同。
这件事的本质，是把原本靠老工程师经验口耳相传的东西，显式化、结构化，变成 AI 可以消化的上下文。这本身就是一个大工程，而且是必须人来做的工程。
所以有一个反直觉的结论：**AI Coding 落地得好的团队，往往不是那些工程规范最差、最需要 AI "救场"的团队，而是那些原本工程底子就扎实、愿意把规范进一步显式化的团队。** AI 是乘法器，不是救火员。底子好，乘出来的结果才好。
五、"产品经理写的代码，为什么不能上线"——这个问题没有捷径
洪定坤分享了一个字节内部真实发生的场景：一位产品经理等不到研发排期，自己用 AI 做出了功能，拿给研发说"我已经写完了，你帮上线就行"。研发一看：有权限漏洞、安全问题、不符合架构规范，上线了会出事。
产品经理很委屈：你们排不了期，我自己做出来了，还不让上线。
研发也很委屈：代码质量有问题不是态度问题，是事实问题。
**这个冲突背后是一个结构性矛盾：AI 降低了写代码的门槛，但没有降低系统的复杂度。**
生产环境里的代码，要嵌入已有架构、和已有模块配合、满足安全和权限要求、保证性能和稳定性、让后续的工程师能维护——这些约束跟谁写的代码无关。AI 写的代码需要满足，产品经理用 AI 写的代码同样需要满足。
这里有两个常见的错误反应。
第一种：因为"不是工程师写的"就一概否定。这很短视。产品经理能低成本地把想法变成可交互的原型，本身是一件好事，沟通更直接，验证更快。问题不在于谁写的，而在于有没有经过正确的工程审查流程。
第二种：直接给产品经理开仓库权限，让他们自己上线。这更危险。系统的复杂度不会因为工具变简单了就自动消失。
字节的思路是往工具化方向走：**把工程规范、安全约束、架构要求沉淀进工具本身，让不同角色用同一套约束生成代码，而不是事后靠人工 Review 来补漏洞。** 规范前置，而不是审查后置。
这个思路是对的，但实现难度不低。规范的显式化本身就需要大量工程投入。而且规范一旦落到工具里，就要保持更新，不然会成为新的技术债。
六、一个更大的问题
洪定坤的演讲被很多人解读为"字节对 AI Coding 的真实反思"。这个定性有点过誉——演讲本质上是字节在大会上推介 TRAE 产品，数据来源是 TRAE 内部团队，不代表字节整体，语气也更多是展望而非反思。
但演讲里有几个判断是真实的、有价值的：指标陷阱、工程质量鸿沟、基建决定上限、协作摩擦的结构性来源——这些问题字节碰到了，所有在认真落地 AI Coding 的公司都会碰到。
还有一个问题洪定坤没有直接说，但数据已经暗示了：**当 AI 写代码的速度不再是瓶颈，新的瓶颈就变成了"人能不能足够快地提供有效的需求输入、做出准确的架构决策、完成高质量的代码 Review"。**
这意味着，AI Coding 对工程师能力的要求，不是在下降，而是在重新分布。机械性的编码工作被压缩了，但系统设计能力、上下文组织能力、工程判断力——这些被放大了。未来工程师之间的差距，不会体现在"谁写代码更快"上，而会体现在"谁能让 AI 在更复杂的场景里生成更高质量的输出"上。
Vibe Coding 降低了入门门槛，但没有降低做好的门槛。这两件事不是一回事。
