BMAD-METHOD 的 bmad-build 实现工作流：在最小化人工干预的同时守住质量检查点

BMAD-METHOD 的 bmad-build 实现工作流在最小化人工干预的同时守住质量检查点【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHODbmad-build是 Breakthrough Method for Agile Ai Driven DevelopmentBMAD-METHOD项目中负责代码实现的标准工作流它接收从自由意图、issue 到完整规划 story 的任何输入以与安全要求兼容的最少人工介入产出代码修改。本文基于 docs/fr/explanation/build.md 展开结合仓库中 docs/build/build-a-change.md、docs/build/review-a-change.md 等实操文档与流程图源码讲清 bmad-build 的设计动机、五大核心原则、审查与 triage 机制以及在实际开发中的调用方式。bmad-build 是什么bmad-build是 BMAD 中所有开发工作的标准实现工作流。它同时接受两类输入自由意图或 issue几句话、一个 bug 追踪链接、从聊天会话复制的一段文字完整规划的 story来自 BMAD 上游规划产物PRD、UX、架构、epics、stories、就绪检查、sprint 计划的已规划 story。无论哪种输入它都输出代码修改并且把人工干预压缩到与安全要求兼容的最低限度。在 commands.md 的工作流技能表 中bmad-build被定义为“实现一个直接意图、issue、功能、修复或已规划的 story”。上游规划是可选的、可变的一个清晰的改动可以直接进入一个更大的计划可以携带 PRD、UX、架构、epics、stories、准备度检查和 sprint 计划进入。这些产物只是强化上下文并不会切换成另一套开发工作流——规划产物增强 Build而不是替代 Build。当一条已规划的 story 进入 Build 时它仍然是产品上下文的来源和验收标准的权威。Build 会为当前这次执行创建自己的执行日志用于保留实现决策与审查观察的可追溯性但不会替换 story 本身。为什么需要这个功能人类注意力是瓶颈人类在循环中的交互是必要的也是昂贵的。当前 LLM 仍会以可预期的方式失败误解意图、用自信的假设填补空缺、漂移到无关的工作、生成噪声很大的待修订结果。与此同时持续的人工介入又限制了开发的流畅度——人类的注意力才是瓶颈。bmad-build重新平衡了这个权衡它信任模型可以在更长的周期内无监督运行但前提是工作流已经建立起足够坚实的边界让这种“放手”变得安全。它没有消除人工控制而是把人工控制移动到少数几个高价值的步骤上。核心设计的五大原则1. 先压缩意图Compress the intent first工作流的第一步是把人与模型的交互从请求压缩成一个连贯一致的目标。输入可以始于粗略的意图表达但在工作流开始自主运行之前意图必须足够小、足够清晰、没有矛盾才能被执行。意图可以呈现为多种形态几句话、指向 bug 追踪工具的链接、规划模式的输出、从聊天会话复制的文本或者来自 BMAD epics 与 sprint 产物的已规划 story。工作流使用所有可用的上游上下文并解决安全实现所需的缺口。人工控制并没有消失而是被重新定位到少数高价值步骤意图澄清——把混乱的请求转化为一个没有隐藏矛盾的一致目标规格批准——确认被固化的理解确实是要构建的内容最终产品审查——主要检查点由人在最后决定结果是否可接受。2. 路由到最短且安全的路径Route to the shortest safe path目标一旦清晰工作流就要判断这是一个真正的一步到位改动还是需要走完整路径。零影响的小改动可以直接进入实现图中的 one-shot mode 分支其余一切都要先经过规划让模型在更长时间的自主运行之前拥有更坚实的框架。3. 更长时间运行、更少监督Run longer with less supervision完成路由决策后模型可以自己承担更大比例的工作。在完整路径上已批准的规格成为模型以较少监督运行的框架——这正是整个设计的核心用意。规格Spec是圆角矩形节点代表它是流程中人工确认过的“契约”从规格到实现之间的箭头不需要再经过人工。4. 在正确的层级诊断失败Diagnose failures at the right level如果实现不正确是因为意图本身有误那么修正代码不是正确的解法如果代码不正确是因为规格太弱那么修正 diff 同样不是正确的解法。工作流被设计为诊断失败从哪一层进入系统回到那一层从该点重新生成。审查结果被用来判断问题来自意图、规格生成还是局部实现——只有真正的局部问题才在局部修复。在流程图中可以看到这条回溯机制intent_gap意图缺口从 Review 一路回到 Clarify说明需要再次澄清意图bad_spec规格不佳从 Review 回到 Plan/Spec 层级重新生成规格而不是打补丁patch局部补丁只有被判定为真正属于本次改动的局部问题才在原地修复。5. 只在必要时让人介入Involve the human only when necessary意图访谈确实把人放进循环但它不是那种反复出现的检查点式打断。工作流尽量把这种反复出现的检查点降到最低意图初步成形之后人主要在两类时刻回归——工作流无法在无人判断的情况下安全继续时以及最后需要审查结果时。意图缺口消解——如果在审查时再次需要介入说明工作流没能正确推断出用户的意图。其余一切都可以候选更长时间的自主执行。这个权衡是刻意的旧模式把更多人类注意力消耗在持续监督上Build 则更信任模型但把人类注意力保留在人类推理影响最大的时刻。从 build-a-change.md 的表述看这种取舍的收益很直接同样一段“规划加实现”bmad-build通常需要从你这里少几轮交互因为它把审查、triage 和自动修复都内置了。为什么审查系统如此重要审查阶段不只是为了找 bug——它存在的意义是把修正路由出去同时不摧毁执行势头。子代理审查设计的基石这个工作流在能生成子代理subagent的平台上效果最佳至少也要能通过命令行调用另一个 LLM 并等待结果。如果你的平台原生不支持可以添加一个 skill 来实现。无上下文的子代理是审查设计的基石临时创建的次级 AI 代理在隔离状态下执行特定任务如代码审查不继承主代理的完整上下文从而能给出更客观、更不带偏见的分析。代理审查的两种典型失败基于代理的审查agentic review经常以两种方式失败产生过多观察迫使人类去筛选噪声偏离当前改动上报无关问题把每一次运行变成一次临时起意的清理项目。Build 通过把审查当作triage分诊来同时解决这两个问题。审查即 triage有些观察属于当前这次改动有些则不属于。如果一条观察是偶发的、与当前工作没有直接关系工作流可以推迟defer它而不是强迫人立即处理。这样既保持了执行的聚焦也避免随机的题外话耗尽注意力资本。这种 triage 有时会不完美——这是可接受的。通常把一些观察判断错了也好过用几千条低价值审查评论淹没一个人。系统优化的是报告质量而不是报告的穷尽性。在 review-a-change.md 中可以看到这套 triage 的落地流程每一层审查代理独立、并行地审查同一个 diff随后 triage 对每条发现单独裁决Verify验证——在指定位置核实声称的后果读懂 diff 上下文判断该后果是否真的会发生Assign severity定级——根据已验证的后果分配严重级别low、medium、highDismiss驳回——驳回噪声、被证伪的声明和缺乏依据的声明但必须记录理由绝不静默丢弃Route路由——把幸存者导向patch补丁、defer推迟或decision needed需要决策。其中patch 是明确的代码修复defer 是真实存在但不属于本次改动的历史问题decision needed 是需要你介入的模糊选择如果没有规格这一档不会启用发现会归入 patch 或 defer。在流程图build-run.svg右侧可以看到内置于 bmad-build 审查阶段的三类审查镜头Review lensesBlind Hunter盲猎手找出任意 10 个可修问题、Edge Cases Hunter边界用例猎手寻找被遗忘的角落用例、Verification Gap Finder验证缺口查找器判断是否被测试覆盖。仓库中对应的独立审查技能为bmad-code-review其 review-prompts 目录下就有edge-case-hunter.md与verification-gap.md两个可复用的审查提示。一次 bmad-build 运行的完整路径结合流程图源码与 build-a-change.md一次运行沿以下节点推进Initial intent初始意图——人给出意图可以是任意形态Clarify and route澄清与路由——先澄清、再决定走 one-shot mode 还是完整路径interview是此处的可选人工介入点Plan规划——完整路径下的规划阶段Spec规格——圆角节点表示人工确认的规格spec review是可选的Implement实现——模型在规格框架内自主实现Fits AC?验收门——菱形判定节点检查实现是否满足验收标准ACacceptance criteriaReview审查——三类审查镜头并行审查输出 patch / rejectvoid作废/ defer写入deferred_work.md/ bad_spec回到规划层/ intent_gap回到澄清层Present呈现——呈现给用户you review the result是最后一道人工检查点Result结果——运行结束产出可审查的结果。实操如何运行 bmad-build规模评估Size the Work使用与改动规模匹配的最小 BMAD 配置。一次典型会话对应一个目标大约 500 行新增或修改代码不含测试涉及少数几个文件。如果能装下就交给bmad-build装不下先规划更大的工作参见 选择规划路径。对于你愿意自己审查的琐碎编辑可以直接让代理修改但如果有 bug 可能逃逸到生产环境bmad-build就值得使用。启动方式第一步开启全新会话。在 AI IDE 中打开一个全新聊天——复用其他工作流的会话可能混入上下文、干扰运行。第二步给出意图。可以在命令之前、之中或之后描述改动不必整理得干净整洁。一段随意的描述、一段语音倾倒、一个半成型的想法、一个 issue 链接、一个文件或一条已规划的 story 都可以。bmad-build会把意图当作工作流输入而不是当作现成的实现计划。/bmad-build 修复允许空密码的登录验证 bug。/bmad-build 修复 https://github.com/org/repo/issues/42。/bmad-build 实现 _bmad-output/implementation-artifacts/my-intent.md 中的意图。我觉得问题出在 auth 中间件它没有检查 token 过期。 让我看看……是的src/auth/middleware.ts 第 47 行完全跳过了 exp 检查。 /bmad-build/bmad-build 你想做什么 将 UserService 重构为使用 async/await 而不是回调。第三步依据证据消解意图。bmad-build从你的请求出发先调查代码库和上游规划产物再判断是否还有实质性的信息缺失。输入可以很粗糙清晰、有证据支撑的请求不会经过澄清回合。遇到不明确之处它先找证据——只有仓库和规划上下文都无法裁定的事项才会变成关于已完成设计的开放问题而不是开工前的访谈。认真回答出现的开放问题——这一层的错误判断是日后最难发现、代价最高的一类错误。第四步在需要时批准计划。调查完成后bmad-build路由到最小安全路径并报告已定型设计的三个事实意图缺口你没说、但会在结果中注意到的内容、不可逆操作、影响范围footprint。三者都干净的设计走轻量路径——同一会话内生成最小规格并实现之后审查任何一项有标记则先产出完整书面计划每个意图缺口作为开放问题由你在批准前回答。计划描述的正是要构建的内容就批准不是就驳回——修正计划比修正代码便宜得多。第五步实现与审查。决策之后bmad-build实现改动、用独立审查者审查自己的工作、修复属于本次改动的问题并在本地提交。审查是 triage 而非全量倾倒属于当前改动的发现被修复无关的既有问题被推迟。如果代码错是因为计划弱或计划错是因为目标错就回到那一层重新生成而不是只修补 diff。需要独立审查PR、他人改动、额外一遍或审查机器人时使用 bmad-code-review / Review a Change。第六步审查结果。运行结束时bmad-build给出简短摘要和常规下一步创建 PR、走查改动或再做一处改动。对成品的引导式审查参见 Walk Through a Change。走查或浏览 diff 确认改动符合意图如有不对告诉代理修复它可以在同一会话内迭代。满意后请它推送提交并创建 PR。注意如果推送的改动引发意外问题用git revert HEAD干净地撤销最后一次提交然后开启全新会话、换一种方式重新运行bmad-build。你能得到什么已应用改动的源文件通过的测试如果项目有测试套件一个带常规提交信息的、可直接推送的提交本次运行的实现记录——有父级规格或 story 时放在其旁边。对成品的 API 与端到端覆盖参见 Test Completed Work。推迟的工作Deferred Work每次运行都专注于一个目标。如果你的请求包含多个独立目标或审查发现了与本次改动无关的既有问题bmad-build会把它们写入实现产物目录下的deferred-work.md而不是试图一次做完一切。运行后检查这个文件——它是一份后续跟进清单backlog每个条目都可以在之后喂给一次全新的bmad-build运行。流程图中的deferred_work.md节点正是 defer 路由的落点。何时应该先规划在运行bmad-build之前先添加规格或 PRD、UX、架构、story 规划当满足以下条件时改动影响多个系统或需要跨许多文件协调更新你不确定范围需要先做需求发现需要为团队记录文档或架构决策澄清意图时不断浮出矛盾单次会话无法解决。更大的工作会变成一系列单会话改动这个序列会随着实现教会你更多而改变。父级规格保持共同目标story 记录承载决策与完成状态集成检查与回顾覆盖合并结果。bmad-build只处理一个单元——它不拥有 backlog、不挑选下一条 story、也不替代那些后期的检查。对于基础性、高风险或重要的 story你的决策可能为后续工作设定模式使用bmad-build当这些模式稳定之后bmad-build-auto可以在不等待你的情况下运行一个单元参见 Autonomous Development Loops。需要说明的是bmad-build-auto不负责编排多个单元由 AI 编码会话或其他编排器如 bmad-loop为每个单元派发一个 worker。实现技能全景技能用途产出bmad-build以人工检查点实现一个直接意图或已规划 story实现记录 代码bmad-build-auto为调用方或编排器无人值守地实现并审查一个单元实现记录 代码 终端状态bmad-code-review用多个独立审查者审查任何代码改动发现 已应用的补丁bmad-correct-course评估一次重要的中期冲刺改动的影响更新后的计划或重新路由bmad-retrospective依据留下的证据回顾一个完成的 epic回顾文档、行动项、验收裁决术语表子代理Sous-agent / subagent临时创建的次级 AI 代理在隔离状态下执行特定任务如代码审查不继承主代理的完整上下文从而能给出更客观、更不带偏见的分析。代理审查Revue agentique / agentic review由 AI 代理自主执行的代码审查能够分析、识别问题并提出建议无需直接人工介入。分诊Triage对审查观察进行过滤与优先级排序的过程区分需要立即处理的与可以稍后再处理的问题。从设计上看bmad-build的取舍很明确它愿意为一次运行多花一些推理时间换来的是把人类注意力从“持续监督”重新分配到“意图澄清、规格批准、最终审查”三个不可替代的节点上——正如 build-a-change.md 所强调的人类注意力是 AI 辅助软件开发中最昂贵的资源、也是生产力的瓶颈。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考