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 安裝。