SpecScore vs OpenSpec
兩者都將規範以 Markdown 形式放在程式碼旁邊，可供 AI 代理讀取。它們解決的問題不同：OpenSpec 組織規範並產生代理指令；SpecScore 對規範內容進行 linting、強制執行生命週期，並將程式碼追溯到需求。
兩者的共同點
OpenSpec 的優勢
最廣泛的代理支援
OpenSpec 透過產生技能檔案支援 29 個 AI 編碼代理 — Claude、Cursor、Copilot、Gemini、Windsurf、Cline 等。如果你的代理在支援列表中，OpenSpec 無需任何設定即可整合。
極低的上手門檻
npm install -g @fission-ai/openspec && openspec init 即可開始編寫規範。無需學習 schema，無需必填的 frontmatter。設計上追求零摩擦 — 尤其適合現有專案。
清晰的變更增量模型
OpenSpec 的 ADDED / MODIFIED / REMOVED 規範演進格式設計精良。每個變更是包含提案、增量規範和任務的資料夾 — 一種結構化的修改提案方式。
功能對比
| 能力 | OpenSpec | SpecScore |
|---|---|---|
| 規範格式 | Markdown（無 frontmatter） | Markdown + YAML frontmatter |
| 規範 linting | 僅檔案結構 | 內容品質 — 模糊動詞、缺失驗收標準、懸空引用 |
| 需求 ID | 無（透過標題引用） | 基於 slug（REQ: slug-format） |
| 驗收標準 ID | 無 | 機器可定址的 ID |
| 生命週期狀態 | 隱式（基於檔案位置） | 強制執行 — Draft → Under Review → Approved → Implementing → Stable → Deprecated |
| 程式碼到規範的可追溯性 | 無 | specscore: 註解 + Verifies: 提交尾註 |
| 子功能 | 否 | 支援（嵌套目錄） |
| 交叉引用 | 無正式機制 | 相依關係、源 Idea、計畫引用 |
| CI 整合 | 基礎（openspec validate） | specscore lint 可設定嚴重層級，支援 pre-commit 鉤子 |
| 代理支援 | 29 個代理 | 以 Claude Code 為主 + CLI 支援任何代理 |
| Schema 自訂 | 支援（schema.yaml、fork/init） | 固定 schema（設計上保持一致性） |
| 變更提案 | 增量模型（ADDED/MODIFIED/REMOVED） | 變更請求 Idea + 提案 |
| 執行階段相依性 | Node.js 20.19+ | 無 — 單一 Go 二進位檔案 |
| 授權條款 | MIT | MIT |
SpecScore 更進一步之處
校驗不止於檔案結構
OpenSpec 的 validate 檢查檔案結構 — 檔案是否存在、是否包含正確的章節。SpecScore 檢查得更多，分為兩層：lint 確定性地校驗內容關係 — 每個需求都有驗收標準、交叉引用可解析、狀態轉換合法 — 而 AI 審查器（/review、/score）則捕捉任何 linter 都無法發現的問題：含糊的驗收標準和模糊的動詞。
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
每個需求都有機器可讀的 ID
OpenSpec 透過標題引用需求 — 重新命名時容易出錯。SpecScore 分配基於 slug 的 ID（REQ: slug-format）和驗收標準 ID，在重新命名、重構和代理交接時保持穩定。
生命週期是強制的，而非隱含的
在 OpenSpec 中，規範的生命週期由檔案位置決定：specs/（當前）、changes/（提議中）、archive/（已完成）。在 SpecScore 中，生命週期是一個強制執行的狀態欄位 — Draft → Under Review → Approved → Implementing → Stable → Deprecated — 由 lint 驗證，透過 git 鉤子或 CI 中的 specscore change-status 進行狀態轉換。
程式碼可追溯到規範
OpenSpec 沒有可追溯性機制。SpecScore 在程式碼註解中使用 specscore: 源註解和 Verifies: 提交尾註。執行 specscore code refs 即可確定性地回答「哪些程式碼實現了這個需求？」
無執行階段相依性
OpenSpec 需要 Node.js 20.19+。SpecScore 是單一 Go 二進位檔案 — 無執行階段相依性、無 node_modules。可直接用於 Go、Rust、Python、Java 專案，無需在工具鏈中引入 Node。
可組合的產物階層
OpenSpec 的規範按領域平鋪。SpecScore 具有具型別階層結構：Idea 晉升為 Feature，Feature 包含需求和驗收標準，Plan 引用驗收標準，Task 引用 Plan。所有關係均可透過 CLI 進行機器導覽。
何時使用哪一個
以下場景適合從 OpenSpec 開始……
- 你使用 Cursor、Copilot 或非 Claude 代理，需要開箱即用的整合。
- 你首次為現有程式碼庫新增規範，希望零摩擦上手。
- 你的團隊更看重 schema 靈活性而非強制約束。
以下場景適合使用 SpecScore……
- 你需要規範品質保障 — lint 在代理浪費 token 之前就能捕捉歧義。
- 你需要程式碼到規範的可追溯性 — 「哪些程式碼實現了這個需求？」能得到確定性答案。
- 你正在構建具有大量功能、子功能和生命週期轉換的大型系統。
- 你需要零執行階段相依性 — 單一二進位檔案，無需 Node.js。
- 你需要在 CI 中設定規範品質門檻 —
specscore lint在檢查失敗時返回非零結束代碼，與 ESLint 或go vet一致。
兩者並不互斥
SpecScore 可以對 OpenSpec 的 spec.md 檔案進行 lint。從 OpenSpec 起步的團隊可以在不遷移的情況下新增 SpecScore 的品質層 — 對現有規範進行 lint，在需要時新增可追溯性，在團隊擴大時強制執行生命週期。
OpenSpec 是一個優秀的入門通道。SpecScore 是品質護欄。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.