94 lines
5.0 KiB
Markdown
94 lines
5.0 KiB
Markdown
---
|
||
title: "快速流程"
|
||
description: 小型变更的快速通道 - 跳过完整方法论
|
||
sidebar:
|
||
order: 1
|
||
---
|
||
|
||
跳过繁琐流程。快速流程通过单个工作流将你从意图带到可运行的代码 — 无需产品简报、无需 PRD、无需架构文档。
|
||
|
||
## 何时使用
|
||
|
||
- Bug 修复和补丁
|
||
- 重构现有代码
|
||
- 小型、易于理解的功能
|
||
- 原型设计和探索性开发
|
||
- 单智能体工作，一名开发者可以掌控完整范围
|
||
|
||
## 何时不使用
|
||
|
||
- 需要利益相关者对齐的新产品或平台
|
||
- 跨越多个组件或团队的主要功能
|
||
- 需要架构决策的工作（数据库架构、API 契约、服务边界）
|
||
- 需求不明确或有争议的任何工作
|
||
|
||
:::caution[Scope Creep]
|
||
如果你启动快速流程后发现范围超出预期，`bmad-quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程，而不会丢失你的工作。
|
||
:::
|
||
|
||
## 工作原理
|
||
|
||
运行 `bmad-quick-dev`，工作流会处理一切 — 澄清意图、规划、实现、审查和呈现结果。
|
||
|
||
### 1. 澄清意图
|
||
|
||
你描述想要什么。工作流将你的请求压缩成一个连贯的目标 — 足够小、足够清晰、没有矛盾，可以安全执行。意图可以来自多种来源：几句话、一个错误追踪器链接、计划模式输出、聊天会话文本，甚至来自你的史诗的故事编号。
|
||
|
||
### 2. 路由到最小安全路径
|
||
|
||
一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在自主运行之前就有更强的边界。
|
||
|
||
### 3. 规划和实现
|
||
|
||
在规划路径上，工作流生成完整的技术规范，包含有序的实现任务、Given/When/Then 格式的验收标准和测试策略。你批准规范后，它成为模型在较少监督下执行的边界。
|
||
|
||
### 4. 审查和呈现
|
||
|
||
实现后，工作流运行自检审计和差异的对抗性代码审查。审查充当分诊 — 与当前变更相关的发现会被处理，附带的发现会被推迟以保持运行专注。结果呈现供你确认。
|
||
|
||
### 人机交互检查点
|
||
|
||
工作流将人类控制重新定位到少数几个高价值时刻：
|
||
|
||
- **意图澄清** — 将混乱的请求转化为一个连贯的目标
|
||
- **规范审批** — 确认冻结的理解是正确要构建的东西
|
||
- **最终审查** — 决定结果是否可接受
|
||
|
||
在这些检查点之间，模型以更少的监督运行更长时间。这是经过深思熟虑的 — 它用持续监督换取在最高杠杆时刻的集中人类注意力。
|
||
|
||
## 快速流程跳过的内容
|
||
|
||
完整的 BMad 方法在编写任何代码之前会生成产品简报、PRD、架构文档和 Epic/Story 分解。Quick Flow 用单个技术规范替代所有这些。这之所以有效，是因为 Quick Flow 针对以下变更：
|
||
|
||
- 产品方向已确立
|
||
- 架构决策已做出
|
||
- 单个开发者可以推理完整范围
|
||
- 需求可以在一次对话中涵盖
|
||
|
||
## 升级到完整 BMad 方法
|
||
|
||
快速流程包含内置的范围检测护栏。当你运行 `bmad-quick-dev` 时，它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围：
|
||
|
||
- **轻度升级** — 建议在实现前创建计划
|
||
- **重度升级** — 建议切换到完整的 BMad 方法 PRD 流程
|
||
|
||
你也可以随时手动升级。你的技术规范工作会继续推进 — 它将成为更广泛规划过程的输入，而不是被丢弃。
|
||
|
||
---
|
||
## 术语说明
|
||
|
||
- **Quick Flow**：快速流程。BMad 方法中用于小型变更的简化工作流程，跳过完整的产品规划和架构文档阶段。
|
||
- **PRD**：Product Requirements Document，产品需求文档。详细描述产品功能、需求和验收标准的文档。
|
||
- **Product Brief**：产品简报。概述产品愿景、目标和范围的高层文档。
|
||
- **Architecture doc**：架构文档。描述系统架构、组件设计和技术决策的文档。
|
||
- **Epic/Story**：史诗/故事。敏捷开发中的工作单元，Epic 是大型功能集合，Story 是具体用户故事。
|
||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||
- **Scope Creep**：范围蔓延。项目范围在开发过程中逐渐扩大，超出原始计划的现象。
|
||
- **tech-spec**：技术规范。详细描述技术实现方案、任务分解和验收标准的文档。
|
||
- **Given/When/Then**：一种行为驱动开发（BDD）的测试场景描述格式，用于定义验收标准。
|
||
- **adversarial review**：对抗性审查。一种代码审查方法，模拟攻击者视角以发现潜在问题和漏洞。
|
||
- **stakeholder**：利益相关者。对项目有利益或影响的个人或组织。
|
||
- **API contracts**：API 契约。定义 API 接口规范、请求/响应格式和行为约定的文档。
|
||
- **service boundaries**：服务边界。定义服务职责范围和边界的架构概念。
|
||
- **spikes**：探索性开发。用于探索技术可行性或解决方案的短期研究活动。
|