SpecScore vs Plain Markdown
大多數團隊已經有了「規範」——以 docs 資料夾裡的臨時 Markdown、Notion 頁面或 Jira 工單的形式存在。它免費、它早已就位、它能用。SpecScore 就是同樣的 Markdown，外加 AI 代理可以 lint、查詢並追溯回程式碼的結構。
兩者的共同點。
預設方案的優勢。
Plain Markdown、Notion 和 Jira 才是真正的預設選擇。它們當之無愧。
零學習曲線
沒有 schema、沒有必填欄位、流程中沒有 CLI。打開一個檔案，開始打字。 對於一次性的筆記或微型專案來說，這恰到好處——你不需要的結構只是摩擦。
早已安裝就位
你的團隊已經在用 Notion、Confluence 或一個 docs/ 資料夾。 無需採用任何新東西，無需遷移。摩擦最小的選項就是你已經在用的那個。
普遍可攜
Plain Markdown 在任何地方都能打開，並且比任何工具都更長久。SpecScore 正是建立在 這一特性之上——這也是為什麼 SpecScore 同樣採用 Markdown，而非資料庫。
功能對比。
差別不在於檔案本身——而在於代理能用它做什麼。
| 能力 | Plain Markdown / Notion | SpecScore |
|---|---|---|
| 格式 | 自由格式 Markdown / 文件 | Markdown + YAML frontmatter（結構化） |
| 需求存放在哪裡 | Jira、Notion、Slack、某人的腦子裡 | 在儲存庫中，緊挨著程式碼 |
| 「這份規範完整嗎？」 | 由人閱讀並判斷 | specscore lint — 自動完成 |
| 歧義偵測 | 無 — 模糊動詞悄無聲息地發布 | 標記模糊動詞、缺失的驗收標準、懸空引用 |
| 需求 / 驗收標準 ID | 無 | 機器可定址的 ID（REQ: slug） |
| 生命週期狀態 | 隱式，如果有追蹤的話 | 強制執行 — Draft → Approved → Implementing → Stable |
| 程式碼到規範的可追溯性 | 無 | specscore: 註解 + Verifies: 結尾註記 |
| 代理導覽 | 讀取每個檔案才能找到任何東西 | 從 CLI 查詢規範圖譜 |
| CI 品質門禁 | 無 | specscore lint 回傳非零結束代碼，像 linter 一樣 |
| 學習曲線 | 無 | 需要學習一種格式（可漸進） |
| 成本 / 授權條款 | 免費 | 免費、開源 |
SpecScore 更進一步之處。
歧義被捕捉，而非被解讀
使用自由格式規範時，每次代理互動都從解讀開始—— 「登入應該能用」在正確與貌似合理但錯誤之間是一場擲硬幣。 SpecScore 的 lint 會在代理據此行動之前標記出模糊的動詞和缺失的 驗收標準。
$ specscore lint auth/login.md ✗ R1 "should work" — unmeasurable ✗ R1 no acceptance criteria
誤解不再層層累積
一個代理誤讀了需求，第二個在其基礎上構建，第三個又依賴前兩者—— 而你在三個代理之後才察覺。結構化的驗收標準讓每個代理擁有相同的 通過/失敗條件，因此解讀不會在它們之間發生漂移。
程式碼可追溯回規範
純文件與實作它們的程式碼之間沒有任何連結。SpecScore 新增了specscore: 來源註解和 Verifies:提交結尾註記——specscore code refs 能確定性地回答「哪些程式碼 實作了這個需求？」。
一份規範勝過四十個工單
一位新隊友（或一個全新的代理）只需閱讀一份包含全部情境的功能規範， 而不必從四十個 Jira 工單和一條 Slack 討論串中重建意圖。
代理查詢，而非反覆閱讀
在 docs 資料夾裡，要找出「哪些正在進行中？」意味著逐個打開檔案。 在 SpecScore 中，那就是 specscore feature list——規範圖譜 從 CLI 給出答案，因此代理不必為反覆閱讀儲存庫而消耗情境。
品質在 CI 中強制執行
自由格式規範沒有門禁——寫了一半的規範與完整的規範一樣容易合併。specscore lint 在出現問題時回傳非零結束代碼， 就像 ESLint 或 go vet 守護程式碼一樣。
何時使用哪個。
以下情境適合 Plain Markdown……
- 這是一次性的筆記、一次探針，或一個小到不需要結構的專案。
- 不會有 AI 代理基於該文件建構——人讀了就明白。
- 你在記錄一個粗略的想法，而非某人將要實作的需求。
以下情境適合使用 SpecScore……
- AI 代理基於規範建構——歧義會變成錯誤的程式碼。
- 多個代理或多人依賴同一批需求。
- 你需要知道哪些程式碼實作了哪個需求。
- 「這份規範完成了嗎？」應由工具回答，而非靠開會。
- 專案大到反覆閱讀所有內容已經無法擴展。
讓你已有的規範進階。
你無需轉換你的待辦清單，也無需更換工具。挑選你的下一個功能， 為它寫一份 SpecScore 規範，執行 specscore lint——看看它是否 捕捉到你的工單遺漏的東西。實作它時新增 specscore: 註解。 只有在它真正有幫助時，才擴展到下一個 sprint。
Plain Markdown 是入口匝道。SpecScore 是它進階後的樣子。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.