SpecScore vs Spec Kit
它們運作在不同的層面。Spec Kit 是一套工作流程—— 一個引導代理從想法走向實作的有序流程。 SpecScore 是規範書寫所用的格式，外加一個用於 lint、查詢和追溯它們的 CLI。 Spec Kit 可以產出 SpecScore 檔案。
兩者的共同點。
Spec Kit 的優勢。
Spec Kit是來自 GitHub Next 的規範驅動開發工作流程。
完整、有主見的流程
Spec Kit 給你整條主線：constitution → specify → plan → tasks → implement。 每一步都有一個斜線命令和一段提示詞，旨在讓代理保持在軌道上。 如果你想要一套流程，Spec Kit 直接遞給你一套。
強大的分發與影響力
背靠 GitHub Next，擁有龐大的社群和不斷成長的擴充庫。 對許多開發者而言，Spec Kit 是他們接觸到的第一個規範驅動工作流程。
與代理無關的命令
Spec Kit 的命令在 Claude Code、Cursor、Copilot 等之間通用—— 無論你執行哪一個，工作流程都能驅動代理。
功能對比。
這些工具回答的是不同的問題，所以這張表對比的是角色，而非勝負。
| 能力 | Spec Kit | SpecScore |
|---|---|---|
| 主要角色 | 工作流程 / 方法論 | 儲存格式 + CLI |
| 規範產出 | 自由格式 Markdown | Markdown + YAML frontmatter（結構化） |
| 規範 linting | 無 | 內容品質 — 模糊動詞、缺失驗收標準、懸空引用 |
| 需求 / 驗收標準 ID | 無 | 機器可定址的 ID（REQ: slug） |
| 生命週期狀態 | 隱式（工作流程步驟） | 強制執行 — Draft → Approved → Implementing → Stable → Deprecated |
| 程式碼到規範的可追溯性 | 無 | specscore: 註解 + Verifies: 提交結尾註記 |
| 從 CLI 查詢規範 | 鷹架（specify、plan、tasks） | 查詢 API — feature list / show / deps、lint、code refs |
| 執行時期相依性 | Python | 無 — 單個 Go 二進位檔案 |
| CI 整合 | 執行工作流程 | specscore lint 回傳非零結束代碼，支援 pre-commit 鉤子 |
| 關係 | 它們可以組合 — Spec Kit 可以產出 SpecScore 檔案 | |
| 授權條款 | MIT | MIT |
SpecScore 增添了什麼。
產出是可 lint 的
Spec Kit 產出自由格式 Markdown——無論好壞，它都會交付。 SpecScore 分兩層檢查結果：lint確定性地驗證每個需求都有驗收標準、交叉引用可解析、 狀態轉換合法——而 AI 審查器（/review、/score）則捕捉含糊的 標準和模糊的動詞。
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
產出是可查詢的
Spec Kit 寫檔案；要回頭讀它們就得打開它們。SpecScore 的規範能從 CLI 回答問題：specscore feature list、feature deps、code refs——這樣代理無需 閱讀儲存庫中的每個檔案即可導覽規範圖譜。
每個需求都有 ID
Spec Kit 透過散文引用需求。SpecScore 分配基於 slug 的 ID（REQ: slug-format）和驗收標準 ID，在重新命名、 重構和代理交接時保持穩定。
生命週期是強制的
在 Spec Kit 中，規範的階段取決於你處在工作流程的何處。 在 SpecScore 中，生命週期是一個強制執行的狀態欄位——Draft → Approved → Implementing → Stable → Deprecated——由 lint 驗證，並透過 git 鉤子或 CI 中的specscore change-status 進行狀態轉換。
程式碼可追溯回規範
Spec Kit 沒有可追溯性機制。SpecScore 擁有specscore: 來源註解和 Verifies:提交結尾註記——執行 specscore code refs 即可確定性地回答 「哪些程式碼實作了這個需求？」。
無執行時期相依性
SpecScore 是單個 Go 二進位檔案——無需安裝任何執行時期。 可直接用於 Go、Rust、Python、Java 或 JavaScript 專案， 無需在工具鏈中引入任何東西。
何時使用哪個。
以下情境適合使用 Spec Kit……
- 你想要一套有引導、有主見的流程，從想法走向實作。
- 你的團隊需要明確的 specify / plan / tasks 步驟所帶來的紀律。
- 你正在團隊範圍內統一驅動代理的方式。
以下情境適合使用 SpecScore……
- 你需要代理無需閱讀每個檔案即可 lint、查詢和修改的規範。
- 你需要帶有確定性答案的程式碼到規範可追溯性。
- 你正在建構具有大量功能和生命週期轉換的大型系統。
- 你想要零執行時期相依性——一個二進位檔案，無需任何語言工具鏈。
- 你需要在 CI 中設定回傳非零結束代碼的規範品質門禁，就像 ESLint 或
go vet。
SpecScore 擴充 Spec Kit——而非取代它。
Spec Kit 是產出規範的流程；SpecScore 是該規範可以書寫所用的格式。 一個能輸出 SpecScore 格式的 Spec Kit 擴充功能正在開發中—— 執行 Spec Kit 工作流程，在另一端得到可 lint、可查詢、可追溯的規範。
為流程選擇 Spec Kit。為產出物選擇 SpecScore。當你兩者都想要時，兩者一起用。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.