GSD（Get-Shit-Done）使用指南(让你的AI当包工头,而不是抽奖机)

zhou94
274 阅读12分钟

给 Claude Code 用的「规格驱动开发 + 上下文工程」工作流系统。 仓库：github.com/gsd-build/g…

0. 为什么要用 GSD？

0.1 你大概率经历过的"AI 编程翻车现场"

先说几个画面，看看眼熟不：

  • 场景一：聊到第 30 轮，AI 突然失忆。 早上你信誓旦旦交代了"用 pinia 不要 vuex"，到下午它热情洋溢给你写了一坨 mapState。你愣了五秒，怀疑自己是不是说梦话说出去的。

  • 场景二：它写得飞快，你审得想哭。 一个 prompt 砸下去，它噼里啪啦改了 23 个文件。你点开 diff，发现它顺手帮你"优化"了和这个需求八竿子打不着的三个模块，理由是"看起来更整洁"。

  • 场景三：「重写一下，这次更简洁点」之后的灾难。 改完发现 bug 没修，需求漏了俩，注释还自信地写着"已处理边缘情况"。

  • 场景四：你想回滚，发现没法回滚。 所有改动塞在一个又大又乱的 commit 里，git bisect 在哭，git revert 在拒绝服务。

这些都不是 AI 笨，而是你和 AI 之间的工作方式有问题——靠"唠嗑"驱动，没有合同、没有验收、没有归档。

0.2 这些坑的根源，其实就三个字：上下文

LLM 不是越聊越聪明，是越聊越糊。这有个学术名字叫 context rot（上下文腐烂），翻译成人话：

上下文使用率它的真实状态现场表现
0–30%满电，思路清晰全面、严谨、记得住所有约束
50%+开始省电模式"我会更简洁一点哦"——然后偷偷砍掉一半逻辑
70%+已经在抢救式输出幻觉、漂移、把你早上说的话忘得一干二净

你以为是"AI 累了"，其实是它的注意力被你 30 轮聊天稀释成了苏打水。

0.3 GSD 解决了什么

GSD 不是给 AI 加魔法，它是给你加了一套强制流程，把"自由聊天写代码"改成"工业流水线":

老问题GSD 的解法
AI 越聊越糊（context rot）把重活派给子代理（subagent），每个任务都用一份全新的 200k 上下文。第 50 个任务和第 1 个任务一样清醒
AI 写出来的不是你想要的写之前先 discuss，把布局/接口/数据结构/错误处理这些灰色地带白纸黑字钉死，存进 CONTEXT.md
大乱炖 commit 没法回滚每个 task 自己一个 commit（atomic commits），git bisect、git revert 都能用
跨会话失忆项目状态全部落盘到 PROJECT.md/ROADMAP.md/STATE.md/CONTEXT.md，新会话开局自动加载
测试和实现绑死，一改就裂用 goal-backward 验证：问的是"要让它工作，什么必须为 TRUE"，测行为不测内脏
你忘了自己说过啥每条决策有编号（D-01、D-02...）；规划阶段有阻塞门，决策没落进 plan 不让你继续

0.4 一句话比喻

没有 GSD 的 AI 编程：你雇了个一边喝酒一边装修的临时工，前两面墙挺漂亮，第三面开始走样，第四面变成立体派。

用 GSD 的 AI 编程：你换成了一个有点强迫症的项目经理 + 一群每天换班的清醒包工头。每开工一面墙都让你签字，每砌完一段都拍照存档，半夜想拆哪面墙都能精准定位是谁砌的、为什么砌成这样。

听起来啰嗦？是的。但它帮你把**"我以为它懂"变成了"白纸黑字写过它确实懂"**。

0.5 谁该用，谁可以先不急

强烈推荐：

  • 项目超过一两个文件的体量，且你不打算手把手盯着每一行 diff
  • 经常被"AI 越改越乱"折磨过
  • 想把 AI 当队友而不是当抽奖机

可以先不急：

  • 一次性脚本、五分钟搞定的小修小补（这种用 /gsd-quick 就够了）
  • 写个 README 改个错别字（杀鸡用牛刀）

好了，认真的部分开始。

目录

1. 安装与启动

# 一键安装（会问你用哪个 runtime：Claude Code / Codex / OpenCode / Gemini CLI / Kilo 等）
npx get-shit-done-cc

# GSD 是为"自动化"设计的，官方原话就是：要丝滑就别一直点 yes
claude --dangerously-skip-permissions

安装位置（Claude Code）：~/.claude/skills/gsd-*/

装完命令不出现 → 重启 runtime。别怀疑人生，重启就好了。

命令语法差异（同一个命令，不同 runtime 写法不一样，别记混）：

Runtime写法
Claude Code / Copilot / OpenCode / Kilo/gsd-command-name [args]（连字符）
Gemini CLI/gsd:command-name [args]（冒号）

2. 核心命令循环

2.1 标准主流程（这就是 GSD 的"心电图"）

/gsd-new-project          # 体检 + 出方案：回答问题、生成路线图，你审批
/clear                    # 清场，别把开胃菜端到主菜桌上
/gsd-discuss-phase 1      # ⭐ 关键步骤——把你脑子里的样子讲清楚
/gsd-ui-phase 1           # 仅前端：先签设计契约，再开工
/gsd-plan-phase 1         # 调研 + 拆任务 + 自检
/gsd-execute-phase 1      # 子代理们并行开干（每个任务一个 commit）
/gsd-verify-work 1        # 你亲自 UAT，别全甩给它
/gsd-ship 1               # 一键开 PR
/gsd-ui-review 1          # 仅前端：视觉走查

完整循环：discuss → plan → execute → verify → ship，跑到 milestone 完工，archive、tag，然后开下一个 milestone——干净、利落、能复盘。

2.2 已经有一坨代码了怎么办？

先跑 /gsd-map-codebase，让它把你家底先摸一遍（栈是啥、风格是啥、约定是啥）。 先摸底再 new-project，问的问题才会问到点子上。否则它问得云里雾里，你答得心烦意乱。

2.3 迷路了？喊导航

/gsd-progress                       # "我在哪？下一步是什么？"——救命三连
/gsd-progress --next                # 不废话，直接推进到下一步
/gsd-progress --do "fix the auth bug"   # 把一句人话扔给它，它自己挑命令
/gsd-progress --forensic            # 标准报告 + 完整性审计（出事时用）

2.4 命令分类速览

类别常用命令
生命周期/gsd-new-project、/gsd-map-codebase、/gsd-new-milestone、/gsd-complete-milestone
阶段流程/gsd-discuss-phase N、/gsd-ui-phase N、/gsd-plan-phase N、/gsd-execute-phase N、/gsd-verify-work N、/gsd-ship N、/gsd-ui-review N
路线图调整/gsd-phase、/gsd-phase --insert N、/gsd-phase --remove N、/gsd-phase --edit N、/gsd-phase --edit N --force
多线并行/gsd-workstreams、create <name>、switch、status、progress、complete、resume
快速通道/gsd-quick（可叠加 --discuss --research --full）
自动化/gsd-discuss-phase N --chain、/gsd-autonomous --only N
诊断 / 收尾/gsd-progress、/gsd-forensics、/gsd-audit-milestone、/gsd-session-report
设置/gsd-settings

3. 真正决定质量的几条原则

如果只让你记 6 件事，就这 6 件。其他都是细枝末节。

3.1 别跳过 discuss-phase，求你了

路线图里每个阶段就一句话——这相当于你跟装修队说"做个北欧风的客厅"，然后回家发现客厅放了一头驯鹿。discuss-phase 就是把这些灰色地带逐条钉死：

  • 这个页面长啥样？
  • API 字段叫啥、返回啥结构？
  • 错误怎么处理？
  • 数据流是单向还是双向？

每条决策会以 D-01、D-02...的编号写进 CONTEXT.md。然后规划阶段有个阻塞门：每条决策必须出现在某个 plan 的 must_haves / truths / body 里——少一条它都不让你过。

跳过 discuss = 拿到合理的默认； 用好 discuss = 拿到你的设想。

两种 discuss 模式：

  • Default（开放式）：默认行为，问你一堆开放问题。适合从零开始、你自己都还没想清楚的时候。
  • Assumptions 模式：它先读你代码库，列出"我打算这么干"的结构化假设，让你只对错的部分提反对意见。适合老项目，效率高得多。 开启方式：/gsd-settings → 把 workflow.discuss_mode 改成 assumptions。

3.2 把上下文当电池用

回忆一下 0.2 节的腐烂曲线。结论很简单：

  • 阶段之间 /clear，别让上一个 phase 的残茶剩饭污染下一个。
  • 重活让 subagent 干，它们每个都拿一份新鲜的 200k 窗口。
  • 你的主会话保持在 30–40% 上下文以下就对了，剩下的让它们去消耗。

主会话像项目经理——只负责调度和把关，不亲自搬砖。

3.3 进 discuss 之前，自己先想 5 分钟

带着以下信息进来。问得越糊，它问得越多，循环越长，你越想砸键盘：

  • 目标——到底想解决什么问题？（不是"做个网站"这种）
  • 目标用户——谁在用？什么场景？
  • 核心功能列表
  • 约束——性能、合规、预算、时间，哪些是硬底线
  • 技术栈偏好——历史包袱、团队熟悉度

记住：GSD 不会读心。你模糊它就模糊，你清晰它就清晰。

3.4 拥抱"原子计划 / 原子提交"

每个 plan 只塞 2–3 个任务，刚好放进半个新鲜上下文。每个任务一个 commit。 好处一箩筐：

  • git bisect 不会哭
  • git revert 能精准外科手术
  • 出 bug 时一眼能看出"是这一刀切坏的"
  • 后人（包括三个月后失忆的你）能读懂

反例：把 12 个任务塞进一个 plan，然后惊讶地发现 AI 在第 8 个任务时开始"偷懒"。这不是 AI 偷懒，是你给它准备了一桌满汉全席又怪它吃不完。

3.5 验证看"行为"，不看"它做了啥"（goal-backward）

老套路：写 30 个单元测试断言它调用了哪个函数、传了什么参数。结果第二天重构一下，30 个测试全红，需求其实没坏。

GSD 套路：问**"要让它工作，什么必须为 TRUE？"**——然后只测这个。 重构、换实现、换库，行为没变，测试就不该红。

3.6 真活需要时间，喝杯咖啡

跑一个完整的 phase 经常 30–60 分钟，里面相当一部分时间是子代理在并行干活。看着控制台没动静，不代表它在偷懒——它可能是在三个不同的 subagent 里同时拆三块骨头。

别打断它。打断的代价远大于多等十分钟。

4. 提速技巧速查表

想做的事怎么做
小 bug / 一次性改动，不想走全流程/gsd-quick，可叠加 --discuss --research --full
一次性把所有 phase 都 discuss 完，剩下放手跑先逐个 /gsd-discuss-phase N，再 /gsd-discuss-phase N --chain 或 /gsd-autonomous --only N
多条特性并行（不互相打架）/gsd-workstreams create <name>，每个 workstream 有独立 .planning/workstreams/<n>/
路线图变了/gsd-phase、--insert N、--remove N、--edit N（紧急插入要克制）
不知道在哪/gsd-progress / /gsd-progress --forensic
状态看起来坏了/gsd-forensics 出诊断报告（相当于让它自己拍 X 光）
Milestone 全部完成/gsd-audit-milestone → /gsd-complete-milestone → /gsd-new-milestone

5. 推荐工作姿势

把这套流程当肌肉记忆背下来，能省你大量纠结：

  1. 已有代码 → 先 /gsd-map-codebase，让它先看家底。
  2. /gsd-new-project，把 PROJECT.md / REQUIREMENTS.md / ROADMAP.md 审到位（这是签合同，不是走过场）。
  3. 一次性把每个 phase 都 discuss 一遍——前期辛苦半小时，后期解放半天。
  4. 然后 /gsd-autonomous --only N 一阶段一阶段跑，你只在 verify 和 ship 处亲自把关。
  5. 阶段间记得 /clear。说三遍：clear、clear、clear。
  6. milestone 完工 → audit → complete → tag → 下一个 milestone。

干净到像在跑流水线。

6. 关键文件与状态管理

GSD 没有"共享记忆"这种玄学。所有跨会话的状态都老老实实落盘：

文件作用类比
PROJECT.md愿景 / 项目目标项目立项书
REQUIREMENTS.md范围 / 需求需求文档
ROADMAP.md阶段路线图工期表
STATE.md当前位置、当前决策工地"今日施工进度"白板
CONTEXT.md每个 phase 的实现决策（<decisions> 块）装修方案变更单
.planning/config.jsonGSD 配置工地规章制度
.planning/workstreams/<n>/每个并行 workstream 的隔离目录不同分包的独立工棚

每次新会话启动，GSD 会重新加载这些文件，所以即使 /clear 掉聊天上下文，它依然知道项目走到哪一步、签过哪些字。

7. 常见反模式

把这张表打印出来贴墙上：

反模式后果正确做法
跳过 discuss-phase 直接 plan拿到泛化默认实现，和你预期差十万八千里老老实实 discuss，把决策写进 CONTEXT.md
把多个任务塞进同一个 plancontext rot，质量下降，回滚困难保持每个 plan 2–3 任务、原子提交
阶段之间不 /clear主上下文越来越满，后续阶段开始幻觉每个新阶段开始前 /clear
频繁 --insert 紧急 phase路线图变成意大利面，谁都看不懂仅在真正紧急时插入；其他用 add-phase 追加
用单元测试细节断言实现改实现就破测试，测试变累赘用 goal-backward 行为断言
不耐烦中途打断长任务状态可能不一致，得用 forensics 抢救让它跑完，去喝咖啡
discuss 时回答"随便""都行""你看着办"它真就看着办了，然后你后悔决策权在你手上，认真行使

8. 参考链接

一句话总结：用好 GSD = 在 discuss 阶段把设想钉死 + 信任子代理的上下文隔离 + 让每个 plan/commit 保持原子。 三大反模式：跳过 discuss、塞大 plan、不 /clear。

你不是在和 AI 聊天写代码，你是在用 AI 当包工头——合同写清楚、签字到位、验收严格，房子才不会塌。

avatar
文章
阅读
粉丝