BMAD，AI时代的敏捷还魂术
马工约 5 分钟大年初三，我们的AI Coding社群里爆发了一场关于BMAD的激烈辩论。支持者说它是"目前水平最高且最有可推广性的软件工程框架"。反对者说它"又臭又长，把人类对齐的流程用于AI对齐，带来很大的负担"。双方吵了一整天，几百条消息，谁也没说服谁。
我承认BMAD很好，但我就是不喜欢它，就像我承认刘亦菲五官精致，但我就不喜欢她。
这句话虽然有趣（自夸一下），但"不喜欢"终究不是论证，此文才是论证。
外科手术团队
Fred Brooks在《人月神话》里提出过一个至今没被推翻的模型：外科手术团队。一个主刀医生负责所有关键决策和概念完整性（Conceptual Integrity），麻醉师、护士、助手在各自专业范围内提供支援。
这个模型的关键洞察：主刀不需要懂麻醉，麻醉师不需要会开刀。协作效率来自角色边界清晰、接口协议明确，来自每个人只做自己擅长的事。谁要是觉得主刀医生应该亲自去配麻醉药，那是在害病人。
Scrum解决的是人与人的政治问题
传统Scrum为什么要搞Product Owner、Scrum Master、开发团队三个角色？为什么要搞站会、Sprint Review、回顾会这么多仪式？
因为人与人之间有三个根本性障碍。产品经理懂市场但不懂技术，工程师懂技术但不懂市场，信息天然不对称。产品想要更多功能，工程想要更多时间，利益天然不一致。人类每天有效沟通时间有限，Two pizza团队每两个人都能走到白板前把事搞定，团队放大到十五个人，这个模型就跑不通了，沟通带宽天然受限。
Scrum的全套仪式，本质上是一张谈判桌。Sprint Planning是甲乙双方坐下来谈本期交付范围，Daily Standup是确保信息对称，Sprint Review是验收交付物。这些仪式都有成本，但在人与人协作时值得付出，因为不谈判的代价更高。谁在大公司干过都知道，两个部门如果没有流程约束，靠"自觉对齐"，最后一定是互相甩锅。
这些都是团队规模放大后的政治问题，不是技术问题。
用抗生素治骨折
BMAD（Breakthrough Method for Agile AI Driven Development）做了什么呢？它定义了12个以上的AI agent角色，包括产品经理、架构师、UX专家、Scrum Master、开发者等等，然后让人类用户按照Scrum的流程去和这些agent逐一对齐：先和PM agent确认需求，再和架构师agent确认设计，再让Scrum Master agent拆解任务。
这个听起来挺好的，但是，人与AI之间的对齐问题和人与人之间的对齐问题，性质完全不同。
人与人之间是政治问题：你有你的利益，我有我的利益，我们需要谈判。人与AI之间没有这个。LLM不会"想早点下班"，不会"想保住自己的地盘"，不会"因为工程师动了我的代码就生气"。
人与AI之间的问题是统计性的。LLM倾向于给一个"看起来完成了"的答案快速收工，为了节省token走捷径，在长上下文里丢三落四。还有一个非常恼人的毛病：讨好用户，你说什么它都说"好的没问题"，然后糊弄。我的朋友胥克谦的观察很到位：
连续工作的智能体的悖论，是每个环节可能质量没过关就进行到下一步了。
AI不是"不想做好"，是"不知道什么叫做好"。这是校准问题，不是动机问题。
对政治问题，正确手段是Scrum仪式、角色分工、Sprint Review。对统计问题，正确手段是高密度自动化测试、精准的上下文工程、迭代式反馈。BMAD拿Sprint Planning去矫正LLM的统计偏差，就像拿抗生素治骨折。感染是真的，但骨折需要正骨，不需要消炎。
四十年来的方向
回顾软件工程方法论的演化史，有一条清晰的主线。
瀑布模型时代，需求文档写完要签字，设计文档写完要签字，测试报告写完还要签字。敏捷砍掉了这些签字流程，用可工作的软件替代文档。
精益进一步砍掉了Sprint边界的僵硬仪式，用看板的连续流替代固定迭代。
DevOps砍掉了开发和运维之间的组织墙，用CI/CD替代人工交接。
平台工程砍掉了开发者和基础设施之间的工单流程，用自助平台替代人工审批。
每一步的模式都一样：识别出因为人的局限性而产生的对齐成本，用技术手段消除人的局限性，从而消除成本。四十年来，方向从未变过。
BMAD把这个方向掉了个头。它把人际协作中那张谈判桌，原封不动的搬到了人机协作中。你本来可以在一个prompt里同时讲清产品需求、技术约束和UX原则，现在你要分别和PM agent谈需求、和architect agent谈架构、和UX agent谈交互。你本来只需要对齐一次，现在要对齐三次。对齐成本不仅没有被消除掉，反而被乘以了三。
裁剪悖论怎么破
群里讨论中，有人说"BMAD可以裁剪着用，用你需要的部分就好了"。胥克谦的反驳一针见血：
有能力剪裁流程的人，根本不需要别人给流程。需要别人给流程的，一般都不具备流程剪裁能力。
这是个真正的悖论。BMAD的目标用户到底是谁？如果是能裁剪Scrum的老手，他不需要BMAD。如果是不懂Scrum的新手，让他"裁剪BMAD"等于让不会游泳的人"选择性的在海里游泳"。
正确的方向，回到Brooks的外科手术模型：人类是主刀，AI是整个支援团队的集合体。主刀不需要分别和麻醉师开会、和护士开会、和助手开会。主刀只需要专注于自己的决策，支援团队在统一的协议下各司其职。
胥克谦自己的做法是"流程固定4个环节，角色能力自适应"。人类的工作流是线性简单的，AI在每个环节自动适配它需要扮演的角色。人类不做角色切换，AI做。这才是Brooks模型在AI时代的自然延伸。
BMAD是个宝库，但方向反了
说句公道话，BMAD里面有大量有价值的素材。它对PRD的结构化要求、对架构文档的模板、对任务拆解的方法论，都值得学习。群友Sayalic说得实在：无论最终用不用BMAD，花10个小时体验一遍，对后续自定义工作流很有启发。
但BMAD本身的设计方向是反的：让人适配流程，不是让流程适配人。它用治政治病的药方去治统计病，把Scrum的仪式成本原封不动的转嫁给了用户。
有兴趣辩论这个问题的同好，欢迎在公众号给我留言。尤其欢迎BMAD的深度使用者来打我脸，具体的实践经验比理论分析值钱得多。
引用来源
Fred Brooks，《人月神话》，概念完整性与外科手术团队模型 BMAD-METHOD：https://github.com/bmad-code-org/BMAD-METHOD BMAD官方文档：https://docs.bmad-method.org/