OpenSpec 与 Spec Kit 深入解析

一句话：两者解决的不是同一个问题——OpenSpec 管「规范怎么随变更演进」，用增量目录避免全量重写；Spec Kit 管「从功能描述到任务清单的流水线」，用命令链把规范展开成可执行任务。

说明：两个项目都在快速迭代。本文写于 2026-10，CLI 子命令、目录结构和 Agent 支持名单以官方仓库/文档为准；文中标「以官方文档为准」的地方，不要在团队里当成稳定 API。

为什么需要

团队上 SDD 常见两种失败：

规范写完就过期。 每次变更都重写全文，维护成本高，最后没人更新。
规范到代码之间没有桥。 写了一份需求文档，Agent 仍不知道怎么拆任务、怎么验证、做到哪算完。

OpenSpec 针对第一种：把「当前规范」和「变更提案」分开，只写变化。Spec Kit 针对第二种：用固定命令链把功能描述逐步展开成规范、计划、任务，再交给 Agent 实现。

核心机制

OpenSpec：当前规范 + 变更提案

典型目录（以官方文档为准）：

text

openspec/
├── specs/                    # 当前生效的规范（source of truth）
│   └── <capability>/spec.md
├── changes/
│   ├── <change>/
│   │   ├── proposal.md       # 为什么改、改什么、影响
│   │   ├── tasks.md          # 实施清单
│   │   ├── design.md         # 可选，技术决策
│   │   └── specs/<capability>/spec.md   # 增量规范
│   └── archive/              # 已归档变更
└── project.md                # 项目上下文（以官方模板为准）

增量用标记表达：ADDED / MODIFIED / REMOVED，只描述差异。
归档时合并：把 change 里的增量并进 specs/，change 目录移入 archive。
校验靠结构：openspec validate 检查格式和增量结构；具体检查项以官方文档为准。

关键取舍：增量降低了维护成本，但要求团队遵守目录和标记格式。格式错了，归档合并就会出错；工具能校验结构，不能判断需求写得对不对。

Spec Kit：宪法 + 命令链

宪法（constitution）：项目级约束，保存在 .specify/ 下（具体路径以官方模板为准），被后续命令作为上下文读取。
命令链：/speckit.constitution 定约束 → /speckit.specify 写功能规范 → /speckit.clarify 澄清 → /speckit.plan 出计划 → /speckit.tasks 拆任务 → /speckit.implement 执行。
一致性检查：/speckit.analyze 检查规范、计划、任务之间的覆盖和冲突，不修改文件。
产物：specs/<feature>/ 下的 spec.md、plan.md、tasks.md 等；具体文件名以官方模板为准。

关键取舍：宪法让跨功能决策一致，但流程重、产物多。它没有「改一条宪法就自动重写所有规范」的魔法；一致性靠命令检查和人工审查。

两者对比

维度	OpenSpec	Spec Kit
解决的问题	规范变更维护	规范到任务的流水线
输入	一个变更提案	功能描述 + 宪法
主要产出	`changes/` 增量 + 归档后的 `specs/`	`.specify/` 产物 + `specs/`
约束方式	目录结构 + 增量标记 + validate	宪法 + 命令链 + analyze
集成	CLI，不绑定 IDE	CLI，按 Agent 生成命令
主要成本	格式纪律	流程重量、产物数量
最适合	频繁变更、轻量维护	多团队、统一架构约束

最小上手

OpenSpec

bash

# 安装命令以官方 README 为准
npm install -g @fission-ai/openspec
cd your-repo
openspec init
openspec list

# 新建一个变更（目录和文件按 init 生成的模板填写）
# changes/add-2fa/proposal.md
# changes/add-2fa/specs/auth/spec.md  ← 只写 ADDED/MODIFIED/REMOVED
openspec validate add-2fa
openspec archive add-2fa

验证：validate 无报错；归档后 openspec/specs/auth/spec.md 包含新增条目，changes/archive/ 下留有变更记录。

Spec Kit

bash

# 安装与初始化以官方 README 为准
uvx --from git+https://github.com/github/spec-kit.git specify init my-app --ai claude

在生成的项目里按顺序执行：

text

/speckit.constitution   # 写项目约束
/speckit.specify        # 写功能规范
/speckit.clarify        # 澄清歧义（可选）
/speckit.plan           # 生成计划
/speckit.tasks          # 拆分任务
/speckit.analyze        # 检查跨产物一致性
/speckit.implement      # 执行

验证：specs/ 下有规范、计划和任务；tasks.md 的每条任务有文件路径和验收方式；analyze 报出的缺口被逐条处理或明确接受。

生产动作

只选一个作为权威。 OpenSpec 的 specs/ 或 Spec Kit 的 .specify//specs/，不要双写。双写的结局是两份都过期。
OpenSpec 的变更粒度 = 一个可独立交付的功能。 太小不值得走流程，太大无法 review。
OpenSpec 归档前必须 validate。 合并冲突通常来自多人同时改同一个 capability；先合并规范，再归档。
Spec Kit 的宪法只写能检查的约束。 分层、禁用的库、安全要求、测试门槛可以写；「代码要优雅」不可检查。
升级前读 Release Notes。 子命令和目录会变；把版本写进团队 README，升级后在分支跑一遍完整命令链。
给规范加 Owner 和过期检查。 工具不解决规范腐烂，只降低维护成本。

边界

OpenSpec 不强制架构约束，也不保证 Agent 遵守规范。 它只是变更管理和结构校验。
Spec Kit 的宪法是上下文约束，不是编译器。 Agent 仍可能违反，需要测试和 Review 兜底。
两者都不适合生命周期极短的项目。 规范维护成本会超过收益。
混用会增加心智负担。 如果必须混用，明确谁是权威、谁只做变更记录，并写进团队约定。
第三方文章里的命令，以及「改一条约束就自动修好所有规范」的说法，可能过期或不存在。 以官方仓库的 README 和源码为准。

讲清楚

OpenSpec 和 Spec Kit 常被放在一起比较，但层次不同。OpenSpec 解决规范维护：当前行为放 specs/，每次变更写一个 change，用 ADDED/MODIFIED/REMOVED 描述差异，校验后归档合并。Spec Kit 解决从需求到任务的流水线：先写项目宪法，再用 specify、clarify、plan、tasks、implement 一串命令把功能描述展开成可执行任务。前者的代价是格式纪律，后者的代价是流程重量。选型看你的痛点是「规范总过期」还是「规范到代码没有桥」。两者都替代不了测试和 Review，也都没有「改一条约束就自动修好所有规范」的能力。

初稿 2026-07 | 最后修订 2026-10 | 事实核查：移除 speckit constitution align 等不存在命令与 Star 数，CLI 行为标注以官方文档为准

OpenSpec 与 Spec Kit 深入解析 ​

为什么需要 ​

核心机制 ​

OpenSpec：当前规范 + 变更提案 ​

Spec Kit：宪法 + 命令链 ​

两者对比 ​

最小上手 ​

OpenSpec ​

Spec Kit ​

生产动作 ​

边界 ​

讲清楚 ​