为什么 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 的核心工作流分为四个阶段:
markdown
讨论(Discuss) → 规划(Plan) → 执行(Execute) → 验证(Verify)
↑ |
└────────────── 下一个切片(Slice) ←───────────────┘
- 讨论阶段:和 Agent 对话,明确你要构建什么。不是"我要搜索功能"这种模糊描述,而是"我要基于 MiniSearch 的客户端全文搜索,支持中文分词,搜索结果高亮"这种精确定义。
- 规划阶段 :Agent 分析你的代码库,生成结构化的规格文档(
PROJECT.md、REQUIREMENTS.md、ROADMAP.md),将项目拆分为里程碑(Milestone)、切片(Slice)和任务(Task)。 - 执行阶段 :这是 GSD 的核心。Agent 按照规格逐个执行任务,每个任务都在一个全新的上下文窗口中运行。
- 验证阶段:静态检查 → 命令执行 → 行为测试 → 人工审查(仅在 Agent 信心不足时触发)。
2.2 项目层级结构
arduino
里程碑(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 环境准备与安装
bash
# 要求 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 首次启动与配置
bash
# 在你的项目目录中启动 GSD
cd 你的项目目录
gsd
首次启动时,GSD 会弹出一个配置向导:
- 选择 LLM 提供商 ------ 支持 20+ 提供商(Anthropic、OpenAI、Google、OpenRouter、GitHub Copilot 等)
- 登录认证 ------ 如果你有 Claude Max 订阅,可以直接使用
- 模型选择 ------ GSD 会自动选择一个默认模型,后续可以用
/model切换
3.3 创建第一个项目
bash
# 进入 GSD 会话后,初始化新项目
/gsd
# 如果目录下没有 .gsd/ 文件夹,GSD 会自动进入讨论流程
# 它会问你一系列产品层面的问题,引导你定义项目范围
讨论阶段结束后,GSD 会自动生成以下文件:
bash
.gsd/
├── PROJECT.md # 项目定义
├── REQUIREMENTS.md # 需求规格
├── ROADMAP.md # 里程碑路线图
├── STATE.md # 当前状态(状态机核心)
├── config.json # 项目配置
└── research/ # 研究阶段的产出
3.4 两种工作模式
Step Mode(步进模式)
bash
/gsd
# 或者
/gsd next
每次执行一个工作单元,完成后暂停,显示一个向导界面告诉你:
- 刚完成了什么
- 下一步是什么
- 当前进度
适合你想保持在循环中、逐步审查每个任务的输出。
Auto Mode(自动模式)
bash
/gsd auto
这是 GSD 的杀手级功能。运行后,GSD 会自主完成:
- 读取
.gsd/STATE.md确定下一个工作单元 - 创建全新的 Agent 会话
- 注入聚焦的上下文
- 执行任务
- 验证结果
- 提交代码
- 推进到下一个任务
- 循环,直到整个里程碑完成
3.5 推荐工作流:双终端模式
GSD 官方推荐的工作方式:一个终端跑自动模式,另一个终端随时介入。
终端 1 ------ 让它跑:
bash
gsd
/gsd auto
# 走开去喝杯咖啡
终端 2 ------ 随时干预:
bash
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、定时任务和脚本自动化:
bash
# 在 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 费用自付) |
选型建议:
css
你需要什么? → 选择什么?
──────────────────────────────────────────────────────
长时间自动构建,规格驱动 → 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 编码工具时遇到的"上下文腐烂"经历。