評審者真正問過的問題。

spec-kit 是一種方法論——寫規格說明的流程。SpecScore 是你所寫規格說明的儲存格式，外加 一個用於查詢和編輯的 CLI。兩者可以組合：spec-kit 能產生 SpecScore 檔案，一個以 SpecScore 格式輸出的 spec-kit 擴充功能 正在開發中。

需要流程時選 spec-kit。需要 AI 代理無需讀取儲存庫中每個檔案 就能進行 lint、查詢和變更的規格說明時，選 SpecScore。 兩者都要的時候，就都用。

理念相近。三者都是引導 AI 代理走完 ideate → specify → plan → implement 的技能庫。差異在機制上，不在理念上。

SpecStudio Skills 以 SpecScore 格式 （定義好的 Markdown + YAML 結構）寫出產物，並透過specscore CLI 完成查詢、lint 和狀態變更。 Superpowers 和 agent-skills 主要透過技能文字直接讀寫檔案。

當 token 消耗很重要時，選 SpecStudio Skills——CLI 透過一次 呼叫就能給出 "所有帶未決問題的開放 Feature"這樣的結構化答案，而基於檔案的技能要回答同樣的問題， 就得讀 N 份文件。

技能可以讀寫檔案。但它們無法可靠地做到：

• 在整棵規格樹上保證引用完整性（連結能解析、ID 唯一、索引保持同步）；
• 不讀取每個檔案就返回一份過濾後的「帶未決問題的開放 Feature」列表；
• 在每個產物上、在正確的時機、變更正確的狀態欄位。

CLI 讓代理在每項任務上只需一次乾淨的呼叫——就像jq 讓你只需一次乾淨的呼叫就能查詢 JSON。 單靠技能則消耗更多 token、更容易漂移、還經常忘記更新索引。

"Score"可以有兩種解讀，且都是有意為之。

Partitura（總譜）。一份結構化的需求總譜—— 就像樂譜組織聲部、聲線和時序那樣。打開一棵 SpecScore 樹， 你應該能像指揮讀總譜那樣去讀它：階層、聲部、引用，一目了然。

字面意義上的品質評級。CLI 檢查器是 確定性的分數（規格的結構是否站得住？）。/score 技能是 AI 評判的分數——每個產物的 A–F 就緒度評級，並附給作者 逐項回饋。名字裡"Score"的那一半，從一種願景變成了 工具實際產出的能力。

實測的並排對比正在進行中，會在 Habr 文章前發布——同一項任務 （「我接下來該做什麼？」）跑兩次：一次是普通代理讀文件， 一次是同一個代理呼叫 SpecScore CLI。兩邊都給出 token 計數 和回應時間。

在那些數字落地之前，主張是結構層面的：向 CLI 詢問開放 Feature 和未決問題的代理，得到的是一份小而結構化的回應； 沒有 CLI 的同一個代理則要讀 N 份文件——N 通常以十計。 CLI 的介面正是為了避開這種扇出讀取而設計的。

公開儲存庫 specscore/specscore 中的規範與文件是 CC BY 4.0。specscore/specscore-cli 中的參考命令列介面（CLI）是 Apache-2.0。

不綁定。規格是儲存庫裡的純文字檔。CLI 是本機程式。本站的 AI Skills 為能執行技能的代理包裝這個 CLI。格式本身不要求單一供應商。

規格驅動開發（SDD）是在寫程式之前先寫出可檢驗的規格（需求與驗收標準），再對照該規格檢查結果。SpecScore 是承載這些規格的一種檔案格式。