quick 与 fast 工作流 - 和平哥的学习笔记

这是「GSD 全景代码解析」专题的第 18 篇。

在前面的文章中，我们深入解析了 GSD 的重量级工作流——execute-phase.md（69KB）、plan-phase.md（66KB）和 new-project.md（44KB）。这些工作流构成了 GSD 编排层的"主力舰队"，负责处理复杂、多阶段、需要严格质量保障的大型任务。

但真实的软件开发并非总是波澜壮阔的架构重构。更多时候，开发者面对的是：一个拼写错误、一行配置调整、一个紧急热修复。如果每次修改变量名都要走完整的 Phase 规划 → Wave 并行 → 多轮验证，那无异于用航母战斗群去对付一只蚊子。

GSD 的答案是：quick.md 和 fast.md。这两个工作流体积小巧（quick 约 35KB，fast 不足 10KB），却精准覆盖了整个执行光谱中最轻量级的场景。本文将深入解析它们的设计哲学、执行路径和风险控制策略。

一、quick 工作流：最小规划 + 直接执行

quick.md 位于 get-shit-done/workflows/quick.md，是 GSD 快速执行体系中的"轻骑兵"。它的设计目标非常明确：保留 GSD 的核心保障机制，但将执行路径压缩到最短。

1.1 工作流定位

如果说 execute-phase 是"重型装甲师"，那么 quick 就是"快速反应部队"。它不追求 Wave 并行的吞吐量，也不承担 Phase 级别的全局协调，而是专注于单一、明确、可快速完成的任务。

flowchart TD
    subgraph "execute-phase 标准路径"
        A1[Phase Plan] --> B1[Wave 分组]
        B1 --> C1[多子代理并行]
        C1 --> D1[Phase 验证]
        D1 --> E1[更新 ROADMAP.md]
    end

    subgraph "quick 快速路径"
        A2[任务描述] --> B2[gsd-planner
quick mode]
        B2 --> C2[生成 Quick Plan]
        C2 --> D2[写入 .planning/quick/]
        D2 --> E2[gsd-executor 执行]
        E2 --> F2[原子提交]
        F2 --> G2[更新 STATE.md
Quick Tasks 表]
    end

    style "quick 快速路径" fill:#e1f5fe

1.2 轻量级规划策略

quick 工作流的规划阶段被大幅精简，核心变化体现在三个方面：

① 规划范围收缩

标准 plan-phase 需要产出包含 depends_on、files_modified、test_strategy 等完整字段的 PLAN.md，而 quick 模式生成的 "Quick Plan" 仅需：

任务目标（一句话描述）
涉及文件清单
预期变更概述
验证方式（如有）

② 可选阶段默认关闭

quick 工作流默认跳过以下可选阶段：

阶段	标准模式	quick 模式	恢复方式
discussion（需求讨论）	默认启用	默认跳过	`--discuss` 标志
research（技术研究）	按需启用	默认跳过	`--research` 标志
plan-checking（计划审查）	最多 3 轮	默认跳过	`--validate` 标志
verification（执行后验证）	Phase 完成后统一验证	默认跳过	`--validate` 标志

③ 存储路径隔离

Quick 任务不进入 phases/ 目录体系，而是存储在独立的 .planning/quick/ 目录下：

.planning/
├── quick/
│   ├── fix-auth-bug/
│   │   ├── PLAN.md
│   │   └── SUMMARY.md
│   └── update-readme/
│       ├── PLAN.md
│       └── SUMMARY.md
├── phases/
│   └── 01-core/
│       └── ...
└── STATE.md

这种隔离设计确保快速任务不会污染正式的阶段规划体系，同时仍然保留可追溯的执行记录。

1.3 适用场景

quick 工作流最适合以下三类任务：

小改动

修复一个已知 root cause 的 Bug
添加一个简单的方法或工具函数
调整 API 接口的参数或返回值

热修复

生产环境紧急问题修复（可叠加 --validate 增强保障）
安全补丁的快速应用
配置错误的即时纠正

文档更新

README 的说明补充
代码注释的修正
API 文档的同步更新

flowchart TD
    A[任务评估] --> B{"需要多步规划
或跨文件协调?"}
    B -->|是| C[使用标准流程
/gsd:execute-phase]
    B -->|否| D{"需要记录跟踪
或后续审计?"}
    D -->|否| E[使用 /gsd:fast]
    D -->|是| F[使用 /gsd:quick]
    F --> G[生成 Quick Plan]
    G --> H[执行 + 原子提交]
    H --> I[更新 Quick Tasks 表]

二、fast 工作流：更激进的执行策略

fast.md 位于 get-shit-done/workflows/fast.md，是 GSD 执行光谱中最轻量级的末端。如果说 quick 是"精简版规划+执行"，那么 fast 就是"零规划 Inline 执行"。

2.1 quick 与 fast 的核心差异

这是 GSD 用户最容易混淆的一对命令。它们的差异不是程度上的，而是本质上的：

维度	`/gsd:quick`	`/gsd:fast`
生成 PLAN.md	是（Quick Plan）	否
使用子代理	是（gsd-planner + gsd-executor）	否（Inline 直接修改）
原子提交	是	是（如果适用）
STATE.md 更新	是（Quick Tasks 表）	否
上下文加载	加载 .planning/ 上下文	仅使用当前会话上下文
典型耗时	5-30 分钟	< 2 分钟
适用场景	小型功能、Bug 修复、文档更新	拼写修正、配置调整、单行重构

flowchart TD
    subgraph "/gsd:quick 执行链"
        Q1[用户输入] --> Q2[Spawn gsd-planner]
        Q2 --> Q3[生成 Quick Plan]
        Q3 --> Q4[Spawn gsd-executor]
        Q4 --> Q5[执行 + 提交]
        Q5 --> Q6[更新 STATE.md]
    end

    subgraph "/gsd:fast 执行链"
        F1[用户输入] --> F2[当前 AI 直接修改]
        F2 --> F3[提交（如适用）]
        F3 --> F4[完成]
    end

    style "/gsd:fast 执行链" fill:#fff3e0

2.2 Inline 执行的本质

fast 工作流最显著的特征是 "无子代理、无上下文切换"。整个执行过程发生在当前 AI 会话中：

用户输入 /gsd:fast 将 user_name 改为 username
当前 AI 直接读取相关文件
当前 AI 直接修改代码
当前 AI 直接执行 git commit（如果仓库适用）
完成——无额外跟踪，无状态更新

这种设计的优势在于零编排开销：不需要 spawn planner 来生成计划，不需要 spawn executor 来执行计划，不需要更新 STATE.md 来记录进度。所有的 "overhead" 被压缩到零。

代价也同样明显：

没有计划文档——无法事后审计 "当时做了什么"
没有状态跟踪——项目历史中出现 "幽灵提交"
没有验证闭环——执行正确性完全依赖当前 AI 的自我检查

2.3 适用场景

fast 工作流只适用于满足全部四个条件的任务：

能用一句话描述清楚
能在 2 分钟内完成
不需要额外验证/测试
不在关键路径上（即修改出错不会导致系统崩溃）

典型场景包括：

修正代码注释中的拼写错误
调整配置文件中的数值参数
重命名局部变量以符合命名规范
删除未使用的 import 语句
简单的格式化调整

三、快速模式 vs 标准模式的对比

为了更系统地理解 quick/fast 在整个 GSD 体系中的位置，我们将三种执行模式进行全维度对比：

对比维度	标准模式（execute-phase）	quick 模式	fast 模式
规划深度	完整 PLAN.md，含依赖、测试策略	简化 Quick Plan	无规划
规划审查	Plan-Checker 最多 3 轮	可选（`--validate`）	无
子代理使用	gsd-planner, gsd-executor, gsd-verifier	gsd-planner(quick), gsd-executor	无（Inline）
执行并行度	Wave 分组并行	串行	串行
代码审查	code-review gate	可选	无
回归测试	regression gate	可选	无
状态跟踪	ROADMAP.md + STATE.md	Quick Tasks 表	无
人工检查点	Checkpoint 中断	无	无
失败恢复	node-repair + 重试	手动恢复	手动恢复
执行耗时	30 分钟 - 数小时	5-30 分钟	< 2 分钟
上下文开销	高（多轮子代理）	中（2 个子代理）	低（当前会话）

flowchart LR
    subgraph "执行深度光谱"
        direction LR
        A["/gsd:fast
零规划
Inline"] --> B["/gsd:quick
简化规划
子代理精简"]
        B --> C["/gsd:execute-phase
完整规划
Wave 并行"]
    end

    style A fill:#ffccbc
    style B fill:#e1f5fe
    style C fill:#c8e6c9

从工程角度看，这个光谱设计体现了一个核心原则：质量保障的深度应当与任务的风险和复杂度成正比。用完整的 Phase 执行流程去修正一个拼写错误是浪费，用 fast 模式去重构核心模块是冒险。

四、速度 vs 质量的权衡决策树

在真实项目中，选择执行模式往往不是非黑即白的。GSD 提供了一套结构化的决策框架，帮助开发者根据任务特征做出理性选择。

4.1 任务特征决策树

flowchart TD
    A[任务到来] --> B{"能用一句话
描述清楚?"}
    B -->|否| C{"需要研究或多步规划?"}
    C -->|是| D[使用 /gsd:quick
可叠加 --research]
    C -->|否| E[使用标准流程
/gsd:plan-phase + /gsd:execute-phase]
    B -->|是| F{"能在 2 分钟内
完成?"}
    F -->|否| D
    F -->|是| G{"不需要
验证/测试?"}
    G -->|否| D
    G -->|是| H{"不是关键路径
代码?"}
    H -->|否| D
    H -->|是| I[使用 /gsd:fast]

4.2 项目阶段视角

项目阶段	典型场景	推荐模式	理由
开发高峰期	核心功能实现	标准模式	需要完整的规划、验证和跟踪
维护期	生产环境紧急修复	quick + `--validate`	速度优先，但不放弃基本验证
日常编码	读代码时顺手修个小问题	fast	不打断心流，最小摩擦
发布前	最后冲刺修 Bug	quick 或标准模式	避免 fast 引入回归问题
技术债务清理	批量重构	quick（批量）	需要跟踪但不需要完整 Phase

4.3 质量保障等级

GSD 的快速工作流通过可组合的标志系统实现了质量保障的"调光开关"：

flowchart TD
    A[/gsd:quick/] --> B{选择标志}
    B -->|默认| C[最小保障
直接规划+执行]
    B -->|--discuss| D[增加需求澄清]
    B -->|--research| E[增加技术调研]
    B -->|--validate| F[增加计划审查
+ 执行后验证]
    B -->|--full| G[完整保障
讨论+研究+审查+验证]

    C --> H[Quick Plan]
    D --> H
    E --> H
    F --> H
    G --> H

--discuss：在规划前增加轻量级讨论，澄清模糊需求
--research：执行前调查实现方案、库选项、潜在陷阱
--validate：启用 plan-checking（最多 2 轮）和执行后验证
--full：启用全部可选阶段，等同于 --discuss --research --validate

这种设计的关键洞察是："快速"不等于"草率"。quick 模式的默认路径已经保留了原子提交和 STATE.md 跟踪这两个 GSD 核心机制；而 --validate 标志则让开发者可以在 "速度优先" 和 "质量优先" 之间动态切换，无需改变执行命令。

五、快速工作流的风险控制

快速执行模式在提升效率的同时，也引入了特定的风险。GSD 通过三层机制进行风险控制。

5.1 架构层面的隔离

存储隔离：Quick 任务存储在 .planning/quick/ 目录，与正式的 phases/ 目录完全隔离。这意味着：

快速任务不会干扰 Phase 的依赖拓扑
快速任务的 SUMMARY.md 不会影响 ROADMAP.md 的进度计算
项目审计时可以区分 "正式交付" 和 "快速修复"

状态隔离：Quick 任务只更新 STATE.md 中的 "Quick Tasks Completed" 表，不修改 Current Phase、Current Plan 等核心状态字段。

5.2 执行层面的底线

即使在最激进的 fast 模式下，GSD 仍保留了以下底线：

底线机制	quick	fast	说明
原子提交	✓	✓（如适用）	每个任务独立提交，便于回滚
Git 历史	✓	✓	变更始终留在版本控制中
当前会话上下文	✓	✓	不会脱离当前代码库环境

fast 模式的特殊风险：由于 fast 不生成 PLAN.md、不更新 STATE.md，如果执行出现问题，开发者可能面临 "改了什么、为什么改" 的信息缺失。GSD 官方文档明确建议：

"对于任何可能需要事后解释或审计的修改，请使用 /gsd:quick 而非 /gsd:fast。"。

5.3 组织层面的最佳实践

基于 GSD 社区的经验，以下是使用快速工作流的实用准则：

① 时间盒原则

如果 quick 任务执行超过 30 分钟未结束，考虑中止并升级为标准流程
如果 fast 任务超过 2 分钟未完成，说明任务复杂度被低估，应改用 quick

② 关键路径禁令

支付、认证、数据持久化等关键模块的修改，禁用 fast 模式
涉及数据库 Schema 变更的任务，至少使用 quick + --validate

③ 批处理策略

多个相关的小改动应当合并为一个 quick 任务，而非多次 fast 调用
批量 fast 修改容易导致" death by a thousand cuts "（千刀万剐）式的技术债务

④ 事后补录机制

对于使用 fast 完成的、但事后发现值得记录的修改，手动在 STATE.md 的 Decisions 段补充说明
定期（如每周）审查 quick/ 目录，将重要的修复迁移到正式的 Phase 文档中

六、何时使用 quick/fast，何时使用标准流程

6.1 选择矩阵

场景	推荐命令	关键判断因素
新功能开发	`/gsd:plan-phase` + `/gsd:execute-phase`	需要完整规划、依赖管理和阶段验证
架构重构	`/gsd:plan-phase` + `/gsd:execute-phase`	影响范围广，需要 Wave 分组和回归测试
已知 Bug 修复	`/gsd:quick`	范围明确，但需要跟踪修复记录
生产热修复	`/gsd:quick --validate`	速度优先，但不跳过验证
文档/注释更新	`/gsd:fast`	低风险，无运行时影响
代码格式化	`/gsd:fast`	纯风格调整，无副作用
配置微调	`/gsd:fast`	局部变更，即时生效
拼写修正	`/gsd:fast`	最小任务，零跟踪需求
原型验证	`/gsd:quick --research`	需要快速尝试，但需要记录调研结论

6.2 从 fast 到标准流程的升级路径

实际工作中，任务的复杂度往往在执行过程中才逐渐显露。GSD 的设计允许在执行过程中"动态升级"：

flowchart TD
    A[开始: /gsd:fast] --> B{执行中是否发现
复杂度超预期?}
    B -->|是| C[保存当前进度]
    C --> D[切换为 /gsd:quick]
    D --> E{是否涉及
多文件/多步骤?}
    E -->|是| F[切换为标准流程]
    E -->|否| G[继续 quick 执行]
    B -->|否| H[完成 fast 任务]

这个升级路径的关键在于：不要在发现任务比预期复杂时硬撑。一个本应该走 quick 的任务如果强行用 fast 完成，往往会导致：

修改不完整（只修了表面问题，没处理关联代码）
缺乏验证（没有运行测试就提交）
无法追溯（没有 PLAN.md 记录原始意图）

6.3 速度不是唯一目标

GSD 的快速工作流常常被误解为"捷径"或"偷懒"。但更准确的理解是：它们是对 "不同复杂度任务需要不同治理深度" 这一工程现实的承认。

flowchart LR
    A[开发效率] --> B[执行速度]
    A --> C[可维护性]
    A --> D[可追溯性]

    B --> E{"任务复杂度"}
    E -->|低| F[fast/quick
速度优先]
    E -->|高| G[标准流程
质量优先]

    C -.-> F
    C -.-> G
    D -.-> F
    D -.-> G

真正高效的团队不是一味求快，而是为每个任务选择恰到好处的执行深度。quick 和 fast 工作流的价值，正在于它们填补了 "重型 Phase 执行" 和 "纯手工修改" 之间的空白地带，让 GSD 的覆盖范围从大型项目交付一直延伸到日常编码的每个微小动作。

小结

quick.md 和 fast.md 是 GSD 工作流编排层中最轻量、却最常被调用的两个工作流。它们的设计哲学可以用一句话概括：

"The right tool for the right job, at the right level of rigor."

工作流	核心特征	适用边界	风险等级
fast	零规划、Inline 执行、无状态跟踪	< 2 分钟、一句话能说清、非关键路径	中（滥用会导致技术债务）
quick	最小规划、精简子代理、Quick Tasks 跟踪	小型修复、热修复、文档更新、原型验证	低（保留核心保障机制）
标准流程	完整规划、Wave 并行、多轮验证	功能开发、架构重构、复杂 Bug 修复	低（最全面的质量保障）

理解何时使用 fast、何时使用 quick、何时必须回归标准流程，是掌握 GSD 执行层的关键能力。快速工作流不是对规范的妥协，而是对效率与质量平衡点的精准把控。

📌 下一篇预告：第 19 篇《验证与审计工作流》将深入解析 GSD 的质量保障后半场——从 verify-phase.md 的目标回溯验证，到 audit-milestone.md 的里程碑审计，再到 code-review.md 和 audit-fix.md 构成的自动化审查流水线。我们将看到 GSD 如何在 "快速执行" 和 "严谨验证" 之间构建闭环，确保速度从不以牺牲质量为代价。