Spec-Kit vs BMAD：AI 原生 SDD 双框架实战对比（叶小钗重构迁移案例）¶
Ch04.096 Spec-Kit vs BMAD：AI 原生 SDD 双框架实战对比（叶小钗重构迁移案例）¶
📊 Level ⭐⭐ | 16.0KB |
entities/spec-kit-bmad-sdd-practice-yexiaocha.md
Spec-Kit vs BMAD：AI 原生 SDD 双框架实战对比（叶小钗重构迁移案例）¶
原文存档：原文存档
叶小钗（2026-06-05）用 Spec-Kit 和 BMAD 跑通一个重构迁移项目（把旧系统能力迁到新系统、兼容线上 API），总结出 SDD 双框架的实战差异：Spec-Kit 拉团队上限、BMAD 拉团队下限——前者适合成熟基建 / 单一 Feature，后者适合一人小团队 / 跨角色补足。
AI 原生的本质：协作流程重塑¶
金句：「AI 原生 = 人人都用 AI 工具，但 人人都用 AI 工具 ≠ AI 原生。」
- 个人课题：专业能力和工具的匹配度问题 → 要求把 AI 能力发挥到极致
- 团队课题：当每个人都快了一些后，如何保持整体一致性 → 要求为工具（AI）准备好稳定的环境
- 核心转变：从"AI 能不能帮我写代码"变成"AI 依据什么写代码"
惊艳案例：某研发团队让 AI 接入群聊、线上日志、会议纪要和项目文档，定期识别问题、整理 todolist，20%+ 代码由 AI 全流程自助完成（发现问题 → 拆任务 → 写代码 → 跑测试 → 提交 PR），部分低风险合并通过双模型交叉 Review 完成。
背后 12 项策略：权限设置 / 自动 vs 人审任务分级 / 群聊监听规则 / todo 去重 / PR 改动范围限制 / 单测失败处理 / review 兜底 / 模型冲突仲裁 / 催人补材料的话术分级 / 上下文压缩 / 优先级误判 / 自动合并事故责任。
SDD 工具谱系：Spec-Kit / OpenSpec / BMAD¶
| 工具 | 风格 | 核心特点 |
|---|---|---|
| Spec-Kit | 标准化规格流程 | /specify / /plan / /tasks / /implement 顺序流程，强制上下文标准化 |
| OpenSpec | 轻量级规格变更 | proposal(范围/边界锁定) + design + tasks + specs(ADDED/MODIFIED/REMOVED 增量化)，已有 Openspec Spec Driven Development Trae Solo 实体 |
| BMAD | 完整 AI 研发流程编排 | 角色化 Agent 团队 + 圆桌评审 + 4 阶段（分析/规划/方案/实现） |
Spec-Kit 实战：秩序感很强¶
最大特点：强制将散乱的上下文整理成一条链路。
多仓适配：3 类补充¶
Spec-Kit 基础流程在多仓项目里不够用——主仓沉淀需求，前端/后端子仓各自消费。补 3 类机制：
| 补充类型 | 解决方案 |
|---|---|
| 多仓适配 | 子仓作为 submodule 挂到主仓；封装新实现命令指定前端/后端位置；任务按端自动切片 |
| 多视角评审 | 扩展 analyze：一组角色化评审命令（架构看数据模型、后端看接口消费、QA 看验收标准），各看各的再汇总 |
| 门禁卡点 | 启动前检查（API ID 冲突、版本规划）→ 合规验证（代码与规范对齐）→ 发布前全量检查 |
顺序流程的拉扯现实¶
理想：1234 顺序（specify → plan → tasks → implement） 现实：123、234、12341234 来回拉扯——做 plan 时拆解暴露细节；写完代码才发现需求漏洞。
两条路： - 先跑通再补文档 — 改造成本小，但文档与代码对不上 → 后续 AI 信息有偏差、产生漂移 - 回到规格主仓重新走一遍 — 文档与代码始终对齐
关键洞察：「Spec-Kit 管的是它那条链路内部的秩序，我补的这些管的是链路之外的事。」
BMAD 实战：AI 团队围着项目追问¶
设计理念：内置不同角色（产品、架构师、开发者、QA）的 Agent 团队，跟真实人类协作方式非常像。
圆桌（Roundtable）— 核心功能¶
每个步骤拉圆桌，多角色 Agent 对同一问题做评审。模拟人类的产品需求评审、技术方案评审、测试用例评审。
三重价值： - 弥补一个人想法的局限性（擅长方向不同，天然有差异） - 规避 AI 漂移和 AI 擅自脑补 - 多 AI 同时审阅一个 AI，模拟"多 Agent 员工协调"
圆桌挑战"成功标准" — 硬约束落地¶
我的初始成功标准："切换后对方研发几乎无感"。 圆桌偏架构 Agent 挑战：「你拿什么证明？你要跟老系统比，但老系统的行为基线你采了吗？」 这一问把问题问穿了——标准建立在一个没被验证的前提上（老系统行为是清楚的），但老系统跑了好多年，行为是历史演化出来的，根本没完整文档。 最后硬约束：没有基线，不切换。
BMAD 帮我纠正的 2 个认知偏差¶
| 维度 | 初始认知 | BMAD 纠正后 |
|---|---|---|
| 业务性质 | 标准 SaaS | BPO（Business Process Outsourcing）系统——把公司内部资源包装到系统做业务对外输出 |
| 核心目标 | 实现功能 | 替换掉线上系统——所有方案设计朝"丝滑切换"对齐，而非仅"功能完整" |
砍需求 13 项 — 贯穿全程¶
不是上线前一次性砍，每个阶段砍一波： - PRD 阶段：砍 13 项（超前功能，第一个客户根本用不到） - 架构阶段：砍一轮 - epics 阶段：砍一轮
判断逻辑：这东西到现在还没用上 + 上线日越来越近 + 留它写它测它维护它的代价 > 它能带来的收益。
BMAD 的最大问题：心智负担¶
- 工作量翻倍——担心 AI 在细节上自己脑补，每个细节都得审阅；不擅长的点（前端审后端方案）需要先完全搞懂
- 整体时间不一定比人类协同快——写代码那段确实提效，但审阅过程断断续续不连贯，每次问 AI 它要思考，然后来回拉扯 + 圆桌 + 挑战，整个过程被拉得非常长
- 审阅负担：相比人类会议评审 1-2 小时基本搞定，AI 协同需要反复多次会话
一句话差异：Spec-Kit vs BMAD¶
| 维度 | Spec-Kit | BMAD |
|---|---|---|
| 拉的能力 | 拉团队上限（取决于使用它的人上限在哪里） | 拉团队下限（copilot 感，把整体下限托住） |
| 前置条件 | 基建越完善、规范越健全、团队能力越强，它就越顺 | 内部已封装行业能力，无需强基建 |
| 衍生问题 | 如果基建薄弱需要大量人为治理，用起来吃力 | 不知道它托起来的东西对不对——最终敢不敢拍板，还是需要人去审核 |
| 流程形态 | 顺序（specify → plan → tasks → implement） | 4 阶段（分析/规划/方案/实现）+ 圆桌穿插 |
| 关键能力 | 强制上下文标准化 | 多 Agent 圆桌评审 |
| 心智负担 | 链路内可控 | 全程需审阅，负担重 |
场景适配公式¶
| 团队类型 | 推荐工具 |
|---|---|
| 一人团队 / 很小团队 | BMAD — 补足团队里的角色缺失，补足整体业务和技术能力 |
| 能力强 / 基建完善 | Spec-Kit — 更好地控制 AI 在团队里的输出，让它变得更可控 |
与现有 SDD 实体差异化¶
本实体关注"双框架实战对比 + 重构迁移项目场景"（Spec-Kit 强秩序 vs BMAD 强圆桌的对比维度 + 各自适用场景）。
- Openspec Spec Driven Development Trae Solo — Trae IDE 内置的 OpenSpec 框架（proposal/design/tasks/specs 四类文档）。本实体是外部 SDD 工具对比（Spec-Kit/BMAD），那个是集成 IDE 的 SDD 工具；形成"独立工具谱系 ↔ IDE 集成 SDD"对照。
- Ai Native Team Building Failures Ceo Digital Twin Case — 叶小钗 16.8KB 旧文，深度讲 AI 原生团队组织建设的"脏乱差"（CEO 数字分身失败案例 / AI 销售线索分配兴衰）。本实体是"SDD 双框架在重构迁移项目的实战"，那个是"AI 原生团队组织建设的失败教训"；同作者同主题不同场景。
- Spec As Aios Anti Entropy Architecture Gaode Ai Native Series 2 — 高德 AI 原生系列第 2 篇：Spec 作为 AIOS 抗熵增架构。本实体是 SDD 流程工具对比，那个是 Spec 作为架构概念的延伸。
深度分析¶
1. SDD 双框架互补公式的深层含义¶
叶小钗总结出「Spec-Kit 拉上限 / BMAD 拉下限」互补公式，本质上揭示了 AI 原生研发的两种不同路线：能力放大 vs 风险兜底。Spec-Kit 要求团队自身具备完善基建和规范，适合已经处于高成熟度状态的团队；BMAD 通过内置多角色 Agent 补足团队缺失，适合刚起步或角色缺失严重的小团队。这个公式对团队选型具有重要指导意义：不要盲目追求「最强工具」，而要判断「我的团队当前最缺什么」。
2. 圆桌评审的核心价值：对抗 AI 漂移而非对抗人类¶
BMAD 圆桌评审（Roundtable）的设计并非简单复制人类评审形式，而是针对 AI 时代特有的「AI 漂移」问题。多个角色化 Agent 同时审视同一个问题，能有效规避单一 AI 擅自脑补的风险。当叶小钗的项目中架构 Agent 提出「老系统行为基线你采了吗」这个追问时，实际上是强制让人类重新审视一个被默认为已解决的隐含前提。这类追问在人类协作中可能被忽略，但在 AI 辅助场景下变得尤为关键。
3. 基线验证是重构迁移的硬约束¶
「没有基线，不切换」这条硬约束揭示了重构迁移项目最核心的风险：旧系统行为是历史演化而来的，通常没有完整文档。当叶小钗用「切换后对方研发几乎无感」作为成功标准时，BMAD 圆桌直接戳穿了这个标准的漏洞——这个标准建立在一个没被验证的前提上。基线验证的意义不仅在于验证新系统功能完整性，更在于迫使团队在切换前完整理解旧系统的真实行为边界。
4. AI 原生团队需要「机制建设」而非「工具堆砌」¶
某研发团队 20%+ 代码由 AI 全流程自助完成的惊艳案例，背后是 12 项策略的系统化配置：权限分层、任务自动/人工分级、群聊监听规则、todo 去重、PR 改动限制、单测失败处理、模型冲突仲裁、催人补材料话术、上下文压缩、优先级误判处置、自动合并责任界定。这些策略构成了一个完整的机制体系，而非单点工具的堆砌。这与叶小钗在「AI 原生团队」主题下的其他案例（如 CEO 数字分身失败）形成呼应：工具本身不解决问题，建立配套机制才是关键。
5. 顺序流程 vs 圆桌流程的结构性差异¶
Spec-Kit 的顺序流程（specify → plan → tasks → implement）在多仓场景下暴露了结构性短板：链路内部的秩序感很强，但链路之外的跨仓消费、跨视角评审、门禁卡点都需要额外补充。而 BMAD 的圆桌穿插模式虽然心智负担重，但在捕捉跨角色问题上更有优势。两种工具分别代表了「流程内 vs 流程外」的不同关注维度，实际落地时需要根据项目阶段和团队成熟度选择主辅搭配。
实践启示¶
1. 重构迁移项目优先建立行为基线¶
在启动任何重构迁移项目前，第一件事不是画架构图，而是完整采集旧系统的行为基线。没有基线的切换是盲切。可以参考叶小钗的做法：让 BMAD 圆桌追问「你拿什么证明」，迫使团队在早期就正视这个问题。行为基线包括：典型业务流程的输入输出、边界条件处理、历史需求变更记录、外部系统集成点。
2. 多仓项目用三层补充机制补 Spec-Kit 的短板¶
面对多仓场景，不要试图让 Spec-Kit 原生支持所有场景，而是补三层机制：① 多仓适配（submodule 挂载 + 按端自动切片任务）② 多视角评审（一组角色化评审命令各自覆盖数据模型/接口消费/验收标准）③ 门禁卡点（启动前检查 → 合规验证 → 发布前全量检查）。这三层机制让 Spec-Kit 在多仓场景下依然保持链路内秩序感。
3. 用「砍需求 13 项」逻辑做需求优先级动态管理¶
需求不是一次性砍完的，而是在 PRD 阶段、架构阶段、epics 阶段分批审视。判断逻辑就一条：到现在还没用上 + 上线日越来越近 + 维护代价 > 收益。这个逻辑可以做成一个可量化的打分卡，每个迭代前跑一遍，避免需求在早期被随意保留到后期变成技术债务。分批砍比一次性砍更符合实际，因为团队对需求的理解是逐渐加深的。
4. 小团队优先用 BMAD 补角色缺失¶
一人团队或很小团队在引入 AI 辅助时，优先选 BMAD 而不是 Spec-Kit。原因是 BMAD 内置的多角色 Agent 能补足团队里缺失的角色（产品、架构师、QA），相当于用工具侧弥补人员侧的空缺。Spec-Kit 需要团队自身具备全面能力才能用好，单一角色用它只能覆盖自己擅长的部分，后端/前端互相审不动的问题会很突出。
5. 警惕「文档与代码漂移」建立双轨校正机制¶
当 Spec-Kit 的 1234 顺序被打乱时（这是常态），团队面临两条路：① 先跑通再补文档（改造成本小，但漂移风险高）② 回到规格主仓重新走（成本高但始终对齐）。建议建立双轨校正机制：每隔 2-3 个迭代，用 BMAD 圆桌对文档和代码的一致性做一次跨角色审视，作为 Spec-Kit 链路内审查的补充。这样可以在保持效率的同时控制漂移。
相关主题¶
- AI 原生团队 — Agent Evolution Four Stages Six Dimensions Aliyun / Agent Skills Teams Architecture Evolution Selection Guide
- 多 Agent 圆桌协作 — Openclaw Multi Agent Team Practice V2
- 规格驱动开发概念 — Ai Agent Exploration Path Legacy Tech
- AI Coding Agent 评测 — Harness Engineered Business Agent Evaluation Aliyun Boyu