2026 年 6 月 23 日到 24 日，火山引擎开了 FORCE 大会。往年这种行业大会，大家聊得最多的是多模态、大模型调用量和 MaaS 生意，但这次火山把大量篇幅给了 AI 编程。经济观察报在报道里用了一个很贴切的标题：字节正在补上 AI 编程的短板。
会上发布了豆包 2.1 Pro，重点提升编程和 agent 能力。原来的 TRAE SOLO 也升级成了 TRAE Work，分为 Work 和 Code 两个模式，一个面向日常办公，一个面向代码开发。
不过，对开发者和工程管理者来说，这次大会真正有信息量的不是产品名变化，而是字节公开的内部研发数据。
字节跳动技术副总裁、TRAE 业务负责人洪定坤分享说，过去一年，字节内部 AI 产出的代码占比翻了 6 倍，其中 TRAE 团队超过了 90%。TRAE 的日均 Token 消耗达到 5.6 万亿，是一年前的 50 倍。火山引擎总裁谭待也给了更大的背景：截至今年 6 月，豆包大模型日均 Token 调用量已经超过 180 万亿。中国企业家的报道记录了这组数据，并提到火山在国内 MaaS 市场拿到了接近一半的份额。
这里出现了一个反差：AI 写代码的速度已经是人的 10 倍以上，TRAE 团队超过 90% 的代码来自 AI，那么团队的研发效率是不是也接近翻了几倍？
答案是没有。洪定坤给出的数字是：人均需求吞吐率提升大约 60%。
这组数据之所以有价值，是因为它同时给出了输入端和输出端。输入端是 AI 写了多少代码，输出端是团队最终交付了多少需求。两端都量出来以后，中间的折损就暴露出来了：代码生成量涨得非常快，真实交付没有按同样比例增长。
洪定坤在会上举了几个具体问题。工程师可能只是想改一个参数，AI 却把一大段相关逻辑复制出来重写，留下冗余代码。AI 能很快生成一段代码，但要把它放回现有架构里，做接口对齐、集成、测试，中间还有很长的距离。还有一个更典型的组织问题：字节内部有产品经理用 AI 做出了功能完整的页面，希望直接上线，但研发团队拦了下来，因为这套代码在扩展性、安全性和性能上都需要重构。
这些问题指向同一个瓶颈：AI 让代码生成变便宜了，但把代码变成可上线软件的后续流程，成本还没有同步下降。
Remio 在报道里转述了另一组实验数据。按它的说法，字节做了 900 多次测试，主流模型的代码正确率能超过 80%，但在没有周边工具辅助时，代码的可交付程度只有 40 到 60 分。加上 harness，也就是测试、依赖检查、staging 这类验证和支撑工具后，可交付程度能升到 80 分左右。这组数字目前主要来自媒体转述，我们还没看到官方白皮书或完整演讲稿，所以写作时需要谨慎归因。但它和 90% 代码占比只带来 60% 吞吐提升这件事，是同一个方向的信号。
这次 FORCE 大会真正露出来的问题，不是字节是否做 AI 编程工具，也不是 TRAE Work 怎么定位。它更像一次大规模实践后的压力测试：AI 时代，写代码这个环节正在变得非常快，但软件工程的瓶颈正在移到后面。
人均需求吞吐率提升 60%，放在任何成熟研发团队里都是相当高的收益。所以这组数据不能被读成 AI 编程失败。它真正说明的是另一件事：代码生成速度和软件交付速度之间出现了明显脱节。
可以把 AI 写好的代码想象成工厂里的半成品。当 AI 像流水线一样不断吐出代码时，review、编译、跑测试、管理依赖、部署 staging 环境、安全审计这些下游环节并不会自动加速。新代码在这些卡点前排队，就变成了库存。它已经被生产出来了，但还不能算交付。
软件工程历史上出现过一次类似的瓶颈转移。
2010 年前后，敏捷开发开始普及，团队写代码和提交变更的频率从几个月一次，缩短到几周、几天，甚至更短。但当时很多团队把代码合入主干、测试、部署到服务器，仍然靠手工编译、人工跑测试、发邮件申请运维排期。开发把变更写完了，集成和部署却成了噩梦。这个模式在安全领域也反复出现：真正出问题的往往不是代码片段本身，而是部署、权限和环境边界。之前分析 vibe coding 泄露案例时也看到过同样的结构，问题不在代码能不能跑，而在部署层有没有把风险拦住。
DevOps 不是因为大家突然喜欢 CI/CD 或 YAML。它是被高频变更逼出来的。当部署频率上去以后，旧的交付流程跑不通，行业只能把测试、集成和发布这些环节自动化。CI/CD 流水线的意义，是让高频变更能稳定、安全地进入生产环境。
今天的 AI 编程处在类似的位置。只是这一次，突然变快的不是部署，而是更上游的代码生成。Token 成本下降，模型能力提升，代码生成变成了低成本供给。但下游的 review、测试、依赖管理、staging、架构约束和安全审计，没有自动变便宜。
这就解释了为什么 90% 的 AI 代码占比只能转化为 60% 的吞吐提升。代码生成虽然快了，但团队还没有一条能匹配这种速度的交付流水线。harness 在这里的角色，和当年的 CI/CD 很像：自动跑测试、检查依赖、做架构约束、拉起 staging，把高频生成的代码送过一套可重复的验证流程。
换句话说，harness 是 AI 代码时代的 CI/CD。
过去讨论 harness engineering，我们常看几个维度：单个 agent 能跑多久，多个 agent 怎么并行，人和 agent 怎么交互。火山这组数据补了另一个维度：团队对 AI 代码的吸收带宽。
Token 可以花钱买，AI 生成代码的吞吐量可以靠算力放大。但团队吸收这些代码的能力，不会自动翻倍。产品经理用 AI 写完页面，工程师仍然要检查网络请求怎么发、组件能不能复用、有没有越权风险、性能会不会拖垮页面。AI 放大了代码生产力，但 review、架构治理和集成验证仍然紧缺。
字节提到的上下文工程、架构约束和知识沉淀，本质上是在拓宽这条吸收流水线。
先看上下文工程。如果 AI 每次接任务都要重新读代码库，重新猜团队的历史包袱、命名习惯和架构偏好，那 Token 会花在重复理解上，而不是推进需求。把代码结构、技术决策和历史约定整理成 AI 能直接读取的上下文，AI 写出的代码才更容易贴合现有项目。这和之前写 team context infrastructure 时的判断一致：模型能力跨过门槛以后，真正拉开差距的往往是它能不能拿到高密度、可复用的上下文。
再看架构约束。让 AI 放开写，很容易让代码库的熵上升。团队需要在流水线里加入规则，提前拦截不符合分层、依赖方向或安全边界的代码，避免垃圾代码混进主干。这里的安全边界不是抽象担忧。AI 编程工具会读取项目配置、规则文件和代码注释，之前梳理过一轮 AI 编程配置文件注入，核心问题就是同一个仓库里哪些内容被当成数据，哪些内容会变成 agent 的指令。
最后是知识沉淀。一个 agent 在 A 模块里踩过的坑，应该能被另一个处理 B 模块的 agent 复用。如果这种经验还要靠人开会、写长文档、口头传达，知识流动速度就会落后于代码生成速度。
这些东西靠模型变强无法自动解决。再聪明的模型，也不知道你们五年前为什么保留了一个奇怪接口，也不知道你们内部对权限控制有什么特殊要求。这些信息必须由团队自己沉淀到代码库和工程环境里。
如果这个判断成立，下一阶段 AI 编程工具的竞争重点会从“谁更会写代码”，转向“谁能把 AI 写出的代码稳定送过交付流水线”。
工程管理者评估 AI 编程工具时，也不能只看 AI 代码占比。这个指标只看供给端，就像只看工厂生产零件的速度，却不看质检站和仓库堵成什么样。Anthropic 对 Claude Code 真实使用数据的分析也指向同一个变化：用户正在从“让 AI 修一个 bug”，转向“让 AI 跑完一整件事”，这意味着衡量口径也要从代码片段转向完整工作块的交付。
更该看的，是这些更贴近交付的指标：一个需求从开始写到合入或部署用了多久，AI 生成代码第一次跑测试能通过多少比例，资深工程师每天花多少时间 review AI 提交的变更，上线后回滚和故障率有没有变化，AI 生成的代码过一段时间后有多少留了下来。
这些指标衡量的是最终交付效率，而不是生成端的账面数字。
这次 FORCE 大会的数据给行业提了一个醒：AI 写代码的产能红利已经开始兑现。TRAE 团队 90% 的代码贡献率、每天数万亿 Token 的消耗，都说明 AI 写代码已经不是最难的环节。
接下来的问题，是怎样缩小代码生成和代码交付之间的折损。这件事不能只等大模型升级。它需要团队像当年搭 DevOps 流水线一样，把测试、review、依赖检查、staging、架构约束和上下文基础设施补齐。谁先把这条 AI 代码的交付流水线跑通，谁才能把 AI 编程真正变成可持续的工程效率。