Spec-Driven Development

工具对比

工具核心问题类比
Spec-Kit”按什么规矩干”建筑规范手册
OpenSpec”改了什么”施工变更单
Superpowers”怎么干”施工队工作手册

Spec-Kit

pip install uv

github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development

英文原版

Release Spec Kit - 0.16.5 · github/spec-kit · GitHub

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.12.2

中文

uv tool install specify-cn-cli --from git+https://github.com/Linfee/spec-kit-cn.git@v0.5.0

更新

specify self upgrade

初始化

specify-cn init .

命令

2.1 /speckit.constitution - 建立项目原则(项目宪法：全局约束、开发准则)
2.2 /speckit.specify - 创建基线规范(功能规范：描述 what 和 why)
2.3 /speckit.plan - 创建实施计划(技术计划：技术栈和架构选择)
2.4 /speckit.tasks - 生成可执行任务(任务分解：可执行的任务清单)
2.5 /speckit.implement - 执行实施
│  ○ /speckit.clarify (optional) - Ask structured questions to de-risk ambiguous areas before planning (run before /speckit.plan if used)                                      │
│  ○ /speckit.analyze (optional) - Cross-artifact consistency & alignment report (after /speckit.tasks, before /speckit.implement)                                             │
│  ○ /speckit.checklist (optional) - Generate quality checklists to validate requirements completeness, clarity, and consistency (after /speckit.plan)

  • /speckit-clarify （需求澄清）

    • 使用时机：在 /speckit-specify 之后、/speckit-plan 之前（可选）。用于识别规范中的模糊点和歧义，通过结构化的选择题来澄清边界与例外，并更新规范文档。

  • /speckit-checklist （生成质量校验清单）

    • 使用时机：在 /speckit-plan 技术方案生成之后（可选）。用于生成需求满足检查清单，辅助人工审查方案的完整性和一致性。

  • /speckit-analyze （一致性检查）

    • 使用时机：在 /speckit-tasks 任务分解之后、/speckit-implement 编码实现之前（可选，强烈建议）。用于交叉检查规范、计划和任务之间的一致性，生成一致性报告和问题修复建议，防止后续开发偏离需求。

Constitution

产出：constitution.md

  • 代码质量标准
  • 测试规范
  • 用户体验一致性要求
  • 性能要求

spec.md（规范）：描述具体功能的需求

  • 用户故事
  • 功能需求
  • 不涉及技术栈（关注 what 和 why）

plan.md（计划）：技术实现方案

  • 技术栈选择
  • 架构设计
  • API 契约

tasks.md（任务）：可执行的任务清单

  • 从计划中提取的具体任务
  • 实现步骤

OpenSpec

安装

npm install -g @fission-ai/openspec@latest

进入你的项目根目录，执行 openspec init。系统会交互式询问你使用的 AI 工具（如 Cursor、Claude Code 等），随后自动生成 openspec/ 目录

  • specs/ ：系统当前行为的“唯一事实来源（Source of Truth）”。
  • changes/ ：待实现的功能变更提案工作区。
  • config.yaml：项目配置（强烈建议在此填入技术栈、代码规范等上下文，AI 后续生成代码时会自动读取）。

核心工作流（日常开发四步曲）

OpenSpec 的日常使用可以概括为：提案 → 实施 → 验证 → 归档。在 AI 编辑器中，主要通过以下斜杠命令（以 /opsx: 为例）驱动：

  1. 第一步：提出变更提案（Propose）

    • 命令：/opsx:propose [change-name] （例如 /opsx:propose add-dark-mode）
    • 作用：AI 会生成一套规划文档，包括 proposal.md（背景与目标）、specs/（增量需求规范）、design.md（技术方案）和 tasks.md（实施清单）。
    • ⚠️ 关键动作：AI 生成后必须经过人工审查。你可以直接修改 Markdown 文件来调整需求或技术方案，确认无误后再进入下一步。

  2. 第二步：执行代码实施（Apply）

    • 命令：/opsx:apply [change-name]
    • 作用：AI 会读取 tasks.md，像“照图施工”一样逐个任务生成代码，并在完成后自动勾选任务状态。

  3. 第三步：验证一致性（Verify，可选）

    • 命令：/opsx:verify [change-name]
    • 作用：检查代码实现与规范文档是否对齐，生成验证报告，防止 AI 自由发挥导致偏离需求。

  4. 第四步：归档变更（Archive）

    • 命令：/opsx:archive [change-name]
    • 作用：将本次变更移至归档目录，并将增量规范（Delta Specs）合并至主规范库（specs/），更新变更日志。这标志着该功能正式成为系统现状的一部分。

CLI 终端管理指令

在终端中，你可以使用以下命令管理项目状态：

  • openspec list：列出当前进行中的所有变更。
  • openspec show [item] ：查看某个变更或规范的详细信息。
  • openspec validate [item] ：校验规范格式是否正确。
  • openspec update：如果斜杠命令不生效，运行此命令刷新 AI 工具指令文件并重启编辑器。