BMAD：误用与退出条件
框架最大的风险，不是它本身太差，而是团队把它用成“看起来很完整”的仪式，却没有把真实交付、验证和 review 绑进去。能不能及时退出错误用法，比一开始会不会写模板更重要。
常见误用
- 把每个角色都做成独立官僚流程，导致执行速度被自己压垮。
- 只有文档 handoff，没有把验证命令和 review 证据接进流程。
- 明明是小改动，却强行走完整多阶段流程。
维护成本
- 角色说明、模板和故事拆解规则需要持续维护。
- 需要有人负责流程纪律和产物目录整洁度。
- 如果团队规模变化，角色数量与阶段深度也要及时收缩。
退出条件
- 产物越来越多，但没有人按这些产物决策。
- 故事拆解和真实代码执行长期脱节。
- 团队为了绕开流程，不断在仓库外另起聊天或手工补活。
维护与退出矩阵
| 判断面 | 继续保留框架的条件 | 该停下来做减法的信号 |
|---|---|---|
| 执行方式 | 角色说明、模板和故事拆解规则需要持续维护。 | 产物越来越多，但没有人按这些产物决策。 |
| 团队认知 | 需要有人负责流程纪律和产物目录整洁度。 | 故事拆解和真实代码执行长期脱节。 |
| 长期收益 | 如果团队规模变化，角色数量与阶段深度也要及时收缩。 | 团队为了绕开流程，不断在仓库外另起聊天或手工补活。 |
团队检查清单
- 团队能不能说清每个阶段产出什么，而不只是记住框架名。
- 框架维护成本有没有低于它带来的返工下降与节奏稳定收益。
- 只要真实任务已经持续绕开这套骨架，就该先停下来做减法。
这类风险页的作用，不是证明框架“也有问题”，而是帮助你在框架开始失效时尽早识别出错方向，避免继续往一个已经不被真实任务采用的骨架里堆更多 ritual。
下一步怎么读
- Spec Kit：如果你主要缺的是 spec -> plan -> tasks 的产物链，Spec Kit 更轻。
- OpenSpec：如果你主要是 brownfield 的高频小改动，OpenSpec 更省维护成本。
- Superpowers：如果你需要的是日常 agent 操作框架，而不是团队角色制度，Superpowers 更贴近日常执行。
- Spec-First：大多数 BMAD 任务最终都应落回先定边界、再执行的主线。
- Parallel Worktrees / Multi-Agent：在故事清晰后再把低耦合子任务并行化。