「先規格、後程式碼」這個理念，2026 年市面上至少有七種做法：GitHub 的 Spec Kit、BMAD-METHOD、OpenSpec、superpowers、AWS Kiro、Agent OS、Taskmaster，再加上 mattpocock/skills。它們解決的是同一個問題，差別在誰主導、多重、綁多深。
這篇是公司教育訓練的附錄整理成的文章：把這些框架放在同一張表上比，然後說明我們這種「主戰場是 legacy .NET 既有專案」的團隊，為什麼最後選了 mattpocock/skills。前面兩篇（介紹、教學）講的是它本身怎麼用，這篇補的是「為什麼是它而不是別的」。
一、它們解決的是同一個問題
Spec 驅動開發（Spec-Driven Development）一句話講完：AI 動手寫程式之前，先把「要做什麼」寫成可審查的規格。
沒有規格的 AI 開發，等於你在 review 一坨你沒參與決策的程式碼。它跑得起來，但你不知道它為什麼長這樣，改壞了也不知道該從哪裡查起。
所有這類框架的共同流程都是同一條：
flowchart LR
A([需求釐清]) --> B[規格] --> C[拆任務] --> D[實作] --> E([驗證])
差別只在三個維度：
| 維度 | 兩端 |
|---|---|
| 誰主導 | 人拿方向盤 vs. AI 角色群自問自答 |
| 多重 | 幾個可拆用的輕量 skills vs. 整套開發方法論 |
| 綁多深 | 純文字檔 vs. 專用 CLI vs. 專用 IDE |
這個領域每個月都有新工具，下面列的是目前社群討論度最高的幾套，不求完整。
二、全景圖：三種型態
| 型態 | 代表 | 特徵 |
|---|---|---|
| 方法論 / 多 agent 框架 | BMAD-METHOD、superpowers | 整套開發方法，多角色 agent 接力，自動化程度高 |
| CLI / 文件工具 | GitHub Spec Kit、OpenSpec、Agent OS、Taskmaster | 指令加固定文件結構，搭配你現有的 AI coding 工具 |
| IDE 內建 | AWS Kiro | spec 流程直接做進編輯器，體驗最順、綁定最深 |
mattpocock/skills 介於前兩者之間：一組可單獨取用的 skills，組起來是完整流程，拆開來各自能用。
三、五套主要框架逐一看
Spec Kit（GitHub 官方，開源）
- 流程固定四步：
/specify→/plan→/tasks→/implement constitution.md定義專案憲法，也就是不可違反的原則- 跨工具：Copilot、Claude Code、Gemini CLI 都能用
- 內建 git worktree 管理，多功能平行開發是這幾套裡做得最完整的
適合：greenfield、想要 GitHub 生態正規解的團隊。
代價：文件產出偏重、流程固定；對既有專案（brownfield）的導入沒有特別著墨。
BMAD-METHOD（最重量級，模擬整個敏捷團隊）
- 12 個以上的角色 agent：Analyst、PM、Architect、UX、SM、Dev、QA、Tech Writer……
- 兩階段：規劃（產 PRD、架構文件）→ 開發循環（SM 切 story、Dev 實作、QA 驗）
- 文件極完整，多團隊、大型企業場景最強
適合：greenfield 大案、需要完整 agile 文件鏈的組織。
代價：學習曲線最陡、token 消耗大。AI 角色之間自己對話，人很容易變成旁觀者。
OpenSpec（以變更提案為中心，審計導向）
- 每個變更是一份提案（proposal），核准後才實作
- Delta 標記：ADDED / MODIFIED / REMOVED，明確記錄「相對於現況改了什麼」
- 輕量，是這幾套裡對既有專案最友善的一套
適合：變更管理嚴格、需要審計軌跡的環境。
代價：只管「規格與變更」這一段，測試紀律、context 管理要自己補。
superpowers（Claude Code 生態，社群星數最高）
- 7 階段強制流程：brainstorm → spec → plan → TDD → subagent 開發 → review → finalize
- skills 自動觸發：每個任務前先檢查該用哪些 skill，流程是強制的
- 紀律極嚴：先於測試寫出的程式碼會被直接刪掉
適合：想要全自動、信任框架決策的個人開發者。
代價：主導權在框架不在人；和其他流程框架互斥，裝了就是全套。
Kiro（AWS，商用 IDE）
- VS Code fork，spec 流程做進 IDE：需求（EARS 格式）→ 設計 → 任務，全在編輯器裡追蹤
- Agent hooks：存檔、commit 等事件自動觸發 AI 動作
- 體驗最整合、上手最快
適合：願意換 IDE、想要開箱即用的團隊。
代價：商用訂閱、綁定 AWS 生態與專用編輯器；客製彈性最低。
還有這些，一句話帶過
| 工具 | 定位 |
|---|---|
| Agent OS（Builder Methods） | 三層文件（standards / product / specs）讓 agent 帶著你的 coding 規範工作，重點在「標準」而非流程 |
| Taskmaster | PRD → 任務分解與追蹤，以 MCP 形式掛進各家工具，重點在任務管理 |
| 各 IDE 內建 plan/spec 模式 | Copilot、Cursor、Claude Code 都在往內建規劃模式走。輕量，但沒有完整方法論 |
趨勢很明顯：工具彼此借鑑，「先規格後程式」正在變成所有 AI coding 工具的預設姿勢。
四、一張表比完
| Spec Kit | BMAD | OpenSpec | superpowers | Kiro | mattpocock/skills | |
|---|---|---|---|---|---|---|
| 定位 | 官方流程 CLI | 整套方法論 | 變更提案工具 | 全自動框架 | 商用 IDE | 工具箱 |
| 主導權 | 人＋流程 | AI 角色群 | 人 | 框架 | IDE 引導 | 人 |
| 自動化程度 | 中高 | 高 | 低 | 最高 | 中高 | 中（關鍵點必停） |
| brownfield | 普通 | 需專用模式 | 好 | 普通 | 普通 | 好（逐步導入） |
| 學習成本 | 中 | 高 | 低 | 中 | 低 | 低～中 |
| 綁定 | CLI＋文件結構 | 方法論全套 | 文件結構 | Claude Code 全套 | IDE＋訂閱 | 純 Markdown，可拆用 |
| 授權 | 開源 | 開源 | 開源 | 開源 | 商用 | MIT |
五、為什麼我們選 mattpocock/skills
先講我們的現實：主戰場是 legacy .NET 既有專案，業務邏輯複雜，需求常常是「這張表多一個欄位，連帶三支程式要改」這種規模。在這個前提下，五個理由：
它允許逐步導入。 挑一個小需求就能開始，不要求整個專案先「就緒」。全自動框架在 brownfield 上風險最高：它假設專案結構乾淨、測試齊全，而 legacy 專案兩者都沒有。
方向盤必須在人手上。 關鍵決策（規格、切票、測試位置）都停下來問你。BMAD 和 superpowers 的 AI 自問自答模式，在我們的業務複雜度下等於把決策外包給猜測。AI 不知道那個欄位為什麼十年前被設計成 nvarchar，但老同事知道。
純 Markdown、MIT、可 fork。 不綁 CLI、不綁 IDE、不換編輯器。可以改成公司習慣，也可以只取用其中幾個 skill。
學的是可轉移的能力。 它就是 Claude Code 原生 skill 機制的最佳實踐。學會之後，我們自己寫了 tdd-dotnet、QR 單測試 pipeline 等公司內部 skill，用的是同一套思路。換句話說，就算哪天不用這個 repo 了，寫 skill 的能力還在。
context 紀律講得最清楚。 smart zone、一票一對話、handoff，這些是其他框架很少明說的實戰知識。其他框架把 context 管理藏在自動化裡面，你不知道它什麼時候會爆；這套是直接教你怎麼管。
六、選型結論
框架沒有絕對優劣，只有「和你的現實合不合」：
- greenfield 大案、要完整 agile 文件鏈 → 看 BMAD、Spec Kit
- 變更審計嚴格 → 看 OpenSpec
- 願意換 IDE、要開箱即用 → 看 Kiro
- 既有專案、決策在人、想逐步導入、要能客製 → 我們選了 mattpocock/skills
共同底線：不管用哪套，「先規格、後程式」都比「直接叫 AI 寫」好。工具會換，這個習慣不會過期。
留言