AI 写了 90% 的代码之后，企业才真正开始补课

作者 / 来源中智凯灵 / 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 DrivenAI 写代码越快需求越要结构化·知识库、Skills 与组织资产AI 能力如何从一次性使用变成持续复利这么好的内容你不转一下吗转发本篇文章至朋友圈截图私信后台可免费领取AiDD上海站演讲PPT下载链接下一站生产级 Agent 的故事上海站只是开篇。当企业从“试一试智能体”进入“把智能体放进真实业务”更需要讨论的就不只是模型和工具而是评估、可观测、权限、运营和组织级交付能力。2026年 AiDD 北京站将继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。FDE 深度工作坊也会把这些问题带到更具体的实操场景里如何识别真实场景如何设计 PoC如何搭建知识库和智能体如何建立评估与反馈闭环并把 AI 项目推向真实使用。北京我们继续聊。