字节跳动最新AI Coding实践曝光，我总结了7 条反常识的结论

最近看到字节跳动技术副总裁洪定坤在火山引擎 Force 原动力大会上做了一场关于 AI Coding 的分享，聊的是他们在 AI Coding 上的真实实践。不是那种“我们很厉害”的宣传，反而很坦诚地讲了踩过的坑、遇到的问题，以及他们现在怎么想这件事。我觉得里面有不少东西挺值得琢磨的，整理出来跟大家聊聊。

数据好看，不代表事情做好了

先说一组数据。过去一年，字节内部 AI 代码贡献率涨了 6 倍多，AI 在编程上消耗的 token 涨了 5 倍，代码合入率也翻了 2 倍多。这些数字乍一看很唬人，感觉 AI 已经全面接管了写代码这件事。

但洪定坤自己说，这些数字不代表他们做得有多好。恰恰相反，用得越多，越能感受到问题在哪。

他拿自家的 TRAE 团队举了个例子。这个团队本身就是做 AI Coding 工具的，用 AI 非常激进，过去半年超过 90% 的代码都是 AI 写的。按道理说，AI 写代码的速度至少是人的 10 倍，那效率应该有好几倍的提升才对。但实际结果呢？人均需求吞吐只提升了 60%。

10 倍的速度优势，最后只转化成了 1.6 倍的效率提升，中间那巨大的落差去哪了？

这个问题其实很有意思。我们日常生活中也经常遇到类似的情况，比如买了个效率工具，感觉自己应该能多做很多事，但实际上时间还是不够用。问题往往出在：你只优化了其中一个环节，但整个链条上还有很多其他瓶颈没解决。写代码快了，但理解需求、设计方案、测试验证、沟通协调这些环节并没有同步变快。

所以洪定坤的第一个观点就是：不要过度迷信单一指标。AI 代码贡献率高，不等于整体效率真的提升了。如果只盯着一个数字去优化，很可能会忽略全局的问题。

感觉快了，实际可能更慢

第二个话题是关于 Vibe Coding。这个词这两年特别火，意思就是那种很随性的开发方式：脑子里有个想法，跟 AI 聊几句，生成一版代码，跑一下能用就行，不行再改。整个过程很轻快，很“跟着感觉走”。

听起来很美好对吧？但洪定坤说，在真实的企业开发里，这种方式有很大的隐患。

他们做了一个很有说服力的实验。选了一个中等复杂度的真实业务需求，用 3 个主流 AI 模型配 3 个主流框架，同样的提示词，每种组合跑了 100 次，总共 900 次。

结果怎么样呢？功能正确率都挺高，基本都超过 80%。也就是说，AI 写出来的东西大部分情况下“能跑”。但是，当他们去看 UI 易用性、可维护性、性能、兼容性这些维度的时候，分数直接大幅下降。有的代码异常处理不规范，有的没有复用已有的组件，有的改动影响了别的功能，有的写法完全不符合团队规范。

换句话说，AI 写的代码“能用”和“能上线”之间，还隔着一条很宽的鸿沟。

这个道理放到我们日常工作中也一样。很多时候我们觉得一件事“差不多了”，但“差不多”和“真正能交付”之间的差距，往往比我们想象的要大得多。快速出活是一种能力，但把活做到真正可靠、可持续，是另一种更稀缺的能力。

基建才是真正的胜负手

那怎么解决这个问题呢？洪定坤提到了一个概念叫 Harness，翻译过来就是“基础建设”。

具体来说，就是在让 AI 写代码之前，先把一些基础工作做好：比如上下文工程（让 AI 能理解当前项目的背景和约束），架构约束（告诉 AI 哪些东西能动哪些不能动），团队知识沉淀（把过去积累的经验和规范喂给 AI），以及技术债的梳理（让 AI 知道哪些历史遗留问题需要注意）。

加上这些基建之后，同样的实验再跑一遍，效果完全不一样了。正确率从 80% 提升到接近 90%，更关键的是可交付性从之前四五十分的不及格水平，直接拉到了 80 分。

这说明什么？AI 本身的能力其实已经不错了，但它需要足够的上下文和约束才能发挥好。就像一个聪明的新员工，能力很强，但如果你不告诉他公司的规矩、项目的背景、团队的习惯，他写出来的东西大概率不符合要求。

这个思路其实可以迁移到我们使用任何 AI 工具的场景。很多人觉得 AI 不好用，可能问题不在 AI 本身，在于你给它的信息不够、约束不清楚。你花时间把背景交代清楚、把要求说明白，AI 的输出质量会有质的飞跃。

人人都能写代码，但不是人人都能上线

AI 带来的另一个有趣变化是：写代码这件事不再是程序员的专利了。产品经理、设计师、运营，谁都可以用 AI 把自己的想法变成代码。

洪定坤讲了一个真实的故事。有个产品同学用 Vibe Coding 自己做了一个功能，页面能看，流程也能跑。她就去找研发说，能不能给我代码仓库权限，我直接提交上线？结果研发一看代码，性能不行，扩展性没考虑，还有权限安全问题。

这个场景特别典型。AI 降低了代码生产的门槛，但没有降低系统复杂度。一段代码要放进真实的业务系统里，需要和已有的模块配合，需要考虑性能、安全、可维护性等等一堆问题。这些东西不会因为 AI 能写代码就自动消失。

但反过来说，也不能因此就否定非技术人员参与的价值。产品同学能快速做出原型，能让想法更直观地呈现出来，这本身就是巨大的效率提升。关键是要找到一个合理的协作方式：让更多人参与到代码生产中来，但产出要经过统一的规范和流程才能上线。

这其实就是一个“开放”和“规范”之间的平衡问题。任何组织都会遇到这种张力：你想让更多人发挥创造力，但又不能没有标准和底线。

用原型替代文档，先做出来再讨论

在具体的实践方法上，洪定坤分享了一个我觉得很有启发的做法：原型驱动开发。

传统的开发流程是：产品写需求文档，设计画图，研发写技术方案，然后再写代码。问题是，很多分歧在文档阶段根本发现不了，等做出来了才发现大家理解的完全不一样。

现在有了 AI，做原型的成本大幅降低了。与其花时间写一堆文档来描述你想要什么，不如直接做一个可交互的原型出来。大家围绕着一个真实的、能点能用的东西去讨论，比对着文字空想要高效得多。

这个思路其实适用于很多场景。与其花大量时间去“想清楚”，不如先快速做一个粗糙的版本出来，在实际的东西上去迭代。完美的计划不如一个能跑的原型。

让 AI 参与全流程，而不只是写代码

还有一个重要的观点：AI 不应该只参与“写代码”这一个环节，应该进入整个开发流程。

洪定坤说，他们内部经常遇到的情况是：写代码这一步用了 AI，但前面的需求分析、后面的测试验证、发布上线，还是传统的方式在做。就像一条流水线上只有一个环节换成了自动化，其他环节还是手工操作，整体效率提升自然有限。

他们现在的做法是让 AI 参与从写 Spec（技术规格说明）到自动验证功能正确性，再到自动提交发布的全流程。AI 写完代码后，自己打开浏览器验证功能对不对，发现 bug 自己修，确认没问题了自动提交上线。

这个思路的本质是：如果你要用 AI 提效，就不能只在一个点上用，要让它贯穿整个链条。任何一个环节如果还是老办法，就会成为新的瓶颈。

从个人能力到组织能力

最后一个值得关注的点是：怎么把少数人的经验变成整个团队的能力。

洪定坤观察到，早期 AI Coding 的效果很依赖个人水平。有些工程师特别会写提示词，懂得怎么管理上下文，知道怎么拆解任务，所以他们用 AI 的效率特别高。但对一个组织来说，只有少数人厉害是不够的，需要把这些经验沉淀下来，变成标准、工具和流程，让所有人都能受益。

他们的做法是把内部摸索出来的最佳实践文档化、产品化，直接沉淀到 TRAE 这个工具里，让所有人都能用上。

这个逻辑放到任何领域都成立。一个人摸索出了好方法，如果只停留在个人层面，价值是有限的。真正厉害的是能把个人经验提炼成可复制的方法论，让更多人受益。不管是在公司里还是在个人成长中，这种“把隐性知识显性化”的能力都非常重要。

写在最后

整场分享听下来，我觉得最核心的一个信息就是：AI Coding 这件事，远没有看起来那么简单。不是说有了 AI 就万事大吉了，真正的挑战在于怎么把 AI 融入到完整的工程体系里，怎么在“快”和“稳”之间找到平衡，怎么让更多人参与进来的同时保证质量。

对我们普通人来说，道理其实是相通的。工具再好，也需要正确的方法和体系来配合。追求速度的同时不能忽略质量，降低门槛的同时不能丢掉标准。这些看似朴素的道理，在 AI 时代反而变得更加重要了。

最后，告诉大家一个好消息：我的星球社群已经运营了 800 多天，累计主题 2000 个，星球加入人数 1750 人，精华主题 292 篇，各种专栏课程累计上百篇，今年更新的视频教程也有 50+ 了。