规范驱动开发SDD工具对比：OpenSpec与SpecKit，新项目与存量代码库如何选？

AI 编程工具越来越强，但“先写规范再写代码”的 SDD（规范驱动开发）理念也开始流行。面对复杂的项目需求，如何将模糊的想法转化为结构化的行动指南？GitHub 的 Spec Kit 与 Fission AI 的 OpenSpec 是目前最值得关注的两个开源框架，它们的设计思路和使用体验有何不同？本文将为你梳理它们的核心差异，助你根据项目场景做出合适的选择。

先说背景：为什么需要 SDD

当你使用 Cursor、Claude Code 或 Copilot 编写代码时，是否习惯直接将一段需求描述丢给 AI，然后等待输出？这种被称为 “Vibe Coding” 的方式，在处理简单功能时或许有效，一旦需求复杂，生成的代码往往似是而非。问题可能不在于模型不够强大，而在于我们提供的上下文信息不足。

SDD 的理念则截然不同：先将需要完成的任务写成一份结构化的规范文档，再让 AI 依据这份文档来生成代码。规范本身也可以由 AI 辅助生成，但过程中的每一步都能进行人工审查和修正。那么，如何高效地组织和管理这个流程呢？Spec Kit 和 OpenSpec 给出了两种不同的答案。

Spec Kit：GitHub 出品，流程严谨

定位

Spec Kit（GitHub Star 28K+）并非一个AI助手，而是一套为你的AI助手“制定规矩”的工具包。它通过向项目中注入一组斜杠命令（slash commands），供 GitHub Copilot、Claude Code、Gemini CLI 等工具调用。其核心思想是 门控流程 —— 每完成一步并经过人工确认后，才能进入下一步。

安装

它基于 Python 生态，推荐使用 uv 安装：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-project

specify init 执行后，斜杠命令会被写入项目的 agent 配置目录（如 .claude/、.github/prompts/ 等），后续不再需要直接使用 specify 命令。

工作流：7 步门控

Constitution → Specify → Clarify → Plan → Tasks → Analyze → Implement

这是一个严格的线性流程，无法跳过或打乱顺序。

• /speckit.constitution — 制定章程：创建 constitution.md 文件，用于明确规定项目的铁律，例如测试覆盖率底线、技术栈约束、编码规范等。AI在后续所有步骤中都会参考此文件，有效减少“上下文漂移”。

• /speckit.specify — 撰写规范：用自然语言描述“要做什么”以及“为什么做”，无需涉及具体技术细节。

• /speckit.clarify — 消除歧义：AI 会基于上一步的规范，提出一系列结构化的澄清问题，覆盖潜在的模糊点。你的答案会被回写到规范的“Clarifications”部分。这一步非常关键，许多后期的返工都源于前期需求不清。

• /speckit.plan — 技术方案：你需要给出大致的技术方向（如选择什么框架、采用何种架构），AI 会据此生成详细的技术方案。

• /speckit.tasks — 任务拆解：AI 将规范和技术方案拆解成一份可执行的任务列表，包含依赖顺序、并行标记（[P]）、目标文件路径以及测试要求。

• /speckit.analyze — 一致性检查：交叉检查规范、方案和任务三者之间是否存在矛盾。它会输出一个“Findings Table”，每个发现都有编号（如A1、C2）。你可以直接说“Fix A1, C2”来让AI修正问题。

• /speckit.implement — 最终实现：基于以上所有产物，开始编写实际代码。

优缺点

优点是流程严谨。每一步都设有人工卡点，clarify 和 analyze 环节能显著减少返工，确保最终产出与预期一致。

缺点是流程较重。仅 specify 阶段就可能生成超过800行的文档，整套8个命令走下来需要投入相当多的耐心和时间。对于日常的、小型的功能迭代而言，这套流程可能显得“杀鸡用牛刀”。

OpenSpec：轻量灵活，为存量代码而生

定位

OpenSpec 的设计出发点有所不同——它假设你的大部分工作是在已有的代码库上进行增量修改，而非从零开始。因此，它的一切都围绕 “变更（Change）” 这个概念来组织。

其最新的 v1.0.0 (The OPSX Release) 是一个重大更新，将早期的3步线性流程重构为10个可以自由组合的 OPSX 命令，不再强制要求顺序执行。

安装

OpenSpec 使用 TypeScript 编写，需要 Node.js 20.19.0+ 环境：

npm install -g @fission-ai/openspec
openspec init
# 或直接指定你想用的AI工具
openspec init --tools claude,cursor

目前它支持多种 AI 工具（Claude Code、Cursor、Windsurf、Copilot 等）。初始化后会在项目中生成对应的 skill 文件，不同工具的斜杠命令语法略有差异：

工具	格式
Claude Code	/opsx:command
Cursor / Windsurf / Copilot	/opsx-command
Trae	/openspec-command-name

核心概念：产物依赖图

理解 OpenSpec 的关键在于它的 产物依赖图。每个变更包含4个核心产物：

proposal (根)
├── specs    (依赖 proposal)
├── design   (依赖 proposal)
└── tasks    (依赖 specs + design)

每个产物都有三种状态：BLOCKED → READY → DONE。AI 通过查询 CLI 获取实时状态，自动判断下一步该做什么。这意味着你可以随时回去修改任何产物，系统会自动更新整个依赖链路的状态。

完整命令（10个）

按使用阶段可分为以下几类：

探索

• /opsx:explore — 在正式启动变更前，用于调研问题、对比方案。此模式具有硬隔离，不会产生任何实际产物或代码变更，纯粹用于思路整理。

规划

• /opsx:new <name> — 创建一个新的变更，在 openspec/changes/<name>/ 目录下搭建好脚手架。支持 --schema 参数指定自定义的产物流程。
• /opsx:ff — Fast-Forward（快进模式），按照依赖顺序一口气生成 proposal、specs、design、tasks 四个产物。适合需求非常明确的场景。
• /opsx:continue — 每次只生成下一个就绪的产物，适合“边想边做”的探索式开发。

  如何选择？ 想清楚了就用 ff，没想清楚就用 continue。

实现

• /opsx:apply — 依据 specs 和 design，逐个实现 tasks.md 中列出的任务。支持 /opsx:apply <name> 指定变更名，实现断点续跑。
• /opsx:verify — 实现完成后运行一致性校验，检查代码是否与规范相符。问题分为三级：CRITICAL / WARNING / SUGGESTION。

归档

• /opsx:sync — 将变更中的增量规范（Delta Specs）合并回主规范目录。此为可选步骤，在归档时也会提示。
• /opsx:archive — 在所有产物和任务完成后，将变更移动到 archive 目录，标志其完成。
• /opsx:bulk-archive — 同时归档多个变更，并自动检测跨变更间的规范冲突。

入门

• /opsx:onboard — 使用你的真实代码库进行一次完整的引导教学，共11个阶段，全程约15分钟。

三种典型工作流

模式	场景	流程
快速功能	需求清晰	new → ff → apply → verify → archive
探索式	需求模糊	explore → new → continue → ... → apply → verify → archive
并行变更	多任务并行	多个 new 创建并行变更，按需切换执行，最后使用 bulk-archive 归档

几个值得注意的设计

变更隔离
OpenSpec 明确区分“当前系统状态”和“变更提案”：

openspec/
├── specs/          ← 系统当前规范（Source of Truth）
├── schemas/        ← 自定义产物工作流
├── config.yaml     ← 项目配置
└── changes/        ← 各个进行中的变更提案
    ├── add-dark-mode/
    ├── fix-login-bug/
    └── archive/    ← 已完成的历史变更

每个功能都在独立的 change 目录中开发，仅在归档时才合并到主规范。这在多人协作时能有效避免互相干扰。相比之下，Spec Kit 直接修改主规范文件，在协作场景下容易产生冲突。

Delta Spec（增量规范）
变更中的规范会使用 ADDED、MODIFIED、REMOVED、RENAMED 等标记来记录增量部分，而非全量覆盖。这让开发者一目了然地看到本次变更的具体内容。

动态指令（v1.0 新增）
AI 收到的指令不再是静态模板，而是由三层动态组装而成：项目上下文（config.yaml）、产物规则、输出模板。AI 在每次操作前都会查询 CLI 以获取最新状态，因此指令总是与项目的实际情况同步。

CLI 命令

除了集成在AI助手里的斜杠命令，OpenSpec 还提供了一套终端 CLI 命令用于管理：	命令	用途
openspec init	初始化项目
openspec status	查看各产物完成状态
openspec list	列出活跃的变更和规范
openspec show <name>	查看特定变更的详情
openspec view	启动交互式状态仪表盘
openspec validate	校验规范文件格式
openspec archive	在终端中归档变更（--yes 可跳过确认）
openspec feedback	提交产品反馈
openspec completion install	安装 Shell 命令自动补全

对比：怎么选

核心差异

维度	Spec Kit	OpenSpec
出品方	GitHub	Fission AI
语言 / 安装	Python / uv	TypeScript / npm
Stars	28K+	22K+
设计思路	严格门控，步步审查	依赖图驱动，灵活迭代
擅长场景	新项目从零开始（Greenfield）	已有代码库增量开发（Brownfield）
命令数量	8 个	10 个
规范体量	较重，单阶段可达 800+ 行	较轻，典型文档约 250 行
流程自由度	线性，不可跳步或回退	非线性，随时可回改任一产物
协作友好度	直接修改主规范，多人协作易冲突	变更隔离，仅在归档时合并，冲突少
Token 消耗	较高	较低
变更追踪	无内置机制	Delta Spec + 归档历史

快速上手命令对照：

Spec Kit：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-project

# 在 AI 助手中：
/speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement

OpenSpec：

npm install -g @fission-ai/openspec
openspec init --tools claude

# 在 AI 助手中：
/opsx:new feature-name → /opsx:ff → /opsx:apply → /opsx:verify → /opsx:archive

选择建议

场景	推荐
启动全新的、对规范严谨性要求极高的项目	Spec Kit
在已有的大型代码库上进行日常功能迭代或修复	OpenSpec
多人协作开发，需要关注冲突管理和并行工作	OpenSpec
合规性、可审计性要求极高的场景（如金融、医疗）	Spec Kit
追求开发速度和迭代灵活性	OpenSpec
需求极其模糊，需要进行深度探索和消歧	Spec Kit

总结

Spec Kit 与 OpenSpec 并非非此即彼的对立关系。实际上，一种高效的组合策略是：在新项目启动阶段，使用 Spec Kit 来严格定义架构和核心规范；当项目进入稳定迭代期后，切换到 OpenSpec 来管理日常的增量变更。这种组合既能确保项目初期的严谨性，又能满足后期快速迭代的需求。

无论选择哪种工具，SDD 的核心价值都在于将开发过程从“模糊的对话”转变为“结构化的协作”。希望这篇对比能帮助你在 云栈社区 的探索之路上，找到适合自己的 AI 辅助开发工作流。