GSD Core：对抗上下文腐化的阶段循环引擎

<blockquote><p>&quot;Claude Code is powerful. GSD Core makes it reliable.&quot;<br>Claude Code 很强大。GSD Core 让它变得可靠。</p><p>——open-gsd&#x2F;gsd-core README</p></blockquote><p>第 12 章给了 Loop Engineering 一个很大的愿景：你不再提示 Agent，而是设计提示 Agent 的循环。但那一章停在原理层，讲的是五个原语加一个状态记忆。把这些原语落成一套能直接安装、有明确文件结构、带 67 个命令的工程系统，是另一回事。</p><p>GSD Core 就是这样一套系统。它不发明新的 Agent，也不取代 Claude Code，而是套在你已有的运行时上面，把讨论、规划、执行、验证、交付这五步，固化成每个里程碑都要重复一遍的流水线。它想回答的不是&quot;Agent 能不能写代码&quot;，这个早就不是问题了，而是一个更隐蔽的问题：为什么 Agent 在小任务上表现惊艳，一接手大项目就开始胡言乱语？</p><p>这个问题有名字，叫上下文腐化（Context Rot）。本章讲 GSD Core 怎么把对抗上下文腐化当成第一性原则，用阶段循环、子智能体、持久化工件这三样东西，把一个容易漂移的编码 Agent 变成靠得住的工程伙伴。</p><span id="more"></span><p><img src="/images/image-20260614104546667.png"></p><h2 id="13-1-GSD-是什么：Git-Ship-Done"><a href="#13-1-GSD-是什么：Git-Ship-Done" class="headerlink" title="13.1 GSD 是什么：Git. Ship. Done."></a>13.1 GSD 是什么：Git. Ship. Done.</h2><p>GSD 是三个词的首字母，Git. Ship. Done.（提交、交付、完成）。项目全称 <code>open-gsd/gsd-core</code>，由 open-gsd 组织维护，以 npm 包 <code>@opengsd/gsd-core</code> 的形式发布，MIT 协议开源。</p><p>它给自己的定位是一句话：一套轻量级的元提示（meta-prompting）、上下文工程与规格驱动开发系统。这三个定语各有所指。meta-prompting 是说它不直接干活，而是组织 Agent 怎么干活；context engineering 是说它的核心目标是管理上下文；spec-driven 是说它继承了第 3 章的规格驱动思想。</p><p>GSD Core 最要紧的特征是跨运行时。它不绑定任何一个 Agent 产品，安装时会问你跑在哪个运行时上，再把命令和 Agent 定义适配过去。官方支持的运行时有 Claude Code、OpenCode、Gemini CLI、Kimi CLI、Kilo、Codex、Copilot、Cursor、Windsurf。安装就一行命令：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx @opengsd/gsd-core@latest</span><br></pre></td></tr></table></figure><p>安装器会问你选哪个运行时、装到全局还是本地，并处理命名空间转换：有的运行时用连字符 <code>gsd-plan-phase</code>，有的用冒号 <code>gsd:plan-phase</code>。官方明确不建议你直接从 <code>agents/</code> 或 <code>commands/</code> 目录手动拷文件，让安装器做转换才能保证跨运行时一致。</p><p>整个系统由 67 个斜杠命令驱动。这个数字写在 <code>docs/INVENTORY.md</code> 里，还有一个测试 <code>command-count-sync.test.cjs</code> 盯着它和实际命令数对得上。换句话说，这不是一个 prompt 模板，是一个有版本、有测试、有文档的工作流引擎。</p><p>这里要澄清一个小差异。项目站点 opengsd.net 的首屏把循环的第一步写成 Research，GitHub README 写的是 Discuss。两者指同一件事，动手之前先把事情想清楚。本章统一用 README 的五步说法：Discuss → Plan → Execute → Verify → Ship。</p><h2 id="13-2-核心问题：上下文腐化"><a href="#13-2-核心问题：上下文腐化" class="headerlink" title="13.2 核心问题：上下文腐化"></a>13.2 核心问题：上下文腐化</h2><p>要理解 GSD Core 为什么长成这样，得先看清它在跟什么作斗争。</p><p>上下文腐化指的是：上下文窗口越填越满，AI 的输出质量也跟着往下走。一个 Agent 在对话开头思路清晰、引用准确；聊到第五十轮，它开始忘记早先的决定、混淆文件、把已经否决的方案又提一遍。窗口没满，但信噪比塌了。</p><p>GSD 的文档把多数 AI 编程方案在规模上的失败，归到三件事头上：</p><ul><li>上下文膨胀悄悄拉低质量。研究、规划、执行的细节全堆在同一个会话里，越堆越多，模型越来越难分辨什么重要。</li><li>会话之间没有共享记忆。今天的会话结束，明天重开一个，昨天的决定、试过的弯路、定下的约定，全没了。Agent 每次都从零开始。</li><li>没有机制验证代码真的能跑。Agent 说&quot;做完了&quot;，可&quot;做完了&quot;是声称，不是证明。这正是第 12 章反复敲的那一点。</li></ul><p>针对这三个病根，GSD 立了三根支柱：</p><table><thead><tr><th>病根</th><th>支柱</th><th>做法</th></tr></thead><tbody><tr><td>上下文膨胀</td><td>干净的执行上下文</td><td>每一步恰到好处，不膨胀、不漂移</td></tr><tr><td>无共享记忆</td><td>明确的计划与持久化状态</td><td>结构化任务图加落盘工件，可对齐、可审计</td></tr><tr><td>无验证</td><td>真实的验证</td><td>自动化检查加上人类读得懂的证据</td></tr></tbody></table><p>这三根支柱，分别对应后面三节要讲的三样东西：阶段循环、子智能体、持久化工件。</p><h2 id="13-3-五步阶段循环：Discuss-→-Plan-→-Execute-→-Verify-→-Ship"><a href="#13-3-五步阶段循环：Discuss-→-Plan-→-Execute-→-Verify-→-Ship" class="headerlink" title="13.3 五步阶段循环：Discuss → Plan → Execute → Verify → Ship"></a>13.3 五步阶段循环：Discuss → Plan → Execute → Verify → Ship</h2><p>GSD 把工作组织成里程碑（milestone），每个里程碑内部分成若干阶段（phase），每个阶段都走同一套五步循环。这里有一条铁律：每次只推进一个阶段。不许一边规划一边执行，也不许跳过验证直接交付。</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br></pre></td><td class="code"><pre><span class="line">里程碑 Milestone</span><br><span class="line"> └── 阶段 Phase 01</span><br><span class="line"> Discuss → Plan → Execute → Verify → Ship</span><br><span class="line"> └── 阶段 Phase 02</span><br><span class="line"> Discuss → Plan → Execute → Verify → Ship</span><br><span class="line"> └── ...</span><br></pre></td></tr></table></figure><p>这五步各有专属命令，下面逐一拆解。</p><p><img src="/images/image-20260614104948441.png"></p><h3 id="13-3-1-Discuss——动手规划前先把实现决策定下来"><a href="#13-3-1-Discuss——动手规划前先把实现决策定下来" class="headerlink" title="13.3.1 Discuss——动手规划前先把实现决策定下来"></a>13.3.1 Discuss——动手规划前先把实现决策定下来</h3><p>命令：<code>/gsd-discuss-phase &lt;编号&gt;</code>。</p><p>这一步不是写正式规格，而是一次轻量对话，目的是在规划开始前把实现决策定下来，免得规划者带着错误假设往下走。</p><p>它有个模式值得一提，叫假设模式（Assumptions mode）。传统的&quot;讨论&quot;是面试式提问，一条条问你想怎么做。假设模式反过来：Agent 先读代码库，基于证据自己形成观点，只在真正拿不准的地方请你纠正。它扮演的是思考伙伴，不是问卷。背后是一个朴素的判断：大部分实现决策，代码本身已经给了答案，没必要再问人。</p><p>产出两个工件：<code>CONTEXT.md</code>，结构化的决策记录；<code>&lt;NN&gt;-DISCUSSION-LOG.md</code>，人能读的审计轨迹。</p><h3 id="13-3-2-Plan——研究、分解，并验证计划装得进一个全新上下文窗口"><a href="#13-3-2-Plan——研究、分解，并验证计划装得进一个全新上下文窗口" class="headerlink" title="13.3.2 Plan——研究、分解，并验证计划装得进一个全新上下文窗口"></a>13.3.2 Plan——研究、分解，并验证计划装得进一个全新上下文窗口</h3><p>命令：<code>/gsd-plan-phase &lt;编号&gt;</code>，可带 <code>--research</code>、<code>--skip-research</code>、<code>--tdd</code>、<code>--mvp</code> 等标志。</p><p>这一步是 GSD 子智能体编排最密集的地方。编排者（orchestrator）依次派出三个子智能体：研究员（researcher）拿到一个干净的 200k token 窗口，专做技术研究，产出 <code>RESEARCH.md</code>；规划者（planner）拿到研究输出和需求做任务分解，产出一个或多个 <code>PLAN.md</code>；计划检查者（plan-checker）审查计划，趁执行前把歧义抓出来。</p><p>这里有条核心约束：每个计划必须能装进一个全新的上下文窗口。这不是建议，是设计原则。如果一个计划大到一个执行器的 200k 窗口都装不下它需要的全部上下文，那它就是太大了，必须拆。这条约束直接决定了任务分解的粒度。</p><p>产出工件：<code>RESEARCH.md</code>、若干 <code>PLAN.md</code>、<code>VALIDATION.md</code>（受奈奎斯特采样思想启发的验证策略），可选的 <code>PATTERNS.md</code>（代码库类比映射，告诉执行器&quot;项目里类似的东西是怎么写的&quot;）。</p><h3 id="13-3-3-Execute——以并行波次运行，每个执行器从干净上下文起步"><a href="#13-3-3-Execute——以并行波次运行，每个执行器从干净上下文起步" class="headerlink" title="13.3.3 Execute——以并行波次运行，每个执行器从干净上下文起步"></a>13.3.3 Execute——以并行波次运行，每个执行器从干净上下文起步</h3><p>命令：<code>/gsd-execute-phase &lt;编号&gt;</code>，可带 <code>--wave N</code>、<code>--gaps-only</code>、<code>--tdd</code>。</p><p>执行阶段把计划分成波次（wave）：彼此独立的计划在同一波里并行跑，有依赖关系的排到后面的波。每个计划对应一个执行器（executor）子智能体，每个执行器都从一个干净的 200k token 上下文起步，它只拿到自己这个计划需要的工件，不被别的计划的细节污染。</p><p>这就是&quot;并行波次&quot;的意思：不是无脑并发，而是按依赖图分层并发。<code>PLAN.md</code> 的 YAML frontmatter 里就写着 <code>wave</code>、<code>dependencies</code>、<code>modified_files</code>、<code>requirements</code>、<code>must_haves</code> 这些字段，编排者据此排波。</p><p>产出：代码、原子化的 git 提交，以及每个计划的 <code>&lt;NN&gt;-&lt;PP&gt;-SUMMARY.md</code> 执行记录。</p><h3 id="13-3-4-Verify——宣告完成前先诊断并生成修复计划"><a href="#13-3-4-Verify——宣告完成前先诊断并生成修复计划" class="headerlink" title="13.3.4 Verify——宣告完成前先诊断并生成修复计划"></a>13.3.4 Verify——宣告完成前先诊断并生成修复计划</h3><p>命令：<code>/gsd-verify-work [N]</code>。</p><p>一个验证者（verifier）子智能体检查实际构建出来的东西，看它对不对得上最初的目标、决策和计划。它做两道覆盖度检查，需求覆盖和决策覆盖：你在 Discuss 阶段定下的每条决策，都被执行了吗？</p><p>发现问题，它不止报告，还会派调试子智能体去诊断根因，并生成修复计划。这是 GSD 验证步骤最有牙齿的地方：验证的产出不是一句&quot;还有 bug&quot;，而是一份能直接执行的修复方案。产出工件：<code>VERIFICATION.md</code>（验证报告）、<code>UAT.md</code>（用户验收测试结果）。</p><h3 id="13-3-5-Ship——创建-PR、归档阶段、推进下一阶段"><a href="#13-3-5-Ship——创建-PR、归档阶段、推进下一阶段" class="headerlink" title="13.3.5 Ship——创建 PR、归档阶段、推进下一阶段"></a>13.3.5 Ship——创建 PR、归档阶段、推进下一阶段</h3><p>命令：<code>/gsd-ship</code>，可带 <code>--draft</code> 创建草稿 PR。</p><p>最后一步：创建拉取请求、归档本阶段的所有工件、更新 <code>STATE.md</code> 把这个阶段标记为完成，然后对下一个阶段重复整套流程。</p><p>把五步连起来看，它和第 5 章 gstack 的 Sprint（Think → Plan → Build → Review → Test → Ship）、第 8 章 Goal Workflow 的 <code>/prd → /goal → /review-it → /ship-it</code> 是同一个谱系。GSD 的独特之处不在循环的形状，在它对每一步上下文的洁癖，这是下一节的事。</p><h2 id="13-4-子智能体如何保持上下文整洁"><a href="#13-4-子智能体如何保持上下文整洁" class="headerlink" title="13.4 子智能体如何保持上下文整洁"></a>13.4 子智能体如何保持上下文整洁</h2><p>GSD 把对抗上下文腐化的关键机制叫瘦编排者（Thin Orchestrator）模式。</p><p><img src="/images/image-20260614105150559.png"></p><p>主会话，也就是你直接对话的那个编排者，刻意保持精简。它只做四件事：加载上下文、派生专门的子智能体、收集结果、更新共享状态。它不自己做繁重研究，不自己写大段代码，不让执行细节堆进自己的窗口。</p><p>所有重活下放给子智能体，而每个子智能体都拿到一个干净的、最多 200k token 的上下文窗口，外加它这份活儿要用的工件，仅此而已。研究员只看研究要用的东西，执行器只看自己那个计划。任务和任务之间物理隔离，一个 Agent 的上下文不可能污染另一个。</p><p>这套设计的三条原则，GSD 文档总结得很干净。第一条，每个 Agent 一份新上下文（Fresh Context Per Agent），用来消除上下文腐化。第二条，瘦编排者（Thin Orchestrators），让主会话不囤积细节。第三条，文件化状态（File-Based State），让状态落盘，可持久、可检视。</p><p>回头看第 12 章会发现，这正是 12.3.5 讲的 maker-checker 分离的工业级落地：写代码的执行器和验证工作的验证者不是同一个上下文，甚至可以不是同一个模型。第 12 章把这个分离称作循环里最有用的结构性设计，GSD 把它从一个有用的设计，变成了贯穿整个工作流的强制纪律。</p><p>支撑这套编排的，是一个叫 <code>gsd-tools.cjs</code> 的 CLI 工具。它是 GSD 工作流操作的功能后端，把配置解析、模型解析、阶段查找、git 提交、摘要验证、状态管理、模板操作这些重复逻辑集中起来，替掉了散落在各个命令文件里的内联 bash。工作流文件（<code>workflows/*.md</code>）的典型套路是：用 <code>gsd-tools.cjs init &lt;workflow&gt;</code> 加载上下文，解析该用哪个模型，派生 <code>agents/*.md</code> 里定义的专门 Agent，收集结果，再用 <code>gsd-tools.cjs state update</code> 更新状态。</p><p>模型这件事 GSD 也做了精细化。它提供模型档位（model profiles），即 <code>quality</code>、<code>balanced</code>、<code>budget</code>、<code>adaptive</code>、<code>inherit</code> 五种预设策略，给不同的 Agent 分配不同的 Claude 模型。比如 <code>quality</code> 档给 <code>gsd-planner</code> 用 opus，<code>budget</code> 档给同一个 planner 用 sonnet。你还能按阶段类型（planning &#x2F; research &#x2F; execution）配模型，或者对单个 Agent 做覆盖。解析优先级是：单 Agent 覆盖大于阶段类型，阶段类型大于全局档位，全局档位大于运行时默认。这让&quot;贵模型做规划、便宜模型做执行&quot;这种成本意识的分工，变成一行配置，和第 14 章 improve 的思路殊途同归。</p><h2 id="13-5-持久化工件：STATE-md-与-CONTEXT-md"><a href="#13-5-持久化工件：STATE-md-与-CONTEXT-md" class="headerlink" title="13.5 持久化工件：STATE.md 与 CONTEXT.md"></a>13.5 持久化工件：STATE.md 与 CONTEXT.md</h2><p>第 12 章 12.3.6 那句话在这里落了地：Agent 会忘记，仓库不会。GSD 用一整套落盘的结构化工件，补上&quot;会话间无共享记忆&quot;这个病根。</p><p><img src="/images/image-20260614105344263.png"></p><p>所有工件都活在项目根目录的 <code>.planning/</code> 文件夹里，它是项目状态的唯一真相来源。目录结构大致是这样：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br></pre></td><td class="code"><pre><span class="line">.planning/</span><br><span class="line">├── STATE.md # 项目的活档案 / 导航层</span><br><span class="line">├── codebase/ # 代码库地图（onboarding 时生成）</span><br><span class="line">│ ├── STACK.md</span><br><span class="line">│ ├── ARCHITECTURE.md</span><br><span class="line">│ └── CONVENTIONS.md</span><br><span class="line">├── phases/</span><br><span class="line">│ └── &lt;NN&gt;-&lt;slug&gt;/ # 每个阶段一个目录</span><br><span class="line">│ ├── CONTEXT.md # Discuss 阶段的决策记录</span><br><span class="line">│ ├── RESEARCH.md # Plan 阶段的研究</span><br><span class="line">│ ├── &lt;NN&gt;-&lt;PP&gt;-PLAN.md # 可执行的工作单元</span><br><span class="line">│ ├── VERIFICATION.md # Verify 阶段的报告</span><br><span class="line">│ └── ...</span><br><span class="line">└── quick/ # /gsd-quick 的临时任务</span><br></pre></td></tr></table></figure><p>两个核心工件值得细看。</p><p>先是 <code>STATE.md</code>，项目的活档案、中央导航层。它记录当前里程碑、活跃阶段、已完成和待办的计划、进度指标、累积的决策，还有会话连续性笔记。所有工作流启动时先读 <code>STATE.md</code>，做完重要动作后写回。它就是第 12 章说的那根脊柱：明天早上的运行从今天停下的地方接着走，不是从零开始。<code>gsd-tools.cjs</code> 甚至提供 <code>state get &lt;section&gt;</code> 让你按小节查它。</p><p>再是 <code>CONTEXT.md</code>，Discuss 阶段捕获的实现决策。它包含阶段边界、带 <code>D-NN</code> 编号的锁定决策、规范文档引用、已有代码洞见、具体的灵感来源、推迟的想法。它被研究员、规划者、执行器共同消费，这意味着你在讨论阶段定的每条决策，会一路流到执行器手里，而且因为带着 <code>D-NN</code> 编号，验证阶段能逐条核对&quot;决策覆盖&quot;。</p><p>此外还有 <code>PLAN.md</code>（带 YAML frontmatter 的可执行工作单元）、<code>RESEARCH.md</code>、<code>VALIDATION.md</code> 等等，每种都有明确的 schema。这套工件体系的意义在于：知识不再活在某次对话的上下文窗口里，而是活在文件系统里，谁都能读，下次运行接着来。这就是&quot;文件化状态&quot;原则的全部价值。</p><h2 id="13-6-上手与既有代码库的接入"><a href="#13-6-上手与既有代码库的接入" class="headerlink" title="13.6 上手与既有代码库的接入"></a>13.6 上手与既有代码库的接入</h2><p>全新项目用 <code>/gsd-new-project</code> 启动。但更现实的场景，是把 GSD 接到一个已经存在的代码库（brownfield）上，这条路径值得单独说。</p><p>第一步，让 GSD 读懂你的代码。命令 <code>/gsd-map-codebase</code> 会派出四个并行的 mapper 子智能体（技术栈 mapper、架构 mapper 等），分析代码库，在 <code>.planning/codebase/</code> 下产出 <code>STACK.md</code>、<code>ARCHITECTURE.md</code>、<code>CONVENTIONS.md</code> 等结构化地图。</p><p>第二步，<code>/gsd-new-project</code> 聚焦于&quot;你要加什么&quot;，而不是重新发明已有的东西，它会从现有代码里抽取并验证需求。</p><p>第三步，进入正常的 Discuss → Plan 循环。此时代码库地图会喂给 <code>/gsd-discuss-phase</code> 和 <code>/gsd-plan-phase</code>，确保计划顺着既有的约定和结构走，而不是另起炉灶。</p><p>除了完整的五步循环，GSD 还留了轻量入口。<code>/gsd-quick</code> 用于小而临时的任务：它保留 GSD 的保证（原子提交、<code>STATE.md</code> 追踪），但默认跳过研究、讨论、计划检查、验证这些可选环节，只派 <code>gsd-planner</code>（quick 模式）和 <code>gsd-executor</code>。需要时可以用标志逐级把质量管线加回来，<code>--discuss</code> 加轻量讨论，<code>--validate</code> 加计划检查和验证，<code>--full</code> 开完整管线，<code>--research</code> 加聚焦研究。quick 任务存在 <code>.planning/quick/</code>，并更新 <code>STATE.md</code> 里的 &quot;Quick Tasks Completed&quot; 表。</p><p>这种&quot;完整循环加快速通道&quot;的双轨设计，对应的是真实开发里&quot;大功能走流程、小修补抄近道&quot;的常态。但就算抄近道，原子提交和状态追踪也不丢。</p><h2 id="13-7-产品矩阵：从框架到独立-Harness"><a href="#13-7-产品矩阵：从框架到独立-Harness" class="headerlink" title="13.7 产品矩阵：从框架到独立 Harness"></a>13.7 产品矩阵：从框架到独立 Harness</h2><p>GSD 不止 gsd-core 一个产品。看清整个矩阵，才能看清它在第 10 章 Harness Engineering 谱系里的位置。</p><p>gsd-core 是本章主角，套在现有运行时上的工作流引擎。它本身不是 Harness，是给别人的 Harness 加一层可靠性。</p><p>gsd-pi 是一个 terminal-native 的独立自主 Agent，带 TUI 和 Web UI、worktree 隔离的 git、多模型路由，安装 <code>npm install -g @opengsd/gsd-pi@latest</code>。这才是一个完整的、独立的 Harness，对应第 10 章。</p><p>gsd-browser 是基于 CDP（Chrome DevTools Protocol）的浏览器自动化，提供 MCP server 模式和带版本的元素引用，标准动作流是 <code>navigate → snapshot → act → assert → export</code>，支持人工接管（human takeover），安装 <code>npm install -g @opengsd/gsd-browser@latest</code>。它给 GSD 的验证步骤提供了&quot;行为级证据&quot;：不是猜代码对不对，而是真的在浏览器里跑一遍、断言、留痕。</p><p>此外还有两个规划中的产品。gsd-workbench 是桌面端的本地工作区，管计划、backlog、证据、交付交接；gsd-cloud 是托管服务，提供跨设备的项目状态和团队可见性。</p><p>这个矩阵透露了 GSD 的野心：gsd-core 让任何运行时变可靠，gsd-pi 提供一个自带可靠性的运行时，gsd-browser 给验证装上眼睛，workbench 和 cloud 把单机循环扩展到团队。</p><h2 id="13-8-与全书方法论的对接"><a href="#13-8-与全书方法论的对接" class="headerlink" title="13.8 与全书方法论的对接"></a>13.8 与全书方法论的对接</h2><p>GSD Core 几乎是前几章方法论的一次集大成，把分散的原则拧成了一套能直接安装的工程系统。</p><p>跟第 3 章 SDD 的关系最直接：GSD 本质就是规格驱动，但它把规格嵌进了阶段循环。<code>CONTEXT.md</code> 是讨论阶段的规格，<code>PLAN.md</code> 是执行阶段的规格，验证阶段逐条核对规格覆盖。规格不再是开头写一次的文档，而是贯穿循环的活合约。</p><p>跟第 5 章 gstack 同为&quot;想、划、做、审、交&quot;谱系，但 GSD 更偏执于上下文隔离。gstack 用角色覆盖来保证质量，GSD 用&quot;每个 Agent 一份新上下文&quot;来保证质量。跟第 8 章 Goal Workflow 高度同构，<code>/prd → /goal → /review-it → /ship-it</code> 几乎可以和 Discuss → Plan → Execute → Verify → Ship 对位，GSD 可以看作 Goal Workflow 加了一套强制的文件化状态和子智能体编排。</p><p>跟第 10 章 Harness Engineering，gsd-pi 是一个完整的独立 Harness，gsd-core 则是&quot;给别人的 Harness 加可靠性层&quot;的另一种工程实践。</p><p>最深的一层是跟第 12 章 Loop Engineering 的对接。GSD 是 12.3 那&quot;五个原语加状态记忆&quot;的一次工业级落地：子智能体加持久化工件加独立验证门禁，再配上 worktree 隔离和模型路由。第 12 章讲的是循环的原理，GSD 给了你一个能直接 <code>npx</code> 装上的循环。</p><p>最后是跟第 14 章 improve、第 15 章 Compound Engineering 的关系，三者都信&quot;规划重于执行&quot;。improve 把成本分工压到极致，强模型审计、弱模型执行；Compound Engineering 在末端加了知识复利；GSD 则把重心放在跨会话的上下文工程和验证证据上。</p><h2 id="13-9-本章小结"><a href="#13-9-本章小结" class="headerlink" title="13.9 本章小结"></a>13.9 本章小结</h2><p>GSD Core 把一个容易被忽视的工程真相摆到了中心：AI 编程在规模上的失败，大多不是模型不够聪明，而是上下文管理不善。它给这个真相起了名字，叫上下文腐化，再用三样东西系统性地反击它。</p><p>第一样是阶段循环（Discuss → Plan → Execute → Verify → Ship），每次只推进一个阶段，把工作切成上下文窗口装得下的块。第二样是子智能体加瘦编排者，每个 Agent 一份干净的 200k 上下文，主会话不囤积细节，maker 和 checker 物理隔离。第三样是持久化工件（<code>STATE.md</code>、<code>CONTEXT.md</code>、<code>PLAN.md</code> 等），把状态落盘到 <code>.planning/</code>，让知识跨越会话边界存续。</p><p>它最聪明的定位是：不取代你的 Agent，而是让你的 Agent 变可靠。同一个 Claude Code，套上 GSD Core，就从一个聊到第五十轮开始漂移的对话伙伴，变成一个有计划、可恢复、有验证证据的工程流水线。这也正是它那句标语的全部意思：Claude Code 很强大，GSD Core 让它变得可靠。</p>