先说背景：为什么需要 SDD（规范驱动开发）
在使用 Cursor、Claude Code 或 Copilot 进行 AI 辅助编程时，许多开发者习惯于直接向 AI 工具抛出一段简单的需求描述，然后静待代码生成。这种被称为 "Vibe Coding" 的编程方式在应对小型功能时或许尚可，然而一旦需求变得复杂，生成的代码往往逻辑含混、似是而非 —— 问题的根源并非模型能力不足，而是我们未能提供充分的上下文与结构性指引。
SDD（规范驱动开发）的理念非常朴素：先将待实现的需求转化为结构化的规范文档，再让 AI 严格依据这套规范来编写代码。规范本身同样可由 AI 辅助生成，但每个关键节点都允许开发者审查与修正。针对 "如何组织这一流程"，目前两个主流框架给出了截然不同的解答。
Spec Kit：GitHub 官方出品，流程严谨且门控严格
产品定位
Spec Kit（28K+ Star）并非简单的 AI 辅助工具，而是一套为 AI 助手 "立规矩" 的方法工具包。它通过向项目中注入一组 slash commands，借助 GitHub Copilot、Claude Code、Gemini CLI 等主流 AI 编程工具进行调用。其核心思想是门控流程 —— 每个阶段完成后，必须经过人工确认，才能进入下一步骤。
安装方式
基于 Python 生态，通过 uv 即可快速安装：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-project
specify init 执行完毕后，slash commands 会被自动写入项目的 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 — 任务拆解
将规范与方案拆解为可执行的具体任务列表，附带依赖顺序、并行标记（[P]）、文件路径以及测试要求。
/speckit.analyze — 一致性检查
交叉验证规范、方案与任务之间是否存在矛盾。输出一份 Findings Table，每行带有唯一编号（如 A1、C2），开发者可直接指示 "Fix A1, C2" 让 AI 进行针对性修正。
/speckit.implement — 代码实现
基于以上所有阶段性产物，正式进入代码编写环节。
优势与局限
最大优势在于严谨性。每个步骤均设置人工卡点，clarify 与 analyze 环节能够显著降低返工率。
相应的代价是流程较重。仅 specify 阶段就可能产出 800 多行文档，整套流程包含 8 个 slash command，完整执行一遍需要投入相当耐心。对于日常的小功能迭代而言，略显繁重。
OpenSpec：轻量灵活，专为存量代码的增量变更设计
产品定位
OpenSpec 的设计出发点与 Spec Kit 有所不同 —— 它假设开发者大部分时间是在已有代码库上进行增量变更，而非从零开始搭建项目。因此，其核心概念围绕 "变更（Change）" 来组织所有工作流。
v1.0.0（The OPSX Release）是一次重大版本升级，将早期的 3 步线性流程重构为 10 个可自由组合的 OPSX 命令，不再强制要求按固定顺序执行。
安装方式
采用 TypeScript 编写，需要 Node.js 20.19.0+ 环境：
npm install -g @fission-ai/openspec
openspec init
# 或直接指定目标工具
openspec init --tools claude,cursor
目前支持多种主流 AI 编程工具（Claude Code、Cursor、Windsurf、Gemini CLI、Copilot、Cline、Amazon Q 等）。初始化后，系统会在项目中生成对应的 skill 文件，不同工具的命令语法略有差异：
| 工具 | 命令格式 |
|---|---|
| Claude Code | /opsx:command |
| Cursor / Windsurf / Copilot | /opsx-command |
| Trae | /openspec-command-name |
核心概念：产物依赖图
理解 OpenSpec 的关键在于其产物依赖图（Artifact Graph）。每个变更包含 4 个核心产物：
proposal (根节点)
├── specs (依赖 proposal)
├── design (依赖 proposal)
└── tasks (依赖 specs + design)
每个产物拥有三种状态：BLOCKED → READY → DONE。AI 通过查询 CLI 获取实时状态，自动判断下一步该执行什么操作。这意味着开发者可以随时回退修改任意产物，系统会自动更新整个状态链路。
完整命令（共 10 个）
按使用阶段划分：
探索阶段
/opsx:explore — 在正式启动前调研问题、对比不同方案。该模式具有硬隔离机制，不会产生任何产物或代码变更，纯粹用于理清思路。
规划阶段
/opsx:new — 创建一个新的变更，在 openspec/changes/ 下自动搭建好脚手架。支持 --schema 参数自定义产物流程。
/opsx:ff — Fast-Forward，按照依赖顺序一次性生成 proposal、specs、design、tasks 四个产物。适用于需求已经明确的场景。
/opsx:continue — 每次只生成下一个状态为就绪的产物，适合边思考边推进的探索式开发。
实现阶段
/opsx:apply — 根据 specs 和 design 逐个实现 tasks.md 中的任务。支持 /opsx:apply 指定变更名称，实现断点续跑。
/opsx:verify — 实现完成后运行校验机制，检查代码与规范是否保持一致。问题分为三个等级：CRITICAL / WARNING / SUGGESTION。
归档阶段
/opsx:sync — 将变更中的 delta specs 合并回主规范目录。此为可选步骤，执行 archive 时也会提示同步。
/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/← 系统当前状态（权威数据源）
├── schemas/← 自定义产物工作流
├── config.yaml ← 项目配置
└── changes/← 各个变更提案
├── add-dark-mode/
├── fix-login-bug/
└── archive/← 历史变更归档
每个功能在独立的 change 目录中开发，仅在 archive 阶段才合并至主规范。多人并行开发时不会相互干扰。相比之下，Spec Kit 直接修改主规范文件，协作时容易产生冲突。
Delta Spec 增量规范
变更中的规范采用 ADDED、MODIFIED、REMOVED、RENAMED 标记增量内容，而非全量覆盖。开发人员只需一眼即可了解本次变更的具体内容。
动态指令机制（v1.0 新增）
AI 获取的指令不再是静态模板，而是从三个层面动态拼装而成：项目上下文（config.yaml）、产物规则、输出模板。AI 每次操作前都会查询 CLI 获取最新状态，因此指令始终与项目实际情况保持同步。
CLI 命令一览
除 AI 助手中的 slash commands 外，终端同样提供一组实用的 CLI 命令：
| 命令 | 用途说明 |
|---|---|
openspec init |
初始化项目 |
openspec status |
查看当前产物完成状态 |
openspec list |
列出所有活跃变更与规范 |
openspec show |
查看指定变更的详细信息 |
openspec view |
启动交互式仪表盘 |
openspec validate |
校验规范格式是否正确 |
openspec archive |
终端归档操作（--yes 跳过确认） |
openspec feedback |
提交使用反馈 |
openspec completion install |
安装 Shell 命令补全 |
对比分析：如何根据实际需求选择
核心差异对照
| 对比维度 | Spec Kit | OpenSpec |
|---|---|---|
| 出品方 | GitHub | Fission AI |
| 语言 / 安装方式 | Python / uv |
TypeScript / npm |
| GitHub Stars | 28K+ | 22K+ |
| 设计哲学 | 严格门控，步步审查 | 依赖图驱动，灵活迭代 |
| 擅长场景 | 新项目从零起步（Greenfield） | 已有代码库增量开发（Brownfield） |
| 命令数量 | 8 个 | 10 个 |
| 规范文档体量 | 较重，单阶段可达 800+ 行 | 较轻，文档约 250 行 |
| 流程自由度 | 线性模式，不可跳跃步骤 | 非线性模式，随时可回退修改 |
| 协作友好度 | 直接修改主规范，多人易冲突 | 变更隔离，archive 时统一合并 |
| 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 进行高效的增量变更管理，从而兼顾前期规范性与后期灵活性。
