Get Shit Done 深度评测：73k Star 的「上下文工程」系统，真能把事做完？

**一句话总结**：GSD 是一套为 AI 编程代理设计的元提示、上下文工程与规格驱动开发系统。它不写代码——它确保 AI 写的代码是对的。从 context rot（上下文腐烂）这个真实痛点出发，GSD 用 Phase Loop + 子代理编排 + 结构化记忆，把 Claude Code 从「能用但不可靠」变成「能用且可验证」。

基础数据

指标	数值
原仓库	`gsd-build/get-shit-done`
新仓库	`open-gsd/gsd-core`（2026-05 分叉）
Star	64,627（原）+ 8,887（新）= 73,514
Fork	5,456（原）+ 637（新）= 6,093
创建时间	2025-12-14（原）/ 2026-05-22（新）
最新版本	v1.50.0-canary.0（原）/ v1.7.0+（新）
许可证	MIT
语言	JavaScript（TypeScript SDK）
npm 月下载	48,579（原包 `get-shit-done-cc`）
依赖	`@anthropic-ai/claude-agent-sdk`、`ws`
运行时支持	Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、CodeBuddy、Cline
Open Issues	0（原）/ 132（新）

它解决什么问题？

Context Rot：AI 编程的隐形杀手

你用 Claude Code 写一个中等规模项目。一开始效果惊艳——代码干净、逻辑清晰。但随着对话推进，上下文窗口被填满，输出质量开始劣化：

忘记之前的决定
重复已解决的问题
风格不一致
边界条件被忽略

这就是 context rot——上下文腐烂。不是模型变笨了，是它的「工作记忆」被噪音淹没了。

GSD 的核心洞察：不要让 AI 在一个膨胀的上下文里做所有事。把重活（研究、规划、执行）拆到独立的子代理里，每个子代理拿到干净的 200k token 窗口，干完就交回结果。主会话只做协调，保持轻量。

架构设计：Phase Loop

GSD 的核心是 Phase Loop——一个五步循环：

Discuss → Plan → Execute → Verify → Ship
   ↑                                    |
   └────────────────────────────────────┘

1. Discuss（讨论）

在写任何代码之前，先和 AI 讨论实现方案。不是「帮我写个登录页」，而是「我想做一个 OAuth2 流程，支持 Google 和 GitHub，用户数据存 PostgreSQL，你觉得呢？」

这一步生成 .planning/PROJECT.md——项目的「基因文档」。

2. Plan（规划）

研究阶段：派 gsd-phase-researcher 子代理调研技术方案、分析现有代码库、识别依赖关系。

规划阶段：派 gsd-planner 子代理把需求拆解成可执行的 PLAN.md——每个任务有明确的输入、输出、验证标准。

检查阶段：派 gsd-plan-checker 子代理审查计划质量，最多 3 轮修订循环。

3. Execute（执行）

把 PLAN.md 里的任务按依赖关系分组，每组并行执行：

Wave 1: [Task A] [Task B] [Task C]  ← 无依赖，并行
Wave 2: [Task D] [Task E]           ← 依赖 Wave 1，等它完成
Wave 3: [Task F]                    ← 依赖 Wave 2

每个执行器（gsd-executor）在独立的 worktree 里工作，互不干扰。完成后提交代码，生成 SUMMARY.md。

4. Verify（验证）

派 gsd-verifier 子代理检查：

代码是否符合计划
测试是否通过
是否引入回归
文档是否更新

不通过？生成修复计划，回到 Execute。

5. Ship（发布）

创建 PR，归档阶段，开始下一个 Phase。

核心能力拆解

1. 子代理编排（Subagent Orchestration）

GSD 有 33 个专用子代理，每个都有明确的职责边界：

代理	职责
`gsd-executor`	执行计划任务，提交代码
`gsd-verifier`	验证阶段完成度
`gsd-planner`	从需求创建详细计划
`gsd-phase-researcher`	调研技术方案
`gsd-plan-checker`	审查计划质量
`gsd-debugger`	诊断和修复问题
`gsd-codebase-mapper`	映射项目结构
`gsd-code-reviewer`	代码审查
`gsd-ui-researcher`	UI/UX 方案调研
`gsd-security-auditor`	安全审计

每个子代理都有自己的「合约」（agent contracts）——明确它能读什么、能写什么、不能做什么。这防止了子代理越界操作。

2. 结构化记忆（Structured Memory）

GSD 用文件系统做「记忆」，而不是依赖上下文窗口：

.planning/
├── PROJECT.md          # 项目基因
├── REQUIREMENTS.md     # 需求文档
├── ROADMAP.md          # 路线图
├── STATE.md            # 项目状态（跨会话记忆）
├── config.json         # 工作流配置
└── phases/
    └── 01-phase-name/
        ├── CONTEXT.md   # 阶段上下文
        ├── RESEARCH.md  # 调研报告
        ├── PLAN.md      # 执行计划
        ├── SUMMARY.md   # 执行摘要
        └── VERIFICATION.md  # 验证报告

STATE.md 是关键——它记录了项目的所有决策、当前进度、已知问题。新会话开始时，先读 STATE.md，立刻恢复上下文。这解决了「会话断裂」问题。

3. 门控机制（Gate System）

每个阶段转换都有门控（gates）：

Phase 状态门：Complete 状态的阶段不能随意重规划（除非 --force）
验证门：验证不通过不能 Ship
构建门：自动检测构建系统（Xcode、Makefile、Cargo、Go、Python、npm）
提交门：所有变更必须通过测试才能提交

4. 上下文预算管理（Context Budget）

GSD 智能管理上下文窗口：

大窗口（≥500k）：加载更丰富的上下文，包括历史阶段的 CONTEXT.md 和 SUMMARY.md
小窗口（<200k）：精简提示，把示例和边缘案例移到按需加载的参考文件
最小安装：--minimal 模式只装 6 个核心技能，冷启动从 ~12k token 降到 ~700 token（≥94% 减少）

5. 多运行时支持

GSD 不绑定 Claude Code。它支持 13+ 个 AI 编程运行时：

Claude Code：原生支持，子代理通过 Agent() 调用
Codex：通过 $gsd-* 命令调用
Copilot：降级为顺序执行（子代理完成信号不可靠）
Cursor/Windsurf：通过 .cursor/ 目录安装
Cline：通过 .clinerules 安装

67 个命令：全景扫描

GSD 提供 67 个命令，覆盖项目全生命周期：

核心循环（6 个）

/gsd:new-project — 初始化新项目
/gsd:discuss-phase — 讨论阶段方案
/gsd:plan-phase — 规划阶段
/gsd:execute-phase — 执行阶段
/gsd:help — 帮助
/gsd:update — 更新 GSD

项目管理（15 个）

/gsd:new-milestone — 创建新里程碑
/gsd:complete-milestone — 完成里程碑
/gsd:progress — 查看进度
/gsd:stats — 统计信息
/gsd:health — 健康检查
/gsd:import — 导入现有项目
/gsd:onboard — 接入现有代码库

执行辅助（20 个）

/gsd:execute-phase --wave N — 执行特定波次
/gsd:validate-phase — 验证阶段
/gsd:verify-work — 验证工作
/gsd:code-review — 代码审查
/gsd:add-tests — 添加测试
/gsd:debug — 调试会话
/gsd:forensics — 问题取证

规划辅助（15 个）

/gsd:sketch — 快速草图
/gsd:spike — 技术探针
/gsd:explore — 探索性开发
/gsd:ultraplan-phase — 超级规划
/gsd:mvp-phase — MVP 模式
/gsd:spec-phase — 规格阶段

工作区（11 个）

/gsd:workspace — 工作区管理
/gsd:workstreams — 工作流管理
/gsd:pr-branch — PR 分支
/gsd:ship — 发布
/gsd:undo — 撤销

安装体验

npx get-shit-done-cc@latest

安装器会问你：

用哪个运行时？（Claude Code / Codex / Cursor / …）

全局安装还是本地安装？

安装完成后，验证：

# Claude Code
/gsd-help

# Codex
$gsd-help

推荐配置：跳过权限确认模式

claude --dangerously-skip-permissions

GSD 的设计目标是无摩擦自动化，频繁的权限确认会打断工作流。

实际使用场景

场景 1：从零构建 SaaS

/gsd:new-project "构建一个 AI 写作助手 SaaS"
→ 生成 PROJECT.md、REQUIREMENTS.md、ROADMAP.md

/gsd:plan-phase 1
→ 研究技术栈，拆解 Phase 1（用户认证）

/gsd:execute-phase 1
→ 并行执行 5 个计划，每个在独立 worktree

/gsd:verify-phase 1
→ 验证通过，创建 PR

/gsd:ship
→ 合并，开始 Phase 2

场景 2：接入现有项目

/gsd:onboard
→ 分析现有代码库，生成 PROJECT.md 和 STATE.md

/gsd:plan-phase 1
→ 规划第一个改进阶段

/gsd:execute-phase 1
→ 执行，不破坏现有功能

场景 3：紧急修复

/gsd:debug "用户报告登录偶尔失败"
→ 派 gsd-debugger 诊断，生成修复计划

/gsd:execute-phase "hotfix"
→ 执行修复

/gsd:verify-phase "hotfix"
→ 验证修复有效

与类似工具对比

维度	GSD	Ponytail	rtk	caveman	BMAD
定位	全流程项目管理	代码精简指令	快速原型	文本压缩	企业级敏捷
Star	73k+	115k	~5k	10k+	~20k
核心机制	Phase Loop + 子代理	7 级懒人阶梯	单文件指令	洞穴人风格	故事点+冲刺
上下文管理	STATE.md + 子代理隔离	无	无	无	Jira
验证机制	gsd-verifier + 门控	安全阀	无	无	UAT
多运行时	13+	Claude Code only	Claude Code	Claude Code	Claude Code
复杂度	高（67 命令 + 33 代理）	低（~100 行）	低	极低	高
适用场景	中大型项目	过度工程防护	快速想法验证	文本输出	团队协作
学习曲线	陡峭	平缓	平缓	极平缓	陡峭
Token 成本	高（多代理）	低	低	极低	高

关键差异

GSD vs Ponytail：

Ponytail 是「减法」——防止过度工程
GSD 是「加法」——提供完整项目管理框架
两者互补：GSD 管流程，Ponytail 管代码风格

GSD vs rtk：

rtk 是「快速原型」——一个文件搞定
GSD 是「完整项目」——从需求到发布
rtk 适合 hackathon，GSD 适合产品开发

GSD vs caveman：

caveman 是「文本压缩」——省 token
GSD 是「上下文管理」——省认知负担
可以叠加：用 GSD 管项目，用 caveman 压缩输出

优点

1. 解决真实痛点

Context rot 是 AI 编程的头号杀手。GSD 的子代理隔离 + 结构化记忆是正解。

2. 工程化程度极高

33 个专用子代理，每个有明确合约
门控系统防止状态混乱
上下文预算自适应管理
多运行时兼容层

3. 可验证性

每个阶段都有 VERIFICATION.md，不是「写完就算」，而是「写完+测完+审完才算」。

4. 社区活跃

73k+ Star，48k 月下载，Discord 社区，频繁更新（v1.50.0）。

5. MIT 许可

完全开源，可以自由修改和分发。

缺点

1. 学习曲线陡峭

67 个命令 + 33 个代理 + 复杂的工作流配置。新手需要花时间理解 Phase Loop、子代理编排、门控机制。

2. Token 成本高

每个阶段要派多个子代理，每个子代理都有独立的上下文窗口。一个 Phase 可能消耗数百万 token。

3. 过度工程风险

对于小项目（<1000 行代码），GSD 的仪式感可能超过价值。「讨论→规划→执行→验证→发布」五个步骤，可能只需要「写→测→发」。

4. 依赖 Node.js 22+

安装器需要 Node.js 22+，对某些环境不友好。

5. 仓库分裂

原仓库 gsd-build/get-shit-done 已标记 deprecated，新仓库 open-gsd/gsd-core 正在活跃开发。但 npm 包名还是 get-shit-done-cc，文档链接混乱。

评分

维度	分数	说明
功能完整度	9.5/10	从需求到发布的全链路覆盖，67 个命令几乎无死角
设计深度	9/10	Phase Loop + 子代理编排 + 门控系统 + 上下文预算，工程化程度极高
文档质量	8/10	中文 README 完善，但仓库分裂导致链接混乱
安装便捷度	7/10	一行命令安装，但 Node.js 22+ 要求和多运行时选择增加复杂度
中文友好度	8/10	官方中文 README，社区有中文讨论
实际效果	8.5/10	大型项目效果显著，小型项目过度工程
社区活跃度	9/10	73k+ Star，频繁更新，Discord 活跃
综合评分	8.5/10

适用场景推荐

✅ 强烈推荐

中大型项目（>5000 行代码）
多人协作项目
需要长期维护的产品
从零构建 SaaS
接入现有代码库进行重构

⚠️ 谨慎使用

小型项目（<1000 行代码）
快速原型/hackathon
一次性脚本
学习/探索性编程

❌ 不推荐

纯文本输出（用 caveman）
过度工程防护（用 Ponytail）
快速想法验证（用 rtk）

安装建议

如果你决定试试 GSD：

# 1. 确保 Node.js 22+
node --version

# 2. 安装 GSD
npx get-shit-done-cc@latest

# 3. 选择运行时和安装位置

# 4. 验证
/gsd-help

# 5. 开始第一个项目
/gsd:new-project "你的项目想法"

推荐配置：

使用 --minimal 安装（如果你的上下文窗口 <200k）
启用 --dangerously-skip-permissions（如果安全允许）
从 /gsd:onboard 开始（如果接入现有项目）

结语

GSD 不是「让 AI 写代码更快」的工具——那是 Cursor Copilot 的活。GSD 是「让 AI 写的代码更可靠」的系统。

它用工程化的方法解决了 AI 编程的核心问题：上下文管理。子代理隔离、结构化记忆、门控验证——这些不是花哨的功能，是让 AI 从「能用」到「可用」的基础设施。

73k+ Star 不是偶然。当 AI 编程从「玩具」变成「工具」，你需要的不是更快的生成速度，而是更可靠的质量保证。GSD 做到了这一点。

但记住：它不是银弹。小项目用 GSD 是杀鸡用牛刀。选择工具要看场景，不是看 Star 数。

评测时间：2026-08-30

数据来源：GitHub API、npm、官方文档

作者：Minis