本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《AI 原生研发落地实践：我用 Spec-Kit 和 BMAD 跑了一遍 SDD》
今年开始很多企业都在追求AI原生，为什么会发生这个情况呢？
答案是组织非常眼红于AI对个人的提效，特别是在看到AI编程对个人竟然可以100%+提效的时候，因为他们并没有在团队/组织上看到这种个人效率提升带来的巨大好处，所以他们就会疑惑：真的假的？
于是他们会安排一些人去调研、去学习，几乎都可以拿到正反馈：确实如此！某某团队1个人，一周就完成了个XXX，之前至少得两个月...
但是，真的当这些企业去推所谓AI原生的时候，就会发现那种戏剧性的割裂感一下就上来了，甚至他们会忍不住怀疑：我们是不是没做对，怎么感觉有点Low呢？
其实，并不是他们方向错了，而是现阶段很多优秀的AI原生案例，要么来自于小团队（尤其是以个人为单位的开发者）、要么就是来自于成熟的大团队（拥有系统性的AI工具链）：
OPC类小团队案例惊艳是因为他们不需要协作，所以效率很高；
大团队案例厚实是因为他们做了大量的机制建设，枯燥的部分已经被做掉了；
比如，以下案例是某研发团队追求AI原生的结果，也是很惊艳的：
研发团队开始让AI接入群聊、线上日志、会议纪要和项目文档，由AI定期识别问题、整理todolist，并同步到自己的任务看板。
随后，AI会结合源码仓库、项目目标和历史需求，判断任务类型：
能写代码的，就自动创建需求、修改代码、补测试、跑单测、提交PR；
能出方案的，就直接生成技术方案或项目文档；
上下文不足的，就主动私聊责任人补充材料，直到任务可以继续推进；
在一些复杂项目里，已经有20%以上的代码由AI全流程自助完成，从发现问题、拆任务、写代码、跑测试到提交PR，甚至部分低风险合并也会通过两个模型交叉Review完成。
从案例可以看出，这已经不是简单的AI Coding，而是AI开始进入研发团队的任务流、协作流和交付流，成为团队里的虚拟研发成员了。
对比传统模式，他绝对称得上AI原生，也配得上一个酷字：
只不过，如果站在外部看、站在AI一线使用者的角度看，这当然很酷；但如果是站在AI组织建设者的角度去看，那就一点都不酷了......
因为这种高智能化表现的背后是各种策略，比如上述案例我们实际处理过的模块：
权限怎么设；
什么任务能自动做、什么任务必须人审；
哪些群聊可以监听、哪些信息不能进上下文、建群规则是什么、监听内容的格式有无要求；
AI生成的todo怎么去重；
PR怎么限制改动范围；
单测失败怎么办；
代码review谁兜底；
两个模型意见冲突怎么办；
AI催人补材料，话术怎么写才不冒犯、需不需要分级、不同级别的频率是什么、任务卡住多久要升级给负责人；
上下文太长怎么压缩；
AI误判需求优先级怎么办；
自动合并造成事故谁负责；
......
并且，案例只是暂时表现很好，他有很多边界问题需要不断调试/优化才能彻底进入稳定状态，而这是真的需要投入管理成本的，这里也许也就是为什么会有那种割裂的不真实感的原因：
你使用AI Coding的时候，感叹的是他的效率如何的高
但团队考虑的却不只是效率，他们需要的是稳定的效率，而且不得不关注的问题是错了怎么办、流程崩了怎么办
于是乎，我们就一边在看到未来，一边又在处理低级、琐碎的现实问题，那种荒诞的感觉自然就产生了。
综上，看上去是未来研发团队、Agent虚拟员工，其背后却像在搞一个半自动流水线似的，到处都是规则、到处都需要人工干预/兜底...
上面只是一个很小的案例，但足以说明有建设一个AI原生的研发团队需要面对什么，有了这个认知，便可以进入今天真正的课题了（对你们没猜错，才开始！）：
研发团队应该如何进入AI原生？
研发团队→AI原生
根据前面的探讨，大家能明白：AI能很好让个人提效，但未必能让整个组织大幅进步，换句话说，个人和组织面对AI的课题是不同的：
个人的课题是专业能力和工具的匹配度问题；
团队的课题是当每个人都快了一些后如何保持整体的一致性问题；
课题不同内容不同其要求就有本质上的差异：
个人要求是将AI能力发生到极致，而组织要求是为工具（AI）准备好稳定的环境，所以
AI原生=人人都用AI工具，但人人都用AI工具≠AI原生
AI原生的核心是：让AI参与团队的协作流程，这里依旧是整个视角的变化，需要从
AI能不能帮我写代码？
变成
AI依据什么写代码？
而具体怎么做，我们之前也自己瞎折腾过，比如：拿文档工具沉淀需求、规则，再把这些拉进代码仓库，让AI实现时去参考：
后来碰上Spec-Kit，发现他理念跟我那套几乎一个意思，只是更系统，于是开始深用。
而这个Spec-Kit的背后也就是现在行业里开始越来越多地讨论一个词：
SDD，Spec-Driven Development，规格驱动开发
他也就是我们前面说的面向研发组织级的AI原生团队搭建的一类“最佳实践”了，这里是值得好好看看的：
SDD
SDD全称Spec-Driven Development，即我们常说的规格（范）驱动开发，GitHub在2025年Github通过开源一个名为Spec-kit的工具集，把SDD理念推到了更多开发者面前。沿着这条思路，社区里也出现了不同风格的实践工具：Spec-Kit偏标准化规格流程，OpenSpec偏轻量级规格变更，BMAD则更偏完整的AI研发流程编排。我们这里先来做下简单介绍：
Spec-Kit
以我较为熟悉的Spec-Kit为例，这套工具提供了一套很轻的流程骨架：
用/specify把需求和约束讲清楚
用/plan把方案拆明白
用/tasks列成可执行的小任务
最后让AI按/implement一步步把代码写出来。
其核心就是我们之前说的：维护AI稳定运行需要的上下文环境，这个上下文环境包括：需求边界、代码边界、特殊业务规则......
事实上，没有这些规则我们也能通过和AI结对编程产出最终的结果。
但在组织的角度就会很乱、很多返工内耗，于是Spec-Kit的价值就体现出来了：强制把散乱的信息标准化到一起。
他回答的是一个底层问题：当AI开始进入研发流程之后，团队应该如何组织需求、方案、任务和代码？
总体来说，如果项目本身产品沉淀、工程事实源都还不错又是单一Feature，那么Spec-Kit会是个不错的选择。
BMAD
BMAD是个协作框架，AI-driven development framework。
这个东西给很多人的感觉会高级很多，拿一组角色化的Agent加引导式工作流，把一个项目从构想、规划、架构，一路推进到开发和测试。
现在的版本把它收成四个大阶段：分析（可选）、规划、方案设计、实现。不同Agent在对应阶段从不同视角进入：
为什么会特意介绍这个工具呢，因为他“科技感”噱头要多点，他有个Party模式，能把好几个角色拉进同一场会话里互相讨论、互相挑刺，很有点“多Agent员工协调”的意思。
......
工具这里不介绍太多，我们直接进入案例实践：
案例：重构迁移
这次的项目是重构一个正在跑着的系统，期望把旧系统的能力迁到新系统上来。
重构迁移会涉及历史包袱问题，包括：
旧系统在线跑着不能出问题；
历史需求和业务逻辑文档不全；
旧系统可能早接了一堆外部系统；
新系统不光内部逻辑要对接，对外的API也得兼容；
...
这种项目最麻烦的地方在于：在历史、背景知识缺失的情况下，代码也不一定能解释清楚业务为什么这么做。比如，有些逻辑是为了兼容某个老客户，这种场景一定会存在的。
所以，这种“硬骨头”就非常适合拿来测试所谓AI原生研发框架了：
Spec-Kit：秩序感很强
Spec-Kit的最大特点是：强制将散乱的上下文整理成一条链路。
不过，真正用起来之后问题就来了：Spec-Kit的主流程很清楚，但真实项目的复杂度，经常不在这条主流程里面。
比如我这个项目，有规格主仓，也有前端、后端等实现子仓。
主仓负责沉淀需求、业务规则、状态流、验收标准。
前端子仓要消费其中的页面规则、交互逻辑、接口约束。
后端子仓要消费其中的数据模型、权限边界、接口契约、错误码规则。
这时候问题就来了：
同一份规格，前端和后端怎么各自消费？
如果主仓修改了一个字段，前端和后端哪些地方会受影响？
.....
这些事情，Spec-Kit的基础流程不会帮你全部解决：
Spec-Kit能很好地管理一个Feature内部的Spec、Plan、Tasks、Implement，但如果你要把它放进一个多仓库、多角色、多规范的环境里，就需要补很多治理机制。
比如，把子仓作为submodule挂到主仓下面，让主仓和子仓的上下文尽量打通。
再比如，给不同子仓配置不同的规则文件，让AI知道它当前是在处理前端、后端，还是共享规格。
我用Spec-Kit，大概在那个项目里前前后后做了有十几个feature。我的项目是三个仓库。因为我想把规格这些东西都当成单一事实源，所以把它当做了一个主仓，前端仓库和后端仓库作为两个子仓，以submodule的形式跟主仓做了关联。
做关联的原因是，之前我其实是用飞书做需求管理，把飞书的文档需求写完以后，就直接拉到前端仓库和后端仓库分别去做代码实现。但这种模式有很多问题。首先你的文档怎么算是固定了？每次下发下去写代码的过程中很有可能会发现有问题，回头去更新这些文档的时候，也不太好更新。当时还搞了一套发布和消费的机制，但总体效果很一般。
到了Spec-Kit这里，其实也有这个问题。它最大的特点是，你如果只是做一个单一的feature，然后完美地从头设计、做计划、拆任务到实现，那这个是比较顺的。但这个太理想化了。
在实际的项目重构过程中，你经常会先输出一个百分之八九十的需求。然后当你做plan的时候，会发现有些内容跟你想象的不一样——因为你做plan的时候是会对spec做拆解的，一拆解出来，有些细节就暴露出来了。同样的，从plan转移到task的时候，也会有这样的问题。所以你可能会不断地回头去改之前已经产出的文档。
如果光是设计阶段的拉扯，其实还好，因为这时候大多数都只是需求或者技术方案的变更，还没有涉及到对代码的对齐，改动成本不算特别高，范围也主要集中在这个规格主仓里。
但还有另外一个比较头疼的情况：代码写到一半，你突然发现这里好像有点问题。甚至是代码都写完了，在测试的时候发现需求存在一些漏洞。这时候你就需要对需求或者技术方案做调整，有两条路来选。
一种是先不管三七二十一，先把代码搞了，让功能先跑通。另一种是完全回到规格主仓，从头开始把原始的需求文档改了，改完以后再拆解到plan，再更新task，最终再落回到代码和验收。
如果选第一种，改造成本相对可能小一点，但最大的问题是你的需求文档、技术方案、计划任务跟代码就对不上了。原本文档应该是单一事实源，所有代码都该跟它对齐。但现在变成了代码是新的，文档是老的。后续做新迭代的时候，喂给AI的信息就是有偏差的，容易产生漂移。
其实这种场景还蛮多的。所以Spec-Kit对它固化的那套流程，其实是能控制比较好的，但实际落到团队工程项目里，更多的情况下还是会不断地反复。正常情况是1234的顺序，但实际开发中很有可能是123、234，或者12341234这样来回拉扯。
这个是我用Spec-Kit做重构下来一个比较深刻的体会。也是因为这些，我在使用它的过程中不断地去做补充，大概可以分成三类。
第一类是多仓适配。比如Spec-Kit原版的实现命令是在当前仓库里做代码实现，但因为我做了前后端子仓的机制，就需要再封装一个命令出来，告诉它哪里是前端仓库、哪里是后端仓库，代码应该分别写在哪里。任务拆分也是——原版只产出一份tasks.md，我又加了一层按端自动切片的逻辑，前端后端各拿各的任务清单。
第二类是多视角评审。Spec-Kit自带的analyze能检查一个项目内部的跨产物一致性，但我需要更多维度。于是搞了一组不同角色的评审命令，比如架构看数据模型合不合理、后端看接口能不能消费、QA看验收标准全不全，每个角色各看各的，最后汇总出报告。
第三类是门禁卡点。新Feature动手之前先跑一轮启动检查，看看API ID有没有冲突、版本规划有没有纳进来，全过了才能开始写代码。写完之后再跑一轮合规验证，拿代码跟规范对一对。发布前还要对整个版本做一次全量检查。
这些东西都不是一次想清楚的，都是在实际项目推进过程中，碰到什么问题就补什么。Spec-Kit管的是它那条链路内部的秩序，我补的这些管的是链路之外的事。
BMAD：更像一个AI团队在围着项目追问
了解到BMAD也是机缘巧合。有一次突然看到一个东西，具体在哪我忘了，说这个框架跟人类协作的方式更贴合。然后我就去了解了一下，发现它跟我用Spec-Kit时觉得欠缺的那些东西，正好有一个很好的补足。
用Spec-Kit最大的感受是，它把workflow设计好了，你只要按部就班地在里边填内容、走流程就好了。
但这需要你有一个很全面的能力才行。比如你如果要把一个PRD转成前端和后端的实现，那你需要对整个前后端的技术栈、代码设计、方案编写能力都很强，才能hold住。不然你如果是个前端，可能就只能审查前端那一部分，后端那一部分你就审不动。
但前后端其实是并行的事情，在Spec-Kit里它是一个顺序流程，这就有点冲突。一个人用Spec-Kit干这个事情，会觉得很吃力。前面我不是也封装了很多类似真实角色的agent和skill吗？就是想弥补这方面的不足。
然后看到BMAD的时候，发现它的设计理念就是给你提供了一套模拟的AI团队。它里边有预先设计好的不同角色——产品、架构师、开发者、QA等等。所以在使用的过程中有一个很强的感受：
你不是在用一个工具，而是在跟一个AI虚拟产研团队合作推进一个事情，把一个想法逐渐变成具体的方案，再转换成标准的需求，再对需求做拆解，演变成技术方案、产研计划、工作任务。跟真实的人类协作方式非常像。所以你的认知和思维模式不用做调整，用起来就比较舒服。
而且还有一个很好的点：因为它内置了很多角色，也内置了很多专业的视角，会给你做很好的兜底。比如我这个项目，本质上是要替换线上一个已经在跑的系统。
最开始我用Spec-Kit做的时候，其实是把它当成一个从0到1的事情来做的，所以推进过程中更多关注的是功能怎么设计、怎么实现。但到BMAD这边，它提出了一个很尖锐的问题：不管你最后做出来的东西是什么样，你的核心目标是要替换掉线上这套系统。所以除了实现功能很重要以外，还有一个更重要的目标，就是你要设计好怎么样才能很丝滑地切换过去。
因为线上有业务，业务不能停。它在一开始就会提到这个点，你做的所有方案设计和指标都是朝着这个方向去对齐的。这样整个项目做完以后，你整体上是比较踏实的，而不是说做了一个东西，做完以后发现跟线上偏差比较大。
虽然功能做得比较完善、比较规范、比较整齐，但跟线上偏差大，这时候去切换就会很痛苦，甚至可能还有一大部分工作需要返工。
还有一个让我印象比较深的事。我最开始把这个系统简单地理解成了一个标准SaaS，但通过BMAD的引导和流程推进，我发现它其实是个BPO系统——并不是一个完全标准的SaaS，而是把我们公司内部的资源包装到一个系统里，然后去做业务的对外输出。
这个感触其实很大，因为它相当于从源头上就把建设方向给改了。如果按照之前标准SaaS的思路做出来，有可能有些功能是过度设计的，然后有些实际业务运行过程中的需求又没有很好地被录到系统里。
另外就是它的圆桌功能，非常强大。每个步骤里你都可以拉圆桌，拉不同的角色来对同一个问题做评审。
其实就是跟实际人类协同中的评审一样——产品需求评审、技术方案评审、测试用例评审，评审的时候不同角色的人分别站在自己的角度去看，哪些合理、哪些不足、哪些有漏洞。圆桌就是在模拟这种场景，用不同角色的agent对同样的问题分别做分析，提出自己的意见。
这个非常好，因为你一个人的想法有时候是有局限性的，你擅长的方向不同、能力不同，对同一个问题看到的点天然就是有差异的。
你有你的优势，但肯定有你的不足。通过圆桌的形式，能很好地弥补这个下限，而且确实也能很好地规避AI漂移和AI擅自脑补的问题。有点像用一个AI去审阅另一个AI，只不过这个是多个AI同时去审阅这一个AI。
圆桌在重构迁移这个场景里价值特别突出。我最开始的思路是，先把系统做出来，做完以后再单独设计怎么跟线上做迁移。但圆桌里一个偏架构视角的agent在方案阶段就对这个事情发起了挑战。
它顺着我的成功标准往下追。我当时写了类似"切换后对方研发几乎无感"这样的目标，它问了一句：你拿什么证明？你要跟老系统比，但老系统的行为基线你采了吗？
这一问就把问题问穿了。我原来以为自己写了一个挺合理的成功标准，但实际上这个标准建立在一个没被验证的前提上——老系统的行为是清楚的。但老系统跑了好多年，很多行为是历史演化出来的，根本没完整文档。最后落成了一句硬约束：没有基线，不切换。
挑战让我意识到这个事确实是需要在前期就想好的。因为如果最后东西都做出来了再反过头去调整，改的东西一多，你都不确定即使是AI改的是不是全部改到位了，整体返工成本非常大。
再一个是砍需求这件事，贯穿了整个BMAD推进过程。不是上线前一次性砍的，是每个阶段砍一波。
最开始我的想法是，这个系统未来肯定要接多个客户，有些场景现在已经在实际发生了，别的系统也在跑，所以想提前把基础做好，一次性做全。比如有一个功能是给标准化对接客户设计的认证机制，但我们V1的目标只是把第一个客户的业务替换过来，根本就不存在做这个的场景，完全可以放到后面版本去做。
类似的还有很多，总结下来就是：你预期未来这些肯定要做，但在第一个版本下它又不是必要的。所以PRD阶段就一次性砍了13项。后面也一直延续这个节奏——架构砍一轮，epics又砍一轮。每波逻辑都一样：这东西到现在还没用上，上线日越来越近，留它写它测它维护它的代价，已经大于它能带来的收益了。
但随之而来的也有一个很大的问题：心智负担太重了。
首先工作量翻了很多倍。我这个人又有强迫症，又很担心AI在很多细节上自己脑补，所以每一个细节都得挨个审阅。但BMAD的流程很长，细节很多，每次产出的文档内容也很多，审阅起来就很累。
而且对于自己擅长的内容审阅起来比较轻松，不擅长的点就比较吃力。尤其是技术方面，我是前端，要去审阅后端的技术方案、做一些决策，就得先完全搞懂它在说什么，不同方案的优缺点是什么，然后才能比较准确地做出判断。这个很痛苦。
而且算下来整体时间其实不见得就比原始的人类协同快。感受下来，最终写代码的那段时间确实是提效了，因为输入确定的情况下，它输出代码的速度确实比人类高很多。
但前面审阅的过程，比人类世界里审阅的时间要多得多。因为它是断断续续的，也不连贯。你每次问它一个问题，它也要思考，思考完了回来你还要跟它来回拉扯，然后还要去做圆桌、做挑战，整个过程会被拉得非常长。像人类的话，最多拉个会，评审一次花一两个小时，基本评得差不多就各自分头干活了。
但跟AI协同还不完全是这样，所以在整个前期的方案设计阶段，就会投入非常多的时间。审阅的时候心智负担非常重。这个是我觉得BMAD现在在使用过程中比较麻烦的一个问题。
一句话的差异
如果要一句话说这两个框架的区别，我觉得是这样的：
Spec-Kit能发挥多大作用，取决于使用它的人上限在哪里。你的基建越完善、规范越健全、团队能力越强，它就越顺——你只需要按部就班地在现有体系下去实现一个又一个功能。
它给了你一条清晰的链路，你越能按照它的标准范式推进，就越合适。但如果你的基建很薄弱，需要大量人为去治理、去补足它欠缺的能力，用起来就比较吃力。
BMAD刚好反过来，它能很好地把你的下限拉上来。因为它内部有比较完善的行业能力封装——多Agent的定义也好，圆桌也好，某个方向的深入挖掘也好，它真正是copilot的感觉，把你的整体下限都托住了。
但衍生出来一个最大的问题：你不知道它给你托起来的这些东西对不对。最终敢不敢拍板，还是需要人去审核和确认，这就带来了大量的审阅工作量和心智负担。
所以我觉得场景是这样的：如果你是一个一人团队或者很小的团队，可以用BMAD来帮你补足团队里的角色缺失，或者说补足整体的业务能力和技术能力。
如果你的团队整体能力比较强，基建也比较完善，那用Spec-Kit可以更好地控制AI在团队里的输出，让它变得更可控。
结语
最后回归一下，我们开始说了：
AI原生=人人都用AI工具，但人人都用AI工具≠AI原生
而AI原生是什么？
AI原生就是：团队要适应于AI的能力去做改造，以便最大化AI的能力，今天的Case就是围绕研发团队构建AI比较舒服的环境和工具链和产生的。
我们今天重点讨论了Spec-Kit和BMAD，甚至对于BMAD进行了大量细节的套路，从这些实践感悟中，我相信大家应该能够理解到，AI原生团队的核心其实重新组织协作流程。
好了，今天篇幅不小了，我们后面再继续！