🚀 Get Shit Done (GSD) 完全使用指南：让 Claude Code 从玩具变成生产力引擎

> 一句话介绍：GSD 是一个轻量级但强大的元提示、上下文工程和规范驱动开发系统，让 Claude Code、OpenCode、Gemini CLI 和 Codex 能够可靠地完成复杂项目。

---

📋 目录

1. 什么是 GSD？ 2. 为什么需要 GSD？ 3. 安装与配置 4. 核心概念解析 5. 完整工作流程 6. 命令详解 7. 实战案例 8. 最佳实践 9. 常见问题 10. 与其他工具对比

---

什么是 GSD？

Get Shit Done (GSD) 是由独立开发者 TÂCHES（GitHub: @glittercowboy）创建的一套 AI 编程工作流系统。

它的核心理念很简单：把"规划"和"执行"分开，用文件作为真相来源，防止上下文腐烂（Context Rot）。

GSD 的三大支柱

支柱	说明
Meta-Prompting（元提示）	系统会主动追问你的需求，而不是盲目开始编码
Context Engineering（上下文工程）	将项目状态外化为文件，每个任务在新鲜上下文中执行
Spec-Driven Development（规范驱动开发）	先写规范再写代码，避免返工

谁适合使用 GSD？

• ✅ 想用 Claude Code 做真正项目的开发者
• ✅ 厌倦了"氛围编程"（Vibe Coding）导致代码质量下降的设计师
• ✅ 需要管理复杂多阶段项目的独立开发者
• ✅ 希望 AI 编程助手更可靠、更可控的团队

> 不适合：只想快速原型、不在乎代码质量、或者希望完全自动化的用户。GSD 需要你在关键节点参与决策。

---

为什么需要 GSD？

问题：Context Rot（上下文腐烂）

当你和 Claude Code 长时间对话时，会发生以下情况：

1. 上下文窗口被失败代码、过时讨论和无关信息填满 2. AI 的输出质量不断下降 3. 你开始玩"俄罗斯轮盘赌"——赌什么时候撞到上下文窗口的墙 4. 最后不得不重启会话，丢失所有上下文

GSD 的解决方案

传统方式：
你 → Claude → 长时间对话 → 质量下降 → 崩溃 → 重启 → 重复

GSD 方式：
你 → GSD 编排器 → 子代理 1（研究）
                    → 子代理 2（规划）
                    → 子代理 3（执行）→ 新鲜上下文
                    → 子代理 4（验证）
         → 每个子代理都有 200k tokens 的干净上下文

真实效果

• 主上下文窗口保持在 24-40%，即使执行完整阶段
• 每个原子任务都有全新 200k tokens 上下文，零累积垃圾
• 可连续执行 10 个计划，上下文仍低于 50%

---

安装与配置

前置要求

1. Claude Code 已安装

   npm install -g @anthropic-ai/claude-code
   

2. Node.js（如未安装，从 nodejs.org 下载）

安装 GSD

方式一：全局安装（推荐）

npx get-shit-done-cc

安装时选择：

• Runtime: Claude Code
• Location: Global（适用于所有项目）

方式二：本地安装

npx get-shit-done-cc
# 选择 Location: Local（仅当前项目）

验证安装

claude --dangerously-skip-permissions

在 Claude Code 中输入：

/gsd:help

如果看到完整的 GSD 命令列表，说明安装成功。

> 为什么使用 --dangerously-skip-permissions？ > > GSD 会自动执行 git 提交、文件操作和日期戳记录。手动批准每个操作会拖慢工作流。这个标志让 Claude 能够自主工作，这是使用 GSD 进行严肃项目的正确方式。

---

核心概念解析

1. 文件结构

GSD 会在你的项目中创建以下文件结构：

项目根目录/
├── .planning/                    # 规划文件目录
│   ├── PROJECT.md               # 项目愿景（始终加载）
│   ├── REQUIREMENTS.md          # 分版本的需求
│   ├── ROADMAP.md               # 阶段路线图
│   ├── STATE.md                 # 当前状态和决策
│   └── research/                # 研究资料
│       ├── stack.md
│       ├── features.md
│       ├── architecture.md
│       └── pitfalls.md
│
├── {phase}-CONTEXT.md           # 阶段设计决策
├── {phase}-RESEARCH.md          # 阶段研究资料
├── {phase}-{N}-PLAN.md          # 原子任务计划
├── {phase}-{N}-SUMMARY.md       # 执行摘要
├── {phase}-VERIFICATION.md      # 验证报告
└── {phase}-UAT.md              # 用户验收测试

2. Context Engineering（上下文工程）

每个文件都有基于 Claude 质量退化阈值的大小限制：

文件	大小限制	作用
PROJECT.md	保持精简	项目愿景，始终加载
REQUIREMENTS.md	中等	分版本需求，带阶段追溯
ROADMAP.md	中等	方向和进度
STATE.md	动态更新	决策、阻碍、位置——跨会话记忆
PLAN.md	原子级别	小任务 + XML 结构 + 验证步骤

保持在限制之下，就能获得一致的高质量输出。

3. Multi-Agent Orchestration（多智能体编排）

┌─────────────────────────────────────────┐
│           GSD 编排器（薄层）              │
│         （协调，不执行重活）              │
└─────────────────────────────────────────┘
                    │
    ┌───────────────┼───────────────┐
    ▼               ▼               ▼
┌─────────┐    ┌─────────┐    ┌─────────┐
│ 研究代理 │    │ 规划代理 │    │ 执行代理 │
│(并行×4) │    │(创建+检查)│   │(波次执行)│
└─────────┘    └─────────┘    └─────────┘
    │               │               │
    └───────────────┼───────────────┘
                    ▼
            ┌─────────────┐
            │   验证代理   │
            │ (确认交付物) │
            └─────────────┘

4. XML Prompt Format

每个计划都是为 Claude 优化的结构化 XML：

<plan id="02-01">
  <name>Hero Section Layout</name>
  
  <task type="auto">
    <n>Create hero section HTML structure</n>
    <files>index.html</files>
    <action>
      Add hero section with semantic HTML.
      Include h1 for name, p for tagline.
      Wrap in section with id="hero".
    </action>
    <verify>Hero section exists in DOM with correct elements</verify>
    <done>Hero section renders with name and tagline</done>
  </task>
  
  <task type="auto">
    <n>Style hero section</n>
    <files>styles.css</files>
    <action>
      Background: #0A0A0A solid
      Name: 48px font-size
      Tagline: 18px font-size
      Center content vertically using flexbox
      Full viewport height (100vh)
    </action>
    <verify>Hero fills viewport, text is centered, colors match spec</verify>
    <done>Hero section matches Phase 2 CONTEXT.md specifications</done>
  </task>
</plan>

---

完整工作流程

GSD 的工作流是一个 讨论 → 计划 → 执行 → 验证 的循环。

阶段 0：初始化项目

/gsd:new-project

系统会：

1. 提问 — 持续追问直到完全理解你的想法

• 项目的主要目标是什么？
• 目标受众是谁？
• 技术偏好？
• 边界情况？

2. 研究（可选但推荐）— 派出并行代理调查相关领域

3. 需求提取 — 区分 v1、v2 和超出范围的内容

4. 路线图 — 创建与需求对应的阶段规划

产出文件: PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md

> 已有代码库？ 先运行 /gsd:map-codebase，系统会分析你的技术栈、架构、约定和潜在问题。

阶段 1：讨论（Discuss）

/gsd:discuss-phase 1

路线图里每个阶段只有一两句话的描述，这不足以构建你想要的东西。讨论阶段的作用是捕获你的实现偏好。

系统会分析当前阶段，识别"灰色地带"——那些有多种合理实现方式的决策点：

• 视觉功能 → 布局、交互、空状态处理
• API/CLI → 响应格式、错误处理、详细程度
• 内容系统 → 结构、语气、深度、流程

产出文件: {phase}-CONTEXT.md

阶段 2：计划（Plan）

/gsd:plan-phase 1

系统会：

1. 研究 — 调查如何实现当前阶段 2. 计划 — 创建 2-3 个原子任务计划 3. 验证 — 检查计划是否满足需求，循环修正直到通过

重要理念：Goal-Backward Planning（目标回溯规划）

不是从"我们应该构建什么"出发，而是问"为了实现目标，什么条件必须成立？"——然后反向推导出计划和任务。

产出文件: {phase}-RESEARCH.md、 {phase}-{N}-PLAN.md

阶段 3：执行（Execute）

/gsd:execute-phase 1

系统会：

1. 波次执行 — 独立任务并行执行，有依赖的按顺序 2. 新鲜上下文 — 每个计划在全新的 200k tokens 上下文中执行 3. 原子提交 — 每个任务独立 git commit 4. 目标验证 — 检查代码库是否实现了阶段承诺的功能

Git 提交示例：

abc123f feat(02-01): create hero section HTML structure
def456g feat(02-01): style hero with centered layout and colors
hij789k feat(02-02): build project grid with 48px gaps
lmn012o feat(02-02): add hover effects and image placeholders

产出文件: {phase}-{N}-SUMMARY.md、 {phase}-VERIFICATION.md

阶段 4：验证（Verify）

/gsd:verify-work 1

自动化验证能检查代码是否存在、测试是否通过。但功能是否按你的预期工作？这需要你来确认。

系统会：

1. 提取可测试的交付物 — 列出你现在应该能做到的事情 2. 逐一引导验证 — "能用邮箱登录吗？" 是/否，或描述问题 3. 自动诊断失败 — 派出调试代理查找根因 4. 创建修复计划 — 可直接执行的修复方案

产出文件: {phase}-UAT.md

循环重复

/gsd:discuss-phase 2 → /gsd:plan-phase 2 → /gsd:execute-phase 2 → /gsd:verify-work 2
...
/gsd:complete-milestone → /gsd:new-milestone

---

命令详解

项目管理

命令	作用
/gsd:new-project	初始化新项目，创建 PROJECT.md、REQUIREMENTS.md、ROADMAP.md
/gsd:map-codebase	分析已有代码库的技术栈和架构
/gsd:complete-milestone	归档里程碑并标记版本
/gsd:new-milestone	开启下一个版本的构建
/gsd:update	检查更新、安装并显示变更日志

阶段工作流

命令	作用
/gsd:discuss-phase N	讨论第 N 阶段的实现偏好
/gsd:plan-phase N	为第 N 阶段创建计划
/gsd:execute-phase N	执行第 N 阶段的计划
/gsd:verify-work N	验证第 N 阶段的交付物

快捷命令

命令	作用
/gsd:quick	快速模式，跳过研究和验证，用于小任务
/gsd:help	显示所有可用命令
/gsd:debug	启动隔离的调试子代理

---

实战案例

案例 1：个人作品集网站

Day 1 上午：初始化

mkdir my-portfolio
cd my-portfolio
claude --dangerously-skip-permissions

/gsd:new-project
> "Build me a portfolio site with dark mode, project grid, and contact form"

GSD 提问：

• 主要目标？展示作品还是获取客户？
• 目标受众？
• 品牌偏好？
• 空状态处理？
• 移动端要求？

Day 1 下午：讨论和计划

/gsd:discuss-phase 1
> "Hero: centered, dark background #0A0A0A, name 48px, tagline 18px"
> "Project grid: 48px gaps, lift on hover, 16:9 images"

/gsd:plan-phase 1

Day 2：执行和验证

/gsd:execute-phase 1
/gsd:verify-work 1

结果：一个符合你设计愿景的作品集，代码质量高，git 历史清晰。

案例 2：带 AI 聊天的 Web 应用

需求：

• Google OAuth 认证
• AI 聊天界面（Claude API）
• 评论系统

工作流程：

/gsd:new-project
> "Build a web app with Google OAuth, AI chat, and comments"

/gsd:discuss-phase 1  # 认证
/gsd:plan-phase 1
/gsd:execute-phase 1

/gsd:discuss-phase 2  # AI 聊天
/gsd:plan-phase 2
/gsd:execute-phase 2

/gsd:discuss-phase 3  # 评论系统
/gsd:plan-phase 3
/gsd:execute-phase 3

/gsd:verify-work 3

---

最佳实践

1. 准备粗略的愿景文档

在启动 /gsd:new-project 之前，先准备一份粗略的描述：

我想做一个 [什么]
目标是 [解决什么问题]
目标用户是 [谁]
关键功能是 [A, B, C]
不需要的功能是 [X, Y, Z]

描述越详细，系统追问得越少。

2. 积极参与讨论阶段

不要跳过 /gsd:discuss-phase。这是捕获你设计偏好的关键步骤。

不好的回答： > "随便，你决定"

好的回答： > "Hero 要居中，背景用纯黑 #0A0A0A，名字 48px 比副标题 18px 大很多，垂直居中"

3. 验证时诚实反馈

在 /gsd:verify-work 阶段，如果发现问题，要详细描述：

不好的反馈： > "有点问题"

好的反馈： > "问题：Placeholder 文字被截断了。期望：显示完整文字。实际：只显示一半"

4. 使用原子提交的优势

# 如果某个任务引入了 bug
git bisect start
git bisect bad HEAD
git bisect good abc123f  # 上一个已知好的提交
# git 会自动二分查找引入 bug 的确切提交

5. 保持主上下文干净

不要在一个会话中执行太多阶段。每个阶段完成后，可以考虑：

• 提交并推送代码
• 关闭 Claude Code
• 重新启动新会话执行下一阶段

---

常见问题

Q: GSD 是免费的吗？

A: GSD 本身是免费开源的。但你仍然需要支付 Claude Code 的 API 费用。TÂCHES 每月消耗约 $30,000 的 Opus tokens，但因为每个任务都在新鲜上下文中执行，返工极少，实际效率远高于在一个退化的上下文中反复修修补补。

Q: GSD 能完全自动化吗？

A: 不能。GSD 是人类引导的工作流，不是自主代理。每个阶段边界都需要你手动输入命令。这和 Ralph Wiggum 的 AFK 模式形成对比——Ralph 是设计来"启动后去睡觉"的，GSD 则要求你在每个关键节点都在场。

Q: 如果我没有编程背景，能用 GSD 吗？

A: 可以，但有编程背景会更有优势。GSD 让你用设计思维描述需求，但理解代码结构能帮助你给出更精确的反馈。

Q: GSD 和 Ralph Wiggum 循环有什么区别？

维度	Ralph Wiggum	GSD
核心定位	执行技术（bash loop）	上下文工程 + 规格驱动
规划能力	无（需自备 spec）	强（研究→讨论→规划）
执行自主性	最高（AFK 模式）	需手动触发每步
Context Rot 处理	新 session 重启	子代理新鲜上下文
质量验证	依赖外部测试	自动验证 + UAT
人类参与	Human on the Loop	Human in the Loop

Q: 如何更新 GSD？

/gsd:update

---

与其他工具对比

GSD vs 直接使用 Claude Code

方面	直接使用	GSD
上下文管理	逐渐腐烂	始终保持新鲜
代码质量	随时间下降	保持一致
需求理解	假设共享上下文	显式捕获决策
可追溯性	混乱	每个决策都有记录
返工率	高	低

GSD vs BMAD / SpecKit

方面	BMAD / SpecKit	GSD
流程复杂度	高（企业敏捷流程）	低（几个简单命令）
上下文工程	无内置方案	核心特性
目标用户	企业团队	独立开发者、小团队
上手难度	较高	低

---

总结

GSD 代表了 AI 编程工具演进的一个重要方向：从"让 AI 写代码"到"让 AI 可靠地交付项目"。

它继承了 Ralph Wiggum 的核心洞察——新鲜上下文比累积上下文更有价值——但在此基础上加入了项目理解、决策捕获、结构化规划、并行执行和质量验证，形成了一个完整的闭环。

关键要点

1. Context Engineering 是核心 —— 文件作为真相来源，每个任务在新鲜上下文中执行 2. Human in the Loop —— 不是完全自动化，而是在关键节点让你参与决策 3. Spec-Driven —— 先规划再执行，避免返工 4. Atomic Commits —— 每个任务独立提交，可追溯、可回滚

开始你的第一个 GSD 项目

# 1. 安装
npx get-shit-done-cc

# 2. 启动 Claude Code
claude --dangerously-skip-permissions

# 3. 初始化项目
/gsd:new-project

# 4. 跟随提示，开始你的 AI 驱动开发之旅

---

参考资源

• GitHub: https://github.com/gsd-build/get-shit-done
• NPM: https://www.npmjs.com/package/get-shit-done-cc
• 创建者: TÂCHES (@glittercowboy)
• 详细教程: https://www.humai.blog/a-step-by-step-guide-to-designing-and-shipping-with-claude-code/

---

*本文基于 GSD 官方文档和社区资料整理，旨在帮助中文用户快速上手这一强大的 AI 编程工作流系统。*

#GSD #GetShitDone #ClaudeCode #AI编程 #上下文工程 #规范驱动开发 #生产力工具 #教程