Build
bmad-build 是所有开发工作的标准实施 workflow。它既可接收自由意图或 issue，也可接收完整规划的 story，并在安全前提下用尽可能少的人机交互完成代码变更。
上游规划仍然可选且深度可变。清晰变更可以直接进入；大型项目可以携带 PRD、UX、架构、epics、stories、就绪检查和 sprint 计划。这些产物会增强上下文，而不是选择另一条开发 workflow。
当已规划的 story 进入 Build 时，它仍然是产品上下文和验收标准的来源。Build 会为当前运行创建自己的执行记录，使实施决策和审查发现可追溯，但不会取代上游 story。
它解决什么问题
Section titled “它解决什么问题”纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Build 做的是中间解：
- 在关键节点保留人工判断
- 在可控区间放大模型自主执行时长
- 通过规范与审查把偏航风险收回来
Build 的核心机制
Section titled “Build 的核心机制”1. 先把意图压缩成单一目标
Section titled “1. 先把意图压缩成单一目标”无论输入来自几句话、issue 链接、计划稿，还是 epics.md 的 story，都要先压缩成一个可执行目标。
目标不清晰时，后续自动化越强，偏差成本越高。
2. 选择最小安全路径
Section titled “2. 选择最小安全路径”目标明确后，workflow 会判断：
- 是不是“零爆炸半径”的 one-shot 变更
- 还是必须先走 planning 再实现
原则是：能走短路径就不走长路径，但不能为了快跳过必要边界。
3. 在边界内长时自主执行
Section titled “3. 在边界内长时自主执行”当目标与规范足够清晰，模型会承担更长段的连续实现。
这一步省下的是“重复确认成本”，不是“质量成本”。
4. 在正确层级修复问题
Section titled “4. 在正确层级修复问题”Build 会区分问题来源：
- 意图层问题：需求理解本身不对
- 规范层问题：tech-spec 边界不够强
- 实现层问题：本地代码缺陷
只有实现层问题才直接补代码；上层问题要回到对应层级重做。
5. 只在必要时拉回人工
Section titled “5. 只在必要时拉回人工”人类主要在三个高杠杆时刻介入：
- 意图澄清
- 规范确认
- 最终结果审查
为什么它和“普通自动化”不一样
Section titled “为什么它和“普通自动化”不一样”Build 不追求“全自动”，而是追求“最少但有效的人类判断”。
它把人工注意力从大量低价值确认，转移到少量高价值决策。
与对抗性评审的关系
Section titled “与对抗性评审的关系”Build 是执行节奏设计；adversarial review 是审查策略。二者经常配合：
- Build 负责高效推进实现
- 对抗性评审负责提高问题发现率并做分诊
也就是说，Build 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
适合：
- 目标可定义、可验收的实现任务
- 希望减少流程摩擦但不放弃质量门
不适合：
- 目标长期模糊且频繁变化
- 团队尚未接受“先规格后长时执行”的工作方式