三層，而非一層。
SpecScore 分層校驗，最廉價、最確定的優先。程式碼檢查器是確定性的 — 快速、免費，每次提交都執行。AI 審查是機率性的 — 更深入，消耗 token，能捕捉程式碼檢查器夠不著的東西。人的判斷是第三層： 前兩層無法彌合的縫隙仍然需要人 — 因為目前還沒有工具能可靠地彌合它們。 這兩個自動層是互補的，而非冗餘的：程式碼檢查器捕捉 AI 無法佐證的問題，AI 捕捉程式碼檢查器夠不著的問題。
每個校驗器檢查什麼。
Layer 1
CLI 程式碼檢查器
deterministic每次執行結果相同，不用 LLM，零成本。如果在這裡通過了，那就是事實 — 而非意見。
$ 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
- 引用完整性 — 連結可解析、ID 唯一
- 結構約定 — 必需的章節、frontmatter 的形態
- 狀態衛生與索引漂移
- slug 衝突
- 元資料欄位上的前綴合法性（例如
Related Ideas:）
Layer 2
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
- 驗收標準是否寫成可驗證的 Given/When/Then
- 單個產物內部的一致性
- 含糊或占位性的內容
- 對人類審查者而言的可讀性
- 作者可操作、標註了嚴重級別的回饋
- A–F 的就緒度評級
它們捕捉不到什麼。
沒有哪個校驗器是魔法。下面就是每一個止步之處 — 好讓你清楚地知道，哪裡仍然需要你自己的判斷來完成工作。
Layer 1
CLI 程式碼檢查器
- 跨深階層的隱式矛盾
- 規格與程式碼之間的漂移 （隨著
specstudio:recap上線而改善） - 驗收標準在語意上的正確性
- 一個名稱是否真的講得通
- 這些需求是否解決了所陳述的問題
Layer 2
AI 審查與評分
捕捉並不穩定- 完全的逐次可重現性 — 在容差範圍內裁決可能會變化
- 沒有顯式交叉檢查時，大型樹中跨產物的矛盾
- 需求是否真正解決了問題 — 能標出明顯的缺口，會漏掉特定領域的缺口
- 從底層 LLM 繼承而來的偏見
- 以絕對的把握保證語意正確性
- 任何評分細則沒有納入權重的東西
- 1
程式碼檢查器夠到這裡
結構、引用、衛生。廉價又確定 — 但對含義視而不見。
- 2
AI 夠到這裡
含義、清晰度、單個產物內部的一致性。更深入 — 但是機率性的，在大型樹上較弱。
- 3
仍然要靠你
對整個系統的貫穿式判斷 — 這是目前沒有工具能可靠完成的工作，所以仍然需要一位人類審查者。
兩個工具都救不了你的那種情形
想像一棵真實而深的規格樹。功能 A 要求 X。功能 B 要求Y。功能 C 要求 Z。然後功能 D 悄悄要求了某個與 B 矛盾的東西 — 但只在 A 同時生效時才矛盾。程式碼檢查器看到的是四份合法、彼此連結良好的文件，於是通過了。 AI 審查器逐個閱讀產物，沒有理由把這四份一起載入進來，從而注意到這種三方互動。
這兩層都無法可靠地捕捉它 — 我們也不會假裝不是這樣。正是這一類矛盾，才是第三層存在的理由。SpecScore 的職責是把這棵樹做得足夠易於導覽， 讓一位審查縫隙的人能夠找到衝突 — 開放問題沿階層向上傳播、相關需求只需一次查詢即達 — 而不是聲稱某個工具已經替你找到了它。