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：问题的本质

上下文腐化的三个阶段

为什么会发生？

Claude Code 的上下文窗口虽然大（200k tokens），但质量分布并不均匀：

上下文窗口质量分布：
┌─────────────────────────────────────────────────────┐
│ 开头 30%  ████████████████████  最佳质量            │
│ 中间 40%  ██████████████        中等质量            │
│ 末尾 30%  ████████              质量下降            │
└─────────────────────────────────────────────────────┘

关键洞察： 无论上下文窗口多大，前半段的 token 总是比后半段更有效。这不是 bug，这是 LLM 的固有特性。

传统解决方案的局限

四、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（上下文工程）

每个文件都有基于 Claude 质量退化阈值的大小限制。保持在限制之下，就能获得一致的高质量输出。

2. XML Prompt Formatting

每个计划都是为 Claude 优化的结构化 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. 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：牺牲规划能力换取执行自主性，启动后可以去睡觉
• GSD：牺牲执行自主性换取规划质量和人类校验，每个阶段都需要你介入

Chase AI 的总结：

"Ralph 循环假设你带着完整蓝图来——GSD 帮你构建这个蓝图。"

八、什么时候用 GSD？

✅ 适合使用 GSD

• 复杂项目（多个组件、真实业务逻辑）
• 需要多会话完成的工作
• 你关心干净的 git 历史
• 需要可追溯的需求和验证

❌ 不适合使用 GSD

• 快速一次性任务（直接用 Claude）
• 原型验证（基础 vibecoding 就够了）
• 简单脚本或配置修改

快速模式

对于小改动，使用 /gsd:quick：

• 同样保证新鲜代理上下文
• 跳过繁重的规划流程
• 适合微调和小修复

九、实际效果

TÂCHES 的数据

• 使用 \(200/月的 Max 计划 - 每月消耗约\)30,000 的 Opus tokens
• 听起来很多，但因为每个任务都在新鲜上下文中执行，返工极少
• 实际效率远高于在一个退化的上下文中反复修修补补

对比体验

十、结语：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
• 创建者: TÂCHES (glittercowboy)
• 安装: npx get-shit-done-cc

你遇到过 Context Rot 问题吗？尝试过 GSD 或其他解决方案吗？欢迎在评论区分享你的经验。