兩者的共同點。
Tessl 擅長什麼。
Tessl 有兩套介面很容易被人混為一談。下面的筆記把它們拆開，依據是 2026年10月30日讀過的頁面。
「規範即源頭」這件事講明白了
Simon Maple 於 2025年6月27日發表的文章指出：產品需求文件（PRD）——寫給人看、說明要打造什麼的散文——通常會過時失效，程式碼反而變成唯一可信的依據。文章提出的另一條路是：你改的是規範，由大型語言模型產生程式碼、測試與文件。這是一個站得住的立場，不是口號。
替代理備好上下文的平台
Tessl 的文件寫的是登錄庫、會掃描技能再給技能評分的治理機制、評測，以及橫跨各個代理的可觀測性。文件說，技能就是你儲存庫裡的一般產物，平台可以跟 Claude Code、Cursor、Copilot、Gemini 等一起用。那邊講的評分，評的是技能，不是產品規範。
官方出的規範驅動 tile，shell 檢查一併附上
tessl-labs/spec-driven-development 這個 tile，在公開的 tile 儲存庫裡以 MIT 授權發布。它教代理先訪談、寫下 .spec.md 檔案、等核准，然後才實作。登錄庫那一頁列出 scripts/validate-specs.sh 與 scripts/check-spec-links.sh，用來檢查前置資料、targets 以及 [@test] 連結。同一頁也說，這個 tile 是用來引導的上下文：沒有特別的命令，也沒有一套框架。
功能對比。
「把規範當成源頭」是 Tessl 的文章。tile 是疊在目前這套平台上的一套技能組合。SpecScore 是有版本號的檢查器所檢查的格式。
| 能力 | Tessl | SpecScore |
|---|---|---|
| 主要角色 | 代理技能平台，外加一個規範驅動的 tile，以及 2025 年一篇談規範即源頭的文章 | 開放的規範格式 + CLI |
| 規範指的是什麼 | 文章：那份會一直留著的源頭，程式碼由它產生。tile：一份 .spec.md，代理對照它來實作，程式碼仍由你留著。 | 放在程式碼旁邊的契約。檢查不會重新產生程式碼。 |
| 規範的長相 | tile：YAML 前置資料、targets 萬用字元，以及指向測試檔案的 [@test] 連結 | Markdown + YAML、REQ: slug、給定／當／那麼 |
| 怎麼檢查規範 | tile 隨附的 shell 指令稿，只檢查這個 tile 自己的前置資料與連結 | specscore spec lint，針對 SpecScore 格式，在這個儲存庫的 CI 裡執行。/score 是要手動跑的 AI 評分。 |
| 授權 | 這個 tile 是 MIT。平台是一項產品。文件沒有公布平台的原始碼。 | CC BY 4.0 格式 · Apache-2.0 CLI |
| 定價 | 在 2026年10月30日讀到的Tessl 首頁上寫著免費方案（一個工作區一個月 1,000 點額度）以及付費的企業方案。 | 不必付費，格式與 CLI 都一樣 |
SpecScore 增添了什麼。
對外發布的是格式，不是 tile 的指令稿
tile 的 shell 指令稿檢查的，是這個 tile 請代理去寫的 .spec.md 檔案。SpecScore 檢查的，是本站寫下來的格式。dogfood.yml 會安裝一個釘選版本的 specscore 發行版本，並執行 specscore spec lint。/score 不是那項作業：它是一項手動技能，AI 審查者回報問題時會以非零狀態結束。
$ 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)
程式碼兩邊都還是你的——文章走得更遠
2025 年的文章認為，程式碼應該依規範重新產生。2026年10月30日讀到的 tile 頁面，是讓代理對照一份已核准的規範去實作，並沒有描述一個會把你的原始碼樹換掉的編譯器。SpecScore 不會把程式碼收走。規範是審過的契約；程式碼還是你的。
每一條需求都有固定的名字
tile 用 targets 與 [@test] 把一條需求指向檔案。SpecScore 把需求命名為 REQ: slug，於是計畫、任務和提交結尾註記在檔案搬家之後仍能引用它。
何時使用哪個。
遇到這些情況，選 Tessl……
- 你需要登錄庫、評測和治理，來管理許多代理、許多儲存庫一起共用的技能。
- 你想把「規範即源頭」那篇文章裡的工作流程做成一塊引導 tile：先訪談，核准一份 .spec.md，然後才實作。
- 你已經在付費使用或試用 Tessl 平台，並希望它的規範 tile 就放在那個登錄庫裡。
以下情境適合使用 SpecScore……
- 規範格式本身必須在 CI 裡有效，連那些不安裝 Tessl 的儲存庫也一樣。
- 你要需求識別碼，以及一個不會去呼叫模型的檢查器。
- 你希望這份格式開源，用的是創用 CC 授權，並且跟技能平台分開。
規範可以當源頭，也要經得起檢查。
Tessl 的文章說得對：過時的 PRD 會輸給程式碼。格式檢查，就是讓規範繼續成為你信得過的那一份的辦法。SpecScore 不會照規範去產生你的應用程式。結構、連結或狀態有誤時，它會讓規範在 CI 裡失敗。
平台和 tile 選 Tessl。git 裡那份產物若必須由拉取請求來證明，選 SpecScore。
來源。
下方公開頁面讀於 2026 年 10 月 30 日。價格、方案名稱和發布線會改變。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.