OpenSpec、Superpowers 和 Spec Kit：SDD 实践模式

OpenSpec、Superpowers 和 GitHub Spec Kit 的实现方式不同，但它们指向同一个工程问题：不要让 AI 编码工具直接从一句提示词跳到生产代码。先把意图、边界、任务、测试和评审证据写成可检查的 artifact。

发布于 2026-05-11 · 更新 2026-05-11 · 8 分钟阅读 · 作者：Spec Coding Editorial Team · 审稿说明：Editorial Policy

SDD 有价值的不是名字，而是 artifact 链

现在很多项目都在讲 spec-driven development。有人强调形式化规格，有人强调验收标准，有人强调 AI agent 的工作流。真正有用的问题不是哪个名词更准确，而是：代码开始之前是否有稳定 artifact，谁负责批准它，最后的 diff 如何证明自己遵守了这个 artifact。

OpenSpec、Superpowers 和 GitHub Spec Kit 值得放在一起看。它们不是同一种产品，Spec Coding 也不是它们的包装层。但它们暴露出一组可以复用的工作流模式。

模式 1：实现前先生成稳定文件

OpenSpec 把一次变更组织成 proposal、specs、design 和 tasks。Spec Kit 强调 constitution、specify、plan、tasks、implement 的生命周期。Superpowers 会先从对话里澄清规格，再进入计划和编码。词汇不同，本质相同：不要让 agent 直接从聊天上下文跳到代码修改。

团队可以用很简单的规则落地：生成代码之前，至少要有一个文件写清目标、非目标、验收标准、负责人、依赖和证据要求。聊天记录不够。需求只存在于模型上下文里，就无法被复查、重跑，也无法和最终代码对照。

模式 2：把产品意图和技术计划分开

Spec Kit 明确把“写什么和为什么”放在“怎么实现”之前。OpenSpec 也把 proposal/specs 和 design/tasks 分开。这一点很重要，因为 AI 编码工具很容易把产品模糊性直接压成实现细节。一旦模型在产品问题还没定时就替你决定数据库结构、API 边界和 UI 行为，团队就失去了决策路径。

模式 3：按风险选择流程重量

OpenSpec 强调流程应该是流动、迭代、适合已有代码库的，而不是僵硬瀑布。这一点值得保留。最差的 SDD 是一堆 Markdown，阻塞工作却不提升评审质量。好的 spec 流程应该跟风险匹配：认证、支付、数据迁移、公开 API、AI 生成代码，需要比文案修正更强的门禁。

最小版本可以只是一页 spec packet。最大版本可以包含 constitution、需求规格、技术设计、任务拆分、迁移计划、风险登记和测试证据。关键是选择最小但足够的 artifact 组合。

模式 4：任务必须能被验证

Superpowers 的强项是让 agent 不能跳过澄清、计划、TDD 和 review。很多 AI 编码流程缺的就是这一步。一个 spec 本身还不够，如果下一步是让模型“把所有东西都做了”，范围仍然会失控。

Task: add timeout retry to refund worker
Write scope:
- src/billing/refund-worker.ts
- src/billing/refund-worker.test.ts

Acceptance:
- timeout once -> retry with same idempotency key
- timeout twice -> keep pending status, no duplicate refund_id

Evidence:
- test: refund_timeout_replay
- log query: duplicate_refund_attempts remains zero

这样的任务给实现留出了空间，但没有把产品策略交给模型决定。

模式 5：评审证据是流程的一部分

三个项目最终都在缩小同一个差距：AI 写出了代码，团队是否能够信任这次变更。这里缺的词是 evidence。规格不应该止步于实现方案，还要写清评审者要看的证据：测试、fixture、日志、截图、契约检查、迁移 dry-run 或灰度指标。

ticket.md
  -> spec.md
  -> design.md
  -> tasks.md
  -> tests + evidence.md
  -> PR review

如果 AI 生成的 PR 不能把每个修改映射回任务和验收标准，这个 PR 就还没准备好。

三个项目各自最值得借鉴的点

不绑定任何工具也能先落地

你不需要先选定框架，才能采用 SDD 的核心。先在仓库里建立一个简单布局：

/specs
  /active
    refund-retry/
      spec.md
      design.md
      tasks.md
      evidence.md
  /archive
/templates
  feature.spec.md
  api-contract.spec.md
  ai-coding-review.md
/docs
  engineering-principles.md

这个布局借鉴了 OpenSpec 的变更文件夹、Spec Kit 的生命周期拆分，以及 Superpowers 的“先计划再执行”。同时它也保持可迁移，后续换工具不会丢掉核心资产。

团队落地时先选一个高频场景

不要一开始就把所有研发流程都改成 SDD。更稳的方式是选一个反复出问题的高频场景，比如 API 字段变更、支付重试、数据迁移、后台批量操作，或者 AI 生成代码进入 PR 前的审查。先把这个场景固定成一套小流程：谁写 spec，谁确认非目标，谁把任务拆成可执行项，谁负责提供测试证据。

第一次试点时，只要求三个文件：spec.md、tasks.md 和 evidence.md。如果这个组合已经能减少澄清评论和返工，就不要急着加更重的 governance。如果仍然有人在评审时争论产品策略，再补 design.md 或 constitution。流程不是越完整越好，而是要刚好覆盖团队最容易漏掉的决策。

AI 编码场景下的评审门禁

当 SDD 用在 AI coding 上，最重要的不是模型能力，而是评审门禁是否清楚。一个合格的 AI 任务应该写清允许修改的文件、禁止触碰的接口、验收标准、失败路径和必须运行的测试。模型可以提出实现方案，但不能决定是否新增依赖、改变公开 API、扩大范围或跳过回滚说明。

评审者应该先看 artifact 链，再看代码风格。第一步确认 diff 是否只改了允许的文件。第二步确认每条验收标准是否对应测试、日志、截图或人工检查。第三步确认没有“顺手重构”“顺手改字段”“顺手补功能”。如果这些问题没有过关，代码再整洁也不应该合并。

一份可执行的 SDD 检查清单

• 需求是否从一句话变成了可评审的 spec.md？
• 非目标是否能阻止范围漂移，而不是只写“暂不考虑”？
• 任务是否小到可以独立实现、测试和回滚？
• 每个任务是否有明确的文件边界和验收标准？
• 证据是否在 PR 前准备好，而不是发布后补充？
• AI 生成的代码是否能逐条映射回 spec 和 tasks？

决策建议

如果变更很窄、风险低、一个 PR 就能评审完，用轻量 spec packet。需要 proposal、design、tasks 和历史归档时，用 OpenSpec 风格的变更文件夹。需要项目原则和重复治理时，参考 Spec Kit 的生命周期。希望 agent 强制执行澄清、TDD 和 review 时，参考 Superpowers 的 skills 工作流。

不要让流程变成表演。好的 SDD 应该减少澄清评论，让测试更早出现，让 PR 评审更客观。如果只是多了文档，就把流程收窄到每个 artifact 都能改变一个决策或证明一个行为为止。