本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《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会话，差不多就到了极限。
数量再多，人脑便开始混乱：
这个任务在干什么？
那个任务卡在哪里？
哪个Agent还在等待补充上下文？
于是，他们通过开源的Symphony，把项目管理工具Linear改造成了Agent控制台。
人提交任务，后台自动领取、执行、测试，再处理评审意见。部分团队上线后的前三周，合并PR的数量直接上升了500%。
单看这些数字，一个比一个猛。可这里藏着一个很容易被忽略的问题：
代码写得更快、更多，并不等于产品迭代得更快
Dropbox的团队说得很直接：AI提高代码生成速度以后，交付压力只是顺着流水线向后转移。评审队列越来越长，CI越来越拥挤，测试、发布、部署和线上运维全都开始堵。
百度内部也遇到了几乎一样的情况。Coding Agent让写代码的速度提高了十倍以上，常规的双周迭代周期却没有明显缩短。
团队复盘后发现：Coding只占整条研发链路约20%的时间，其余时间都耗在需求澄清、方案评审、测试验证和等待上。
做个简单计算：如果占比20%的Coding环节提速十倍，其余环节维持原样，整个交付周期也只能缩短18%左右。这一下就很尴尬了：
大家原以为AI会消灭瓶颈，把整体生产效率提高十倍、百倍。结果AI拿着一个大喇叭，把过去藏在研发流程里的问题全喊了出来：
需求不清晰。
优先级反复变化。
接口迟迟没人提供。
组织知识散落在N个群聊和不同人的脑子里。
测试用例不完整，自动化回归测试也没补齐。
验收标准含糊，没人能说清楚怎样才算做完。
其实比较经典的还是这张图：
这和我在企业里观察到的情况基本一致，关于AI编程带给研发团队的效率提升，我有三个感受：
团队越小，提效越明显。极端情况下甚至能达到1000%；团队规模越大，整体提升30%已经很不错。
项目类型会直接影响效果。老系统迁移、后台项目和传统增删查改，提效非常夸张；需要多人共创、跨部门协作的项目，提升往往没那么明显。
工程师能力越强，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年做的两个决定印象很深：
把分散的代码合进一个Monorepo；
用Nix把开发、CI和生产环境做成可复现的统一底座。
这两个工程都不性感，推进时也不会讨喜。
迁移过程会出各种问题，CI需要重建，缓存和测试基础设施欠下的债也得一起还。放在以前，这类事项大概率会被归为重要但不紧急，然后就没有然后了...
只不过，Agent一接入，旧账立刻全部暴露：
没有健全的环境复现能力，Agent就无法验证结果。
代码仓库割裂，Agent就拿不到完整上下文，也看不到一次修改对其他系统的影响。
业务流程没人写下来，新同事学不会，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研发操作系统至少要承载三类能力：
信息通道：组织需求、代码、文档、规则和历史决策；
工作流容器：承载工具、Skills、测试、评审和部署流程；
控制系统：管理权限、审批、日志、成本、失败重试和结果验收。
一家公司刚开始没有必要自研River。Linear、Jira、GitHub、GitLab、CI、Sandbox，再加上项目Rules和Skills，已经可以拼出一个最小版本：
判断的重要性
Anthropic对约40万次Claude Code Session的研究发现，典型协作中，人主要负责规划，Claude主要负责执行。
用户的领域知识越强，一条指令能够撬动的Agent工作量越大，成功率也越高：
产物变便宜，判断和决策变贵
这也符合当前真实情况：谁都可以生成，不代表谁都可以发布。
架构由谁负责，谁能访问生产数据，哪些操作需要审批，出了问题由谁解释，这些边界必须写清楚。
OpenAI会把低风险操作放在Sandbox里自动执行，高风险动作交给人审批，身份、凭据和关键行为全部留下记录。
管理Agent，需要按照上线生产系统的标准来。
毕竟它不睡觉，手速极快，还可能同时拥有代码、客户数据和发布权限，这人万一不听话，那会很麻烦！
结语
上面说了很多，但普通研发团队没有必要开局就重做整套体系。
先找一件经常发生、结果容易判断的任务，把输入、权限、停止条件和验收标准写清楚，然后跑一遍。
第一轮大概率不会更快。
你会发现文档过期、环境缺失、测试不足，很多团队规则也没有写下来。这些问题早就藏在研发流程里了，Agent只是让它们提前暴露。
某个错误反复出现，就放进自动化测试或评测集；某条规则只有老员工知道，就写进项目规则；能够自动检查的问题，尽量别留到人工评审阶段。
最终衡量的也不该是代码量、Token消耗和Agent数量。
任务多久能够交付、中间返工几次、出现多少缺陷、多少任务需要人接管，这些指标更有价值。
代码确实正在变得越来越便宜，但判断、边界和责任没有跟着变少，管理也不会凭空消失。
AI研发操作系统要做的，就是承接机器提速以后新增的复杂度，让整条研发生产线真的快起来。