BMAD
多 Agent 治理，以宪法文件作为防护栏。适合 10+ 团队的企业级项目。
AI 辅助开发方法论
本指南是 2025-2026 年间涌现的 15 种结构化 AI 辅助开发方法论的快速参考。它们按照从战略编排到优化技术的 6 层金字塔组织。
决策树：你需要什么？
Section titled “决策树：你需要什么？”+-- "我要高质量代码" --> TDD 工作流|+-- "我要先写规格再写代码" --> Spec 驱动开发|+-- "我需要规划架构" --> 计划驱动开发|+-- "我在迭代改进" --> 迭代精炼工作流|+-- "我需要方法论理论" --> 继续阅读下文15 种方法论总览
Section titled “15 种方法论总览”| 方法论 | 层级 | 主要关注 | 团队规模 | 学习曲线 |
|---|---|---|---|---|
| BMAD | 编排 | 治理 | 10+ | 高 |
| GSD | 编排 | 工作流 | 任意 | 中 |
| SDD | 规格 | 契约 | 任意 | 中 |
| Doc-Driven | 规格 | 对齐 | 任意 | 低 |
| Req-Driven | 规格 | 上下文 | 5+ | 中 |
| DDD | 规格 | 领域 | 5+ | 很高 |
| BDD | 行为 | 协作 | 5+ | 中 |
| ATDD | 行为 | 合规 | 5+ | 中 |
| CDD | 行为 | API | 5+ | 中 |
| FDD | 交付 | 功能 | 10+ | 中 |
| Context Eng. | 交付 | AI 会话 | 任意 | 低 |
| TDD | 实现 | 质量 | 任意 | 低 |
| Eval-Driven | 实现 | AI 输出 | 任意 | 中 |
| Multi-Agent | 实现 | 复杂度 | 任意 | 中 |
| Iterative | 优化 | 精炼 | 任意 | 低 |
第 1 层：战略编排
Section titled “第 1 层：战略编排”GSD
6 阶段元提示工作流，每个任务使用全新上下文。适合个人开发者。
BMAD（突破性敏捷 AI 驱动开发） 颠覆了传统范式：文档成为事实来源，而非代码。使用专业化 Agent（分析师、PM、架构师、开发者、QA）进行严格治理编排。
- 核心概念：Constitution.md 作为战略防护栏
- 适用场景：需要治理的复杂企业项目
- 不适用场景：小团队、MVP、快速原型
GSD（Get Shit Done） 通过系统化的 6 阶段工作流（初始化 -> 讨论 -> 计划 -> 执行 -> 验证 -> 完成）解决上下文腐烂问题，每个任务使用全新的 200k token 上下文。
计划优先工作流
Section titled “计划优先工作流”不仅仅是一个功能（/plan 命令），更是一种系统化纪律。
何时需要计划优先：
| 任务复杂度 | 需要计划？ | 原因 |
|---|---|---|
| 修改 >3 个文件 | 是 | 跨文件依赖需要架构思考 |
| 修改 >50 行 | 是 | 足够复杂，容易出错 |
| 架构变更 | 是 | 需要影响分析 |
| 不熟悉的代码库 | 是 | 行动之前需要探索 |
| 修复拼写错误 | 否 | 计划开销 > 任务时间 |
| 单行修改 | 否 | 直接做就好 |
-
探索阶段（通过
Shift+Tab进入计划模式）Claude 读取文件、探索架构。不允许编辑——强制先思考再行动。
-
验证阶段（你来审查）
计划暴露假设和遗漏。现在纠正方向比写了 100 行之后容易得多。
-
执行阶段（用
Shift+Tab切回正常模式）计划到代码变成机械翻译。更少意外，更干净的实现。
在 CLAUDE.md 中集成：
## 计划策略- 必须先计划：API 变更、数据库迁移、新功能- 可选计划：<10 行的 Bug 修复、添加测试- 绝不跳过：影响 >2 个模块的变更第 2 层：规格与架构
Section titled “第 2 层：规格与架构”| 名称 | 定义 | 适用场景 | Claude 适配度 |
|---|---|---|---|
| SDD | 先写规格再写代码 | API、契约 | 核心模式 |
| Doc-Driven | 文档 = 事实来源 | 跨团队对齐 | CLAUDE.md 原生支持 |
| Req-Driven | 丰富的上下文工件（20+ 个） | 复杂需求 | 设置较重 |
| DDD | 领域语言优先 | 业务逻辑 | 设计时使用 |
SDD（规格驱动开发） —— 代码之前写规格。一个结构良好的迭代等于 8 个无结构的迭代。CLAUDE.md 就是你的规格文件。
DDD（领域驱动设计） —— 通过以下方式让软件与业务语言对齐：
- 通用语言：代码中的共享词汇
- 限界上下文：隔离的领域边界
- 领域蒸馏：核心域 vs 支撑域 vs 通用域
第 3 层：行为与验收
Section titled “第 3 层：行为与验收”| 名称 | 定义 | 适用场景 | Claude 适配度 |
|---|---|---|---|
| BDD | Given-When-Then 场景 | 利益相关者协作 | 测试与规格 |
| ATDD | 验收标准优先 | 合规、受监管行业 | 流程较重 |
| CDD | API 契约作为接口 | 微服务 | OpenAPI 原生支持 |
BDD（行为驱动开发） —— 不只是测试，而是协作流程：
Feature: 订单管理 Scenario: 无库存时无法购买 Given 库存为 0 的产品 When 客户尝试购买 Then 系统拒绝并显示错误消息ATDD（验收测试驱动开发） —— 在编码之前由「三方会议」（业务、开发、测试）协作定义验收标准。在 Agent 开发中特别有效，因为 Agent 需要明确的成功条件。
CDD（契约驱动开发） —— API 契约（OpenAPI 规格）作为团队间的可执行接口。
第 4 层：功能交付
Section titled “第 4 层：功能交付”| 名称 | 定义 | 适用场景 | Claude 适配度 |
|---|---|---|---|
| FDD | 按功能逐步交付 | 10+ 大团队 | 结构化 |
| Context Eng. | 上下文作为一等设计元素 | 长会话 | 基础性 |
FDD（功能驱动开发） —— 五个流程：
- 开发整体模型
- 构建功能列表
- 按功能计划
- 按功能设计
- 按功能构建
严格迭代：每个功能最多 2 周。
上下文工程 —— 将上下文视为设计元素：
- 渐进式披露：让 Agent 增量发现
- 内存管理：对话 vs 持久记忆
- 动态刷新：响应前重写 TODO 列表
第 5 层：实现
Section titled “第 5 层：实现”TDD
红-绿-重构。经典循环，AI 辅助的核心工作流。
Eval-Driven
LLM 的 TDD。通过评估测试 Agent 行为。
Multi-Agent
编排子 Agent。从单一助手到编排团队。
TDD（测试驱动开发）
Section titled “TDD（测试驱动开发）”经典循环：
- 红色：写失败的测试
- 绿色：写最少代码使其通过
- 重构：清理代码，测试保持绿色
与 Claude 配合时要明确：「写尚不存在的失败测试。」
验证循环 —— 比 TDD 更广泛的自主迭代模式：
| 领域 | 验证工具 | Claude 能「看到」什么 |
|---|---|---|
| 前端 | 浏览器预览 | 视觉渲染、布局、交互 |
| 后端 | 测试（单元/集成） | 通过/失败状态、错误消息 |
| 类型 | TypeScript 编译器 | 类型错误、不兼容 |
| 风格 | Linter（ESLint, Prettier） | 风格违规、格式问题 |
| 安全 | 静态分析器（Semgrep） | 漏洞模式 |
Eval 驱动开发
Section titled “Eval 驱动开发”LLM 的 TDD。通过评估测试 Agent 行为：
- 基于代码：
output == golden_answer - 基于 LLM：另一个 Claude 评估
- 人工评分：参考标准，较慢
多 Agent 编排
Section titled “多 Agent 编排”从单一助手到编排团队：
Meta-Agent（编排者）+-- 分析师（需求）+-- 架构师（设计）+-- 开发者（代码）+-- 审查者（验证）ADR 驱动开发
Section titled “ADR 驱动开发”架构决策记录（ADR）结合 Claude Code 技能，让架构决策直接驱动实现：
- 用 ADR 格式记录决策（上下文、决策、后果）
- 创建实现技能（通用或专门的
implement-adr） - 将 ADR 作为提示传给技能，附带明确的验收标准
- Claude 根据 ADR 中的架构指导执行
第 6 层：优化
Section titled “第 6 层：优化”| 名称 | 定义 | 适用场景 | Claude 适配度 |
|---|---|---|---|
| 迭代精炼 | 自主收敛 | 优化 | 核心 |
| 全新上下文 | 每任务重置，状态存文件 | 长自主会话 | 高级用户 |
| 提示工程 | 技术基础 | 一切 | 前提条件 |
迭代精炼循环 —— 自主收敛：
- 执行提示
- 观察结果
- 如果结果不等于「完成」-> 精炼并重复
提示工程 —— 所有 Claude 使用的基础：
- 零样本思维链：「一步一步思考」
- 少样本学习：2-3 个预期模式的示例
- 结构化提示：用 XML 标签组织
- 位置重要：长文档中把问题放在末尾
全新上下文模式（Ralph Loop） —— 通过每个任务生成全新 Agent 实例来解决上下文腐烂。状态持久化在 git + 进度文件中，而非聊天历史。适合长自主会话。
SDD 工具参考
Section titled “SDD 工具参考”三种工具形式化了规格驱动开发：
| 工具 | 使用场景 | Claude 集成 |
|---|---|---|
| Spec Kit | 全新项目、治理 | /speckit.constitution, /speckit.specify, /speckit.plan |
| OpenSpec | 存量项目、变更 | /openspec:proposal, /openspec:apply, /openspec:archive |
| Specmatic | API 契约测试 | MCP Agent 可用 |
Spec Kit（全新项目）
Section titled “Spec Kit（全新项目）”5 阶段工作流：
- 宪法：
/speckit.constitution-> 防护栏 - 规格：
/speckit.specify-> 需求 - 计划：
/speckit.plan-> 架构 - 任务：
/speckit.tasks-> 分解 - 实现：
/speckit.implement-> 代码
OpenSpec（存量项目）
Section titled “OpenSpec（存量项目）”双目录架构：
openspec/+-- specs/ <-- 当前事实（稳定）+-- changes/ <-- 提案（临时）工作流：提案 -> 审查 -> 应用 -> 归档
写出有效的规格
Section titled “写出有效的规格”六个核心组件
Section titled “六个核心组件”| 组件 | 包含什么 | 示例 |
|---|---|---|
| 命令 | 带标志的可执行命令 | npm test -- --coverage |
| 测试 | 框架、覆盖率、位置 | vitest, 80%, tests/ |
| 项目结构 | 显式目录 | src/, lib/, tests/ |
| 代码风格 | 一个示例 > 多段文字 | 展示一个真实函数 |
| Git 工作流 | 分支、提交、PR 格式 | feat/name, 约定式提交 |
| 边界 | 权限层级 | 见下方 |
| 层级 | 用途 |
|---|---|
| 始终执行 | 安全操作，无需审批（lint, format） |
| 先确认 | 高影响操作（delete, publish） |
| 绝不执行 | 硬停止（提交密钥、强制推送 main） |
按场景推荐的方法论组合：
| 场景 | 推荐组合 | 说明 |
|---|---|---|
| 个人 MVP | SDD + TDD | 最小开销，质量聚焦 |
| 5-10 人团队，全新项目 | Spec Kit + TDD + BDD | 治理 + 质量 + 协作 |
| 微服务 | CDD + Specmatic | 契约优先，并行开发 |
| 现有 SaaS（100+ 功能） | OpenSpec + BDD | 变更跟踪，无规格漂移 |
| 10+ 企业 | BMAD + Spec Kit + Specmatic | 完整治理 + 契约 |
| LLM 原生产品 | Eval-Driven + Multi-Agent | 自我改进系统 |