BMAD-METHOD 规划路径选择指南从一次编辑到多 Epic 项目的最简 BMad 流程【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本文是 BMAD-METHOD 规划章节的入口文档choose-a-planning-path.md的深度解读。它解决一个核心问题一项软件变更到底需要多少规划。答案只取决于一个判断——意图intent是否已经定义清楚清楚就直接交给bmad-spec定型并进入构建不清楚就先借助规划技能把它打磨清楚。读完本文你将掌握如何为变更选择最小的安全路径、如何区分单次构建Build session、Epic 与 Project 三个规模层级以及每个规划技能各自产出什么文档、如何衔接bmad-build与bmad-retrospective形成完整闭环。从意图出发一个问题的决策树规划深度的选择只有一个核心判据意图是否已经良定义well-defined。一份良定义的意图应当说明工作完成时应该成立什么what should be true when the work is done、什么不能改变what must not change、以及哪些不在范围内what is out of scope。它的完整度标准是完整到别人不需要猜测就能实现同时不超过这个长度。意图的来源无关紧要——可能是一句话、一个 issue、一个锻造过的想法forged idea、一份研究报告或一份 PRD。由此产生两条分支意图良定义直接运行bmad-spec。产出的 spec 若恰好适合一次 Build 会话就直接进入bmad-build若是 Epic 级规模则要求 Story Breakdown 拆解然后逐个 story 执行 Build。详见 define-requirements-and-a-specification.md。其他一切情况意图尚未就绪。先使用本章下方各页面把它打磨清楚再运行bmad-spec。注意bmad-spec写的是契约它不帮你弄清你想要什么。如果变更本身只适合一次实现会话那么你已经不在本章的领地而是属于 Build 页面build-a-change.md 覆盖了会话规模的评估以及小改动是否需要 BMad。前置条件Prerequisites使用 Build 或其他 BMad 工作流前需先安装 BMad见 install-bmad.md。对于显而易见、低风险的编辑不需要 BMad。输入长度的硬性约束bmad-spec一次性读入你给它的全部内容实际上限是几万 token约等于一份 40 页的文档。如果塞给它数倍于此的原始文档堆它会静默丢失关键部分——所以先浓缩再投喂。如果 spec 反馈输入太薄说明你在这个章节还没做完。达成良定义意图独立工具而非阶段这些规划技能是相互独立的工具不是流水线阶段。按缺口挑选、任意顺序使用且它们都不负责构建任何东西。产出物需要浓缩后再交给bmad-spec而不是直接投喂原始堆料。意图缺口应该做什么完全没有清晰想法或不确定想法是否足够好explore-and-validate-an-idea.md头脑风暴 / Forge Idea决策需要证据支撑research-a-decision.mdDeep Recon需要为 PRD 或 pitch 写下产品是什么的书面说明产品简介brief或 PRFAQ见 define-requirements-and-a-specification.md多个 Epic 或多个 Agent 必须遵守的共享决策design-ux-and-architecture.md多人/多团队之间的共识、归属与签核以 PRD 作为组织拥有的文档见 plan-inside-an-organization.md关键判据一份简短的决策清单往往就够用了。只有当多于一人都必须同意产品是什么或多于一个 Epic 不得分叉时才需要 PRD否则跳过。多 Epic 产品则对每个 Epic 各运行一次bmad-spec以这些文档作为来源。规划技能及其产出清单本章每一个技能都会写出一份可以继续传递的文档。下表按分析 → 规划 → 方案设计solutioning排列每个章节页面都从其覆盖的第一个技能处被链接并说明该技能在何时适用。在已安装的项目中bmad-help会推荐下一个技能。技能目的产出物bmad-brainstorming用引导式会话生成想法explore-and-validate-an-idea.mdbrainstorm.html纪念品 可选的brainstorm-intent.mdbmad-forge-idea压力测试一个想法直到它硬化、被证实或廉价地死掉每次运行产出forge-report.html想法硬化时产出forged-idea.mdbmad-deep-recon研究一个主题以支撑决策research-a-decision.md带引用的research.md 可选的 HTML 简报bmad-product-brief概念清晰时捕捉产品愿景define-requirements-and-a-specification.mdbrief.mdaddendum.mdbmad-prfaq以客户优先、从新闻稿倒推的方式压力测试产品概念prfaq-project.mdbmad-prd创建、更新或验证 PRD创建/更新prd.md、addendum.md、.memlog.md验证HTML .md报告bmad-ux记录产品的外观与行为design-ux-and-architecture.mdDESIGN.md、EXPERIENCE.md、.memlog.mdbmad-spec将任意意图浓缩为一份简短契约按需拆分为 storySPEC.mdspecs/spec-slug/下的配套文件可选的stories.yamlbmad-architecture做出让独立构建的各部分保持一致的技术决策默认产出ARCHITECTURE-SPINE.mdbmad-create-epics-and-stories把需求拆解为 Epic 与 storybreak-work-into-stories-and-track-it.md带 story 的 Epic 文件bmad-sprint-planning实现前检查就绪度然后跟踪 story 状态PASS/CONCERNS/FAIL sprint-status.yamlbmad-prd有三种意图——create、update、validate调用时需说明要哪一种否则它会询问。bmad-product-brief为bmad-prd提供输入PRD 在 discovery 阶段会读取 brief但两者互不强制依赖。从源码看bmad-spec的契约实现规划技能表的枢纽是bmad-spec。其实现位于 skills/bmad-spec/SKILL.md其可配置项见 skills/bmad-spec/customize.toml。几个对流程影响最大的配置默认值spec_template assets/spec-template.md五字段内核Why、Capabilities、Constraints、Non-goals、Success signal的骨架模板可在团队/个人 TOML 中覆盖以强制不同的形状如为研究项目增加 hypothesis 字段、为游戏增加 mechanics 字段spec_filename SPEC.md内核工件文件名按惯例大写以标示中心事实源spec_output_path {output_folder}/specs与run_folder_pattern spec-{slug}spec始终是一个文件夹默认解析为{output_folder}/specs/spec-{slug}/。相同 slug 落进相同文件夹第二次调用会在原处更新 spec 并保留 capability ID。从 skills/bmad-spec/assets/spec-template.md 可以看到内核的五字段结构Why痛点、机会、愿景或任务四种驱动力之一、Capabilities每条含intent与success描述 WHAT 而非 HOW、Constraints必须真正弯曲设计决策的非协商项、Non-goals至少一条防止下游填补真空、Success signal具体到能写测试或演示来判定。可选字段Assumptions与Open Questions分别记录未经验证的推断与等待人类决策的缺口。更深一层的机制在 skills/bmad-spec/assets/spec-template.md 与 SKILL.md 的 Spec Law 中体现.memlog.md是追加式权威记录SPEC.md每次运行都从 memlog重新派生而非手工编辑——这正是 PRD、UX、架构、Epic 可以任意顺序运行并持续投喂同一份 spec 而不产生合并漂移的原因。SPEC.md的唯一写入者就是bmad-spec外部手工修改会在下次派生时被覆盖。规模跟随意图Edit / Build / Epic / Project 四层路径意图的规模决定后面有多少个 Build 会话一个连贯结果、需要若干会话 →Epic横跨多个 Epic、或大概需要20 个以上会话→Project。范围只是信号之一当工作具有高风险、需求不清、架构影响面广、跨系统影响、或需要人与人/团队之间协调时应使用更多规划。所有路径都复用同一个实现单元。更大的工作只是在该单元周围增加共享上下文并重复它而不是切换到一套独立的交付系统。规模判定的实操锚点作为对照单次 Build 会话的典型体量在 build-a-change.md 中有明确说明一个目标、约 500 行新增/修改代码不含测试、涉及少量文件。装得下就交给bmad-build装不下就先规划。判断不准时询问bmad-help。对于愿意自己 review 的琐碎编辑直接让 Agent 改即可但若 bug 可能漏进生产环境bmad-build大概率值得。执行路径1. 启动 Epic 级工作适用场景需要多个 Build 会话但仍是一个连贯结果。定义并切分 Epic以 Epic 意图运行bmad-spec。关于 spec 包含什么、何时可独立成立见 define-requirements-and-a-specification.md。要求Story Breakdown。这会创建与SPEC.md同级的、有序的stories.yaml。审查建议的顺序决定哪些 story 需要 checkpoint。story 列表是执行计划不是什么都不变的承诺。当早期工作暴露出缺失的约束、更好的切分方式或 story 间的冲突时应更新 spec 并重新运行 Story Breakdown。建立实现模式用bmad-build实现重要的、有风险的或奠基性的 story。早期 story 往往奠定架构、初始项目结构和后续 story 沿用的重复模式。在自动化重复之前先让这些决策获得人工关注。每个 story 运行一次 Build。Build 会在 spec 文件夹下创建或恢复该 story 的实现记录并保持它与父 spec 的关联。收尾 Epic不只逐个验证 story而要把它们合在一起验证。然后用 spec 文件夹运行bmad-retrospective。Retrospective 把stories.yaml当作 Epic 清单对照父 spec 评判合并结果。见 finish-an-epic.md。从 finish-an-epic.md 可以看到 spec-backed Epic 的验收规则stories.yaml定义 Epic 清单、每个stories/id-*.md记录定义完成状态产出RETROSPECTIVE.md位于 spec 文件夹内不创建或改动 sprint-status 文件。裁决为accepted、accepted-with-open-items或rejected——Epic 的任一 story 未完成会使裁决为rejected人类仍可覆盖。2. 启动 Project 级工作适用场景全新产品greenfield、多 Epic 计划或大概需要20 个以上实现会话的工作。先从上面的表格中只准备项目实际需要的规划plan-inside-an-organization.md 覆盖谁拥有哪份文档、签核发生在哪里。然后对每个 Epic 运行bmad-spec用 break-work-into-stories-and-track-it.md 跟踪 story并用 finish-an-epic.md 收尾每个 Epic。这些文档协调实现但不替代 Build。每个 Epic 仍然是一个会话一个单元的序列。当 Epic 流的边界明确时独立的 Epic 流可以并行推进——每条流需要一个 owner所有流都对同一产品意图与架构负责并在每个 Epic 边界运行集成检查与 retrospective。切分工作会丢失信息一个需求被削弱、一个约束消失、两个各自正确的 story 组合后失败。PRD、架构和 spec 的存在就是为了让后续会话仍能看到整体。关于bmad-build-auto的时机当重要的实现决策稳定之后bmad-build-auto可以在不等待人工输入的情况下运行一个会话。但它不选择下一个 story也不拥有 backlog。Worker 契约见 autonomous-development-loops.md。你最终得到什么一条与工作规模匹配的路径Epic 得到一份 spec 加 story 列表Project 得到共享产品文档加每 Epic 一份 spec——无论哪种每个单元仍然一次一个 Build 会话地实现。快速决策速查我的情况路径明显低风险的琐碎编辑无需 BMad直接改单个目标、约 500 行以内直接bmad-build想法模糊或未验证bmad-brainstorming/bmad-forge-idea/bmad-deep-recon先处理一个连贯结果、多会话bmad-spec→ Story Breakdown → 每 story 一次bmad-build→bmad-retrospective多 Epic / 约 20 会话以上组织级文档PRD/UX/架构→ 每 Epic 一份 spec → 每 Epic 收尾决策已稳定、想无人值守bmad-build-auto只跑一个单元不管理 backlog【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 BMAD-METHOD 规划路径选择指南：从一次编辑到多 Epic 项目的最简 BMad 流程
BMAD-METHOD 规划路径选择指南从一次编辑到多 Epic 项目的最简 BMad 流程【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD本文是 BMAD-METHOD 规划章节的入口文档choose-a-planning-path.md的深度解读。它解决一个核心问题一项软件变更到底需要多少规划。答案只取决于一个判断——意图intent是否已经定义清楚清楚就直接交给bmad-spec定型并进入构建不清楚就先借助规划技能把它打磨清楚。读完本文你将掌握如何为变更选择最小的安全路径、如何区分单次构建Build session、Epic 与 Project 三个规模层级以及每个规划技能各自产出什么文档、如何衔接bmad-build与bmad-retrospective形成完整闭环。从意图出发一个问题的决策树规划深度的选择只有一个核心判据意图是否已经良定义well-defined。一份良定义的意图应当说明工作完成时应该成立什么what should be true when the work is done、什么不能改变what must not change、以及哪些不在范围内what is out of scope。它的完整度标准是完整到别人不需要猜测就能实现同时不超过这个长度。意图的来源无关紧要——可能是一句话、一个 issue、一个锻造过的想法forged idea、一份研究报告或一份 PRD。由此产生两条分支意图良定义直接运行bmad-spec。产出的 spec 若恰好适合一次 Build 会话就直接进入bmad-build若是 Epic 级规模则要求 Story Breakdown 拆解然后逐个 story 执行 Build。详见 define-requirements-and-a-specification.md。其他一切情况意图尚未就绪。先使用本章下方各页面把它打磨清楚再运行bmad-spec。注意bmad-spec写的是契约它不帮你弄清你想要什么。如果变更本身只适合一次实现会话那么你已经不在本章的领地而是属于 Build 页面build-a-change.md 覆盖了会话规模的评估以及小改动是否需要 BMad。前置条件Prerequisites使用 Build 或其他 BMad 工作流前需先安装 BMad见 install-bmad.md。对于显而易见、低风险的编辑不需要 BMad。输入长度的硬性约束bmad-spec一次性读入你给它的全部内容实际上限是几万 token约等于一份 40 页的文档。如果塞给它数倍于此的原始文档堆它会静默丢失关键部分——所以先浓缩再投喂。如果 spec 反馈输入太薄说明你在这个章节还没做完。达成良定义意图独立工具而非阶段这些规划技能是相互独立的工具不是流水线阶段。按缺口挑选、任意顺序使用且它们都不负责构建任何东西。产出物需要浓缩后再交给bmad-spec而不是直接投喂原始堆料。意图缺口应该做什么完全没有清晰想法或不确定想法是否足够好explore-and-validate-an-idea.md头脑风暴 / Forge Idea决策需要证据支撑research-a-decision.mdDeep Recon需要为 PRD 或 pitch 写下产品是什么的书面说明产品简介brief或 PRFAQ见 define-requirements-and-a-specification.md多个 Epic 或多个 Agent 必须遵守的共享决策design-ux-and-architecture.md多人/多团队之间的共识、归属与签核以 PRD 作为组织拥有的文档见 plan-inside-an-organization.md关键判据一份简短的决策清单往往就够用了。只有当多于一人都必须同意产品是什么或多于一个 Epic 不得分叉时才需要 PRD否则跳过。多 Epic 产品则对每个 Epic 各运行一次bmad-spec以这些文档作为来源。规划技能及其产出清单本章每一个技能都会写出一份可以继续传递的文档。下表按分析 → 规划 → 方案设计solutioning排列每个章节页面都从其覆盖的第一个技能处被链接并说明该技能在何时适用。在已安装的项目中bmad-help会推荐下一个技能。技能目的产出物bmad-brainstorming用引导式会话生成想法explore-and-validate-an-idea.mdbrainstorm.html纪念品 可选的brainstorm-intent.mdbmad-forge-idea压力测试一个想法直到它硬化、被证实或廉价地死掉每次运行产出forge-report.html想法硬化时产出forged-idea.mdbmad-deep-recon研究一个主题以支撑决策research-a-decision.md带引用的research.md 可选的 HTML 简报bmad-product-brief概念清晰时捕捉产品愿景define-requirements-and-a-specification.mdbrief.mdaddendum.mdbmad-prfaq以客户优先、从新闻稿倒推的方式压力测试产品概念prfaq-project.mdbmad-prd创建、更新或验证 PRD创建/更新prd.md、addendum.md、.memlog.md验证HTML .md报告bmad-ux记录产品的外观与行为design-ux-and-architecture.mdDESIGN.md、EXPERIENCE.md、.memlog.mdbmad-spec将任意意图浓缩为一份简短契约按需拆分为 storySPEC.mdspecs/spec-slug/下的配套文件可选的stories.yamlbmad-architecture做出让独立构建的各部分保持一致的技术决策默认产出ARCHITECTURE-SPINE.mdbmad-create-epics-and-stories把需求拆解为 Epic 与 storybreak-work-into-stories-and-track-it.md带 story 的 Epic 文件bmad-sprint-planning实现前检查就绪度然后跟踪 story 状态PASS/CONCERNS/FAIL sprint-status.yamlbmad-prd有三种意图——create、update、validate调用时需说明要哪一种否则它会询问。bmad-product-brief为bmad-prd提供输入PRD 在 discovery 阶段会读取 brief但两者互不强制依赖。从源码看bmad-spec的契约实现规划技能表的枢纽是bmad-spec。其实现位于 skills/bmad-spec/SKILL.md其可配置项见 skills/bmad-spec/customize.toml。几个对流程影响最大的配置默认值spec_template assets/spec-template.md五字段内核Why、Capabilities、Constraints、Non-goals、Success signal的骨架模板可在团队/个人 TOML 中覆盖以强制不同的形状如为研究项目增加 hypothesis 字段、为游戏增加 mechanics 字段spec_filename SPEC.md内核工件文件名按惯例大写以标示中心事实源spec_output_path {output_folder}/specs与run_folder_pattern spec-{slug}spec始终是一个文件夹默认解析为{output_folder}/specs/spec-{slug}/。相同 slug 落进相同文件夹第二次调用会在原处更新 spec 并保留 capability ID。从 skills/bmad-spec/assets/spec-template.md 可以看到内核的五字段结构Why痛点、机会、愿景或任务四种驱动力之一、Capabilities每条含intent与success描述 WHAT 而非 HOW、Constraints必须真正弯曲设计决策的非协商项、Non-goals至少一条防止下游填补真空、Success signal具体到能写测试或演示来判定。可选字段Assumptions与Open Questions分别记录未经验证的推断与等待人类决策的缺口。更深一层的机制在 skills/bmad-spec/assets/spec-template.md 与 SKILL.md 的 Spec Law 中体现.memlog.md是追加式权威记录SPEC.md每次运行都从 memlog重新派生而非手工编辑——这正是 PRD、UX、架构、Epic 可以任意顺序运行并持续投喂同一份 spec 而不产生合并漂移的原因。SPEC.md的唯一写入者就是bmad-spec外部手工修改会在下次派生时被覆盖。规模跟随意图Edit / Build / Epic / Project 四层路径意图的规模决定后面有多少个 Build 会话一个连贯结果、需要若干会话 →Epic横跨多个 Epic、或大概需要20 个以上会话→Project。范围只是信号之一当工作具有高风险、需求不清、架构影响面广、跨系统影响、或需要人与人/团队之间协调时应使用更多规划。所有路径都复用同一个实现单元。更大的工作只是在该单元周围增加共享上下文并重复它而不是切换到一套独立的交付系统。规模判定的实操锚点作为对照单次 Build 会话的典型体量在 build-a-change.md 中有明确说明一个目标、约 500 行新增/修改代码不含测试、涉及少量文件。装得下就交给bmad-build装不下就先规划。判断不准时询问bmad-help。对于愿意自己 review 的琐碎编辑直接让 Agent 改即可但若 bug 可能漏进生产环境bmad-build大概率值得。执行路径1. 启动 Epic 级工作适用场景需要多个 Build 会话但仍是一个连贯结果。定义并切分 Epic以 Epic 意图运行bmad-spec。关于 spec 包含什么、何时可独立成立见 define-requirements-and-a-specification.md。要求Story Breakdown。这会创建与SPEC.md同级的、有序的stories.yaml。审查建议的顺序决定哪些 story 需要 checkpoint。story 列表是执行计划不是什么都不变的承诺。当早期工作暴露出缺失的约束、更好的切分方式或 story 间的冲突时应更新 spec 并重新运行 Story Breakdown。建立实现模式用bmad-build实现重要的、有风险的或奠基性的 story。早期 story 往往奠定架构、初始项目结构和后续 story 沿用的重复模式。在自动化重复之前先让这些决策获得人工关注。每个 story 运行一次 Build。Build 会在 spec 文件夹下创建或恢复该 story 的实现记录并保持它与父 spec 的关联。收尾 Epic不只逐个验证 story而要把它们合在一起验证。然后用 spec 文件夹运行bmad-retrospective。Retrospective 把stories.yaml当作 Epic 清单对照父 spec 评判合并结果。见 finish-an-epic.md。从 finish-an-epic.md 可以看到 spec-backed Epic 的验收规则stories.yaml定义 Epic 清单、每个stories/id-*.md记录定义完成状态产出RETROSPECTIVE.md位于 spec 文件夹内不创建或改动 sprint-status 文件。裁决为accepted、accepted-with-open-items或rejected——Epic 的任一 story 未完成会使裁决为rejected人类仍可覆盖。2. 启动 Project 级工作适用场景全新产品greenfield、多 Epic 计划或大概需要20 个以上实现会话的工作。先从上面的表格中只准备项目实际需要的规划plan-inside-an-organization.md 覆盖谁拥有哪份文档、签核发生在哪里。然后对每个 Epic 运行bmad-spec用 break-work-into-stories-and-track-it.md 跟踪 story并用 finish-an-epic.md 收尾每个 Epic。这些文档协调实现但不替代 Build。每个 Epic 仍然是一个会话一个单元的序列。当 Epic 流的边界明确时独立的 Epic 流可以并行推进——每条流需要一个 owner所有流都对同一产品意图与架构负责并在每个 Epic 边界运行集成检查与 retrospective。切分工作会丢失信息一个需求被削弱、一个约束消失、两个各自正确的 story 组合后失败。PRD、架构和 spec 的存在就是为了让后续会话仍能看到整体。关于bmad-build-auto的时机当重要的实现决策稳定之后bmad-build-auto可以在不等待人工输入的情况下运行一个会话。但它不选择下一个 story也不拥有 backlog。Worker 契约见 autonomous-development-loops.md。你最终得到什么一条与工作规模匹配的路径Epic 得到一份 spec 加 story 列表Project 得到共享产品文档加每 Epic 一份 spec——无论哪种每个单元仍然一次一个 Build 会话地实现。快速决策速查我的情况路径明显低风险的琐碎编辑无需 BMad直接改单个目标、约 500 行以内直接bmad-build想法模糊或未验证bmad-brainstorming/bmad-forge-idea/bmad-deep-recon先处理一个连贯结果、多会话bmad-spec→ Story Breakdown → 每 story 一次bmad-build→bmad-retrospective多 Epic / 约 20 会话以上组织级文档PRD/UX/架构→ 每 Epic 一份 spec → 每 Epic 收尾决策已稳定、想无人值守bmad-build-auto只跑一个单元不管理 backlog【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考