2026 年首選的規範驅動開發工具

下面把 GitHub Spec Kit、OpenSpec、Kiro、Tessl、BMAD Method、Task Master AI、CodeSpeak、Datarim、純 Markdown，還有 SpecScore 放進同一篇規範驅動開發工具對照。公開頁面與儲存庫的閱讀日是 2026年10月30日。命令、檔案怎麼擺、產品實際檢查什麼，往後都可能改；每一則說法出自哪一頁，寫在底部的來源裡。

一個儲存庫真正要分開的，是這份規範能不能自己讓 CI 失敗。SpecScore 網站那個儲存庫裡，dogfood.yml 會裝上 SpecScore CLI，並在拉取請求與推向 main 的時候執行 specscore spec lint。specstudio-skills 裡的 /score 技能，是由人動手觸發的 AI 評分，評的是一份產物。要跑，得你自己去叫。那條工作流程不會去跑。

GitHub Spec Kit

GitHub Spec Kit 是一套開放的工具組，把一條流程交給編碼代理：Specify、Plan、Tasks、Implement、Converge。Spec Kit 文件首頁所標日期為 2026年9月28日，寫明每一個階段都會產出 Markdown，下一個階段再去讀它。

那些檔案住在 specs/ 底下的功能目錄。升級指南 的閱讀日是 2026年10月30日，舉的路徑像 specs/001-my-feature/spec.md，同層還有 plan.md 與 tasks.md。代理式 SDD 參考 對 /speckit.analyze 的說法是：它彙整規範、計畫與任務之間的不一致，編成一份報告，檔案本身不會被改。/speckit.clarify 與 /speckit.checklist 是另外兩道命令，要在代理裡自己跑。文件首頁也點了社群擴充的名，其中一個叫 CI Guard，用來加上合規關卡。

授權是 MIT，公開儲存庫為 github/spec-kit。若團隊要的就是這條流程，也接受規範繼續以代理寫下的 Markdown 存在，Spec Kit 就對得上。與 SpecScore 並排的對照在 SpecScore 對照 Spec Kit。

OpenSpec

OpenSpec 出自 Fission-AI。每一次變更單獨成一個資料夾，人和代理得以在程式碼寫下之前先講定。README 的閱讀日是 2026年10月30日，裡面看得到 openspec/changes/add-dark-mode/，含有 proposal.md、一個 specs/ 目錄、design.md 以及 tasks.md。需求用純 Markdown 來寫：一句 SHALL，再加上 WHEN / THEN 情境。同一份 README 寫它能配合的 AI 助理在 30 種以上。

openspec validate 會去看變更與規範有沒有結構上的問題。CLI 參考 讀於 2026年10月30日，載明驗證失敗時以非零狀態結束，並附上一段 shell，CI 作業可以照著跑。那項檢查查的是 OpenSpec 自己的變更與規範結構。

授權是 MIT，公開儲存庫為 Fission-AI/OpenSpec。若團隊要的是那個變更資料夾，再加上那道結構檢查，OpenSpec 就對得上。見 SpecScore 對照 OpenSpec。

Kiro

Kiro 出自亞馬遜網路服務（AWS）。它是一套代理式開發環境，裡頭有編輯器、CLI 與網頁應用程式。功能規範頁 的更新日期是 2026年8月4日，帶著一項功能走完需求、設計與任務。requirements.md 採用 EARS。design.md 與 tasks.md 並排放著。快速規範（Quick Spec）一次把三步跑完，中間不設核准停點。

需求檢視（Analyze Requirements）在設計之前找出前後不一致、歧義、彼此衝突的約束，以及缺漏。這項分析是在 Kiro 裡面跑的。功能規範頁所描述的，就是這項做在產品裡的檢查。

Kiro 授權 讀於 2026年10月30日。它寫明：IDE 與 CLI 以 AWS 內容（AWS Content）授權，依據是 AWS 客戶協議（AWS Customer Agreement）或其他書面協議，再加上 AWS 智慧財產授權（AWS Intellectual Property License）。若你要的是由這項產品起草那三份檔案，Kiro 就對得上。見 SpecScore 對照 Kiro。句式見EARS 需求語法。

Tessl

Tessl 的文件 讀於 2026年10月30日，講的是一個管理代理技能的開放平台：登錄庫、治理、評測，以及相關的管控。技能、規則與說明文件，都是儲存庫裡的檔案。

另外還有一件產物，規範驅動開發 tile，發布自 tesslio/spec-driven-development-tile，並出現在 Tessl 登錄庫。tile 的 README 寫道：代理會寫下 .spec.md，放進 specs/ 目錄，帶著 YAML 前置資料、targets 以及 [@test] 連結。它也記載了 scripts/validate-specs.sh 與 scripts/check-spec-links.sh，還有專門 lint 這塊 tile 本身的 GitHub Actions。

這塊 tile 的授權是 MIT，就在該儲存庫。文件把登錄庫平台寫成 Tessl 的產品，並沒有指出整個平台的公開儲存庫。若團隊要把技能訂成標準，或想要這塊 tile 那種先寫規範再寫程式碼的引導，Tessl 就對得上。見 SpecScore 對照 Tessl。

BMAD Method

BMAD Method 儲存庫的 README 讀於 2026年10月30日，講的是一套給 AI 驅動開發用的敏捷方法。你可以整段用完，也可以把它的簡報、規範與架構帶進手邊已有的工作流程。那裡點名的穩定線是 v6.12。v7 被寫成 main 分支上的預覽。專案把名字拼作 BMad；儲存庫名稱則是 BMAD-METHOD。

README 把重心放在那些規劃產物，以及產出它們的代理技能。它沒有記載一道命令，能在 CI 裡檢查固定的規範綱要。

授權是 MIT，位於 bmad-code-org/BMAD-METHOD。那份授權檔也載有一份 BMad 的商標聲明。若團隊要的是這條敏捷循環，並打算把規範留在那些簡報與規範裡，這套方法就對得上。見 SpecScore 對照 BMAD Method。

Task Master AI

Task Master AI 是給 AI 編碼代理用的任務清單。README 讀於 2026年10月30日，建議備一份 PRD，路徑常常放在 .taskmaster/docs/prd.txt，再以 task-master parse-prd 把那段散文轉成任務。文件 涵蓋任務結構、相依與標籤。

README 把 PRD 當成輸入，任務清單才是代理據以動手的東西。它沒有描述一種檢查器，能去查 PRD 的措辭或結構。

授權是 MIT 另附 Commons Clause，位於 eyaltoledano/claude-task-master。README 寫明：你可以用 Task Master 打造產品；把 Task Master 本身拿去賣，或當成託管服務來提供，則落在這項授權之外。它適合想把 PRD 拆成任務的團隊。見 SpecScore 對照 Task Master AI。

CodeSpeak

CodeSpeak 的網站讀於 2026年10月30日，講的是一套代理式工程工具組。它從代理的聊天裡捕捉意圖，把意圖轉成對應到程式碼的結構化需求，並說每一次變更都會強制這些需求。網站也說，完整產品上線之前，有一個網頁工具可以從聊天裡把意圖找回來。

服務條款 自 2026年3月3日起生效，載明 CodeSpeak Ltd 保留該服務（Service），包含其軟體與原始碼。產品網站沒有公布這套工具組的原始碼儲存庫，所以本頁不替它指名一種軟體授權。

若團隊想在那項產品裡從對話捕捉需求，並讓需求一直對應到程式碼，CodeSpeak 就對得上。見 SpecScore 對照 CodeSpeak。

Datarim

Datarim 的 README 掛著 4.9.0 版本徽章，讀於 2026年10月30日，講的是一套給 Claude Code、Codex CLI、Cursor 與 Google Antigravity 用的迭代工作流程。/dr-prd 會產生一份 PRD。進行中的任務放在 backlog.md，做完的紀錄放在 backlog-archive.md。

你跑 /dr-compliance 時，它會拿實作去對 PRD。/dr-dream lint 則對知識庫做健康檢查，找矛盾、孤兒、壞連結、過時內容與重複項。這些都是工作流程裡的命令。

授權是 MIT，位於 Arcanada-one/datarim。若團隊想在 README 點名的那些代理上使用這些分階段命令，Datarim 就對得上。見 SpecScore 對照 Datarim。

Plain Markdown

純 Markdown 就是把規範寫成一份普通的 .md 檔案：一個標題、幾條項目，提交到你選的地方。沒有綱要。在你自己加上檢查器之前，審查就是有人去讀這份檔案。

沒有產品，也沒有可以連出去的授權檔。這份檔案的條款，就是你套在儲存庫上的那份授權。純 Markdown 適合一篇短記、一回時間有限的試做，或打算靠閱讀散文來審查的團隊。見 SpecScore 對照純 Markdown。

SpecScore

SpecScore 是規範的一種格式——功能、需求與驗收標準，寫成帶 YAML 的 Markdown——另外附一支檢查這些檔案的 CLI。格式在 specscore/specscore。CLI 在 specscore/specscore-cli。

怎樣寫出代理能夠核對的標準，見如何撰寫驗收標準。

含需求、驗收標準、計畫和任務的 Markdown 功能規格範本見Markdown PRD 範本。

用 Claude Code 和 Cursor 做規範驅動開發：功能檔案、代理指令檔，以及迴圈中的 specscore spec lint，見 用 Claude Code 和 Cursor 做規範驅動開發。

如何在持續整合裡執行這個 linter，見在 CI 中 lint 規格。

在這個網站的儲存庫裡，dogfood.yml 會裝上那支 CLI，並在拉取請求上、以及推向 main 時執行 specscore spec lint。規範若把格式寫壞，那項作業就會失敗。/score 技能是一次手動的 AI 評分：你開口要求時，它會把設定好的審查者再跑一遍；dogfood 工作流程不會去叫它。

格式的授權是 CC BY 4.0，位於 specscore/specscore。CLI 的授權是 Apache-2.0，位於 specscore/specscore-cli。若團隊需要的是：標題、連結或狀態錯了，規範就得讓 CI 失敗，不論檔案出自哪一個代理，SpecScore 就對得上。openspec validate 是此處其他工具裡最接近的結構檢查；它查的是 OpenSpec 自己的變更形狀。個別對照從 /vs/ 起頭。

怎麼挑。

想要一條有人帶路的流程，而且 Markdown 可以在拉取請求裡審查，就選 GitHub Spec Kit、OpenSpec、BMAD Method 或 Datarim。想請那項產品起草 EARS 需求，就選 Kiro。PRD 該變成任務清單時，選 Task Master AI。意圖該在那項產品裡從聊天捕捉時，選 CodeSpeak。問題落在代理技能、規範 tile 只是可選的引導時，選 Tessl。

規範檔本身必須讓 CI 失敗時，選 SpecScore。這個儲存庫裡的檢查，是 specscore spec lint，寫在 dogfood.yml。上面那份清單裡的某一條工作流程，仍然可以是規範被寫下來的方式。

來源。

閱讀日是 2026年10月30日；若某一頁自己印了更新日期，以那一頁為準。價格與方案名稱會改，所以不列。

• GitHub Spec Kit 文件（頁面日期 2026年9月28日）
• Spec Kit——代理式 SDD 參考
• Spec Kit——升級指南（specs/ 路徑）
• github/spec-kit——MIT 授權
• Fission-AI/OpenSpec——README
• OpenSpec CLI 參考——openspec validate
• Fission-AI/OpenSpec——MIT 授權
• Kiro 文件——功能規範與 EARS（更新於 2026年8月4日）
• Kiro——授權
• Tessl 文件——什麼是 Tessl？
• tesslio/spec-driven-development-tile
• Tessl 規範驅動開發 tile——MIT 授權
• bmad-code-org/BMAD-METHOD——README
• BMAD-METHOD——MIT 授權
• eyaltoledano/claude-task-master——README
• Task Master——MIT 另附 Commons Clause
• CodeSpeak
• CodeSpeak——服務條款（2026年3月3日生效）
• Arcanada-one/datarim——README（4.9.0 徽章）
• Datarim——MIT 授權
• specscore/specscore——dogfood.yml（specscore spec lint）
• specstudio-skills——/score 技能（手動 AI 評分）
• specscore/specscore——CC BY 4.0
• specscore/specscore-cli——Apache-2.0