87 lines
2.8 KiB
Markdown
87 lines
2.8 KiB
Markdown
---
|
||
title: "快速开发"
|
||
description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
|
||
sidebar:
|
||
order: 2
|
||
---
|
||
|
||
`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。目标越清楚，自动化收益越大。
|
||
:::
|
||
|
||
## 继续阅读
|
||
|
||
- [对抗性评审](./adversarial-review.md)
|
||
- [高级启发](./advanced-elicitation.md)
|
||
- [工作流地图](../reference/workflow-map.md)
|