94 lines
5.3 KiB
Markdown
94 lines
5.3 KiB
Markdown
---
|
||
title: "快速流程"
|
||
description: 小型变更的快速通道 - 跳过完整方法论
|
||
sidebar:
|
||
order: 1
|
||
---
|
||
|
||
跳过繁琐流程。快速流程通过两条命令将你从想法带到可运行的代码 - 无需产品简报、无需 PRD、无需架构文档。
|
||
|
||
## 何时使用
|
||
|
||
- Bug 修复和补丁
|
||
- 重构现有代码
|
||
- 小型、易于理解的功能
|
||
- 原型设计和探索性开发
|
||
- 单智能体工作，一名开发者可以掌控完整范围
|
||
|
||
## 何时不使用
|
||
|
||
- 需要利益相关者对齐的新产品或平台
|
||
- 跨越多个组件或团队的主要功能
|
||
- 需要架构决策的工作（数据库架构、API 契约、服务边界）
|
||
- 需求不明确或有争议的任何工作
|
||
|
||
:::caution[Scope Creep]
|
||
如果你启动快速流程后发现范围超出预期，`quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程，而不会丢失你的工作。
|
||
:::
|
||
|
||
## 工作原理
|
||
|
||
快速流程有两条命令，每条都由结构化的工作流程支持。你可以一起运行它们，也可以独立运行。
|
||
|
||
### quick-spec：规划
|
||
|
||
运行 `quick-spec`，Barry（Quick Flow 智能体）会引导你完成对话式发现过程：
|
||
|
||
1. **理解** - 你描述想要构建的内容。Barry 扫描代码库以提出有针对性的问题，然后捕获问题陈述、解决方案方法和范围边界。
|
||
2. **调查** - Barry 读取相关文件，映射代码模式，识别需要修改的文件，并记录技术上下文。
|
||
3. **生成** - 生成完整的技术规范，包含有序的实现任务（具体文件路径和操作）、Given/When/Then 格式的验收标准、测试策略和依赖项。
|
||
4. **审查** - 展示完整规范供你确认。你可以在最终定稿前进行编辑、提问、运行对抗性审查或使用高级启发式方法进行优化。
|
||
|
||
输出是一个 `tech-spec-{slug}.md` 文件，保存到项目的实现工件文件夹中。它包含新智能体实现功能所需的一切 - 无需对话历史。
|
||
|
||
### quick-dev：构建
|
||
|
||
运行 `quick-dev`，Barry 实现工作。它以两种模式运行：
|
||
|
||
- **技术规范模式** - 指向规范文件（`quick-dev tech-spec-auth.md`），它按顺序执行每个任务，编写测试，并验证验收标准。
|
||
- **直接模式** - 直接给出指令（`quick-dev "refactor the auth middleware"`），它收集上下文，构建心智计划，并执行。
|
||
|
||
实现后，`quick-dev` 针对所有任务和验收标准运行自检审计，然后触发差异的对抗性代码审查。发现的问题会呈现给你，以便在收尾前解决。
|
||
|
||
:::tip[Fresh Context]
|
||
为获得最佳效果，在完成 `quick-spec` 后，在新对话中运行 `quick-dev`。这为实现智能体提供了专注于构建的干净上下文。
|
||
:::
|
||
|
||
## 快速流程跳过的内容
|
||
|
||
完整的 BMad 方法在编写任何代码之前会生成产品简报、PRD、架构文档和 Epic/Story 分解。Quick Flow 用单个技术规范替代所有这些。这之所以有效，是因为 Quick Flow 针对以下变更：
|
||
|
||
- 产品方向已确立
|
||
- 架构决策已做出
|
||
- 单个开发者可以推理完整范围
|
||
- 需求可以在一次对话中涵盖
|
||
|
||
## 升级到完整 BMad 方法
|
||
|
||
快速流程包含内置的范围检测护栏。当你使用直接请求运行 `quick-dev` 时，它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围：
|
||
|
||
- **轻度升级** - 建议先运行 `quick-spec` 创建计划
|
||
- **重度升级** - 建议切换到完整的 BMad 方法 PRD 流程
|
||
|
||
你也可以随时手动升级。你的技术规范工作会继续推进 - 它将成为更广泛规划过程的输入，而不是被丢弃。
|
||
|
||
---
|
||
## 术语说明
|
||
|
||
- **Quick Flow**：快速流程。BMad 方法中用于小型变更的简化工作流程，跳过完整的产品规划和架构文档阶段。
|
||
- **PRD**：Product Requirements Document，产品需求文档。详细描述产品功能、需求和验收标准的文档。
|
||
- **Product Brief**：产品简报。概述产品愿景、目标和范围的高层文档。
|
||
- **Architecture doc**：架构文档。描述系统架构、组件设计和技术决策的文档。
|
||
- **Epic/Story**：史诗/故事。敏捷开发中的工作单元，Epic 是大型功能集合，Story 是具体用户故事。
|
||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||
- **Scope Creep**：范围蔓延。项目范围在开发过程中逐渐扩大，超出原始计划的现象。
|
||
- **tech-spec**：技术规范。详细描述技术实现方案、任务分解和验收标准的文档。
|
||
- **slug**：短标识符。用于生成 URL 或文件名的简短、唯一的字符串标识。
|
||
- **Given/When/Then**：一种行为驱动开发（BDD）的测试场景描述格式，用于定义验收标准。
|
||
- **adversarial review**：对抗性审查。一种代码审查方法，模拟攻击者视角以发现潜在问题和漏洞。
|
||
- **elicitation**：启发式方法。通过提问和对话引导来获取信息、澄清需求的技术。
|
||
- **stakeholder**：利益相关者。对项目有利益或影响的个人或组织。
|
||
- **API contracts**：API 契约。定义 API 接口规范、请求/响应格式和行为约定的文档。
|
||
- **service boundaries**：服务边界。定义服务职责范围和边界的架构概念。
|
||
- **spikes**：探索性开发。用于探索技术可行性或解决方案的短期研究活动。
|