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

> **一句话介绍**：GSD 是一个轻量级但强大的元提示、上下文工程和规范驱动开发系统，让 Claude Code、OpenCode、Gemini CLI 和 Codex 能够可靠地完成复杂项目。 --- ## 📋 目录 1. [什么是 GSD？](#什么是-gsd) 2. [为什么需要 GSD？](#为什么需要-gsd) 3. [安装与配置](#安装与配置) 4. [核心概念解析](#核心概念解析) 5. [完整工作流程](#完整工作流程) 6. [命令详解](#命令详解) 7. [实战案例](#实战案例) 8. [最佳实践](#最佳实践) 9. [常见问题](#常见问题) 10. [与其他工具对比](#与其他工具对比) --- ## 什么是 GSD？ **Get Shit Done (GSD)** 是由独立开发者 **TÂCHES**（GitHub: <span class="mention-invalid">@glittercowboy</span>）创建的一套 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** 已安装 ```bash npm install -g @anthropic-ai/claude-code ``` 2. **Node.js**（如未安装，从 [nodejs.org](https://nodejs.org) 下载） ### 安装 GSD **方式一：全局安装（推荐）** ```bash npx get-shit-done-cc ``` 安装时选择： - Runtime: **Claude Code** - Location: **Global**（适用于所有项目） **方式二：本地安装** ```bash npx get-shit-done-cc # 选择 Location: Local（仅当前项目） ``` ### 验证安装 ```bash 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： ```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：初始化项目 ```bash /gsd:new-project ``` 系统会： 1. **提问** — 持续追问直到完全理解你的想法 - 项目的主要目标是什么？ - 目标受众是谁？ - 技术偏好？ - 边界情况？ 2. **研究**（可选但推荐）— 派出并行代理调查相关领域 3. **需求提取** — 区分 v1、v2 和超出范围的内容 4. **路线图** — 创建与需求对应的阶段规划 **产出文件**: `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` > **已有代码库？** 先运行 `/gsd:map-codebase`，系统会分析你的技术栈、架构、约定和潜在问题。 ### 阶段 1：讨论（Discuss） ```bash /gsd:discuss-phase 1 ``` 路线图里每个阶段只有一两句话的描述，这不足以构建你想要的东西。讨论阶段的作用是**捕获你的实现偏好**。 系统会分析当前阶段，识别"灰色地带"——那些有多种合理实现方式的决策点： - 视觉功能 → 布局、交互、空状态处理 - API/CLI → 响应格式、错误处理、详细程度 - 内容系统 → 结构、语气、深度、流程 **产出文件**: `{phase}-CONTEXT.md` ### 阶段 2：计划（Plan） ```bash /gsd:plan-phase 1 ``` 系统会： 1. **研究** — 调查如何实现当前阶段 2. **计划** — 创建 2-3 个原子任务计划 3. **验证** — 检查计划是否满足需求，循环修正直到通过 **重要理念：Goal-Backward Planning（目标回溯规划）** 不是从"我们应该构建什么"出发，而是问"为了实现目标，什么条件必须成立？"——然后反向推导出计划和任务。 **产出文件**: `{phase}-RESEARCH.md`、 `{phase}-{N}-PLAN.md` ### 阶段 3：执行（Execute） ```bash /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） ```bash /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 上午：初始化** ```bash 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. 使用原子提交的优势 ```bash # 如果某个任务引入了 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？ ```bash /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 项目 ```bash # 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 (<span class="mention-invalid">@glittercowboy</span>) - **详细教程**: https://www.humai.blog/a-step-by-step-guide-to-designing-and-shipping-with-claude-code/ --- *本文基于 GSD 官方文档和社区资料整理，旨在帮助中文用户快速上手这一强大的 AI 编程工作流系统。* #GSD #GetShitDone #ClaudeCode #AI编程 #上下文工程 #规范驱动开发 #生产力工具 #教程