近期，某公司研发团队开展了一次较为深入的咨询陪跑活动，期间分享了他们在过去两年中推进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拿着一个大喇叭，把过去隐藏在研发流程中的问题全部喊了出来：
需求不清晰。优先级反复变化。接口迟迟无人提供。组织知识散落在无数个群聊和不同人的头脑中。测试用例不完整，自动化回归测试也尚未补齐。验收标准模糊不清，没人能说清楚怎样才算完成。
其实，经典的还是这张图：
这与我们在企业中的观察基本一致。关于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研发操作系统要做的，就是承接机器提速以后新增的复杂度，让整条研发生产线真正快起来。