Spec Kit 与 OpenSpec 对比:哪个更适合你的 AI 编码流程

Spec Kit 和 OpenSpec 都是 MIT 许可的开源工具,解决的是同一个问题:需求只存在于聊天记录里时,AI 编码助手的输出很难预测,所以先把规范写下来,让人和 AI 先对齐再写代码。它们的区别在于流程的重量、规范的组织方式和工具链。

先说明立场

HagiCode 自己的工作流基于 OpenSpec,所以我们有偏好。下面的事实来自两个项目的官方文档,核对日期 2026-10-26,判断部分会标明是我们的看法。两个项目都在快速迭代,选型前请再看一遍各自的最新文档。

对比的是什么

Spec Kit:GitHub 出品,命令行是 specify(Python 包 specify-cli),安装和用法见 Spec Kit 安装教程。
OpenSpec:Fission AI 出品,命令行是 openspec(npm 包 @fission-ai/openspec),介绍见 OpenSpec 介绍。

关键差异

维度	Spec Kit	OpenSpec
运行环境	Python 3.11+,用 uv 或 pipx 安装	Node.js 20.19.0+,用 npm 或 Homebrew 安装
安装命令	`uv tool install specify-cli`	`npm install -g @fission-ai/openspec@latest`
初始化	`specify init my-project --integration claude`	进入项目后运行 `openspec init`
命令前缀	`/speckit-*`	`/opsx:`(部分助手写作 `/opsx-`,Codex 为 `$openspec-*`)
主流程	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge;最短路径是 specify → plan → tasks → implement → converge	默认配置是 propose、explore、apply、update、sync、archive;展开配置还有 new、continue、ff、verify 等
每个功能的产物	`spec.md`、`plan.md`、`tasks.md`,以及清单和分析结果	一个变更目录,内含 `proposal.md`、`specs/`、`design.md`、`tasks.md`
规范的组织方式	围绕单个功能写完整的规范	以”增量规范”为核心,用 `ADDED`、`MODIFIED` 描述变化,归档时并入长期规范
扩展机制	扩展(extension)和预设(preset),官方有 bug、assess 等扩展	可自定义 schema 和社区 schema
跨仓库	我们没有在官方文档的核心流程里看到专门的跨仓库支持	Stores(测试版)用独立仓库存放规划,跨多个代码仓库共享
支持的助手	官方文档列出数十个集成	官方文档称支持 30 多个工具
许可	MIT	MIT

流程重量:这是最常被说的差别

OpenSpec 的 README 把 Spec Kit 概括为”完整但偏重:阶段门禁严格、Markdown 多、需要 Python 环境”,并把自己定位成更轻、可以随时回头改任意产物。这是 OpenSpec 一方的说法。

公平地看:Spec Kit 的快速开始本身就给出了只有五步的最短路径,constitution、clarify、checklist、analyze 都是可选的;而 OpenSpec 展开配置后命令也不少。真正的区别不在命令数量,而在默认姿态:Spec Kit 更像一条从规范一路走到实现再收敛的流水线,OpenSpec 更强调每个变更是一个可以随时修改的独立目录。

按场景选

下面的建议是我们的判断,不是两个项目的官方结论。

你的情况	更合适的选择	原因
新项目,想要一套从零写规范到实现的完整流程	Spec Kit	流程完整,有 constitution 约束整个项目,`converge` 负责对照规范收尾
已有大量代码,每次只改一小块	OpenSpec	增量规范只描述变化,不需要为已有功能重写完整规范
团队主要是 Python 技术栈,习惯 uv	Spec Kit	安装方式和技术栈一致
团队主要是 Node.js 技术栈	OpenSpec	用 npm 一条命令安装
一次功能要改多个仓库	OpenSpec	Stores 可以把规划放在独立仓库里共享;注意它还是测试版
想要大量现成扩展(缺陷修复、想法评估)	Spec Kit	官方站点列出的扩展和预设更多
需求经常变,希望随时改规范、改计划	OpenSpec	产物不分严格阶段,可以随时回头修改

决策建议

先看技术栈和习惯,再看功能。 两者在能力上重叠很多,环境匹配带来的摩擦差别往往更大。
用同一个小功能各跑一遍。 选一个半天能做完的需求,分别走一次完整流程,比读十篇对比文章更可靠。
别同时在同一个项目里装两套。 两个工具都会往项目里生成命令和目录,混用会让助手的命令列表变得混乱。
评估时看三件事: 规范写完后是否真的减少了返工;你的 AI 助手是否被正式支持;团队成员是否愿意维护这些 Markdown。

HagiCode 的做法

我们自己长期使用 OpenSpec,并围绕它做了多仓库规范管理和按阶段使用不同 Agent 的实践,写在这两篇文章里:用不同的 Agent 优化 OpenSpec 各阶段效能:HagiCode 实践总结、MonoSpecs 是什么:为什么说它是对 OpenSpec 的进一步升级和扩展。这是我们的选择,不代表它对所有团队都更好。如果你的团队更适合 Spec Kit,它同样可以和 Claude Code、Codex 等 HagiCode 支持的 Agent CLI 一起使用,准备方式见 AI Agent CLI 安装。