SDD 工具链横向对比：Kiro / Spec Kit / OpenSpec / Superpowers

一句话：四者不在同一层——Kiro 是带规范工作流的 IDE，Spec Kit 是「规范到任务」的 CLI 工具包，OpenSpec 是规范变更管理约定，Superpowers 是 Agent 的流程 Skill；选型先看输入、产出、约束方式、集成代价，而不是看功能清单和热度。

说明：本文写于 2026-10。四个项目都在快速迭代，命令、目录和 Agent 支持名单以官方仓库/文档为准；本文不引用 Star 数、下载量等会快速过期的指标。

为什么需要

SDD 工具很容易比错。常见的错误比法有三种：

• 比功能清单：列一张「支持 TDD / 支持子 Agent」的表，但「支持」的定义各不相同。
• 比热度：用 Star 数、下载量推断质量，数字既会过期，也不代表适配你的团队。
• 比模型名：把某个模型版本写进选型结论，模型一升级，结论就失效。

更稳定的比较维度是四个：输入（你给它什么）、产出（它留下什么）、约束（它靠什么保证一致性）、集成（它要求你换工具，还是接进现有工具）。

核心机制

Kiro（AWS）

• 输入：IDE 里的自然语言需求。
• 产出：规范产物（需求、设计、任务等 Markdown 文件），再进入实现。
• 约束：规范审核 + steering 文件（项目级上下文）+ agent hooks。
• 集成：绑定 Kiro IDE。不换 IDE 就用不上它的完整工作流。
• 适合：希望在一个 IDE 内完成「规范 → 任务 → 实现」的团队；代价是工具绑定。

Kiro 的定位是产品化的 spec-driven IDE，不是可以插进任意编辑器的插件。具体文件结构和 hooks 行为以官方文档为准。

GitHub Spec Kit

• 输入：功能描述 + 项目宪法（constitution）。
• 产出：.specify/ 下的宪法、功能规范、计划、任务等 Markdown 产物。
• 约束：宪法作为跨功能的约束；/speckit.clarify 澄清歧义，/speckit.analyze 做跨产物一致性检查。
• 集成：用 specify CLI 初始化项目，按所选 Agent 生成命令文件；支持多个主流 Agent，名单以官方 README 为准。
• 适合：多团队、需要统一架构约束的项目；代价是产物多、流程重。

Spec Kit 是 GitHub 的开源工具包，不是 Copilot 的内置功能。它通过生成 slash commands 让不同 Agent 执行同一套流程。

OpenSpec

• 输入：一个变更提案。
• 产出：openspec/changes/<change>/ 下的 proposal、tasks、design 和增量规范（ADDED / MODIFIED / REMOVED）；归档后合并进 openspec/specs/。
• 约束：增量格式 + openspec validate 的结构检查。
• 集成：CLI 初始化，为不同 Agent 生成使用说明；不绑定 IDE。
• 适合：需求频繁变化、想低成本维护规范的项目；代价是缺少架构级强制约束。

OpenSpec 的重心是「规范怎么变」，不是「代码怎么写」。它不提供 TDD、子 Agent 或审核门。

Superpowers

• 输入：一个功能想法。
• 产出：计划文件、失败测试、实现、验证输出。
• 约束：Skill 流程 + TDD + 独立审查。
• 集成：主要是 Claude Code 插件；其他工具多为社区适配。
• 适合：质量敏感、愿意付出流程开销的功能；代价是 token 消耗和工具绑定。

详见 03-Superpowers深度使用指南。

对比表

维度	Kiro	Spec Kit	OpenSpec	Superpowers
层级	IDE	CLI 工具包	变更管理 CLI	Agent Skill 包
输入	IDE 内需求	功能描述 + 宪法	变更提案	功能想法
主要产出	规范/设计/任务	.specify/ 产物	changes/ 增量	计划/测试/代码
约束方式	规范审核 + steering	宪法 + 一致性检查	增量格式 + validate	Skill + TDD
集成代价	换 IDE	接现有 Agent	接现有 Agent	主要绑定 Claude Code
主要成本	工具绑定	流程重、产物多	无架构强制	token、绑定
最适合	IDE 内一体化	多团队统一约束	频繁变更	核心功能质量门

表中的能力描述是机制层面的归纳，具体命令和默认行为以各项目官方文档为准。

最小上手

不要一次评估四个。选一个真实功能，用同一份输入跑两个候选工具，比较四个产物：

输入：登录连续失败 5 次锁定 30 分钟
记录：
1. 规范文件：是否落盘、能否直接进 git
2. 计划/任务：是否含文件路径、依赖和验收
3. 测试：是否先于实现、能否对应验收条目
4. 验证输出：是否有命令和结果，而不是口头结论

判据：如果某个工具需要你反复补同样三类信息（范围、异常、验收），说明它的模板不适合你的需求类型；如果产物无法进 git 或无法被另一个工具读取，说明集成成本会长期存在。

生产动作

• 先定规范存放位置，再选工具。 规范放在 specs/（或工具默认目录）并进 git；不要让规范散落在各工具的配置里。
• 组合可以，但要有唯一权威。 常见组合是 Spec Kit 管宪法、OpenSpec 管增量变更、Superpowers 管核心功能的 TDD；三者都写规范时，必须指定谁覆盖谁。
• 记录版本。 对比结论标注工具版本和日期，升级后重跑一次最小验证。
• 团队规模不是唯一维度。 真正决定选型的是：是否愿意换 IDE、是否需要跨项目约束、变更频率、改错的代价。
• 给试点设退出条件。 两周内产不出可 review 的规范，或维护成本高于返工成本，就停。

边界

• 不要用 Star 数、下载量、模型名做选型依据。 这些数字变化快，也不代表适配度。
• 「支持 N 个工具」通常指生成了对应指令文件，不等于在该工具里行为一致。
• 没有工具能保证 Agent 遵守规范。 最终仍要靠测试、审查和 CI。
• 闭源 IDE 的能力以官方发布为准，第三方评测可能滞后。
• 方法论工具不能替代工程能力。 规范写得再好，测试和发布流程缺失仍然会出事故。

讲清楚

这四个工具经常被放在一张表里比，但它们不在同一层。Kiro 是 IDE，把规范、任务和实现放进一个产品里，代价是换工具。Spec Kit 是 CLI 工具包，用宪法和命令链把功能描述展开成计划和任务，代价是流程重。OpenSpec 只管理规范变更，用增量目录让规范跟得上代码，代价是没有架构强制。Superpowers 是 Agent 的流程 Skill，用计划和 TDD 管住实现质量，主要绑定 Claude Code。选型不要看功能清单和热度，看四件事：输入是什么、产出能不能进 git、约束靠什么、集成要不要换工具。实际使用中可以组合，但必须有一个权威规范源。

---

初稿 2026-07 | 最后修订 2026-10 | 事实核查：移除 Star 数、虚构能力矩阵与模型路由，改为输入/产出/约束/集成四维