为什么 5 万人给 GSD 点了 Star？一篇文章讲透它的核心工作流
你的 AI 编码 Agent 是不是写着写着就"失忆"了？GSD 用规格驱动 + 上下文工程彻底解决这个问题。本文从原理到实战，再到同类工具横向对比，一篇讲透。
前言：AI Agent 的"失忆症"
你有没有遇到过这样的场景——
让 Claude Code 或 Codex 帮你写一个中型项目。前 10 轮对话一切顺利：架构清晰、代码规范、测试完整。但到了第 30 轮，Agent 开始"跑偏"：忘了之前定好的数据结构，重复实现已经写过的功能，甚至和自己前面写的代码产生冲突。
这不是个例。这个问题在业内有个专门的术语：上下文腐烂（Context Rot）。
LLM 的注意力机制天生就有一个特点：越早的 token 得到的注意力越多，越晚的 token越容易被"遗忘"。当你的对话积累到几万 token，Agent 对早期设计意图的"记忆"就开始退化。它不是变笨了，而是它的上下文窗口被代码片段、报错日志、文件树等噪音填满了。
怎么办？GSD（Get Shit Done） 给出了一个出人意料的答案：把失忆变成特性。
一、GSD 是什么？
GSD 全称 Get Shit Done，是一套元提示（Meta-Prompting）+ 上下文工程（Context Engineering）+ 规格驱动开发（Spec-Driven Development） 系统。
它的核心理念可以用一句话概括：
规格就是提示词（Specs are Prompts）。 你给 AI Agent 的规格文档有多精确，它输出的代码就有多精确。
1.1 从 v1 到 v2 的演进
GSD 的发展经历了两个阶段：
| 维度 | v1（Prompt 框架） | v2（独立 CLI 应用） |
|---|---|---|
| 运行方式 | Claude Code 斜杠命令 | 基于 Pi SDK 的独立 CLI |
| 上下文管理 | 靠 LLM 自觉 | 程序化清空 + 精准注入 |
| 自动模式 | LLM 自己循环调用自己 | 文件驱动的状态机 |
| 可观测性 | 无 | 成本追踪、进度面板、卡死检测 |
| GitHub Stars | 51K+ | 5K+（独立仓库） |
v1 在 2025 年作为 Claude Code 的 Prompt 框架爆火。它通过一组 Markdown 文件注入到 ~/.claude/commands/，为 Claude Code 增加了项目规划、分阶段执行、验证等工作流。但本质上，它是在"请求" LLM 做这些事，无法真正控制上下文。
v2 做了根本性重写。它不再是 Prompt 框架，而是一个 TypeScript 应用程序，直接通过 Pi SDK 控制 Agent 会话。这意味着 GSD 可以在程序层面做到：每个任务清空上下文、在分发时精确注入所需文件、管理 Git 分支、追踪 token 消耗、检测死循环、从崩溃中恢复。
二、核心架构与工作原理
2.1 四阶段工作流
GSD 的核心工作流分为四个阶段：
讨论（Discuss） → 规划（Plan） → 执行（Execute） → 验证（Verify）
↑ |
└────────────── 下一个切片（Slice） ←───────────────┘
- 讨论阶段：和 Agent 对话，明确你要构建什么。不是"我要搜索功能"这种模糊描述，而是"我要基于 MiniSearch 的客户端全文搜索，支持中文分词，搜索结果高亮"这种精确定义。
- 规划阶段：Agent 分析你的代码库，生成结构化的规格文档（
PROJECT.md、REQUIREMENTS.md、ROADMAP.md），将项目拆分为里程碑（Milestone）、切片（Slice）和任务（Task）。 - 执行阶段：这是 GSD 的核心。Agent 按照规格逐个执行任务，每个任务都在一个全新的上下文窗口中运行。
- 验证阶段：静态检查 → 命令执行 → 行为测试 → 人工审查（仅在 Agent 信心不足时触发）。
2.2 项目层级结构
里程碑（Milestone） ← 一个可发布的版本（包含 4-10 个切片）
└── 切片（Slice） ← 一个可演示的垂直功能（包含 1-7 个任务）
└── 任务（Task） ← 一个原子级的编码单元
这个层级结构不只是组织方式，更是上下文管理的边界。每个任务执行时，GSD 会：
- 创建一个全新的 Agent 会话
- 仅注入该任务所需的上下文（规格、相关代码、依赖信息）
- 让 Agent 在这个干净的窗口中完成工作
- 任务完成后，将结果写回磁盘状态文件
这就是 GSD 解决上下文腐烂的秘密：不是让 Agent 记住一切，而是让它每次只关注一件事。
2.3 上下文工程
GSD 的每次任务分发都经过精心构造，LLM 不需要浪费工具调用来"搞清楚自己在哪"：
- 事实（Truths）：可观察的项目信息——技术栈、文件结构、已完成的任务
- 规格（Specs）：当前任务的精确定义——目标、文件路径、验证标准
- 护栏（Guardrails）：限制条件——不能修改哪些文件、必须遵循哪些规范
┌─────────────────────────────────────┐
│ 全新上下文窗口 │
│ ┌─────────┐ ┌─────────┐ ┌───────┐ │
│ │ 事实 │ │ 规格 │ │ 护栏 │ │
│ └─────────┘ └─────────┘ └───────┘ │
│ ↓ │
│ LLM 执行任务 │
│ ↓ │
│ 结果写回磁盘 │
└─────────────────────────────────────┘
2.4 Git Worktree 隔离
GSD 使用 Git Worktree 实现里程碑级别的代码隔离。每个里程碑在独立的 worktree 中执行，互不干扰。完成后再合并回主分支。这样做的好处是：
- 并行开发多个里程碑
- 某个里程碑失败不会污染其他工作
- 天然的代码审查边界
三、实战教程：从安装到自动构建
3.1 环境准备与安装
# 要求 Node.js >= 22.0.0（推荐 24 LTS）
node --version
# 全局安装 GSD
npm install -g gsd-pi
# 验证安装
gsd --version
注意：如果你使用 oh-my-zsh，它的 git 插件会定义
alias gsd='git svn dcommit'，会覆盖 GSD 命令。解决方案：在~/.zshrc中添加unalias gsd 2>/dev/null，或者使用gsd-cli替代命令。
3.2 首次启动与配置
# 在你的项目目录中启动 GSD
cd 你的项目目录
gsd
首次启动时，GSD 会弹出一个配置向导：
- 选择 LLM 提供商 —— 支持 20+ 提供商（Anthropic、OpenAI、Google、OpenRouter、GitHub Copilot 等）
- 登录认证 —— 如果你有 Claude Max 订阅，可以直接使用
- 模型选择 —— GSD 会自动选择一个默认模型，后续可以用
/model切换
3.3 创建第一个项目
# 进入 GSD 会话后，初始化新项目
/gsd
# 如果目录下没有 .gsd/ 文件夹，GSD 会自动进入讨论流程
# 它会问你一系列产品层面的问题，引导你定义项目范围
讨论阶段结束后，GSD 会自动生成以下文件：
.gsd/
├── PROJECT.md # 项目定义
├── REQUIREMENTS.md # 需求规格
├── ROADMAP.md # 里程碑路线图
├── STATE.md # 当前状态（状态机核心）
├── config.json # 项目配置
└── research/ # 研究阶段的产出
3.4 两种工作模式
Step Mode（步进模式）
/gsd
# 或者
/gsd next
每次执行一个工作单元，完成后暂停，显示一个向导界面告诉你：
- 刚完成了什么
- 下一步是什么
- 当前进度
适合你想保持在循环中、逐步审查每个任务的输出。
Auto Mode（自动模式）
/gsd auto
这是 GSD 的杀手级功能。运行后，GSD 会自主完成：
- 读取
.gsd/STATE.md确定下一个工作单元 - 创建全新的 Agent 会话
- 注入聚焦的上下文
- 执行任务
- 验证结果
- 提交代码
- 推进到下一个任务
- 循环，直到整个里程碑完成
3.5 推荐工作流：双终端模式
GSD 官方推荐的工作方式：一个终端跑自动模式，另一个终端随时介入。
终端 1 —— 让它跑：
gsd
/gsd auto
# 走开去喝杯咖啡
终端 2 —— 随时干预：
gsd
/gsd discuss # 讨论架构决策
/gsd status # 查看进度
/gsd pause # 暂停自动模式
/gsd visualize # 打开可视化面板
3.6 常用命令速查
| 命令 | 用途 |
|---|---|
/gsd | 步进模式，逐步执行 |
/gsd auto | 自动模式，全程无人值守 |
/gsd quick | 快速任务，不需要完整规划 |
/gsd discuss | 进入讨论模式 |
/gsd status | 查看当前进度 |
/gsd pause | 暂停自动模式 |
/gsd stop | 停止自动模式 |
/gsd doctor | 运行健康检查 |
/gsd forensics | 调试自动模式的失败 |
/gsd prefs | 配置模型、超时、预算上限 |
/gsd visualize | 打开工作流可视化面板 |
/gsd start | 启动工作流模板（bugfix、feature、refactor 等） |
3.7 Headless 模式：CI/CD 集成
GSD 支持无界面运行，适合 CI、定时任务和脚本自动化：
# 在 CI 中运行自动模式，设置 10 分钟超时
gsd headless --timeout 600000
# 单步执行
gsd headless next
# 从规格文件创建并执行里程碑
gsd headless new-milestone --context spec.md --auto
四、同类工具对比
GSD 处于一个特殊的位置：它既是一个规格驱动开发（SDD）工具，也是一个终端编码 Agent 的编排层。因此，我们从两个维度进行对比。
4.1 SDD 工具对比：GSD vs Spec Kit vs Taskmaster AI vs Kiro
这四个工具都围绕"先规格、后执行"的理念构建，但在架构和侧重点上差异显著：
| 维度 | GSD | Spec Kit | Taskmaster AI | Kiro |
|---|---|---|---|---|
| 定位 | 执行优先的上下文工程系统 | 规格优先的方法论 | PRD 到任务的分解器 | 规格驱动的 IDE Agent |
| GitHub Stars | 51K+(v1) / 5K+(v2) | 25K+ | 12K+ | N/A（Amazon 产品） |
| 开源协议 | MIT | MIT | MIT | 免费 + 付费 |
| 支持平台 | Claude Code、OpenCode、Gemini CLI | 20+ AI 工具 | Cursor（首选）、Claude Code 等 | 独立 IDE |
| 上下文管理 | 程序化隔离，每任务全新窗口 | 依赖宿主工具 | 依赖宿主工具 | 内置 |
| 自动化程度 | 全自动（auto mode） | 半自动 | 半自动 | 全自动 |
| 核心差异 | 上下文工程 + 崩溃恢复 | 平台广度 + 丰富工件 | 依赖感知的任务树 | 事件驱动 Hooks |
| 研究能力 | 4 个并行研究 Agent | 无内置 | 集成网络搜索 | 内置 |
| 验证机制 | 四级验证阶梯 | 无内置 | 基础 | Hooks 驱动 |
关键差异解读：
- GSD 的核心竞争力是上下文工程。每个执行器获得全新的上下文窗口，这在长时间自动运行中至关重要。但代价是 token 消耗更高（有用户反馈 10 倍于直接使用 Claude Code）。
- Spec Kit 胜在平台广度，支持 20+ AI 工具，且规格产出丰富（18+ 种 Agent 模板）。适合需要跨多个工具使用统一规格的团队。
- Taskmaster AI 的亮点是依赖感知。它将 PRD 解析为有依赖关系的层级任务树，自动确定执行顺序。与 Cursor 的集成最为成熟。
- Kiro 是 Amazon 的产品，独特之处在于 Hooks 系统——事件驱动的自动化，当某些条件满足时自动触发后续动作。AWS 生态集成是其壁垒。
4.2 终端 Agent 对比：GSD vs Claude Code vs Codex CLI vs Aider
从"终端中写代码"的角度，GSD 与这些工具的关系更像是"编排层 vs 执行层"：
| 维度 | GSD（编排层） | Claude Code | Codex CLI | Aider |
|---|---|---|---|---|
| 类型 | 编排系统 | 终端 Agent | 终端 Agent | 终端 Agent |
| 底层模型 | 通过 Pi SDK 接入 | Claude Opus 4.6 | GPT-5.3/5.4 | 任意模型（BYOK） |
| 任务分解 | 自动（Milestone → Slice → Task） | 手动 | 半自动 | 手动 |
| 上下文策略 | 每任务全新窗口 | 单窗口累积 | 云沙箱隔离 | 单窗口累积 |
| Git 集成 | 自动提交（每任务） | 深度集成 | PR/Diff 输出 | 自动提交（每次修改） |
| 自动化程度 | 高（fire-and-forget） | 中（默认交互式） | 高（异步执行） | 低（需要人在旁边） |
| 适合场景 | 多天构建、大型脚手架 | 复杂推理、多文件重构 | 快速任务、隔离执行 | Git 原生工作流 |
| SWE-bench | 依赖底层模型 | 80.9% | 77.3% | 26-79%（取决于模型） |
| 定价 | 与底层模型相同（但消耗更多） | $20-200/月 | $20-200/月 | 免费（API 费用自付） |
选型建议：
你需要什么？ → 选择什么？
──────────────────────────────────────────────────────
长时间自动构建，规格驱动 → GSD
复杂推理、多文件重构、日常编码 → Claude Code
快速任务、隔离安全执行 → Codex CLI
开源、Git 原生、预算有限 → Aider
需要跨 20+ 工具的统一规格 → Spec Kit
Cursor 用户、依赖感知任务管理 → Taskmaster AI
AWS 生态、事件驱动自动化 → Kiro
4.3 一个值得注意的趋势
2026 年的 AI 编码工具正在分化为三个层次：
- 底层模型（Claude、GPT、Gemini）—— 提供推理能力
- 执行 Agent（Claude Code、Codex CLI、Aider）—— 将自然语言转化为代码
- 编排系统（GSD、Spec Kit、Taskmaster）—— 管理长期任务的规划、分解和调度
GSD 的独特之处在于它跨越了第 2 和第 3 层：既是编排系统，也内嵌了执行能力。这让它在长期自动构建场景中有明显优势，但也意味着更高的 token 消耗和学习成本。
五、优缺点与适用场景
适合使用 GSD 的场景
- 独立开发者或小团队，执行多天构建任务
- 从详细规格出发的大型项目脚手架搭建
- 遗留代码库迁移，需要结构化的分阶段执行
- 需要过夜运行的自动构建（崩溃恢复 + 成本追踪让你放心）
- 20+ 个相互关联文件的功能开发
不太适合的场景
- 需要 commit 级人工审批的合规环境（GSD 的 squash-merge 策略会隐藏中间步骤）
- 快速的单文件修改 —— 直接用 Claude Code 或 Aider 更快
- 团队尚未接受 AI 自动化 —— GSD 需要对自动化的信任
- 生产关键的紧急修复 —— GSD 的范式强大但仍在成熟中
- Node.js 22+ 环境受限的场景
性价比考量
GSD 的 token 消耗显著高于直接使用 Claude Code。因为每个任务都要创建全新上下文并注入完整的规格信息。一个中型项目任务的对比：
| 方式 | 预估 token 消耗 | 预估费用 |
|---|---|---|
| 直接 Claude Code | ~50K tokens | $1.50 |
| GSD 编排执行 | ~200-500K tokens | $3-15 |
但如果你把人的时间成本算进去，结论可能完全不同：GSD 可以在你睡觉的时候完成一个完整里程碑。
六、总结
关键收获
- 上下文腐烂是真实问题，GSD 用"每任务全新上下文"的策略正面解决它。
- 规格就是提示词，投入在规格上的时间会在执行阶段获得成倍回报。
- GSD v2 不再是 Prompt 框架，而是一个真正的 TypeScript 应用，程序化控制 Agent 会话。
- 双终端工作流（auto + steer）是 GSD 的推荐用法，平衡了自动化和可控性。
- GSD 不是万能的 —— 快速修复用 Claude Code，日常编码用 Cursor，GSD 解决的是"长期自动构建"这个特定问题。
资源链接
| 资源 | 链接 |
|---|---|
| GSD v2 仓库 | github.com/gsd-build/g… |
| GSD v1 仓库 | github.com/gsd-build/g… |
| 官方文档站 | getshitdone.help |
| Spec Kit | github.com/spec-kit |
| Taskmaster AI | 搜索 "taskmaster-ai" |
| Kiro | kiro.dev |
写在最后：AI 编码工具的竞争在 2026 年进入了白热化阶段。没有一个工具能通吃所有场景。理解每个工具的核心优势和边界，比盲目追逐 Star 数更重要。GSD 解决的是一个很具体的问题：如何让 AI Agent 在长期任务中保持专注。如果这恰好是你的痛点，它值得一试。
如果这篇文章对你有帮助，欢迎点赞收藏，也欢迎在评论区聊聊你在使用 AI 编码工具时遇到的"上下文腐烂"经历。
