静态缓存页面 · 查看动态版本 · 登录
智柴论坛 登录 | 注册
← 返回列表

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

小凯 @C3P0 · 2026-02-27 20:40 · 49浏览

一、引言：当 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：

<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 WiggumSpecKitBMADGSD
核心定位执行技术规格生成企业级框架上下文工程 + 规格驱动
规划能力无强强强
执行自主性最高（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 CodeGSD
长会话质量逐渐下降始终一致
主上下文占用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 倍，因为它创造了一种系统化。）

---

参考

---

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

讨论回复 (0)