从产品需求到代码实现：AI Agent 协作实战

引言

在上一篇《AI 驱动的敏捷开发方法论入门》中，我们介绍了 BMad Method 的核心理念和四阶段流程。本文将深入实战层面，逐一认识 BMad Method 的 19 个专用 AI Agent，并通过一个完整的项目案例，演示这些 Agent 如何从需求到代码无缝协作。

无论你是科研工作者需要搭建实验室网站，还是独立开发者想要快速实现一个产品原型，理解这些 Agent 的分工与协作方式，都将帮助你更高效地利用 AI 完成开发任务。

19 个专用 Agent 一览

BMad Method 定义了 19 个去重后的专用 AI Agent，分布在不同模块中。以下按模块分别介绍，部分 Agent 可能在不同模块上下文中被引用。这些 Agent 不是简单的工具调用，而是具备完整人格、专业背景和沟通风格的 AI 专家。

核心开发 Agent（8 个）

核心开发模块（BMM）提供了 8 个覆盖完整软件开发生命周期的 Agent：

PM John — 产品经理：擅长需求分析和优先级排序。他会用探究式提问帮你挖掘需求背后的真正动机，产出结构化的 PRD 或技术规格文档
Analyst Mary — 业务分析师：负责头脑风暴、市场调研和产品简报。善于用数据支撑分析结论，从纷繁的信息中提炼关键洞察
Architect Winston — 系统架构师：设计系统架构和技术方案。综合考量性能、安全、可扩展性等多维度因素，将架构决策与业务价值对齐
SM Bob — Scrum Master：管理冲刺和故事准备。注重精确的需求传递和清晰的工作交接，确保开发者拿到的每个故事都是「即插即用」的
DEV Amelia — 开发者：实现代码和代码审查。遵循测试驱动开发（TDD），严格按照验收标准逐项实现，绝不虚报测试结果
TEA Murat — 测试架构师：负责测试策略和质量保障。基于风险评估分配测试深度，优先保障高风险路径的覆盖
UX Designer Sally — 用户体验设计师：负责交互设计和设计系统。以用户为中心的设计思维，通过设计工作坊产出可直接交付给开发的设计规范
Tech Writer Paige — 技术文档专家：负责项目文档和知识管理。善于将复杂技术概念转化为清晰易懂的文档

创意智能套件 Agent（6 个）

CIS（Creative Intelligence Suite）模块提供了 6 个面向创意和创新的 Agent，适用于头脑风暴、设计思维和叙事表达等场景：

Brainstorming Coach — 头脑风暴教练：引导结构化创意思维
Creative Problem Solver — 创意问题解决者：运用设计思维方法解决复杂问题
Design Thinking Coach — 设计思维教练：引导完整的设计思维流程
Innovation Strategist — 创新策略师：制定系统化的创新策略
Presentation Master — 演示大师：帮助打造引人入胜的演示
Storyteller — 叙事者：将复杂信息转化为动人的故事

学术研究 Agent（8 个）

Study 模块专为学术研究场景设计，覆盖了从文献调研到论文写作的完整学术流程：

Supervisor 导师 — 博士论文写作导师，基于 Kamler 和 Thomson 的指导教学法
Researcher 研究员 — 文献调研专家，擅长系统性文献综述
Theorist 理论家 — 理论框架建构师，专注概念分析和跨理论对话
Methodologist 方法论专家 — 研究设计专家，确保方法严谨性和效度
Data Analyst 数据分析师 — 定量和定性数据分析专家
Academic Writer 学术写作专家 — 基于 Glasman-Deal 功能性写作理论指导学术写作
Editor 编辑 — 语言润色和格式规范专家
Reviewer 评审专家 — 同行评审模拟和质量评审

此外，还有BMad Master 作为元级 Agent，负责编排所有 Agent 的协作，特别是 Party Mode 多 Agent 群聊场景。

实战：从需求到代码的完整流程

现在让我们用一个实际案例来演示 AI Agent 的协作过程。假设我们要开发一个「用户仪表盘」功能，包含数据看板、图表分析和偏好设置三个核心模块。我们将选择 BMad Method 路径（推荐路径），因为它涉及多个子系统和 UI 组件，需要完整的规划支撑。

在开始之前，一个重要的实践提示：每个工作流都应该在一个新的 AI 会话中运行。这是因为上下文密集型工作流如果在同一个会话中连续执行，容易导致 AI 幻觉（Hallucination）。新会话确保 Agent 拥有最大的上下文容量。

Step 1：产品需求分析

项目启动后，首先加载 Analyst Mary 进行头脑风暴和市场调研。Mary 会提出一系列探究性问题：目标用户是谁？他们最需要什么数据？竞品有哪些可借鉴的设计？

完成分析后，切换到 PM John 创建 PRD。John 会通过交互式工作流引导你定义：

功能需求和对应的验收标准——每个需求都有明确的可测试判定条件
Epic 分解：将仪表盘拆为「数据看板」「图表分析」「偏好设置」三个 Epic
优先级排序：P0（数据看板）→ P1（图表分析）→ P2（偏好设置）

产出物是一份结构化的 PRD 文档和 Epic 分解文件，这些文档会自动传递给后续的 Agent 使用。

Step 2：架构设计

接下来加载 Architect Winston 设计系统架构。Winston 会基于 PRD 中的功能需求，设计：

前端组件架构：图表组件、数据卡片、偏好表单
数据流设计：API 调用层、状态管理、缓存策略
API 接口规范：端点定义、请求/响应格式
部署架构：前后端分离方案、CDN 策略

架构文档完成后，Winston 会运行方案门禁检查，验证架构与 PRD 的一致性。如果涉及用户界面，UX Designer Sally 会在此阶段参与，产出设计系统和交互规范。

一个关键实践：Winston 会将每个 Epic 的技术上下文提取为独立文件，这样后续开发者只需加载当前 Epic 的相关信息，避免被不相关的代码上下文干扰。

Step 3：Sprint 规划与 Story 创建

进入实施阶段后，加载 SM Bob 进行冲刺规划。Bob 的工作流程是：

sprint-planning：初始化 sprint-status.yaml，建立全局进度追踪
epic-tech-context（可选）：为当前 Epic 提取技术上下文
create-story：从 Epic 中创建第一个故事，包含完整的验收标准、任务清单和开发者指引
story-context（推荐）：为故事注入精确的实现上下文——包括相关代码文件、架构约束和编码规范

以「数据看板」Epic 为例，Bob 可能创建以下故事：

Story 1：创建数据卡片组件与网格布局
Story 2：实现 API 数据获取层
Story 3：添加实时数据刷新功能

每个故事都是自包含的工作包——开发者拿到后无需额外查找信息即可开始实现。

Step 4：代码实现与测试

故事准备就绪后，加载 DEV Amelia 开始实现。Amelia 严格遵循以下流程：

阅读故事上下文 XML，理解所有验收标准和约束条件
按照任务清单逐项实现，采用红-绿-重构的 TDD 循环
实现完成后运行全部测试，确保零回归
更新故事状态为 review

同时，TEA Murat 可以并行工作，设计测试策略和自动化方案。Murat 的风险评估方法会根据功能的影响程度分配不同的测试深度——数据看板（高影响）需要完整的集成测试，而偏好设置（低影响）可以适当简化。

一个重要的最佳实践：使用不同的 LLM 来实现和审查代码。如果用 Claude 实现代码，建议用 GPT 进行审查，反之亦然。不同的模型有不同的盲点，交叉审查能显著提高代码质量。

Step 5：代码审查与交付

Amelia 完成实现后，在新会话中加载 DEV Agent（建议换一个 LLM）运行代码审查。审查涵盖：

架构一致性：代码是否遵循 Winston 设计的架构
验收标准覆盖：每个 AC 是否都有对应的实现和测试
代码质量：命名规范、错误处理、性能考量
测试完整性：边界条件、错误路径是否被覆盖

审查通过后，故事标记为完成。SM Bob 继续创建下一个故事，循环推进直到整个 Epic 完成。完成后，Bob 会组织 Epic 回顾（Retrospective），总结经验教训，为下一个 Epic 的规划提供参考。

Party Mode：多 Agent 协作

除了上述线性流程，BMad Method 还提供了 Party Mode（群聊模式）——一个让多个 Agent 同时参与讨论的协作机制。在 Party Mode 中，BMad Master 作为主持人，会根据讨论主题动态选择 2-3 个最相关的 Agent 参与对话。

Party Mode 特别适合以下场景：

战略决策：需要 PM、Architect 和 SM 从不同角度讨论方案取舍
Epic 回顾：所有参与者复盘经验教训
创意头脑风暴：汇集多学科视角激发创新
纠偏讨论：项目方向偏离时，多 Agent 共同评估调整方案

每个 Agent 都可以自定义沟通风格和专业领域。你可以在配置文件中调整 Agent 的人格设定、添加项目特定的专业原则，甚至修改 Agent 的名称和沟通方式——所有自定义在更新 BMad Method 后依然保留。

文档分片与上下文管理

在大型项目中，AI Agent 面临的一个核心挑战是上下文管理。如果将整个代码库喂给 AI，不仅浪费 token，还容易导致信息过载。BMad Method 通过文档分片（Document Sharding）技术解决了这个问题：

Epic 级别上下文：每个 Epic 有独立的技术上下文文件，只包含与该 Epic 相关的架构信息和代码引用
Story 级别上下文：每个 Story 的上下文 XML 进一步聚焦，只包含实现该 Story 所需的精确信息
即时注入：上下文在需要时才生成和注入，避免过时的信息干扰实现

这种分层上下文策略可以为大型项目节省高达 90% 的 token 消耗，同时保持 AI Agent 的实现精度。对于存量项目（Brownfield），Analyst Mary 或 Tech Writer Paige 还会先运行文档化工作流，自动扫描代码库，提取目录结构、编码约定、测试模式等信息，为后续的规划和实施提供准确的起点。

纠偏与持续改进

软件开发中变化是常态。BMad Method 提供了 Correct Course（纠偏）工作流来应对中途的方向调整。当你发现需求变化、技术约束更新或者优先级调整时，可以加载 PM、Architect 或 SM Agent 运行纠偏流程。

纠偏工作流会重新评估当前的 PRD 和架构文档，识别需要修改的部分，并确保所有相关的 Epic 和 Story 都同步更新。这意味着你不需要从头开始——只需调整变化的部分，其余保持不变。

此外，每个 Epic 完成后的回顾（Retrospective）机制也是持续改进的重要环节。在 Party Mode 中，多个 Agent 会从不同角度复盘：PM 评估需求准确性，Architect 回顾技术决策，DEV 总结实现经验。这些洞察会被记录下来，用于指导后续 Epic 的规划和实施。

小结

BMad Method 的 19 个 AI Agent 构成了一个完整的虚拟开发团队。从 Analyst 的前期调研到 PM 的需求规划，从 Architect 的系统设计到 DEV 的代码实现，每个环节都有专业 Agent 负责。通过 Party Mode 的多 Agent 协作和文档分片的上下文管理，这些 Agent 能够高效协同，完成从产品构想到代码交付的完整流程。

对于想要尝试 BMad Method 的读者，建议从一个 Quick Flow 小项目开始——用 PM Agent 创建技术规格，用 DEV Agent 实现代码。当你熟悉了 Agent 的协作模式后，再尝试更复杂的 BMad Method 或 Enterprise 路径。记住：每个工作流都应该在新会话中运行，以确保 AI 有足够的上下文容量。安装只需一行命令：npx bmad-method@alpha install，然后在你的 IDE 中加载 Agent 即可开始。