@xiaogaifun: 字节对大厂 AI Coding 的反思，好真实。 字节技术副总裁洪定坤的分享，我来回看了好几遍，很有启发。 字节在 AI Coding 方面的实践还是很有代表性的，推荐所有做研发的同学都可以看看。应该会感同身受。 我看完记了一整页笔记，分…

字节对大厂 AI Coding 的反思，好真实。 字节技术副总裁洪定坤的分享，我来回看了好几遍，很有启发。 字节在 AI Coding 方面的实践还是很有代表性的，推荐所有做研发的同学都可以看看。应该会感同身受。 我看完记了一整页笔记，分享给大家。 我甚至觉得可以把这个分享理解为字节在 AI Coding 上的一些真实反思。 根据自己的理解，我把这个分享里对我有启发的几个判断展开来聊一聊。 其中会夹杂很多我自己的感触，想看原文的可以直接去找演讲全文。 反思一：AI 代码贡献率不该是 KPI AI Coding 基本上都已经逐步进入了各个公司的生产流程。 很多人都在说自己的业务有 90% 的代码是 AI 生成的，乍一听，感觉很恐怖。 但其实，AI 对研发的提效没有外界想象的那么高。 洪定坤举了 TRAE 团队的例子。TRAE 本身就是做 AI 工具的，所以这个团队对 AI Coding 的采用非常积极。 过去半年里，他们有 94% 的代码都是 AI 贡献的。但人均需求吞吐率只提升了 60%，也就是之前的 1.6 倍。 这就有疑惑了，AI 写代码的速度至少是人的 10 倍以上，如果 90% 以上的代码都是 AI 产出的，效率至少应该提升 5 倍或者 10 倍吧？为什么只提高了 1.6 倍？ 字节得出来的结论是，单一的指标，比如 AI 代码占比，根本没有办法代表真实的生产力。 如果把 AI 代码贡献率当成 KPI，结果就是大家都去优化 AI 的生成量，而不是优化交付能力。 看起来 AI 用了很多，但系统的效率并没有真正变好。 那为什么 90% 的代码都是 AI 写的，人效才提了 1.6 倍？一个很重要的原因是，写代码只是整个研发流程的一个环节。 写之前要理解需求、写 Spec，写完之后要验证功能、提交发布，这些环节如果还是传统方式，光把写代码加速了，整体效率提不上去。 洪定坤把字节在这方面的尝试叫做系统化的 AI Development，核心意思就是 AI 不能只管写代码，得让它进入更多的研发环节，整条链路都跑通，效率才能真正上来。 前两天出去的时候还跟别人争论这件事。现在还有不少公司在追踪员工到底用了多少 Token，说白了，这是在追踪过程。 更应该关注的是，用了这个工具之后，从结果层面去看，交付到底有没有变得更快、更可靠。 一个团队天天说自己 AI 工具用得贼溜，消耗了多少 Token，但没有什么有效的产出，那这到底是好事还是坏事。我觉得这是一个值得每个管理者思考的新问题。 反思二：功能正确≠工程可用 Vibe Coding 的理想状态是就像聊天一样，用自然语言表达自己的需求，最后做出来想要的产品。 如果哪里不对，再用自然语言和 AI 沟通，让它修改。这是过去一年 Vibe Coding 风靡的思路。 对于不太复杂的应用，这种方式完全没问题。我自己做的一些项目基本上就是这个流程跑下来的。 但只要是做生产级的软件，无论公司大小，流程肯定不是这样。 因为公司里必然有老代码，有一套约束。怎么复用已有的组件，安全和权限怎么处理，性能怎么保证，还有兼容性、可维护性。 正经写过工程代码的人都清楚，Vibe Coding 描述的那个状态是比较理想化的，更适合做小项目和验证想法。 真正的程序员虽然也在 Vibe Coding，但流程跟理想状态不一样。 字节内部做了一个实验来验证这个判断：三个模型，三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。 结果发现，AI 在功能正确率上表现还不错，所有组合都超过了 80%，也就是说，AI 把功能写对的能力已经过了及格线。 但无论哪个组合，生成代码的工程质量都不太好。比如 UI 不对，没有复用组件，性能有问题，结构不符合规范。 这些问题大家在用 AI 写代码的时候应该都碰到过。 现在所有上了牌桌的 Coding 模型，都已经过了 Opus 4.6 这个级别的临界点，模型可以自主写代码了。 这个时候影响 AI Coding 成败的绝对不是裸模型，而是裸模型加上 Harness 的能力。 这个判断本身不算新鲜。 但我最受触动的是字节对 Harness 的理解。 他们的反思是，整个行业好像还是把 Harness 等同于 Agent 框架，诸如用 single agent 还是 multi agent，包含哪些角色，角色之间怎么配合。 这些当然重要，但字节在实践中发现，真正决定 AI Coding 能不能落地的，反而是更基础、更工程化的东西。 洪定坤把它叫做基建。 比如上下文工程有没有做好，架构的约束够不够清晰，团队的知识能不能有效沉淀下来，过去的技术债有没有梳理清楚。 这些看起来不那么性感的工作，反而直接影响 AI Coding 的效果。 实验数据也验证了这一点。同样的模型和框架组合，把这些基建结合进去之后，功能正确率直接从 80% 提升到了接近 90%，工程质量得分，也从之前 40 到 60 分的不及格水平，普遍提升到了 80 分左右。 基建做不好的话，可能的后果是，Vibe Coding 感觉快了，但实际整体可能更慢。工程的债，迟早得还。 反思三：代码门槛下降之后，团队怎么协同 洪定坤分享里有一个例子让我印象很深刻。 产品经理有个需求，发现还得等研发排期，就说那我自己来吧，用 AI 三下五除二就把功能给实现了。 确实这个功能不复杂。做完之后产品经理把代码给到研发，说我已经把代码写完了，现在你只需要帮忙把功能上线就行。 研发一看，不行。你这代码能跑，但不符合上线的规范，有权限问题、安全问题。 产品经理就很委屈，你们没时间做这个需求，现在我都做完了又不让上线。可研发看到的其实是代码质量的问题。 所以这里面就有一个需要所有人正视的事情，虽然代码的生成门槛虽然下降了，这并不代表系统的复杂度也下降了。 真实的业务系统里，代码要放到已有的架构里，要跟已有的模块配合，还要考虑各种各样的问题。 绝对不是谁写出来就能直接上线的。不然肯定会出问题。 怎么让不同角色的人用同一套工具和规范做出符合要求的代码，这是接下来大家需要去解决的。 字节的思路是在内部尝试工具化。比如把内部实践直接产品化，沉淀到 TRAE 里面，开放给所有人。 其实说白了就是工具化。 我看朋友圈有好多大佬也都在转这篇文章，应该还是有挺多共鸣的。 我感觉这一次分享多少也是一些拨乱反正吧。因为过去一段时间确实有很多听起来很离谱的言论，有些人会疯狂地炫耀自己使用了多少 Token，会认为这就代表着 AI Native...... 强烈推荐大家看看原文。字节跳动的公众号就有。