作者 / 来源：中智凯灵 / AiDD

——从字节的 AI Coding 实践看，研发提效的下一站不是“更多代码”，而是交付系统重构

6 月 23 日，火山引擎 Force 原动力大会上，字节跳动技术副总裁洪定坤分享了一组很有冲击力的数据：

过去一年，字节跳动的 AI 代码贡献率增长了 6 倍多，AI Coding 上的 Token 消耗增长了 5 倍，AI 代码合入率增长超过 2 倍。

如果只看这些数字，很多人会自然得出一个结论：AI Coding 已经进入企业研发的主战场。

但真正值得注意的，不是这些增长本身，而是字节在增长之后看到的反常识问题。

图 1：洪定坤《AI Coding 的实践与探索》：火山引擎 Force 原动力大会现场演讲画面

TRAE 团队本身就在做 AI Coding 工具，也非常激进地使用 AI Coding。过去半年，团队里超过 90% 的代码由 AI 写出，但人均需求吞吐率只提升了 60%。

90% 的代码由 AI 生成，效率却只提升到 1.6 倍。

这个差距，可能正是企业 AI Coding 从“工具尝鲜”走向“组织能力”时，必须面对的第一道坎。

图 2：洪定坤《AI Coding 的实践与探索》：TRAE 团队 AI 代码贡献率与人均需求吞吐率对比

▍AI 代码贡献率，不该成为唯一 KPI

过去一年，很多团队衡量 AI Coding 的方式都很直观：AI 写了多少代码、采纳了多少代码、代码贡献率有多高。

这些指标当然有用。它们能说明一个团队是否真的开始使用 AI，也能反映工具是否进入日常研发流程。

但问题在于，如果企业只盯着“AI 写了多少代码”，很容易把研发提效误解成代码生成量的竞赛。

代码生成得越多，不代表需求交付越快；AI 采纳率越高，也不代表系统质量越好。

一个真实需求从提出到上线，中间经过的环节远不止写代码：需求澄清、方案设计、架构约束、代码复用、测试验证、安全合规、上线发布、线上观察，每一步都会影响最终效率。

AI 把“写代码”这一步压缩了，但如果需求仍然反复变更，测试仍然靠人补，代码仍然难以进入既有架构，发布仍然需要大量人工兜底，整体效率就不会线性提升。

所以，AI Coding 的第一个管理误区，是把“代码贡献率”当成了“生产力提升率”。

真正应该被衡量的，不只是 AI 写了多少代码，而是需求吞吐率有没有提高，返工有没有减少，缺陷有没有下降，交付周期有没有缩短，跨角色协作成本有没有降低。

企业要的不是更多代码，而是更稳定、更快、更可控的交付。

▍功能正确，不等于工程可用

Vibe Coding 让很多人第一次感受到“自然语言写软件”的速度。

有想法，告诉 AI；生成一版，跑起来；哪里不对，再继续改。对于个人项目、临时工具、原型验证，这种方式非常有效。

但一旦进入企业生产环境，问题就出现了。

字节在演讲中提到一个实验：针对一个真实的中等复杂度需求，选取 3 个主流 Coding 模型和 3 个主流 Agent 框架，两两组合，用同样的 Prompt 跑 100 次，总计 900 次。

只看“功能是否基本正确”，所有组合都超过 80%。这说明今天的 AI Coding 模型，已经具备相当不错的功能实现能力。

但如果继续看 UI 易用性、可靠性、可维护性、性能、兼容性等工程指标，结果就明显下降。有的代码没有复用仓库已有组件，有的异常处理不规范，有的改动影响历史功能，有的实现方式不符合团队工程规范。

换句话说，AI 能把功能写出来，但不一定能把软件交付出来。

图 3：洪定坤《AI Coding 的实践与探索》：Vibe Coding 实验中“功能正确”与工程可用指标的差异

这正是很多企业在 AI Coding 落地中最容易忽视的地方：Demo 能跑，不等于系统能上线；页面能看，不等于业务能用；功能正确，不等于工程可用。

过去，软件工程里的很多“慢”，其实是在为长期可维护性付费。架构规范、测试体系、异常处理、安全边界、权限控制、性能优化，这些东西不会在第一眼演示时显得惊艳，却决定系统能不能长期运行。

AI Coding 的价值，不应该停在“更快写出一段代码”。真正的价值，是让 AI 在工程约束中完成任务。

▍Harness 不是框架，而是企业 AI 研发基建

这也是为什么字节在演讲中重点提到了 Harness。

今天很多人讨论 Harness，会自然想到 Agent 框架、工具调用、多 Agent 协作。但在真实业务里，Harness 不只是一个框架选择问题。

它更像一套企业 AI 研发基建。

这里面包括上下文工程、架构约束、团队知识沉淀、历史技术债梳理、组件规范、测试验证、权限控制、质量标准和交付流程。

没有这些基建，AI 就像一个很聪明但不了解现场的临时外援。它能写代码，但不知道团队过去为什么这样设计；它能实现功能，但不知道哪些组件必须复用；它能生成方案，但不知道哪些边界不能越过。

一旦把这些上下文、规范和验证机制补上，AI Coding 的表现就会完全不同。

字节的实验也说明了这一点：在引入 Harness 基建后，功能正确率从 80% 左右提升到接近 90%，更关键的是，可交付性从原来的 40 到 60 分，普遍提升到 80 分左右。

图 4：洪定坤《AI Coding 的实践与探索》：引入 Harness 基建后，可交付性明显提升

这说明 AI Coding 的真正分水岭，不是“用了哪个模型”，也不只是“选了哪个 Agent 框架”，而是企业有没有把自己的工程知识、业务上下文和交付标准沉淀成 AI 可以理解、可以调用、可以遵守的系统。

模型能力会越来越普惠，但企业自己的上下文不会自动生成。

谁能更早把组织知识变成 AI 可用的工程资产，谁就更容易把 AI Coding 从个人技巧变成组织能力。

▍人人都能写代码之后，协作规则要重建

AI Coding 带来的另一个变化，是代码生产能力开始从工程师扩散到产品、设计、运营、市场，甚至更多业务角色。

这当然是好事。

过去，一个想法要变成可交互原型，需要经过文档、设计、研发排期、前端还原等一长串流程。现在，一个产品同学可能自己就能用 AI 做出页面和流程。沟通成本会降低，想法验证会加快，更多角色也能直接参与产品创造。

但代码生产门槛降低，不代表系统复杂度降低。

产品同学用 AI 做出来的代码能跑，不代表它可以直接进入生产仓库；设计师生成的前端代码看起来还原，不代表它符合组件规范；运营做出的小工具能用，不代表它满足权限、安全和稳定性要求。

这里的挑战不是“非工程师能不能写代码”，而是“不同角色生成的代码如何进入统一交付流程”。

未来的企业研发组织，可能会出现一种新的分工：

更多人负责提出问题、构造原型、验证想法；工程师则从单纯的 Code Writer，转向 Reviewer、Architect 和 Problem Solver。

工程师的价值不会消失，但会从“亲手写每一行代码”，转向“定义约束、设计系统、把关质量、治理复杂度”。

这要求企业重新定义协作规则：谁可以生成代码，谁可以提交代码，谁负责验证，谁对线上结果负责，什么样的产出可以进入主干，什么样的产出只能停留在原型阶段。

AI 让代码生产变得更开放，但企业交付仍然需要秩序。

▍AI Coding 的下一站，是系统化 AI Development

字节在演讲中提到一个方向：系统化 AI Development。

这句话很关键。

因为 AI Coding 如果只停留在“写代码”，它解决的只是研发链条上的局部问题。真正的企业级提效，是让 AI 进入从需求到上线的完整流程。

比如，AI 可以基于当前上下文编写 Spec，可以根据功能需求生成实现方案，可以自动打开浏览器验证功能，可以自动修复 Bug，可以辅助提交和发布。

这时，AI 不再只是一个“代码生成器”，而开始成为研发流程中的协作节点。

再往后，AI 还会从 Coding 延伸到 Work。它不只服务工程师，也服务产品、设计、运营、市场和企业里的更多知识工作者。

这也是为什么 AI Coding 的讨论，最终一定会走向组织问题。

个体用了 AI，可能会很快；但组织要真正变快，需要流程、工具、知识、规范、权限和评估一起变化。

否则，AI 写代码越快，团队可能越忙于 review、返工、修 Bug 和处理技术债。

▍结语：企业要补的课，不是 AI 工具课

字节这次分享真正有价值的地方，不在于告诉大家“AI Coding 很强”，而在于把一个更真实的问题摆了出来：

当 AI 已经能写出大部分代码之后，企业研发到底还缺什么？

答案不是再多买一个工具，也不是再追一个更高的代码贡献率。

企业真正要补的课，是交付系统。

要重新设计指标，避免把 AI 代码量误当成生产力；要补齐 Harness，让 AI 在真实工程约束中工作；要重建协作规则，让更多角色参与创造，同时让产出进入统一治理；要把个人经验沉淀为组织资产，让 AI 不只是某些高手的外挂，而是整个团队可以复用的能力。

AI Coding 的上半场，是个人提效。

下半场，是组织重构。

而这也正是 AiDD 一直关注的问题：AI 进入企业之后，真正改变的从来不只是工具，而是研发方式、交付机制和组织能力。

如果说过去一年，企业还在问“AI 会不会写代码”，那么接下来更重要的问题会变成：

当 AI 已经会写代码，我们的组织准备好接住它了吗？

相关文章
·Agent 从 Demo 到生产级，中间到底差什么？
·FDE 不是驻场开发：AI 时代的新型工程角色到底新在哪里？
·别再只看写了多少代码：AI 研发提效到底该怎么量？
·为什么FDE成了今年最火的岗位：Palantir 给企业 AI 的启示
·AI赋能研发组织提效的效果度量：从“个人效率”走向“组织交付”的新标尺
·从跑分到护栏：AI Agent 规模化落地，为什么必须先补上质量底座？
·从 AI Coding 到 Agentic Engineering：研发提效正在进入第二阶段
·为什么企业需要 Spec Driven：AI 写代码越快，需求越要结构化
·知识库、Skills 与组织资产：AI 能力如何从一次性使用变成持续复利






下一站



生产级 Agent 的故事，上海站只是开篇。
当企业从“试一试智能体”进入“把智能体放进真实业务”，更需要讨论的就不只是模型和工具，而是评估、可观测、权限、运营和组织级交付能力。
2026 年 AiDD 北京站，将继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。FDE 深度工作坊也会把这些问题带到更具体的实操场景里：如何识别真实场景，如何设计 PoC，如何搭建知识库和智能体，如何建立评估与反馈闭环，并把 AI 项目推向真实使用。
北京，我们继续聊。
点这里↓↓↓记得关注标星哦~