SpecScore 對照 BMAD Method
BMAD Method（以敏捷、人工智慧驅動開發為名的突破方法，Breakthrough Method for Agile AI-Driven Development）是一種開源做法，用 AI 代理來跑敏捷交付：先把工作釐清、排好計畫、做出來、再檢查，決策都要寫下來。產品需求文件（PRD）是用散文交代要打造什麼、為誰做；這個方法的工作流程地圖會先產出一份，其後才是架構與故事。規範驅動開發（SDD）是兩邊共同所屬的更大想法——行為要在程式碼之前先訂好。SpecScore 是這種規範的開源格式，另外加上命令列介面（CLI）。持續整合（CI）——每一項提議中的變更都會自動查一次——可以在 SpecScore 檔案的結構不對時失敗。
兩者的共同點。
BMAD Method 擅長什麼。
2026年10月30日讀過的專案 README，稱 v6.12 為穩定版，稱 main 分支上的 v7 為預覽。那份 README 所寫的 v7 日期，讀的時候已經過了。這些版本線的名字，只該當成當時的快照。
方法自己會看工作有多大
README 說，小改動直接進入打造，比較大的工作才做規劃。main 上的工作流程地圖把階段寫清楚了：一份 PRD（PRD.md）、可有可無的 UX 規範、附有決策紀錄的 architecture.md、史詩檔與故事檔，接著才是一輪衝刺。這是一整圈敏捷循環，不是單單一則提示詞。
實作之前先有一道關卡
同一張地圖列出 bmad-check-implementation-readiness。實作開始前，它只回傳三種結果：PASS、CONCERNS、FAIL。v6 的產品經理代理另外還有 validate-PRD。兩道都是代理在自己的工作流程裡做的關卡，不是一支可以拿去掃任意 Markdown 目錄樹的格式檢查器。
它的確公開發布了
這個方法在公開儲存庫裡以MIT 授權發布。README 裡的穩定安裝命令是 npx bmad-method install。README 要求的版本是 Node.js 20.12 以上、Python 3.10 以上。網站bmadcode.com說這個方法不收費。
功能對比。
BMAD 是做事的流程。SpecScore 是流程可以對準的產物格式。這張表對照的是這兩種角色。
| 能力 | BMAD Method | SpecScore |
|---|---|---|
| 主要角色 | 敏捷方法：代理、技能與工作流程，從想法一路到驗證過的程式碼 | 開放的規範格式 + CLI |
| 規劃時留下的東西 | PRD、UX 規範、架構、史詩與故事、衝刺狀態——依據 2026年10月30日讀過的工作流程地圖 | 想法、功能、計畫、任務，放在 spec/ 目錄樹裡，而且帶著需求識別碼 |
| 怎麼檢查工作 | 由代理執行的就緒關卡（PASS / CONCERNS / FAIL），外加 validate-PRD 這條工作流程 | specscore spec lint 在 CI 裡執行，結果每次都確定。/score 是要手動跑的 AI 評分。 |
| 需求識別碼 | 故事與功能需求寫在 PRD 和史詩檔裡。並不是 SpecScore 的 REQ: slug。 | REQ: slug，以及驗收標準的識別碼 |
| 執行環境 | v6.12 的安裝器，README 寫明要有 Node.js 與 Python | 沒有別的，只要一支 Go 二進位檔就夠 |
| 授權 | MIT，bmad-code-org/BMAD-METHOD | CC BY 4.0 格式 · Apache-2.0 CLI |
SpecScore 增添了什麼。
檢查是一則命令，不是方法裡的一步
BMAD 的就緒結果，是它工作流程內部的一個決定。SpecScore 的結果是行程的結束代碼。dogfood.yml 在每一則拉取請求上執行 specscore spec lint。/score 用儲存庫裡設好的審查者替產物評分；得由你自己呼叫。CI 不會去叫。
$ 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)
換一套方法，格式還在
BMAD 的文件，長相是它的工作流程定出來的。你若停止執行 BMAD，Markdown 還在，但方法以外就沒有東西再去強制這個形狀。一棵 SpecScore 目錄樹就是契約。別的工作流程——BMAD 也算——一樣可以去寫它，檢查器照樣算數。
故事和需求靠識別碼連在一起
BMAD 的故事會把上下文留到下一步，代理就不必把產品重新決定一遍。SpecScore 把這條關聯做成可以機械核對的：計畫裡的任務會引用 REQ: slug，specscore: 註解再加上 Verifies: 提交結尾註記，把程式碼指回那條標準。
何時使用哪個。
遇到這些情況，選 BMAD Method……
- 你要代理按角色各自的工作流程，把一整圈敏捷做完：PRD、架構、故事、衝刺。
- 你要那道就緒關卡，以及這個方法附帶的產品、架構與測試幾種視角。
- 你在把團隊下提示詞的方式定成標準，而這個方法的技能就是那套標準。
以下情境適合使用 SpecScore……
- 標題、連結或狀態錯了，規範就得讓 CI 失敗，就算那天沒有人跑 BMAD 工作流程。
- 你需要跨工具都穩得住的需求識別碼，而不是只活在某一種方法的故事檔裡。
- 你希望有一種開源格式，讓另一種流程也可以對準它。
流程可以寫出這種格式。
BMAD 回答的是「我們要怎麼把工作跑起來」。SpecScore 回答的是「哪一份檔案才是契約，CI 又怎麼知道它還完好」。團隊可以留著 BMAD 的 PRD 和故事來談事情，再留一份 SpecScore 功能，放那些一定要通過檢查的需求。
循環留在 BMAD Method。拉取請求要檢查的那份產物，留在 SpecScore。
來源。
下方公開頁面讀於 2026 年 10 月 30 日。價格、方案名稱和發布線會改變。
回饋
本對比基於公開文件與原始碼。發現不準確或過時的資訊？請 提交勘誤 issue. 希望我們將 SpecScore 與其他工具對比？請 提交請求.