夜雨聆风
最近国外大佬们又在搞事情：
他的大概意思是：
你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的 Agent
而后 Addy Osmani 又有一篇实践案例被推崇：《Loop Engineering》，于是整个 Loop Engineering 就火了起来。
只不过就我研究下来，他们说的未必完全是同一件事，或者说大方向一样，都是在回答 Agent 如何与人协作的问题，所以：
Loop Engineering 可以被看作一次 AI 原生研发团队的实践案例
或者说，是 AI 原生在研发协作场景里的一个具体切面
其实类似于《Loop Engineering》里面替代的案例，我已经看了很多了，跟他类似的案例还有内容团队围绕着 AIGC 工作流做展开的案例。
于是这里真正的问题也就出来了：为什么当前很多实践案例全部是围绕 Agent 展开的，更进一步说是围绕着 Coding Agent 展开的？
原因很简单：现阶段通用大模型基本能力包括通识、推理、成本、效率，都没什么问题了，那么他一定会演进为某“通用垂直领域的偏科模型”，而事实上也确实如此：
现阶段基座模型有很大的精力都是围绕 Coding 展开的
关于为什么选 AI Coding，或者产研这个领域，之前我们也有过探讨，无非是 Coding 首先最好做，其次他既是通用能力，又具备收集垂直领域知识的能力，什么意思呢？
意思是，GitHub 提供了海量优质数据，搞 Coding 这批人对于程序员的 KnowHow 又尤其熟悉
最后就是一旦这个工作台做好后，各行各业只要用它去实现业务，基模就有可能完成优质垂直领域数据收集
整个一套是阳谋，说实话挺聪明的，所以最近一年 AI Coding 演进的速度很快，而从去年下半年开始就已经有很多优秀实践案例了，比如《Loop Engineering》中提到的案例，又比如我们之前的实践案例：
这里可以下个结论就是：AI Coding 对于每个个人的效率提升的有效且夸张的！
但现在有个实际且尴尬的情况是：个人提效 ≠ 整体提效，现阶段团队层面的提升，相较于个人就很不明显了。
所以技术负责人的课题就出来了：团队要怎么和 AI 合作，这个问题比 Coding 工具选型更重要：
进一步，我为什么会说思考清楚 AI 如何与团队协作更重要呢？
他们都在坑你
现阶段市面上有很多坑逼，以《Loop Engineering》为例：
这篇文章很有启发，但也很容易误导团队
因为他看似把 Coding Agent 如何循环起来讲得很清楚，但却隐去了很多细节，比如：
这个 Loop 到底运行在什么组织环境里？
什么意思呢？意思是你正在做的工作，或者 AI 所需的运行环境是谁在维护，这里有非常多的前提：
是一个人自己写项目？ 是两三个人的小团队？ 还是一个几十人、上百人的产研团队？ 是一个新项目？ 还是一个跑了五六年的遗留系统？ 是一个内部工具？ 还是一个有真实用户、有线上 SLA、有合规要求、有历史包袱的生产系统？
这些问题不说清楚，Loop Engineering 就很容易被理解成，按照那个老哥的方法论：
搭好 Automations、Worktrees、Skills、Connectors、Sub-agents，再搞一个 Memory，团队研发就能自动提效了。
这不是扯犊子吗？？？
再比如 Boris Cherny 6 个月没打开 IDE、一个人靠 AI 循环产出 259 个 PR、497 次提交、4 万行代码。
这看起来很酷吧？但各位注意到关键词了吗：一个人，他说的是一个人呢，而你的工作环境是一个人吗？
这就是问题所在：Loop Engineering 的原始叙事，本质上是一个单人超级程序员借助多智能体放大自身产能的故事，而不是一个多人异构团队协作治理的故事。
就文章 《Loop Engineering》 中至少有三个被有意无意隐藏的关键前提：
一、Skill 从哪来？谁来维护？
Loop 的五个组件中，Skill负责把项目知识（代码风格、规范、架构、踩过的坑）打包给 Agent 看。
原文说 Agent 每跑一遍都读一次，无需每次都重新输入，听起来简单。
但在真实团队中，这个 Skill 谁来写？谁来评审？谁来保证它和实际代码库的一致性？
当业务规则发生变化时，谁来更新？如果 Skill 写错了，会不会扯皮，进一步会不会内耗？
二、谁来做最终验证？
Addy 原文中其实也承认了这一点：验证仍然在你身上。一个无人值守的循环也是一个在无人值守时犯错的循环。
他还警告说：Loop虽然很好，但是不要被其诱惑，变成不会思考、只会点开始键的人。
但在真实团队中，验证在你身上意味着什么？
意味着技术负责人要审核每一个 Agent 生成的 PR？那和之前人在循环里的尴尬状态有什么区别？
Loop Engineering 并没有回答：当 Loop 同时跑几十个任务时，人类有限的审阅带宽如何跟得上？
所以说他们鸡贼啊！
三、token成本谁来买单？
Loop 模式总 token 消耗是手动 Prompt 的 3-8 倍，单任务成本是人工的 2-4 倍。
Loop Engineering 方向没错，但你的团队适不适合，这个是要考虑的，因为个人的 Loop 和团队的 Loop 不可能是一个概念，只不过我们这里只是探讨架构，就不考虑成本问题了。
个人效率 ≠ 团队效率
Loop Engineering 的原始案例 Boris Cherny 一个人搞 259 个PR，充分证明了 AI 是个人效率的极致放大；
但是当 10 个工程师各自设计了自己的 Loop，这些 Loop 之间如何协作？当 A 的 Loop 改了一个公共模块，B 的 Loop 完全不知情，怎么办？当产品经理的需求变更了，如何同步给所有正在运行的 Loop？
在我们 AI 训练营学员里面有位 AI 负责人，他分享过一次在做 AI 原生团队搭建过程中的踩坑实录，其中有个金句令我深表认同：
方向正确和实现简单之间，隔着大量的工程细节，每个细节都能让你在错误的方向上耗几个月
他们那套系统跟 Loop Engineering 的方法论很像，但他花了三个月才真正跑通，中间经历了十多次设计推翻。
这里的三个月 + 十几次设计推倒，才是真实团队落地 AI 自动化的常态，而不是 Boris Cherny 那种删掉 IDE、259 个 PR的传奇叙事：
综上，Loop Engineering 是一个美好愿望，他不看团队规模，但我们要看，因为大团队和小团队在实施 AI 原生的过程中面临的问题完全不同，比如：
skill 的维护变成了一个需要版本管理和变更流程的工程项目 多 Loop 并行时，需要统一的上下文治理； token 成本变成了需要预算管理的财务问题； 不同 Loop 生成的代码风格和架构一致性需要统一的规范约束； ......
所以，真正的问题不是要不要搞 Loop，而是应该如何搞，或者说要搞 Loop 需要补足什么，于是这里再次回到了之前的课题：AI 如何与团队协作更重要呢？
关于这个课题，我们之前就给出了答案：SDD。
组织级补丁：SDD
很多人一听到 SDD，就容易把它理解成先写一堆文档。PRD、技术方案、架构文档、测试文档，然后用这些文档去让 AI 生成代码。
这个理解，你不能说它错了，但确实过于简单粗暴些。真正的 SDD 想解决的是 AI 编程进入真实团队项目后所面临的核心问题：
AI 到底应该基于什么上下文去开展工作？ AI 到底应该恪守的边界是什么？哪些有所为，哪些不能为？ AI 生成的结果，到底应该用什么标准去判断对错？
到了团队级别的 AI 提效，一个长期稳定、可追溯、可复用的标准交付流程就很重要了：
为什么需要 SDD
多数同学开启 AI 编程都很幼稚：一句话生成页面、修复 bug、补全测试...
在这个阶段，开发者通过自然语言描述意图，AI 快速生成代码，人类再调整。功能边界小，影响面简单，效率提升非常明显。
但进入团队开发，项目变大变复杂后，问题就来了：
AI 不知道哪个模块不能随便改动，因为被多个应用共享； AI 不知道哪些接口要做兼容； AI 不知道哪些组件是共性的、需要复用而不是重写； AI 也不知道某些看起来别扭的业务逻辑，恰恰是因为解决过特定线上问题才长成那样的。
AI 当前最大的问题不是输出速度，这是从底层实现上钉死了的，他只解决了干得快的问题，不解决干得对的问题：
所以说，Coding Agent 被设计成协作型 Agent，其原因就是需要人去补足，那么补足的是什么呢？补足的是边界与标准，用各种约束尽量去解决 AI 的不可控性。
而 SDD 就是为此而生，他提供一整套完整的方法论：共享上下文、共享规则、共享边界、共享验收标准。
在这个基础下，我们再探讨 SDD 是什么就顺滑得多了：
SDD 到底是什么？
SDD：Spec-Driven Development，规格驱动开发，他是一套方法论；Spec 是这套方法论的核心产物。
他是为了解决我们前面所说的问题而生，这些问题包括：文档写完没人看、和代码脱节、更新不及时、难以验证、只是沟通材料...
这里的 Spec 是研发流程里的事实真相，它有三个核心角色：
第一，Spec 是上下文。
它告诉 AI：业务目标是什么？当前需求解决什么问题？哪些范围可以改、哪些不能动？系统有什么历史约束？接口、数据、权限、状态如何定义？
第二，Spec 是协作契约。
它让产品、研发、测试、架构、AI 这些不同角色围绕同一份理解展开工作——而不是产品说一套、研发理解一套、AI 生成一套、测试验另一套。
第三，Spec 是质量基准。
它定义了什么叫做"完成"：功能是否满足？边界是否覆盖？接口是否兼容历史？性能是否达标？安全合规是否达到？测试是否通过？
SDD 的关键，在于这些规格能不能真正进入有 AI 参与的工作流，成为代码生成、验收和演进的依据。
TDD 和 BDD
这里也顺便说下 TDD 和 BDD，毕竟他们看着单词挺像的：
TDD 的重点是先写测试再写实现，它解决的是代码到底有没有按预期工作。
但 TDD 更靠近技术实现层，对产品方和业务方不够友好，而且测试用例本身也很依赖研发对需求的理解能力，所以现在不太使用，毕竟测试这个工种都要被干没了。
BDD 是用行为场景对齐业务理解。
它通过 Given-When-Then 这样的方式，把业务行为表达出来，让业务和研发围绕用户场景达成一致。
BDD 解决的是业务行为有没有被正确理解。
但 BDD 主要停留在场景和测试层，对代码实际编写过程中的架构约束、代码结构、上下文治理，以及 AI 协作支持有限。
而 SDD 关注的问题更偏上游，他把要做什么、不能做什么、怎么判断完成这几个问题进一步前移，并让这些内容友好的被 AI 消费，所以最终他胜出了。
了解了 SDD 后，我们再说下实操问题。
Spec 应该怎么写？
根据几个学员 SDD 实践情况来说，很多团队会踩一个常见的坑：以为 Spec 越长越好。
这不是的，内容越多，审阅压力越大。有价值的 Spec，不以长短做依据，核心还是要围绕 AI 输出的稳定性出发。
经过实践，有六点心得可供参考：
一、目标：这个需求要达到什么效果？
第一点是要说清楚用户、系统或业务流程在需求完成后能获得什么能力。
错误写法：新增管理后台商品订单详情页。
更好的写法：为运营人员提供商品订单详情查看能力，支持查看订单状态、支付状态、物流状态和异常原因，便于定位履约问题。
二、范围：这次做什么，不做什么
AI 太容易过度发挥了，所以除了告诉它做什么，第二重要的事就是告诉它不做什么。
例如：本期只支持查看，不支持编辑订单；本期只支持手机号验证码登录，不要密码登录及任何第三方快捷登录。
三、约束：AI 必须遵守的边界
这里没什么好说的，直接举个例子吧：
涉及用户敏感信息的数据，落库时必须加密存储，前端展示时必须脱敏；调用外部 AI 接口的超时时间必须控制在 15 秒内，超时或不可用时触发降级策略，严禁阻塞主流程。
四、决策：不允许 AI 重新设计
AI 很容易在执行时重新做架构设计。
所以需要明确：使用哪个表、复用哪个组件、使用哪个状态枚举、接口路径如何命名。
五、任务：拆解小任务
不要让 AI 一次性完成大功能。
虽然现在模型支持百万级上下文，但随着上下文增长，幻觉问题会越来越严重。
应该让 AI 在较低的上下文体量下完成单个任务：数据模型调整、接口定义、前端页面编写、测试用例，逐项推进。
六、验收
写清楚：正常流程怎么验、异常流程怎么验、边界场景有哪些、哪些需要自动化测试、是否需要端到端验证、是否需要灰度或监控。
综上，就是如何写好一个 Spec 的建议，Spec 的价值是明确告知哪些事不能靠猜。
大家照着目标、范围、约束、决策、任务、验收来就行，这六个部分构成了 Spec 的基本骨架。
全链路研发协作
前面聊了 Spec 怎么写、SDD 是什么，但这些都还停留在怎么把需求说清楚的层面，接下来我们看看 Spec 如何影响团队协作。
一、客服反馈案例
客服在群里反馈一个问题：用户说订单详情页打不开，你们看看是不是系统 Bug？而这句话本身是没法直接进入研发流程的。
研发接到以后会有一套 SOP：
是不是操作问题； 重启后会不会发生； 确实没办法才会动手走后续； 哪个用户？哪个订单？什么环境？有没有截图？ 是所有用户都有问题还是个别用户？ 最近有没有发布？日志有没有异常？
客服说的是现象，研发关心的是复现路径，技术 Leader 关注有没有锅，但无论如何都会有很多角色参与其中，这些信息全部靠群聊来回补。
但在 AI 参与的链路里，Agent 收到这条反馈后，新的 SOP 就开始了，我们会按规则把这条反馈整理成一个轻量 Spec（有模板）：
问题现象：订单详情页打开失败； 影响对象：某一类订单、某一批用户，还是所有用户； 复现路径：从哪个入口进入，执行了什么操作； 相关上下文：订单状态、用户身份、客户端版本、最近发布记录； 初步判断：前端展示问题、接口异常、数据异常，还是权限问题； 修改范围：涉及哪些模块，哪些模块不能动； 验收标准：什么情况下算修复完成； 风险提示：是否影响核心流程，是否需要灰度和回滚。
这就是 Spec 的第一个价值：把非结构化反馈，变成结构化任务。
二、Spec 在链路里怎么流转
如果把从反馈到上线的过程拉通，Spec 的流转链路是这样的：
第一步，信息收集。
Agent 先接收问题，自动追问必要信息，比如订单号、报错时间、操作路径、客户端版本...
第二步，初步判断。
Agent 结合日志、接口返回、最近发布记录、代码变更，先判断问题属于哪一类：用户操作问题？配置问题？数据问题？产品体验问题？代码 Bug...
如果不是 Bug，Agent 生成解释口径同步给客服；如果是 Bug，进入下一步。
第三步，生成 Spec。
Agent 把问题整理成一份轻量 Spec，进入研发流程。
研发看到的是一份已经整理过的工程任务：问题现象、影响范围、复现路径......
这个模板越详细，研发乃至后续 AI 自动化的效率越高。
第四步，边界确认。
如果问题简单，Agent 直接基于 Spec 生成修复方案；
如果问题复杂（涉及订单状态、支付链路），Agent 先把方案发给研发确认，不直接改。
第五步，执行修复。
研发确认边界后，AI 再开始基于 Spec 去执行，Spec 里已经写清楚了目标、范围、约束、决策和验收。AI 知道解决什么问题，也知道哪些地方不能碰，这时候 Loop 才有意义。
第六......
后续模块就不赘述了，大家应该能够理解 SDD 是如何参与 AI 协作的了。
三、代码只是过程量
在这个链路里，写代码仅仅是很小的一环。
在案例中，AI 参与了问题识别、上下文整理、任务拆解、边界确认、测试验收和经验沉淀，那它改变的就是整个团队的信息流转方式。
这里我需要再强调一下：
需要改造整个团队的信息流转方式，以去更好的适应 AI 带来的效率
个人提效看的是 AI 输出快不快；团队提效看的是从问题出现到问题解决，整个链路有没有更短、更稳。
上述案例，就是我们某个学员真实的实践情况，只不过他最后也坦言，这个 Case 之所以能够运行得很好，是因为他只涉及到了产研（客服），如果再扩大，就难办了，而难办的点往往是其他团队不配合搭建信息量...
SDD 的三个层次
前面讲了全链路里 Spec 怎么流转，但不同团队落地的深度不一样。根据实际情况，SDD 可以分成三个层次：
第一层：Spec First，规格先行。
这是大部分团队的起手式。先写需求规格，再让 AI 生成方案、拆任务。
这个层次解决的核心问题是需求别做偏，适合新功能、中大型需求、独立模块、边界相对明确的迭代。
第二层：Spec-Anchored，规格锚定。
这一层比 Spec First 更进一步。规格不再是单次输入，而是整个需求、缺陷、重构、测试的长期锚点。
功能上线后，规格作为系统资产持续维护，改模块前先看规格，AI 理解模块也要先读规格，测试补用例也基于规格编写。
第三层：Spec as Source，规格即源码。
这是 SDD 的终极形态。人只维护规格，所有代码由工具生成。
但在大多数业务系统里，这个阶段很难一步到位，毕竟历史包袱、隐性规则、工程妥协、非标准实现太多了，没法完全靠规格生成所有代码。
不是所有任务都需要 SDD
还有一个重要前提需要说清楚：如果所有需求都套进完整规格流程，那原本的 AI 提效就会变成文档负担。
比如：改个文案也要写完整规格？没必要吧。所以 SDD 按任务复杂度又可以做分级：
小改动，比如改文案、调样式。这类任务用 Prompt 就足够了，最多补充一下目标、影响文件，以及告诉 AI 不要改哪些地方。 中等需求，比如新增一个接口、调整一个流程。需要轻量规格：目标、影响范围、约束、验收标准，四样写清楚。让 AI 先出计划，人确认以后再实现。 大型任务，比如新模块开发、多端业务联动、新业务流程接入。需要完整规格：需求规格、技术方案、接口契约、数据模型、任务拆解、测试策略、发布方案、回滚方案。
成熟团队需要能根据任务复杂度选择合适的规格强度。
难在维护
只要做过文档管理的同学都会清楚：所有的知识类管理的难度一定不是写而是数据更新！
SDD 的核心难点也是如此，如何让规格长期稳定维护，始终是项目里的真实来源（Source of Truth），这个会是 AI 负责人长期的命题，他的背后是管理成本的持续投入。
如果你的老板以为 AI 自动化/SDD 是一次性工作，那多半要完犊子...
落地 SDD 的四步路径
说了这么多问题，来聊点实在的：想落地 SDD，怎么开始？
第一步，选一个高价值场景做切入点。
不要一上来就搞完整流程。先选一个场景试点，比如：新模块开发、遗留系统迁移、外部平台接入。
这些场景的共同点是：复杂度高、沟通成本高、返工成本高、上下文容易丢，在这里引入 SDD，价值体现最明显。
第二步，定义轻量 Spec 模板。
不需要很复杂，先把关键问题固定下来：
背景与目标、本期范围、明确不做、业务规则、技术约束、接口和数据影响、任务拆解、验收标准、风险与回滚。
模板不需要每次全填满，但只有这个模板，有没有 AI 效率都会提示。
第三步，建立项目级上下文。
真正持续提升 AI 研发质量的，是项目级的上下文资产：项目原则、架构约束、目录规范、接口规范、权限模型、状态机、错误码、数据字典。
这些内容一旦沉淀下来，就可以反复喂给 AI 作为所有需求的基础上下文，比每次从零解释项目背景高效得多。
第四步，把 Spec 纳入研发流程，明确人工卡点。
需求进入开发前先写轻量 Spec，AI 辅助补充遗漏边界和风险。产品、研发、测试评审关键边界。AI 基于 Spec 生成计划和任务。
开发过程中持续更新 Spec，测试基于 Spec 生成用例。发布后把长期有价值的内容沉淀到项目上下文。
AI 进入组织
前面花了很多篇幅在介绍 SDD，甚至用他去复刻了 Loop 工程类似的案例，搞这么多事情的目的只有一个，告诉技术负责人，你需要关注：
AI 应该在什么规则下参与研发流程？
而 SDD 的价值就在这里，他的意思是：你如果没有方法论，那就用我这一套，其本质也是去构造信息流，构造 AI 需要的环境。
Loop Engineering 这东西给了个美好的愿望，但他更多是一人和 AI 的狂欢，这里确实会很欢，但他意义有限。
如果要让这个美好的愿望更多更大，那就一定要解决信息通道建设的问题，而 SDD 应运而生，但他其实也只是解决了产研体系的工作。
综上，SDD 可以协助我们完成研发团队的全链路 AI 升级
那么，更大范围，比如企业级的方法论是什么，或者说更宏观的视角是什么样的呢？
AI 原生：更高的视角
其实无论是 Loop 工程还是 SDD，他们最终要解决的问题都是一个：大模型这个跨时代的技术进入组织后引起的复杂度如何消化？
大家这里可能不太懂，我们补两个案例：
一开始，AI 只是进入工作任务：写文档、写代码，效率很高；
然后，AI 开始进入流程：它开始改变输入、输出、协作、交付和验收标准；
从这里开始就不仅是工具导入的问题，影响面开始从个人到组织，这里会涉及机制流程，会引发很多人的不适感，最终体现出来的就是各种管理成本。
PS：《Loop 工程》里面的案例更多是在这里打转
再往后，AI 会进入组织：它会冲击角色边界、责任边界、资源调度和评价体系；
所以 AI 进入组织:
最初是单点效率提升； 其次是组织为匹配个人效率提升最初的机制流程改变； 然后是整个公司为了适应 AI 而宣布新的组织结构； 最后是稳定后整个评价体系基于新技术的重塑；
从这里大家再看看 Loop 工程和 SDD 的关系：
Loop 工程描述的是一个效率超高的美好愿望
SDD 是在实现这个愿望过程中所爆发的问题的某种解法
进一步来说他遭遇的是 AI 工具在促使个人提效后，如何转向组织提效过程中的信息流建设方法论
总结一下，AI 进入组织以后，是一个连续爬坡的过程，他会分为四层：
第一层解决个人工具问题，会暴露团队协作问题； 第二层解决流程标准问题，会暴露组织边界问题； 第三层解决组织协作问题，会暴露专业评价问题； 第四层解决评价权专业问题，又会最终暴露商业模式问题；
这里如果要展开会很复杂，但只要大家想实现 Loop 工程的目标，就一定会遭遇这四层循环，并且不用着急：上一层的问题解决以后，会把下一层的问题推出来。
并且，这些问题并不是 AI 带来的，就我对管理及 AI 的认知，我会认为：组织原本就存在的问题。
只是过去这些问题可以被低效率掩盖，但 AI 进来以后，某些节点突然变快了，旧系统的不均衡就被放大了，所以你想推 AI 原生，就必须关注到每一层的问题，解决每一层的问题：
结语
AI Coding 把代码写快了，但交付并没有等比例变快，最终结构是：
个人提效 ≠ 整体提效
现阶段，写代码不是瓶颈，所以瓶颈在往他的上下游延伸，而解决的方法就是构建规则和信息流。
最后，无论是 Loop 工程还是 SDD，都是 AI 原生这个命题下的产物，对 AI 原生感兴趣的可以看看下图：
