规范驱动的 Vibe Coding：GSD 实践指南

用上下文工程解决 AI 代码生成的"上下文腐烂"，让代码生成从随机对话变成可重复的管道。

为什么 Vibe Coding 会失效？

Vibe Coding 的核心问题不是 AI 能力不够，而是上下文腐烂（Context Rot）——随着对话历史累积，AI 的输出质量下降：遗忘早期决策、需求矛盾、偏离原始目标。

GSD 的核心洞察：不要让 AI 在累积的对话历史中工作，而要让它在精心管理的结构化上下文中工作。

GSD 是什么？

GSD（Get Shit Done）是一个元提示框架（meta-prompting framework）和上下文工程系统，位于你和 AI 编码助手之间，管理上下文问题。

• GitHub：https://github.com/gsd-build/get-shit-done（60k+ stars）
• 官网：https://getshitdone.help/
• 核心语言：JavaScript
• 支持工具：Claude Code、Gemini CLI、OpenCode、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code

核心理念

"写结构化规范，然后让 AI 执行规范，而不是即兴发挥"

GSD 不是另一个 AI 编码工具，它是运行在现有 AI 编码工具之上的工程层。

核心问题解决

问题	GSD 的解法
上下文腐烂	每个任务获得全新 200K token 上下文
状态丢失	所有状态存储在 .planning/ 目录的 Markdown 文件中
需求矛盾	先讨论再规划，规范必须批准后才能进入执行
验证缺失	内置质量门禁，验证结果而非信任输出
原子性缺失	每个任务完成后自动生成 Git 提交

GSD vs OpenSpec vs Spec-Kit vs BMad vs Kiro

维度	GSD	OpenSpec	Spec-Kit	BMad	Kiro
stars	60k+	48k+	100k+	43k+	3.6k+
核心解决	上下文腐烂	Brownfield 变更	规范模板	多 Agent 协作	EARS notation
工作流	5 阶段管道	propose → apply	6 阶段	PM→架构师→Dev	Spec → Tasks → Implement
执行模式	波浪式并行 + 自动提交	单线程	单线程	多 Agent	单 Agent
质量门禁	4 层（静态→命令→行为→人工）	有限	有限	无	有限
上下文管理	锚点修剪 + 任务隔离	文件按需加载	文件模板	文档继承	Steering 文件

核心概念

1. 项目结构层次

项目（Project）
  └── 里程碑（Milestone）
        └── 阶段（Phase）
              └── 计划（Plan）
                    └── 任务（Task）

2. 五阶段管道

讨论（Discuss）→ 规划（Plan）→ 研究（Research）→ 执行（Execute）→ 验证（Verify）

每个阶段产出文件，驱动下一个阶段。

3. 文件系统状态

所有状态存储在 .planning/ 目录的 Markdown 和 JSON 文件中：

.planning/
├── PROJECT.md          # 项目概述
├── ROADMAP.md          # 里程碑路线图
├── STATE.md            # 派生的会话状态
├── REQUIREMENTS.md     # 需求（必须 FINALIZED 才能进入执行）
├── CONTEXT.md          # 决策和约束
├── RESEARCH.md         # 研究结果
├── PLAN.md             # 原子任务计划
├── {N}-{M}-SUMMARY.md  # 任务执行摘要
└── {N}-VERIFICATION.md # 验证报告

无数据库、无服务器、无外部依赖——所有状态都在文件中，可审查、可版本控制。

4. Thin Orchestrator（薄协调器）

GSD 使用薄协调器模式：

• 协调器（workflow）不做重活
• 加载上下文 → 生成专用 Agent → 收集结果 → 路由下一步
• 每个 Agent 在自己的隔离上下文中运行（200K token）

主线程（轻量）
    ↓ 加载上下文，生成专用 Agent
Agent 1（研究员）→ 写 RESEARCH.md
Agent 2（规划师）→ 写 PLAN.md
Agent 3（执行者）→ 执行任务，提交代码
Agent 4（验证者）→ 验证结果
    ↓
主线程收集结果，更新状态

5. Wave-Based Execution（波浪式执行）

Plan 被分组为依赖感知的波浪：

• 独立 Plan：在同一波浪中并行执行
• 依赖 Plan：等待前置波浪完成后执行
• 每个执行者：获得全新的 200K token 上下文
• 每个任务完成：自动生成原子 Git 提交

波浪 1（并行）
  Task 1 ──→ 提交
  Task 2 ──→ 提交
  Task 3 ──→ 提交

波浪 2（等待波浪 1）
  Task 4（依赖 Task 2）──→ 提交

波浪 3（等待波浪 2）
  Task 5（依赖 Task 4）──→ 提交

6. 质量门禁（Quality Gates）

GSD 实现 4 层防御：

门禁类型	触发时机	检查内容
Pre-flight	规划前	研究问题未解决则阻塞规划
Revision	计划生成后	验证计划是否达标（最多 3 轮迭代）
Escalation	任意阶段	安全问题、范围缩减检测
Abort	验证失败	停止并报告

7. 目标反向验证（Goal-Backward Verification）

GSD 验证结果，不验证步骤：

• Truth 验证：可观察的行为
• Artifact 验证：文件有真实实现和最小行数
• Key Link 验证：import 连线正确
• Stub 检测：扫描 TODO、return null、硬编码空响应

工作流命令

命令	用途
/gsd new-project	创建项目，深度提问 → 生成 REQUIREMENTS.md
/gsd discuss-phase N	澄清阶段 N 的实施细节
/gsd plan-phase N	为阶段 N 创建任务分解
/gsd execute-phase N	在波浪中并行执行计划
/gsd verify-work N	验证阶段 N 达成目标
/gsd auto N	自动执行里程碑 N
/gsd complete-milestone	归档、标记发布、初始化下一周期

安装与初始化

# 安装
npm install -g get-shit-done

# 或通过 Claude Code
claude /install https://github.com/gsd-build/get-shit-done

初始化后运行：

/gsd new-project

GSD 会问一系列结构化问题来理解你的想法，然后生成项目文件。

完整示例：构建一个 API 服务

Step 1: 创建项目

/gsd new-project

GSD 提问：

• 你在构建什么？
• 给谁用？
• 技术约束是什么？
• 成功的定义是什么？

回答后生成：

• PROJECT.md：项目概述
• REQUIREMENTS.md：需求清单（每个需求有状态和验证标准）
• ROADMAP.md：里程碑路线图

Step 2: 讨论阶段

/gsd discuss-phase 1

GSD 澄清第一个里程碑的实施细节：

• 检查代码库
• 研究相关库文档
• 搜索网络资料
• 生成 CONTEXT.md

Step 3: 规划阶段

/gsd plan-phase 1

1. 研究 Agent 并行调查：

   • 技术栈研究
   • 架构模式研究
   • 风险分析

2. 规划 Agent 生成 XML 任务计划

3. 计划检查 Agent 验证计划

Step 4: 执行阶段

/gsd execute-phase 1

GSD 按波浪执行任务：

波浪 1（并行）
  Task 1: 初始化项目 → 提交
  Task 2: 创建数据库模型 → 提交

波浪 2（等待波浪 1）
  Task 3: 实现用户认证 → 提交

波浪 3（等待波浪 2）
  Task 4: 实现 API 端点 → 提交

每个任务：

• 获得全新 200K token 上下文
• 执行后自动 Git 提交
• 写 SUMMARY.md

Step 5: 验证阶段

/gsd verify-work 1

GSD 运行验证：

• 自动化检查
• 用户验收测试（UAT）指导
• 生成验证报告

GSD 的关键设计

1. 规范必须批准后才能执行

讨论 → 规范（必须 FINALIZED）→ 规划 → 执行

GSD 机械性地阻止在规范批准前写任何代码。

2. 主线程永远不累积重量

主线程（轻量协调）→ 生成 Agent → Agent 在隔离上下文中工作 → 只保留输出文件

上下文腐烂的根源是主线程累积了实现工作的重量。GSD 的设计中，主线程只做协调，实现工作都在子 Agent 中。

3. 状态派生而非状态存储

STATE.md 是派生的缓存，不是事实来源。GSD 从文件系统中派生所有状态：

文件存在？ → 阶段是什么？ → 执行什么规则？

4. 工具调用替代机械操作

GSD 提供两个工具暴露整个确定性层：

工具	操作数	用途
gsd_manage	18	状态、Git、脚手架、上下文
gsd_verify	4	静态验证

AI 永远不构造 git 命令，永远不解析 Markdown 找任务——它调用工具。

何时用 GSD？

场景	推荐度
复杂代码库，长期 AI 编码会话	⭐⭐⭐⭐⭐
需要解决上下文腐烂问题	⭐⭐⭐⭐⭐
多任务并行执行	⭐⭐⭐⭐⭐
需要原子性 Git 提交	⭐⭐⭐⭐⭐
快速原型验证	⭐⭐
团队多角色协作	⭐⭐（用 BMad）
极简流程，Brownfield 增量	⭐⭐（用 OpenSpec）

参考资源

• 官网：https://getshitdone.help/
• GitHub：https://github.com/gsd-build/get-shit-done
• 文档：https://getshitdone.help/user-guide/developing-with-gsd/
• RFC 2119：关键词含义