一句话总结
GSD 不是单纯再包一层 Claude Code，而是把「长任务容易聊烂、上下文越跑越脏」这个老问题，拆成了一套能持续推进的大任务流水线。
最近看到这个项目突然刷屏，第一眼很多人会把它理解成“又一个 AI coding 包装层”。但我认真看完之后，感觉它更像是在补一个很多人已经踩过、但一直没被系统解决的坑：任务一长，Agent 就开始掉状态。
01. 先看一张信息卡
| 项目 | 内容 |
|---|---|
| 名称 | GSD / Get Shit Done |
| GitHub | https://github.com/gsd-build/get-shit-done |
| 官网 / 文档 | https://getshitdone.run |
| 适用对象 | Claude Code、OpenCode、Gemini CLI 等多种 AI coding 工具用户 |
| 核心用途 | 把复杂长任务拆成多 Agent、多阶段、可验证的执行流 |
| 最直接收益 | 减少上下文腐烂，降低任务越做越乱、越聊越偏的情况 |
| 适合谁 | 经常让 AI 写代码、做调研、搭产品、跑复杂工作流的人 |
| 当前热度 | 文中提到开源 5 天 5 万 Star，已是近期非常夸张的传播速度 |
重点不是“功能堆更多”，而是让复杂任务在更长链路里还能保持稳定输出。
02. 它到底解决了什么问题？
说白了，GSD 盯上的就是一个大家都很熟、但平时只能硬扛的问题：上下文腐烂（Context Rot）。
任务短的时候，Claude Code 这类工具很好用；但一旦开始做多阶段需求，比如：
- 从零搭一个产品
- 边调研边写代码边验证
- 一个需求拆成前后端、接口、验收多个部分
- 需要连续几十轮以上才能完成的复杂任务
就很容易出现几个典型症状：
- 回答越来越短
- 关键要求开始漏
- 前面说过的话后面忘掉
- 逻辑开始漂移
- 主对话窗口越来越脏，越跑越不敢继续加需求
GSD 的价值就在这：它不是要求一个 Agent 从头扛到尾，而是把整个过程拆开，让不同 Agent 在新的、干净的上下文里分段执行。
03. 它是怎么起作用的？
它的核心机制，我看下来主要有 4 个层次。
-
第一层：任务拆解。
不是一股脑把需求塞给一个对话窗口，而是先拆成可执行的小任务。 -
第二层：角色分工。
会把工作分给不同职责的 Agent，比如研究员、规划师、执行者、验证者。 -
第三层：分 Wave 并行推进。
没依赖的任务可以一起跑，有依赖的放到后面的 Wave，效率会比串行硬做高很多。 -
第四层：结构化执行指令。
它不是只给一句自然语言任务，而是用接近 XML 的结构把文件路径、动作、验证标准、完成条件都写清楚。
这件事的意义很大。
因为很多时候 AI 不是不会做，而是任务边界不清、验收标准不清、上下文已经脏了。GSD 相当于把这三件事一起补上了。
文里给的一个例子就挺典型：
<task type="auto">
<name>创建登录接口</name>
<files>src/app/api/auth/login/route.ts</files>
<action>用 jose 库做 JWT（别用 jsonwebtoken，有 CommonJS 兼容问题）。验证用户凭据。成功后返回 httpOnly cookie。</action>
<verify>curl 请求登录接口返回 200 + Set-Cookie</verify>
<done>有效凭据返回 cookie，无效凭据返回 401</done>
</task>
这种写法最直接的好处就是：AI 不太需要猜你的意思。
04. 最值得借鉴的亮点是什么？
如果只挑一个最有记忆点的地方，我会选：它把“主窗口保持干净”这件事，做成了工作流默认值。
这个点其实比“多 Agent”本身还重要。
因为很多人现在已经知道可以多开 Agent、可以并行、可以拆任务，但真正难的是：
- 谁来拆
- 怎么拆才不乱
- 跑完怎么验证
- 中途暂停后怎么续上
- 项目状态怎么沉淀下来
GSD 把这些都放进了一套连续命令里，比如文中提到的：
/gsd-new-project/gsd-discuss-phase 1/gsd-plan-phase 1/gsd-execute-phase 1/gsd-verify-work 1/gsd-pause-work/gsd-resume-work/gsd-quick/gsd-next
本质上，它在做的不是“多一个命令集”，而是把复杂任务的推进顺序标准化了。
另外一个亮点是状态管理。
它会持续维护项目愿景、需求、路线图、决策记录、阻塞项和完成项。这个设计很像给 Agent 配了一套“项目脑子”，所以你中断之后再回来，不至于每次都从头热身。
05. 实际使用里要注意什么？
这个项目很强，但也不是没有代价。
我觉得至少有 4 个现实注意点：
-
它更适合复杂任务，不一定适合所有小活。
如果只是改一个按钮文案、修一个很小的 bug，直接用原生 Claude Code 可能更快。 -
自动化越强，权限和验证越重要。
文里提到 Claude Code 下推荐配合claude --dangerously-skip-permissions。这确实能减少频繁确认，但也意味着你要更清楚它实际会执行什么。 -
前期定义越清楚，后面收益越大。
这类系统不是“你说一句它就自动神奇完成”，而是更像把你的任务管理方法工程化。前面信息给得含糊，后面一样会偏。 -
它解决的是长程协作问题，不是替你判断业务对错。
拆得更清楚、执行得更稳定，不代表需求本身就是对的，所以验收和决策这层仍然要人来盯。
06. 最后一句话
如果你已经明显感觉到：AI 在短任务里很好用，但一到复杂任务就开始“越聊越乱、越跑越虚”，那 GSD 值得看一眼。它真正有价值的地方，不是又造了一个 Agent，而是把复杂任务该怎么持续推进这件事，终于做得更像工程系统了。