选择SDD工具：OpenSpec 还是 Spec-Kit
在前文《什么是SDD》中我们了解了规范驱动开发的重要性，本文将深入对比两款主流SDD工具——OpenSpec和Spec-Kit，帮助开发者根据自身需求做出选择。
OpenSpec与Spec-Kit概览
OpenSpec简介
OpenSpec 是由Fission AI开发的规格驱动开发(SDD)框架，专门为AI编程助手打造。
项目地址：https://github.com/Fission-AI/OpenSpec
核心特点：
- 轻量级规格层，让人类和AI在写代码前对齐
- 每个变更有独立文件夹，包含提案、规格、设计和任务
- 支持20+种AI助手通过斜杠命令集成
- 灵活迭代，无刚性阶段门控
- 完整的变更生命周期管理
Spec-Kit简介
Spec-Kit 是由GitHub开发的规格驱动开发开源工具包。
项目地址：https://github.com/github/spec-kit
核心特点：
- 将规格文档变为可执行规范，直接生成可工作代码
- 支持多种AI代理：Claude Code、Copilot、Gemini CLI、Codex、Cursor、Windsurf等
- 完整的工作流程：Constitution → Specify → Plan → Tasks → Implement
- 丰富的扩展生态：Jira集成、Azure DevOps集成、代码审查等
- 支持Greenfield和Brownfield项目
安装与配置
OpenSpec安装
前置要求：Node.js 20.19.0或更高版本
初始化项目
禁用遥测（可选）
Spec-Kit安装
前置要求：Python环境（推荐使用uv）
初始化项目
核心功能对比
基础功能
| 功能 | OpenSpec | Spec-Kit |
|---|---|---|
| 实现语言 | Node.js | Python |
| CLI工具 | openspec | specify |
| AI代理支持 | 20+种 | 10+种 |
| 变更结构 | 提案+规格+设计+任务 | Constitution+Specify+Plan+Tasks |
| 状态管理 | 完整生命周期 | 阶段式流程 |
| 扩展生态 | 基础 | 丰富（Jira、Azure DevOps等） |
| 并行执行 | 基础支持 | 工作包模式 |
OpenSpec斜杠命令
| 命令 | 功能 |
|---|---|
/opsx:propose "想法" |
创建新提案 |
/opsx:new |
创建新变更 |
/opsx:continue |
继续变更 |
/opsx:apply |
执行任务 |
/opsx:ff |
快进完成 |
/opsx:verify |
验证变更 |
/opsx:sync |
同步状态 |
/opsx:archive |
归档已完成变更 |
/opsx:bulk-archive |
批量归档 |
/opsx:onboard |
新成员入门 |
Spec-Kit斜杠命令
| 命令 | 功能 |
|---|---|
/speckit.constitution |
建立项目治理原则 |
/speckit.specify |
定义功能需求 |
/speckit.plan |
技术规划 |
/speckit.tasks |
分解任务 |
/speckit.implement |
执行实现 |
/speckit.clarify |
澄清模糊需求 |
/speckit.analyze |
一致性分析 |
/speckit.checklist |
质量检查 |
工作流程对比
OpenSpec工作流
OpenSpec以变更为核心，每个变更有独立的文件夹结构：
变更文件夹结构：
├── proposal.md # 提案描述
├── spec.md # 规格说明
├── design.md # 技术设计
├── tasks.md # 任务清单
└── artifacts/ # 产出物开发循环
1. 提出想法
/opsx:propose "添加用户认证功能"
2. 创建变更
/opsx:new
# 创建变更文件夹
3. 编写规格
编辑 spec.md
4. 技术设计
编辑 design.md
5. 执行任务
/opsx:apply
6. 验证完成
/opsx:verify
7. 归档
/opsx:archiveSpec-Kit工作流
Spec-Kit采用阶段式流程，强调规范文档的可执行性：
工作流程：
Constitution → Specify → Plan → Tasks → Implement开发循环
1. 初始化项目
specify init . --ai claude
2. 建立原则
/speckit.constitution
# 定义项目治理规范
3. 定义规格
/speckit.specify
# 描述要构建的功能
4. 制定计划
/speckit.plan
# 提供技术栈和架构
5. 分解任务
/speckit.tasks
# 生成可执行任务列表
6. 执行实现
/speckit.implement
# 按计划实现功能AI代理支持对比
OpenSpec支持
- Claude Code ✅
- GitHub Copilot ✅
- Gemini CLI ✅
- 以及20+种其他AI助手
Spec-Kit支持
| AI代理 | 支持 | 备注 |
|---|---|---|
| Claude Code | ✅ | |
| GitHub Copilot | ✅ | |
| Gemini CLI | ✅ | |
| Codex CLI | ✅ | 需 --ai-skills 参数 |
| Cursor | ✅ | |
| Windsurf | ✅ | |
| Qoder CLI | ✅ | |
| Kilo Code | ✅ | |
| Generic | ✅ | 需指定 --ai-commands-dir |
Spec-Kit扩展生态
Spec-Kit拥有丰富的扩展和预设：
扩展（Extensions）
| 扩展 | 功能 |
|---|---|
| AI-Driven Engineering (AIDE) | 7步结构化工作流 |
| Jira Integration | 与Jira同步任务 |
| Azure DevOps Integration | 与Azure DevOps同步 |
| Review Extension | 代码审查 |
| Verify Extension | 规格验证 |
| Spec Sync | 检测规格与实现偏差 |
预设（Presets）
| 预设 | 功能 |
|---|---|
| AIDE In-Place Migration | 技术迁移预设 |
| Pirate Speak | 海盗风格输出 |
适用场景对比
选择OpenSpec的场景
- 需要完整变更追踪的项目
- 重视提案→规格→设计→任务流程的团队
- 多AI工具混合使用的环境
- 喜欢灵活迭代而非严格阶段的项目
- 需要频繁变更审查的团队
选择Spec-Kit的场景
- 企业环境，需要Jira/Azure DevOps集成
- 需要代码审查和质量门控
- 重视规格文档可执行性的团队
- 需要技术迁移支持的场景
- 使用Claude Code、Copilot等主流AI代理
总结对比
┌─────────────────────────────────────────────────────────┐
│ SDD工具对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ OpenSpec │ Spec-Kit │
│ ───────── │ ───────── │
│ • Node.js实现 │ • Python实现 │
│ • 变更驱动 │ • 规格可执行 │
│ • 20+ AI助手支持 │ • 10+ AI助手支持 │
│ • 灵活迭代 │ • 阶段式流程 │
│ • 完整变更生命周期 │ • 丰富扩展生态 │
│ │ • 企业集成支持 │
│ │
│ 适合: │ 适合: │
│ • 变更追踪重要 │ • 企业环境 │
│ • 灵活迭代流程 │ • 质量门控 │
│ • 多AI工具混用 │ • 规格验证 │
│ │
└─────────────────────────────────────────────────────────┘最终建议
选择OpenSpec如果：
- 需要完整的提案→规格→设计→任务流程
- 重视变更的历史追踪和审查
- 喜欢灵活迭代的工作方式
- 使用多种AI编程工具
选择Spec-Kit如果：
- 需要与企业工具（Jira、Azure DevOps）集成
- 重视代码审查和质量验证
- 需要规格与实现一致性检查
- 使用Claude Code、Copilot等主流AI代理
可以结合使用：两个工具可以互补——使用OpenSpec进行快速变更探索，使用Spec-Kit进行企业级规范管理。