6 月 23 日，火山引擎 Force 原动力大会在北京举行。现场，字节跳动技术副总裁洪定坤进行了《 AI Coding 的实践与探索》主题分享。
过去一年，字节跳动的 AI 代码贡献率增长了 6 倍多，但洪定坤表示，正是因为用得多，所以企业在真实的 AI Coding 落地上感受到了更大的挑战。
什么是 AI 时代的好指标？如何让 Vibe Coding 真正进入软件工程？企业不同角色如何更好地合作？他在演讲中分享了自己的经验。
以下是演讲全文，在不改变原意的前提下进行了编辑和整理：
大家好，我是字节跳动的洪定坤。
去年，我向大家介绍了我们的 AI Coding 产品 TRAE。今年我想换一个主题，不再讲产品，而是分享一下我们在 AI Coding 中的实践与探索。
当然，今天的 AI Coding 仍然还在探索期，远没有形成一套固定范式。字节内部业务形态很多，我们也鼓励不同团队结合自身的场景更积极、更认真、更深入地尝试。今天的分享也并非给出一个“标准答案”。
过去一年，字节跳动 AI 代码贡献率已经增长了 6 倍多。同时， AI Coding 上的 tokens 消耗增长了 5 倍，并且每个月仍然在保持高速增长。 AI 的代码合入率也增长了超过 2 倍。
这些数字说明什么呢？说明 AI Coding 已经非常深入地嵌入到了我们的日常研发流程。但我要非常坦诚地说，这些数字不代表我们的 AI Coding 实践已经做得非常好。实际上，正因为用得越来越多，我们对 AI Coding 的“挑战”有了更真实的体感。
AI Coding 遇到的挑战
过度重视 AI 代码贡献率
第一个挑战是指标。当我们开始把 AI Coding 引入日常研发之后，很自然地会先关注一些直观指标，比如 AI 代码贡献率、采纳率、生成代码量。
这些指标确实有参考价值。但我们在实践里也发现，如果只看这些数字，很容易带来一个问题，就是会把 AI Coding 简单理解成“我用了多少 AI”、“我用 AI 生成了多少代码”。甚至一些团队，把这个指标定成了一个 KPI，单纯围绕这个指标去提升和优化。
这个感受一开始没那么明显。因为当这些数字快速增长的时候，我们很容易自我感觉良好，觉得自己走在了时代前列，用 AI 带来了很大的生产力提升。但内部认真分析一下就会发现，真实的情况是有一些出入的。
这是 TRAE 团队过去半年的数据。作为本身就在做 AI Coding 工具的团队，TRAE 非常积极也非常激进地尝试 AI Coding。过去半年 TRAE 里的代码超过 90% 的代码是 AI 写的。同时我们关注到，人均需求吞吐率提升了 60%，达到 1.6 倍。
单看这个数字还不错。但大家都知道，AI 写代码的速度，起码是人的 10 倍以上，当 90% 的代码都由 AI 产出之后，那其实带来的效率应该远远不止 60% 这么简单，它应该是几倍甚至一个数量级的提升。
但实际过程中，10 倍和 1.6 倍之间，有着很大的差距。我觉得这个数字背后就可以看到。单一的代码贡献率，其实很难完全衡量我们实际效率的提升，它会失真。
这个是我说的第一个问题，过度重视单一的指标、单一的 AI 代码贡献率，可能会让你没有找到更好的、全局的优化方法。
Vibe Coding ：感觉快了，可能慢了
聊完指标，我想再聊一下 Vibe coding。
AI 生成代码的速度很快，Vibe Coding 这个词在过去一两年间很火，代表了一种很轻量、很快的开发方式：我有一个想法，就和 AI 聊，生成一版代码，跑一下，如果不对再改，直到结果看起来能用。
但在真实世界里的开发，Coding 只是一部分，企业需要的是长期稳定的、可维护、可运行的系统。我一直认为，软件工程本质是一种平衡的艺术：要满足业务目标，也要控制复杂度；要快，也要稳；既要局部效率，也要关注是不是全局可维护。
就像我前面提到的，AI 生成代码的速度很快，但真实世界里的开发，远远不是把功能写出来这么简单。
接下来，我想给大家分享一下真实的例子。有一个豆包即将上线的功能，是让用户可以在自己的创作页面里创作视频然后做预览和调整。这个需求的复杂难度是中等，不是很快就能写出来的，但也没有难到夸张。
针对这个需求，我们做了一个实验。我们选取 3 个主流 Coding 模型和 3 个主流的 Agent 框架，进行两两组合，用真实的业务需求和相同的 Prompt 分别跑了 100 次，也就是总计 900 次。
最左边绿色这一列，代表着跑出来的结果是不是可用、功能是不是基本正确。只看这一列，我们也看到所有的组合都达到了其实挺让人满意的情况——正确率都超过了 80%。
但当我们关注右边的这几列，比如说 UI 易用性、交互是不是可行、可靠性、可维护性、性能、兼容性等因素时，很有意思的结果就出来了。
我们看到，所有的组合在这个维度上面的得分，相比正确率都出现了非常大的下降。在这些维度上面，模型加上框架表现出来非常强的随机性。比如有的代码异常处理不规范，有的没有复用仓库里已有的组件，有的改动影响了历史功能，有的实现方式不符合团队工程规范。按照真实业务上线的标准来看，这些结果距离真正的上线交付都还有一定距离。这是我们在实际 Vibe Coding 中会面临的问题：如何让 AI 不仅写对功能，更要在真实软件工程实践中做到稳定可交付。
因此，接下来我想谈一谈 Harness。 Harness 是26年非常火热的词汇。但今天讨论到 Harness，我们很多时候会更多把关注点放在 Agent 框架上、工具调用能力上。这些当然重要，但在真实业务实践里，我们越来越发现，真正决定 AI 能不能落地的，往往是更基础、更工程化的问题。
Harness 是在真实业务中跑出来的实践工程。它需要在具体场景里快速验证、发现问题、持续迭代，改进很多基础的东西。我一直把它叫做“基建”，比如这里的上下文工程、架构约束、团队知识的沉淀是不是已经在 Memory 里了，以及对过去技术债的梳理等等。
前面我用三个不同模型和三个主流框架基于相同 Prompt 用 Vibe Coding 进行了展示，当我们把 Harness 的基建结合进去之后，跑出了新的结果。
左下角是原来的 9 种不同情况下的得分，横坐标是正确率，纵坐标是刚才定义的可交付性。在正确率上，任何一个模型加框架都有了一定的提升。正确率从 80% 到了接近 90%。但更显著的是纵坐标，我刚才提到的真实 Coding 场景里遇到的软件工程的各种可交付性，普遍从之前 40 分到 60 分的不及格水平，提升到了 80 分的比较不错的水平。
所以我们不仅要关注 Vibe Coding，也要关注基建、 Harness。你感觉 Vibe Coding 快了，但是如果不把这些做好，实际未必快，甚至会慢。
人人都是程序员，如何协作？
第三个问题，每个人都是程序员，我们该怎样更好协作？
AI 带来的一个很大变化，是代码生产能力被进一步普及，每个人都能把自己的想法变成代码，这也带来了协作关系的变化。
我举一个真实的例子，前段时间，有个产品同学找到我，说她最近有个需求，自己用 Vibe Coding 已经做出来了。页面能看，流程也能跑。但她说：“我拿给研发看，结果研发说，这个需求还是要排期，可能还要几天。”她就有点不理解，为什么不能直接给我代码仓库权限？我自己提交，不就上线了吗？
后来，我们认真看了一下这段代码，发现这段代码虽然能跑，但存在很多问题。性能不够好，扩展性也没考虑，也有权限安全问题。
这个例子很能说明我们今天遇到的新问题。AI 让产品、设计、运营各种角色都有机会把想法直接变成代码，这个变化非常有价值，因为沟通更直接、验证也更快。所以肯定不能说，“除了工程师，其他角色写的代码都不能用”。但另一方面，代码生成门槛下降，不代表系统复杂度下降。真实业务系统里，代码要放进既有架构里，要和已有模块配合，要考虑各种各样的问题，所以也不能“谁写出来谁就直接上线”。
我觉得真正面临的挑战，是怎么让不同的角色，更多的人，可以更合理、更有效地参与到代码生产这个过程里面来，每一个人都可以发挥价值。但这些产出要进入统一的架构、规范和交付流程，最终把整体效率提升。
关注三件事：指标、治理、协作
这些都是真实世界里的挑战。所以我们后来对 AI Coding 的关注，其实也发生一些变化，更加关注这三个问题。
第一，找到更合理的指标，衡量 AI 是否真的全局提升了交付效率和生产力。
第二，是治理，用更合理、更稳定的方式，让 Vibe Coding 走向真正的软件工程。
第三，围绕 AI Coding，让软件开发（881272）的各种上下游角色更好地合作提升效率。
不只是字节，相信行业里的大多数公司也都在面临类似的问题。我们内部也有各种各样的探索和尝试，接下来，我也想围绕这几个方向，分享我们真实的实践和尝试。
我们的 AI Coding 探索经验
原型驱动的开发模式
过去我们习惯用文档驱动研发。产品先写产品需求文档（PRD），设计再画图，研发再写技术方案，然后变成真实的代码再上线。但真实情况往往是，问题在文档里读起来都合理，真做出来了发现分歧还是很大。
AI 带来的变化是，其中制作产品原型的成本大幅降低了，我们现在做出来的原型可以把静态的东西变成动态的，它是一个真实的、可交互的东西，是和真实场景高度拟合的。然后我们围绕着这个动态的东西去讨论、体验。
现在 TRAE 的开发流程中，就在应用这套方法。前几天，我说我们的“问题反馈”这个功能做得不好，想要实现一个前端的 “feedback” 功能，用户可以通过 /feedback 命令向 TRAE 提交用户反馈。
我今天在这里演示一下：
有了原型开发之后，可以大幅提高其他一些地方的生产效率。去年我在这个现场分享了我自己做的小应用，当时是找了一个前端同学和我一起做，我印象中他花了 60% 的时间做图的还原。有了 AI coding 之后，未来也许设计师就可以直接出高保真的还原图，直接就有代码了，省下大量的时间。
原型只是第一步。要真正进入企业研发，还需要把这些共识继续沉淀成一些可复现、可验证、可维护的工程流程。我将其称为“系统化的 AI Development”。
系统化 AI Development
这句话通俗来说是什么意思呢？就是 AI 不止可以写代码，应该进入各个流程里面去。过去如果你想让一个系统很好地运转，齿轮是要能够耦合到一起的，是要能够嵌合的。但是我们在实践过程中，经常遇到的问题是：Coding 部分是用 AI 做，但后面大量工作还是传统的方式和传统的流程，人在大量地介入，传统的系统在大量发挥作用。
我们内部在这方面有一些探索。这个视频介绍了我们是怎么让 AI 参与到各个流程里面去的，让它在全流程里面发挥作用。
可以看到，AI 根据我们的功能需求，基于当前的 Context，开始编写 Spec，当然功能实现完毕以后，AI 通过“Browser Use”的能力自动打开浏览器验证功能正确性并自动进行 Bugfix，当确认功能实现正确后，AI 自动提交，帮我们线上发布。
组织化建设
早期 AI Coding 往往依赖少数高水平个体。有些工程师很会写 Prompt，很懂系统上下文管理，也知道怎么拆解任务、如何验证结果，所以他们可以获得很高的效率提升。
但对组织来说，我们不仅关注个体，重要的是提升团队整体的能力，包括如何让组织内部的 AI Coding 实践沉淀下来，变成内部的标准、工具、技能。这也是我们一直想做的事情。
比如上面提到的原型驱动开发和系统化的 AI Development ，我们也在内部尝试文档化以及产品化。实际上，我们的很多能力都直接沉淀到了 TRAE 里，开放给所有工程师一起使用、共创。过去一年 TRAE 的增长也非常不错，我们的 Token 日均消耗量达到了 5.6 万亿，相比去年增长了 50 倍。
同时，我们也看到了 TRAE 的用户人群逐渐泛化，越来越多的非技术背景的用户使用 TRAE 来完成日常的工作。为了更好地满足这些用户场景，我们近期推出了 TRAE Work 。我们会和火山引擎一起将 TRAE Work 的能力集成到 TRAE 的企业版之中。为了想把它用好，我们需要真实地走进企业里面去，认真的听取企业的问题反馈，一起去改进。
AI Coding 和 AI Working 还是一个很早期的命题，我们也希望和大家一起探索如何把 AI 用好，让所有的团队都实现真正的生产力提升。
