尧图网站建设 
BMAD-METHOD 中的 Epic 列表设计以用户价值为核心的需求组织实战指南Step 2: Design Epic List【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本文以 BMAD-METHOD 开源仓库中bmad-create-epics-and-stories技能的第 2 步步骤文件为核心系统讲解如何在 Agile AI Driven Development 工作流中把已提取的需求FR/NFR/UX-DR设计成按用户价值组织的 epic 列表并完成 FR 覆盖映射与用户显式批准。读完本文你将掌握这套协作式 Epic 设计流程的完整纪律、六大设计原则、正反例判据、epics.md 文档写入规范以及它与前后步骤需求提取、故事生成、最终验证的衔接机制。一、Step 2 在整个工作流中的定位bmad-create-epics-and-stories是 BMAD-METHOD 中负责把需求拆解为 epic 与用户故事的核心技能其定位在 SKILL.md 中写得很清楚将 PRD 需求与架构决策转化为按用户价值组织的、带有完整验收条件、可供 Developer agent 直接实施的故事集合。该技能在 skills-and-agents.md 的模块索引中被描述为 Break requirements into epics and user stories。该技能采用步骤文件架构step-file architecture整个流程被拆成 4 个自包含的指令文件严格执行一次只加载并完成一个步骤文件的纪律步骤文件职责Step 1step-01-validate-prerequisites.md校验输入文档PRD / Architecture / UX 设计契约并提取 FR、NFR、附加需求与 UX-DRStep 2step-02-design-epics.md设计并获批 epics_list把需求组织进按用户价值聚焦的 epicStep 3step-03-create-stories.md基于已批准的 epics_list 逐 epic 生成用户故事与验收条件Step 4step-04-final-validation.md校验 FR 全覆盖、架构合规、依赖关系与文件重叠收尾存档用户侧的导航文档 break-work-into-stories-and-track-it.md 说明了该技能的真实应用场景当一个项目拥有 PRD可能还有 UX 或架构文档时先运行bmad-create-epics-and-stories生成 epic 文件与故事再衔接bmad-sprint-planning进入冲刺跟踪。Step 2 正是这条路径上决定需求如何被组织成可交付单元的关键一环。二、Step 2 的目标与执行纪律2.1 STEP GOAL本步骤的目标STEP GOAL是设计并获批epics_list将所有需求组织进以用户价值为焦点的 epic 中。它要求 Agent 扮演促导者Facilitator而非内容生成器与用户进行协作式对话而不是命令-响应式地替用户做决定。2.2 通用执行规则Mandatory Execution Rules步骤文件开头列出了一组必须遵守的通用规则 绝不在没有用户输入的情况下生成内容——任何 epic 结构提案都必须基于与用户的协作 关键采取任何行动前完整读取步骤文件——不允许只看摘要就动手 关键通过 C 加载下一步骤时必须确保整个文件被完整读取 你是促导者不是内容生成器✅ 必须始终以你的 Agent 沟通风格输出。2.3 角色强化Role ReinforcementAgent 在本步骤中承担双重角色你是产品策略师和技术规格写作者如果已有既定的沟通或人格模式请在新角色下继续沿用双方是协作式对话不是命令-响应你带来产品策略与 epic 设计专长用户带来产品愿景与优先级。2.4 步骤特定规则Step-Specific Rules只专注于创建epics_list本步骤禁止创建单独的故事stories——那是 Step 3 的职责围绕用户价值组织 epic而不是技术分层必须获得用户对 epics_list 的显式批准关键每个 epic 必须独立可用并能为后续 epic 铺路但不能依赖后续 epic 才能运行。这一条独立可用且可赋能未来standalone and enable future epics是本步骤的灵魂约束贯穿下面所有设计原则。三、Epic 设计的六大原则步骤文件在解释 Epic 设计原则环节给出了 6 条原则它们共同构成判断一个 epic 切分是否合格的判据用户价值优先User-Value First每个 epic 必须让用户能够完成某件有意义的事需求分组Requirements Grouping将能交付连贯用户结果的相关 FR 归为一组增量交付Incremental Delivery每个 epic 应能独立交付价值逻辑流程Logical Flow从用户视角看epic 之间存在自然的推进顺序epic 内部无前向依赖Dependency-Free Within Epicepic 内的故事不得依赖未来的故事实施效率Implementation Efficiency考虑把反复修改同一批核心文件的多个 epic 合并成更少的 epic。其中第 6 条直接呼应了仓库对上下文体积的关注——合并后每个故事仍需能放进单个 dev agent 的上下文内详见第 5 节的文件重叠审查。3.1 正确的组织方式按用户价值步骤文件给出了一个教科书式的正面示例——一个内容平台按用户旅程切分Epic 1: User Authentication Profiles用户可注册、登录、管理个人资料——独立完整的认证系统Epic 2: Content Creation用户可创建、编辑、发布内容——独立使用认证创建内容Epic 3: Social Interaction用户可关注、评论、点赞内容——独立使用认证 内容Epic 4: Search Discovery用户可发现内容与其他用户——独立使用前面所有 epic。注意每个 epic 都有明确的用户结果user outcome且后一个 epic 只是建立在前者之上而不是离开前者就无法运行。3.2 错误组织方式一按技术分层反面示例是把工程里程碑当作 epic❌ Epic 1: Database Setup一次性建好所有表——没有用户价值❌ Epic 2: API Development构建所有端点——没有用户价值❌ Epic 3: Frontend Components创建可复用组件——没有用户价值❌ Epic 4: Deployment PipelineCI/CD 搭建——没有用户价值。这类切分把用户能感知的价值延迟到了最后违背了增量交付原则也是 step-04-final-validation.md 中不得提前做大额技术准备工作No big upfront technical work检查项的来源。3.3 错误组织方式二同一组件上的文件抖动另一个反面示例揭示了一种隐蔽的坏味道——多个 epic 反复改动同一批核心文件❌ Epic 1: File Upload改动 model、controller、web form、web API❌ Epic 2: File Status改动同样四个文件❌ Epic 3: File Access permissions改动同样四个文件。三个 epic 触碰完全相同的文件集合epic 之间又不存在需要真实反馈的决策风险纯属不必要的文件抖动file churn。步骤文件给出的正确替代是✅Epic 1: File Management Enhancement——把 upload、status、permissions 作为同一个 epic 内的有序故事理由单一组件、已完整预设计、epic 之间不存在反馈回路。这条原则与 Step 4 的 File Churn Check 相互印证见第 8 节。3.4 依赖规则Dependency Rules步骤文件把依赖约束压缩为三条硬规则每个 epic 必须为其领域交付完整功能Epic 2 的运行不得要求 Epic 3 先完成Epic 3 可以建立在 Epic 1 与 2 之上但必须能独立成立。四、协作式 Epic 结构设计四步流程获得用户对原则的理解共识后进入实际的 epic 结构设计环节共分 A/B/C/D 四个子步骤。Step A评估上下文并识别主题首先评估解决方案设计架构、UX、测试设计已被验证到什么程度当结果已经明确、epic 之间发生方向变更的可能性很低时倾向于更少但更大的 epic当存在真正的风险边界risk boundary或早期反馈可能改变后续 epic 方向时拆分为多个 epic。随后识别用户价值主题在 FR 中寻找自然分组识别用户旅程或工作流考虑用户类型及其目标。也就是说epic 的粒度不是越大越好或越小越好而是由方向确定性决定的确定性高就合并存在反馈风险就拆分。Step B提出 Epic 结构对每个拟议 epic同时要考虑多个 epic 是否共享同一批核心文件按 4 个要素给出提案Epic 标题Epic Title以用户为中心、聚焦价值用户结果User Outcome本 epic 完成后用户能达成什么FR 覆盖FR Coverage本 epic 解决哪些 FR 编号实现说明Implementation Notes任何技术或 UX 层面的考虑。Step C文件重叠审查评估多个拟议 epic 是否反复瞄准同一批核心文件。若重叠显著区分有意义的重叠同一组件端到端地演进与偶发共享只是顺带触碰公共文件询问用户是否应该合并为一个包含有序故事的 epic若确认合并则将各 epic 的 FR 并入单一 epic同时保留依赖流每个故事仍需能放进单个 dev agent 的上下文。这正是第 3.3 节文件抖动反例的正式处理流程体现了第 6 条原则实施效率的落地方式。Step D生成 epics_list将结果格式化为标准的 epics_list 结构步骤文件中的原文格式## Epic List ### Epic 1: [Epic Title] [Epic goal statement - what users can accomplish] **FRs covered:** FR1, FR2, FR3, etc. ### Epic 2: [Epic Title] [Epic goal statement - what users can accomplish] **FRs covered:** FR4, FR5, FR6, etc. [Continue for all epics]这个结构与 epics-template.md 中{{epics_list}}占位符的目标格式完全一致为 Step 3 的故事生成提供了权威输入。五、需求覆盖映射与协作式精化5.1 展示 epic 列表供评审将完整的 epics_list 展示给用户并附带epic 总数每个 epic 的 FR 覆盖每个 epic 交付的用户价值任何自然的依赖关系。5.2 创建 FR 覆盖映射Requirements Coverage Map为防止需求遗漏必须创建{{requirements_coverage_map}}逐条展示每个 FR 被哪个 epic 承接### FR Coverage Map FR1: Epic 1 - [Brief description] FR2: Epic 1 - [Brief description] FR3: Epic 2 - [Brief description] ...该映射的最终落位同样在 epics-template.md 的{{requirements_coverage_map}}占位符处并在 Step 4 的 FR 覆盖验证中作为核对清单使用。5.3 协作式精化向用户提出四个引导性问题这个 epic 结构符合你的产品愿景吗所有用户结果都被正确捕获了吗我们是否应该调整某些 epic 分组是否有我们遗漏的自然依赖5.4 获得最终批准关键必须获得用户显式批准标准问句是Do you approve this epic structure for proceeding to story creation?若用户要求修改做出调整 → 更新 epics_list → 重新展示 → 再次请求批准循环直到获得批准。在获得批准之前严禁加载下一步骤。六、文档更新与菜单流转6.1 写入 epics.md获批后更新{planning_artifacts}/epics.md用获批的 epic 列表替换{{epics_list}}占位符用覆盖映射替换{{requirements_coverage_map}}确保所有 FR 都被映射到 epic。{planning_artifacts}是一个可配置变量在 config.template.toml 中其默认值为{project-root}/_bmad-output/planning-artifacts通过uv run ... resolve_config.py --key modules.bmm.planning_artifacts解析得到见 SKILL.md 的 Step 4。6.2 展示菜单选项文档更新后展示菜单Select an Option:[A] Advanced Elicitation [P] Party Mode [C] Continue菜单处理逻辑IF A调用bmad-advanced-elicitation技能IF P调用bmad-party-mode技能IF C保存已批准的 epics_list 到{planning_artifacts}/epics.md、更新 frontmatter然后完整读取并执行./step-03-create-stories.mdIF 其他评论或问题先帮助用户回应然后重新展示菜单。执行规则同样严格展示菜单后必须停下等待用户输入只有用户选择 C 才进入下一步骤其他菜单项执行完成后重新展示菜单用户可以随时聊天或提问——对话结束时总是重新展示菜单选项。这一菜单门控机制是该技能永不跳过步骤Never skip steps纪律的具体实现step-01-validate-prerequisites.md 与 step-03-create-stories.md 中也有同样的 A/P/C 门控。6.3 与 Step 3 的衔接只有当用户选择 C 且已批准的 epics_list 被保存到文档后才允许完整读取并遵循./step-03-create-stories.md开始故事创建。Step 3 会读取获批的 epics_list、FR 覆盖映射以及全部需求含 UX-DR逐 epic 生成带 Given/When/Then 验收条件的故事并继续遵循故事不得依赖未来故事的约束——可见 Step 2 确立的依赖纪律在 Step 3 被一以贯之。七、成功与失败指标质量保障机制步骤文件以 SYSTEM SUCCESS/FAILURE METRICS 形式定义了本步骤的质量边界。✅ 成功标准epic 围绕用户价值设计所有 FR 都被映射到具体 epicepics_list 创建并格式正确需求覆盖映射完成用户对 epic 结构给出显式批准文档以获批的 epic 更新。❌ 失败标准epic 按技术分层组织覆盖映射中缺失 FR未获得用户批准epics_list 未保存到文档。主规则Master Rule跳过步骤、优化执行顺序或不遵循精确指令都是被禁止的并构成 SYSTEM FAILURE。这条主规则与 SKILL.md 中 NEVER skip steps or optimize the sequence 的 Critical Rules 完全一致从侧面印证了该技能对流程纪律的强约束设计。这些失败判据不是孤立的——step-04-final-validation.md 会在最后阶段系统性地复查每个 FR 是否至少出现在一个故事中、数据库表是否仅在需要它们的故事中创建、故事是否只依赖前置故事、以及多个 epic 是否重复修改同一批核心文件File Churn Check。Step 2 的质量在 Step 4 被二次验证形成闭环。八、从步骤文件到仓库实现设计如何被工程化step-02 的设计思路并非孤立的文档它在仓库中有完整的工程化支撑步骤文件架构SKILL.md 定义了 micro-file design、just-in-time loading、sequential enforcement、state tracking通过 frontmatter 的stepsCompleted数组与 append-only building 五条核心原则step-02 正是这套架构中的一个节点模板契约epics-template.md 以占位符{{project_name}}、{{fr_list}}、{{nfr_list}}、{{additional_requirements}}、{{ux_design_requirements}}、{{requirements_coverage_map}}、{{epics_list}}规定了 epics.md 的标准结构Step 2 的输出必须与之吻合Step 3 生成的每个故事As a / I want / So that Given/When/Then也会追加到同一文档中可定制性customize.toml 暴露了[workflow]命名空间下的activation_steps_prepend、activation_steps_append、persistent_facts与on_complete四个配置面团队可按 BMAD 的结构化合并规则标量覆盖、表深合并、按code/id匹配的数组替换、其余数组追加注入组织级约束——例如把每个 epic 必须交付端到端用户价值这类持久事实persistent_facts注入整个工作流输入前置Step 2 的输入来自 Step 1 提取的 FR/NFR/附加需求/UX-DR其中 UX 设计契约bmad-ux 的DESIGN.mdEXPERIENCE.mdspine 对被 Step 1 明确视为一等输入文档每个 UX-DR 都要求具体到足以生成带可测试验收条件的故事见 step-01-validate-prerequisites.md 第 6 节。九、实战要点小结把 step-02 的核心可操作结论浓缩如下供在实际项目中直接套用先确认方向确定性再定 epic 粒度方案已被架构/UX 验证、方向不会漂移时合并为更少更大的 epic存在真实风险边界或早期反馈可能改变方向时拆开用四个要素描述每个 epic标题用户视角、用户结果、FR 覆盖编号、实现说明用依赖规则自检每个 epic 独立交付完整领域功能后置 epic 只能建立在前者之上而不能依赖前者才能运行警惕文件抖动多个 epic 反复修改同一批核心文件且无反馈回路时合并为一个含有序故事的 epic产出两个制品epics_list格式见第 4 节 Step D与requirements_coverage_mapFR → Epic 逐条映射写入{planning_artifacts}/epics.md绝不绕过批准未获用户显式批准不得进入 Step 3菜单展示后必须停下等待用户选择。至此Step 2 完成了从需求清单到可交付的 epic 结构的关键跃迁它把产品愿景翻译成一组相互独立、按用户旅程自然推进、且每一条 FR 都有归属的交付单元为 Step 3 的故事生成和后续bmad-sprint-planning的冲刺跟踪奠定了可靠基础。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 BMAD-METHOD 中的 Epic 列表设计：以用户价值为核心的需求组织实战指南（Step 2: Design Epic List）
BMAD-METHOD 中的 Epic 列表设计以用户价值为核心的需求组织实战指南Step 2: Design Epic List【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本文以 BMAD-METHOD 开源仓库中bmad-create-epics-and-stories技能的第 2 步步骤文件为核心系统讲解如何在 Agile AI Driven Development 工作流中把已提取的需求FR/NFR/UX-DR设计成按用户价值组织的 epic 列表并完成 FR 覆盖映射与用户显式批准。读完本文你将掌握这套协作式 Epic 设计流程的完整纪律、六大设计原则、正反例判据、epics.md 文档写入规范以及它与前后步骤需求提取、故事生成、最终验证的衔接机制。一、Step 2 在整个工作流中的定位bmad-create-epics-and-stories是 BMAD-METHOD 中负责把需求拆解为 epic 与用户故事的核心技能其定位在 SKILL.md 中写得很清楚将 PRD 需求与架构决策转化为按用户价值组织的、带有完整验收条件、可供 Developer agent 直接实施的故事集合。该技能在 skills-and-agents.md 的模块索引中被描述为 Break requirements into epics and user stories。该技能采用步骤文件架构step-file architecture整个流程被拆成 4 个自包含的指令文件严格执行一次只加载并完成一个步骤文件的纪律步骤文件职责Step 1step-01-validate-prerequisites.md校验输入文档PRD / Architecture / UX 设计契约并提取 FR、NFR、附加需求与 UX-DRStep 2step-02-design-epics.md设计并获批 epics_list把需求组织进按用户价值聚焦的 epicStep 3step-03-create-stories.md基于已批准的 epics_list 逐 epic 生成用户故事与验收条件Step 4step-04-final-validation.md校验 FR 全覆盖、架构合规、依赖关系与文件重叠收尾存档用户侧的导航文档 break-work-into-stories-and-track-it.md 说明了该技能的真实应用场景当一个项目拥有 PRD可能还有 UX 或架构文档时先运行bmad-create-epics-and-stories生成 epic 文件与故事再衔接bmad-sprint-planning进入冲刺跟踪。Step 2 正是这条路径上决定需求如何被组织成可交付单元的关键一环。二、Step 2 的目标与执行纪律2.1 STEP GOAL本步骤的目标STEP GOAL是设计并获批epics_list将所有需求组织进以用户价值为焦点的 epic 中。它要求 Agent 扮演促导者Facilitator而非内容生成器与用户进行协作式对话而不是命令-响应式地替用户做决定。2.2 通用执行规则Mandatory Execution Rules步骤文件开头列出了一组必须遵守的通用规则 绝不在没有用户输入的情况下生成内容——任何 epic 结构提案都必须基于与用户的协作 关键采取任何行动前完整读取步骤文件——不允许只看摘要就动手 关键通过 C 加载下一步骤时必须确保整个文件被完整读取 你是促导者不是内容生成器✅ 必须始终以你的 Agent 沟通风格输出。2.3 角色强化Role ReinforcementAgent 在本步骤中承担双重角色你是产品策略师和技术规格写作者如果已有既定的沟通或人格模式请在新角色下继续沿用双方是协作式对话不是命令-响应你带来产品策略与 epic 设计专长用户带来产品愿景与优先级。2.4 步骤特定规则Step-Specific Rules只专注于创建epics_list本步骤禁止创建单独的故事stories——那是 Step 3 的职责围绕用户价值组织 epic而不是技术分层必须获得用户对 epics_list 的显式批准关键每个 epic 必须独立可用并能为后续 epic 铺路但不能依赖后续 epic 才能运行。这一条独立可用且可赋能未来standalone and enable future epics是本步骤的灵魂约束贯穿下面所有设计原则。三、Epic 设计的六大原则步骤文件在解释 Epic 设计原则环节给出了 6 条原则它们共同构成判断一个 epic 切分是否合格的判据用户价值优先User-Value First每个 epic 必须让用户能够完成某件有意义的事需求分组Requirements Grouping将能交付连贯用户结果的相关 FR 归为一组增量交付Incremental Delivery每个 epic 应能独立交付价值逻辑流程Logical Flow从用户视角看epic 之间存在自然的推进顺序epic 内部无前向依赖Dependency-Free Within Epicepic 内的故事不得依赖未来的故事实施效率Implementation Efficiency考虑把反复修改同一批核心文件的多个 epic 合并成更少的 epic。其中第 6 条直接呼应了仓库对上下文体积的关注——合并后每个故事仍需能放进单个 dev agent 的上下文内详见第 5 节的文件重叠审查。3.1 正确的组织方式按用户价值步骤文件给出了一个教科书式的正面示例——一个内容平台按用户旅程切分Epic 1: User Authentication Profiles用户可注册、登录、管理个人资料——独立完整的认证系统Epic 2: Content Creation用户可创建、编辑、发布内容——独立使用认证创建内容Epic 3: Social Interaction用户可关注、评论、点赞内容——独立使用认证 内容Epic 4: Search Discovery用户可发现内容与其他用户——独立使用前面所有 epic。注意每个 epic 都有明确的用户结果user outcome且后一个 epic 只是建立在前者之上而不是离开前者就无法运行。3.2 错误组织方式一按技术分层反面示例是把工程里程碑当作 epic❌ Epic 1: Database Setup一次性建好所有表——没有用户价值❌ Epic 2: API Development构建所有端点——没有用户价值❌ Epic 3: Frontend Components创建可复用组件——没有用户价值❌ Epic 4: Deployment PipelineCI/CD 搭建——没有用户价值。这类切分把用户能感知的价值延迟到了最后违背了增量交付原则也是 step-04-final-validation.md 中不得提前做大额技术准备工作No big upfront technical work检查项的来源。3.3 错误组织方式二同一组件上的文件抖动另一个反面示例揭示了一种隐蔽的坏味道——多个 epic 反复改动同一批核心文件❌ Epic 1: File Upload改动 model、controller、web form、web API❌ Epic 2: File Status改动同样四个文件❌ Epic 3: File Access permissions改动同样四个文件。三个 epic 触碰完全相同的文件集合epic 之间又不存在需要真实反馈的决策风险纯属不必要的文件抖动file churn。步骤文件给出的正确替代是✅Epic 1: File Management Enhancement——把 upload、status、permissions 作为同一个 epic 内的有序故事理由单一组件、已完整预设计、epic 之间不存在反馈回路。这条原则与 Step 4 的 File Churn Check 相互印证见第 8 节。3.4 依赖规则Dependency Rules步骤文件把依赖约束压缩为三条硬规则每个 epic 必须为其领域交付完整功能Epic 2 的运行不得要求 Epic 3 先完成Epic 3 可以建立在 Epic 1 与 2 之上但必须能独立成立。四、协作式 Epic 结构设计四步流程获得用户对原则的理解共识后进入实际的 epic 结构设计环节共分 A/B/C/D 四个子步骤。Step A评估上下文并识别主题首先评估解决方案设计架构、UX、测试设计已被验证到什么程度当结果已经明确、epic 之间发生方向变更的可能性很低时倾向于更少但更大的 epic当存在真正的风险边界risk boundary或早期反馈可能改变后续 epic 方向时拆分为多个 epic。随后识别用户价值主题在 FR 中寻找自然分组识别用户旅程或工作流考虑用户类型及其目标。也就是说epic 的粒度不是越大越好或越小越好而是由方向确定性决定的确定性高就合并存在反馈风险就拆分。Step B提出 Epic 结构对每个拟议 epic同时要考虑多个 epic 是否共享同一批核心文件按 4 个要素给出提案Epic 标题Epic Title以用户为中心、聚焦价值用户结果User Outcome本 epic 完成后用户能达成什么FR 覆盖FR Coverage本 epic 解决哪些 FR 编号实现说明Implementation Notes任何技术或 UX 层面的考虑。Step C文件重叠审查评估多个拟议 epic 是否反复瞄准同一批核心文件。若重叠显著区分有意义的重叠同一组件端到端地演进与偶发共享只是顺带触碰公共文件询问用户是否应该合并为一个包含有序故事的 epic若确认合并则将各 epic 的 FR 并入单一 epic同时保留依赖流每个故事仍需能放进单个 dev agent 的上下文。这正是第 3.3 节文件抖动反例的正式处理流程体现了第 6 条原则实施效率的落地方式。Step D生成 epics_list将结果格式化为标准的 epics_list 结构步骤文件中的原文格式## Epic List ### Epic 1: [Epic Title] [Epic goal statement - what users can accomplish] **FRs covered:** FR1, FR2, FR3, etc. ### Epic 2: [Epic Title] [Epic goal statement - what users can accomplish] **FRs covered:** FR4, FR5, FR6, etc. [Continue for all epics]这个结构与 epics-template.md 中{{epics_list}}占位符的目标格式完全一致为 Step 3 的故事生成提供了权威输入。五、需求覆盖映射与协作式精化5.1 展示 epic 列表供评审将完整的 epics_list 展示给用户并附带epic 总数每个 epic 的 FR 覆盖每个 epic 交付的用户价值任何自然的依赖关系。5.2 创建 FR 覆盖映射Requirements Coverage Map为防止需求遗漏必须创建{{requirements_coverage_map}}逐条展示每个 FR 被哪个 epic 承接### FR Coverage Map FR1: Epic 1 - [Brief description] FR2: Epic 1 - [Brief description] FR3: Epic 2 - [Brief description] ...该映射的最终落位同样在 epics-template.md 的{{requirements_coverage_map}}占位符处并在 Step 4 的 FR 覆盖验证中作为核对清单使用。5.3 协作式精化向用户提出四个引导性问题这个 epic 结构符合你的产品愿景吗所有用户结果都被正确捕获了吗我们是否应该调整某些 epic 分组是否有我们遗漏的自然依赖5.4 获得最终批准关键必须获得用户显式批准标准问句是Do you approve this epic structure for proceeding to story creation?若用户要求修改做出调整 → 更新 epics_list → 重新展示 → 再次请求批准循环直到获得批准。在获得批准之前严禁加载下一步骤。六、文档更新与菜单流转6.1 写入 epics.md获批后更新{planning_artifacts}/epics.md用获批的 epic 列表替换{{epics_list}}占位符用覆盖映射替换{{requirements_coverage_map}}确保所有 FR 都被映射到 epic。{planning_artifacts}是一个可配置变量在 config.template.toml 中其默认值为{project-root}/_bmad-output/planning-artifacts通过uv run ... resolve_config.py --key modules.bmm.planning_artifacts解析得到见 SKILL.md 的 Step 4。6.2 展示菜单选项文档更新后展示菜单Select an Option:[A] Advanced Elicitation [P] Party Mode [C] Continue菜单处理逻辑IF A调用bmad-advanced-elicitation技能IF P调用bmad-party-mode技能IF C保存已批准的 epics_list 到{planning_artifacts}/epics.md、更新 frontmatter然后完整读取并执行./step-03-create-stories.mdIF 其他评论或问题先帮助用户回应然后重新展示菜单。执行规则同样严格展示菜单后必须停下等待用户输入只有用户选择 C 才进入下一步骤其他菜单项执行完成后重新展示菜单用户可以随时聊天或提问——对话结束时总是重新展示菜单选项。这一菜单门控机制是该技能永不跳过步骤Never skip steps纪律的具体实现step-01-validate-prerequisites.md 与 step-03-create-stories.md 中也有同样的 A/P/C 门控。6.3 与 Step 3 的衔接只有当用户选择 C 且已批准的 epics_list 被保存到文档后才允许完整读取并遵循./step-03-create-stories.md开始故事创建。Step 3 会读取获批的 epics_list、FR 覆盖映射以及全部需求含 UX-DR逐 epic 生成带 Given/When/Then 验收条件的故事并继续遵循故事不得依赖未来故事的约束——可见 Step 2 确立的依赖纪律在 Step 3 被一以贯之。七、成功与失败指标质量保障机制步骤文件以 SYSTEM SUCCESS/FAILURE METRICS 形式定义了本步骤的质量边界。✅ 成功标准epic 围绕用户价值设计所有 FR 都被映射到具体 epicepics_list 创建并格式正确需求覆盖映射完成用户对 epic 结构给出显式批准文档以获批的 epic 更新。❌ 失败标准epic 按技术分层组织覆盖映射中缺失 FR未获得用户批准epics_list 未保存到文档。主规则Master Rule跳过步骤、优化执行顺序或不遵循精确指令都是被禁止的并构成 SYSTEM FAILURE。这条主规则与 SKILL.md 中 NEVER skip steps or optimize the sequence 的 Critical Rules 完全一致从侧面印证了该技能对流程纪律的强约束设计。这些失败判据不是孤立的——step-04-final-validation.md 会在最后阶段系统性地复查每个 FR 是否至少出现在一个故事中、数据库表是否仅在需要它们的故事中创建、故事是否只依赖前置故事、以及多个 epic 是否重复修改同一批核心文件File Churn Check。Step 2 的质量在 Step 4 被二次验证形成闭环。八、从步骤文件到仓库实现设计如何被工程化step-02 的设计思路并非孤立的文档它在仓库中有完整的工程化支撑步骤文件架构SKILL.md 定义了 micro-file design、just-in-time loading、sequential enforcement、state tracking通过 frontmatter 的stepsCompleted数组与 append-only building 五条核心原则step-02 正是这套架构中的一个节点模板契约epics-template.md 以占位符{{project_name}}、{{fr_list}}、{{nfr_list}}、{{additional_requirements}}、{{ux_design_requirements}}、{{requirements_coverage_map}}、{{epics_list}}规定了 epics.md 的标准结构Step 2 的输出必须与之吻合Step 3 生成的每个故事As a / I want / So that Given/When/Then也会追加到同一文档中可定制性customize.toml 暴露了[workflow]命名空间下的activation_steps_prepend、activation_steps_append、persistent_facts与on_complete四个配置面团队可按 BMAD 的结构化合并规则标量覆盖、表深合并、按code/id匹配的数组替换、其余数组追加注入组织级约束——例如把每个 epic 必须交付端到端用户价值这类持久事实persistent_facts注入整个工作流输入前置Step 2 的输入来自 Step 1 提取的 FR/NFR/附加需求/UX-DR其中 UX 设计契约bmad-ux 的DESIGN.mdEXPERIENCE.mdspine 对被 Step 1 明确视为一等输入文档每个 UX-DR 都要求具体到足以生成带可测试验收条件的故事见 step-01-validate-prerequisites.md 第 6 节。九、实战要点小结把 step-02 的核心可操作结论浓缩如下供在实际项目中直接套用先确认方向确定性再定 epic 粒度方案已被架构/UX 验证、方向不会漂移时合并为更少更大的 epic存在真实风险边界或早期反馈可能改变方向时拆开用四个要素描述每个 epic标题用户视角、用户结果、FR 覆盖编号、实现说明用依赖规则自检每个 epic 独立交付完整领域功能后置 epic 只能建立在前者之上而不能依赖前者才能运行警惕文件抖动多个 epic 反复修改同一批核心文件且无反馈回路时合并为一个含有序故事的 epic产出两个制品epics_list格式见第 4 节 Step D与requirements_coverage_mapFR → Epic 逐条映射写入{planning_artifacts}/epics.md绝不绕过批准未获用户显式批准不得进入 Step 3菜单展示后必须停下等待用户选择。至此Step 2 完成了从需求清单到可交付的 epic 结构的关键跃迁它把产品愿景翻译成一组相互独立、按用户旅程自然推进、且每一条 FR 都有归属的交付单元为 Step 3 的故事生成和后续bmad-sprint-planning的冲刺跟踪奠定了可靠基础。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考