alookdlna投屏t
17.07MB · 2026-04-04
GSD 第一眼很容易被看成一套 Prompt 框架，但真把仓库翻完，感觉会完全不一样。它做得很重，而且这个“重”不是堆概念，是真往工程系统那个方向走了。
它关心的也不是“让 Agent 回答更聪明”，而是把从想法到交付这条线搭起来：需求拆分、阶段规划、并行执行、验证、发 PR、跨会话恢复，都有对应的命令、workflow、agent 和状态文件。
我先把最核心的 4 个判断摆在前面：
.planning/，而不是赌模型一直记得住command -> workflow -> subagent -> artifact 这条明确链路gsd-tools.cjs，不全靠 Prompt 硬扛从本地仓库看，GSD v1.30.0 已经不是“小而美”的 skill 包了，更像一套完整的工程底盘：
57 个命令入口56 个 workflow18 个 agent.planning/ 文件协议压成一句话的话，我会这么写：
README 里的自我定义是：
这句话很长，不过拆开就清楚了。
GSD 当然有 Prompt，也有 agent，但它的骨架远不止这些。仓库里至少有这几层：
bin/install.jscommands/gsd/*.mdget-shit-done/workflows/*.mdget-shit-done/bin/gsd-tools.cjsagents/*.mdget-shit-done/templates/、references/docs/所以它不是“读一段总 prompt，然后模型自由发挥”。更像一套把 Prompt、状态文件、CLI 和多 Agent 协作绑在一起的东西。
GSD 的 README 里有一句很出名的话，大意就是：别搞企业表演，直接把事做完。
这不是句口号，它躲的就是这些坑：
所以它的取向挺明确：流程可以重，但必须服务交付，不能只服务管理感。
很多人看到 GSD，会先记住一个词：Context Rot。
没错，它确实在解决上下文腐化。但如果只把它理解成“记忆增强”，还是看窄了。
我更愿意把它看成：它想把 Agent 开发从“临场发挥”拉回“项目推进”。
这里的差别很大：
这已经不是单纯的 Prompt 工程了。
基于当前本地仓库，GSD 的核心结构可以先粗看成这样：
get-shit-done/
├── bin/ # 安装器
├── commands/gsd/ # 57 个命令入口
├── agents/ # 18 个 agent 定义
├── get-shit-done/
│ ├── bin/gsd-tools.cjs # CLI 工具层
│ ├── workflows/ # 56 个工作流
│ ├── templates/ # PROJECT/STATE/PLAN/UAT 等模板
│ ├── references/ # 参考规则与说明
│ └── commands/gsd/ # 某些 runtime 的命令适配
├── hooks/
├── sdk/
└── docs/
如果按运行时来理解，它更像下面这个结构：
flowchart TD
A["用户输入 /gsd:command"] --> B["Command Layer"]
B --> C["Workflow Layer"]
C --> D["Subagents"]
C --> E["gsd-tools.cjs"]
D --> E
E --> F[".planning/ 状态文件"]
F --> C
F --> D
这里关键的不是文件多，而是分层很清楚。
用户面对的是 /gsd:new-project、/gsd:plan-phase、/gsd:execute-phase 这些命令。入口很短，记忆负担不大。
复杂逻辑都在 workflow 里：什么时候问用户、什么时候拉 research、什么时候派 agent、什么时候进入验证循环。
gsd-tools.cjs 很关键。状态解析、roadmap 更新、plan 索引、提交、frontmatter 处理、UAT 渲染、健康检查，这些都不再塞进 Prompt 里赌模型表现，而是交给 Node 工具。
.planning/ 是系统的持久状态层这也是 GSD 和很多 skill-first 框架最大的分叉点。它不是让模型“记住项目”，而是把项目状态写到磁盘上。
第一次看 GSD，最容易被震到的就是命令数量。
当前本地仓库里，commands/gsd/ 有 57 个命令，常见的有：
/gsd:new-project/gsd:discuss-phase/gsd:plan-phase/gsd:execute-phase/gsd:verify-work/gsd:ship/gsd:next/gsd:quick/gsd:fast/gsd:map-codebase/gsd:pause-work/gsd:resume-work/gsd:thread/gsd:workstreams如果只从“少即是多”的角度看，你可能会觉得它有点过了。但读完仓库再回头看，这反而是它的强点。
在很多系统里，流程都藏在一条大 prompt 里。你得自己记得：
GSD 的做法是把这些节点变成显式命令。这样好处很现实：
GSD 有个地方我挺喜欢，它不是只做完整流程，也给了很多短路径：
/gsd:next：自动判断下一步/gsd:quick：轻量任务但保留 GSD 的结构化保障/gsd:fast：更直接的快速执行/gsd:forensics：对失败流程做事后排查这意味着它不是只有一条大主链，而是围绕主链做了很多旁路和补丁口。
.planning/ 才是 GSD 的核心如果只挑一个最能代表 GSD 的设计，我会选 .planning/。
因为这套系统很多看起来“聪明”的地方，最后都落在这里。
GSD 的核心状态文件大致是：
PROJECT.mdREQUIREMENTS.mdROADMAP.mdSTATE.mdconfig.jsonphases/research/threads/seeds/HANDOFF.json这些不是“顺手生成的文档”，而是整个系统真正依赖的运行层。
可以画成这样：
flowchart LR
A["PROJECT.md"] --> P["Planner / Executor / Verifier"]
B["REQUIREMENTS.md"] --> P
C["ROADMAP.md"] --> O["Orchestrators"]
D["STATE.md"] --> O
D --> P
E["CONTEXT.md / RESEARCH.md"] --> P
F["PLAN.md"] --> X["Executors"]
G["SUMMARY.md / VERIFICATION.md / UAT.md"] --> D
G --> C
这条链说明一件事：GSD 的上下文不是一次性喂进去的，而是被拆成不同层级的工件，然后按阶段传播。
STATE.md 不是装饰，它真的是“活的”文档里直接把 STATE.md 叫作项目的 living memory。我觉得这个说法不过分。
它承载的东西包括：
更重要的是，它不是只靠模型读写。gsd-tools.cjs 里有一整套 state 子命令去更新它。
GSD 文档里有个细节很能说明它不是“Prompt 玩具”。
并行执行时，多个 executor 可能同时更新 STATE.md。为了解决这个问题，系统用了基于 lockfile 的互斥写入，STATE.md.lock 配合原子创建和超时检测，避免最后一个写入者把前一个 agent 的状态覆盖掉。
这一层一旦出现，性质就变了：
GSD 还有一套 session continuity 设计：
/gsd:pause-work/gsd:resume-work/gsd:progresscontinue-here.mdHANDOFF.json这套设计的重点不在“存一份总结”，而在于让上下文重置之后还能接着做，不至于又从头问一遍“我们现在做到哪了”。
这点在真实使用里非常重要。
GSD 的主流程其实很清楚：
flowchart TD
A["/gsd:new-project"] --> B["/gsd:discuss-phase"]
B --> C["/gsd:plan-phase"]
C --> D["/gsd:execute-phase"]
D --> E["/gsd:verify-work"]
E --> F["/gsd:ship"]
F --> G["/gsd:complete-milestone / new-milestone"]
看起来像经典的 spec-driven development，但它做了不少自己的取舍。
new-project：先把项目定义出来/gsd:new-project 不是只建几个文件，它会跑一整套初始化流程：
最后产出的是：
PROJECT.mdREQUIREMENTS.mdROADMAP.mdSTATE.mdconfig.json这一步很值钱。很多 Agent 项目一开始只有一句想法，后面全靠会话里边聊边修。GSD 的做法是先把项目底稿立住，后面所有阶段都接着这套东西往下走。
discuss-phase：不是再聊一遍，而是锁定这阶段的实现偏好README 对这一步解释得很对：Roadmap 里的 phase 通常只有一两句话，直接拿去实现根本不够。
所以 discuss-phase 的职责不是重复需求，而是把这一阶段的偏好、边界、灰区决策收成 CONTEXT.md。
原因很简单，后面的 researcher 和 planner 都会读这个文件。
plan-phase：研究、规划、校验一起做plan-phase 是 GSD 里我最喜欢的步骤之一，因为它不是“生成计划”这么简单。
它通常会串起三种 agent：
gsd-phase-researchergsd-plannergsd-plan-checker主线大概是：
PLAN.md这里的重点是：计划不是一份建议稿，而是准备直接喂给 executor 的执行工件。
execute-phase：Wave 并行是 GSD 最像“系统”的地方到了执行阶段，GSD 和很多 Agent 框架的差异会非常明显。
它不是简单地“一次开几个 agent”。它会先分析 plan 之间的依赖关系，然后分 wave：
flowchart LR
A["Wave 1: Plan 01 / Plan 02"] --> B["Wave 2: Plan 03 / Plan 04"]
B --> C["Wave 3: Plan 05"]
同一 wave 内可以并行，不同 wave 按依赖顺序推进。
这个设计很朴素，但非常有效。它至少解决了三个问题：
verify-work：把 UAT 也结构化了很多系统做到自动验证就停了，但 GSD 还往前走了一步：把用户验收也纳进流程。
verify-work 会：
SUMMARY.mdUAT.md这里有个判断我很认同：
这比让用户自己发散描述 bug 要高效得多。
GSD 的 README 和文档里反复强调上下文工程。这不是宣传语，确实是它整套设计的重心。
GSD 不会把所有东西一次性塞给一个 agent，而是按层级传播：
PROJECT.mdREQUIREMENTS.mdROADMAP.mdSTATE.mdCONTEXT.md、RESEARCH.mdPLAN.mdSUMMARY.md、VERIFICATION.md、UAT.md这比“整个仓库 + 一大段说明”要可靠得多。
map-codebase 是很被低估的一步如果你是在已有项目里用 GSD，/gsd:map-codebase 非常重要。
它会并行派出 4 个 mapper agent，直接写出一组结构化文档：
STACK.mdINTEGRATIONS.mdARCHITECTURE.mdSTRUCTURE.mdCONVENTIONS.mdTESTING.mdCONCERNS.md这里的设计很有意思：
.planning/codebase/这能看出来，GSD 已经很在意“上下文回传成本”这件事。
GSD 的 PLAN.md 里大量使用结构化字段和 XML 风格片段，比如：
<task type="auto"><verify><done><acceptance_criteria>这不是为了看起来高级，而是为了让 executor 更少猜测。
当一个计划同时明确：
那执行者就不太容易在主观理解上跑偏。
GSD 的多 Agent 设计，核心并不在数量，而在职责划分和上下文隔离。
无论是 new-project、plan-phase 还是 execute-phase，GSD 文档里一直在强调一件事：
这句话很关键。它的意思是：
这样做的直接收益是：主会话不会被所有实现细节塞满。
GSD 文档里直接写了 fresh 200K context window。这也解释了它为什么特别依赖“每个 plan 都足够原子”，这样 executor 不需要继承前面所有执行历史。
这也是为什么它非常强调：
如果 plan 写不好，Wave 并行就跑不起来。
GSD 对并行执行时的坑，处理得比我预想中细得多。
比如：
git commit --no-verify，避免 pre-commit hook 互相抢锁STATE.md 写入有锁这些都不是“写几句 Prompt 提醒一下”能解决的。
gsd-tools.cjs：它把多少 Prompt 逻辑挪成了工具如果说 .planning/ 是 GSD 的状态层，那 gsd-tools.cjs 就是那台把状态真正跑起来的引擎。
这个文件开头那一长串 usage，已经很说明问题了。它集中处理的东西包括：
state 读写roadmap 解析和更新requirements 标记完成phase-plan-indexprogressfrontmatter CRUDverify 系列检查template fillaudit-uatinit <workflow>很多 workflow 里都能看到这样的调用：
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" init plan-phase "$PHASE"
这一步会把当前 workflow 需要的上下文一次性整理出来，形成标准 JSON，然后再交给 orchestrator 使用。
这就有两个直接好处：
除了运行时工具，bin/install.js 也挺有代表性。
它处理的不只是安装文件复制，而是：
这说明 GSD 不是“先写一套 Prompt，再顺手发个 npm 包”。它一开始就把跨平台落地当成正式问题来做。
这一节我不打算把 57 个命令逐个列完，那样没什么阅读价值。更有意思的是，哪些命令最能体现 GSD 的系统设计。
new-project这是整个系统的起点。它决定的不是“项目名叫什么”，而是后面所有 artifact 的初始质量。
discuss-phase它让 phase 不只是 roadmap 里的一个标题，而是有清晰偏好和边界的实现上下文。
plan-phase这是 GSD 把“研究、规划、校验”揉成一个动作的地方，也是执行质量的分水岭。
execute-phase如果只看一个 workflow，我会推荐看这个。Wave 分组、并行执行、atomic commit、summary 生成，全在这里。
verify-work它把 UAT 也结构化了，不让“验证”停留在自动测试通过这一步。
next/gsd:next 特别像一个小型路由器。它会读 STATE.md、ROADMAP.md 和 phase 目录，然后直接决定下一步该跑哪个命令。
这类命令的意义不是省几次输入，而是减少流程犹豫。
map-codebase对于已有项目，这一步很值。它把“读代码库熟悉环境”做成了结构化资产，而不是一次性的探索结果。
quick 和 fast这两个命令说明 GSD 不是死板系统。它知道不是每件事都值得完整走 phase 流程，所以保留了轻量模式。
pause-work / resume-work / progress这是 GSD 跨会话体验的关键。没有这组命令，.planning/ 只是一堆文件；有了它们，系统才真正有连续性。
thread / plant-seed / workstreams这三个命令特别能体现 GSD 的野心。
thread：给跨会话但不属于某个 phase 的问题一个轻量容器plant-seed：把未来想法带着触发条件存起来，等下一个 milestone 自动浮出workstreams：在同一代码库里隔离多条并行规划状态，避免互相踩严格说，这已经不只是“开发流程工具”了，而是在做项目操作层。
如果只说 GSD 能抗 Context Rot，这篇文章其实不用写这么长。更让我在意的，是下面这些地方。
很多 AI 编程工具，本质还是一轮轮会话。GSD 在做的事，是把会话外面的工程骨架补齐：
这套东西一旦立住，项目就不再完全依赖“这轮会话状态好不好”。
README 里支持的 runtime 很多，但更难的是让这些 runtime 真的能用。
从安装器和 workflow 文本里能看出来，GSD 认真处理了：
这类工作很琐碎，但决定了一个框架能不能真的落地。
很多框架在 happy path 上都很好看，一出问题就散了。GSD 这边至少留了一整套补救命令和状态层：
forensicsdiagnose-issuesdebugverify-workpause-work / resume-work这说明它不是只为演示场景设计的，作者确实在想“出事之后怎么办”。
workstreams、manager、threads、seeds 这些能力说明，GSD 想处理的已经不只是单线程 feature delivery。
它开始碰的是更难的问题：
这部分未必每个人都用得上，但很能说明它的上限。
很多系统也写 plan，但最后 plan 只是供人类看看。GSD 里的 PLAN.md 不是，它就是给 executor 吃的。
这会倒逼前面的计划写得更具体，也让后面的执行更少漂移。
不是每个系统都能把多 Agent 做得很稳。GSD 能跑起来，是因为它先把：
这些东西补齐了。
如果你做的是一个能持续几周、几个月推进的项目，GSD 的价值会越来越明显。因为它不只是帮你写当前任务，而是在帮你维持整个项目的推进结构。
说完优点，也得说代价。GSD 绝对不是没有成本的。
57 个命令、56 个 workflow、18 个 agent，再加一套 .planning/ 状态层，这不可能是轻系统。
如果你只是想改一个小脚本，这套东西很可能显得过于正式。
很多开发者天然抗拒再多一层 Markdown 工件。GSD 恰恰相反，它把 Markdown 工件变成了运行协议。
你如果不愿意维护这些东西，系统优势就发挥不出来。
Wave 并行好不好用，取决于：
这些前置工作没做好，多 Agent 反而会放大混乱。
这不是批评，只是得先说清楚：GSD 不会像一个小 skill 那样“装上就几乎没存在感”。
它是有存在感的，也确实会改变你的工作方式。
我会更推荐在下面这些场景里用它：
不那么适合的场景也很清楚：
.planning/看完仓库以后，我对 GSD 的印象很明确：它最值得学的地方，不是某个命令，也不是某个 agent prompt，而是它背后的系统判断。
可以压成 5 条：
如果只用一句话概括：
也正因为这样，我觉得它值得认真研究。它碰到的已经不是 Prompt 怎么写，而是一个更硬的问题：
gsd-build/get-shit-done — GitHubREADME.mdpackage.jsonbin/install.jsget-shit-done/bin/gsd-tools.cjsget-shit-done/workflows/new-project.mdget-shit-done/workflows/plan-phase.mdget-shit-done/workflows/execute-phase.mdget-shit-done/workflows/execute-plan.mdget-shit-done/workflows/verify-work.mdget-shit-done/workflows/map-codebase.mdget-shit-done/workflows/next.mddocs/ARCHITECTURE.mddocs/USER-GUIDE.mddocs/FEATURES.md
