GSD 深度解析：如何用 Context Engineering 战胜 Claude Code 的上下文腐化

## 一、引言：当 Claude 开始"失忆" 如果你用过 Claude Code 做过复杂项目，一定经历过这样的场景： **会话开始时：** - Claude 思路清晰，代码质量高 - 记得你所有的需求和约束 - 每个建议都深思熟虑 **会话进行到一半：** - Claude 开始说"我会更简洁一些" - 代码变得草率，省略了错误处理 - 忘记了之前讨论过的关键约束 **会话快结束时：** - 出现幻觉，引用不存在的文件 - 忘记了项目的核心目标 - 建议的方案与整体架构冲突 这不是你的错觉，也不是 Claude 变笨了。这是 **Context Rot（上下文腐化）**——随着对话变长，上下文窗口被失败代码、过时讨论和无关信息填满，输出质量持续下降。 **GSD（Get Shit Done）** 就是为了解决这个问题而生的。 --- ## 二、什么是 GSD？ GSD 是一个专为 Claude Code、OpenCode、Gemini CLI 设计的**元提示、上下文工程和规格驱动开发系统**。 创建者 **TÂCHES**（GitHub: glittercowboy）是一位独立开发者。他的理念很简单： > "我不是 50 人的软件公司。我不想玩企业戏剧。我只是一个想做出好东西的创意人。" 在他的直播中，TÂCHES 展示了一个令人震撼的事实：他**从不手写代码**。他用 GSD 在 4 小时内从零构建了一个完整的 macOS 原生音乐生成应用，全程零手写代码。 **GSD 的核心理念：** - 把复杂性藏在系统里 - 用户只需要几个简单命令 - 系统在背后处理所有上下文管理、任务编排和质量验证 项目发布两个月内获得 **2.1 万 GitHub stars**，几乎每天更新 15-20 次。 --- ## 三、Context Rot：问题的本质 ### 上下文腐化的三个阶段 | 阶段 | 上下文占用 | 表现 | |------|-----------|------| | **黄金期** | 0-30% | 峰值质量，全面思考，记住一切 | | **衰退期** | 50%+ | 开始赶工，"我会更简洁"，省略细节 | | **混乱期** | 70%+ | 幻觉，遗忘需求，偏离目标 | ### 为什么会发生？ Claude Code 的上下文窗口虽然大（200k tokens），但质量分布并不均匀： ``` 上下文窗口质量分布： ┌─────────────────────────────────────────────────────┐ │ 开头 30% ████████████████████ 最佳质量 │ │ 中间 40% ██████████████ 中等质量 │ │ 末尾 30% ████████ 质量下降 │ └─────────────────────────────────────────────────────┘ ``` **关键洞察：** 无论上下文窗口多大，前半段的 token 总是比后半段更有效。这不是 bug，这是 LLM 的固有特性。 ### 传统解决方案的局限 | 方案 | 问题 | |------|------| | 手动清理上下文 | 容易误删重要信息 | | 重启新会话 | 丢失所有上下文，需要重新解释 | | 依赖 autocompact | 只能部分缓解，无法根治 | --- ## 四、GSD 的解决方案：Context Engineering ### 核心原则：新鲜上下文 > 累积上下文 GSD 不使用一个长会话，而是**为每个任务生成全新的子代理**： ``` 传统方式（Context Rot）： ┌─────────────────────────────────────────────────────┐ │ 主会话 │ │ [任务1] → [任务2] → [任务3] → ... → [任务50] │ │ 质量: ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │ └─────────────────────────────────────────────────────┘ GSD 方式（Fresh Context）： ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 子代理1 │ │ 子代理2 │ │ 子代理3 │ ... │ 子代理50│ │ 任务1 │ │ 任务2 │ │ 任务3 │ │ 任务50 │ │ ████████│ │ ████████│ │ ████████│ │ ████████│ │ 200k全新│ │ 200k全新│ │ 200k全新│ │ 200k全新│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ↓ ↓ ↓ 主会话（30-40% 上下文） 只负责编排，不做重活 ``` **结果：** 任务 50 的质量与任务 1 完全相同，零退化。 ### 主会话保持轻量 TÂCHES 的实测数据： - 完成 3 个完整阶段的开发 - **主上下文窗口始终保持在 24%** - 每个子代理只需加载不到 1,000 行上下文 - 连续执行 10 个计划，上下文仍低于 50% 这和直接在 Claude Code 中工作完全不同：不再是"玩俄罗斯轮盘赌，赌什么时候撞到上下文窗口的墙"。 --- ## 五、六阶段工作流：从想法到交付 GSD 将复杂项目拆解为六个明确的阶段： ### 阶段 1：初始化项目（/gsd:new-project） ``` 启动流程： 1. 提问 — 持续追问直到完全理解你的想法 2. 研究 — 派出并行代理调查相关领域 3. 需求提取 — 区分 v1、v2 和超出范围的内容 4. 路线图 — 创建与需求对应的阶段规划 ``` **产出文件：** - `PROJECT.md` — 项目愿景 - `REQUIREMENTS.md` — 分版本需求 - `ROADMAP.md` — 阶段规划 - `STATE.md` — 跨会话记忆 ### 阶段 2：讨论（/gsd:discuss-phase N） 捕获你的实现偏好，识别"灰色地带"： - 视觉功能 → 布局、交互、空状态 - API/CLI → 响应格式、错误处理 - 内容系统 → 结构、语气、深度 **产出文件：** `{phase}-CONTEXT.md` ### 阶段 3：计划（/gsd:plan-phase N） ``` 计划流程： 1. 研究 — 调查如何实现当前阶段 2. 计划 — 创建 2-3 个原子任务（XML 格式） 3. 验证 — 检查计划是否满足需求，循环修正 ``` **关键设计理念：Goal-Backward Planning（目标回溯规划）** 不是问"我们应该构建什么"，而是问"为了实现目标，什么条件必须成立？"然后反向推导出任务。 **产出文件：** - `{phase}-RESEARCH.md` - `{phase}-{N}-PLAN.md` ### 阶段 4：执行（/gsd:execute-phase N） ``` 执行流程： 1. 波次执行 — 独立任务并行，有依赖的按顺序 2. 新鲜上下文 — 每个计划全新 200k tokens 3. 原子提交 — 每个任务独立 git commit 4. 目标验证 — 检查是否实现阶段承诺 ``` **波次并行示例：** ``` 波次 1: [任务A] [任务B] [任务C] ← 同时执行 波次 2: [任务D] [任务E] ← 等待波次1完成 波次 3: [任务F] ← 等待波次2完成 ``` **产出文件：** - `{phase}-{N}-SUMMARY.md` - `{phase}-VERIFICATION.md` ### 阶段 5：验证（/gsd:verify-work N） 自动化验证能检查代码是否存在、测试是否通过。但功能是否**按你的预期工作**？这需要你来确认。 ``` 验证流程： 1. 提取可测试的交付物 2. 逐一引导验证（"能用邮箱登录吗？"） 3. 自动诊断失败（派出调试代理） 4. 创建修复计划 ``` **Goal-Backward Verification：** 不问"我们做了什么任务"，而是问"什么必须为真才能让这工作？" **产出文件：** `{phase}-UAT.md` ### 阶段 6：里程碑管理 ``` /gsd:complete-milestone → 归档当前里程碑 /gsd:new-milestone → 开启下一个版本 ``` --- ## 六、四大技术支柱 ### 1. Context Engineering（上下文工程） | 文件 | 作用 | 大小限制 | |------|------|---------| | `PROJECT.md` | 项目愿景，始终加载 | < 500 tokens | | `research/` | 生态知识 | 按需加载 | | `REQUIREMENTS.md` | 分版本需求 | < 2000 tokens | | `ROADMAP.md` | 方向和进度 | < 1000 tokens | | `STATE.md` | 决策、阻碍、位置 | < 500 tokens | | `PLAN.md` | 原子任务 + XML 结构 | < 3000 tokens | | `SUMMARY.md` | 执行记录 | 归档历史 | 每个文件都有基于 Claude 质量退化阈值的大小限制。保持在限制之下，就能获得一致的高质量输出。 ### 2. XML Prompt Formatting 每个计划都是为 Claude 优化的结构化 XML： ```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. Return httpOnly cookie on success. </action> <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify> <done>Valid credentials return cookie, invalid return 401</done> </task> ``` 精确的指令，不需要猜测，验证内置在每个任务中。 ### 3. Multi-Agent Orchestration（多代理编排） | 阶段 | 编排器 | 代理 | |------|--------|------| | 研究 | 协调、展示发现 | 4 个并行研究员 | | 规划 | 验证、管理迭代 | 规划者 + 检查者 | | 执行 | 分组波次、跟踪进度 | 执行者（并行）| | 验证 | 展示结果、路由下一步 | 验证者 + 调试者 | 编排器从不做重活。它派出代理、等待、整合结果。 ### 4. Atomic Git Commits（原子提交） 每个任务完成后立即独立提交： ``` abc123f docs(08-02): complete user registration plan def456g feat(08-02): add email confirmation flow hij789k feat(08-02): implement password hashing lmn012o feat(08-02): create registration endpoint ``` **好处：** - `git bisect` 能定位到具体的失败任务 - 每个任务可独立回滚 - 清晰的历史帮助 Claude 理解代码演变 --- ## 七、GSD vs 其他方案 | 维度 | Ralph Wiggum | SpecKit | BMAD | **GSD** | |------|-------------|---------|------|---------| | 核心定位 | 执行技术 | 规格生成 | 企业级框架 | **上下文工程 + 规格驱动** | | 规划能力 | 无 | 强 | 强 | **强** | | 执行自主性 | 最高（AFK）| 手动触发 | 手动触发 | **手动触发** | | Context Rot 处理 | 新 session 重启 | 无 | 无 | **子代理新鲜上下文** | | 质量验证 | 依赖外部 | 构建检查 | 内置 QA | **自动验证 + UAT** | | 用户复杂度 | 最低 | 中等 | 较高 | **低** | | 系统复杂度 | 最低 | 中等 | 较高 | **高** | **关键差异：** - **Ralph Wiggum**：牺牲规划能力换取执行自主性，启动后可以去睡觉 - **GSD**：牺牲执行自主性换取规划质量和人类校验，每个阶段都需要你介入 **Chase AI 的总结：** > "Ralph 循环假设你带着完整蓝图来——GSD 帮你构建这个蓝图。" --- ## 八、什么时候用 GSD？ ### ✅ 适合使用 GSD - 复杂项目（多个组件、真实业务逻辑） - 需要多会话完成的工作 - 你关心干净的 git 历史 - 需要可追溯的需求和验证 ### ❌ 不适合使用 GSD - 快速一次性任务（直接用 Claude） - 原型验证（基础 vibecoding 就够了） - 简单脚本或配置修改 ### 快速模式 对于小改动，使用 `/gsd:quick`： - 同样保证新鲜代理上下文 - 跳过繁重的规划流程 - 适合微调和小修复 --- ## 九、实际效果 ### TÂCHES 的数据 - 使用 $200/月的 Max 计划 - 每月消耗约 $30,000 的 Opus tokens - 听起来很多，但因为每个任务都在新鲜上下文中执行，返工极少 - 实际效率远高于在一个退化的上下文中反复修修补补 ### 对比体验 | 场景 | 传统 Claude Code | GSD | |------|-----------------|-----| | 长会话质量 | 逐渐下降 | 始终一致 | | 主上下文占用 | 70%+ | 24-40% | | 返工率 | 高 | 低 | | 可追溯性 | 差 | 完整 | | git 历史 | 混乱 | 原子化 | --- ## 十、结语：AI 编程的新范式 GSD 代表了 AI 编程工具演进的一个重要方向： **从"让 AI 写代码"到"让 AI 可靠地交付项目"** 它解决了一个根本性问题：**如何在长项目中保持 AI 的高质量输出？** 答案不是更大的上下文窗口，而是**更聪明的上下文管理**——把大任务拆成小任务，让每个任务都在最佳质量的上下文中完成。 **核心启示：** 1. **新鲜上下文 > 累积上下文** — 不要为了"记得更多"而牺牲质量 2. **编排 > 控制** — 让子代理做重活，主会话保持轻量 3. **验证 > 假设** — 每个阶段都要有明确的验证标准 4. **原子性 > 批量** — 小任务、独立提交、可追溯 正如 TÂCHES 所说： > "This has like 100x'd my ability to make cool shit with Claude Code because it's just created this systematization." **（这让我的能力提升了 100 倍，因为它创造了一种系统化。）** --- ## 参考 - GitHub: [gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done) - 创建者: TÂCHES (glittercowboy) - 安装: `npx get-shit-done-cc` --- *你遇到过 Context Rot 问题吗？尝试过 GSD 或其他解决方案吗？欢迎在评论区分享你的经验。*