OpenSpec：误用与退出条件
框架最大的风险，不是它本身太差，而是团队把它用成“看起来很完整”的仪式，却没有把真实交付、验证和 review 绑进去。能不能及时退出错误用法，比一开始会不会写模板更重要。
常见误用
- 任何小 typo 都走 proposal，流程负担立刻超过收益。
- archive 永远不清理，导致没人再愿意看历史。
- proposal 写了很多，但实现和验证仍然全靠临场发挥。
维护成本
- proposal 模板与 archive 目录需要持续修剪。
- 需要有人判断哪些变化值得进入 OpenSpec，哪些不值得。
- 如果没有与 PR 和验证命令联动，就会变成孤立文档堆。
退出条件
- proposal 数量越来越多，但 merge 时没人再回看。
- 团队开始用 OpenSpec 包装大项目，最后流程既轻不下去也重不起来。
- archive 没有检索价值，成员只好回到聊天记录找上下文。
维护与退出矩阵
| 判断面 | 继续保留框架的条件 | 该停下来做减法的信号 |
|---|---|---|
| 执行方式 | proposal 模板与 archive 目录需要持续修剪。 | proposal 数量越来越多，但 merge 时没人再回看。 |
| 团队认知 | 需要有人判断哪些变化值得进入 OpenSpec，哪些不值得。 | 团队开始用 OpenSpec 包装大项目，最后流程既轻不下去也重不起来。 |
| 长期收益 | 如果没有与 PR 和验证命令联动，就会变成孤立文档堆。 | archive 没有检索价值，成员只好回到聊天记录找上下文。 |
团队检查清单
- 团队能不能说清每个阶段产出什么，而不只是记住框架名。
- 框架维护成本有没有低于它带来的返工下降与节奏稳定收益。
- 只要真实任务已经持续绕开这套骨架，就该先停下来做减法。
这类风险页的作用，不是证明框架“也有问题”，而是帮助你在框架开始失效时尽早识别出错方向，避免继续往一个已经不被真实任务采用的骨架里堆更多 ritual。
下一步怎么读
- Spec Kit：当你需要更完整的 spec 与 plan 链时，Spec Kit 更合适。
- BMAD：当任务跨角色跨阶段时，BMAD 更能承载治理。
- Superpowers：当你要的是 agent 每天如何执行，而不是 proposal 管理层时，Superpowers 更直接。
- Bugfix / Refactor / Test：OpenSpec 很适合承接高 频维护型变化。
- Issue / Jira -> Draft PR：proposal 通过后，可直接进入异步 PR 流程。