https://github.com/0xfurai/claude-code-subagents
https://github.com/bmadcode/BMAD-METHOD
下面给出 BMAD-METHOD 与 Claude Code Subagents Collection（以下简称 CCSC） 的逐项对比分析，帮助你判断在什么场景该选哪一种，或如何组合使用。
| 维度 | BMAD-METHOD | Claude Code Subagents Collection |
|---|---|---|
| 核心定位 | 以「业务-模型-应用-数据」四步抽象做需求→代码的整体方法论，强调一次性写出可演进、可隔离、可测试的业务代码。 | 以50 个领域子 Agent做任务级自动委派，把「写/改/查/审」等原子动作交给最擅长的 Agent，强调持续交互、低成本试错、快速迭代。 |
| 粒度 | 宏观：先画好整体蓝图（领域模型、模块边界、用例图），再落地代码。 | 微观：一次只解决一个可感知的任务（写一个组件、补一个测试、排查一次故障）。 |
| 建模顺序 | 1) Business → 2) Model → 3) Application → 4) Data，强制先做领域建模，抑制「一上来就 CRUD」。 | 无固定顺序，由上下文动态选择 Agent；你可以先写 UI，再让 backend-architect 补 API，再让 database-optimizer 补索引。 |
| 输出物 | • 领域模型图（UML/ER） • 模块接口定义 • 完整可运行代码骨架（含单测） | • 当前请求的最优解（一段代码、一份报告、一条命令） • 多 Agent 协作日志 |
| 角色分工 | 开发者自己按 BMAD 四阶段推进，人主导。 | 50 个 Agent 充当「云同事」，Agent 主导、人 review / 决策。 |
| 适用阶段 | • 0→1 新项目立项 • 需要整体重构/统一语言 • 架构升级（DDD、Clean Architecture） | • 日常开发、改 Bug、加需求 • 突发线上故障 • PoC 快速验证 |
| 知识沉淀 | 强调文档即代码：领域模型、用例、决策记录全部进入 repo，长期资产化。 | 默认不强制沉淀；如需可让 api-documenter 事后补文档。 |
| 可测试性 | 建模阶段就把可测试接口画出来，天然 TDD。 | 由 test-automator 事后补测试，也可让 code-reviewer 强制要求单测。 |
| 技术债控制 | 通过「模型防腐层」「边界上下文」提前隔离。 | 通过 legacy-modernizer 事后渐进式偿还。 |
| 学习曲线 | 需要团队先理解 DDD + BMAD 四步法，前期心智成本高。 | 开箱即用，上手几乎零门槛；但想用好需熟悉 50 个 Agent 的特长。 |
| 成本模型 | 人力时间前置，一次性投入大，后期变动成本低。 | 按需调用 Token，小步快跑，持续付费；复杂任务用 Opus 成本高。 |
| 治理/标准化 | 统一方法论后，跨团队代码风格、术语一致。 | 依赖 .claude/agents 的版本控制，可 fork 统一团队 Agent 模板。 |
组合使用建议
| 场景 | 推荐做法 |
|---|---|
| 新项目启动 | 先用 BMAD-METHOD 跑完业务-模型-应用-数据四步，产出领域模型与模块边界；再把骨架代码交给 CCSC 的 backend-architect / frontend-developer 等 Agent 快速填充实现。 |
| 已有遗留系统 | 用 CCSC 的 legacy-modernizer 做渐进式拆分，同时在关键模块内部逐步引入 BMAD 的「防腐层+领域模型」，避免大爆炸重写。 |
| 日常迭代 | 继续用 CCSC 的各 Agent 做「小步快跑」；每季度让 architect-reviewer 对照 BMAD 的领域蓝图做一次整体架构体检，防止模型漂移。 |
| 技术债治理 | CCSC 的 performance-engineer / security-auditor 发现热点后，用 BMAD 的「模型-应用-数据」视角评估是否需重新划分边界而非局部修补。 |
一句话总结
- BMAD-METHOD = 先画好「正确」的地图，再按图施工
- CCSC = 随时叫最专业的「工人」把当下这一步做到极致
两者并不冲突，而是「战略 vs 战术」的关系：用 BMAD 定战略，用 CCSC 打战术，就能兼备长期可演进性与短期交付效率。