字节这次 FORCE 大会里最有信息量的，不是 TRAE Work 这个产品名，而是一组真实内部数据：TRAE 团队 90% 以上代码由 AI 生成，但人均需求吞吐率只提升约 60%。

这不是 AI coding 失败。60% 的吞吐提升放在任何成熟工程团队里都很高。

真正暴露出来的是另一个问题：代码生成已经变得很便宜，但把代码变成可上线软件的流水线还没跟上。

这和 DevOps 当年的处境很像。

敏捷让代码变更频率上去以后，旧的集成、测试、部署流程先被打爆。DevOps 和 CI/CD 不是装饰，而是为了让高频变更能稳定进入生产。

今天 AI coding 里变快的是更上游的代码生成。Token 可以放大代码供给，但 review、测试、依赖检查、staging、架构约束、安全审计不会自动变便宜。

所以 harness 的角色越来越像 AI 代码时代的 CI/CD。

团队接下来不该只看 AI 代码占比。更该看 request-to-merge / deploy cycle time、首轮测试通过率、review 负担、回滚率、AI 代码存活率。

我把这组数据和 DevOps 的历史拐点放在一起写了一篇：

https://yage.ai/share/trae-ai-coding-devops-moment-20260627.html?utm_source=twitter&utm_medium=social&utm_campaign=trae_ai_coding_devops_moment_20260627…

AI 编程正在进入它的 DevOps 时刻

Source: https://yage.ai/share/trae-ai-coding-devops-moment-20260627.html?utm_source=twitter&utm_medium=social&utm_campaign=trae_ai_coding_devops_moment_20260627 ← 目录ENDeep NewsSuperlinear AcademyAI 编程开发工具中国科技生态

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 编程真正变成可持续的工程效率。