命令设计模式与最佳实践

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

在前 11 篇文章中，我们已经完整走遍了 GSD 的命令版图——从生命周期管理到规划执行，从验证审查到调优诊断。但这些命令并非随意堆砌，它们背后共享着一套经过反复锤炼的设计模式与工程规范。本篇将跳出具体命令的实现细节，上升到方法论层面，系统总结 GSD 命令系统的设计哲学、文件组织范式、Prompt 工程技巧，以及自定义命令的完整开发流程。

---

一、命令文件结构模板：契约即代码

GSD 命令系统的第一个核心洞察是：每个命令文件既是一份人类可读的操作手册，也是一份机器可执行的运行时契约。这种「文档即代码」的双态性，是 GSD 能够同时被开发者和 AI Agent 理解的关键。

1.1 标准文件结构

一个 GSD 命令文件由两大部分组成：

命令文件（.md）
├── YAML Frontmatter      # 元数据与权限声明
│   ├── name              # 命令标识符
│   ├── description       # 命令描述
│   ├── argument-hint     # 参数提示
│   ├── allowed-tools     # 工具白名单
│   └── model             # 指定模型（可选）
└── Prompt 主体           # 执行逻辑与上下文定义
    ├── <runtime_note>    # 运行时适配说明
    ├── <context>         # 参数与 flags 定义
    ├── <objective>       # 目标与产出物
    ├── <execution_context>  # 依赖文件引用
    └── <process>         # 执行步骤描述

这种结构化的好处在于：

1. 可解析性：YAML frontmatter 可以被 CLI 工具快速解析，用于命令注册、补全提示和权限校验
2. 自描述性：Prompt 主体使用 XML 标签组织，即使不借助外部工具，人类也能快速理解命令的用途和行为
3. 可验证性：allowed-tools 白名单让系统在执行前就能预判命令的副作用范围

1.2 最小可运行模板

下面是一份从零开始创建 GSD 命令的最小模板：

---
name: gsd:command-name
description: 一句话描述命令的核心功能
argument-hint: "[--flag] <required-arg>"
allowed-tools:
  - Read
  - Bash
  - Write
  - Task
  - AskUserQuestion
---

<runtime_note>
**Copilot (VS Code):** 如使用 VS Code Copilot，请将 `AskUserQuestion` 替换为 `vscode_askquestions`。
</runtime_note>

<context>
**Flags:**
- `--flag` — 标志的语义说明

**Arguments:**
- `<required-arg>` — 必需参数的说明
</context>

<objective>
命令的核心目标描述。

**Creates:**
- `产出文件路径.md` — 产出物说明

**After this command:** 建议的后续操作。
</objective>

<execution_context>
@~/.claude/get-shit-done/workflows/workflow-name.md
@~/.claude/get-shit-done/references/reference-name.md
</execution_context>

<process>
执行 workflow-name.md 工作流，端到端完成目标。
保留所有工作流关卡（validation、approvals、commits、routing）。
</process>

这份模板涵盖了命令文件的五个标准区块。在实际编写中，你可以根据命令的复杂度进行裁剪或扩展，但frontmatter 的三项核心字段（name、description、allowed-tools）必须存在。

---

二、YAML Frontmatter 规范详解

YAML frontmatter 是命令的「身份证」和「权限证书」。它位于文件顶部的 --- 围栏内，决定了命令如何被注册、如何被提示、以及拥有多大的操作权限。

2.1 字段规范一览

字段	类型	必填	说明
name	string	是	命令完整标识符，格式为 gsd:command-name
description	string	是	一句话描述，用于帮助文档和 IDE 自动补全提示
argument-hint	string	否	参数提示模板，如 [--auto] 或 <phase-number>
allowed-tools	list	是	该命令执行期间可调用的工具白名单
model	string	否	指定使用的模型，如 claude-sonnet-4、gpt-4o
context	list	否	需要预加载的上下文文件列表（部分命令使用）

2.2 name：命名空间与标识

name 字段采用 gsd:{command-name} 的格式，其中 gsd: 是全局命名空间前缀。这个设计看似简单，实则解决了三个工程问题：

1. 命名空间隔离：避免与用户自定义命令或其他插件命令冲突
2. IDE 补全优化：以 gsd: 开头的命令在输入 /gsd 时即可触发 IDE 的模糊匹配
3. 权限路由：系统可以通过前缀快速识别命令所属模块，加载对应的配置模板

2.3 description：语义压缩的艺术

description 不是「使用说明」，而是语义压缩包——它需要在 10 个英文单词或 20 个汉字以内，精确传达命令的核心价值。

# ✅ 好的描述：精确、无歧义、包含关键信息
description: Initialize a new project with deep context gathering and PROJECT.md
description: Execute all plans in a phase with wave-based parallelization

# ❌ 差的描述：模糊、冗余、缺乏信息量
description: This command does project stuff
description: A very useful command for developers to use in their daily work

description 的质量直接影响 IDE 补全提示的可用性。当用户输入 /gsd 时，IDE 展示的就是这个字段——如果描述模糊，用户需要反复试错才能找到正确的命令。

2.4 allowed-tools：最小权限原则

allowed-tools 是 GSD 安全模型的基石。它明确声明了命令在执行期间可以调用的工具集，任何超出白名单的工具调用都会被运行时拒绝。

以 execute-phase 命令为例：

allowed-tools:
  - Read        # 读取文件、模板、配置
  - Write       # 创建/修改项目文件
  - Edit        # 编辑现有代码
  - Glob        # 文件模式匹配
  - Grep        # 文本搜索
  - Bash        # 执行 shell 命令（git、测试等）
  - Task        # 创建并行子任务
  - TodoWrite   # 更新 TODO 列表
  - AskUserQuestion  # 向用户提问

对比 stats 命令的精简白名单：

allowed-tools:
  - Read        # 只读统计，无需写入
  - Bash        # 执行 git log 等统计命令

权限设计的黄金法则：只授予完成当前任务所必需的最小工具集。过度授权不仅增加安全风险，还会让 Agent 在复杂场景下产生「工具选择困惑」——面对太多可用工具时，模型反而更难做出正确的调用决策。

2.5 model：模型路由（可选）

部分命令可以通过 model 字段指定其执行时使用的 AI 模型：

model: claude-opus-4    # 需要深度推理的命令
model: claude-sonnet-4  # 标准复杂度的命令

如果省略此字段，命令将继承全局配置中的 model 设置。在 GSD 的设计中，Orchestrator 通常使用 Sonnet 级别的模型以平衡速度和成本，而需要深度分析的任务（如 code-review、debug）则显式指定 Opus 级别。

2.6 context：上下文预加载（可选）

少数命令使用 context 字段声明需要预加载的上下文文件：

context:
  - ~/.claude/get-shit-done/references/ui-brand.md
  - ~/.claude/get-shit-done/templates/project.md

这些文件在执行工作流之前就会被加载到上下文中，确保 Agent 在执行时能够访问必要的背景知识。不过，GSD 更常见的做法是将上下文引用放在 <execution_context> 区块中，由工作流自身按需加载——这样可以避免不必要的上下文膨胀。

---

三、提示词设计技巧：从 Prompt 到 Meta-Prompt

命令文件的 Prompt 主体是 GSD 命令系统的「灵魂」。一个优秀的命令 Prompt 不仅需要精确传达意图，还需要管理好上下文预算、控制信息暴露的节奏，并确保模型输出结构化的、可解析的结果。

3.1 Progressive Disclosure：渐进式披露

**Progressive Disclosure（渐进式披露）**是 GSD Prompt 工程的首要原则。它的核心思想是：不要把所有信息一次性塞给模型，而是按照执行阶段逐步释放。

flowchart LR
    subgraph 传统方式
        A1[全部上下文
一次性加载] --> B1[模型注意力分散
关键信息被稀释]
    end

    subgraph Progressive Disclosure
        A2[阶段 1
加载前置上下文] --> B2[阶段 2
按需加载详细规范]
        B2 --> C2[阶段 3
加载代码基线]
        C2 --> D2[模型始终聚焦
当前任务所需信息]
    end

在 GSD 命令中，渐进式披露体现在三个层面：

1. 命令层：命令文件本身只包含目标和路由信息，具体执行逻辑在工作流文件中
2. 工作流层：工作流分阶段加载参考文档，如研究阶段加载 references/research.md，执行阶段加载 references/execution.md
3. Agent 层：每个子 Agent 只接收其职责所需的上下文切片，Orchestrator 不会把所有文件传给所有 Agent

例如，new-project 命令的 <execution_context> 引用了 4 个文件，但这些文件并非同时加载：

<execution_context>
@~/.claude/get-shit-done/workflows/new-project.md      # 主工作流，首先加载
@~/.claude/get-shit-done/references/questioning.md      # 提问阶段加载
@~/.claude/get-shit-done/references/ui-brand.md         # UI 设计阶段加载
@~/.claude/get-shit-done/templates/project.md           # 生成 PROJECT.md 时加载
</execution_context>

3.2 Context Budget 管理

GSD 对上下文预算的管理精确到字节级别。每个命令在设计时都需要考虑：这个命令会消耗多少 token？如何为子 Agent 分配预算？

flowchart TD
    A[总上下文预算
200K / 1M tokens] --> B[Orchestrator 预算
~15-20%]
    A --> C[子 Agent 预算
~80-85%]
    B --> B1[命令解析
工作流路由]
    C --> C1[Executor 1
100% 纯净上下文]
    C --> C2[Executor 2
100% 纯净上下文]
    C --> C3[Verifier
100% 纯净上下文]

execute-phase 命令的 Prompt 中明确声明了这一预算分配策略：

Context budget: ~15% orchestrator, 100% fresh per subagent.

这意味着：

• **Orchestrator（主上下文）**只保留约 15% 的预算用于发现计划、分析依赖、分组 wave
• 每个子 Agent在执行时获得一个全新的、100% 的上下文窗口，完全不受主会话的污染
• Orchestrator 的"瘦身"策略是 GSD 能够持续处理大规模项目的关键

3.3 指令分层：系统指令 vs 用户指令

GSD 命令 Prompt 采用双层指令架构，将「必须遵守的行为约束」与「当前任务的上下文信息」分离：

层级	位置	内容	语气
系统指令层	<process>、flag 处理规则	行为约束、执行步骤、禁止事项	强制性、无条件
用户指令层	<context>、<objective>	参数值、任务描述、预期产出	描述性、场景化

以 execute-phase 的 flag 处理规则为例，这是典型的系统指令：

Flag handling rule:
- The optional flags documented below are available behaviors, not implied active behaviors
- A flag is active only when its literal token appears in `$ARGUMENTS`
- If a documented flag is absent from `$ARGUMENTS`, treat it as inactive

这段指令使用绝对化的语言（"only when"、"treat as inactive"），不留任何解释空间。其目的是防止模型「自行脑补」flag 的激活状态——在 GSD 的实践中，大语言模型有时会「过度推断」，认为文档中提到的 flag 默认就是开启的。

3.4 XML 结构化提示

GSD 大量使用 XML 标签来组织 Prompt，而非自然语言段落。这种结构化方式有三个显著优势：

1. 消除歧义：<objective> 和 <process> 有明确的语义边界，模型不会混淆「目标」和「步骤」
2. 可解析性：CLI 工具可以通过正则表达式提取特定区块，用于调试和分析
3. 可组合性：不同命令可以复用相同的区块模板，保持风格一致

GSD 命令中常用的 XML 标签及其语义：

标签	语义	示例内容
<runtime_note>	运行时环境适配	IDE 工具映射、版本差异说明
<context>	输入参数与 flags	命令行参数、配置项、环境变量
<objective>	目标与产出定义	预期结果、产出文件、后续操作建议
<execution_context>	依赖声明	工作流文件、参考文档、模板文件
<process>	执行步骤	工作流调用、关卡保留、路由规则

此外，GSD 工作流内部还使用更细粒度的 XML 结构来定义任务，如：

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

这种格式消除了模糊性——action 告诉它做什么，verify 告诉它如何验证，done 告诉它完成的定义是什么。

---

四、命令命名约定：语义即接口

GSD 的 80+ 命令遵循一套严格的命名约定。这套约定不仅是为了「好看」，更是为了降低认知负荷和提升可发现性。

4.1 /gsd-{verb}-{noun} 命名模式

GSD 命令采用 {verb}-{noun} 的复合结构：

/gsd-new-project      # new(动词) + project(名词)
/gsd-plan-phase       # plan(动词) + phase(名词)
/gsd-execute-phase    # execute(动词) + phase(名词)
/gsd-verify-work      # verify(动词) + work(名词)
/gsd-code-review      # code-review(复合动词) + (隐含目标)

这种命名模式的好处：

1. 自解释性：从命令名即可推断其功能，无需查阅文档
2. 可排序性：按字母排序时，相同动词的命令会自然聚类
3. 可扩展性：新增命令时只需遵循同一模式，不会破坏命名体系

4.2 动词选择指南

GSD 命令的动词经过精心设计，每个动词都有明确的语义边界：

动词	语义	示例命令
new	创建全新实体	new-project
plan	制定计划	plan-phase, plan-task
execute	执行已制定的计划	execute-phase, execute-plan
verify	验证成果	verify-work
discuss	讨论与决策	discuss-phase
research	领域研究	research-phase
debug	问题诊断	debug
review	代码审查	code-review
map	扫描与映射	map-codebase
import	导入现有实体	import
cleanup	清理与归档	cleanup

关键原则：动词必须表达动作，而非状态。GSD 不使用 status 或 state 作为命令名（这些是名词），而是通过 stats（查看统计）或 settings（管理配置）来表达操作意图。

4.3 命名空间避免冲突

gsd: 前缀是 GSD 命令的全局命名空间。在自定义命令时，建议采用二级命名空间来避免冲突：

# 团队/项目级别的自定义命令
gsd:team-deploy      # 团队部署命令
gsd:team-onboard     # 新人入职命令

# 个人工作流命令
gsd:my-release       # 个人发布流程

命名空间规则：

1. 官方命令：直接使用 gsd: 前缀，如 gsd:new-project
2. 组织自定义：使用 gsd:{org}- 前缀，如 gsd:acme-deploy
3. 个人自定义：使用 gsd:my- 前缀，如 gsd:my-setup
4. 严禁：使用与官方命令同名或易混淆的名称

---

五、命令与 Workflows 的衔接模式

GSD 命令系统的核心架构决策是：命令是触发器，工作流是剧本。这个「薄分发层」模式是整个系统可扩展性的根基。

5.1 薄分发层（Thin Dispatch Layer）

flowchart TD
    A[用户输入
/gsd:execute-phase 1] --> B[命令文件
commands/gsd/execute-phase.md]
    B --> C{薄分发层}
    C -->|解析 frontmatter| D[权限校验
allowed-tools]
    C -->|解析 Prompt| E[加载 execution_context]
    C -->|路由| F[工作流引擎
workflows/execute-phase.md]
    F --> G[Agent 调度器]
    G --> H[工具层]

命令文件本身不执行业务逻辑。它的职责只有三个：

1. 声明元数据：我是谁、我有什么用、我需要什么权限
2. 定义输入契约：我接受什么参数、支持什么 flags
3. 路由到工作流：加载并执行对应的工作流文件

这种设计的精妙之处在于：修改命令的行为不需要修改命令文件，只需要修改它引用的工作流文件。命令文件可以被视为工作流的「稳定接口」，而工作流是「可变实现」。

5.2 工作流委托模式

每个命令通过 <execution_context> 声明其依赖的工作流和参考文档：

<execution_context>
@~/.claude/get-shit-done/workflows/new-project.md
@~/.claude/get-shit-done/references/questioning.md
@~/.claude/get-shit-done/templates/project.md
</execution_context>

这里的 @path 语法是 GSD 的文件引用协议。它告诉系统：在执行此命令前，需要先将这些文件加载到上下文中。这种显式依赖声明带来了几个好处：

1. 依赖透明：从命令文件即可看出它依赖哪些工作流和模板
2. 版本可控：工作流和模板可以独立演进，不影响命令接口
3. 可测试性：可以单独测试工作流，无需通过命令触发

5.3 Agent 编排模式

命令触发工作流后，工作流内部会编排多个 Agent 协同完成任务。GSD 有三种典型的编排模式：

flowchart TD
    subgraph 模式一：串行流水线
        A1[Planner Agent] --> B1[Executor Agent] --> C1[Verifier Agent]
    end

    subgraph 模式二：并行 Wave
        A2[Orchestrator] --> B2[Executor 1]
        A2 --> C2[Executor 2]
        A2 --> D2[Executor 3]
        B2 --> E2[Wave 2]
        C2 --> E2
        D2 --> E2
    end

    subgraph 模式三：路由分支
        A3[Router] -->|条件A| B3[Agent A]
        A3 -->|条件B| C3[Agent B]
        A3 -->|条件C| D3[Agent C]
    end

模式	适用场景	典型命令
串行流水线	阶段间有明确先后依赖	new-project（提问→研究→需求→路线图）
并行 Wave	大量独立计划需要并行执行	execute-phase
路由分支	根据条件选择不同执行路径	debug（诊断→分派专家 Agent）

5.4 门控机制（Gating Mechanism）

GSD 命令系统内置了多层门控（Gate），用于确保质量、防止误操作：

flowchart TD
    A[命令触发] --> B[前置门控]
    B -->|阶段验证| C{阶段存在?}
    C -->|否| D[错误返回]
    C -->|是| E[配置门控]
    E -->|功能开关| F{功能启用?}
    F -->|否| G[优雅跳过]
    F -->|是| H[权限门控]
    H -->|allowed-tools| I[工具调用]
    I --> J[后置门控]
    J -->|验证关卡| K[产出物检查]
    K -->|通过| L[状态更新]

门控类型	检查点	失败处理
前置门控	参数合法性、阶段存在性	返回明确错误，不进入工作流
配置门控	功能开关（如 workflow.code_review）	优雅跳过，提示用户
权限门控	allowed-tools 白名单	拒绝越权工具调用
后置门控	产出物验证、状态一致性	生成修复计划，自动重试

例如，code-review 命令的配置门控：

配置门检查 workflow.code_review：
- disabled → 跳过审查，提示用户当前配置
- enabled → 继续执行审查流程

---

六、自定义命令开发实战

理论归理论，实践出真知。下面我们将从零开始，创建一个完整的自定义 GSD 命令——/gsd:generate-api-doc，用于自动生成项目的 API 文档。

6.1 需求分析

这个自定义命令需要：

1. 扫描项目中的 API 路由文件
2. 提取接口定义、请求参数、响应结构
3. 生成结构化的 API-DOCS.md 文档
4. 支持 --update 标志以增量更新现有文档

6.2 创建工作流文件

首先创建工作流文件，定义具体的执行逻辑：

# ~/.claude/get-shit-done/workflows/generate-api-doc.md

<objective>
扫描项目 API 路由并生成结构化文档。
</objective>

<process>
1. 使用 Glob 查找 API 路由文件（如 `src/app/api/**/route.ts`、`src/pages/api/**/*.ts`）
2. 对每个路由文件，提取：
   - HTTP 方法和路径
   - 请求参数和验证规则
   - 响应结构和状态码
3. 汇总生成 `API-DOCS.md`
4. 如存在旧版文档，进行差异对比并更新
</process>

6.3 创建命令文件

然后创建命令文件，作为工作流的入口：

---
name: gsd:generate-api-doc
description: Scan API routes and generate structured API documentation
argument-hint: "[--update]"
allowed-tools:
  - Read
  - Glob
  - Grep
  - Write
  - Bash
---

<runtime_note>
**Copilot (VS Code):** 此命令不涉及 AskUserQuestion，无需工具映射。
</runtime_note>

<context>
**Flags:**
- `--update` — 增量更新模式。对比现有 `API-DOCS.md`，仅更新变更部分，保留人工编辑的注释。

**Arguments:**
- 无必需参数。命令自动探测项目结构中的 API 路由目录。
</context>

<objective>
扫描项目 API 路由文件，提取接口元数据，生成结构化的 `API-DOCS.md` 文档。

**Creates:**
- `API-DOCS.md` — 包含所有 API 端点的结构化文档

**After this command:** 手动审查生成的文档，确认接口定义准确无误。
</objective>

<execution_context>
@~/.claude/get-shit-done/workflows/generate-api-doc.md
</execution_context>

<process>
执行 generate-api-doc.md 工作流，端到端完成 API 文档生成。

Flag handling rule:
- `--update` 仅在 `$ARGUMENTS` 中出现时才激活
- 未提供 `--update` 时，执行完整重新生成（覆盖现有文档）

验证关卡：
1. 生成完成后，检查 `API-DOCS.md` 是否包含至少一个 API 端点
2. 检查文档格式是否符合 Markdown 表格规范
3. 如 `--update` 激活，确保未覆盖人工添加的注释区块
</process>

6.4 测试与迭代

自定义命令完成后，按以下流程验证：

# 1. 语法检查：确保 frontmatter 格式正确
/gsd:generate-api-doc --dry-run

# 2. 首次生成
/gsd:generate-api-doc

# 3. 增量更新
/gsd:generate-api-doc --update

# 4. 人工审查输出
# 检查 API-DOCS.md 的完整性和准确性

关键调试技巧：如果命令执行结果不符合预期，首先检查 <process> 区块中的指令是否足够明确。大语言模型对模糊指令的「猜测」是导致自定义命令失效的首要原因。

---

七、命令质量检查清单

每个 GSD 命令在发布前，都应该通过以下质量检查清单。这份清单来源于 GSD 社区在维护 80+ 命令过程中积累的实战经验。

7.1 结构与格式检查

检查项	通过标准
Frontmatter 完整性	name、description、allowed-tools 三项必填
YAML 语法正确性	可通过 yamllint 等工具验证，无缩进错误
命令名规范	格式为 gsd:command-name，全小写，连字符连接
XML 标签闭合	所有 <tag> 有对应的 </tag>，无嵌套错误
@ 引用有效	<execution_context> 中引用的文件路径真实存在

7.2 权限与安全检查

检查项	通过标准
最小权限	allowed-tools 只包含完成任务必需的工具
无过度授权	只读命令不包含 Write/Edit/Bash
危险操作确认	涉及删除、重置等操作的命令包含用户确认步骤
路径安全	不接收未经验证的用户输入作为文件路径

7.3 Prompt 质量检查

检查项	通过标准
目标明确	<objective> 能在 3 句话内说清命令要做什么
产出物清晰	明确列出命令会创建或修改的文件
后续操作建议	告知用户「下一步该做什么」
Flag 处理严谨	明确说明 flag 仅在 $ARGUMENTS 中出现时才激活
无歧义表述	避免「适当」、「必要时」等模糊词汇

7.4 可维护性检查

检查项	通过标准
单一职责	一个命令只做一件事，不试图成为「万能命令」
工作流解耦	业务逻辑在工作流中，命令文件只负责路由
模板复用	优先引用 templates/ 和 references/ 中的共享资源
向后兼容	新增 flag 不影响原有调用方式
文档同步	命令行为变更时，description 和 help 文档同步更新

7.5 自动化检查脚本

你可以使用以下命令快速检查命令文件的基本合规性：

# 检查 frontmatter 是否包含必填字段
grep -L "^name:" commands/gsd/*.md
grep -L "^description:" commands/gsd/*.md
grep -L "^allowed-tools:" commands/gsd/*.md

# 检查是否有未闭合的 XML 标签（粗略检查）
for f in commands/gsd/*.md; do
  for tag in runtime_note context objective execution_context process; do
    open=$(grep -c "<$tag>" "$f" || true)
    close=$(grep -c "</$tag>" "$f" || true)
    if [ "$open" != "$close" ]; then
      echo "[$f] $tag: open=$open, close=$close"
    fi
  done
done

# 检查命令名与文件名是否一致
for f in commands/gsd/*.md; do
  basename=$(basename "$f" .md)
  name=$(grep "^name:" "$f" | head -1 | sed 's/name: gsd://')
  if [ "$basename" != "$name" ]; then
    echo "[$f] filename=$basename, name=$name"
  fi
done

---

八、小结

GSD 命令系统的设计模式可以概括为四个关键词：契约、委托、分层、门控。

模式	含义	体现
契约	Markdown 文件即运行时契约	YAML frontmatter + XML Prompt 主体
委托	命令不执行业务逻辑	薄分发层路由到工作流
分层	信息按阶段逐步披露	Progressive Disclosure + Context Budget 管理
门控	多层质量关卡	前置验证、配置开关、权限白名单、后置检查

这些模式共同支撑起 GSD 命令系统的三个核心特性：

1. 可扩展性：新增命令只需遵循模板和规范，无需修改核心框架
2. 可预测性：从命令文件即可预判其行为、权限和产出物
3. 可维护性：命令与工作流解耦，接口稳定、实现可变

正如 GSD 的设计哲学所言："The complexity is in the system, not in your workflow." 命令系统正是这种哲学的最佳体现——用户看到的只是几个简单的 /gsd:* 命令，背后却是一套经过精心设计的上下文工程、权限管理和质量保障机制。

---

下一篇预告：第 13 篇《工作流架构总览》将跳出命令层的视角，深入 GSD 工作流系统的核心设计——从工作流文件的组织结构、Wave 并行执行引擎、Subagent 上下文注入协议，到状态持久化与检查点机制。我们将揭示「命令是触发器，工作流是剧本」这一架构决策的完整工程实现，敬请期待！