用Claude Code写过大项目的都知道一个问题：上下文窗口填到一半，AI就开始胡说八道。前几轮生成的代码质量不错，到第五六轮就变成复制粘贴机器，逻辑混乱、风格不统一、之前约定的架构全忘了。
这就是所谓的context rot（上下文腐烂），也是vibecoding被人诟病”只能写Demo”的核心原因。
GSD（Get Shit Done）是最近开源的一个解决方案，3天上了HN首页，GitHub 32K Star。它不是又一个AI编码工具，而是一套”上下文工程”框架——通过元提示（meta-prompting）和规范驱动开发，让Claude Code在大型项目里保持一致性。
实际装了一把，看看是不是真的好用。
装上看看
一行命令：
npx get-shit-done-cc@latest
安装器会问你两个选择：用哪个runtime（Claude Code、Gemini CLI、Codex、Copilot等都支持），以及装到全局还是当前项目。
我选了Claude Code + 本地安装，几秒钟就装好了：
Installing for Claude Code to ./.claude ✓ Installed commands/gsd ✓ Installed get-shit-done ✓ Installed agents ✓ Wrote VERSION (1.25.1) ✓ Wrote package.json (CommonJS mode) ✓ Installed hooks (bundled) ✓ Wrote file manifest (gsd-file-manifest.json) ✓ Configured update check hook ✓ Configured context window monitor hook ✓ Configured statusline
装完一看目录结构，信息量很大：
.claude/ ├── agents/ # 15个专用Agent定义 │ ├── gsd-executor.md │ ├── gsd-planner.md │ ├── gsd-debugger.md │ ├── gsd-phase-researcher.md │ ├── gsd-plan-checker.md │ └── ... (共15个) ├── commands/gsd/ # 38个斜杠命令 │ ├── new-project.md │ ├── discuss-phase.md │ ├── plan-phase.md │ ├── execute-phase.md │ └── ... ├── get-shit-done/ │ ├── workflows/ # 40个工作流定义 │ ├── templates/ # 27个文档模板 │ ├── references/ # 12个参考文档 │ └── bin/ # 脚本工具 ├── hooks/ # 会话钩子 └── settings.json # Claude Code配置
总共164个文件，35000行Markdown。这不是一个简单的prompt wrapper，是一整套项目管理方法论。
核心思路：把”写代码”拆成工厂流水线
GSD的工作流分四步：
1. 初始化项目 /gsd:new-project
系统会不断追问你项目的细节——目标、约束、技术选型、边界情况，直到它觉得理解够了。然后自动产出四份文档：
PROJECT.md - 项目概览 REQUIREMENTS.md - 需求清单（区分v1/v2/不做） ROADMAP.md - 分阶段路线图 STATE.md - 当前状态跟踪
2. 讨论阶段 /gsd:discuss-phase 1
这步很关键。路线图里每个Phase就一两句话，信息量不够让AI做出你想要的东西。discuss-phase会根据功能类型问不同的问题：
– 做UI？问布局、间距、交互、空状态
– 做API？问返回格式、错误处理、参数校验
– 做内容系统？问结构、语气、深度
产出一份 CONTEXT.md，后续Research和Plan都基于这份文档。
3. 规划阶段 /gsd:plan-phase 1
这一步生成并行子Agent做调研：
├── Stack researcher - 技术栈调研 ├── Features researcher - 功能实现调研 ├── Architecture researcher - 架构调研 └── Pitfalls researcher - 踩坑预警
调研完自动写Plan文件，然后还有一个Plan Checker Agent来验证计划的可行性，最多循环3次。
4. 执行阶段 /gsd:execute-phase 1
这是最核心的设计：Plan被拆成多个原子任务，每个任务在全新的上下文窗口里执行。
这就是为什么能解决context rot——不是在一个超长对话里堆需求，而是每个任务都拿到200K token的干净上下文，只装载必要的背景信息。
任务之间按依赖关系组成Wave，同一Wave内的任务并行执行：
WAVE 1 (parallel) WAVE 2 (parallel) WAVE 3 ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ User │ │ Product │ │ Orders │ │ Cart │ │ Checkout│ │ Model │ │ Model │ │ API │ │ API │ │ UI │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
每个任务完成自动git commit，全程无需手动干预。
15个Agent的分工
装完看了下agents目录，每个Agent都有明确的职责边界：
| Agent | 职责 | Prompt大小 |
|---|---|---|
| gsd-planner | 写执行计划 | 43K字 |
| gsd-debugger | 问题诊断 | 41K字 |
| gsd-executor | 执行具体任务 | 19K字 |
| gsd-phase-researcher | 阶段调研 | 19K字 |
| gsd-plan-checker | 计划验证 | 23K字 |
| gsd-roadmapper | 路线规划 | 17K字 |
| gsd-codebase-mapper | 代码库分析 | 17K字 |
| gsd-verifier | 结果验证 | 17K字 |
| gsd-ui-auditor | UI审计 | 14K字 |
| gsd-project-researcher | 项目调研 | 16K字 |
最大的planner prompt有4万多字，定义了计划的XML结构、任务拆分规则、依赖关系推导等等。这不是随便写的几行System Prompt，是经过大量迭代的工程化产物。
两个值得注意的设计
Context Window Monitor
GSD在settings.json里配了一个PostToolUse钩子：
{
"hooks": {
"PostToolUse": [
{
"hooks": [
{
"type": "command",
"command": "node .claude/hooks/gsd-context-monitor.js"
}
]
}
]
}
}
每次工具调用后自动检测上下文使用量。一旦快满了就主动拆分任务，而不是等到AI开始胡言乱语才发现问题。
Nyquist验证层
借鉴信号处理的Nyquist采样定理（要想还原信号，采样频率至少是信号频率的两倍），GSD在规划阶段就为每个需求映射自动化测试。Plan Checker会检查：如果某个任务没有对应的验证命令，计划直接打回重做。
这意味着代码写完不是靠人肉review来确认质量，而是每个任务自带验证闭环。
跟其他方案对比
市面上类似的工具不少，挑几个有代表性的对比下：
| 工具 | 解决的问题 | 方法 | 侵入性 |
|---|---|---|---|
| GSD | Context rot + 需求失真 | 元提示 + 子Agent + 新上下文执行 | 中（38个命令，164个文件） |
| BMAD | 需求管理 | 多角色Agent模拟（PM/架构师/开发） | 高（流程复杂） |
| Speckit | 规范驱动 | 从描述生成Spec文档 | 低 |
| Cursor Rules | 代码风格一致 | 项目级Prompt规则 | 低 |
GSD的核心差异就两个字：隔离。其他工具都是在同一个上下文里堆东西，GSD是把任务打散到独立的上下文里执行。这是目前解决context rot最合理的思路。
实际体感和问题
好的方面：
- 上下文隔离确实能解决质量衰减问题，尤其是超过10轮对话之后差异明显
- discuss-phase的追问机制很聪明，能把你脑子里模糊的想法逼成具体需求
- Wave并行执行省时间，不用串行等
- 支持6个runtime（Claude Code、Gemini CLI、Codex、Copilot、OpenCode、Antigravity），不锁定生态
问题也不少：
- Token消耗惊人。15个Agent轮流上场，每个都带着几万字的Prompt，一个中型项目规划下来轻松烧掉几百万Token。如果用Opus跑，成本不低
- 164个文件35K行Markdown。.claude目录突然多了这么多东西，有种被入侵的感觉。虽然不影响项目代码，但心理门槛不小
- 强制流程。如果你只想快速改个Bug或加个小功能，走完new-project → discuss → plan → execute这套流程太重了。作者推荐用
/gsd:quick和/gsd:do来处理小任务，但文档里对这两个命令的说明不够清楚 - README里放Dexscreener的$GSD Token链接。一个开发工具的README里放加密货币Token，观感不太好
谁适合用
GSD最适合的场景：
- 用Claude Code（或其他AI编码工具）从零开始做中大型项目
- solo开发者或小团队，没有专职PM来管需求
- 项目复杂度到了”对话两三轮AI就开始忘事”的程度
不适合的场景：
- 已有成熟开发流程的团队，GSD的流程和现有工作流会冲突
- 小修小补，改个样式加个字段这种
- 对Token成本敏感的
一句话总结：GSD把vibecoding从”写Demo”升级到了”做项目”，代价是学习曲线和Token账单。如果你的AI编码体验卡在”写到一半AI就废了”，值得试试。
