Spec-Kit vs OpenSpec：规范驱动开发工具深度对比
两大主流 SDD 工具全方位对比，帮你选择最适合的工作流
目录
- 1. 引言
- 2. 项目背景与定位
- 3. 设计哲学对比
- 4. 核心工作流对比
- 5. 命令体系对比
- 6. 产物与文档结构对比
- 7. 项目目录结构对比
- 8. AI 工具生态对比
- 9. 安装与技术栈对比
- 10. 配置与定制能力对比
- 11. 质量保障机制对比
- 12. 团队协作能力对比
- 13. CI/CD 集成对比
- 14. 学习曲线与上手体验
- 15. 完整工作流对比演示
- 16. 优劣势总结
- 17. 选择指南：场景化推荐
- 18. 能否混用？
- 19. 总结
1. 引言
随着 AI 编码助手的普及，规范驱动开发（Spec-Driven Development，SDD） 正在成为一种新的开发范式。SDD 的核心理念是：在写代码之前，先让人类和 AI 对"要做什么"达成一致。
目前 SDD 领域有两个主流工具：
- Spec-Kit — GitHub 官方开源，2025 年发布
- OpenSpec — Fission AI 开源，2025 年发布
两者都致力于解决"AI 直接写代码导致需求偏离"的问题，但在设计理念、工作流程和目标用户上有显著差异。
本文将从使用者的视角，对两者进行全方位对比，帮你做出选择。
2. 项目背景与定位
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 开发方 | GitHub | Fission AI |
| 开源协议 | MIT | MIT |
| 仓库 | github.com/github/spec-kit | github.com/Fission-AI/OpenSpec |
| 定位 | 重量级、全流程 | 轻量级、灵活迭代 |
| 核心隐喻 | "宪法"——严格约束 | "流动"——自由迭代 |
| 目标用户 | 追求规范的团队/中大型项目 | 追求灵活的个人/团队 |
| 成熟度 | 2025 年发布，社区活跃 | 2025 年发布，快速迭代 |
定位差异的本质
Spec-Kit 的思路是：SDD 需要严格的阶段管理，就像立法一样——先立宪，再按宪法治国。每一阶段都有明确的入口和出口，确保不会跳过关键步骤。
OpenSpec 的思路是：SDD 应该是轻量的、流动的。开发者不需要被强制走固定流程，而是在需要时才引入规范。核心三步（Propose → Apply → Archive）就够用，想要更多控制可以按需扩展。
3. 设计哲学对比
Spec-Kit：严格阶段制
宪法 → 规格 → 方案 → 任务 → 实现
（1） （2） （3） （4） （5）
- 瀑布式推进：每个阶段有明确的输入/输出
- 宪法优先：所有后续产出必须遵循"宪法"
- 变更路径：改规格 → 重走流程 → 代码同步更新
- 核心理念：约束带来一致性
OpenSpec：流动迭代制
Propose → Apply → Archive
（核心三步，按需扩展）
- 灵活迭代：随时更新任何产物，没有阶段关卡
- 精简优先：核心三步就能完成开发
- 按需深入：需要更多控制时才切换到 Expanded Profile
- 核心理念：流动优于僵化
哲学对比总结
| 哲学维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 流程 | 严格阶段制 | 灵活流动制 |
| 约束 | 宪法强制约束 | 默认无强制约束 |
| 迭代 | 变更需重走流程 | 随时修改任何产物 |
| 最小单元 | 5 步 | 3 步 |
| 核心信念 | "没有规矩不成方圆" | "简单是终极的复杂" |
4. 核心工作流对比
Spec-Kit 工作流
┌──────────────────────────────────────────────────────┐
│ Spec-Kit 工作流 │
│ │
│ /speckit.constitution ──→ 制定项目宪法 │
│ │ │
│ ▼ │
│ /speckit.specify ──→ 编写功能规格 │
│ │ │
│ ▼ │
│ /speckit.clarify ──→ 澄清需求（可选） │
│ │ │
│ ▼ │
│ /speckit.plan ──→ 生成技术方案 │
│ │ │
│ ▼ │
│ /speckit.tasks ──→ 拆分任务清单 │
│ │ │
│ ▼ │
│ /speckit.analyze ──→ 一致性分析（可选） │
│ │ │
│ ▼ │
│ /speckit.implement ──→ 执行开发实现 │
│ │ │
│ ▼ │
│ /speckit.checklist ──→ 质量检查（可选） │
└──────────────────────────────────────────────────────┘
OpenSpec 工作流
┌──────────────────────────────────────────────────────┐
│ OpenSpec 核心工作流（Core Profile） │
│ │
│ /opsx:explore ──→ 探索需求（可选） │
│ │ │
│ ▼ │
│ /opsx:propose ──→ 一步创建所有产物 │
│ │ │
│ ▼ │
│ /opsx:apply ──→ 执行任务 │
│ │ │
│ ▼ │
│ /opsx:archive ──→ 归档变更 │
└──────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────┐
│ OpenSpec 扩展工作流（Expanded Profile） │
│ │
│ /opsx:explore → /opsx:new → /opsx:continue │
│ → /opsx:ff → /opsx:apply → /opsx:verify │
│ → /opsx:sync → /opsx:archive │
└──────────────────────────────────────────────────────┘
工作流对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 必经步骤 | 5 步（宪法→规格→方案→任务→实现） | 3 步（Propose→Apply→Archive） |
| 可选步骤 | 3 个（clarify/analyze/checklist） | 5+ 个（explore/new/continue/ff/verify/sync 等） |
| 最小路径 | 5 步 | 3 步 |
| 能否跳步 | 不建议跳步，严格顺序 | 可以跳步，灵活选择 |
| 需求变更 | 更新规格 → 重走 plan/tasks/implement | 直接修改任何产物 → 继续 apply |
| 产物审查 | 每步之间可审查（但流程线性） | 逐步推进时每步可审查（continue） |
5. 命令体系对比
Spec-Kit 命令
| 命令 | 阶段 | 说明 |
|---|---|---|
/speckit.constitution |
初始化 | 制定项目宪法 |
/speckit.specify |
规划 | 编写功能规格 |
/speckit.clarify |
规划（可选） | 需求澄清 |
/speckit.plan |
规划 | 生成技术方案 |
/speckit.tasks |
规划 | 拆分任务清单 |
/speckit.implement |
实现 | 执行开发 |
/speckit.analyze |
验证（可选） | 一致性分析 |
/speckit.checklist |
验证（可选） | 质量检查表 |
命令格式：/speckit.<command>（点分隔）
OpenSpec 命令
| 命令 | 阶段 | 说明 |
|---|---|---|
/opsx:explore |
探索 | 需求探索（只读） |
/opsx:propose |
规划 | 一步创建所有产物 |
/opsx:new |
规划 | 创建变更框架 |
/opsx:continue |
规划 | 逐步生成产物 |
/opsx:ff |
规划 | 快进生成所有产物 |
/opsx:apply |
实现 | 执行任务 |
/opsx:verify |
验证 | 代码一致性验证 |
/opsx:sync |
同步 | 合并 Delta 规范 |
/opsx:archive |
归档 | 归档变更 |
/opsx:bulk-archive |
归档 | 批量归档 |
/opsx:onboard |
学习 | 交互式入门引导 |
命令格式：/opsx:<command>（冒号分隔，Cursor/Copilot 用连字符 /opsx-<command>）
命令对比分析
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 命令数量 | 8 个 | 11 个 |
| 规划方式 | 分步执行（5 个命令） | 灵活选择（propose/ff 一步到位，或 continue 逐步推进） |
| 一步到位 | 无，必须按顺序走完 | 有，/opsx:propose 或 /opsx:ff |
| 命令格式 | 统一点分隔 | 按工具分（冒号/连字符） |
| CLI 配套 | specify CLI（Python） |
openspec CLI（Node.js），功能更丰富 |
6. 产物与文档结构对比
Spec-Kit 产物
Spec-Kit 的产物围绕功能编号组织，每个功能编号下包含多个文件：
specs/001-task-management/
├── spec.md # 功能规格（用户故事 + FR + SC）
├── plan.md # 技术实现方案
├── data-model.md # 数据模型设计
├── quickstart.md # 快速上手指南
├── tasks.md # 任务清单
└── contracts/
└── api-spec.json # API 接口契约
加上项目级的宪法文件：
.specify/memory/constitution.md # 项目宪法
OpenSpec 产物
OpenSpec 的产物围绕变更（Change） 组织，每个变更有四类核心产物：
openspec/changes/add-dark-mode/
├── proposal.md # 提案（为什么做 + 做什么 + 验收标准）
├── specs/
│ └── ui/spec.md # 规范（需求 + 验收场景）
├── design.md # 技术设计
└── tasks.md # 任务清单
加上项目级的规范库：
openspec/specs/ # 主规范库（归档时从 Delta 合并）
产物对比
| 产物维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 项目级约束 | constitution.md（宪法） | 无（依赖规范库） |
| 需求文档 | spec.md（用户故事 + FR + SC） | specs/（需求 + 验收场景） |
| 技术方案 | plan.md + data-model.md + quickstart.md | design.md |
| 任务清单 | tasks.md | tasks.md |
| API 契约 | contracts/api-spec.json | 无独立文件 |
| 验证报告 | 无自动生成 | verify 后生成报告 |
| 增量规范 | 无 | Delta 规范（增量记录变化） |
| 产物粒度 | 更细（plan/data-model/quickstart/contracts 分离） | 更粗（design.md 统一） |
关键差异：宪法 vs 无宪法
Spec-Kit 的宪法是最重要的差异化产物。它强制所有后续 AI 产出遵循统一规则，这在团队协作中非常有价值——避免了不同开发者让 AI 产出风格不一致的代码。
OpenSpec 没有强制的宪法机制，但可以通过全局规范库（openspec/specs/）实现类似效果。
7. 项目目录结构对比
Spec-Kit
project/
├── .specify/
│ ├── memory/
│ │ └── constitution.md # 项目宪法
│ ├── scripts/ # 辅助脚本
│ │ ├── check-prerequisites.sh
│ │ ├── common.sh
│ │ ├── create-new-feature.sh
│ │ ├── setup-plan.sh
│ │ └── update-agent-context.sh
│ ├── specs/
│ │ └── 001-task-management/ # 按编号组织
│ │ ├── spec.md
│ │ ├── plan.md
│ │ ├── data-model.md
│ │ ├── quickstart.md
│ │ ├── tasks.md
│ │ └── contracts/
│ └── templates/ # 文档模板
├── CLAUDE.md # AI 助手上下文
└── src/
OpenSpec
project/
├── openspec/
│ ├── specs/ # 主规范库
│ │ ├── ui/spec.md
│ │ ├── api/spec.md
│ │ └── data-model/spec.md
│ ├── changes/ # 变更目录
│ │ ├── add-dark-mode/ # 活跃变更
│ │ │ ├── .openspec.yaml # 变更元数据
│ │ │ ├── proposal.md
│ │ │ ├── specs/ui/spec.md # Delta 规范
│ │ │ ├── design.md
│ │ │ └── tasks.md
│ │ └── archive/ # 归档目录
│ │ └── 2026-03-10-add-dark-mode/
│ ├── schemas/ # 自定义 Schema
│ └── config.yaml # 项目配置
├── .claude/skills/ # AI 技能
└── src/
结构对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 组织方式 | 按功能编号（001-xxx） | 按变更名称（add-dark-mode） |
| 归档机制 | 无内置归档 | 有归档目录（archive/） |
| 配置文件 | 无独立配置文件 | config.yaml + .openspec.yaml |
| 规范库 | 无独立主规范库 | specs/ 作为单一事实来源 |
| 增量变更 | 无 Delta 机制 | Delta 规范增量记录 |
| 模板 | templates/ 目录 | Schema 模板系统 |
8. AI 工具生态对比
支持的 AI 工具
| AI 工具 | Spec-Kit | OpenSpec |
|---|---|---|
| Claude Code | ✅ | ✅ |
| GitHub Copilot | ✅ | ✅ |
| Cursor | ✅ | ✅ |
| Windsurf | ✅ | ✅ |
| Gemini CLI | ✅ | ✅ |
| Qwen Code | ✅ | ✅ |
| CodeBuddy | ✅ | ✅ |
| Codex CLI | ✅ | ✅ |
| Roo Code | ✅ | ✅ |
| Kilo Code | ✅ | ✅ |
| Auggie | ✅ | ✅ |
| Cline | ❌ | ✅ |
| Trae | ❌ | ✅ |
| Lingma | ❌ | ✅ |
| Kimi | ❌ | ✅ |
| Crush | ❌ | ✅ |
| ForgeCode | ❌ | ✅ |
| Amazon Q | ⚠️（部分） | ✅ |
支持数量：Spec-Kit ~11 个 | OpenSpec ~20+
命令格式差异
| 工具类型 | Spec-Kit | OpenSpec |
|---|---|---|
| 所有工具 | /speckit.<command> |
因工具而异 |
| Claude Code | /speckit.specify |
/opsx:propose |
| Cursor/Copilot | /speckit.specify |
/opsx-propose |
| Trae | 不支持 | /openspec-propose |
Spec-Kit 的命令格式统一，学习成本低；OpenSpec 的格式因工具而异，但更符合各工具的原生习惯。
9. 安装与技术栈对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 运行时 | Python 3.11+ | Node.js 20+ |
| 包管理器 | uv（Python） | npm（Node.js） |
| 安装命令 | uv tool install specify-cli --from git+... |
npm install -g @fission-ai/openspec@latest |
| 安装复杂度 | 较高（需要 uv + Python + GitHub Token） | 较低（npm 一键安装） |
| GitHub 依赖 | 需要 GitHub Token 下载模板 | 不需要 |
| 国内镜像 | 可配置 pip 镜像 | 可配置 npm 镜像 |
| 中文版 | 有（specify-cn） | 有（中文文档完善） |
安装体验对比
Spec-Kit 安装步骤：
- 安装 Python 3.11+
- 安装 uv
- 安装 specify-cli
- 配置 GitHub Token
- 可能需要手动配置 PATH
- 运行
specify check验证
OpenSpec 安装步骤：
- 确保 Node.js 20+
npm install -g @fission-ai/openspec@latest- 完成
OpenSpec 的安装明显更简单，特别是对前端开发者而言。
10. 配置与定制能力对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 配置文件 | 无独立配置文件 | config.yaml |
| 配置层级 | 无 | 项目级 > 用户级 > 默认 |
| 工作流档案 | 无（固定工作流） | Core / Expanded 两种档案 |
| 自定义 Schema | 不支持 | 支持（创建/复制/定制 Schema） |
| 自定义产物 | 不支持 | 支持（自定义 Schema 中定义产物） |
| 投递模式 | 不支持 | Skills / Commands / Both |
| CLI 配置 | 有限（specify init 参数） |
丰富（config 子命令完整） |
| 环境变量 | GITHUB_TOKEN | OPENSPEC_TELEMETRY, DO_NOT_TRACK, OPENSPEC_CONCURRENCY, NO_COLOR |
关键差异：Schema 系统
OpenSpec 的 Schema 系统 是 Spec-Kit 没有的重要特性。它允许你：
- 自定义工作流的产物类型和依赖关系
- 创建精简工作流（如只有 proposal + tasks）
- 基于内置 Schema 定制副本
- 在项目级和用户级之间共享 Schema
这意味着 OpenSpec 的工作流是可编程的，而 Spec-Kit 的工作流是固定的。
11. 质量保障机制对比
| 机制 | Spec-Kit | OpenSpec |
|---|---|---|
| 需求澄清 | /speckit.clarify — AI 主动提问 |
/opsx:explore — 自由探索 |
| 一致性分析 | /speckit.analyze — 跨文档检查 |
/opsx:verify — 三维度验证 |
| 质量检查表 | /speckit.checklist — 需求覆盖检查 |
无独立命令（verify 包含） |
| 宪法约束 | 有——强制所有产出合规 | 无——依赖规范库 |
| 验证报告 | 无自动生成 | 有——CRITICAL/WARNING/SUGGESTION |
质量保障理念差异
Spec-Kit 侧重预防：
- 宪法在源头约束 AI 的产出
- Clarify 在规划阶段消除歧义
- Analyze 在实现之前检查一致性
- Checklist 验证需求覆盖度
OpenSpec 侧重验证：
- Verify 在实现之后检查代码与规范的一致性
- 三维度（完整性/正确性/一致性）全面检查
- 问题分三级（CRITICAL/WARNING/SUGGESTION）
两种方式各有优势：预防减少返工，验证确保质量。
12. 团队协作能力对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 规范共享 | 按功能编号组织，无归档 | 主规范库 + Delta 规范 + 归档 |
| 并行开发 | 不明确支持 | 支持多变更并行 |
| 冲突检测 | 无 | bulk-archive 自动检测规范冲突 |
| 规范演进 | 手动管理 | sync/archive 自动合并 |
| 上下文文件 | CLAUDE.md 等 AI 上下文 | .openspec.yaml 变更元数据 |
| 团队入口 | 无 | /opsx:onboard 交互式引导 |
关键差异：Delta 规范与归档
OpenSpec 的Delta 规范和归档机制是团队协作的核心优势：
- Delta 规范：每个变更只记录增量变化，不重写整个文档
- sync：将增量合并到主规范库，其他变更可以看到最新规范
- 归档：完成的变更按日期归档，主工作区保持干净
- 冲突检测：批量归档时自动检测跨变更的规范冲突
Spec-Kit 没有内置的归档和 Delta 机制，规范管理需要更多手动工作。
13. CI/CD 集成对比
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| CLI 验证 | 无 | openspec validate --all --strict --json |
| JSON 输出 | 无 | 全面支持（list/show/validate/status/instructions） |
| 退出码 | 无 | 0=成功，1=失败 |
| CI 友好 | 低 | 高 |
| 自动化脚本 | 无 | --no-interactive + --json 支持全自动化 |
OpenSpec 在 CI/CD 集成方面明显更强，几乎每个 CLI 命令都支持 --json 输出和 --no-interactive 模式，适合在 CI 流水线中运行。
14. 学习曲线与上手体验
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 安装难度 | 中（Python + uv + Token） | 低（npm 一键安装） |
| 最小上手步骤 | 5 步（5 个命令） | 3 步（3 个命令） |
| 概念数量 | 较多（宪法/规格/方案/任务/FR/SC/...） | 较少（变更/产物/规范） |
| 入门引导 | 无内置引导 | /opsx:onboard 15-30 分钟交互式引导 |
| 中文支持 | 有中文版（specify-cn） | 中文文档完善 |
| 文档质量 | 官方文档 + 社区教程 | 官方文档 + 中文站 + CLI 帮助 |
| 首试时间 | ~1 小时 | ~30 分钟 |
上手体验总结
Spec-Kit：安装配置稍复杂，但工作流清晰、步骤明确，适合喜欢"按部就班"的开发者。
OpenSpec：安装简单，核心三步即可上手，onboard 引导基于真实项目，适合想快速体验的开发者。
15. 完整工作流对比演示
以"为应用添加暗黑模式"为例，对比两个工具的完整工作流。
Spec-Kit 流程
步骤 1: /speckit.constitution
→ 制定宪法：优先原生 API、测试覆盖率 ≥ 85%、UI 响应 < 100ms
步骤 2: /speckit.specify
→ 编写规格：用户故事 + FR（FR-001~FR-006）+ SC（SC-001~SC-004）
步骤 3: /speckit.clarify（可选）
→ 澄清：筛选支持多条件？编辑方式？已完成任务显示？
步骤 4: /speckit.plan
→ 生成方案：plan.md + data-model.md + quickstart.md
步骤 5: /speckit.tasks
→ 拆分任务：4 个 Phase、10 个 Task
步骤 6: /speckit.analyze（可选）
→ 一致性分析：检查规格与方案的一致性
步骤 7: /speckit.implement
→ 执行实现：逐项完成任务，可选 YOLO 模式
步骤 8: /speckit.checklist（可选）
→ 质量检查：验证需求覆盖度
最少 5 步，推荐 8 步
OpenSpec 流程
方式 A — 核心三步流:
步骤 1: /opsx:propose add-dark-mode
→ 一步生成：proposal.md + specs/ + design.md + tasks.md
步骤 2: /opsx:apply
→ 执行任务：逐项完成
步骤 3: /opsx:archive
→ 归档变更：同步规范 + 移入归档目录
方式 B — 逐步推进:
步骤 1: /opsx:explore
→ 探索需求和方案
步骤 2: /opsx:new add-dark-mode
→ 创建变更框架
步骤 3: /opsx:continue → 生成 proposal
步骤 4: /opsx:continue → 生成 specs
步骤 5: /opsx:continue → 生成 design
步骤 6: /opsx:continue → 生成 tasks
步骤 7: /opsx:apply
→ 执行任务
步骤 8: /opsx:verify
→ 验证一致性
步骤 9: /opsx:archive
→ 归档变更
最少 3 步，按需扩展至 9 步
流程对比总结
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 最少步骤 | 5 步 | 3 步 |
| 推荐步骤 | 8 步 | 3-9 步（按需） |
| 灵活度 | 低——固定顺序 | 高——按需选择 |
| 一次性产物 | 否——分步生成 | 是——propose/ff 一步到位 |
16. 优劣势总结
Spec-Kit 优势
| # | 优势 | 说明 |
|---|---|---|
| 1 | 宪法机制 | 强制约束所有 AI 产出，团队一致性有保障 |
| 2 | 需求澄清 | clarify 命令主动识别歧义，减少理解偏差 |
| 3 | 产物细致 | plan/data-model/quickstart/contracts 分离，信息密度高 |
| 4 | 预防式质量 | 宪法 + clarify + analyze 在源头预防问题 |
| 5 | GitHub 官方 | 背靠 GitHub 生态，与 Copilot 深度集成 |
| 6 | 质量检查表 | checklist 命令验证需求覆盖度，Spec-Kit 独有 |
| 7 | 命令格式统一 | 所有工具用同一格式，学习成本低 |
Spec-Kit 劣势
| # | 劣势 | 说明 |
|---|---|---|
| 1 | 安装复杂 | 需要 Python + uv + GitHub Token |
| 2 | 流程偏重 | 5 步必经，对小变更来说过重 |
| 3 | 无归档机制 | 完成的功能没有内置归档流程 |
| 4 | 无增量规范 | 需求变更时需要重写整个 spec |
| 5 | 无 CI 支持 | CLI 不支持 JSON 输出，难以集成 CI |
| 6 | 固定工作流 | 无法自定义产物类型和依赖关系 |
| 7 | AI 工具覆盖少 | ~11 个，不如 OpenSpec 的 20+ |
OpenSpec 优势
| # | 优势 | 说明 |
|---|---|---|
| 1 | 轻量灵活 | 核心三步完成开发，按需扩展 |
| 2 | 安装简单 | npm 一键安装，无额外依赖 |
| 3 | Delta 规范 | 增量记录变化，归档时自动合并 |
| 4 | 归档机制 | 完成变更自动归档，主工作区保持干净 |
| 5 | Schema 可定制 | 工作流可编程，产物类型和依赖可自定义 |
| 6 | CI 友好 | 全面 JSON 输出 + 退出码，适合 CI/CD |
| 8 | AI 工具覆盖广 | 20+ AI 工具支持 |
| 9 | 入门引导 | onboard 命令基于真实项目交互式教学 |
| 10 | 批量归档 | 多变更并行开发后批量归档，自动检测冲突 |
OpenSpec 劣势
| # | 劣势 | 说明 |
|---|---|---|
| 1 | 无宪法机制 | 缺少强制约束，团队一致性依赖自律 |
| 2 | 无需求澄清 | 没有 clarify 类命令主动识别歧义 |
| 3 | 产物粒度粗 | design.md 统一承载技术方案，不如 Spec-Kit 细致 |
| 4 | 验证式质量 | verify 在实现后检查，而非预防 |
| 5 | 命令格式不统一 | 不同 AI 工具用不同格式 |
| 6 | 文档较新 | 社区积累不如 Spec-Kit 丰富 |
| 7 | Schema 复杂度 | 自定义 Schema 增加了学习成本 |
17. 选择指南：场景化推荐
场景一：个人开发者 / 小项目
推荐：OpenSpec
理由：安装简单、核心三步即用、不需要复杂配置。个人开发者追求效率，不需要强制的团队约束。
场景二：中大型团队项目
推荐：Spec-Kit
理由：宪法机制确保团队一致性，clarify 减少沟通损耗，细致的产物格式适合多人协作。严格的流程避免了"各写各的"问题。
场景三：已有项目引入 SDD
推荐：OpenSpec
理由：OpenSpec 明确以"存量项目优先"为设计原则，安装轻量、无需重写代码，onboard 引导基于真实项目。
场景四：前端开发者
推荐：OpenSpec
理由：Node.js 技术栈更亲切，npm 安装一条命令，不需要配置 Python 环境和 GitHub Token。
场景五：需要 CI/CD 集成
推荐：OpenSpec
理由：CLI 全面支持 JSON 输出、退出码、非交互模式，天然适合 CI 流水线。
场景六：追求极致规范
推荐：Spec-Kit
理由：宪法机制 + clarify + analyze + checklist 四重质量保障，在预防问题方面是 OpenSpec 无法比拟的。
场景七：快速原型 / 探索性项目
推荐：OpenSpec
理由：3 步即可完成开发，不需要走 5 步固定流程。快速迭代是 OpenSpec 的设计初衷。
决策矩阵
| 场景 | Spec-Kit | OpenSpec |
|---|---|---|
| 个人开发者 | ★★☆ | ★★★ |
| 中大型团队 | ★★★ | ★★☆ |
| 已有项目 | ★★☆ | ★★★ |
| 前端开发者 | ★★☆ | ★★★ |
| CI/CD 集成 | ★☆☆ | ★★★ |
| 极致规范 | ★★★ | ★★☆ |
| 快速原型 | ★☆☆ | ★★★ |
| 学习 SDD | ★★☆ | ★★★ |
18. 能否混用？
理论上可以，但不推荐。
为什么不推荐混用？
- 目录冲突：Spec-Kit 用
.specify/，OpenSpec 用openspec/，虽然不冲突但两套目录增加认知负担 - 产物冗余：同一功能会在两个系统中生成重复的 spec/plan/tasks 文档
- AI 困惑：AI 助手同时看到两套指令文件，可能混淆
- 维护成本：两套规范文档需要手动保持同步
如果必须迁移
从 Spec-Kit 迁移到 OpenSpec：
- 保留
.specify/memory/constitution.md的内容，作为 OpenSpec 全局规范的基础 - 将
specs/下的内容迁移到openspec/specs/ - 删除
.specify/目录 - 运行
openspec init
从 OpenSpec 迁移到 Spec-Kit：
- 将
openspec/specs/中的规范整理为 Spec-Kit 的 spec.md 格式 - 从规范中提取"宪法"原则写入 constitution.md
- 删除
openspec/目录 - 运行
specify init . --ai <agent>
19. 总结
Spec-Kit 和 OpenSpec 是 SDD 领域两个优秀的工具，代表了两种不同的设计哲学：
一句话总结
Spec-Kit 是 SDD 的"正步走"——严格、一致、可靠。
OpenSpec 是 SDD 的"自由舞"——灵活、轻量、高效。
核心差异速查
| 维度 | Spec-Kit | OpenSpec |
|---|---|---|
| 哲学 | 严格约束 | 灵活流动 |
| 最小步骤 | 5 步 | 3 步 |
| 约束机制 | 宪法强制 | 规范库引导 |
| 质量保障 | 预防式（clarify/analyze/checklist） | 验证式（verify） |
| 团队协作 | 宪法确保一致性 | Delta 规范 + 批量归档 |
| CI/CD | 不支持 | 全面支持 |
| 定制能力 | 固定工作流 | Schema 可编程 |
| 安装 | 复杂（Python + Token） | 简单（npm） |
| AI 工具 | ~11 个 | 20+ |
| 适合 | 团队/大型项目/追求规范 | 个人/团队/追求灵活 |
最后的建议
不要纠结于工具，纠结于规范本身。
两个工具都能帮你实现 SDD 的核心目标——在写代码之前先对齐需求。选择哪个工具不如先开始用起来。如果你已经对 SDD 理念有认同，先用哪个顺手的就好，工作流可以在实践中调整。
参考资源
- Spec-Kit 仓库: github.com/github/spec-kit
- Spec-Kit 官方文档: github.github.com/spec-kit
- OpenSpec 仓库: github.com/Fission-AI/OpenSpec
- OpenSpec 中文文档: lzw.me/docs/OpenSpec-Docs-zh
浙公网安备 33010602011771号