Architecture Journal
BMad Method 是什麼？AI 開發中的規劃、實作與檢查
AI coding agent 寫得出程式，不代表它掌握了需求脈絡。需求散在 issue、對話和程式碼裡；換個 session，背景、限制和已做的決策就可能得重講。
BMad Method 想補上這段落差：把需求、決策和工作進度留下來，讓後續工作能沿用同一份脈絡。它為 AI coding tools 提供一組可組合的 skills；小而明確的修改可以直接實作，範圍較大或意圖未明的工作才增加規劃。[1]
BMad 怎麼從需求走到實作？
BMad 官方把 skills 分成兩類：一類協助探索想法、研究、檢驗假設和記錄決策；另一類接收變更意圖，調查程式碼與相關脈絡，再規劃、實作和檢查成果。兩類可以分開使用，不必每次都跑完整流程。[1]
核心建置 skill bmad-build 可以從一句需求、issue、規格或 ticket 開始。它先讀程式碼和既有規劃資料，再依意圖缺口、不可逆操作和變更範圍選擇流程：情況單純時，用簡短計畫在同一個 session 實作；需要釐清重要問題時，先寫完整計畫，等人確認後再動手。完成後，流程會安排獨立審查、修正屬於這次變更的問題，並讓人檢查摘要或 diff。[3]
官方 Workflow Map 把工作整理成 Analysis、Planning、Solutioning、Implementation 四個階段，其中 Analysis 是可選的。明確的小改動可以直接進入實作；較大的工作才逐步補上需求、設計、架構和工作拆分。這些資料讓下一個 session 能接續已做的決策，而不必每次從頭重建脈絡。[4]
簡化來看，建置流程是：需求與程式現況 → 合適的規劃 → 一個工作單位（例如一項 ticket）→ 實作與檢查 → 人確認結果。較大的工作會拆成多個單位，逐一完成並沿用前面留下的決策。[3] [4]
BMad 為什麼跟 Agile 有關？
BMad 官方稱它為 Agile AI-Driven Development。這裡的 Agile，不是替 AI 安排幾個角色，也不是每個專案都照固定儀式跑完一輪，而是讓流程依變更大小調整。官方也說明，可以整套採用 BMad，或把 brief、specification、architecture 等產出帶進既有交付流程。[2]
這和 Agile Manifesto 的幾項原則相呼應：及早、持續交付有價值的軟體；歡迎需求變動；定期回顧並調整做法。BMad 把這些方向放進 AI 協作流程，依實作和審查結果修正下一步。這是根據雙方官方文件做的對照；BMad 不等於 Scrum，也不要求每項工作都採用 sprint 或完整的敏捷儀式。[1] [6]
規劃有成本，也有適用範圍
完整的 PRD、架構文件和 ticket tree 會增加前置工作，也不保證規格正確。文件過期時，agent 甚至可能更有把握地走錯方向。因此，小而明確的修改不一定需要完整規劃；跨系統、需求不清或需要團隊共同決策的工作，才值得多花時間把問題和決策寫下來。[3]
流程也不會取代工程判斷。自動審查會處理屬於本次變更的發現，既有且無關的問題則留待後續；人仍要確認需求、測試結果和審查發現，並檢查摘要或 diff。[3]
自動化程度更高的 bmad-build-auto 每次只處理一個工作單位，不會自行挑選下一個 ticket 或管理 backlog。跨 ticket 的派工需要人或外層 orchestrator（派工者）負責；這項流程也需要能啟動 subagent（子代理）的 coding tool，並建議搭配版本控制。[5]
我還沒實際使用 BMad。讀官方文件時，我想到 Codex Subagent Delivery Demo 和 Figma-to-Code 之前：先建立 Design Evidence Pack：兩個案例都先留下需求、設計依據和決策，再把實作拆成可交接、可驗證的單位。這和我對規格驅動開發（SDD）的理解相通：規格應該一路支援實作與驗證。
導入時先挑一個真實變更
先拿一個範圍明確、又值得檢查的 bug 或功能修正試跑。觀察 agent 是否讀對程式碼、計畫是否抓到驗收條件、實作是否符合規格，以及審查能否提出可採取行動的發現。
如果試跑後能減少反覆交代背景，再挑一個跨模組或需求尚未釐清的任務，看看較完整的規劃能否降低返工。小型文案修正或一眼就能驗收的調整，直接請 coding agent 修改通常更省事。依交接成本、返工情況和審查品質，判斷是否擴大使用。