跟 Agent 聊长了，前面定的约定会被聊天记录挤掉，后面写出来的代码开始跑偏。
作者 TÂCHES 不想搞评工时、开站会那套演戏，只要把需求说清楚、把活做完。GSD 要防的，就是别让 Agent 在越聊越乱的对话里写代码。
一、这名字什么意思
早期仓库全称是 Get Shit Done，一句美国口语：别磨叽，把那摊活真正干完。迁到 GSD Core 之后，对外口号改成：
Git. Ship. Done.
提交 → 发出去 → 做完
字母还是 G-S-D。意思没变：留下 Git 记录，发出去，这阶段结束。
二、它到底解决什么问题
GSD 不是一个新模型。它套在 Cursor、Claude Code、Codex 这些工具上。原仓库大约 6.4 万 Star，已经停更；现在装的是 @opengsd/gsd-core（大约 1 万 Star）。你敲斜杠命令，它把研究、规划、写代码、验收交给好几个子 Agent 分头做。
这里说的「上下文」，就是这一轮对话里 Agent 能看到的内容。官方 README 说，项目一大，常见三种翻车：聊得越长质量越差；关掉窗口，下次接着干对不上；写完没人验收是不是真能用。换成日常，就是下面三档。
聊长了会飘。 前 20 分钟还能对方案；聊到后面，刚定的约定被改掉，重复点击该怎么处理忘了，二十条消息前还正确的方法名也被编错。文档把这叫 context rot（上下文腐化）：窗口被聊天记录填满，前面定的规矩越来越管不住后面的输出。
做法是：又长又重的活，另外开一轮干净对话让子 Agent 干；你眼前这个窗口只负责安排。文档里常按大约 20 万 token 的干净窗口来设计，新模型也提到 100 万 token 这一档。这是设计目标，不是你电脑上的保证。Why GSD 说主窗口大概只占三到四成，这是官方说法，我没测过。
关掉窗口、隔夜、换个人接着做，会对不上。 需求只活在聊天里，第二天又要从「这是 Spring Boot，已经有 Redis」讲起。GSD 把进度写成仓库里的文件：
.planning/
PROJECT.md / REQUIREMENTS.md / ROADMAP.md
STATE.md # 做到哪、卡在哪
phases/01-xxx/01-CONTEXT.md # Discuss 里你定下来的选择
phases/01-xxx/01-01-PLAN.md
phases/01-xxx/01-VERIFICATION.md
phases/01-xxx/01-UAT.md # 你按目标亲手验收的结果
跑完一轮大命令，文档建议用 /clear 清空当前对话。隔夜接着干，用 /gsd-progress 看进度，或 /gsd-resume-work 接着做。
写完没验就当完。 比如导出接口返回 200 了、单测也绿了，运营一导全量还是把库拖死。自动检查只能证明文件在、测试跑过。/gsd-verify-work 按阶段目标问你「现在能做什么」，挂了就出修复计划再执行；最后 /gsd-ship 开 PR。Ship 才算这阶段结束。
一次只推进一个阶段：
| 步骤 | 命令 | 干什么 |
|---|---|---|
| Discuss | /gsd-discuss-phase N |
先定下怎么实现 |
| Plan | /gsd-plan-phase N |
调研，拆成能单独跑完的计划 |
| Execute | /gsd-execute-phase N |
按谁先谁后分批跑；每个执行器单独开一轮，看不到你之前的聊天 |
| Verify | /gsd-verify-work N |
对照目标验收 |
| Ship | /gsd-ship N |
开 PR，更新 STATE.md |
三、工作里怎么用
npx @opengsd/gsd-core@latest
# 选 Cursor / Claude Code / Codex …；装到本机全局，或只装当前仓库
用官方安装器，不要自己拷 agents/、commands/ 文件夹。Claude / Cursor 是 /gsd-onboard；Gemini 是 /gsd:onboard；Codex 是 $gsd-onboard；插件安装还可能是 /gsd-core:…。命令对不上，先看自己是怎么装的。
/gsd-new-project # 绿地：从零开始的新项目
/gsd-onboard # 棕地：已经有代码的仓库，GSD Core 现在走这条
/gsd-quick # 改配置、补空指针；产物在 .planning/quick/
/gsd-fast # 改名、补 import、三文件以内的小事
已经有代码的仓库用 onboard 接入。/gsd-map-codebase 还在，只用来重新摸一遍代码结构，不要先 map、再当新项目初始化，两套混用。改个名字、补个 import 用 /gsd-fast；说不清的小功能用 /gsd-quick，别套完整五步。
订单导出（演示）。 Spring Boot，已有 MySQL + Redis，两周内要异步 Excel 导出。Discuss 只先定容易吵起来的点：
? 同步还是异步？ → 小批量同步，大任务进队列
? 文件落哪？ → OSS 临时链接，状态进表 + Redis
? 重复点击？ → 同一组条件算出一个 hash，24 小时内返回同一个 taskId
答案写进 01-CONTEXT.md。后面的计划文件是 Markdown，但每条任务用 XML 标签包起来。这样「改哪些文件、怎么做、怎么验、怎样算完」各占一格，执行器不容易糊成一段。路径换成 Java：
<task type="auto">
<name>导出任务状态机</name>
<files>order-export/ExportTaskService.java</files>
<action>
PENDING / RUNNING / DONE / FAILED。
同一组条件算出一个 hash 当幂等键，24 小时内重复提交回同一个 taskId。
不缓存 Excel 文件本身，只缓存任务状态。
</action>
<verify>同样条件连点两次，返回同一个 taskId</verify>
<done>重复提交不会新建任务，状态变化可以测试</done>
</task>
执行时按谁先谁后分批：任务表和 Redis 键可以一起做，Service 下一波，Controller 和测试最后。每个任务提交一次。挂了对照 01-VERIFICATION.md 再执行，或 /gsd-debug "导出任务一直 PENDING"。
/gsd-new-project --auto @prd.md 是按需求文档初始化项目，不是跳过 Discuss。Discuss 被跳过，或你连说「你定」，后面只是在按它的默认猜测执行。
四、和 OpenSpec、Grill Me
我之前写过 OpenSpec 和 Grill Me。三个工具管的不是同一层：想法还没想清楚，用 Grill Me；这次相对现状改了什么要写进 Git，用 OpenSpec；功能大到要跨好几次对话、越聊越崩，用 GSD。
| GSD | OpenSpec | Grill Me | |
|---|---|---|---|
| 写到哪里 | .planning/ |
openspec/ |
默认不写文件 |
| 最适合 | 跨很多文件、隔夜还要接着做 | 已有项目，把「改什么」写进仓库 | 方案还没定 |
五、缺点
第二节讲的是它能防什么。官方也承认有代价，换成日常说法就是下面这些。
- 慢，费额度。 一阶段要拉研究员、规划器、检查器、执行器，比直接说「写这个接口」多好几轮，Token 也烧得更快。
- 小活套五步亏。 改名、补 import 还走完整五步，手续比收益大。小事用
/gsd-fast，小功能用/gsd-quick。 - 你得回答 Discuss。 连说「你定」，计划再漂亮也是在猜。
.planning/会过期。 不看、不改、不进 PR，子 Agent 读到的还是旧文件，文档反而成了负担。- 命令写法不统一。 原仓库已停更，有的用连字符，有的用冒号，有的用
$，插件还有自己的前缀。两个人安装方式不同，命令就对不上。 - 不适合要走 Jira 那套流程的团队。 如果以后要审计「当时改了什么」，OpenSpec / Spec Kit 更合适。对外介绍写 GSD 或 Git. Ship. Done. 即可。
六、参考内容
- 现维护仓：github.com/open-gsd/gsd-core
- 原仓库（已停更）：github.com/gsd-build/get-shit-done
- 官方文档：docs.opengsd.net
- 上下文腐化与代价：context-engineering.md
- 作者原话：Why GSD
- npm：@opengsd/gsd-core（本文按 1.14.0）