---
title: "快速开发"
description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
sidebar:
  order: 2
---

`bmad-quick-dev` 的目标很直接：在保证质量边界的前提下，把“意图到代码”的人机往返轮次降到最低。

![快速开发工作流图](/diagrams/quick-dev-diagram.png)

## 它解决什么问题

纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。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)