这是「GSD 全景代码解析」专题的第 20 篇。在前面的文章中，我们从命令系统到核心工作流编排，从 execute-phase 的 Wave 调度到 plan-phase 的 Chunked Planning，逐步深入了 GSD 的运转机制。当代码被写出来之后，如何保证它的质量？GSD 给出的答案是：让 AI 审查 AI 写的代码。本章将解析 GSD 中专门负责质量把关的三条工作流——code-review、code-review-fix 和 reapply-patches，以及支撑它们的 diff 处理引擎。

---

代码审查与修复工作流

在 GSD 的执行管道中，代码产出只是第一步。真正决定项目能否持续健康运转的，是审查与修复的闭环。GSD 为此设计了一套完整的工作流家族：

工作流	职责	触发时机
code-review	对代码变更进行系统性审查	execute-phase 结束后、merge 前
code-review-fix	修复审查中发现的问题	code-review 发现问题后
reapply-patches	将 diff 补丁重新应用到目标分支	冲突发生、cherry-pick 失败时

这三条工作流共同构成了 GSD 的质量门禁系统（Quality Gate System），它们不是可有可无的装饰品，而是执行管道中不可或缺的环节。本文将逐一拆解它们的设计哲学与实现细节。

---

一、code-review 工作流：AI 审查 AI

1.1 工作流定位

code-review.md 是 GSD 中专门负责代码质量审查的工作流。它的核心假设是：

AI 生成的代码必须经过独立视角的审查，才能进入主分支。

这与传统的人类 Code Review 不同——GSD 的 code-review 由另一个专门的 Agent（gsd-code-reviewer）执行，形成"AI 写、AI 审"的闭环。这种设计有几个关键优势：

1. 无疲劳偏差：Reviewer Agent 不会因为审查了 100 个文件而降低标准
2. 一致性：审查标准来自 verification-patterns.md，不受个人偏好影响
3. 可扩展性：可以同时启动多个 Reviewer 并行审查不同模块
4. 可追溯性：所有审查意见都被写入 REVIEW.md，成为项目历史的一部分

1.2 审查流程

flowchart TD
    subgraph A["① 前置准备"]
        A1[加载变更范围
git diff --stat] --> A2[加载审查标准
verification-patterns.md] --> A3[加载项目上下文
CLAUDE.md + PROJECT.md]
    end

    subgraph B["② 审查执行"]
        B1[生成 diff 摘要] --> B2[按文件分组审查] --> B3[逐行代码分析] --> B4[标注问题等级]
    end

    subgraph C["③ 结果输出"]
        C1[汇总 REVIEW.md] --> C2{发现严重问题?}
        C2 -->|是| C3[触发 code-review-fix]
        C2 -->|否| C4[标记审查通过]
    end

    subgraph D["④ 质量门禁"]
        C3 --> D1[修复循环]
        C4 --> D2[允许进入 merge]
    end

    A --> B --> C --> D

整个流程可以分为四个阶段：

阶段 ①：前置准备

code-review 工作流首先通过 gsd-sdk query init.code-review 加载项目上下文，然后获取本次审查的范围。与人类的 PR Review 不同，AI Reviewer 可以一次性加载整个项目的架构文档（CLAUDE.md、PROJECT.md），从而站在更高的视角审视代码变更是否符合整体设计意图。

阶段 ②：审查执行

这是核心阶段。Reviewer Agent 会对每个变更文件进行逐行分析，检查点包括：

• 是否符合项目的编码规范
• 是否引入了新的反模式（anti-pattern）
• 是否有边界情况未处理
• 命名是否清晰、注释是否充分
• 测试覆盖率是否足够
• 性能隐患
• 安全漏洞（如 SQL 注入、XSS、敏感信息泄露）

阶段 ③：结果输出

审查结果以结构化的 REVIEW.md 文件形式输出，包含以下内容：

# Code Review Report

## 变更概要
- 审查范围：12 个文件，+482/-127 行
- 审查时间：2026-04-24
- Reviewer：gsd-code-reviewer

## 问题列表

### 🔴 Critical（阻塞性）
- **[auth.js:45]** 密码以明文形式存储到 localStorage，存在严重安全风险
- **[api.ts:112]** 缺少输入校验，可能导致 SQL 注入

### 🟠 Major（重要）
- **[utils.ts:23]** 递归函数缺少终止条件检测
- **[component.vue:78]** 生命周期钩子中存在内存泄漏风险

### 🟡 Minor（建议性）
- **[styles.css:34]** 魔法数字应提取为常量
- **[README.md:12]** 文档中的示例代码已过时

## 通过标准
- [ ] 所有 Critical 问题已修复或已接受风险
- [ ] 所有 Major 问题已修复或有合理解释
- [x] Minor 问题不影响合并（建议后续迭代处理）

阶段 ④：质量门禁

根据 REVIEW.md 中的问题等级，code-review 工作流会决定下一步路由：

• Critical 问题存在 → 必须进入 code-review-fix 工作流
• Major 问题存在 → 建议进入修复，但可通过 --force 绕过
• 仅 Minor 问题 → 标记审查通过，允许继续 merge 流程

1.3 与 gsd-code-reviewer Agent 的协作

code-review 工作流本身不执行审查逻辑，而是委托给专门的 gsd-code-reviewer Agent。这种分工遵循 GSD 的"Thin Orchestrator"原则：

sequenceDiagram
    participant Workflow as code-review 工作流
    participant Reviewer as gsd-code-reviewer
    participant Git as git 仓库
    participant State as STATE.md

    Workflow->>Git: 获取 diff 范围
    Workflow->>Reviewer: Spawn Agent + 传递上下文
    Reviewer->>Reviewer: 逐文件分析
    Reviewer->>Workflow: 返回 REVIEW.md 内容
    Workflow->>Git: 写入 REVIEW.md
    Workflow->>State: 更新审查状态
    Workflow->>Workflow: 决策：通过 / 修复 / 人工介入

gsd-code-reviewer Agent 的定义位于 agents/gsd-code-reviewer.md，它包含：

• 角色定义：你是一个严格的代码审查者，专注于发现缺陷而非赞美代码
• 审查清单：来自 verification-patterns.md 的 40+ 条检查项
• 输出格式：严格的结构化输出模板
• 等级判定标准：Critical / Major / Minor 的判定规则

1.4 审查标准来源

审查标准主要来自 verification-patterns.md，这是一个独立的参考文档，定义了跨项目的通用验证模式。它的内容涵盖：

类别	检查项示例
安全性	无明文存储密码、输入校验、XSS 防护、CORS 配置
可靠性	错误处理、超时设置、重试策略、幂等性
性能	N+1 查询检测、大文件读取、内存泄漏、事件监听器清理
可维护性	圈复杂度控制、函数长度、命名规范、注释完整性
测试	分支覆盖、边界测试、Mock 使用、测试隔离性
架构	层间依赖方向、接口稳定性、重复代码检测

code-review 工作流通过 @reference verification-patterns.md 的方式按需加载这些标准，确保 Reviewer Agent 拥有最新的审查准则。

---

二、code-review-fix 工作流：修复审查问题

2.1 工作流定位

当 code-review 发现问题后，code-review-fix 工作流负责将这些问题逐一修复。它的设计哲学是：

修复不是重写，而是精准、最小化的变更。

code-review-fix 的核心约束包括：

• 只修改被审查标记为问题的代码
• 保持原有代码风格和架构一致性
• 每个修复对应一个独立的 commit
• 修复完成后必须重新触发审查验证

2.2 修复流程

flowchart TD
    A[加载 REVIEW.md] --> B[按优先级排序问题]
    B --> C{是否存在 Critical?}
    C -->|是| D[优先修复 Critical]
    C -->|否| E[按文件分组修复]
    D --> F[应用最小化变更]
    E --> F
    F --> G[运行相关测试]
    G --> H{测试通过?}
    H -->|否| I[分析失败原因]
    I --> J[调整修复方案]
    J --> F
    H -->|是| K[提交修复 commit]
    K --> L[重新触发 code-review]
    L --> M{新问题?}
    M -->|是| N[继续修复循环]
    M -->|否| O[标记修复完成]
    N --> B

步骤详解：

① 加载并排序问题

工作流首先读取 REVIEW.md，将所有问题按优先级排序（Critical → Major → Minor）。Critical 问题必须优先处理，因为它们可能阻塞整个流程。

② 按文件分组修复

为了效率，code-review-fix 会将同一文件的问题聚合在一起处理，避免反复切换上下文。但对于跨文件依赖的修复，工作流会识别依赖顺序，确保先修复底层再修复上层。

③ 应用最小化变更

这是 code-review-fix 的关键设计。工作流通过 gsd-executor Agent 执行修复，但给它明确的约束：

约束清单：
- 仅修改被 REVIEW.md 明确标记的行或函数
- 不得重构未涉及的问题代码
- 保持原始缩进、命名风格和注释语言
- 如果修复需要引入新依赖，必须说明理由

④ 测试验证

每个修复都必须通过相关测试。code-review-fix 会自动：

• 运行被修改文件的单元测试
• 运行受影响模块的集成测试
• 如果测试不存在，要求补充测试（作为新的 Minor 问题）

⑤ 提交与重审

修复完成后，code-review-fix 会：

1. 生成一个格式化的 commit：fix(review): resolve code review issues (#42)
2. 将修复详情追加到 REVIEW.md 的"修复记录"部分
3. 重新触发 code-review 工作流验证修复结果
4. 如果新审查发现了新的问题（引入性缺陷），进入下一轮修复循环

2.3 修复验证机制

sequenceDiagram
    participant FixWF as code-review-fix
    participant Executor as gsd-executor
    participant Reviewer as gsd-code-reviewer
    participant Tests as 测试套件

    FixWF->>Executor: 派发修复任务 + REVIEW.md 上下文
    Executor->>Executor: 生成修复 diff
    Executor->>FixWF: 返回修复方案
    FixWF->>Tests: 运行测试验证
    Tests->>FixWF: 通过 / 失败
    FixWF->>Reviewer: 重新审查修复后的代码
    Reviewer->>FixWF: 新问题? 0 / N
    FixWF->>FixWF: 决策：完成 / 继续修复

这种"修复-验证-重审"的循环确保了修复的质量。在实际运行中，大多数 code-review-fix 能在 1-2 轮循环内完成，因为：

• Reviewer 的标准是确定性的，不会因为"审美"反复横跳
• 修复范围被严格限制，引入新问题的概率较低
• 测试验证在提交前拦截了大部分回归

---

三、reapply-patches：补丁重应用工作流

3.1 为什么需要补丁重应用

在 GSD 的 Wave 执行模型中，每个任务都在独立的 worktree 分支上开发。当多个 Wave 并行执行时，它们的代码变更可能基于不同的 commit 点。在合并阶段，会出现以下情况：

1. Wave A 的变更基于 main@100
2. Wave B 的变更也基于 main@100
3. Wave A 先合并到 main，main 变为 main@101
4. Wave B 的补丁应用到 main@101 时发生冲突

flowchart LR
    subgraph Main["main 分支"]
        M100[commit 100
基础版本] --> M101[commit 101
Wave A 合并]
    end

    subgraph WaveA["Wave A worktree"]
        W100A[基于 commit 100] --> WA_PATCH[+patch A]
    end

    subgraph WaveB["Wave B worktree"]
        W100B[基于 commit 100] --> WB_PATCH[+patch B]
    end

    M100 -.->|checkout| W100A
    M100 -.->|checkout| W100B
    WA_PATCH -->|merge| M101
    WB_PATCH -.->|reapply?| M101

reapply-patches 工作流就是专门处理这种情况的。它的目标是将一个分支上的代码变更（diff），安全地迁移到另一个可能已经发生变化的 target 分支上。

3.2 工作流流程

flowchart TD
    A[接收源分支 + 目标分支] --> B[生成源分支的 diff]
    B --> C[尝试直接应用 patch]
    C --> D{成功?}
    D -->|是| E[验证应用结果]
    D -->|否| F[分析冲突原因]
    F --> G{冲突类型}
    G -->|上下文偏移| H[使用 fuzzy match 重定位]
    G -->|逻辑冲突| I[标记需人工介入]
    G -->|已存在| J[跳过重复变更]
    H --> K[重新应用]
    K --> D
    E --> L[运行回归测试]
    L --> M{测试通过?}
    M -->|是| N[提交并记录]
    M -->|否| O[回滚并分析]
    O --> P[调整 patch 策略]
    P --> C
    I --> Q[生成冲突报告]

3.3 diff 处理的三层策略

reapply-patches 采用了三层递进策略来处理 patch 应用：

层级	策略	适用场景	成功率
L1：精确匹配	git apply --check + git apply	目标分支未修改相关文件	~60%
L2：模糊匹配	git apply -3（three-way merge）	上下文偏移但逻辑未变	~30%
L3：智能重构	解析 AST，语义级 patch 应用	代码结构变化但语义等价	~8%
L4：人工介入	生成详细冲突报告，请求人工解决	逻辑冲突无法自动解决	~2%

L1 精确匹配

这是最简单的场景。如果目标分支的对应文件自基线以来没有变化，patch 可以直接应用：

# reapply-patches 内部的典型操作序列
git diff base..source_branch > changes.patch
git checkout target_branch
git apply --check changes.patch  # 预检查
git apply changes.patch          # 应用

L2 模糊匹配

当目标分支的对应文件有小的修改（如新增了几行无关代码），精确匹配会失败。此时使用 three-way merge：

git apply -3 changes.patch

-3 选项会尝试使用共同的祖先 commit 作为基准进行三路合并。这是 Git 的默认 merge 策略，能够处理大部分上下文偏移的情况。

L3 智能重构

这是 reapply-patches 最复杂也最强大的功能。当代码结构发生变化（如函数被重命名、参数列表变更、代码块被移动），传统的 text-level diff 会彻底失效。

此时，reapply-patches 会：

1. 解析源文件和目标文件的 AST（抽象语法树）
2. 识别语义等价的代码元素（如重命名的函数）
3. 在 AST 层面应用变更，而非 text 层面
4. 将修改后的 AST 反序列化回源代码

flowchart LR
    A[源文件 AST] --> B[提取语义变更]
    C[目标文件 AST] --> D[建立语义映射]
    B --> E[AST 级 patch 应用]
    D --> E
    E --> F[代码生成]
    F --> G[格式化输出]

L4 人工介入

对于无法自动解决的冲突，reapply-patches 会生成详细的冲突报告，包括：

• 冲突文件列表
• 冲突代码片段（双方版本对比）
• 冲突原因分析（为什么自动解决失败）
• 建议的解决方向

然后工作流会暂停，等待人工解决或用户提供额外上下文。

---

四、diff 处理引擎：底层机制

4.1 diff 格式解析

GSD 的 diff 处理基于标准的 Unified Diff 格式，但扩展了一些元数据以支持 AI 场景：

--- a/src/auth.js
+++ b/src/auth.js
@@ -42,7 +42,9 @@ function login(credentials) {
   // TODO: implement auth
-  const token = credentials.password;
+  const token = await bcrypt.hash(credentials.password, 12);
+  const session = await createSession(token);
+  return session.id;
 }

 // AI-NOTE: 修复了明文存储密码的安全问题
// REVIEW-ID: auth-001

GSD 的 diff 解析器会提取以下信息：

字段	来源	用途
文件路径	--- / +++ 行	定位目标文件
变更范围	@@ -L,N +L,N @@	确定上下文窗口
变更类型	+ / - 前缀	新增 / 删除 / 修改
AI 注释	// AI-NOTE:	变更意图说明
审查 ID	// REVIEW-ID:	关联审查记录

4.2 补丁应用策略

reapply-patches 的补丁应用不是简单的 git apply，而是一个状态机：

stateDiagram-v2
    [*] --> ParseDiff: 接收 patch
    ParseDiff --> ValidatePatch: 解析成功
    ValidatePatch --> CheckTarget: 语法合法
    CheckTarget --> AttemptApply: 目标文件存在
    CheckTarget --> CreateFile: 目标文件不存在
    AttemptApply --> VerifyResult: 应用成功
    AttemptApply --> AnalyzeConflict: 应用失败
    AnalyzeConflict --> AttemptApply: 可自动解决
    AnalyzeConflict --> HumanIntervention: 需人工介入
    HumanIntervention --> AttemptApply: 获得人工方案
    VerifyResult --> RunTests: 语法检查通过
    RunTests --> Commit: 测试通过
    RunTests --> Rollback: 测试失败
    Rollback --> AttemptApply: 调整策略重试
    Commit --> [*]: 完成
    CreateFile --> VerifyResult: 创建成功

4.3 冲突检测和解决

冲突检测发生在 patch 应用阶段。reapply-patches 定义了三种冲突级别：

Level 1：Text Conflict（文本冲突）

传统的 Git merge conflict，表现为：

<<<<<<< HEAD
  const x = 1;
=======
  const x = 2;
>>>>>>> patch

解决策略：

• 如果是上下文偏移（如双方在同一函数附近新增代码），尝试智能合并
• 如果是逻辑冲突（一方改 A 另一方改 B，互斥），标记为 Level 2

Level 2：Semantic Conflict（语义冲突）

代码能合并，但合并后的逻辑是错误的。例如：

• Wave A 将函数 validate() 重命名为 checkInput()
• Wave B 在另一个文件中新增了对 validate() 的调用
• 合并后代码编译通过，但运行时抛出 validate is not defined

解决策略：

• 通过静态分析（如 ESLint、TypeScript compiler）检测未定义引用
• 通过测试运行捕获运行时错误
• 如果自动修复失败，标记为 Level 3

Level 3：Architectural Conflict（架构冲突）

双方变更在架构层面不兼容。例如：

• Wave A 引入了一个全局状态管理方案
• Wave B 在同一模块引入了另一个互斥的状态管理方案

解决策略：

• 无法自动解决
• 生成架构冲突报告
• 将问题上报给 Orchestrator 或人类开发者

flowchart TD
    A[检测到冲突] --> B{冲突级别}
    B -->|Level 1| C[Text Conflict]
    B -->|Level 2| D[Semantic Conflict]
    B -->|Level 3| E[Architectural Conflict]

    C --> F[智能合并 / 上下文重定位]
    D --> G[静态分析 + 测试验证]
    E --> H[生成冲突报告]

    F --> I{解决成功?}
    G --> I
    I -->|是| J[标记 resolved]
    I -->|否| K[升级冲突级别]
    K --> B
    H --> L[人工介入]

---

五、代码审查的质量标准

5.1 审查通过标准

GSD 对 code-review 的通过标准有明确定义，这些标准被编码在 verification-patterns.md 中：

## 审查通过标准（Pass Criteria）

### 必须满足（Blocking）
- [ ] 无 Critical 级别安全问题
- [ ] 无导致崩溃或数据丢失的缺陷
- [ ] 所有新增代码路径至少有一个测试覆盖
- [ ] 无违反项目架构约束的变更

### 应该满足（Non-blocking but required）
- [ ] 无 Major 级别逻辑错误
- [ ] 命名符合项目规范
- [ ] 错误处理完整
- [ ] 性能影响已评估

### 建议满足（Nice to have）
- [ ] 注释清晰完整
- [ ] 无代码重复
- [ ] 复杂度在合理范围

5.2 审查的深度控制

code-review 工作流支持根据场景调整审查深度：

深度级别	适用场景	检查范围
Quick Scan	热修复、配置变更	安全 + 语法 + 基本逻辑
Standard	常规功能开发	全部 40+ 检查项
Deep Dive	核心模块重构、安全相关	标准 + 架构影响 + 性能基准
Audit	合规审查、发布前检查	深度 + 依赖审计 + 供应链安全

深度级别可以通过命令参数或 config.json 中的 review_depth 配置项指定。

5.3 审查的质量指标

GSD 追踪以下审查质量指标，用于持续改进审查标准：

指标	定义	健康范围
审查漏报率	审查通过但后续发现问题的比例	< 5%
审查误报率	标记为问题但实际无误的比例	< 15%
修复轮次	平均需要多少轮修复才能通过	<= 1.5
审查耗时	完成一次审查的平均时间	< 5min
补丁重应用率	需要 reapply-patches 介入的比例	< 10%

---

六、自动化审查 vs 人工审查

6.1 GSD 的混合审查模型

GSD 不主张完全替代人工审查，而是构建了一个分层审查模型：

flowchart TD
    subgraph Auto["自动化层"]
        A1[Lint / Format] --> A2[静态分析]
        A2 --> A3[单元测试]
        A3 --> A4[AI Code Review]
    end

    subgraph Semi["半自动层"]
        B1[reapply-patches 冲突报告]
        B2[架构冲突检测]
        B3[性能回归预警]
    end

    subgraph Human["人工层"]
        C1[业务逻辑正确性]
        C2[用户体验影响]
        C3[设计意图符合度]
        C4[创新性与简洁性]
    end

    Auto -->|通过| Semi
    Semi -->|通过| Human
    Human -->|通过| Merge

自动化层：100% 由 AI / 工具执行，零人工干预。包括代码格式化、Lint、静态分析、单元测试和 gsd-code-reviewer 的审查。

半自动层：AI 发现潜在问题并生成报告，但需要人类做最终判断。例如架构冲突、性能回归等。

人工层：需要人类经验和直觉的领域。AI 目前难以判断"这个变更是否真正满足了用户需求"或"这个 API 设计是否直观"。

6.2 自动化审查的优势

1. 速度与规模：AI 可以在数分钟内审查数百个文件的变更
2. 一致性：不受情绪、疲劳、时间压力的影响
3. 知识覆盖：可以同时加载项目文档、编码规范、安全指南等大量参考材料
4. 可追溯性：所有审查意见都被结构化记录，便于后续分析

6.3 自动化审查的局限

1. 语义理解：AI 可能理解代码"做了什么"，但难以判断"做的是否正确"
2. 业务上下文：缺乏对业务 domain 的深度理解
3. 创新判断：难以评估一个新设计是否比旧设计更好
4. 边缘情况：对于极其罕见的边界条件，AI 可能误判为不可能发生

6.4 最佳实践：人机协作

GSD 推荐的最佳实践是：

让 AI 做它擅长的（一致性、规模、速度），让人类做人类擅长的（判断、创新、业务理解）。

具体操作建议：

场景	推荐方式
日常功能开发	AI 审查为主，人类抽查
安全相关变更	AI 审查 + 必过人类审查
核心架构变更	AI 预审查 + 人类深度审查
紧急热修复	AI 快速审查，事后人工复盘
新人代码	AI 审查 + 导师人工审查

---

七、三条工作流的协作关系

flowchart TB
    subgraph Execute["execute-phase"]
        E1[Wave 执行完成]
    end

    subgraph Review["代码审查循环"]
        R1[code-review] --> R2{发现问题?}
        R2 -->|是| R3[code-review-fix]
        R3 --> R4[重新审查]
        R4 --> R2
        R2 -->|否| R5[审查通过]
    end

    subgraph Merge["合并阶段"]
        M1[git merge] --> M2{冲突?}
        M2 -->|是| M3[reapply-patches]
        M3 --> M4[解决冲突]
        M4 --> M1
        M2 -->|否| M5[合并成功]
    end

    subgraph Gate["质量门禁"]
        G1[回归测试] --> G2{通过?}
        G2 -->|否| G3[回滚或修复]
        G2 -->|是| G4[进入下一阶段]
    end

    E1 --> Review
    R5 --> Merge
    M5 --> Gate
    G3 --> Review

这个图展示了代码审查与修复在整个 GSD 执行管道中的位置：

1. execute-phase 产出代码变更
2. code-review 对变更进行质量审查
3. code-review-fix 修复发现的问题
4. reapply-patches 处理合并时的冲突
5. 质量门禁 做最后的回归测试验证

它们不是孤立的工具，而是一个有机的质量保障体系。

---

总结

本文解析了 GSD 框架中三条核心的质量保障工作流：

工作流	核心职责	关键设计
code-review	系统性代码审查	Thin Orchestrator + gsd-code-reviewer Agent
code-review-fix	精准修复审查问题	最小化变更 + 修复-验证-重审循环
reapply-patches	补丁重应用与冲突解决	四层递进策略（精确→模糊→AST→人工）

以及支撑它们的 diff 处理引擎，包括：

• Unified Diff 解析：提取语义元数据，支持 AI-NOTE 和 REVIEW-ID
• 三层冲突检测：Text Conflict → Semantic Conflict → Architectural Conflict
• 质量指标追踪：漏报率、误报率、修复轮次等可度量指标

GSD 的审查体系设计体现了一个核心原则：

质量不是事后检查出来的，而是内建在流程中的。

code-review 不是 execute-phase 的可选附件，而是执行管道的必经关卡；code-review-fix 不是"重写一遍"，而是精准、可验证的修复；reapply-patches 不是简单的 git merge，而是一个智能的冲突解决引擎。三者共同构建了一个可自动化、可度量、可迭代的质量保障体系。

---

下一篇预告：第 21 篇《工作流设计模式总结》

经过 20 篇文章的逐层拆解，我们已经遍历了 GSD 的命令系统、工作流编排、Agent 设计和质量保障体系。在下一篇中，我们将跳出单个工作流的细节，从设计模式的视角总结 GSD 工作流体系的通用架构模式——包括 Thin Orchestrator、Context Budgeting、渐进式披露、检查点协议、质量门禁等核心模式。这些模式不仅适用于 GSD，也可以指导你设计自己的 AI 驱动工作流系统。敬请期待！