Claude Code生态最强框架GSD万字深度实测：不写代码也能拿下35000颗星,到底烧Token还是真神器？
“I’m a solo developer. I don’t write code — Claude Code does.”
一个完全不会写代码的人，却做出了整个 Claude Code 社区争议最大的工程框架。
如果你在 Claude Code 的世界里待得足够久，一定听过 GSD（Get Shit Done）这个名字。
GitHub 上 35000+ Star，npm 周下载量过万，Reddit 和 Hacker News 上永远吵成一锅粥——有人用它从零搭出完整 SaaS 产品并成功上线，也有人痛骂烧了一周 API 额度只产出了 500 行代码。
今天这篇文章，我不想列功能清单。咱们坐下来好好聊聊：这个框架到底解决了什么痛点，为什么评价会这么撕裂，以及——它究竟适不适合你。
不会写代码的人，却造出了最强框架
GSD 的作者叫 Lex Christopherson，网名 TACHES，GitHub 上叫 glittercowboy。他的自我介绍特别有意思：“House music producer & AI guy”——一个做电子音乐的，硬是搞出了 Claude Code 社区最复杂的工程化框架。
他的起点很简单：他自己完全不写代码，一切开发都交给 Claude Code。但在重度使用过程中，他撞上了一个要命的问题——上下文腐败（Context Rot）。
什么是上下文腐败？
你跟着 Claude Code 密集聊了两个小时后，上下文窗口眼看就要被塞满。这时候你能明显感觉到，Claude 产出的代码质量在滑坡——开始敷衍、省略错误处理、跳过边界情况。不是模型突然变蠢了，而是它一次要记住的东西太多，注意力已经涣散了。
就像你让一个人同时牢记 50 件事，还要求他写出一篇好文章——根本不可能。
Lex 的应对方案暴力但极其有效：绝不让单个 Agent 扛下所有工作，每项子任务都给一个全新的 200K 上下文窗口。
主会话永远把上下文使用率控制在 30%-40% 之间，只要是重活、累活统统派给子 Agent 去干。子 Agent 干完就把结果写回文件系统，主会话只需要读一下摘要。
这就是 GSD 最核心的设计哲学。
六步工作流：不是玩具，是一条严肃的工程流水线
GSD 绝不是那种“一键搞定”的玩具，它的完整工作流极像一条工业化组装线。
第一步：/gsd-new-project — 项目初始化
一条命令下去，GSD 会同时拉起 4 个研究 Agent 并行开工：
- • 一个深入研究技术栈
- • 一个拆解功能特性
- • 一个分析架构模式
- • 一个摸排常见陷阱
四个 Agent 各自带着干净的上下文工作，结束时汇总成 REQUIREMENTS.md（需求文档）、ROADMAP.md（路线图）和 PROJECT.md（项目愿景）。
第二步：/gsd-discuss-phase N — 需求讨论
GSD 会像一位老练的产品经理那样跟你“聊需求”。它会主动识别你描述里的灰色地带——比如“做一个好看的落地页”，什么叫好看？要哪种风格？给谁看？
刚开始我特别不习惯这种追问，后来才明白——项目越复杂，这个环节就越值钱。跳过讨论直接开干，大概率得返工。
第三步：/gsd-plan-phase N — 制定计划
先派出研究 Agent 做技术调研，再由规划 Agent 制定 2-3 个原子化的执行计划。每个计划都是 XML 结构的任务清单，附依赖关系图。
更妙的是，GSD 内置了计划检查器——规划 Agent 出稿后，检查器 Agent 会进行全面审查，一旦发现漏洞就退回重写，最多迭代 3 轮。
第四步：/gsd-execute-phase N — 执行
这里是 GSD 最硬核的环节。执行并不按顺序推进，而是波次并行的：
第 1 波（并行）: 任务 A + 任务 B（无依赖）
第 2 波（并行）: 任务 C（依赖A） + 任务 D（依赖B）
第 3 波: 任务 E（依赖 C + D）
每个任务由独立的执行 Agent 完成，拥有干净的上下文窗口。每完成一个任务，自动创建一个 git commit——原子化提交，完整可追溯。
第五步：/gsd-verify-work N — 验证
做完不等于做好了。GSD 的验证 Agent 会提取可测试的交付物，逐条核对。一旦发现问题，自动生成修复计划。
第六步：/gsd-complete-milestone — 收尾
归档里程碑，打上 Release Tag，准备进入下一个迭代。
快捷命令 /gsd-next 可以自动检测你当前处于哪一步，然后直接执行下一步。
为什么有人爱它爱到不行，有人恨得牙痒？
这是我这篇文章最想展开的部分。同样一个工具，视角不同，结论可能完全相反。
热爱它的人怎么说
Hacker News 上有一位用户，用 GSD 从零搭出完整 SaaS 产品 whiteboar.it 并成功上线：
“GSD consistently gets me 95% of the way there on complex tasks. That’s amazing. The last 5% is mostly manual testing.”
另一位用户用 GSD + Codex 做了一个 macOS 原生应用，已经在考虑上架 App Store：
“I got sick of paying FreshBooks monthly for basic income/expense tracking. Used GSD to build a macOS Swift app. It’s working great.”
还有一个让我格外印象深刻的案例：一位零 App 开发经验的系统工程师，用 GSD 不到一个月产出了一个约 250K 行代码的 VPN 管理平台，包含 TypeScript 后端和 SwiftUI 的 iOS/macOS 客户端，支持多云部署。
LinkedIn 上还有人做了量化测试：原本需要 2-3 天的工作量，用 GSD 压缩到了 8 小时。
痛恨它的人怎么说
批评的声音同样毫不留情。
最常见的槽点：太烧 Token 了。
“I burned literally a week’s worth of the $20 worth of API credits on GSD. To get like 500 LOC.”
“Just tried GSD and Plan Mode on the same exact task. Plan Mode had a plan and then base implementation in twenty minutes. GSD ran for hours to achieve the same thing.”
也有人抱怨它过于沉重：
“It was incredibly verbose, generating an insane amount of files. I stopped using it because I was worried it would not be possible to rapidly, cheaply, and robustly update things.”
甚至有人直接调侃它的名字：
“Required far too much back and forth. Ate too many tokens. It should be called planning-shit instead.”
这些批评全部真实存在，绝不是黑子。我认真分析后觉得，根源在于 GSD 的架构设计——它用 4 个 Token 做协调，1 个 Token 写代码。对于简单任务，这个开销比确实太离谱；但对于复杂项目，这种开销恰恰就是质量的保障。
GSD vs Superpowers vs BMAD：三方横向对比
Claude Code 社区当下最火的三套工程化框架，我整理了一个简单对比：
| 维度 | GSD | Superpowers | BMAD |
|---|---|---|---|
| 核心思路 | 控制上下文环境 | 控制编码流程 | 控制开发仪式 |
| 哲学 | 每个任务干净上下文 | 强制 TDD 流水线 | 企业级故事点 |
| 适合谁 | 独立开发者、非程序员 | 有工程经验的开发者 | 团队协作 |
| Token 开销 | 高（多 Agent 协调） | 中等 | 高 |
| 上手难度 | 中等 | 低 | 高 |
| 灵活性 | 较低（瀑布式流程） | 高 | 低 |
| 最佳场景 | 大型从零项目 | 增量开发 | 企业项目 |
Medium 上有一篇对比文章总结得非常到位：Superpowers 约束的是 AI“怎么写代码”，GSD 约束的是 AI“在什么条件下写代码”，gstack 约束的是 AI“以什么角色写代码”。
我个人的建议：如果你是独立开发者，准备做一个完整产品，请用 GSD。如果你是工程师想在日常开发中提效，请用 Superpowers。如果你是技术 Leader 要管团队，不妨看看 BMAD。
快速上手指南
讲了这么多理论，如果你决定给 GSD 一次机会，三步就能跑起来。
1. 安装
npx get-shit-done-cc@latest
安装器会询问你装在哪个运行时（Claude Code / Cursor / Windsurf / Codex 等），以及是全局安装还是仅当前项目。
如果要在 CI 环境非交互式安装，可以这样：
npx get-shit-done-cc --claude --global
2. 验证
/gsd-help
看到帮助信息就表示安装成功了。
3. 开始使用
# 新建项目
/gsd-new-project
# 接着一路下一步
/gsd-next
几个实用命令
| 命令 | 作用 |
|---|---|
/gsd-quick |
快速模式，绕过完整流水线处理小任务 |
/gsd-progress |
查看当前项目进度 |
/gsd-resume-work |
恢复上次中断的工作 |
/gsd-health |
检查项目健康状态 |
/gsd-debug "描述" |
用科学方法论进行调试 |
/gsd-code-review N |
对第 N 阶段做代码审查 |
五条发自内心的建议
在 AI 编程工具里泡了这么久，我攒下了几条关于 GSD 的真实体会。
第一，别拿 GSD 去改 bug 或调样式。 它的设计初衷是管理复杂项目。你要是用它修个按钮颜色，就像开航母去钓鱼——不是钓不到，但油钱会心疼死你。
第二，千万不要跳过 discuss 阶段。 GSD 最常被吐槽的就是“聊太多”，但数据不会骗人：跳过讨论的项目，返工率是不跳过的 2-3 倍。那些批评 GSD 是在“planning-shit”的人，很多恰恰就是跳过了讨论之后得到了不理想的结果。
第三，提前备好 Token 预算。 GSD 的协调开销是实打实的。Pro 计划根本不够用，Max 计划（$100-200/月）才是起步价。如果你用的是按量计费的 API，更要做好心理准备。
第四，大项目上 GSD，小任务用 /gsd-quick。 框架自带的快速模式可以绕过完整流水线，特别适合几十分钟就能搞定的琐事。
第五，先拿一个小项目练手。 绝对不要一上来就拿 GSD 做你的核心业务。找个 side project 完整走一遍流程，感受一下节奏，再决定是否主力采用。
你到底适不适合用 GSD
你可能很适合，如果：
- • 你是独立开发者，想从零搭建一个完整产品
- • 你不太会写代码，但脑子里有个很棒的产品想法
- • 你的项目超过 50 个文件，每次改代码都胆战心惊
- • 你受够了 Claude Code 写到后半段代码质量断崖式下跌
- • 你需要可追溯、原子化的 git 提交历史
你可能不适合，如果：
- • 你只是偶尔让 AI 帮忙写几行小代码
- • 你的项目很小，几页代码就完事
- • 你预算吃紧，不想在 Token 上投入太多
- • 你喜欢灵活机动的开发方式，受不了瀑布式的仪式感
- • 你是资深工程师，直接用 Plan Mode 效率反而更高
写在最后
GSD 是一个态度极其鲜明的工具。它的作者 Lex 从一开始就没想过要做一个“万能框架”——他追求的，是一套能让完全不懂代码的人也能持续交付高质量软件的系统。
这个目标他做到了。代价是 Token 开销、是等待的时间、是流程中满满的仪式感。
有人说这些框架终究是过渡品，未来模型足够强大了就没人需要了。我部分同意。但在 2026 年的今天，如果你真的想在 Claude Code 上做严肃的项目开发，GSD 仍然是当下最成熟的选择之一。
不是因为它完美，恰恰是因为它解决了真实存在的问题。
项目地址： github.com/gsd-build/get-shit-done
安装命令： npx get-shit-done-cc@latest
Discord 社区： 项目 README 中可获取邀请链接