最近我为某公司研发团队做了一次相对深入的咨询陪跑，过程中分享了过去两年做 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。
在我们的实践中，一份可以进入执行环节的 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 爆炸，甚至把早已过期的规则当成当前事实。
这里不做好管理策略，一堆问题就会冒出来：
当 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 研发操作系统要做的，就是承接机器提速以后新增的复杂度，让整条研发生产线真的快起来。
本文由作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于平台，未经许可，禁止转载。
睿迎网提示：文章来自网络，不代表本站观点。
