💡 一句話：BMAD-METHOD 把一整個敏捷開發團隊（分析師、PM、架構師、工程師、QA）變成 12 個 AI agent，掛進你的 IDE，從腦力激盪到 code review 全程有角色分工、有文件交接、有品質閘門。
📊 核心數據
| 指標 | 數值 |
|---|
| AI agent 數量 | 12+（Mary、John、Winston、Amelia…各有專長與人設） |
| 工作流 | 34+，分四階段（分析→規劃→設計→實作） |
| 支援 IDE | 30+（Claude Code、Cursor、Windsurf、VS Code…） |
| 規劃路線 | 3 條（Quick Flow / BMad Method / Enterprise） |
| 語言支援 | 英文、繁體中文、越南文、法文 |
| 授權 | MIT 開源 |
🧑💼 12+ 角色 Agent：一個虛擬敏捷團隊
BMAD 的核心不是「一個 AI 幫你寫 code」，而是一整個 AI 團隊各司其職。
Mary
商業分析師
腦力激盪、市場研究、產品簡報、PRFAQ
John
產品經理
PRD、Epic/Story 拆分、實作整備檢查
Sally
UX 設計師
使用者體驗設計、DESIGN.md、互動流程
Winston
系統架構師
技術架構、ADR 架構決策記錄、技術對齊
Amelia
資深工程師
Story 實作、快速開發、code review、sprint 規劃
Quinn
QA 工程師
測試策略、品質驗證、風險評估
🔑 關鍵差異：這些 agent 不是「prompt 模板」— 每個有自己的人設、溝通風格、決策原則，而且可客製。BMAD 甚至有 BMad Builder（BMB）模組讓你自創 agent。
📋 四階段工作流程：文件驅動的 AI 開發
每個階段產出標準化文件，成為下一階段的 context。這不是靠對話歷史記憶，而是靠可追溯的書面 artifacts。
Phase 1：分析（選用）
| 工作流 | 產出 |
|---|
bmad-brainstorming | brainstorming-report.md |
bmad-domain-research / market-research / technical-research | 研究報告 |
bmad-product-brief | product-brief.md — 策略願景 |
bmad-prfaq | PRFAQ — Amazon Working Backwards 壓力測試 |
Phase 2：規劃
| 工作流 | 產出 |
|---|
bmad-prd | prd.md + addendum.md + decision-log.md + validation-report.html |
bmad-ux | DESIGN.md + EXPERIENCE.md |
Phase 3：設計方案
| 工作流 | 產出 |
|---|
bmad-create-architecture | architecture.md + ADR 架構決策記錄 |
bmad-create-epics-and-stories | Epic 檔案 + 可執行的 Stories |
bmad-check-implementation-readiness | 閘門檢查：PASS / CONCERNS / FAIL |
Phase 4：實作
| 工作流 | 功能 |
|---|
bmad-sprint-planning | 初始化開發週期，建立 sprint-status.yaml |
bmad-create-story | 準備下一張 Story 的 context |
bmad-dev-story | 實作 Story，產出程式碼 + 測試 |
bmad-code-review | 驗證品質，通過或退回修改 |
bmad-correct-course | 處理 sprint 中重大變更 |
bmad-retrospective | Epic 完成後回顧，記錄學到的教訓 |
🛤️ 三條路線：按專案規模自適應
| 路線 | 適合 | 需求文件 | 流程 |
|---|
| Quick Flow |
bug fix、1-15 stories |
tech-spec + code |
跳過前三階段，一條 bmad-quick-dev 搞定 |
| BMad Method |
產品、平台、10-50+ stories |
PRD + Architecture + UX |
完整四階段 |
| Enterprise |
合規需求、30+ stories |
PRD + Architecture + Security + DevOps |
四階段 + 安全與維運文檔 |
🔄 Agent 之間如何協作？—「文件即合約」
BMAD 的核心設計哲學：每個 phase 的產出文件，就是下個 phase 的 context。
- Mary 產出 product-brief → John 接手寫 PRD 時自動載入
- John 產出 PRD → Winston 設計架構時知道所有約束條件
- Winston 產出 architecture.md → Amelia 開發時知道要用什麼設計模式
- 每張 Story 檔案 = Amelia 的聚焦 context，不用翻對話歷史
- Amelia 開發完 → Quinn 接手 code review，有完整的架構文件可對照
bmad-help skill 在每個 workflow 結束後自動檢查專案狀態，推薦下一步。workflow 之間用 preceded-by / followed-by 欄位確保依賴關係。
⚔️ 與其他 AI 開發框架的差異
| 框架 | 定位 | BMAD 的差異 |
|---|
| Claude Code / Codex CLI |
單一 agent，靠對話寫 code |
BMAD 是多 agent 團隊，有結構化文件交接，不是靠對話記憶 |
| OpenAI Codex Sites / Plugins |
用自然語言指揮 SaaS |
BMAD 是開發流程框架，Codex 是工作流指揮平台 — 互補 |
| Devin / Cursor Agent |
端到端 AI 寫 code |
BMAD 不是取代你寫 code，是引導你「想清楚再寫」— human-in-the-loop |
🎯 為什麼這個框架重要？
BMAD 解決了 AI 開發最根本的痛點：單一 AI agent 的對話歷史會膨脹、遺忘、幻覺。BMAD 用「文件即 context」的設計，讓每個階段有明確的輸入文件、產出文件、決策記錄 — 把 AI 從黑箱變白箱。
一位實戰開發者的評價（dev.to）：
- 「移除了 AI coding 的黑箱感 — 不是臨時 prompt，而是先產 artifacts（PRD、架構草圖、user story）再寫 code」
- 「BMAD 把敏捷紀律套到 AI 開發上 — 讓 AI 變得可預測」
⚠️ 限制與挑戰
- 學習曲線：34+ workflow 不是一個下午能學會的，需要團隊紀律
- 文件開銷：每個 phase 產出文件 = 更多 token 消耗。Quick Flow 路線是省錢方案
- IDE 依賴：目前主要支援 Claude Code / Cursor，其他 IDE 的生態仍在擴展
- 不適合所有專案：單頁改個顏色不需要跑完整四階段
- 需要 Claude 授權：BMAD 深度整合 Claude，用其他 LLM 效果可能打折
🔮 對我們的啟示
BMAD 的「文件即 context」設計，直接對應我們在 LINE 保險客服機器人和內容策展管線中的架構理念：
- 每個 phase 產出標準化文件 → 跟我們的「搜→篩→分析→發布」四階段對齊
- 多 agent 角色分工 → 我們的子 agent 也可以引入「人設 + 專長」設計
- 品質閘門（PASS/CONCERNS/FAIL）→ 可導入內容管線的品質篩選
- 三條自適應路線 → aithuc / dkyc / learn 三站可用不同路線