**一句话总结**：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-permissionsGSD 的设计目标是无摩擦自动化，频繁的权限确认会打断工作流。
实际使用场景
场景 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