2.8 KiB
2.8 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 快速开发 | 在不牺牲输出质量检查点的情况下减少人机交互的摩擦 |
|
bmad-quick-dev 的目标很直接：在保证质量边界的前提下，把“意图到代码”的人机往返轮次降到最低。
它解决什么问题
纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Quick Dev 做的是中间解：
- 在关键节点保留人工判断
- 在可控区间放大模型自主执行时长
- 通过规范与审查把偏航风险收回来
Quick Dev 的核心机制
1. 先把意图压缩成单一目标
无论输入来自几句话、issue 链接、计划稿，还是 epics.md 的 story，都要先压缩成一个可执行目标。
目标不清晰时，后续自动化越强，偏差成本越高。
2. 选择最小安全路径
目标明确后，workflow 会判断：
- 是不是“零爆炸半径”的 one-shot 变更
- 还是必须先走 planning 再实现
原则是：能走短路径就不走长路径，但不能为了快跳过必要边界。
3. 在边界内长时自主执行
当目标与规范足够清晰，模型会承担更长段的连续实现。
这一步省下的是“重复确认成本”，不是“质量成本”。
4. 在正确层级修复问题
Quick Dev 会区分问题来源：
- 意图层问题：需求理解本身不对
- 规范层问题：tech-spec 边界不够强
- 实现层问题：本地代码缺陷
只有实现层问题才直接补代码；上层问题要回到对应层级重做。
5. 只在必要时拉回人工
人类主要在三个高杠杆时刻介入：
- 意图澄清
- 规范确认
- 最终结果审查
为什么它和“普通自动化”不一样
Quick Dev 不追求“全自动”，而是追求“最少但有效的人类判断”。
它把人工注意力从大量低价值确认，转移到少量高价值决策。
与对抗性评审的关系
Quick Dev 是执行节奏设计；adversarial review 是审查策略。二者经常配合：
- Quick Dev 负责高效推进实现
- 对抗性评审负责提高问题发现率并做分诊
也就是说，Quick Dev 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
适用边界
适合：
- 目标可定义、可验收的实现任务
- 希望减少流程摩擦但不放弃质量门
不适合：
- 目标长期模糊且频繁变化
- 团队尚未接受“先规格后长时执行”的工作方式
:::tip[实践建议] 先把成功标准写清楚，再启用 Quick Dev。目标越清楚，自动化收益越大。 :::