上一篇写了 agent-skills。它解决了一个问题：AI 不按工程流程做事。
还有一个更深的问题它解决不了：
AI 写着写着就忘了。
在一个对话里连续做几个小时，上下文被越塞越满，代码质量肉眼可见地下降。前面定好的架构忘了，约束不遵守了，同样的错误反复出现。
这个问题叫 context rot，GSD 就是为了解决它。
GSD 是什么
GSD（Get Shit Done）是一个元提示框架，给 Claude Code、Gemini CLI、Codex 这些 AI 编程工具用。
它在 GitHub 上开源（gsd-build/get-shit-done），58K+ stars，作者是 TÂCHES。
核心思路就一句话：别在一个对话里干完所有活。每个任务启动一个独立的 agent，给它干净的上下文。
你想想平时用 AI 写代码的场景，讨论需求、写代码、修 bug、review，全在一个窗口里。对话越长，模型能注意到的东西越少，质量就开始下滑。GSD 的做法是把项目拆成阶段，每个阶段启动独立的 agent，每个 agent 都有新鲜上下文，做完就走，不留脏状态。
项目状态存在 .planning/ 目录里，agent 之间靠文件系统传递信息。没有数据库，没有服务器，全是 Markdown 和 JSON，可以 git 追踪。
工作方式
先说几个核心概念。
规划目录 .planning/ 是项目的”单一真相源”。PROJECT.md 写愿景和约束，REQUIREMENTS.md 管理需求，每个需求有 ID 如 AUTH-01，ROADMAP.md 拆阶段和追踪进度，STATE.md 是活记忆，记录当前做到哪了、有什么 blockers。
阶段 是基本单位，用整数编号（1, 2, 3）。紧急插入的工作用小数编号（2.1, 2.2）。几个阶段组成一个里程碑，比如 v1.0 MVP 包含 Phase 1-4。完成一个里程碑后归档，保持 ROADMAP 可读。
日常使用就是一条开发循环：
/gsd-new-project # 新建项目，引导式创建，自动生成需求文档和路线图/gsd-discuss-phase 1 # 讨论阶段实现偏好，生成上下文/gsd-plan-phase 1 # 研究 + 规划，生成任务拆分/gsd-execute-phase 1 # 执行，生成代码/gsd-verify-work 1 # 验收/gsd-next # 推进到下一阶段每一步都有专门的 agent 负责，各自拿独立上下文。Plans 按依赖关系分组，同一组内可以并行执行。
质量上有四层门控：执行前检查 → 结果审查 → 问题升级 → 中止。不是跑完就完事，有验证环节。
具体怎么用
GSD 的命令有 50 多个，但日常开发只需要记住几条主线。
从零开始一个新项目
这是 GSD 最标准的用法。
/gsd:new-project它会引导你走一遍：项目愿景、核心需求、技术选型，最后自动生成 PROJECT.md、REQUIREMENTS.md 和 ROADMAP.md。不需要你手动建目录写文档。
之后就是按阶段推进：
/gsd:discuss-phase 1 # 先讨论 Phase 1 的实现偏好，生成上下文/gsd:research-phase 1 # 研究怎么实现，查文档、看最佳实践/gsd:plan-phase 1 # 研究完再拆任务，生成 PLAN.md/gsd:execute-phase 1 # 按计划执行，写代码/gsd:verify-work 1 # 验收，对照目标检查有没有漏/gsd:add-tests 1 # 可选，给完成的 phase 生成测试/gsd:next # 自动跳到 Phase 2，循环开始每个命令都是一个独立 agent，带着自己那部分的上下文跑。Phase 1 的 agent 不知道 Phase 2 的存在，Phase 2 的 agent 也不需要读 Phase 1 的整个对话记录，它只需要读 .planning/ 里产出的文档。
research-phase 这一步容易被跳过，但很关键。它会让一个专门的研究 agent 去查官方文档、看最佳实践，把调研结果写进 phase 目录，后面的 planning agent 和 executor agent 直接消费这些结论，而不是自己重新猜。
verify-work 也不是走过场。它会对照 phase 的原始目标做 goal-backward 分析，检查代码库是否交付了 phase 承诺的东西，不只是检查任务有没有标记完成。
不想一步步走
/gsd:autonomous告诉它你的目标，它会自动跑完剩余所有阶段。适合你已经有过几个 phase 的手动经验、对 GSD 的节奏有感觉了之后用。跑完它会给你一份 session report。
已有项目，想快速做事
不需要立项、拆 phase 的场景，用轻量命令：
/gsd:fast "帮我看一下这个函数的性能问题"/gsd:quick "给这个模块加单元测试"fast 完全不走 phase 流程，纯 inline 执行。quick 走 GSD 的质量护栏但不拆 phase。fast 更轻，quick 多一层保障。
不知道下一步该干什么
/gsd:progress # 看当前进度，ROADMAP 做到哪了/gsd:stats # 看项目统计，几个 phase、几个任务、完成率/gsd:check-todos # 看待办列表，选一个来做/gsd:health # 检查 .planning/ 目录状态有没有异常遇到 bug
/gsd:debug系统化 debug，走”复现 → 定位范围 → 缩小变量 → 修复根因 → 加 guard”这条链。不像普通 AI debug 那样想到哪改到哪。
严重故障用：
/gsd:forensics事后调查，找出失败根因，类似 post-mortem。
暂停和恢复
/gsd:pause-work # 暂停时生成上下文交接文档/gsd:resume-work # 下次回来直接恢复，不需要重新描述上下文这条链是 context rot 防护的关键一环。项目跨度几天的话，每次回来新 agent 都有完整的交接信息，不需要你重新讲一遍。
想法和 backlog 管理
随时有想法，先记下来再说：
/gsd:note # 零摩擦记录想法/gsd:add-todo # 记成待办，后续可以选来做/gsd:add-backlog # 丢进 backlog 停车场/gsd:plant-seed # 记一个前瞻性的想法/gsd:review-backlog # 回顾 backlog，把合适的提升为 phase不是所有想法都要立刻进 phase。先 parking，后续 review 再决定做不做。
分析现有代码
/gsd:map-codebase并行分析现有代码库，输出结构化的技术架构、架构设计、代码质量分析。接手老项目或者在做 phase plan 之前用。
多工作区并行
/gsd:new-workspace # 创建隔离工作区，带依赖关系/gsd:list-workspaces # 看所有活跃工作区/gsd:pr-branch # 把工作区状态过滤成干净的 PR 分支/gsd:remove-workspace# 清理工作区适合一个项目里有多条线并行推进的场景。
安装
npx get-shit-done-cc@latest装完验证：
/gsd-help出帮助信息就对了。
支持 14 种运行时：Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Qwen Code、Cline、CodeBuddy。
和 agent-skills 的关系
上一篇介绍 agent-skills，这篇介绍 GSD，很多人会问：两个都要用吗？
它们有重叠，但定位不同。
agent-skills 是任务级的，让你在当前对话里调用一个具体技能：写测试、review 代码、修 bug。它不负责管理项目状态，也不管上下文多长。
GSD 是全链路的，从一个项目立项开始，拆分阶段，每个阶段启动独立 agent 执行。它管状态、管质量门控、管上下文隔离。
选型建议： 从零开始做一个有明确边界的项目，用 GSD。在已有项目里做具体事情，用 agent-skills。两者不冲突，可以一起用：GSD 管大框架，agent-skills 管具体技能。
什么时候该用
大多数 AI 编程工具用户都遇到过一个场景：AI 写到一半开始遗忘约束、违反架构、重复犯错，这种场景下 GSD 的价值最直接。
独立开发者也适合。一个人做项目很容易没有结构，把需求、决策、进度全散落在对话里。GSD 的规划目录把这些都沉淀成可追踪的文档。
团队也用得上。底层模型可以换，但项目状态和执行流程可以沉淀下来，新 agent 进来就能接上之前的进度。
局限
GSD 不轻量。.planning/ 目录、阶段规划、多 agent 编排，对一个”帮我看一段代码”的小需求来说太重了。它的最佳场景是”从零开始构建一个有明确边界的项目”。
另外每个 phase 都启动新 agent，token 消耗比单一对话高。大型项目里这个投入值得，小项目自己权衡。
最后
context rot 是被严重低估的问题。大多数人遇到 AI 写到一半变笨，第一反应是换模型。但 GSD 给出的解法是，问题不在模型，在上下文管理的方式。
用一个 orchestrator 管一组短命 worker agent，每个都有干净上下文，这个模式值得更多关注。如果你也遇到过 AI 写着写着就开始跑偏的情况，值得一试。