GSD

在使用 Claude Code 进行超过 3 天的持续开发后，你可能会发现它的表现开始下滑：原本能完美遵循的架构规范被无视，它开始频繁回复"I’ll be more concise now"，甚至遗忘半小时前刚刚达成的技术决策。这不是 Claude 的逻辑能力下降了，而是 context window 中充斥了大量过往推理、错误尝试和冗长的文件读写记录，导致注意力的精确度发生了系统性偏移。 这种现象被称为 Context Rot（上下文腐烂）。对于任何试图用 AI 助手构建真实产品而非简单 Demo 的开发者来说，Context Rot 是限制生产力的核心瓶颈。 get-shit-done（以下简称 GSD） 的出现并非为了让 AI 写出更精妙的代码片段，而是为 Claude Code 引入了一个专门的项目管理层。它的核心逻辑只有一句话：通过外部化的状态文件和受限的编排架构，从底层消灭 context 积累，从而彻底解决 Context Rot 问题。 Context Rot 是什么，为什么它是真正的问题 当你在一个 Session 中连续输入超过 50 轮对话，Claude 的 context usage 往往会跳升至 100k token 以上。此时最直观的证据是响应变慢，以及它开始丢失对全局约束的感知。Transformer 架构的注意力机制在处理超长序列时存在权重弥散——模型会更倾向于关注最近几轮对话的细节，忽略初始阶段定义的架构原则。 根本原因是信息密度超载。在原始的 Claude Code Session 中，搜索结果、代码修改记录、测试报错和无关闲聊被线性地堆叠在一起。这些"噪音"占据了宝贵的注意力空间。即使 Claude 有 200k 的窗口，真正有效的注意力和被噪音稀释后的执行质量之间存在着巨大的鸿沟。 GSD 的判断：不要试图管理长 context，而要从架构上消灭它的积累。 它强制要求通过文件来同步状态，而不是通过对话历史。 状态文件体系：将记忆外挂 GSD 要求项目根目录下存在一套标准的机器可读文件，包括 PROJECT.md、STATE.md、REQUIREMENTS.md、ROADMAP.md 和 PLAN.md。这些文件不是写给人类看的文档，而是 Claude 的"外挂硬盘"。 ...