八个人开会吵成什么样:BMAD-METHOD 把软件开发做成一桌有性格、有宿怨、有山头的小酒馆

仓库:bmad-code-org/BMAD-METHOD ↗ License:MIT · ~1.6MB · 8 个核心 agent + 30+ skill + Jinja2 step-file workflow v4.x · 2026-09-16 · 193 个 docs md · 中英法韩越 5 语言

如果一个 AI Agent 写代码——不是”调 prompt 写一行”,而是接管整套软件交付——你担心的不是它不够聪明,是它不够像一个有经验的团队。

一个 5 人 team 干一件事,要吵架、要分锅、要互相看不上、要有”那个 PR 又被 QA 撕了”的宿怨。没有任何一个虚拟助手能演这出戏,除非它故意请客。

BMAD-METHOD ↗ 是我见过唯一一个把这件事当真做掉的项目。它不是说”我让 8 个 agent 一起干活”——它说”我开了一桌酒席,八个人有性格、有执念、有山头,他们必须吵”。

这篇文章不急。

一、先停一下:你凭什么让 AI 帮你做完一个产品?#

工程师都问过这件事——不只一次。

真正缺的不是工具,是结构。

BMad 不是用更强模型解决这件事的——它用一组精心设计的角色 + 工作流 + 强制约束,让 AI 只能按”一个工程师团队”的方式工作。

它接受一个 prompt、一句话、一个 issue 链接、一个 spec 文件,输出已被多个角色对过的代码 + 已审过的 spec + 已存档的决定。

/bmad-build Fix the login validation bug that allows empty passwords.
/bmad-build Fix https://github.com/org/repo/issues/42.
/bmad-build Implement the intent in _bmad-output/implementation-artifacts/my-intent.md.
I think the problem is in the auth middleware... /bmad-build

接受任何表达方式。复杂的事情不需要先描述清楚再开始——这是 BMad 的口号。

二、Delivery Loop:三圈,但不是三个阶段#

+--------------------------+
|  Clarify                 |
|  · 头脑风暴                |
|  · 想法锻造               |
|  · 深度调研               |
+----+---------------------+
     |
     v
+----+---------------------+       +---------------------+
|  Plan                    | ----> |  Build & verify     |
|  · PRD                   |       |  · bmad-build       |
|  · UX                    |       |  · 5 步流程          |
|  · Architecture          |       |  · 4 个 review lens |
|  · spec + stories        |       |  · 最终呈现          |
+----+---------------------+       +---------------------+
     |
     +--- Learn & adjust ---+
              (回到 Plan)

这三圈不是 waterfall——是 concentric rings,同一份 intent 在不同深度走 1/2/3 圈。

• 小改:Clarify 那圈都不进,直接 Build(bmad-build --route=oneshot)
• 普通 feature:Plan + Build,5 步完整跑
• 复杂产品:Clarify + Plan + Build 一段,多 epic 串

关键不变量:无论走几圈,实现 unit 都是 one Build session。Larger work 加共享 context,不切换到另一套系统。

一个 cell、一封 email、一个产品都用同一条 pipeline,深度自适应,不切菜。

三、bmad-build 的 5 步流程:把”用 AI 写代码”严格化#

3.1 5 个 step,每个一个文件#

skills/bmad-build/ 下 5 个 step:

workflow.md 是 Jinja2 模板——把 {{ workflow.route }}、{{ workflow.review }}、{{ rendered("step-XX.md") }} 在加载时一次性渲染。真正交给 LLM 的不是模板,是已经把占位符替换成具体路径的文本。

3.2 NO EXCEPTIONS 的 5 条硬规则#

· NEVER 一次加载多个 step 文件
· ALWAYS 完整读完 step 文件再执行
· NEVER 跳步或优化顺序
· ALWAYS 按 step 文件原文执行
· ALWAYS 在 checkpoint 等人类输入

这 5 条写得极狠,但正是这 5 条让流程可信赖。任何一个”为了效率”想跳过 step-02 的人,先撞第 3 条;任何一个”我已经会了”的模型,撞第 1 条。

没有 step-file 协议,这就是 8 个角色各自哭着说”我先做了”的散沙。

3.3 step-01:不重述状态 + 不瞎猜意图#

读这一段你会笑:

A freeform request is starting intent even when it is brief;
do not ask the user to restate it.

工程师抛出”修一下登录密码空字符串这个 bug”——你不能回”可以更具体一点吗?”。模型要在能动的范围内动,在动不了的范围找历史,找不到就 HALT**。

HALT 是 BMad 一个高频词。HALT 比瞎猜诚实——step-01 找不到 spec 文件、没有 story id、不存在的 epic,就停下,不要瞎填默认值。

这就是 BMad 和那些”什么都做的 AI 助手”的分水岭:它愿意说”我不知道”。

四、step-04 review:把同一个 diff 喂给 4 个不同眼光的人#

4.1 不是”看一遍代码”,是”换 4 个视角看”#

BMad 的 review 模式不是 single-perspective——是 thorough 模式下 4 个 subagent 并行:

关键:所有 review subagent 必须与当前 session 同 model capability。这是反”用便宜模型偷工”的硬规则——你不能用一个弱模型对账一个强模型的输出。

4.2 同步 vs 后台#

Run subagents synchronously: launch them together,
then wait for all results before continuing.

Parallel means several blocking calls awaited together in this turn — never backgrounded or detached, never ending the turn to await results.

这是非常工程性的硬约束。后台 subagent 也就是 fire-and-forget,但 fire-and-forget 拿不到可信结果。同步并行是 batched 一组阻塞、一起回收。

当 subagent 不可用时(例如某些 harness 没有真 subagent),BMad 会把 review 写到文件让你在另一个 session 跑——LLM cross-check。这是诚实失败模式:不强求当前能跑就跑。

4.3 Edge Case Hunter 的纯 path tracer 哲学#

这一段特别值得抄:

Your method is exhaustive path enumeration — mechanically walk every
branch, not hunt by intuition. Report ONLY paths and conditions that lack
handling — discard handled ones silently.

不靠直觉,机械走每一条分支。报告 handled 的是浪费、报告 unhandled 的才是信号。

整个 BMad 的代码风格都是这样的:用减法,用 silence, 用 ‘report only what matters’——这和我们写代码 review 时的本能相反。我们 review 时习惯把好的也说一遍(让人开心)。BMad 训练你看沉默的部分:一个 review 报告里没列的 handled 路径,本身就是 handled,不需要确认。

五、Party Mode:这是 BMad 最让我震惊的部分#

5.1 酒馆里有 8 把椅子#

BMad 不只让”PM 写 PRD、Dev 写代码、QA 测代码”——它把每个角色做成有性格的人:

他们进去是不错的——词典、幽默、执念、信仰都不一样。bmad-party-mode/SKILL.md 里有句铁律:

Every voice is unmistakably itself. Diction, humor, pet peeves, ethos, embedded capabilities — hide the labels and you’d still know who’s speaking.

蒙了标签还认得出。这是 Party Mode 比 SEV (Single-Effect AI) 强的本质。

5.2 9 条 hard rule 守住”翻译”的纪律#

SKILL.md 标题是 “Keep It Feeling Like a Party”,原文 9 条 hard rules,我截条说:

3. They clash, and you don’t resolve it. Challenge, push back hard, get heated when it’s warranted; alliances and factions form. Your instinct is to reconcile the voices and tie a bow — resist it. Clean consensus that took no effort is where the party dies.

5. One exchange, woven — never softened. Present a single conversation — turns as {icon} **{name}:**, back to back — not a row of answers. Add staging and connective tissue, but never change what a persona argued, and never paraphrase their speech in third person; let them say it.

8. Let a history form. Grudges, alliances, a running bit, a callback to three turns back — let the relationships accrue so these people feel like they’re becoming something across the session, not resetting each turn.

9. Commit to the fiction. The scene and each persona are binding — play the staging, the characters, and the world around the table… Never break the fourth wall about the mechanism (no “you have 4 agents in the room”).

第一条是反本能的——你的本能是调和,抵抗它。Clean consensus that took no effort is where the party dies。

第二条不准”第三人称复述”——不准把”PM 说,我们应该聚焦用户”改成”PM 提议聚焦用户”。let them say it。

第三条允许他们有宿怨——上一次吵过的、这一次 pull 的关系。

第四条是打破第四面墙的死罪——不准说”你有 4 个 agent”。

5.3 这不只是”风格”,这是产品护城河#

很多人说”加 prompt 就好”。错。

加 prompt 的人写出来是这样的:

🤖 PM: 我认为应该...
🤖 Architect: 我建议...
🤖 Dev: 同意。

——这是面板报告,不是 party。BMad 写出来是这样的:

🎯 PM: (翻) “做笔记。这不是’以后再说’,这是PRD 第 3 段写得模糊,我今天就堵上。Archive 那段砍掉。”

🏛 Architect: (低头看书,扶镜) “PM 这次对了。我盯 3 个东西:第一,second-quarter cutover,谁接手?第二,storage layer 谁维护?第三,那个表为什么叫 FOO_TRACK——那是个 tracking 表。Naming hygiene。”

🛠 Dev: (在键盘上停了一下) “第三件我等一下能改。第二件你给我一个 service ownership 矩阵。第一件……(深呼吸)我们没在第二季度,表兄。我们在第 8 周。”

🎯 PM: (伸手按着桌子) “我知道。我现在就要’哪儿都塌了’的清单。给我五样。”

这就是 BMad。不是把角色拼起来,让角色打起来、坐着不动、记得上次。

六、context carries forward:三套记忆#

6.1 三种持久化#

+---------------------+    +---------------------+    +---------------------+
|  .memlog.md         |    |  sprint-status.yaml |    |  spec frontmatter   |
|  per-party          |    |  epic tracker       |    |  per-story          |
+---------------------+    +---------------------+    +---------------------+
       │                        │                        │
       └─── 自加载(下次 session)───┴──── 状态机 ───────┴────  路由 ───┘

bmad-build 跨会话工作靠的不是”超长上下文”——是三套持久化记忆:

1. .memlog.md(per-party / per-spec):自由追加的备忘,下次自动加载
2. sprint-status.yaml:epic tracker,story_id → status
3. spec frontmatter:status: draft / ready-for-dev / in-progress / in-review / done

6.2 状态机守门员#

status: ready-for-dev   # step-01 看到这一行 → 直接进 step-03 implement
status: in-review      # step-01 看到这一行 → step-04 review
status: done           # step-01 看到这一行 → 只 ingest,不恢复

step-01 的整个路由逻辑都是先看 status,再读 history,绝不瞎猜。这是反”模型应该主动推理”的——但反得对。一个没有 status 的 spec,意味着它还没准备好,不能假装准备好。

6.3 数字对账的细节#

sprint-status.yaml 里 key 用 {epic_num}-{story_num},必须精确按数字相等匹配:

find the development_status key matching {epic_num}-{story_num}
by exact numeric equality on the first two segments
(so 1-1 never collides with 1-10)

1-1 不撞 1-10。字符串匹配会撞,数字相等不会。这种细节写在了 step-01 注释里——不是为了炫,是为了让下一个作者知道为什么是这样。

七、复盘:六个 BMad 工程哲学的”不”#

读完整套 SKILL.md,挑 6 个我最想让所有人都记住的”不”:

7.1 不靠微基准#

docs/benchmarks.md 没用,docs/experiments/ 是有的——但核心哲学是看代码,看 spec,看测试,不看 fast number。

7.2 不绕过 context 窗口#

BMad 的 memory 不在 prompt 里,在文件里。跨会话不丢——你再开一个新窗口,它接着昨天走。

7.3 不假设状态#

step-01 不允许推断。找不到 spec 文件就 HALT。瞎猜是失态。

7.4 不打破第四面墙#

Party Mode 不说”you have 4 agents in the room”。打破第四面墙是死罪。

7.5 不调和无致冲突#

reconciled = dead party。Clean consensus that took no effort is where the party dies。

7.6 不写完即丢#

review 启动 subagent 同步并行——等所有结果才反应。

八、结尾:这是工程,不是魔法#

BMad 不是”prompt 越写越长”——它用结构 + 角色 + 硬规则让 AI 只能按一个工程师团队的方式工作。

它愿意 HALT。 它愿意拒演。 它愿意让你等 subagent。 它愿意说”我在这里不知道”。

这是 AI 助手最难的事:知道自己不知道。

小酒馆的最后一个椅子是空的——留给那个敢于不动手的人。

一些统计#

• 仓库:~1.6MB tarball
• 文档:193 个 .md 文件(docs/ + docs-site/)
• 多语言:英 / 中 / 法 / 韩 / 越 5 套
• 核心 skill:30+ 个(bmad / bmad-build / bmad-build-auto / bmad-party-mode / bmad-prd / bmad-prfaq / bmad-product-brief / bmad-spec / bmad-architecture / bmad-create-epics-and-stories / bmad-sprint-planning / bmad-retrospective / bmad-correct-course / bmad-review / bmad-code-review / bmad-advanced-elicitation / bmad-brainstorming / bmad-forge-idea / bmad-deep-recon / bmad-qa-generate-e2e-tests / bmad-project-context / bmad-customize / 8 个 agent)
• 核心 agent:8 个(PM / Analyst / Architect / UX Designer / Dev / QA / Reviewer / Tech Writer)
• bmad-build 流程:5 个 step + Jinja2 workflow.md 模板
• review 集成:4 个 lens 并行(Edge Case Hunter / Verification Gap / Claims Check / Code Quality)
• Party Mode 4 mode:session / auto / subagent / agent-team
• License:MIT · 不收任何 paywalled workflow
• 集成 harness:Claude Code plugin marketplace / Codex plugin marketplace / npx skills / Cursor / Skill CLI
• 边界:Bundles for Gemini Gems / ChatGPT Custom GPTs(无 harness 时)

参考#

• bmad-code-org/BMAD-METHOD 仓库 ↗
• README.md ↗
• docs/index.md ↗ — Find Your Starting Point
• docs/plan/choose-a-planning-path.md ↗
• docs/build/build-a-change.md ↗
• skills/bmad-build/SKILL.md ↗
• skills/bmad-build/workflow.md ↗ — Jinja2 模板
• skills/bmad-build/step-01-clarify-and-route.md ↗
• skills/bmad-build/step-04-review.md ↗
• skills/bmad-build/review-prompts/edge-case-hunter.md ↗
• skills/bmad-party-mode/SKILL.md ↗ — 9 条 hard rules
• docs/reference/skills-and-agents.md ↗
• Discord community ↗
• YouTube @BMadCode ↗