Spec Kit：误用与退出条件
框架最大的风险，不是它本身太差，而是团队把它用成“看起来很完整”的仪式，却没有把真实交付、验证和 review 绑进去。能不能及时退出错误用法，比一开始会不会写模板更重要。
常见误用
- 把 spec 写成空洞大词，导致 plan 和 tasks 仍然无从落地。
- 在没看 repo 的情况下就生成 tasks，最后返工更多。
- 把 Spec Kit 当成文档模板，而不是执行与验收合同。
维护成本
- 模板、示例和任务拆解标准需要持续优化。
- 需要有人判断 spec 到底写到多深才合适。
- 任务复杂度变化后，模板也要跟着收缩或扩展。
退出条件
- spec 与 plan 长期被跳过，团队直接回到临场 prompt。
- tasks 无法对应真实仓库边界，执行始终要重做规划。
- review 已经不再参考 spec，说明链路失效。
维护与退出矩阵
| 判断面 | 继续保留框架的条件 | 该停下来做减法的信号 |
|---|---|---|
| 执行方式 | 模板、示例和任务拆解标准需要持续优化。 | spec 与 plan 长期被跳过，团队直接回到临场 prompt。 |
| 团队认知 | 需要有人判断 spec 到底写到多深才合适。 | tasks 无法对应真实仓库边界，执行始终要重做规划。 |
| 长期收益 | 任务复杂度变化后，模板也要跟着收缩或扩展。 | review 已经不再参考 spec，说明链路失效。 |
团队检查清单
- 团队能不能说清每个阶段产出什么，而不只是记住框架名。
- 框架维护成本有没有低于它带来的返工下降与节奏稳定收益。
- 只要真实任务已经持续绕开这套骨架，就该先停下来做减法。
这类风险页的作用，不是证明框架“也有问题”，而是帮助你在框架开始失效时尽早识别出错方向，避免继续往一个已经不被真实任务采用的骨架里堆更多 ritual。
下一步怎么读
- BMAD：需要多角色和更完整治理时，BMAD 更合适。
- OpenSpec：如果主要是 brownfield 高频小改动，OpenSpec 更轻。
- Superpowers：如果你更缺日常 agent 操作框架而不是 spec 链，Superpowers 更贴近执行。
- Spec-First：Spec Kit 最自然的落点就是 spec-first。
- Local -> Background -> Cloud：plan 定稿后可把部分任务交给后台或云端执行。