AI 把代码写快了10倍，为什么交付只快了18%？

本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《AI 把代码写快了 10 倍，为什么交付只快了 18%？》

最近我为某公司研发团队做了一次相对深入的咨询陪跑，过程中分享了过去两年做AI原生组织的一些经验。

为了准备这次培训，我把近三个月看到的AI团队实践又翻了一遍。

OpenAI、Shopify、Spotify、Dropbox、Figma、百度、腾讯、阿里，还有一些只有几个人，却同时跑着上百个Agent的小团队。

再加上我这三年做过的25个AI项目，材料堆在一起以后，我原本以为能整理出一份AI原生产研团队先进工具清单。

翻完以后，那张清单反倒没那么重要了。

因为这些团队早已越过谁先用上Codex、Claude Code、谁的项目里AI代码占比更高的阶段。

他们正在干一件麻烦得多，也彻底得多的事情：重新搭建整条产研交付生产线。

代码写快了，所以呢？

Spotify披露，超过99%的工程师每周都在使用AI编程产品，94%的工程师认为自己因此更高效，Pull Request的频率上升了76%。

这组数据已经很夸张了。

Shopify走得更远。他们自主研发了一个叫River的原生Slack Agent，并将它部署在公司内部的公开频道。

员工只要在频道里@它，就可以让它读代码、跑测试、查询数据仓库、查看线上Trace，甚至创建新的Pull Request。

30天内，有3536个被合并的PR由River共同编写完成。

OpenAI内部也发现，一个工程师同时盯着3—5个Agent会话，差不多就到了极限。

数量再多，人脑便开始混乱：

1. 这个任务在干什么？

   
   

2. 那个任务卡在哪里？

   
   

3. 哪个Agent还在等待补充上下文？

   
   

于是，他们通过开源的Symphony，把项目管理工具Linear改造成了Agent控制台。

人提交任务，后台自动领取、执行、测试，再处理评审意见。部分团队上线后的前三周，合并PR的数量直接上升了500%。

单看这些数字，一个比一个猛。可这里藏着一个很容易被忽略的问题：

代码写得更快、更多，并不等于产品迭代得更快

Dropbox的团队说得很直接：AI提高代码生成速度以后，交付压力只是顺着流水线向后转移。评审队列越来越长，CI越来越拥挤，测试、发布、部署和线上运维全都开始堵。

百度内部也遇到了几乎一样的情况。Coding Agent让写代码的速度提高了十倍以上，常规的双周迭代周期却没有明显缩短。

团队复盘后发现：Coding只占整条研发链路约20%的时间，其余时间都耗在需求澄清、方案评审、测试验证和等待上。

做个简单计算：如果占比20%的Coding环节提速十倍，其余环节维持原样，整个交付周期也只能缩短18%左右。这一下就很尴尬了：

大家原以为AI会消灭瓶颈，把整体生产效率提高十倍、百倍。结果AI拿着一个大喇叭，把过去藏在研发流程里的问题全喊了出来：

需求不清晰。

优先级反复变化。

接口迟迟没人提供。

组织知识散落在N个群聊和不同人的脑子里。

测试用例不完整，自动化回归测试也没补齐。

验收标准含糊，没人能说清楚怎样才算做完。

其实比较经典的还是这张图：

这和我在企业里观察到的情况基本一致，关于AI编程带给研发团队的效率提升，我有三个感受：

1. 团队越小，提效越明显。极端情况下甚至能达到1000%；团队规模越大，整体提升30%已经很不错。

   
   

2. 项目类型会直接影响效果。老系统迁移、后台项目和传统增删查改，提效非常夸张；需要多人共创、跨部门协作的项目，提升往往没那么明显。

   
   

3. 工程师能力越强，AI带来的增益越大。会拆问题、懂业务、能判断的人，一条指令就能撬动大量Agent工作。

   
   

个人效率已经发生了巨变，组织效率却经常原地踏步。

一个工程师一天完成过去三天的代码量，测试团队仍然按照原来的速度工作；需求还没讲清楚，Agent已经生成了三套方案；一个部门跑得再快，也得在接口、审批和评审环节继续排队：

个人AI提效，不等于组织AI提效

重做生产线

在做咨询之前，我特别喜欢从企业员工AI使用情况/能力，去判断这个团队是否AI原生了，比如用了多少AI、AI代码占比、Token消耗情况...

真正看多了公司，发现所谓Token消耗没得撒子意义，站在组织的角度，关注点会很不一样：它有没有把人的意图、项目知识、机器执行和最终责任，拼成一条能够稳定运转的研发生产线。

放到产研团队里，可以整理成一套更具体的公式：

AI原生产研团队=员工AI能力+研发机制流程+评价治理机制+AI研发操作系统

员工AI能力，决定工程师能不能用好Codex、Claude Code和各种Agent。

研发机制流程，决定需求、方案、任务和验收能不能被机器理解。

评价治理机制，决定谁有权发布、谁负责检查、出了问题由谁承担责任。

AI研发操作系统，负责连接代码、知识、工具、环境、任务、测试和部署。

这四部分共同决定了AI能否进入研发主线。

只给工程师安装几个工具，最多解决第一部分，而很多组织正在走第二部分，比较典型的方法论是SDD：

做个好上游

过去产品经理写PRD，主要是给人看的，他们有个小心思：下游研发会兜底。

所以，文档里留一点模糊空间，通常问题不大。产品经理可以在评审会上补充，研发可以当面追问，UX/UI也会凭经验补齐缺失状态。

这里倒不是吐槽产品经理，因为研发和测试的关系乃至前端和后端的关系是一样的，比如后端就是要写垃圾接口文档，前端是拿他一点办法都没有。

这些事，之前都是默认下游吃亏，但在AI编程时代就不行了，PRD一旦需要直接喂给Agent，前端看不懂后端接口文档，就会自由发挥，这些模糊空间就危险了：

比如你告诉它：做一个会员系统。

它肯定能做出来，而且看上去还挺像那么回事。

可会员能不能退款？

并发登录怎么算？

优惠券能不能叠加？

旧用户如何迁移？

这些内容没有提前说明，Agent就会自己补。它既敢做，也敢猜。至于猜得对不对，那就看造化了...

总之，执行能力越强，模糊需求越危险

以前，一个含糊的需求最多浪费一两个工程师半天时间。现在，同样一句含糊的话，可以驱动20个Agent并行产出20份完整的错误答案。

AI会把效率放大，也会把偏差一起放大，而且偏得更快。最近Spec又被大家捡回来，原因就在这里。

阿里Qoder的Quest Mode会先生成完整Spec，把它作为人和Agent对齐的事实源。

Agent在后台异步执行，遇到歧义时弹出Action Required，任务结束后再交付一份包含验证结果与代码变更的Task Report。

百度的做法也很接近：用Rules固化工程范围，用Skills封装Code Review、E2E测试和知识库更新，再通过Spec约束技术方案。

以前散落在研发经验里的内容，正在被整理成Agent可以读取、理解和执行的组织资产，这类方法现在经常被统称为SDD。

SDD

在我们的实践中，一份可以进入执行环节的Spec，至少应该包含六个部分：

目标；

范围；

约束；

决策；

任务；

验收。

SDD做的事情并不神秘。它用统一模板承载需求，让不同角色接收到的信息尽量保持一致；再把验收标准变成任务准入和交付验收的凭证。

如果上游提交的Spec缺少边界、异常处理和验收条件，下游，包括Agent，可以拒绝开工。

问题留在源头解决，别再让执行环节不断猜测和补位。这里碰到的是研发管理里的两个老问题：

第一个是信息失真。

信息经过多人传递以后，总会被删减、加工，甚至被不同角色悄悄“加料”。

第二个是评价失效。

上游提交了一份无法执行的需求，最后却没有承担任何质量责任。研发为了推进项目，只能自行补齐，出了问题还得背锅。

所以，SDD建立的是一条研发信息通道，也是Agent能够工作的数字底座，反正核心就是把文档写清楚。

一份有用的Spec，需要讲明白什么结果才算做对，并且尽量让这些标准可以被测试。比如：

用户完成付款后会看到什么？

失败后能否重试？

权限不足时，系统应该怎样告知用户？

哪些业务指标不能下降？

Spec既是需求说明，也是一份验收契约。

当然，SDD也会增加管理成本，比如一个很小的需求，有没有必要走完六个部分？哪些任务需要完整Spec？哪些任务只要一张轻量任务卡？谁来维护模板？谁有权拒绝不合格需求？这些都需要团队自己划分。

并且，大家要清楚：

SDD没有消灭复杂度，它只是把复杂度提前到了定义阶段，让上游承担自己应该承担的工作

即使没有AI，一套执行良好的SDD也能提高团队效率。AI只是把这件事逼得更急了：

依旧是上下文

我看完Shopify的案例后，对他们在2024年做的两个决定印象很深：

1. 把分散的代码合进一个Monorepo；

   
   

2. 用Nix把开发、CI和生产环境做成可复现的统一底座。

   
   

这两个工程都不性感，推进时也不会讨喜。

迁移过程会出各种问题，CI需要重建，缓存和测试基础设施欠下的债也得一起还。放在以前，这类事项大概率会被归为重要但不紧急，然后就没有然后了...

只不过，Agent一接入，旧账立刻全部暴露：

1. 没有健全的环境复现能力，Agent就无法验证结果。

   
   

2. 代码仓库割裂，Agent就拿不到完整上下文，也看不到一次修改对其他系统的影响。

   
   

3. 业务流程没人写下来，新同事学不会，Agent同样猜不对。

   
   

Shopify后来总结了一句话：

代码库里那些为了让Agent读懂而需要偿还的债，其实就是你一直欠人类工程师的债

我觉得这句话可以贴在每个CTO的工位上。哦对了，现在很多公司已经没有CTO了...

在之前Context Engineering也很容易被理解成往提示词里塞更多文档，这其实也是一种AI Max的路径，毕竟谁还不想偷个懒。

只不过，文档塞得太多，Agent会注意力涣散、Token爆炸，甚至把早已过期的规则当成当前事实。

这里不做好管理策略，一堆问题就会冒出来：

AI操作系统的重要性

当Agent数量增加，管理方式也要变化。

当因为要适应AI而发展出来的管理机制多了后，管理也会应接不暇，毕竟所有事情的背后都是成本啊！

什么意思呢？最开始，一个工程师开一个Agent会话，靠自己的记忆就能盯住任务。三五个会话也能勉强应付，等数量增加到十几个，问题马上就来了：

哪个任务正在执行？

哪个任务卡住了？

哪些代码还没有经过测试？

哪些操作正在等待人工审批？

失败以后，应该重试还是转交给人？

为了让Agent稳定工作，我们增加了Spec、Rules、Skills、上下文治理、自动化测试、评测集、权限和审批。

这些机制有用的同时，却也带来了新的管理成本。

如果每份Spec都要管理者人工检查，每次执行都要工程师盯着，每个Agent都要手工补充上下文，每次失败都要人肉整理经验，那么团队很快又会陷入另一种忙乱。

所以，AI研发操作系统还要解决一个很现实的问题：

把为了适应AI而增加的管理动作，尽量交给系统自动执行

比如：

Spec缺少验收标准，系统直接拒绝进入开发；

Agent根据项目自动加载对应的Rules和Skills；

代码修改完成后，自动运行单测、E2E和安全扫描；

测试失败，任务自动退回并附上错误信息；

高风险操作触发人工审批；

任务结束后，自动生成变更说明和验证报告；

失败案例进入评测集，后续任务自动回归。

管理没有消失，只是被固化进了系统。

过去需要项目经理反复催促、研发负责人人工检查的事情，开始由任务状态、自动化规则和质量门禁完成。

回头再看River和Symphony，它们的价值也就更容易理解了。

River把Slack变成统一任务入口，同时连接代码仓库、测试系统、数据仓库和线上Trace。

Symphony把Linear变成Agent控制台，让任务可以自动领取、执行、测试，再根据评审意见继续修改。

它们既在调度Agent，也在降低人类管理Agent的成本。

所以，一套AI研发操作系统至少要承载三类能力：

1. 信息通道：组织需求、代码、文档、规则和历史决策；

   
   

2. 工作流容器：承载工具、Skills、测试、评审和部署流程；

   
   

3. 控制系统：管理权限、审批、日志、成本、失败重试和结果验收。

   
   

一家公司刚开始没有必要自研River。Linear、Jira、GitHub、GitLab、CI、Sandbox，再加上项目Rules和Skills，已经可以拼出一个最小版本：

判断的重要性

Anthropic对约40万次Claude Code Session的研究发现，典型协作中，人主要负责规划，Claude主要负责执行。

用户的领域知识越强，一条指令能够撬动的Agent工作量越大，成功率也越高：

产物变便宜，判断和决策变贵

这也符合当前真实情况：谁都可以生成，不代表谁都可以发布。

架构由谁负责，谁能访问生产数据，哪些操作需要审批，出了问题由谁解释，这些边界必须写清楚。

OpenAI会把低风险操作放在Sandbox里自动执行，高风险动作交给人审批，身份、凭据和关键行为全部留下记录。

管理Agent，需要按照上线生产系统的标准来。

毕竟它不睡觉，手速极快，还可能同时拥有代码、客户数据和发布权限，这人万一不听话，那会很麻烦！

结语

上面说了很多，但普通研发团队没有必要开局就重做整套体系。

先找一件经常发生、结果容易判断的任务，把输入、权限、停止条件和验收标准写清楚，然后跑一遍。

第一轮大概率不会更快。

你会发现文档过期、环境缺失、测试不足，很多团队规则也没有写下来。这些问题早就藏在研发流程里了，Agent只是让它们提前暴露。

某个错误反复出现，就放进自动化测试或评测集；某条规则只有老员工知道，就写进项目规则；能够自动检查的问题，尽量别留到人工评审阶段。

最终衡量的也不该是代码量、Token消耗和Agent数量。

任务多久能够交付、中间返工几次、出现多少缺陷、多少任务需要人接管，这些指标更有价值。

代码确实正在变得越来越便宜，但判断、边界和责任没有跟着变少，管理也不会凭空消失。

AI研发操作系统要做的，就是承接机器提速以后新增的复杂度，让整条研发生产线真的快起来。