菜单
AI驱动敏捷开发方法论：一人顶一个团队的虚拟AI开发团队协作框架。当用户说'帮我开发一个产品'、'从零开始做一个项目'、'用AI团队协作开发'、'BMAD'、'敏捷AI开发'、'AI代理团队'、'虚拟开发团队'、'产品全流程开发'时触发。核心特点：多AI角色协作（PM/架构师/Dev/QA）、规划与执行分离、文档分片、上下文工程化开发。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/gaoqiongxie/skills-ai --skill bmad-method命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
网络安全分析师技能库：754个结构化安全技能，覆盖威胁狩猎、数字取证、事件响应、渗透测试、代码安全审计、威胁情报、恶意软件分析等26个安全领域。映射MITRE ATT&CK v19.1、NIST CSF 2.0等五大框架。当用户说'安全分析'、'威胁狩猎'、'威胁情报'、'渗透测试'、'事件响应'、'MITRE'、'数字取证'、'恶意软件分析'、'红队'、'蓝队'、'SOC'、'网络攻防'时触发。与security-audit互补：security-audit聚焦代码层静态扫描，本Skill覆盖全栈安全分析工作流。
企业级全栈迭代工作流Agent：当用户说'开始开发这个需求'、'处理本次迭代'、'全栈开发闭环'、'跑一个迭代'、'enterprise iteration'、'迭代开发'、'需求交付'、'开发闭环'时触发。自动按需求→设计→开发→测试→Review→部署→记忆7阶段推进，维护迭代状态机，路径感知（自动读取需求目录与代码目录），协调多个子Skill协作完成企业级CRM全栈需求交付。支持状态回退、并行分支、上下文继承。
截图转可交互原型统一入口：根据UI设计稿、手绘草图或竞品截图自动生成HTML高保真原型，并自动联动screenshot-to-prd输出PRD、prd-to-demo完善交互。当用户说'根据截图生成原型'、'设计稿转Demo'、'草图转HTML'、'图片转可交互页面'、'复刻这个界面'、'仿照这个APP做原型'、'截图生成网页'时触发。核心特点：视觉分析自动还原布局、组件识别与映射、多截图串联页面流、与screenshot-to-prd/prd-to-demo形成设计驱动闭环。
基于 SOC 职业分类
正在显示 SKILL.md
| name | bmad-method |
| description | AI驱动敏捷开发方法论：一人顶一个团队的虚拟AI开发团队协作框架。当用户说'帮我开发一个产品'、'从零开始做一个项目'、'用AI团队协作开发'、'BMAD'、'敏捷AI开发'、'AI代理团队'、'虚拟开发团队'、'产品全流程开发'时触发。核心特点：多AI角色协作（PM/架构师/Dev/QA）、规划与执行分离、文档分片、上下文工程化开发。 |
来源: bmad-code-org/BMAD-METHOD — Breakthrough Method for Agile AI-Driven Development
发布时间: 2026-04-29
理念: "一个人 + AI = 一支敏捷团队。规划与执行分离，让AI不再失忆。"
用一支虚拟 AI 开发团队，完成从需求到上线的全流程。
BMAD（Breakthrough Method for Agile AI-Driven Development）不是新编程语言，而是一套让 AI 像敏捷团队一样协作的工程化方法。
传统 AI 编程的问题：
BMAD 的解决方案：
| 角色 | 职责 | 输出物 |
|---|---|---|
| 分析师 (Analyst) | 市场调研、竞品分析、用户画像 | 产品简报 (Product Brief) |
| 产品经理 (PM) | 需求梳理、功能定义、PRD 撰写 | PRD 文档 |
| 架构师 (Architect) | 技术选型、系统设计、接口定义 | Architecture.md |
| 产品负责人 (PO) | 文档分片、对齐检查、验收标准 | Epic 清单、Story 文件 |
| Scrum Master | 任务拆分、排期、进度跟踪 | Sprint 计划、Story 队列 |
| 开发工程师 (Dev) | 代码实现、单元测试 | 代码 + 测试 |
| QA 工程师 | 代码审查、测试用例、质量把关 | Review 报告 |
| UX 设计师 | 交互设计、界面原型 | 设计稿/原型 |
适用场景：Bug 修复、小功能、单点优化（< 1 周）
需求描述 → 快速规格 → 开发实现 → 代码审查
操作步骤：
适用场景：新产品、复杂功能、系统级重构（> 1 周）
产品简报 → PRD 文档 → 架构设计 → Epic 拆分
→ Sprint 计划 → Story 开发 → 代码审查 → 合并发布
七阶段详解：
负责人：分析师 + PM
输出：product-brief.md
# {产品名} 产品简报
## 问题
用户遇到什么痛点？
## 解决方案
我们要做什么？
## 目标用户
谁会用这个产品？
## 成功指标
怎么衡量做得好？
## 范围
- 包含：...
- 不包含：...
## 竞品参考
- 对标产品：...
- 差异化点：...
负责人：PM
输出：prd.md
# {功能名} PRD
## 背景
...
## 目标
...
## 用户故事
作为 [角色]，我想要 [功能]，以便 [价值]
## 功能规格
### 功能 1：...
- 输入：...
- 处理：...
- 输出：...
- 边界情况：...
## 非功能需求
- 性能：...
- 安全：...
- 兼容性：...
## 验收标准
- [ ] 标准 1
- [ ] 标准 2
负责人：架构师
输出：architecture.md
# {系统名} 架构设计
## 技术栈
- 前端：...
- 后端：...
- 数据库：...
- 部署：...
## 系统架构图
[文字描述或 ASCII 图]
## 数据模型
User { id: UUID name: String email: String }
## 接口定义
### API 1: POST /api/users
- 请求：...
- 响应：...
- 错误码：...
## 关键决策
- 决策 1：选择 XX 而不是 YY，原因...
- 决策 2：...
## 安全考量
- 认证：...
- 授权：...
- 数据保护：...
负责人：PO + Scrum Master
输出：epics/ 目录下的多个 epic 文件
# Epic 1: 用户认证模块
## 范围
- 注册/登录/登出
- 密码重置
- JWT Token 管理
## 包含的 Stories
- [ ] Story 1.1: 用户注册接口
- [ ] Story 1.2: 用户登录接口
- [ ] Story 1.3: JWT Token 生成与验证
## 依赖
- 需要数据库用户表（Epic 2）
## 验收标准
- [ ] 单元测试覆盖率 > 80%
- [ ] 接口响应时间 < 200ms
负责人：Scrum Master
输出：sprint-1.md
# Sprint 1 计划
## 周期
2026-05-01 ~ 2026-05-07
## 目标
完成用户认证模块核心功能
## Story 队列
| 优先级 | Story | 估点 | 负责人 |
|--------|-------|------|--------|
| P0 | Story 1.1: 用户注册 | 3 | Dev |
| P0 | Story 1.2: 用户登录 | 3 | Dev |
| P1 | Story 1.3: JWT 实现 | 2 | Dev |
## 验收标准
- [ ] 所有 Story 通过单元测试
- [ ] 代码审查通过
- [ ] 集成测试通过
负责人：Dev
核心机制 — 文档分片 + 上下文工程：
每个 Story 开发时，只加载相关上下文：
Story 1.1: 用户注册接口
├── 加载：PRD 中"用户注册"章节
├── 加载：Architecture.md 中"接口定义"+"数据模型"
├── 加载：coding-standards.md（编码规范）
└── 加载：security-requirements.md（安全要求）
不加载：其他 Epic 的文档、UI 设计稿（除非相关）
这样 Dev 代理既有足够上下文，又不会被无关信息干扰。
负责人：QA + 架构师
审查清单：
| 维度 | 检查点 |
|---|---|
| 功能正确性 | 是否满足 Story 验收标准 |
| 架构一致性 | 是否符合 Architecture.md 中的决策 |
| 代码规范 | 是否遵循 coding-standards.md |
| 安全性 | 是否有 SQL 注入、XSS 等风险 |
| 性能 | 是否有 N+1 查询、死循环等 |
| 测试覆盖 | 单元测试是否完整 |
| 文档 | 关键函数是否有注释 |
审查意见格式：
[BLOCK] 必须修改：...
[NIT] 建议优化：...
[LGTM] 通过
大型项目的 PRD + 架构文档可能超过 5000 字，超过 AI 上下文窗口。文档分片解决"AI 看不过来"的问题。
| 文档类型 | 分片方式 | 示例 |
|---|---|---|
| PRD | 按功能模块分片 | prd-auth.md, prd-payment.md |
| 架构 | 按层次分片 | arch-backend.md, arch-frontend.md |
| 规范 | 按主题分片 | coding-standards.md, api-standards.md |
| Story | 每个 Story 独立文件 | story-1.1-register.md |
文档之间通过引用链接，避免重复：
# story-1.1-register.md
## 相关文档
- [PRD: 用户注册](../prd.md#用户注册)
- [架构: 数据模型](../architecture.md#数据模型)
- [规范: API 设计](../standards/api-standards.md)
在 Dev 代理写代码前，自动组装"最小必要上下文包"：
上下文包 = {
"story": "当前 Story 文件",
"relevant_prd": "PRD 中相关章节",
"relevant_architecture": "架构中相关设计",
"coding_standards": "编码规范",
"previous_similar": "已实现的类似代码（可选）"
}
用户：登录接口偶尔返回 500 错误
BMAD 快速路径：
1. 分析师：收集错误日志，确认复现条件
2. PM：输出快速规格（1页）
3. Dev：定位问题（数据库连接池耗尽），修复代码
4. QA：验证修复，补充测试用例
用户：帮我做一个任务管理工具
BMAD 完整路径：
1. 分析师：调研竞品（Todoist、Notion、Trello）
2. PM：输出 PRD（用户、功能、验收标准）
3. 架构师：设计技术栈（React + Node + PostgreSQL）
4. PO：拆分为 3 个 Epic（认证/任务/通知）
5. Scrum Master：规划 Sprint 1（认证模块）
6. Dev：分片开发 Story 1.1 → 1.2 → 1.3
7. QA：代码审查 → 合并 → 部署
用户：把单体应用拆成微服务
BMAD 完整路径：
1. 分析师：梳理现有模块依赖关系
2. PM：定义拆分范围和优先级
3. 架构师：设计服务边界、通信方式、数据一致性方案
4. PO：按服务拆分 Epic
5. Scrum Master：制定渐进式迁移计划
6. Dev：逐个服务迁移，保持兼容性
7. QA：集成测试、回归测试
| BMAD Method | TDD | OpenSpec-SDD | Agile | |
|---|---|---|---|---|
| 核心 | AI 多角色协作 | 测试先行 | 规范先行 | 迭代交付 |
| 适用 | AI 辅助开发 | 代码质量 | 需求对齐 | 团队管理 |
| 文档 | 分片化、工程化 | 测试即文档 | Spec 即文档 | 看板/文档 |
| 效率提升 | 10-50x | 2-3x | 2-3x | 依赖团队 |
最佳实践：
| Skill | 关系 |
|---|---|
| openspec-sdd | BMAD 的 PRD 阶段可调用 OpenSpec-SDD 进行规范驱动设计 |
| test-driven-development | BMAD 的 Dev 阶段可调用 TDD 进行测试驱动开发 |
| systematic-debugging | BMAD 的 QA 阶段可调用系统调试方法排查问题 |
| writing-plans | BMAD 的 Sprint 计划可调用详细实施计划生成 |
| skill-creator | 用 skill-creator 创建自定义的 BMAD 角色 Skill |
用户：我想用 BMAD 方法开发一个 [产品名称]
AI：
1. 启动 BMAD 快速路径/完整路径
2. 确认产品简报
3. 按七阶段推进
4. 每阶段产出文档，用户确认后继续
"AI 编程的下一步不是更大的模型，而是更好的协作方式。BMAD 让 AI 从'助手'变成'团队'。"