公众号名称：James的成长日记

作者名称：Jameszyh

发布时间：2026-06-23 13:06

大家好，我是 James。

上一篇我们拆了 ECC——能力增强框架的代表作。ECC 的核心哲学是「能力可组合、上下文纯净、经验可沉淀」，通过 48 个 Agents + 182 个 Skills 把通用 AI 改造成专业开发引擎。

这一篇我们聊另一个方向的极致代表：GSD（Get Shit Done）。

如果说 ECC 是「给 AI 配工具」，GSD 就是「给 AI 配工作流」。ECC 解决的是「AI 能做什么」的问题，GSD 解决的是 AI 编程最底层、最根本的问题——上下文窗口怎么用。

GSD 不依赖任何外部工具或 API，它的全部魔法都发生在上下文窗口内部。它的核心洞察是：AI 编程的质量，不取决于模型有多强，而取决于你给模型喂的上下文有多好。而 GSD 把「上下文管理」这件事做到了极致——它把不可控的「对话式编程」，改造为可观测、可调度、可恢复的「工业流水线」。

01 | 为什么选 GSD 作为上下文工程类的代表？

上下文工程类 Harness 框架有多个，选择 GSD 作为代表的原因有五：

问题最深刻：GSD 直接攻击 Context Rot（上下文腐烂）——AI 编程最核心的矛盾。随着项目推进，上下文窗口被填满，AI 对早期指令的注意力衰减，产出质量持续下降。GSD 的所有设计都围绕「如何对抗 Context Rot」展开。

设计最纯粹：所有机制都为「上下文管理」服务，没有冗余。不像其他框架还要兼顾规范管理或能力扩展，GSD 只关心一件事——如何让 AI 在长项目中保持高质量产出。

可工业化：GSD 把「AI 唠嗑式编程」改造为「工业流水线」。五阶段标准化流程（Discuss → Plan → Execute → Verify → Ship），每阶段有明确的输入、输出、验收标准，阶段间强制隔离。

三大原理的极致体现：决策外化、流程阶段化、任务原子化在 GSD 中都被推到极致。GSD 是唯一一个把三大原理同时做到极致的框架。

天然可组合：GSD 关注「如何执行」，不关注「规范如何写」和「能力如何扩」。它与 SDD 框架（OpenSpec/Spec-Kit）和能力增强框架（ECC）天然互补。

02 | 设计哲学：上下文是稀缺资源、流水线优于工匠、文件系统即记忆

哲学 1：上下文是稀缺资源，必须显式管理

通用 AI 把上下文当成无限资源用，结果总是耗尽。GSD 的做法是把上下文当成预算来管理。

具体体现：主会话上下文严格控制在 30-40% 占用率；每个子任务有 200K Token 的独立上下文上限；阶段切换时强制 /clear 重置上下文；信息存储在文件系统，按需加载，不长期占用上下文。

这就像内存管理——操作系统不会让一个进程占满所有内存，GSD 也不会让一个会话占满所有上下文。

哲学 2：流水线优于工匠

通用 AI 编程像工匠手作——质量看心情、看运气。GSD 的做法像工业流水线——稳定、可预测、可重复。

五阶段标准化流程，每阶段有明确的输入、输出、验收标准。阶段间强制隔离，不互相污染。失败可局部回滚，不影响其他阶段。这不是限制 AI 的创造力，而是把创造力用在正确的地方。

哲学 3：跨会话记忆基于文件系统而非对话历史

通用 AI 跨会话失忆——每次都要重新讲一遍。GSD 的做法是把文件系统当作「长期记忆」。

.planning/ 目录是项目的「单一真相源」。STATE.md 实时记录当前进度。CONTEXT.md 记录关键决策。新会话自动加载这些文件，3 秒内完全恢复工作状态，无需用户重述，零 Token 浪费。

03 | 核心架构：.planning/ 目录 + 三层拆解模型 + XML 计划 + 状态机

GSD 的核心架构由四个关键概念组成。

概念 1：.planning/ 目录——项目的「操作系统」

your-project/
├── .planning/
│   ├── PROJECT.md        ← 项目愿景与全局约束
│   ├── ROADMAP.md        ← 阶段路线图
│   ├── STATE.md          ← 实时进度（自动维护）
│   ├── CONTEXT.md        ← 关键决策记录
│   └── milestones/
│       ├── M1-foundation/
│       │   └── phases/
│       │       ├── phase-1-auth/
│       │       │   ├── plan.xml    ← 带验证标准的 XML 计划
│       │       │   ├── tasks/      ← 原子任务清单
│       │       │   └── results/    ← 每个任务的执行结果
│       │       └── phase-2-payment/
│       └── M2-features/
└── src/                  ← 实际代码

.planning/ 就像 Git 的 .git/ 目录之于代码仓库——它不参与业务逻辑，但支撑整个工作流的基础设施。AI 和人类共同维护，结构化、可遍历、可索引。

概念 2：三层拆解模型——Milestone → Phase → Task

GSD 的核心拆解模型是三层粒度：

Milestone（里程碑）：业务交付单位，大约 1-2 周的范围。可演示、可验收的功能集。
Phase（阶段）：技术实现单位，大约 1-3 天的范围。架构上独立、可测试。
Task（任务）：执行单位，30 分钟内可完成。单上下文可完成。

三层粒度的意义在于：每一层对应不同的关注点。Milestone 对业务方说「我们什么时候能交付」，Phase 对技术负责人说「这个模块什么时候能测」，Task 对执行者（AI）说「你现在要做什么」。

概念 3：XML 格式的 plan.xml——为机器优化

GSD 选择 XML 而不是 Markdown 来写计划，这是一个值得深思的设计决策。

Markdown 对 AI 来说是「自由文本」——AI 可能理解错格式、可能随意发挥、可能遗漏字段。XML 是强结构化的——明确的字段、嵌套关系、机器可解析、可自动验证完整性。

一个典型的 plan.xml 包含：

objective：阶段目标
validation_criteria：阶段完成的验收标准（Goal-Backward 验证）
tasks：原子任务列表，每个任务包含 description、validation（单任务验收标准）、depends_on（依赖关系）、context_files（需要的上下文文件）

这是一个「为机器优化」的决策——牺牲一点人类可读性，换取系统的稳定性。

概念 4：状态机驱动的进度管理——STATE.md

STATE.md 不是一个简单的进度文档，而是一个状态机：

# 项目状态

## 当前位置
- Milestone: M1-foundation
- Phase: phase-1-auth
- Task: task-2 (in_progress)

## 已完成
- M1.phase-1.task-1 ✅ (2026-06-01)

## 待执行
- M1.phase-1.task-3  (等待 task-2 完成)
- M1.phase-1.task-4
- M1.phase-2 (整个 phase 待启动)

新会话启动时，AI 自动读取这个文件，3 秒内完全恢复工作状态。这让 GSD 具备了「断点续传」能力——任何时候关掉会话，下次开新会话能精确接续。

04 | 五阶段工作流：Discuss → Plan → Execute → Verify → Ship

GSD 把开发过程标准化为五个阶段，每个阶段有明确的命令、目标和纪律。

阶段 1：Discuss（讨论）——命令：/gsd-discuss-phase N

目标：澄清需求细节，锁定关键决策。

AI 主动询问需求中的模糊点，用户与 AI 反复对话，澄清边界。关键决策被记录到 CONTEXT.md。

纪律：不讨论清楚不进入下一阶段。跳过 Discuss 直接 Plan → AI 会自己脑补需求。Discuss 阶段动手写代码 → 决策不稳定。

阶段 2：Plan（规划）——命令：/gsd-plan-phase N

目标：拆解任务为原子单元，生成可执行计划。

AI 读取 CONTEXT.md 理解决策，分析现有代码库，拆解为原子任务（每个 30 分钟内可完成），标注任务依赖关系，定义每个任务的验收标准。

产出：plan.xml（带验证标准的 XML 计划）+ 任务依赖图（DAG）。

纪律：只规划，不写代码。这是 GSD 的铁律。

阶段 3：Execute（执行）——命令：/gsd-execute-phase N

目标：通过子代理并行处理任务。

主代理读取 plan.xml，识别任务依赖图，把无依赖的任务分组为「波次」（Wave），为每个任务启动独立子代理。子代理在干净的上下文中执行任务，每个任务完成后独立提交 Git commit。

关键机制：

波次执行：无依赖任务并行，有依赖任务串行
上下文隔离：每个子代理只看到自己任务相关的文件
原子提交：每个任务一个 commit，便于回滚

阶段 4：Verify（验证）——命令：/gsd-verify-work N

目标：用 Goal-Backward 验证确保交付质量。

GSD 的验证方式与众不同。传统验证问的是「实现是否正确」，Goal-Backward 验证问的是「用户能否达成目标」。

举个例子：传统验证会说「AuthService.login 函数返回了 token」✅。但 Goal-Backward 验证会说「用户能否登录后访问个人主页？」——然后发现 login 函数正确，但 token 没存到 cookie，用户事实上无法访问主页。

这本质上是把 BDD（行为驱动开发）的思想嵌入到 AI 工作流。

阶段 5：Ship（交付）——命令：/gsd-ship N

目标：生成 PR，归档里程碑。

自动生成 PR 描述（含本次变更摘要），关联相关 Issue，归档当前 Phase 到 milestones/，更新 ROADMAP.md。

05 | 波次执行：把串行变并行的工程艺术

波次执行是 GSD 最核心的执行机制。它的设计思路来自分布式系统的 DAG 调度。

假设一个 Phase 有 8 个任务，依赖关系如下：

Task 1 ─┐
Task 2 ─┼─→ Task 5 ─┐
Task 3 ─┘            ├─→ Task 7 ─→ Task 8
Task 4 ───→ Task 6 ─┘

GSD 自动分波次：

波次 1（4 个任务并行）：Task 1, 2, 3, 4
波次 2（2 个任务并行）：Task 5, 6
波次 3（1 个任务）：Task 7
波次 4（1 个任务）：Task 8

理论加速比：8 个任务串行执行需要 8N 时间，波次并行只需要 4N 时间（2 倍加速）。

但 GSD 的波次执行不只是为了快——它是通过并行化避免单会话过载。每个任务在独立的上下文中执行，完成后销毁，主会话始终保持轻盈。速度只是副产品，质量才是真正的目标。

这种设计本质上是在把 LLM 改造成一种「分布式计算系统」：主代理 = 调度器，子代理 = 工作节点，文件系统 = 共享存储，任务依赖图 = DAG。

06 | 对抗 Context Rot 的三个工程实践

实践 1：上下文隔离

传统做法是会话累积污染：会话开始 → Task1 → Task2 → Task3 → 上下文塞满 → 质量下降。

GSD 的做法是隔离执行：主会话只调度 → 每个 Task 启动子代理 → 子代理执行完毕销毁 → 主会话保持轻盈。

具体实现：阶段间强制 /clear 清空上下文；子代理只加载任务相关的文件（通过 task.context_files 字段精确控制）；主会话窗口长期保持 30-40% 占用率。

实践 2：跨会话记忆

传统做法：新会话 → 用户说「我们之前在做 X 项目，已经完成了 A、B」→ AI 重新理解 → 浪费 20K token。

GSD 做法：新会话 → AI 自动读取 .planning/STATE.md → 立刻知道当前位置 → 0 token 浪费。

STATE.md 是项目的「当前状态快照」，CONTEXT.md 是项目的「决策历史」，plan.xml 是当前 Phase 的「执行图」。三者共同构成完整的项目记忆。

实践 3：并行执行而非线性

传统做法是「实现这 8 个任务」→ AI 一个一个做 → 8N 时间 → 上下文累积污染。

GSD 做法是解析任务依赖图 → 分波次并行 → 4N 时间 → 每个任务独立上下文。

07 | GSD 与三大核心原理的关系

GSD 是唯一一个把三大核心原理同时推到极致的框架。

决策外化为文件

GSD 的外化层次最丰富：

PROJECT.md：项目级愿景
ROADMAP.md：里程碑级路径
CONTEXT.md：决策历史
STATE.md：实时进度
plan.xml：阶段级执行计划

在 SDD 框架之外，GSD 增加了「状态文件」这个独特的外化层——它让项目具备了「断点续传」能力。

流程结构化为阶段

GSD 的五阶段是 Harness 框架中最完整的：

Discuss：在 SDD 中很弱（Spec-Kit 的 specify 即是），GSD 把它独立为一个阶段
Plan：与 SDD 类似，但输出是 XML 而非 Markdown
Execute：在 SDD 中通常是黑盒，GSD 显式拆为波次
Verify：GSD 独有的 Goal-Backward 验证
Ship：把 PR/归档纳入流程

任务原子化为单元

GSD 把这条做到了行业最高标准：

显式的 200K Token 单任务上限
子代理强制隔离
波次并行调度
DAG 依赖管理

08 | 精妙设计：GSD 的五个工程智慧

设计 1：XML 而非 Markdown

为什么计划用 XML？结构强制：AI 必须按格式生成，不会随意发挥。可解析：调度器可以自动遍历任务、识别依赖。可验证：完整性可机器校验。

这是一个「为机器优化」的决策——牺牲一点人类可读性，换取系统的稳定性。

设计 2：Goal-Backward 验证

普通验证容易陷入「实现细节」：「Login 函数返回了 token」✅ → 「但用户其实登录不成功」。Goal-Backward 强制从用户视角验证：「用户能不能完成登录并访问主页？」→ 任何中间环节失败都会暴露。

设计 3：状态机化的进度管理

STATE.md 不仅是「记录」，更是「调度依据」。主代理读取 STATE.md 决定下一步做什么，子代理完成任务后回写 STATE.md，任何会话都可以从 STATE.md 恢复。

设计 4：纪律即代码

GSD 把「应该这样做」的纪律编码为命令：/gsd-clear-and-load 强制清空上下文并重新加载，/gsd-verify-context 检查上下文是否被污染，/gsd-checkpoint 在关键节点保存状态。人类纪律不可靠，但命令是可靠的。

设计 5：自动化的 Git 集成

每个原子任务一个 commit，commit message 自动生成（基于 task description）。Git history 本身就是项目执行历史，不需要额外的进度报告。

feat(M1.P1.T8): implement logout API
feat(M1.P1.T7): add JWT validation middleware
feat(M1.P1.T6): implement login API
feat(M1.P1.T5): implement register API
feat(M1.P1.T4): add JWT signing utility
feat(M1.P1.T3): create auth.service.ts skeleton
feat(M1.P1.T2): implement password hashing
feat(M1.P1.T1): create users table migration

09 | 局限与适用场景

局限 1：启动成本最高

GSD 需要把项目拆解到 Milestone → Phase → Task 三层，初次设置需要大量思考。对策：从一个小 Milestone 开始试点。

局限 2：纪律要求最严

GSD 的所有收益建立在「严格执行流程」之上。如果跳过 Discuss、跳过 Verify，效果会显著退化。对策：把 GSD 命令固化为 CI/CD 流程的一部分。

局限 3：对子代理能力依赖最强

GSD 严重依赖子代理（Sub-Agent）能力——必须能在独立上下文中执行任务。对策：选用支持子代理的 AI 工具（Claude Code 是首选）。

局限 4：不擅长快速原型

如果只想「快速搞个原型」，GSD 的流程会显得过重。对策：原型阶段用 Spec-Kit 或纯 vibe coding，进入正式开发后切换到 GSD。

局限 5：缺乏规范管理

GSD 关注「如何执行」，不关注「规范如何写」。如果项目需要长期维护规范契约，需要配合 SDD 框架。

适用场景判断

场景特征	推荐度
长周期项目（数月到一年）	★★★★★
复杂多模块功能开发	★★★★★
需要严格质量保证	★★★★★
多人协作（需要状态共享）	★★★★
快速原型	★★
单文件简单修改	★

总结

GSD 的核心定位：不是工具集，而是「工业流水线」——把不可控的对话式编程改造为可观测、可调度、可恢复的工程化流程
.planning/ 目录：项目的「操作系统」，AI 和人类共同维护的单一真相源
三层拆解模型：Milestone（1-2周）→ Phase（1-3天）→ Task（30分钟），每层对应不同关注点
XML plan.xml：为机器优化的设计决策，牺牲可读性换取系统稳定性
五阶段工作流：Discuss → Plan → Execute → Verify → Ship，每阶段有明确命令和纪律
波次执行：把串行变并行，加速是副产品，质量才是目标
Goal-Backward 验证：从用户目标倒推，比传统验证发现更深层的问题
局限：启动成本高、纪律要求严、依赖子代理、不擅长原型、缺乏规范管理

下一篇我们进入 Harness 工程学的另一个重要板块——错误处理与容错机制。当 AI 犯错了怎么办？如何设计让 AI 系统在错误面前不崩溃、不跑偏、不沉默？我们下一篇见。

关注我，James 的成长日记，持续分享干货，帮你在 AI 时代少走弯路。

内容效果不满意？点此反馈