---
title: "快速开发新预览版"
description: 减少人工介入的阻力，同时保留保护输出质量的检查点
sidebar:
  order: 2
---

`bmad-quick-dev-new-preview` 是对快速流程的一次实验性大改：输入意图即可直接输出代码变更——更少的流程开销、更少的人工介入，但不牺牲质量。

它让模型在检查点之间跑得更久，只在任务没有人工判断就无法安全推进、或需要审查最终结果时，才把人拉回来。

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

## 为什么需要它

人工介入不可或缺，但代价不小。

当前的大语言模型仍会以可预见的方式翻车：曲解意图、用看似靠谱的猜测填坑、跑偏到不相干的工作上、输出一堆噪音式的审查结果。但不停地人工干预同样拖慢开发节奏。人的注意力才是真正的瓶颈。

这个实验版快速流程尝试重新找到平衡点：让模型在更长的时间段内自主运行，但前提是工作流已经建立了足够强的护栏。

## 核心设计

### 1. 先压缩意图

工作流的第一步是让人和模型一起把请求压缩成一个清晰的目标。输入可以很粗糙，但在工作流开始自主运行之前，目标必须足够小、足够明确、没有自相矛盾的地方。

意图的来源很灵活：几句话、一个 bug tracker 链接、Plan 模式的输出、聊天记录里复制的文本，甚至 BMAD 自身 `epics.md` 里的 story 编号。最后这种情况，工作流并不理解 BMAD 的 story 跟踪语义，但它可以拿到 story 内容直接跑起来。

人工控制并没有被取消，而是集中到了少数高价值的节点上：

- **意图澄清** — 把模糊的请求理清为一个连贯目标，排除隐含矛盾
- **规格审批** — 确认锁定的理解就是要做的东西
- **最终产品审查** — 核心检查点，人在最后拍板结果是否达标

### 2. 路由到最小安全路径

目标明确后，工作流判断这是不是真正能一步到位的变更。小改动、影响面为零的变更直接进实现。其余的先走规划，给模型更长自主运行之前加上更强的约束。

### 3. 以更少的监督运行更长时间

路由决策之后，模型可以自主承担更多工作。走完整路径时，已批准的规格本身就是模型在更少监督下执行的边界——这正是整个实验的核心。

### 4. 在正确的层级诊断失败

如果实现出错是因为意图本身就错了，那修代码就是修错了地方。如果代码出错是因为规格不够扎实，光改 diff 也于事无补。工作流的设计目标是找到问题从哪个环节引入，回到那一层重新来过。

审查结果用来判断问题源自意图、规格生成还是局部实现。只有真正的局部问题才就地修补。

### 5. 仅在需要时带回人类

意图访谈需要人工参与，但它不同于反复弹出的检查点中断。工作流会尽可能压缩这类反复中断的次数。初始意图敲定之后，人主要在两个时机回来：工作流靠自己推进不下去的时候，以及最终审查结果的时候。

- **意图缺口解决** — 审查表明工作流无法安全推断原始意图时，人重新介入

其余环节都可以交给模型自主跑更久。这个取舍是有意为之的。老模式把更多人的注意力花在持续盯着上；快速开发新预览版选择更多地信任模型，把人的注意力省给人类判断最有价值的时刻。

## 为什么审查系统很重要

审查阶段不只是找 bug，更重要的是在不打断节奏的前提下把纠正路由到对的地方。

工作流在能拉起子代理的平台上效果最好，至少也要能通过命令行调用另一个 LLM 并等结果返回。平台不原生支持的话，可以加一个 skill 来补。无上下文子代理是审查设计的基石。

AI 代理审查常见两类问题：

- 输出过多发现，逼人在噪音里大海捞针。
- 顺带暴露了不相关的问题，让当前变更跑偏，每次运行都变成临时打扫卫生。

快速开发新预览版的做法是把审查当分诊来处理。

有些发现属于当前变更，有些不属于。如果一个发现只是顺带发现的、跟当前工作没有因果关系，工作流会把它推迟，而不是逼着人当场处理。这样运行才能保持专注，不会被随机的旁枝末节吃掉注意力。

分诊偶尔会不准，这可以接受。漏判几个发现，远好过上千条低价值审查评论把人淹没。系统优化的是信号质量，不是穷举式召回。