夜雨聆风
GSD框架解析:解决AI编程工具Context Rot的工程化方案
嗨，我是小华同学，专注解锁高效工作与前沿AI工具！每日精选开源技术、实战技巧，助你省时50%、领先他人一步。👉免费订阅，与10万+技术人共享升级秘籍！
你可能也遇到过：同一个需求，前半段写得很顺；但当 AI 编程工具的 context window 被日志、报错、diff、约束反复填满后，输出突然开始“跑偏”——格式变了、边界漏了、甚至把你刚确认过的决策改没了。GSD（get-shit-done）要解决的，就是这个 Context Rot：context 越塞越乱，质量持续下滑 的问题。
核心原理
我把 Context Rot 理解成三件事叠加：
- ●知识被稀释：越往后，模型看到的并不是“当前最关键的决策”，而是越来越长的历史碎片。
- ●约束发生漂移（Schema drift）：你以为“规则一直生效”，但在多轮生成/返工里，结构约束悄悄松动。
- ●范围被不小心扩大：需求本该缩到可控的最小实现，但对话持续扩写，导致 scope reduction 失效。
GSD 的解决思路很“工程化”：用 Meta-prompting + Context Engineering + Spec-driven，把开发过程拆成阶段，并让系统在每个阶段都维护“输入应该是什么”。它的关键不是再喂更多文字，而是：
- ●通过阶段式流程，把“讨论/计划/执行/验收/发版”变成可追踪的产物链；
- ●内置质量门禁（例如 Schema drift detection / Security enforcement / Scope reduction detection）把“跑偏”尽早拦下；
- ●在需要的时候做 context-window-aware prompt thinning（提示瘦身）：该删的删、该保留的保留，确保后续仍在同一套决策框架内。
一句话：GSD 不追求聪明，它追求“不会随轮次变味”。
核心功能
实际使用时，GSD 提供了一套常用命令，我在日常开发中主要靠这几条把 AI 编程工作流稳住：你用 GSD 时，实际拿到的是一套“从 0 到 PR 的可控流程”。我建议你把它理解成一位能强制执行流程的工程搭档：
- ●/gsd-new-project：新项目初始化。把知识框架、约束和默认工作流先搭起来，后面才不会越写越飘。
- ●/gsd-discuss-phase [N]：讨论阶段实施决策（N 轮）。我常用在“边界/取舍”需要先定死的时候，避免后续执行阶段反复改方向。
- ●/gsd-plan-phase [N]：研究 + 创建 plan。GSD 会让计划尽量结构化，减少“口头约定到最后落不了地”。
- ●/gsd-execute-phase [N]：按波并行执行。比起一条条让模型慢慢吞需求，按波推进能减少上下文拥挤。
- ●/gsd-verify-work [N]：人工验收测试。这里是关键：让“质量门禁”落到你自己的验收标准上，而不是完全相信模型输出。
- ●/gsd-ship [N]：创建 PR，把产出绑定到版本控制。
- ●/gsd-quick：快速任务模式。适合小改动、或你已经有相对清晰 spec 的情况。
- ●/gsd-map-codebase：分析现有代码库。对已有工程尤其重要，能减少模型对“未知结构”的猜测成本。
另外，它还有一些我认为很实用的“最新能力”：
- ●Knowledge graph integration：让决策/知识不是散落在聊天里。
- ●SDK typed query foundation：用类型与查询底座把信息抓取变得更稳定。
- ●TDD pipeline mode：把测试纳入流水线，而不是最后再补。
- ●Project skills awareness（9 个 agents）：会按项目需求唤起更合适的“技能集合”。
质量门禁方面，至少要记住三条：Schema drift detection、Security enforcement、Scope reduction detection。它们基本覆盖了“为什么你明明按流程跑了，结果还是变烂了”的核心原因。
应用场景
我会把 GSD 用在这几类任务里（你也可以对号入座）：
- ●已有代码库的特性开发：比如在中大型工程里加一个新模块或改动 API 行为；如果你不先 map codebase，很容易出现“改了但没对齐现有约束”。
- ●需要稳定 spec 的需求：例如表单/权限/支付逻辑这类，边界一旦漏掉就会返工。
- ●多轮迭代的重构：Context Rot 会让重构更难收敛；阶段化 plan + 验收能显著降低反复。
- ●需要把输出对齐 PR 的团队协作：GSD 的 ship/PR 流程让交付更像工程而不是聊天。
部署方式
GSD 目前以 npm 包提供（针对 Claude Code 等工具的工作流形态）。安装非常直接：
支持平台（覆盖面很广）：Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Qwen Code、Cline、CodeBuddy（共 15 个）。
如果你是第一次用，我建议你从 /gsd-new-project + /gsd-plan-phase + /gsd-verify-work + /gsd-ship 这一条主链开始跑；等你熟悉“该在什么时候定决策”，再用 discuss/execute 的多轮参数把节奏加快。
总结
- 优点：
- ●把 Context Rot 变成“可工程化管理的问题”，不是靠祈祷模型保持一致；
- ●阶段化 + 质量门禁让返工更可控；
- ●prompt thinning / typed query / TDD pipeline 等能力，都是在为“长期稳定产出”服务。
- 局限：
- ●它不是“更会聊天”的工具，而是“更会执行流程”的系统：如果你的需求 spec 本身很模糊，前置的 discuss/plan 成本会更明显；
- ●对习惯了随写随改的开发方式，需要一点适应。
我最喜欢 GSD 的核心宣言之一：
“By far the most powerful addition to my Claude Code. Nothing over-engineered. Literally just gets shit done.”
如果你想把 AI 编程从“靠运气的对话”变成“可复用的工程流程”，GSD 值得把它加入你的工作台。
项目地址
https://github.com/gsd-build/get-shit-done
热门阅读
清华开源｜做一门课要3天？用 OpenMAIC，30分钟生成完整互动课堂｜GitHub 15.6k
比 BeautifulSoup 快 784 倍！这个自适应爬虫框架，我愿称它为下一代 Web Scraping 标杆
GitHub 14万星！Claude Code 从「会写代码」到「工程系统」的升级指南