你有没有过这种体验：让 AI 写一个功能，前半小时行云流水，后半小时开始跑偏，再往后连自己说过什么都忘了。

这不是 AI 模型的问题。这是上下文腐化（Context Rot）——随着对话轮次增加，AI 的输出质量从山顶滑向山脚。Anthropic 自己的研究表明，当上下文窗口填充超过 60% 时，模型的指令遵循能力显著下降。而一个中等复杂度的功能，单会话很容易用掉 60-80% 的上下文。

这就是 GSD 要解决的核心问题。

GSD 是什么

GSD（Get Shit Done）是一个轻量级的元提示（Meta-Prompting）、上下文工程（Context Engineering）和规范驱动开发（Spec-Driven Development）系统，由开发者 TÂCHES（Lex Christopherson）创建，专为 Claude Code、OpenCode、Gemini CLI、Copilot、Cursor、Windsurf 等 14+ 种 AI 编程运行时设计。

截至 2026 年 5 月，GitHub 仓库已获得 60,500+ Star，138+ 贡献者，2,100+ 次提交，发布了 57 个版本，最新为 v1.41.0。

作者的理念："其他规范驱动工具是为 50 人工程组织设计的——sprint 仪式、story points、Jira 工作流。而我不是。我是一个想持续构建好东西的创意人。复杂在系统之中，不在你的工作流里。"

它的核心思路很朴素：不要把整个项目塞进一个会话。而是将项目拆成多个阶段，每个阶段在全新的 200K Token 上下文窗口中执行，主窗口只负责调度和汇总，始终保持在 30-40% 的低水位。

核心机制：三层上下文工程

GSD 之所以能解决上下文腐化，依赖三个关键设计：

1. 上下文隔离

每个子任务——研究、规划、执行、验证——都在独立的子代理上下文中运行。研究者拿到项目背景，规划者拿到研究结论，执行者拿到具体计划。每个代理只需知道自己该知道的，不会被无关节细节干扰。

2. 结构化持久化工件

GSD 在文件系统上维护一套完整的工作品，不会因关闭会话而丢失：

文件 作用
PROJECT.md 项目愿景与目标
REQUIREMENTS.md 需求规格与追踪矩阵
ROADMAP.md 路线图与里程碑规划
STATE.md 当前进度与决策状态
CONTEXT.md 每阶段的实现决策（跨会话持久化）

这套文件系统的意义在于：它不是"一次性指令"，而是持续积累的项目记忆。下次打开 Claude Code 时，AI 读取这些文件就能知道上次做到了哪一步、做了哪些决策。

3. 验证闭环

代码"能跑"不等于"能工作"。GSD 的验证步骤遍历构建成果，用专用的调试代理诊断失败情况，在"阶段完成"前生成修复计划，形成真正的闭环。

六命令核心工作流

GSD 将开发流程拆解为六个命令，每个命令对应一个独立阶段：

/gsd-new-project       → 初始化：提问 → 研究 → 需求 → 路线图
/gsd-discuss-phase N   → 讨论：锁定实现决策，生成 CONTEXT.md
/gsd-plan-phase N      → 规划：研究 + 计划 + 验证循环
/gsd-execute-phase N   → 执行：计划按并行波次执行，原子提交
/gsd-verify-work N     → 验证：人工 UAT，调试代理诊断
/gsd-ship N            → 交付：创建 PR，准备发布

/gsd-new-project：从想法到路线图

这个命令是整个流程的起点。它会向你提问——项目目标、技术栈偏好、功能范围——然后启动 4 个并行研究代理分别调研技术栈、功能、架构和风险，最后生成 PROJECT.md、REQUIREMENTS.md、ROADMAP.md 和 STATE.md。

/gsd-discuss-phase N：锁定决策

在写任何代码之前，先明确"我们到底要做什么"。这个阶段产出 CONTEXT.md，记录每个实现决策的上下文和理由，避免后续阶段在同一个问题上反复纠结。

/gsd-plan-phase N：研究 + 计划 + 验证

这是 GSD 最复杂的阶段，涉及多层子代理编排：

Phase Researcher (×4 并行)
  ├── 技术栈研究员
  ├── 功能研究员
  ├── 架构研究员
  └── 风险研究员
        │
  ┌─────▼──────┐
  │ RESEARCH.md │
  └─────┬──────┘
        │
  ┌─────▼──────┐
  │   规划器    │ ← 读取 PROJECT, REQUIREMENTS, CONTEXT, RESEARCH
  └─────┬──────┘
        │
  ┌─────▼──────┐     ┌──────────┐
  │ 规划检查器  │────▶│   通过?   │
  └─────────────┘     └────┬─────┘
                      Yes/No (最多 3 次迭代)

规划器基于研究结果生成 XML 格式的原子化任务计划，规划检查器验证计划的完整性和一致性，最多迭代 3 次直到通过。

/gsd-execute-phase N：波次执行

执行阶段是 GSD 上下文工程的精髓。计划被分组为"波次"（Waves），无依赖的计划并行执行，有依赖的按序执行。

# 每个计划文件头部用 YAML frontmatter 声明波次与依赖
wave: 2
depends_on: ["03-01", "03-03"]

每个执行器在自己的独立子代理上下文中运行，完成后自动生成 NN-XX-SUMMARY.md 总结和原子 Git 提交。如果某个任务出错，可以精确定位到那次 commit 并用 git bisect 排查。

/gsd-verify-work N：人工验收

代码写完了，但这一步不能跳过。你需要人工测试，确认功能确实按预期工作。如有问题，GSD 的调试代理会自动分析失败原因并生成修复计划。

/gsd-ship N：交付

验证通过后，直接从阶段工作品创建 PR，准备合并。GSD 还会检查合并后的构建和测试是否通过。

波次执行引擎

波次执行是 GSD v1.40 后的核心能力，理解它才能真正用好 GSD：

/gsd-execute-phase N
    │
    ├── 波次 1（无依赖）
    │     ├── 执行器 A  ──▶ 原子提交
    │     └── 执行器 B  ──▶ 原子提交
    │           │
    ├── 波次 2（依赖波次 1 的输出）
    │     └── 执行器 C  ──▶ 原子提交
    │           │
    └── 验证器 → 对照 REQUIREMENTS.md 检查

关键优势：

v1.40 的三大跃升

Minimal Install Profile

npx get-shit-done-cc --minimal

仅安装 6 个核心技能（new-project、discuss-phase、plan-phase、execute-phase、help、update），系统提示开销从 ~12,000 Token 骤降至 ~700 Token（94% 降幅）。这对 32K-128K 上下文的本地模型或按 Token 计费的 API 来说意义重大。

技能整合：86 → 59

v1.39-v1.40 期间，通过引入 4 个分组技能（capture、phase、config、workspace）和 6 个带 flag 的父技能，将技能总数从 86 缩减到 59，零功能损失。

命名空间路由

引入 6 个命名空间元技能作为分层入口：

命名空间 路由 指向
Phase Pipeline /gsd-ns-workflow discuss, plan, execute, verify, phase, progress
Project Lifecycle /gsd-ns-project milestones, audits, summary
Quality Gates /gsd-ns-review code review, debug, audit, security, eval, UI
Codebase Intelligence /gsd-ns-context map, graphify, docs, learnings
Management /gsd-ns-manage config, workspace, workstreams, thread, update, ship
Exploration /gsd-ns-ideate explore, sketch, spike, spec, capture

技能列表的 Token 成本从 ~2,150 降至 ~120 Token。每个具体技能仍然可以直接调用，命名空间只为模型的"发现层"服务。

模型配置：按角色分配合适的算力

GSD 允许你按代理角色独立配置模型层级（Quality / Balanced / Budget）：

代理 Quality Balanced Budget
gsd-planner Opus Opus Sonnet
gsd-executor Opus Sonnet Sonnet
gsd-phase-researcher Opus Sonnet Haiku
gsd-debugger Opus Sonnet Sonnet
gsd-verifier Sonnet Sonnet Haiku
gsd-plan-checker Sonnet Sonnet Haiku

这意味着你可以在规划阶段用最强的推理模型，在批量研究阶段用更便宜的模型，最大化性价比。

安装与上手

# 初始化项目
npx get-shit-done-cc@latest

# 最小化安装（推荐本地模型或低预算场景）
npx get-shit-done-cc --minimal

# 更新到最新版本
/gsd-update

初始化后，在 Claude Code 中运行 /gsd-new-project 即可开始。

GSD 支持 14+ 种运行时：Claude Code、OpenCode、Gemini CLI、Kilo Code、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、CodeBuddy、Cline、Qwen Code。

与 Superpowers、OpenSpec 的对比

这三个工具常常被放在一起比较，但它们解决的是不同层面的问题：

维度 GSD Superpowers OpenSpec
定位 上下文工程 + 执行编排 工程纪律 + TDD 流程 规范定义 + 变更管理
核心问题 上下文腐化 AI 随意写码 需求不清晰
工作流 6 命令：讨论→计划→执行→验证→交付 7 阶段：头脑风暴→计划→TDD→审查→完成 OPSX 动作系统：新建→快速搭架→应用→验证→归档
执行模型 波次并行 + 子代理 子代理 + 两阶段 Review 变更隔离文件夹
强项 长链路项目不跑偏 强制工程纪律 已有代码库改造
短板 Token 消耗大 小任务流程过重 绿地项目上手路径不同
Star 60.5K+ 14K+ 24.9K+
运行时 14+ 种 Claude Code + Copilot CLI 等 20+ 种

社区实践中的一个共识是：它们不是互斥的，而是互补的。

一个典型的分层组合：

决策层 → gstack（想清楚做什么、该不该做）
上下文层 → GSD（规格和状态锚定，防止长链漂移）
执行层 → Superpowers（规划→TDD→验收闭环）

精炼公式：gstack thinks, GSD stabilizes, Superpowers executes.

什么时候该选 GSD

适合的场景：

不太适合的场景：

总结

GSD 的核心思想简单而有效：不要把所有东西塞进一个会话。通过将开发流程拆解为讨论→计划→波次执行→验证→交付六个独立阶段，每个阶段运行在全新的上下文窗口中，GSD 从根本上解决了 AI 编码的上下文腐化问题。

v1.40 的 Minimal Install Profile、技能整合和命名空间路由进一步降低了使用门槛和 Token 成本。配合波次执行引擎，GSD 让一个复杂项目的实现变成"清晰的阶段 + 并行的波次 + 原子化的提交"，而不是一个越聊越乱的单一会话。

如果你正在做一个需要多轮 AI 协作的复杂项目，GSD 值得一试。

参考资料