OpenSpec：适配边界与替代方案
真正的选型问题不是“谁更先进”，而是你当前的团队规模、任务复杂度和治理成熟度，更适合哪一种骨架。框架一旦选错，后续每次任务都会被额外流程拖累。
更适合什么
- 现有项目、brownfield 场景和高频小改动。
- 需要显式记录变更原因，但又不想引入太多角色和阶段的团队。
- 想把 proposal 与最终实现、归档记录连接起来的组织。
与其他框架的边界
- Spec Kit：当你需要更完整的 spec 与 plan 链时，Spec Kit 更合适。
- BMAD：当任务跨角色跨阶段时，BMAD 更能承载治理。
- Superpowers：当你要的是 agent 每天如何执行，而不是 proposal 管理层时，Superpowers 更直接。
比较矩阵
| 如果你当前更在意 | 更适合继续用它 | 更适合改看别的 |
|---|---|---|
| 先把 planning 合同写稳 | 现有项目、brownfield 场景和高频小改动。 | Spec Kit |
| 多角色或更重流程 | 需要显式记录变更原因，但又不想引入太多角色和阶段的团队。 | BMAD |
| 日常执行纪律 | 想把 proposal 与最终实现、归档记录连接起来的组织。 | Superpowers |
什么时候不要选它
- 大范围新功能、跨团队项目或多角色治理型任务。
- 没有人愿意维护 archive，最后 proposal 堆成坟场的团队。
- 把 proposal 当成测试与 review 的替代品的使用方式。
组合方式
- Bugfix / Refactor / Test：OpenSpec 很适合承接高频维护型变化。
- Issue / Jira -> Draft PR：proposal 通过后，可直接进入异步 PR 流程。
下一步怎么读
- Spec Kit：当你需要更完整的 spec 与 plan 链时，Spec Kit 更合适。
- BMAD：当任务跨角色跨阶段时，BMAD 更能承载治理。
- Superpowers：当你要的是 agent 每天如何执行，而不是 proposal 管理层时，Superpowers 更直接。
- Bugfix / Refactor / Test：OpenSpec 很适合承接高频维护型变化。
- Issue / Jira -> Draft PR：proposal 通过后，可直接进入异步 PR 流程。