这是「GSD 全景代码解析」专题的第 1 篇。在本系列中，我们将逐层拆解 Get Shit Done (GSD) 这一 56K+ stars 的 Meta-Prompting 框架，从命令系统到工作流编排，从 Agent 设计到上下文工程，带你一览上下文驱动开发的工程全貌。
一、GSD 是什么
Get Shit Done（GSD） 是由独立开发者 TÂCHES 创建的一套开源框架。它的 GitHub 仓库 gsd-build/get-shit-done 已获得 56,000+ stars，被 Amazon、Google、Shopify、Webflow 等公司的工程师所采用。
GSD 将自己定位为一个轻量级且强大的 Meta-Prompting、Context Engineering 和 Spec-Driven Development 系统。它支持 14 种以上的 AI 编码运行时：
- Claude Code
- OpenCode / Kilo
- Gemini CLI
- Codex
- GitHub Copilot
- Cursor
- Windsurf
- Antigravity
- Augment
- Trae
- Qwen Code
- Cline
- CodeBuddy
安装只需一条命令：
npx get-shit-done-cc@latest"I’m a solo developer. I don’t write code — Claude Code does." —— TÂCHES
GSD 诞生的背景非常明确：TÂCHES 是一位独立开发者，他不亲自写代码，而是让 Claude Code 代劳。但现有的 Spec-Driven Development 工具要么过于复杂（Sprint 仪式、Story Points、Jira 工作流等企业级戏码），要么缺乏对项目全局的真正理解。GSD 的哲学是将复杂度隐藏在系统内部，而不是暴露在工作流表面——用户看到的是一个简单的命令行界面，背后则是上下文工程、XML Prompt 格式化、Subagent 编排和状态管理的完整机制。
二、Context Rot：AI 编程中的根本问题
在深入 GSD 的架构之前，我们必须先理解它要解决的核心问题——Context Rot（上下文腐烂）。
2.1 什么是 Context Rot
Context Rot 是指随着 AI 模型的上下文窗口被逐渐填满，输出质量持续退化的现象。当你与 Claude、GPT 或其他大语言模型进行长时间的对话时，模型会累积大量的对话历史、代码片段、错误堆栈和修正记录。这些累积的内容就像不断增长的债务，最终会导致以下问题：
| 问题类型 | 具体表现 |
|---|---|
| Token 预算耗尽 | 可用上下文窗口被历史对话填满，新输入被截断或压缩 |
| 注意力稀释 | 模型无法在庞大的上下文中保持对关键信息的精确关注 |
| 质量退化 | 代码一致性下降、遗忘早期约定、重复引入已修复的 bug |
| 幻觉增加 | 模型开始"猜测"而不是基于事实进行推理 |
2.2 Context Rot 的形成过程
flowchart TD
A[开始新项目
上下文窗口：0%] --> B[需求讨论
+ 项目背景 + 约束条件]
B --> C[第一轮编码
+ 代码 + 错误 + 修正]
C --> D[第二轮编码
+ 更多代码 + 更多对话]
D --> E[第三轮编码
+ 积累的技术债务]
E --> F[上下文窗口接近满载
~80-90%]
F --> G{质量变化}
G -->|遗忘早期架构决策| H[架构漂移]
G -->|忽略已有工具函数| I[重复造轮子]
G -->|误解业务逻辑| J[引入回归 bug]
G -->|注意力分散| K[生成不一致的代码风格]
H --> L[Context Rot
项目逐渐失控]
I --> L
J --> L
K --> L这种现象在**长时间的单体对话（Monolithic Session）**中尤为严重。传统的 AI 编程方式往往是：打开一个对话窗口，描述需求，然后不断迭代、修正、扩展。几小时后，上下文窗口已经充斥着数十轮对话的累积信息，模型的表现开始明显下降。
2.3 为什么传统方法无法解决
常见的应对策略包括：
- 手动清理上下文：删除不重要的历史消息——但用户很难判断哪些信息是关键依赖，哪些可以丢弃。
- 频繁开启新对话：丢失项目记忆，每次都需要重新描述项目背景和技术栈。
- 依赖模型的长上下文能力：即使 200K 或 1M 的上下文窗口，Context Rot 只是被推迟，而不是被消除。
根本原因只有一个：没有一个系统化的机制来管理上下文的加载、刷新和隔离。
三、Meta-Prompting：用提示词管理提示词
GSD 的核心设计理念是 Meta-Prompting（元提示）——用提示词来管理和编排提示词。
3.1 从 Prompt 到 Meta-Prompt
在传统的 AI 交互中，用户直接编写 Prompt 来指导模型完成特定任务。而 Meta-Prompting 则在此基础上增加了一层抽象：
flowchart LR
subgraph 传统方式
U1[用户] -->|直接写 Prompt| M1[AI 模型]
end
subgraph Meta-Prompting
U2[用户] -->|描述意图| S[Meta-Prompt 系统]
S -->|自动生成
结构化 Prompt| M2[AI 模型]
S -->|编排多个 Agent| M3[AI 模型]
S -->|管理上下文加载| M4[AI 模型]
end在 GSD 中，用户不需要亲自为每个任务编写详细的 Prompt。相反，用户通过简单的命令（如 /gsd-new-project、/gsd-plan-phase、/gsd-execute-phase）触发预定义的工作流，而这些工作流内部则包含了完整的 Meta-Prompt 逻辑。
3.2 GSD 的 Meta-Prompt 架构
GSD 的 Meta-Prompt 系统由多层组件构成：
- Commands（命令层）：用户通过
/gsd-*命令触发工作流 - Workflows（工作流层）：编排逻辑，负责加载上下文、生成 Agent 指令、管理状态
- Agents（智能体层）：专业化的 Agent 定义，包含角色、工具权限和 Prompt 模板
- References（知识库层）：共享的参考文档，被 Workflows 和 Agents 引用
- Templates（模板层）：预定义的结构化文件模板（PROJECT.md、PLAN.md 等）
这种分层架构的核心价值在于：它将 Prompt 工程从临时性的手工操作转变为系统化的工程实践。
3.3 XML 结构化的 Prompt
GSD 为每个任务生成结构化的 XML 格式 Prompt，例如：
<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>这种格式消除了模糊性——模型不需要"猜测"应该做什么，每个字段都有精确的语义定义。action 告诉它做什么，verify 告诉它如何验证，done 告诉它完成的定义是什么。
四、Spec-Driven Development：规范驱动开发
GSD 的另一个核心理念是 Spec-Driven Development（规范驱动开发）。在传统的 AI 编程（Vibecoding）中，用户描述想要什么，AI 生成代码，结果往往是"不一致的垃圾，在规模扩大后崩溃"。GSD 通过 .planning/ 目录中的一系列规范文件来建立项目的真相源（Single Source of Truth）。
4.1 .planning/ 目录结构
.planning/
├── PROJECT.md # 项目愿景、约束、决策、演进规则
├── REQUIREMENTS.md # 明确范围的需求（v1/v2/out-of-scope）
├── ROADMAP.md # 阶段分解与状态追踪
├── STATE.md # 活跃记忆：位置、决策、阻塞项、指标
├── config.json # 工作流配置
├── research/ # 领域研究成果
│ ├── SUMMARY.md
│ ├── STACK.md
│ ├── FEATURES.md
│ ├── ARCHITECTURE.md
│ └── PITFALLS.md
└── phases/
└── XX-phase-name/
├── XX-CONTEXT.md # 用户偏好（来自 discuss-phase）
├── XX-RESEARCH.md # 生态系统研究
├── XX-YY-PLAN.md # 执行计划
├── XX-YY-SUMMARY.md # 执行结果
└── XX-VERIFICATION.md # 执行后验证4.2 规范文件的作用
每个文件在系统中扮演特定角色：
| 文件 | 作用 | 受众 |
|---|---|---|
PROJECT.md | 项目愿景，始终加载 | 所有 Agent |
REQUIREMENTS.md | 明确范围的需求，可追溯 | Planner、Verifier、Auditor |
ROADMAP.md | 阶段分解与进度 | Orchestrators |
STATE.md | 跨会话的持久记忆 | 所有 Agent |
CONTEXT.md | 每阶段的用户偏好 | Researcher、Planner、Executor |
RESEARCH.md | 每阶段的生态研究 | Planner、Plan Checker |
PLAN.md | 每个计划的具体任务 | Executor、Plan Checker |
SUMMARY.md | 每计划的执行结果 | Verifier、State Tracking |
这种结构化的规范体系确保了：
- 信息不丢失：所有决策和状态都持久化到文件中
- 上下文可精确加载：每个 Agent 只接收它需要的上下文
- 可追溯性：每个代码变更都可以追溯到具体的需求和计划
五、GSD 的解决方案：Fresh Context Per Agent
GSD 解决 Context Rot 的核心机制是 Fresh Context Per Agent（每个 Agent 独立上下文）。
5.1 多 Agent 编排的工作模式
flowchart TD
subgraph 主会话
U[用户] -->|/gsd-execute-phase 1| O[Orchestrator
编排器]
O -->|主上下文保持
30-40% 占用| O
end
subgraph Wave 1 [并行执行]
O -->|Spawn Agent| E1[Executor 1
200K 纯净上下文]
O -->|Spawn Agent| E2[Executor 2
200K 纯净上下文]
E1 -->|原子提交| G1[Git Commit]
E2 -->|原子提交| G2[Git Commit]
end
subgraph Wave 2 [依赖执行]
O -->|Spawn Agent| E3[Executor 3
200K 纯净上下文]
E3 -->|原子提交| G3[Git Commit]
end
subgraph 验证
O -->|Spawn Agent| V[Verifier
新鲜上下文]
V -->|生成报告| R[VERIFICATION.md]
end
G1 --> Wave 2
G2 --> Wave 2
G3 --> 验证在这个模型中：
- Orchestrator（编排器） 运行在用户的主会话中，但它的工作很轻量——只是加载上下文、生成 Agent 指令、收集结果、路由下一步
- 每个 Executor（执行器） 都在一个全新的上下文窗口中运行，拥有 200K（或更高）token 的纯净空间
- 执行完成后，Agent 的上下文被丢弃，结果以
SUMMARY.md和 Git Commit 的形式持久化 - Verifier（验证器） 再以一个新鲜上下文检查执行结果
5.2 Wave 执行模型
GSD 将计划按依赖关系分组为 Wave（波次）：
Wave 1 (并行)
├── Plan 01: User Model (无依赖)
└── Plan 02: Product Model (无依赖)
Wave 2 (等待 Wave 1)
├── Plan 03: Orders API (依赖 Plan 01)
└── Plan 04: Cart API (依赖 Plan 02)
Wave 3 (等待 Wave 2)
└── Plan 05: Checkout UI (依赖 Plan 03 + 04)独立计划并行执行，依赖计划串行等待。每个 Executor 只在自己的上下文中工作，彼此之间不会污染。
5.3 为什么这能解决 Context Rot
| 传统方式 | GSD 方式 |
|---|---|
| 单一会话累积所有上下文 | 每个任务使用独立上下文 |
| 200K token 被历史对话占用 | 200K token 全部用于当前任务 |
| 注意力被无关信息分散 | 只接收精确筛选的上下文 |
| 质量随时间线性下降 | 每个任务都以最佳质量完成 |
正如 GSD 文档所说："你可以运行一整个阶段——深度研究、多个计划被创建和验证、数千行代码在并行 Executor 中写入、自动化验证——而你的主上下文窗口只使用了 30-40%。工作发生在新鲜的 Subagent 上下文中，你的会话保持快速和响应。"
六、GSD 与传统 AI 编程工具的对比
6.1 传统工具的根本局限
Cursor Rules / Cline Rules：
这些是简单的规则文件（如 .cursorrules、.clinerules），定义了代码风格和项目约定。它们的问题在于：
- 静态规则：无法动态加载项目状态、阶段进度或研究结论
- 无状态管理：不知道项目当前处于哪个阶段，完成了什么，下一步该做什么
- 无编排能力：无法触发研究、规划、执行、验证的完整工作流
- 单一会话：所有工作都在一个对话中完成，Context Rot 不可避免
Devin 等 AI 编码 Agent：
Devin 代表另一类工具——全自动的 AI 程序员。但它的局限性在于：
- 黑盒执行：用户难以理解和干预其决策过程
- 缺乏规范驱动：没有
.planning/这样的结构化规范体系 - 上下文管理不透明：用户无法精确控制上下文的加载和刷新
- 企业级复杂：过多的仪式感和流程负担
6.2 GSD 的根本差异
flowchart LR
subgraph Cursor/Cline
R1[静态规则文件] --> C1[单一会话]
C1 -->|Context Rot| D1[质量退化]
end
subgraph Devin
R2[全自动 Agent] --> C2[黑盒执行]
C2 -->|难以干预| D2[失控风险]
end
subgraph GSD
R3[Meta-Prompt 框架] --> C3[多 Agent 编排]
C3 -->|Fresh Context| D3[持续高质量]
C3 -->|.planning/ 规范| D4[完全透明]
C3 -->|用户可控| D5[灵活干预]
end| 维度 | Cursor Rules / Cline Rules | Devin | GSD |
|---|---|---|---|
| 核心机制 | 静态规则文件 | 全自动 Agent | Meta-Prompt + 多 Agent 编排 |
| 上下文管理 | 无 | 不透明 | Fresh Context Per Agent |
| 状态持久化 | 无 | 内部状态 | .planning/ 文件系统 |
| 用户可控性 | 低 | 低 | 高（每个步骤可干预） |
| 规范体系 | 无 | 弱 | Spec-Driven Development |
| 透明度 | 低 | 低 | 高（所有决策文件化） |
| 扩展性 | 低 | 中 | 高（插件化 Agent、Hooks） |
| 复杂度 | 低 | 高（企业级） | 中（复杂度在系统内） |
GSD 的独特之处在于它不是简单的规则集，也不是完全自动化的黑盒。它是一个完整的 Context Engineering 框架，提供了从项目初始化到里程碑完成的完整管道，同时保持每个步骤的透明度和用户可控性。
七、质量保障机制
GSD 不只是一套工作流，它还内置了多层质量保障：
7.1 四层防御
- Plan Checker（计划验证）：执行前验证计划是否覆盖需求，最多迭代 3 次
- Atomic Commits（原子提交）：每个任务独立提交，可追溯、可回滚
- Post-Execution Verification（执行后验证）：自动检查代码是否符合阶段目标
- UAT（用户验收测试）：人工验证，不通过则自动生成修复计划
7.2 内置安全检查
GSD 从 v1.27 开始内置了安全加固：
- 路径遍历防护：验证用户提供的文件路径在工程目录内
- Prompt Injection 检测：扫描用户输入中的注入模式
- PreToolUse Prompt Guard：扫描
.planning/写入操作中的注入向量 - 安全 JSON 解析：防止畸形参数破坏状态
八、总结
GSD 代表了一种新的 AI 编程范式——不是让 AI 替你写代码，而是建立一套系统化的上下文工程框架，让 AI 能够持续、可靠、高质量地为你工作。
它的核心创新可以总结为三点：
- Meta-Prompting：用提示词管理和编排提示词，将 Prompt 工程从手工艺术转变为系统工程
- Fresh Context Per Agent：通过多 Agent 编排和 Wave 执行模型，从根本上解决 Context Rot
- Spec-Driven Development：通过
.planning/目录建立项目的真相源，确保所有决策可追溯、可验证
正如 TÂCHES 所说："The complexity is in the system, not in your workflow."（复杂度在系统内部，而不在你的工作流中。）这正是 GSD 的设计哲学——用户看到的只是几个简单命令，背后却是一整套经过精心设计的上下文工程机制。
下一篇预告： 第 02 篇《仓库结构全景图》
我们将深入 GSD 的命令系统，逐一解析 /gsd-new-project、/gsd-discuss-phase、/gsd-plan-phase、/gsd-execute-phase 等核心命令的实现逻辑，以及它们如何协同工作来驱动整个开发流程。 敬请期待。