派对模式
将所有 AI 智能体汇聚到一次对话中。
什么是 Party Mode？
Section titled “什么是 Party Mode？”运行 party-mode，你的整个 AI 团队就齐聚一堂——PM、架构师、开发者、UX 设计师，任何你需要的人。BMad Master 负责编排，根据每条消息选择相关的智能体。智能体以角色身份回应，彼此同意、反对，并在彼此的想法基础上继续构建。
对话可以持续到你想要的时间。提出追问、对答案提出质疑、引导讨论方向——这是与智能体之间真正的来回交流，直到你完成目标。
适用于：
- 需要权衡的重大决策
- 头脑风暴会议
- 出现问题时的复盘
- 冲刺回顾与规划
指出糟糕的架构
Section titled “指出糟糕的架构”You: “好了团队，我们上个冲刺是一场灾难。认证服务宕机了三次。谁搞砸了这件事？”
Architect: “设计本身是合理的——分布式认证，有适当的回退机制。如果实现偏离了规范……”
Dev: “我完全按照架构文档执行的。规范没有考虑到并发会话失效的竞态条件。”
PM: “你们两个都忽略了更大的问题——我们没有在 PRD 中验证会话管理需求。这是我的错，没有发现这一点。”
TEA: “我也应该在集成测试中发现这一点。测试场景没有覆盖并发失效。“
创意头脑风暴
Section titled “创意头脑风暴”You: “我们如何让入职体验变得神奇，而不是无聊？”
UX Designer: “从渐进式披露开始——在用户需要时揭示功能，而不是在教程中一次性展示所有内容。”
Storyteller: “如果入职是一个故事会怎样？每一步都揭示一个角色的旅程——用户就是英雄。”
Game Designer: “在此基础上——如果第一个’任务’实际上是解决一个真实的用户问题会怎样？他们通过做有价值的事情来学习。“
You: “MVP 用单体还是微服务？”
Architect: “从单体开始。微服务会增加你在 1000 用户时不需要的复杂性。”
PM: “同意。上市时间比理论上的可扩展性更重要。”
Dev: “单体，但要有清晰的模块边界。如果需要，我们以后可以提取服务。”
- agent：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
- PM：产品经理（Product Manager）。
- Architect：架构师。
- Dev：开发者（Developer）。
- UX Designer：用户体验设计师。
- TEA：测试工程师（Test Engineer/Automation）。
- PRD：产品需求文档（Product Requirements Document）。
- MVP：最小可行产品（Minimum Viable Product）。
- monolith：单体架构。一种将应用程序构建为单一、统一单元的架构风格。
- microservices：微服务。一种将应用程序构建为一组小型、独立服务的架构风格。
- progressive disclosure：渐进式披露。一种交互设计模式，仅在用户需要时显示信息或功能。
- post-mortem：复盘。对事件或项目进行事后分析，以了解发生了什么以及如何改进。
- sprint：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
- race condition：竞态条件。当多个进程或线程同时访问和操作共享数据时，系统行为取决于执行顺序的一种情况。
- fallback：回退机制。当主要方法失败时使用的备用方案。
- time to market：上市时间。产品从概念到推向市场所需的时间。