格式
Markdown + YAML。在任何能開啟文字的編輯器中使用。 無需新工具即可開始撰寫。
規格說明中的每一處歧義，
都是你的 AI 代理燒掉的 token。
SpecScore 是一種用於規格說明的開放、可 lint 的檔案格式，用 Markdown 和 YAML（YAML Ain't Markup Language）寫成，就像 JSON（JavaScript Object Notation）之於資料，並配有命令列介面（CLI），供你的 AI 代理呼叫以查詢和編輯它們，就像 jq 之於 JSON。
然後是開發途中的一個澄清問題。然後是上線之後的一次修復。 然後是你一遍遍重新解釋的上下文。
為你已有的規格說明提供格式。
SpecScore 是一種基於 Markdown + YAML 的格式，用於描述功能、 需求和驗收標準。它定義了一種你的團隊和 AI 代理都能理解的結構——而它只是儲存庫中的檔案。
一個 SpecScore 專案包含三種生命週期產物：Idea（構想）捕捉一個半成形的方向；Feature（功能）凍結已達成共識的行為；Plan（計畫）將功能分解為循序任務， 每個任務引用它所滿足的驗收標準。
為什麼你的 AI 代理在意。因為結構是機器可讀的， AI 代理可以透過 CLI 查詢規格說明，而不必讀取每一個檔案。問一句“我接下來該做什麼？”，CLI 就會返回開放的 Feature 和尚未回答的問題。和你團隊審查的是同一份形態，但代理需要載入的 上下文要少得多。
規格說明是階層結構。所以你的規格樹也是。
當 Feature 數量達到五十個時，扁平列表就會變成一堆亂麻。 SpecScore 讓樹保持可導覽——父節點掌管範圍，子節點掌管細節， 目錄結構映射的正是你的團隊早已在頭腦中梳理的產品結構。
未決問題會向上彙總。任何深度上未解決的問題， 都會浮現在每個父節點的索引裡。你可以從樹頂看到是什麼在阻礙發布， 而無需深入挖掘。
大多數規格工具假設扁平列表就夠用了。確實夠用——直到不夠用為止。 SpecScore 正是為「這個 Feature 該放在哪裡？」開始變得要緊的那一刻 而設計的。
specscore-cli/spec/features/cli/spec/features/cli/
├── agent/
│ └── setup/
├── feature/
│ ├── change-status/
│ ├── deps/
│ ├── info/
│ ├── list/
│ ├── new/
│ ├── refs/
│ └── tree/
├── idea/
│ ├── change-status/
│ ├── new/
│ └── relocate/
├── spec/
│ └── lint/
│ ├── issue-rules/ ← 子-子 Feature
│ └── plan-rules/
├── task/
│ ├── info/
│ ├── list/
│ └── new/
└── … 還有 10 個頂層 Feature沒有它會出什麼問題。
規格說明會漂移。
文件中的規格、Slack 裡的討論和 PR 中的程式碼悄悄地 分歧了好幾週。沒人能找到哪個版本的對話才是權威的。
解決方案
儲存庫中的唯一權威規格，與程式碼一起進行版本管理。
specscore lint在 CI 中每次推送時執行； git 歷史就是稽核追蹤。規格、討論和 PR 不可能悄悄 分歧——它們審查的是同一個檔案。驗收標準含混不清。
"優雅地處理錯誤"本來應該是指"顯示提示並復原"。還是"記錄日誌並重試？"AI 代理只能猜測。
解決方案
程式碼檢查器在寫任何程式碼之前就能捕捉含混的標準。 動詞無法通過檢查，因為它缺少具體的物件或條件。 修復這個警告會迫使你寫清楚"處理"到底 意味著什麼。
AI 代理交付了錯誤的東西。
人類會推斷、提問、澄清。AI 代理不會——它們實現的 是訓練資料中最常見的模式。程式碼通過了審查，因為它做了某些合理的事情。只是不是你想要的。
解決方案
結構化輸入。AI 代理確定性地解析 REQ ID、AC ID 和
GIVEN / WHEN / THEN情境——無需推斷。Plan 必須引用每個任務滿足的 AC ID， 所以構建的內容始終可以對照規格進行驗證。含糊的規格，你要付兩次錢。
代理根據含糊的指令做出了東西，你發現不對，於是換四種說法 重新提示。每個做了一半的功能、每一次重試，都按 token 計費。 規格越含糊，落地前來回的輪次就越多。
解決方案
在代理執行前先 lint 規格。
specscore lint在一開始就拒絕含糊的動詞和缺失的驗收標準，於是代理一次就 實現明確的指令，而不是在重試中反覆猜測。最便宜的一次代理 執行，就是你不必重複的那一次。AI 代理反覆付費讀取規格。
AI 代理回答"什麼依賴於這個功能？"時， 要讀取整個功能 README。然後讀每個父級索引。 然後以防萬一再讀兄弟功能。每次查詢都是一次重新解析。 Token 在消耗；延遲在增加；費用也隨之攀升。
解決方案
用結構化查詢代替檔案讀取。
specscore feature tree以 YAML 格式返回階層結構；feature deps遍歷可傳遞相依鏈；feature info展示狀態、負責人和待解決問題——每個只需 一次呼叫。代理導覽的是圖，而不是文字。程式碼忘記了它的規格。
六個月後，你在除錯一個函式，沒人記得它實現了哪個 功能。程式碼和規格之間的關聯存在於某人的腦袋裡， 而那個人已經離職了。引入它的 PR 已經存檔。
解決方案
原始碼註解。類似
// specscore: features/checkout/apply-discount/R1.AC-2的註解使關聯變得機器可讀，並在每次重構中保留下來。specscore code deps一次呼叫即可回答"這個檔案實現了哪個規格？"； 程式碼檢查器會標記指向已刪除規格的引用。狀態變更會洩漏。
你把一個功能從 Draft 改為 Approved， 但父級的 features-index 仍然顯示它是 Draft。三週後， 讀取索引的 AI 代理認為它仍在變動中。狀態現在存在於 兩個地方，而且它們不一致。
解決方案
specscore feature change-status在一個 不可部分完成的作業中重寫功能的 Status 欄位並重新同步 features-index 中的列——檢查失敗會復原修改。狀態存在於唯一的權威位置； 索引只是它的生成檢視。規格忘記了它不知道的東西。
規格讀起來像是已經定稿了——直到你想起兩個月前在 Slack 討論中遺失的"時區怎麼辦？"這個問題， 它從來沒有進入文件。現在你們在實現階段，沒人能說出 答案是什麼。
解決方案
每個 SpecScore 功能都有一個必填的Outstanding Questions 部分。程式碼檢查器 會拒絕省略它的功能——留空可以 （
"None at this time."），但不能沒有。 未解決的問題在文件中可見，可從 CLI 查詢，不可能被遺忘。
最簡單的入門方式：面向 AI 代理的 SpecStudio Skills。
SpecStudio Skills是一個 Claude Code 外掛，它將 SpecScore 生命週期轉化為四個斜線命令。 安裝一次，然後按順序執行——從原始構想走向可執行的計畫。
$ /plugin marketplace add specscore/ai-marketplace $ /plugin install specstudio@specscore
Claude Code自動完成
> /specstudio: /specstudio:ideate 將原始構想打磨為 SpecScore Idea /specstudio:specify 將已核准的 Idea 轉化為 Feature 規格 /specstudio:plan 將 Feature 分解為循序任務的 Plan /specstudio:implement 執行 Plan 中的下一個任務
可免費用於任何用途，包括商業用途。外掛原始碼在specscore/specstudio-skills——MIT 授權條款。
分兩遍檢查你的規格。
先是快速的確定性程式碼檢查器，再是更深入的 AI 審查 — 都在你剛才看到的規格上執行。兩遍檢查，兩種確定性。
執行程式碼檢查器。
deterministic$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors) # exit code 1
每次執行結果都相同。免費、快速，可在每次提交時執行。
用 AI 審查並評分。
non-deterministic> /score apply-discount.md Grade: B — ready with edits AC-2 vague trigger — name the actor and event AC-3 no error path for an expired code prose reads clean; criteria need tightening
像人類審查者一樣按含義閱讀。
包含什麼。
程式碼檢查器
Go 語言編寫的 CLI。驗證結構、引用和完整性。 失敗時返回非零結束代碼——適用於你的終端機和 CI。
無需綁定任何工具。
SpecScore 只是你儲存庫中的檔案。無需註冊任何 SaaS。無需編排器。 可以與 Linear、Jira、GitHub Projects、資料夾中的原始 Markdown 一起使用，或者完全不用任何專案管理工具。格式和程式碼檢查器 不關心你的工單放在哪裡。
SpecScore 與同類工具的比較。
規範驅動開發是一個擁擠的領域。這裡坦誠地說明 SpecScore 相較於各種替代方案的定位。
Plain Markdown預設選擇。SpecScore 是你的 Markdown 進階後的樣子。OpenSpec一個可靠的入門通道。SpecScore 是品質護欄。Spec KitSpec Kit 是工作流程。SpecScore 是產物。DatarimDatarim 執行管線。SpecScore 是它留下的成果。CodeSpeakCodeSpeak 押注於編譯器。SpecScore 押注於格式。KiroKiro 在 IDE 裡起草規格。SpecScore 是 CI 可以檢查的格式。TesslTessl 主張規格即源頭。SpecScore 檢查放在程式碼旁邊的規格。BMAD MethodBMAD 跑敏捷循環。SpecScore 是拉取請求可以檢查的產物。Task Master AITask Master 把 PRD 拆成任務。SpecScore 是這些任務可以引用的規格。
更喜歡 CLI？
不使用 AI 代理，或者需要在 CI 管線中驗證規格？ 有一個 CLI 工具可以做到。60 秒完成安裝——無需帳號、無遙測， 適用於任何 Markdown 規格目錄。
$ curl -fsSL https://specscore.md/install/get-cli | sh> irm https://specscore.md/install/get-cli.ps1 | iex對隨二進位檔案附帶的範例規格執行程式碼檢查器：
$ specscore lint examples/checkout/apply-discount.md檢視輸出：
examples/checkout/apply-discount.md
✓ R1 has acceptance criteria
✓ R2 has acceptance criteria
✗ R3 no acceptance criteria
✗ link "Related Feature: discount-tiers" not found
✗ section "Open Questions" missing
3 problems exit 1基於 SpecScore 構建。
DataTug
使用 DataTug 探索資料庫結構、撰寫並執行查詢，理解查詢結果。產品需求和驗收標準由 SpecScore 規範指導。
datatug.app 了解這些開發工具MeaningGraph
資料模型與語意定義的開放註冊表，定義保存在你自己的 Git 儲存庫中，並與模型和程式碼關聯。
meaninggraph.io 瀏覽註冊表Codegrapher
程式碼圖引擎，用於快速程式碼探索以及規範與程式碼的雙向關聯。
codegrapher.devDALgo
使用 SpecScore 規範的 Go 資料存取層。
dal-go.github.ioinGitDB
使用 SpecScore 規範的基於 Git 的版本化資料庫。
ingitdb.comRehearse
驗收證據層——真實執行規範的驗收標準，檢查可重複使用，無需黏合程式碼。
rehearse.inkSpecScore Studio
用於檢視和編輯 SpecScore 規格的 Web UI。
specscore.studio