SDD 与 OpenSpec / Spec Kit

对比对象：

• Fission-AI/OpenSpec
• github/spec-kit

说明：

• 本文基于两个项目截至 2026-04-17 可见的官方 README、仓库结构与公开说明整理。

1. 什么是 SDD

SDD，通常指 Spec-Driven Development，也就是“规范驱动开发”。

它的核心思想不是先写代码、再补文档，而是先把“要做什么、为什么做、做到什么程度算完成”描述清楚，再让实现围绕这些规范展开。

和传统开发相比，SDD 有几个明显差异：

• 规范不是附属品，而是开发主线
  • 需求、场景、约束、验收标准，不再只是开会纪要或聊天记录，而是实际驱动实现的核心材料。
• 先对齐再实现
  • 在编码前，团队和 AI 助手先对“目标”和“边界”达成一致，减少后期返工。
• 规范可以直接驱动 AI
  • 在 AI coding assistant 场景下，spec 不再只是给人看的文档，也是在约束 AI 输出。
• 开发过程可追踪
  • 从 proposal、requirements、design 到 task breakdown，链路更完整，决策更容易回溯。

2. 为什么 SDD 在 AI 编码时代更重要

没有 SDD 时，很多 AI 开发流程实际上是“聊天驱动开发”：

• 需求散落在上下文里
• 实现边界不清晰
• AI 容易补全错误假设
• 多轮对话后，最初目标逐渐漂移

这会带来几个典型问题：

• 需求漂移
  • 同一个功能在不同轮次里被 AI 理解成不同东西。
• 实现不可控
  • AI 可能一次性做太多，也可能漏掉关键约束。
• 难以协作
  • 如果多人或多 Agent 参与，聊天记录很难成为稳定的协作契约。
• 难以复盘
  • 需求为什么这么写、为什么这么设计、任务为什么这样拆，后面很难追踪。

所以，SDD 在 AI 时代的价值，本质上是给 AI 开发加一层 结构化约束：

• 让目标更清晰
• 让实现更可预测
• 让多人协作更稳定
• 让项目积累下来的不是聊天记录，而是可复用的工程资产

3. 一个典型的 SDD 流程

虽然不同工具实现不同，但一个典型的 SDD 流程通常类似这样：

1. 提出变更
   • 明确想解决什么问题、给谁用、预期效果是什么。
2. 编写或生成规范
   • 把需求、场景、边界条件、验收标准结构化下来。
3. 形成设计方案
   • 明确技术实现方向、数据结构、接口、约束。
4. 拆解任务
   • 把工作拆成可以执行和验证的实现步骤。
5. 实施与验证
   • AI 或开发者按规范和任务推进实现。
6. 归档与沉淀
   • 将这次变更的 spec、设计和任务保留下来，形成团队资产。

OpenSpec 和 Spec Kit 都是在做这件事，只是两者做法不一样：

• OpenSpec 更强调“轻量、流畅、快速进入实现”
• Spec Kit 更强调“完整、规范、可治理、可扩展”

4. 两个项目分别在解决什么问题

OpenSpec

OpenSpec 想解决的问题是：

如何在不引入太重流程的前提下，让 AI coding assistant 的开发过程有 spec 约束，而不是完全靠聊天上下文驱动。

它的理念很鲜明：

• fluid not rigid
• iterative not waterfall
• easy not complex
• built for brownfield not just greenfield

它更像是给日常 AI 开发加一套“轻量护栏”。

Spec Kit

Spec Kit 想解决的问题是：

如何把 Spec-Driven Development 做成一套可落地、可扩展、可治理的方法与工具体系。

它不只是一个命令行工具，而是一整套：

• CLI
• templates
• integrations
• presets
• extensions
• workflows

它更像是“把 SDD 工程化”的工具箱。

5. 核心定位差异

6. OpenSpec 的优缺点

优点

• 上手成本低
  • Node 环境下安装直接，进入项目后 openspec init 即可开始。
• 主流程短
  • /opsx:propose -> /opsx:apply -> /opsx:archive，很适合快速迭代。
• 更适合 brownfield
  • 官方明确强调它适合已有项目，不只是新项目。
• 更符合 AI 协作直觉
  • 先提出一个变更，再生成 proposal/spec/design/tasks，然后直接实施，交互阻力较小。
• 仪式感较低
  • 对不想引入太重文档流程的团队更友好。
• 支持多种 AI 工具接入
  • 支持 20+ AI assistants / 25+ tools。

缺点

• 方法论深度不如 Spec Kit 完整
  • 在治理原则、模板体系、流程扩展等方面，公开材料里 Spec Kit 更系统。
• 容易依赖团队自觉
  • 因为强调灵活，团队如果没有纪律，spec 可能又退化成“半结构化描述”。
• 不那么偏向重治理场景
  • 对于需要严格留痕、清晰阶段边界、强模板约束的组织，默认流程偏轻。
• 复杂项目的 artifact 粒度相对没那么重
  • 当你需要 research、data model、contracts 等细分输出时，OpenSpec 默认表达没有 Spec Kit 那么体系化。

7. Spec Kit 的优缺点

优点

• SDD 方法论更完整
  • 从 constitution 到 specify、plan、tasks，链路清晰。
• 治理能力更强
  • 把工程原则前置，适合多人协作和高质量要求场景。
• 扩展能力强
  • 仓库里有 extensions、presets、integrations、templates 等结构。
• AI agent 集成覆盖广
  • 支持 30+ AI coding agents。
• 更适合团队沉淀标准流程
  • 不只是解决“怎么让 AI 帮我写代码”，更在解决“团队怎么稳定地用 spec 驱动开发”。
• 文档层次更完整
  • 对流程、阶段、扩展和社区资源的说明更丰富。

缺点

• 上手更重
  • 依赖 Python 3.11+、uv、Git，相比 OpenSpec 接入成本更高。
• 流程更长
  • constitution -> specify -> plan -> tasks -> implement，本身就更正式。
• 文档和 artifact 更多
  • 这提高了治理能力，但也提高了维护成本。
• 对小项目可能偏重
  • 如果只是个人开发或快速试错，Spec Kit 可能会显得过度设计。
• 团队执行门槛更高
  • 规范越完整，越需要团队真正愿意维护这些规范。

8. 使用流程

在 AI coding 场景里，可以把这两个项目理解成“给 agent 提供结构化开发流程”的工具：

• OpenSpec / Spec Kit：负责定义流程、工件、命令约定
• Codex / OpenCode：负责读代码、改代码、执行命令、推进实现

也就是说，它们不是替代关系，而是组合关系。

8.1 OpenSpec 使用流程

安装

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

要求：

• Node.js 20.19.0+

初始化

cd your-project
openspec init
openspec update

提出变更并生成 spec

/opsx:propose 

通常会生成：

• proposal.md
• specs/
• design.md
• tasks.md

按任务实施

/opsx:apply

完成后归档

/opsx:archive

可选扩展命令

如果要更完整流程，还可以使用：

• /opsx:new
• /opsx:continue
• /opsx:ff
• /opsx:verify
• /opsx:sync
• /opsx:bulk-archive
• /opsx:onboard

适用场景

• 已有项目增量迭代
• 个人开发者配合 AI 助手
• 小团队快速推进功能
• 希望引入 spec，但不想流程太重

8.2 Spec Kit 使用流程

安装

推荐安装：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

一次性使用：

uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init . --ai copilot

要求：

• Python 3.11+
• uv
• Git
• 支持的 AI coding agent

初始化

specify init .

或：

specify init --here --ai codex --ai-skills

建立治理原则

/speckit.constitution

这一阶段主要定义项目的工程原则，例如：

• 质量要求
• 测试要求
• UX 一致性要求
• 性能要求
• 技术约束

生成功能规范

/speckit.specify

重点是把“做什么”和“为什么做”说清楚。

生成技术计划

/speckit.plan

这一阶段常见输出包括：

• plan.md
• research.md
• data-model.md
• contracts/
• quickstart.md

生成任务拆解

/speckit.tasks

通常输出 tasks.md，包含：

• 按用户故事组织的任务
• 依赖关系
• 并行标记
• 实现提示

进入实施与验证

后续由开发者或 AI 按 spec、plan、tasks 推进开发。

适用场景

• 从 0 到 1 的项目
• 多人协作项目
• 需要明确工程原则和决策边界的团队
• 想把 SDD 作为正式开发制度落地的团队

8.3 在 AI Coding 中怎么用

用两个常见 agent 举例：

• Codex
• OpenCode

思路都一样：

1. 先在仓库里初始化 SDD 工具
2. 再启动 AI coding agent
3. 先让 agent 生成或完善 spec
4. 再让 agent 按 spec 实现
5. 最后回到验证、归档、沉淀

一个通用原则

不要一上来就对 agent 说“帮我把这个功能做完”。

在 SDD 场景里，更稳定的方式是分成两段：

1. spec 阶段
   • 明确要做什么、边界是什么、验收标准是什么
2. implementation 阶段
   • 基于已有 spec 去实现、测试、修正

这样做的好处是：

• agent 不容易跑偏
• 需求变更时更容易同步
• 多人或多 agent 协作时更容易对齐

示例一：Codex + OpenSpec

第一步：初始化 OpenSpec

cd your-project
openspec init
openspec update

openspec update 的作用是刷新 agent instructions 和命令绑定。

第二步：启动 Codex

cd your-project
codex

第一次运行时，按官方说明会提示你登录 ChatGPT 账号或配置 API key。

第三步：先做 spec，不急着写代码

进入 Codex 后，先告诉它：

先不要实现。请先基于 OpenSpec 工作流为这个需求生成 proposal、spec、design 和 tasks。
需求：为后台管理系统增加批量导出订单的能力，支持按时间范围和状态筛选。
完成 spec 后，先总结你的设计取舍，再等我确认。

如果你所在的 agent 环境已经加载了 OpenSpec 命令，也可以直接使用：

/opsx:propose 为后台管理系统增加批量导出订单的能力，支持按时间范围和状态筛选

也可以直接使用 OpenSpec 生成好的 Skill：

$openspec-propose 为后台管理系统增加批量导出订单的能力，支持按时间范围和状态筛选

第四步：审阅 spec，再让 Codex 实现

确认 spec 后，再给 Codex 明确指令：

现在根据已生成的 OpenSpec artifacts 开始实现。
要求：
- 严格按 tasks 顺序推进
- 每完成一组任务就运行相关测试
- 如果发现 spec 与现有代码冲突，先停下来说明冲突点

如果你的 OpenSpec 配置了实现命令，也可以使用：

/opsx:apply

也可以直接使用 OpenSpec 生成好的 Skill：

$openspec-apply-change

第五步：收尾和归档

功能完成后，可以让 Codex：

• 对照 tasks 检查是否全部完成
• 对照 spec 检查是否有偏差
• 补充测试与文档
• 执行归档

例如：

请根据当前变更，检查 spec、design、tasks 和实现是否一致；如果一致，再执行归档建议。

示例二：Codex + Spec Kit

Spec Kit 更适合在 Codex 里跑一个更正式的阶段化流程。

先初始化：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
cd your-project
specify init . --ai codex

然后启动 Codex：

codex

推荐交互方式：

阶段 1：先建立 constitution

/speckit.constitution

可以补一句：

我们的项目原则是：
- 默认先测试后实现
- 接口变更必须更新文档
- 新功能必须提供最小可验证验收路径

阶段 2：生成功能规范

/speckit.specify

你可以这样描述需求：

功能：增加订单批量导出
用户：运营人员
目标：按筛选条件导出 CSV
约束：导出任务不能阻塞主请求线程；导出结果保留 24 小时

阶段 3：生成技术计划和任务

/speckit.plan
/speckit.tasks

这一步之后，再要求 Codex：

先总结 plan 和 tasks，再指出其中的高风险点、依赖项和需要我确认的决策。

阶段 4：再进入实现

/speckit.implement

如果你不想一次性全自动，也可以直接说：

根据 spec.md、plan.md 和 tasks.md 实现第一阶段任务；每完成一步都给出变更摘要和验证结果。

示例三：OpenCode + OpenSpec

根据 OpenCode README，基本用法是：

opencode

也可以指定工作目录：

opencode -c /path/to/project

OpenCode 的优势在于：

• 终端内交互直接
• 支持自定义 commands
• 支持非交互模式 -p

一个实用流程是：

第一步：先初始化 OpenSpec

cd your-project
openspec init
openspec update

第二步：打开 OpenCode

opencode -c your-project

第三步：让 OpenCode 先产出 spec

在会话里直接输入：

先不要编码。请基于 OpenSpec 流程，为“订单批量导出”生成功能 proposal、spec、design、tasks，并指出还缺哪些业务约束。

如果你已经把常用流程做成 OpenCode custom command，也可以把“生成 spec”“按 spec 实现”“验证 spec 与实现一致性”做成项目命令，之后通过 Ctrl+K 直接调用。

第四步：按 spec 实现

现在开始实现，但要求：
- 只按已确认的 tasks 执行
- 不要额外扩展需求
- 每次完成后告诉我改了哪些文件、跑了哪些验证

OpenCode 也支持非交互模式，所以你可以拿它做脚本化流程，例如：

opencode -c your-project -p "阅读当前 OpenSpec artifacts，总结未完成任务和实现风险"

这个模式适合做：

• 每日状态检查
• spec 完整性检查
• 任务执行前的上下文预热

示例四：OpenCode + Spec Kit

Spec Kit 和 OpenCode 的组合更像“本地终端版的阶段化 SDD 流程”。

初始化：

cd your-project
specify init . --ai opencode

然后启动：

opencode -c your-project

推荐按下面顺序推进：

1. /speckit.constitution
2. /speckit.specify
3. /speckit.plan
4. /speckit.tasks
5. 实现或 /speckit.implement

如果你希望 OpenCode 更高效，可以结合它的 custom command 机制，把常见命令包装成项目命令，例如：

• project:sdd-specify
• project:sdd-plan
• project:sdd-tasks
• project:sdd-verify

这样做的价值是：

• 新成员更容易按统一流程执行
• 降低 prompt 漂移
• 常见动作可以复用

Quick Start

如果你只想先跑通一次，可以直接按这个顺序：

OpenSpec + Codex

npm install -g @fission-ai/openspec@latest
npm i -g @openai/codex
cd your-project
openspec init
openspec update
codex

然后在 Codex 中输入：

先不要写代码。请按 OpenSpec 流程为“给订单列表增加批量导出 CSV”生成 spec、design 和 tasks。等我确认后再实现。

8.4 在 AI Coding 中的实践建议

先 spec，后 implementation

这是 SDD 在 AI coding 里最重要的一条。
如果一开始就让 agent 直接动手，通常更容易出现范围漂移。

一次只推进一个阶段

不要把“写 spec、做 plan、拆 tasks、写代码、补测试”塞进同一条 prompt。
拆阶段之后，agent 更稳定，审查也更容易。

把验收标准写进 spec

尤其是：

• 输入输出要求
• 失败场景
• 性能约束
• 数据一致性要求

这比单纯说“做个导出功能”有效得多。

把 agent 当执行者，不要当需求拥有者

需求边界、取舍原则、验收标准，最好还是由你或团队明确给出。
agent 更适合在这些边界内执行，而不是替你决定目标。

9. 如何选

选 OpenSpec，如果你更看重

• 快速落地
• 少流程阻力
• 在已有项目中自然接入
• 把 spec 当成 AI 协作护栏，而不是正式治理体系

选 Spec Kit，如果你更看重

• 团队统一规范
• 从需求到实现的完整留痕
• 强治理、强模板化、强扩展能力
• 把 SDD 作为正式工程方法推广

一个务实判断

如果你们团队还没有稳定采用 SDD，通常 OpenSpec 更容易先落地。
如果你们已经接受“先规范、后计划、再实施”的节奏，并愿意维护更多 artifact，通常 Spec Kit 的长期收益更大。

10. 总结

从 SDD 的角度看，这两个项目不是简单的“谁更强”，而是代表了两种不同落地方向：

• OpenSpec：把 SDD 做轻，优先解决“怎么尽快在 AI 编码里用起来”
• Spec Kit：把 SDD 做全，优先解决“怎么把 spec 驱动开发变成稳定工程体系”

如果你是个人开发者或小团队，且项目已经存在，OpenSpec 往往更顺手。
如果你是多人协作团队，想把 SDD 正式纳入研发流程，Spec Kit 通常更合适。

11. 参考来源

• OpenSpec GitHub README: https://github.com/Fission-AI/OpenSpec/
• Spec Kit GitHub README: https://github.com/github/spec-kit