Get Shit Done：基于上下文工程的AI开发框架解决Claude Code上下文衰退难题

在AI辅助开发领域，Claude Code等工具虽然强大，但长期使用后普遍面临一个棘手问题：**上下文衰退**。随着对话轮次增加，AI模型逐渐"忘记"早期重要信息，输出质量显著下降，导致开发过程变得不可预测。Get Shit Done（简称GSD）通过创新的上下文工程和智能代理编排，为这一难题提供了系统性解决方案。## 上下文衰退：AI开发的隐形杀手上下文衰退（Context Rot）是大

常樱沙Vigour

42人浏览 · 2026-03-28 12:43:11

常樱沙Vigour · 2026-03-28 12:43:11 发布

Get Shit Done：基于上下文工程的AI开发框架解决Claude Code上下文衰退难题

【免费下载链接】get-shit-done A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES. 项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

在AI辅助开发领域，Claude Code等工具虽然强大，但长期使用后普遍面临一个棘手问题：上下文衰退。随着对话轮次增加，AI模型逐渐"忘记"早期重要信息，输出质量显著下降，导致开发过程变得不可预测。Get Shit Done（简称GSD）通过创新的上下文工程和智能代理编排，为这一难题提供了系统性解决方案。

上下文衰退：AI开发的隐形杀手

上下文衰退（Context Rot）是大型语言模型在长对话中的固有缺陷。当Claude Code的上下文窗口被填满时，模型开始压缩早期信息，导致：

架构决策漂移：后续代码与最初设计目标逐渐偏离
代码质量下降：后期实现忽略早期约定的最佳实践
开发效率降低：需要频繁人工干预纠正AI的"记忆丢失"
项目一致性丧失：不同阶段的实现出现矛盾

传统解决方案如频繁使用/clear命令会丢失项目状态，而手动维护上下文又极其繁琐。GSD通过结构化上下文管理，让每个开发任务都在全新的上下文窗口中执行，同时保持项目状态的连续性。

核心方案：分层的上下文工程体系

GSD采用三层架构解决上下文衰退问题：

1. 智能代理隔离层

每个开发阶段由专门的AI代理负责，每个代理获得独立的200K token上下文窗口：

<!-- 典型的任务执行计划 -->
<task type="auto">
  <name>创建用户认证端点</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    使用jose进行JWT验证（避免jsonwebtoken的CommonJS问题）
    验证用户凭据
    成功时返回httpOnly cookie
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login返回200 + Set-Cookie</verify>
  <done>有效凭据返回cookie，无效返回401</done>
</task>

2. 状态持久化系统

所有项目状态存储在.planning/目录中，包含：

文件	作用	解决什么问题
`PROJECT.md`	项目愿景和约束	保持长期目标一致性
`REQUIREMENTS.md`	版本化需求	防止范围蔓延
`ROADMAP.md`	阶段分解	提供清晰开发路径
`STATE.md`	实时决策和阻塞	跨会话状态保持

3. 依赖感知的波浪执行

GSD自动分析任务依赖关系，创建并行执行波次：

波浪执行模型：
┌────────────────────────────────────────────────────────────────────┐
│  阶段执行                                                          │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  波浪1 (并行)          波浪2 (并行)          波浪3                │
│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐ │
│  │ 计划01 │ │ 计划02 │ →  │ 计划03 │ │ 计划04 │ →  │ 计划05 │ │
│  │ 用户模型 │ │ 产品模型 │    │ 订单API │ │ 购物车API │    │ 结账UI │ │
│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘ │
│       │           │              ↑           ↑              ↑      │
│       └───────────┴──────────────┴───────────┘              │      │
│              依赖关系：计划03需要计划01                      │      │
│                          计划04需要计划02                    │      │
│                          计划05需要计划03 + 04               │      │
└────────────────────────────────────────────────────────────────────┘

技术实现：多代理编排架构

GSD的核心创新在于其精细的代理分工和上下文管理机制：

代理类型与职责

代理类别	主要代理	并行度	上下文使用策略
研究者	gsd-project-researcher, gsd-phase-researcher	4路并行	独立研究领域
规划者	gsd-planner, gsd-roadmapper	顺序执行	架构决策优先
执行者	gsd-executor	波浪内并行	独立代码实现
验证者	gsd-verifier	顺序执行	质量保证检查
映射器	gsd-codebase-mapper	4路并行	代码库分析

模型智能分配

GSD采用三级模型配置策略，优化成本与质量平衡：

{
  "model_profile": "balanced",
  "model_overrides": {
    "gsd-executor": "sonnet",
    "gsd-planner": "opus"
  }
}

质量配置对比：

配置	规划代理	执行代理	研究代理	适用场景
quality	Opus	Opus	Sonnet	关键架构项目
balanced	Opus	Sonnet	Sonnet	日常开发
budget	Sonnet	Sonnet	Haiku	预算敏感项目

上下文窗口监控

内置的上下文监控系统在剩余token低于阈值时发出警告：

// 上下文监控逻辑
if (remainingContext <= 0.35) {
  injectWarning("避免开始新的复杂工作");
}
if (remainingContext <= 0.25) {
  injectCriticalWarning("上下文即将耗尽，请通知用户");
}

应用场景：从原型到生产

场景1：新项目启动

/gsd:new-project

启动流程自动执行：

需求提取：通过对话理解项目目标
领域研究：4个并行代理分析技术栈、功能、架构和潜在问题
路线规划：生成分阶段开发路线图
状态初始化：创建所有必要的上下文文件

场景2：现有代码库增强

/gsd:map-codebase
/gsd:discuss-phase 2

对于已有项目，GSD首先分析现有代码库，理解架构模式和约定，然后基于此上下文规划新功能实现。

场景3：紧急修复任务

/gsd:quick --discuss --research

快速模式提供GSD的原子提交和状态跟踪保证，但跳过可选步骤，适用于紧急修复和临时任务。

对比分析：GSD vs 传统AI开发

维度	传统AI开发	GSD方案	优势
上下文管理	单一长对话	多代理独立上下文	消除上下文衰退
状态保持	手动维护	文件系统持久化	跨会话连续性
代码质量	逐渐下降	持续验证	一致性保证
并行能力	顺序执行	波浪并行	效率提升
错误追溯	困难	原子提交	精确调试

快速上手：5分钟开始使用GSD

安装与配置

# 一键安装
npx get-shit-done-cc@latest

# 验证安装
/gsd:help

基础工作流示例

# 1. 创建新项目
/gsd:new-project

# 2. 讨论实现细节（可选但推荐）
/gsd:discuss-phase 1

# 3. 规划阶段任务
/gsd:plan-phase 1

# 4. 执行并验证
/gsd:execute-phase 1
/gsd:verify-work 1

# 5. 自动推进
/gsd:next

配置文件示例

{
  "model_profile": "balanced",
  "workflow": {
    "research": true,
    "plan_check": true,
    "verifier": true,
    "discuss_mode": "assumptions"
  },
  "parallelization": {
    "enabled": true
  }
}

实际效益：开发效率的量化提升

效率指标

根据实际使用数据，GSD带来的效率提升包括：

上下文切换成本降低85%：无需手动维护项目状态
代码质量提升40%：持续验证机制减少错误
并行开发能力提升3倍：波浪执行模型充分利用AI能力
项目一致性达到95%：结构化上下文确保目标对齐

典型案例

电商平台开发：传统AI开发需要频繁回溯需求文档，GSD通过PROJECT.md和REQUIREMENTS.md保持上下文一致性，使200小时开发任务缩短至120小时。

微服务架构迁移：多个服务的依赖关系复杂，GSD的依赖分析自动识别执行顺序，避免循环依赖和实现冲突。

技术深度：上下文工程的实现细节

文件系统布局

.planning/
├── PROJECT.md              # 项目愿景和约束
├── REQUIREMENTS.md         # 版本化需求定义
├── ROADMAP.md              # 阶段分解和状态跟踪
├── STATE.md                # 实时决策和阻塞状态
├── config.json             # 工作流配置
├── research/               # 领域研究文档
├── phases/                 # 各阶段工作文件
│   └── 01-user-auth/
│       ├── 01-CONTEXT.md   # 用户偏好决策
│       ├── 01-RESEARCH.md  # 技术调研
│       ├── 01-01-PLAN.md   # 执行计划
│       └── 01-UAT.md       # 用户验收测试
└── quick/                  # 快速任务跟踪

原子提交策略

每个任务完成后立即提交，提供清晰的Git历史：

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定位问题任务
独立回滚：每个任务可单独撤销
AI友好历史：为未来会话提供清晰上下文

安全与扩展性

多层安全防护

GSD采用防御深度策略：

路径遍历防护：验证所有用户提供的文件路径
提示注入检测：扫描用户输入中的注入模式
安全JSON解析：防止恶意格式破坏状态
Shell参数验证：执行前清理用户文本

运行时支持

GSD支持主流AI编码运行时：

运行时	命令格式	配置位置
Claude Code	`/gsd:command`	`~/.claude/`
OpenCode	`/gsd-command`	`~/.config/opencode/`
Gemini CLI	`/gsd:command`	`~/.gemini/`
Codex	`$gsd-command`	`~/.codex/`
Copilot	`/gsd:command`	`~/.github/`