每个人都快了，交付却没快，如何破局？
本文来源： 朱少民（公众号：朱少民）
原文链接： https://mp.weixin.qq.com/s/1qskM-o28yV03uf2bLqTRg
发布时间： 2026-08-26 07:50
作者： 朱少民 发布时间： 2026-08-26 07:50
先看三组放在一起非常刺眼的数字：
腾讯披露，九成员工使用编程助手后，编码时间缩短 40%，整体研发效率只提升约 20%；
字节跳动 TRAE 内部报告显示，其代码超90%由AI生成，AI写码速度至少是人工的10倍，但人均需求交付并未同比提升；
还有团队统计，个人用AI提效10倍，公司却颗粒无收。
个人越来越快，组织纹丝不动——这不是哪个团队的运气问题，而是2026年整个行业的"效率悖论"。字节跳动TRAE研发团队技术专家张皓洋在第10届AiDD北京峰会上的演讲，用一句话戳破了这层窗户纸：
"编码速度可以提升很多倍，组织吞吐却不会等比例提升。需求澄清、方案评审、上下文交接、测试验证和发布协同，只要还有一个环节没有被重构，局部速度就会被等待、沟通和返工重新吸收。"
（来源：字节跳动TRAE研发团队技术专家张皓洋《从Coding到Engineering：AI如何参与TRAE的真实研发流程》，可以去：https://www.aidd.vip/dhrc-bj2026 下载）
这篇文章，我们沿着这两条线索往下走：先看看这道鸿沟长什么样、从哪来，然后登上五级台阶——每一级都来自TRAE在真实研发流程里的落地实践。读完这篇文章，你会得到一个答案：从"我更快了"到"我们更稳了"，中间差的是五级台阶，而不是一个更强的模型。
一、效率幻觉：每个人都快了，交付却没快
先做一个思想实验。假设你给团队每个人配了顶配 AI 助手，一个原本写五天的模块，两天就"生成"完了。作为管理者，你会期待什么？——剩下三天，团队再产出 60% 的增量？
现实通常是骨感的：省下来的时间没有变成增量产出，而是蒸发在排队、等待和返工里。更讽刺的是，AI还顺带抬高了老板的预期——"既然AI能提效，这需求一周就该上线。"结果编码这一段确实快了，整体节奏不仅没跟上，人反而更累了。
1.1 两道真实的鸿沟
快手研发效能团队把这道鸿沟拆成了两层，非常清晰：
| 鸿沟 | 所在层级 | 典型症状 |
|---|---|---|
| 第一道：个人 → 团队 | 协作接口没提速 | 你代码写完了，代码评审还在排队；测试环境还得等；联调对象还在开会 |
| 第二道：团队 → 组织 | 价值链瓶颈没重构 | 团队交付快了，但需求供给跟不上、压测不动、发布窗口卡死，交付周期照样原地踏步 |
这就是为什么"编码提速 10 倍"听上去震撼，落到组织指标上常常只剩 15%～25%。你只提速了流水线上的一台机器，其他工位纹丝不动，整条线自然还是老速度。
1.2 一条链的解释：为什么"只快一段"等于"白快"
字节张皓洋的解释很精炼。一次交付 = 一条链：
需求澄清 → 方案评审 → 上下文交接 → 编码实现 → 测试验证 → 发布协同 → 反馈迭代
"只要还有一个环节没有被重构，局部速度就会被等待、沟通和返工重新吸收。"翻译成大白话：你把代码生成修成了高速公路，可前面的需求、后面的评审测试还是乡间小道——结果不是整体变快，而是在每个接口处排起更长的队。
我之前反复强调，希望从更本质的层面点破这件事：软件开发是"介于精确的规则性要求与AIGC内容生成两者之间的一个工程级问题"——AI拼尽全力提升的，只是其中"生成"这一段；而规则、设计、约束、验证这些工程性的部分，才是组织吞吐的真正大头。把"生成"提得再快，也撬不动"工程"的底盘。
1.3 还有一种快，是"借来的"
更隐蔽的问题是：有些快，是把代价往后挪了。AI生成的代码可能不符合架构风格、可能重复造了轮子——眼前是快了，后面却留下"维护税"。例如，AI 会给你一个"看似完成"的结果——需求不清它也会补全，方案没理解透它也会开始写代码，上下文缺失它自己猜，标准模糊它交一个表面过关的东西。
智能体的自主时长正以惊人的速度拉长——去年只能自主工作几分钟，六个月前能完成部分端到端任务，今天已经能连续工作数小时。单点能力越来越长、越来越强，可一旦脱离组织的流程和验证，拉长的只是"失控的长度"，不是"交付的广度"。
快，但不可信；完成，但不可验证。 这是鸿沟的深层问题。
二、追根溯源：三个"组织级缺陷"
鸿沟普遍存在，不是因为工具不够强，而是组织有三个结构性缺陷。
缺陷一：能力锁在"人"身上，而不是挂在"场景"上
观察一下大多数团队的AI使用方式：每个工程师都有自己的prompt库、自己的skill 组合、自己的验证习惯、自己的"完成标准"。Agent A一套skill，Agent B另起炉灶，Agent C又一套。
张皓洋称之为"超级个体问题"：研发能力散落在个人经验里，锁在某个高手身上——同一类任务，换个人、换个agent，质量就换一副面孔；执行不可复现、不可审计；能力无法沉淀为组织资产。
（来源：字节张皓洋的《从Coding到Engineering：AI如何参与TRAE的真实研发流程》）
这解释了许多企业观察到的怪象：一家 800人的团队写了几百上千个Skill，日常真正被广泛使用的只有几十个。为什么？因为 Skill绑在人身上，而不是绑在场景和流程上。个人英雄再多，也组不成一支军队。
缺陷二：上下文断在"交接"处
张皓洋在演讲里反复强调一个隐性变量：上下文质量。演讲中那句"需求不清，它也会补全；方案没透，它也会开写；上下文缺失，它会自己猜"，指的正是五个前置条件能不能立住，全看喂给 AI 的上下文靠不靠谱。
（来源：字节张皓洋的《从Coding到Engineering：AI如何参与TRAE的真实研发流程》）
而组织层面，上下文损耗更严重。网易智企用一句话点破这种"分裂"：你的 AI 助手越来越懂你，同事的AI也在按他的上下文工作；等到决策会上，A 的AI说往东，B 的AI说往西——每个人都在自己的小黑屋里把AI调教得越来越懂"我"，放到组织桌上，却制造了更多噪音与分歧。
有工程团队把这四个"协作病"总结得极其到位：意图失真、状态不同步、验证不可扩展、注意力瓶颈——而且它们会互相叠加、恶性循环。个人越强，组织越分裂，不是错觉，是机制。
缺陷三：验证停在"人眼扫过"
多数团队对 AI 产物的验证是"人扫一眼"。但人眼有两个致命问题：看得不深，且标准因人而异。更危险的是，如果验证由执行者自己做，就会出现"为了让测试通过而改测试"的作弊式闭环。
（来源：字节张皓洋的《从Coding到Engineering：AI如何参与TRAE的真实研发流程》）
我在《软件工程3.0》的论述中反复强调验证的分量——"人机结对编程与测试将成为标准作业模式"，生成代码和测试用例是大势所趋，效率提升也是显著的。但前提是：验证体系得先立起来。否则"人机结对"就会变成"人跟不上AI，人成为瓶颈"，而不是质量与效能的革命性飞跃。
从面向Agent的AI研发流程设计来看：干活的和验收的，不能是同一个。
三、从 Coding 到 Engineering 的跃迁路线图
张皓洋演讲的标题本身就是答案：
"从 Coding 到 Engineering，不是给代码生成再增加几个功能，而是把需求、设计、实现、验证、发布和反馈重新组织成一条可持续推进的工作链。AI 的价值也随之发生变化：它不再只替人完成某个动作，而是开始参与一整套交付关系。"
提效的对象，从"动作"变成了"交付关系"。沿着这个思路，TRAE 在实践中搭出了五级台阶——恰好构成"个人提效 → 组织提效"的完整阶梯。先给你一张总览地图：
| |
| |
第一级：把"一次生成"变成"一次交付"
起点是稳定单点交付。张皓洋提出，稳定交付来自五个前置条件，每个条件对应一个解法：
| |
| |
一句话：从"一句 prompt 直接开写"升级为"先想清楚再动手"。复杂变更被切成小步，产出变成"目标·方案·约束·验收标准 + 可执行步骤 + 验证证据"。但请注意张皓洋的提醒——五步串起来，单点交付才走向稳定，"但这还只是'单点'"。它是地基，不是终点。
第二级：把"个人能力"变成"组织契约"
这一级是最关键的一跃，也是"我快"变"我们快"的分水岭。做法就一条：能力绑定到"研发场景"，而不是绑定到某个 agent 或个人。
（来源：字节张皓洋的《从Coding到Engineering：AI如何参与TRAE的真实研发流程》）
| 绑定到 agent（现状） | 绑定到研发场景（目标） | |
|---|---|---|
| 能力来源 | 散落在 prompt/个人经验里 | skill/验证/门禁直接挂在场景类型上（组织级契约） |
| 完成标准 | 全靠自觉 | 类型强制，创建即冻结、不再变 |
| 执行结果 | 同一产物，换人换个质量 | 同一门禁，换任意 agent 执行，研发能力不变 |
| 组织视角 | 能力锁在超级个体身上，不可复现、不可审计 | 能力成为组织资产，可复现、可审计 |
落地机制包括：类型可自定义（TRAE 实践里的 Investigation/Remediation 等）；必须有通过的验证或人工 override 才允许标记完成；契约以只读快照形式存在，防止"各改各的"。
用一个比喻理解：个人skill是梅西的球技，场景契约是球队的战术板——球技再神，没有战术板，换个人上场球队就散；战术板写清楚，谁上场都按同一套跑位踢。组织的"稳定"，本质上是把个人的最佳实践契约化、冻结化、可审计化。
第三级：把"对话上下文"变成"组织记忆"
解决了"能力归谁"，还要解决"上下文归谁"。TRAE 在流程里落地了两套机制：
一是 Artifact（产物）的血缘沉淀。流程里每个节点的产出——需求文档、设计文档、spec——被当作只读输入自动交接给下游，且带 sha256 哈希固定成快照。下游用的永远是"交接那一刻的那一版"，上游后来怎么改，都不影响已经交接出去的契约。这就像寄快递时的签收单：签收那一刻的版本被固化，谁也不能事后偷换。
二是 Memory（结构化长期记忆）的编码与召回。概念、命题、对话被结构化成可检索、可引用的记忆库（TRAE 实践里已有 815个concepts、2008条propositions、343 段对话被沉淀）。AI 开工前先"问一下这个项目的记忆"，而不是每次从零开始猜。
（来源：字节张皓洋的《从Coding到Engineering：AI如何参与TRAE的真实研发流程》）
这两套合起来，回答了一个组织级难题：上下文在人与人、人与 AI、任务与任务之间交接时，如何不损耗。个人的对话记录，变成组织的可检索资产；一次踩过的坑，变成下一次开工前的默认背景。
第四级：把"一次执行"变成"研发流程"
单点稳定了、能力沉淀了、上下文接续了，接下来把它们串成流程闭环。张皓洋的两个工程细节非常见功力：
历史只前进，不后退。返工不是回滚重来，而是"派生一个新节点接着往前走"，被取代的旧下游在投影层标记为 stale，执行面的状态一动不动。这保证了流程历史永远可追溯、可审计——所有"改主意"都有痕迹，而不是抹掉重来。项目里真实发生过"重新设计后端"、"Waive stage-3"这样的分支修正，全部留痕在案。
用平台迭代平台自己（Dogfooding）。TRAE 团队直接用自己的 pilot流程平台来打磨 pilot流程本身——调研平台现状、产出优化方案、实施、验证，全走自己搭的那套流程。平台好不好用，先让自己疼一遍。这是对流程机制"可信度"最硬核的检验：你自己都不敢吃自己做的饭，凭什么让团队吃？
第五级：把"完成"变成"证据"，让人有据可放行
流程跑起来了，最后一道闸门是验证与人类放行。核心设计是两个词：交叉验证 + 可审查证据链：
- 执行 AgentRun与验收 AgentRun分离：干活的负责实现，不负责给自己判过；验收的是独立角色，按节点事先定好的验收标准单独判一次：过/不过。
- PAS往下走，FAIL自动打回：每次判定都记录"谁执行、谁验收、依据什么标准、理由是什么"，全程可回看——尤其防住"为了让测试通过去改测试"。
- 人工放行也要留痕：人可以在有依据时override，但 override 本身记进证据链。
- 准出看的是可复核证据：主任务、验证任务、报告、截图、采纳动作全部串在一条任务链路里。TRAE的验证 run会产出浏览器仿真报告和逐场景截图——一次验证跑 8 个场景全部 PASS，每一条都有截图佐证。
这一级回答了一个终极问题：AI 说"做完了"，凭什么信？我之前给出了同一个答案的另一种表述——从 L3 迈向 L4 的第一大引擎，就是"可执行、可验证的环境语义模型，让 AI 从'能做'走向'能证明做对'"。"完成"不是agent的一个状态，而是一摞可以随时回看的证据。我们从不同侧面，指向了同一个判断：在 AI 时代，可信，才是效率的通行证。
四、跳上台阶之后：组织该做的五件事
五级台阶是 TRAE 的内部实践，但对任何团队，落到行动上可以浓缩为五件事——有意思的是，这五件事恰好与我之前总结的"落地自主编程五大成功要素"一一呼应：
- 一把手工程：把 AI 提效从"个人行为"上升为"组织工程"。个人偷偷用 AI 叫行为，组织强制用 AI 叫工程。一把手不拍板，能力绑定、契约冻结、门禁强制这些事一件都推不动——因为它们动的是每个人的"舒适区"。
- 换一把尺子：别用代码行数和 token 消耗当绩效。代码行天然适合被 AI 刷爆，token 榜只会催生"为烧而烧"。把人均产出从"代码行"换成"交付需求数"，保留交付周期、变更失败率做质量锚点，新增 AI 采纳率、需求一次通过率等指标。
- 自动化测试先行：先把验证能力补上，再放 AI 去跑。我把"自动化测试先行"列为成功要素之一；TRAE 的交叉验证、浏览器仿真证据链则给出了工程答案。没有验证体系兜底，AI 跑得越快，风险滚得越大。
- 建立审核机制：干活的和验收的，必须分开。执行 AgentRun 与验收 AgentRun 分离、人工 override 留痕、判定依据可回看——这套"审核机制"既是张皓洋的证据链，也是我强调的工程底线：渐进式放权的前提，是每一步都有据可查。
- 持续培训赋能：重新定义人的位置。我曾在5月AiDD峰会上用一句话点透了终局——"从副驾驶到自动驾驶，变的是谁在握方向盘，不变的是，总要有人知道去哪里。"人不再负责"写得多快"，而负责定义目标、设计方案、审查证据、决定放行。AI 省出来的人效，应该用来承接更多项目、覆盖更多场景，而不是把人变少。
最后，我要把之前提醒大家的三大陷阱贴在墙上，随时对照：期望过高、急于求成；重技术、轻管理变革；团队因担心被替代而被动抵制。前两个是节奏问题，第三个是人性问题——而人性的问题，永远不能用工具解决。
结语：填平鸿沟的，从来不是更强的模型
回到开头的三组数字。编码时间缩短 40%、代码编写速度提升10倍、个人提效10倍——它们之所以没能变成组织吞吐的提升，不是因为模型不够强，而是因为提效只发生在了"动作"层面，没有发生在"交付关系"层面。
张皓洋给行业留下了一个清醒的坐标系：AI Coding 解决"这一次做得成不成"，Engineering 解决"下一次做得快不快、稳不稳"；前者是个人的事，后者是组织的事。
而填平个人与组织之间这道鸿沟的路径，恰恰就是那五级台阶：
把生成变成交付，把能力变成契约，把上下文变成记忆，把执行变成流程，把完成变成证据。
当这五件事都做到，AI 的价值才会真正发生质变——它不再只替人完成某个动作，而是开始参与一整套交付关系。这正是我所说的"软件工程3.0"的常态：人机交互智能——Harness让agent这一次做成，Loop Engineering让组织下一次更快、更稳地做成。
到那时，"我更快了"才终于有机会变成"我们更稳了"，"编码提速10倍"才终于有机会变成"组织吞吐提升10倍"。而方向盘，始终在人的手里——因为总要有人知道去哪里。
本文转载自微信公众号「朱少民」，仅供学习交流使用。
觉得内容不错？我要
