Spec Kit：适配边界与替代方案
真正的选型问题不是“谁更先进”，而是你当前的团队规模、任务复杂度和治理成熟度，更适合哪一种骨架。框架一旦选错，后续每次任务都会被额外流程拖累。
更适合什么
- 新功能、跨模块变更和容易跑偏的复杂任务。
- 需要先对齐目标和验收，但不想引入完整多角色制度的团队。
- 希望把 planning 产物标准化，又保留现有 repo 治理方式的组织。
与其他框架的边界
- BMAD：需要多角色和更完整治理时，BMAD 更合适。
- OpenSpec：如果主要是 brownfield 高频小改动，OpenSpec 更轻。
- Superpowers：如果你更缺日常 agent 操作框架而不是 spec 链，Superpowers 更贴近执行。
比较矩阵
| 如果你当前更在意 | 更适合继续用它 | 更适合改看别的 |
|---|---|---|
| 先把 planning 合同写稳 | 新功能、跨模块变更和容易跑偏的复杂任务。 | BMAD |
| 多角色或更重流程 | 需要先对齐目标和验收，但不想引入完整多角色制度的团队。 | OpenSpec |
| 日常执行纪律 | 希望把 planning 产物标准化，又保留现有 repo 治理方式的组织。 | Superpowers |
什么时候不要选它
- 单点小修、紧急事故或一次性探索任务。
- 完全没有人 review spec 与 plan，只想直接“生成代码”。
- 需要多角色制度、复盘和流程治理的更重场景。
组合方式
- Spec-First：Spec Kit 最自然的落点就是 spec-first。
- Local -> Background -> Cloud：plan 定稿后可把部分任务交给后台或云端执行。
下一步怎么读
- BMAD：需要多角色和更完整治理时，BMAD 更合适。
- OpenSpec：如果主要是 brownfield 高频小改动，OpenSpec 更轻。
- Superpowers：如果你更缺日常 agent 操作框架而不是 spec 链，Superpowers 更贴近执行。
- Spec-First：Spec Kit 最自然的落点就是 spec-first。
- Local -> Background -> Cloud：plan 定稿后可把部分任务交给后台或云端执行。