---
sha256: 356f4847da0fa115f44022be7d886e0afd71d52be24e7b35c6773005f5d1d4ae
source: "https://mp.weixin.qq.com/s/Lpsl52F_oiFwMBDV7dL8RQ"
title: "AI 原生研发落地实践：我用 Spec-Kit 和 BMAD 跑了一遍 SDD"
author: 叶小钗
publisher: 叶小钗
date: 2026-06-05
type: article
ingested: 2026-06-05
review_value: 8
review_confidence: 8
review_recommendation: worth-reading
---

# AI 原生研发落地实践：我用 Spec-Kit 和 BMAD 跑了一遍 SDD

> 作者：叶小钗 · 发布：2026-06-05

> 导读：今天的话题会涉及到很多 Agent 相关知识，不了解的同学可移步《生产级 Agent 实践指南》。

## 一、AI 原生 ≠ 人人用 AI 工具

### 1.1 个人提效 vs 组织提效的割裂感

今年开始很多企业都在追求 AI 原生，根本原因：组织非常眼红于 AI 对个人的提效（特别是 AI 编程对个人 100%+ 提效的数据），但他们没有在团队/组织上看到这种个人效率提升带来的巨大好处。

- **OPC 类小团队案例惊艳**是因为他们不需要协作，所以效率很高；
- **大团队案例厚实**是因为他们做了大量的机制建设，枯燥的部分已经被做掉了。

但当企业去推 AI 原生时，就会发现戏剧性的割裂感。

### 1.2 一个惊艳的 AI 原生研发案例

某研发团队开始让 AI 接入群聊、线上日志、会议纪要和项目文档，由 AI 定期识别问题、整理 todolist，并同步到自己的任务看板。

随后，AI 会结合源码仓库、项目目标和历史需求，判断任务类型：
- **能写代码的**：自动创建需求、修改代码、补测试、跑单测、提交 PR
- **能出方案的**：直接生成技术方案或项目文档
- **上下文不足的**：主动私聊责任人补充材料

在一些复杂项目里，**已经有 20% 以上的代码由 AI 全流程自助完成**，从发现问题、拆任务、写代码、跑测试到提交 PR，甚至部分低风险合并也会通过两个模型交叉 Review 完成。

### 1.3 惊艳背后的策略清单

这种高智能化表现的背后是各种策略：
- 权限怎么设
- 什么任务能自动做、什么任务必须人审
- 哪些群聊可以监听、哪些信息不能进上下文、建群规则是什么、监听内容的格式有无要求
- AI 生成的 todo 怎么去重
- PR 怎么限制改动范围
- 单测失败怎么办
- 代码 review 谁兜底
- 两个模型意见冲突怎么办
- AI 催人补材料的话术怎么写才不冒犯、需不需要分级、不同级别的频率是什么
- 上下文太长怎么压缩
- AI 误判需求优先级怎么办
- 自动合并造成事故谁负责

**金句**：「你使用 AI Coding 的时候，感叹的是他的效率如何的高；但团队考虑的却不只是效率，他们需要的是稳定的效率，而且不得不关注的问题是错了怎么办、流程崩了怎么办。」

### 1.4 AI 原生的本质

```
AI 原生 = 人人都用 AI 工具，但 人人都用 AI 工具 ≠ AI 原生
```

AI 原生的核心是：**让 AI 参与团队的协作流程**——视角从"AI 能不能帮我写代码"变成"AI 依据什么写代码"。

## 二、SDD（Spec-Driven Development）

### 2.1 SDD 的诞生

SDD 全称 Spec-Driven Development，规格（范）驱动开发。GitHub 在 2025 年通过开源一个名为 Spec-kit 的工具集，把 SDD 理念推到了更多开发者面前。

沿着这条思路，社区里出现了不同风格的实践工具：
- **Spec-Kit** — 偏标准化规格流程
- **OpenSpec** — 偏轻量级规格变更
- **BMAD** — 偏完整的 AI 研发流程编排

### 2.2 Spec-Kit：标准化流程

**Spec-Kit 提供了一套很轻的流程骨架**：
- `/specify` — 把需求和约束讲清楚
- `/plan` — 把方案拆明白
- `/tasks` — 列成可执行的小任务
- `/implement` — 让 AI 按步骤把代码写出来

**核心价值**：维护 AI 稳定运行需要的上下文环境——需求边界、代码边界、特殊业务规则。强制把散乱的信息标准化到一起。

**适用场景**：项目本身产品沉淀、工程事实源都还不错，又是单一 Feature。

### 2.3 BMAD：AI 虚拟产研团队

**BMAD（AI-driven development framework）** 是个协作框架，给一组角色化的 Agent 加引导式工作流，把一个项目从构想、规划、架构，一路推进到开发和测试。

**当前版本四阶段**：分析（可选）→ 规划 → 方案设计 → 实现。不同 Agent 在对应阶段从不同视角进入。

**特色功能**：
- **Party 模式** — 把好几个角色拉进同一场会话里互相讨论、互相挑刺
- **圆桌（Roundtable）** — 每个步骤里都可以拉圆桌，不同角色对同一个问题做评审（产品需求评审、技术方案评审、测试用例评审）

**设计理念**：提供一套模拟的 AI 团队，内置不同角色（产品、架构师、开发者、QA 等），跟真实人类协作方式非常像。

## 三、案例：重构迁移

### 3.1 重构迁移的痛点

**项目背景**：把旧系统的能力迁到新系统上来。

**历史包袱**：
- 旧系统在线跑着不能出问题
- 历史需求和业务逻辑文档不全
- 旧系统可能早接了一堆外部系统
- 新系统不光内部逻辑要对接，对外的 API 也得兼容

**最麻烦的地方**：在历史、背景知识缺失的情况下，代码也不一定能解释清楚业务为什么这么做。

## 四、Spec-Kit 实战：秩序感很强

### 4.1 Spec-Kit 的最大特点

**强制将散乱的上下文整理成一条链路**。主流程：spec → plan → tasks → implement。

### 4.2 多仓适配的痛点

**Spec-Kit 基础流程在多仓项目里不够用**：
- 主仓负责沉淀需求、业务规则、状态流、验收标准
- 前端子仓要消费其中的页面规则、交互逻辑、接口约束
- 后端子仓要消费其中的数据模型、权限边界、接口契约、错误码规则

**核心问题**：
- 同一份规格，前端和后端怎么各自消费？
- 如果主仓修改了一个字段，前端和后端哪些地方会受影响？

### 4.3 三类补充机制

**第一类：多仓适配**
- 把子仓作为 submodule 挂到主仓下面
- 封装新的实现命令，指定前端/后端仓库位置
- 任务拆分加一层按端自动切片逻辑（前端后端各拿各的任务清单）

**第二类：多视角评审**
- Spec-Kit 自带的 analyze 检查项目内部的跨产物一致性
- 搞一组不同角色的评审命令（架构看数据模型、后端看接口消费、QA 看验收标准）
- 每个角色各看各的，最后汇总出报告

**第三类：门禁卡点**
- **新 Feature 启动前**：跑启动检查（API ID 冲突、版本规划纳入）
- **写完之后**：跑合规验证（代码与规范对齐）
- **发布前**：全量版本检查

### 4.4 实战心法：1234 顺序是理想化

**正常情况**：specify → plan → tasks → implement（1234 顺序）

**实际开发**：
- 可能是 1-2-3 然后回头改 spec
- 也可能是 1-2-3-4-1-2-3-4 来回拉扯
- 经常先输出 80-90% 需求，做 plan 时发现细节不对
- 代码写到一半甚至写完后才发现需求漏洞

**两条路**：
1. **先跑通再补文档** — 改造成本小，但需求文档、技术方案、计划任务跟代码对不上 → 后续做新迭代时 AI 信息有偏差，容易产生漂移
2. **回到规格主仓重新走一遍** — 文档与代码始终对齐

**关键洞察**：Spec-Kit 管的是它那条链路内部的秩序，我补的这些管的是链路之外的事。

## 五、BMAD 实战：AI 团队围着项目追问

### 5.1 引入 BMAD 的契机

用 Spec-Kit 最大的感受是，它把 workflow 设计好了，按部就班地填内容走流程就好——但这需要你具备全面能力（前端要 hold 住后端技术栈）。如果是个前端，可能只能审查前端那一部分，后端那一部分审不动。

看到 BMAD 时发现，它的设计理念就是给你提供了一套模拟的 AI 团队——**内置不同角色（产品、架构师、开发者、QA），跟真实人类协作方式非常像**。

### 5.2 圆桌（Roundtable）功能

每个步骤里都可以拉圆桌，拉不同角色对同一个问题做评审。**用不同角色的 agent 对同样的问题分别做分析，提出自己的意见**。

**价值**：
- 弥补一个人想法的局限性
- 规避 AI 漂移和 AI 擅自脑补
- 多个 AI 同时审阅一个 AI，模拟"多 Agent 员工协调"

### 5.3 圆桌挑战"成功标准"案例

**场景**：重构迁移项目，把线上系统替换掉。

**我的最初成功标准**："切换后对方研发几乎无感"。

**圆桌偏架构 Agent 的挑战**：「你拿什么证明？你要跟老系统比，但老系统的行为基线你采了吗？」

**这一问把问题问穿了**——我原来以为自己写了一个挺合理的成功标准，但实际上这个标准建立在一个没被验证的前提上（老系统的行为是清楚的）。老系统跑了好多年，很多行为是历史演化出来的，根本没完整文档。

**最后落成硬约束**：**没有基线，不切换**。

### 5.4 BMAD 帮我纠正的认知偏差

**纠正 1：从 SaaS 到 BPO 的认知**

我最初把系统简单理解成标准 SaaS，但通过 BMAD 的引导和流程推进，发现它其实是个 **BPO（Business Process Outsourcing）系统**——并不是完全标准的 SaaS，而是把公司内部的资源包装到一个系统里，然后做业务的对外输出。

**感触**：从源头上把建设方向给改了。如果按标准 SaaS 的思路做出来，有些功能是过度设计的，而有些实际业务运行过程中的需求又没很好地录到系统里。

**纠正 2：核心目标对齐**

BMAD 提出的尖锐问题：不管你最后做出来的东西是什么样，核心目标是要替换掉线上这套系统。所以除了实现功能外，还要设计好怎么样才能很丝滑地切换过去。

**效果**：所有方案设计和指标都朝着"丝滑切换"对齐，做完后整体比较踏实。

### 5.5 砍需求 13 项 — 贯穿全程

不是上线前一次性砍，每个阶段砍一波：
- **PRD 阶段**：砍 13 项（认证机制等超前功能，第一个客户根本用不到）
- **架构阶段**：砍一轮
- **epics 阶段**：砍一轮

**判断逻辑**：这东西到现在还没用上，上线日越来越近，留它写它测它维护它的代价，已经大于它能带来的收益。

### 5.6 BMAD 的最大问题：心智负担

**工作量翻倍**：
- 担心 AI 在细节上自己脑补，每个细节都得审阅
- BMAD 流程长、细节多、每次产出文档内容多
- 不擅长的点（前端审后端方案）需要先完全搞懂

**整体时间不一定比原始人类协同快**：
- 写代码那段确实提效了（输入确定时 AI 输出比人类快）
- 但前面审阅的过程比人类世界审阅时间多得多
- 断断续续不连贯，每次问 AI 它要思考，然后来回拉扯，再做圆桌挑战，整个过程被拉得非常长

## 六、Spec-Kit vs BMAD：一句话差异

### 6.1 互补关系

**Spec-Kit 拉团队上限**：
- 取决于使用它的人上限在哪里
- 基建越完善、规范越健全、团队能力越强，它就越顺
- 按部就班地在现有体系下实现一个又一个功能
- **如果你需要大量人为去治理、去补足它欠缺的能力，用起来比较吃力**

**BMAD 拉团队下限**：
- 内部有比较完善的行业能力封装（多 Agent 定义、圆桌、深入挖掘）
- copilot 感，把整体下限都托住
- **衍生问题**：你不知道它给你托起来的这些东西对不对——最终敢不敢拍板，还是需要人去审核

### 6.2 场景适配

| 团队类型 | 推荐工具 | 原因 |
|----------|----------|------|
| 一人团队 / 很小团队 | **BMAD** | 补足团队里的角色缺失，补足整体业务和技术能力 |
| 能力强 / 基建完善 | **Spec-Kit** | 更好地控制 AI 在团队里的输出，让它变得更可控 |

### 6.3 总结对照表

| 维度 | Spec-Kit | BMAD |
|------|----------|------|
| 设计哲学 | 标准化流程骨架 | 角色化 AI 团队 |
| 流程形态 | 顺序（specify → plan → tasks → implement） | 4 阶段（分析/规划/方案/实现） |
| 关键能力 | 强制上下文标准化 | 多 Agent 圆桌评审 |
| 多仓支持 | 需补充（submodule / 子仓命令） | 内置多角色 |
| 适合场景 | 单一 Feature、成熟基建 | 一人团队、跨角色补足 |
| 心智负担 | 链路内可控 | 全程需审阅，负担重 |
| 拉的能力 | 上限（团队能力决定顺不顺） | 下限（兜底能力） |

## 七、结语

> AI 原生就是：团队要适应于 AI 的能力去做改造，以便最大化 AI 的能力。

**AI 原生团队的核心**是重新组织协作流程——Spec-Kit 帮你把流程标准化，BMAD 帮你把角色虚拟化。两个工具不是替代关系，是**互补关系**：Spec-Kit 控制链路内的秩序，BMAD 兜住链路外的多视角补足。