如何使用 GSD Core 框架防止 AI 助手上下文退化
前 15 分钟与 Claude Code 或 Cursor 等神经网络助手的协作通常看起来很完美。模型立即掌握项目结构，编写清晰的函数，并整齐地将模块组织到文件夹中。半小时后，会话扩展到数十条消息，奇怪的事情开始发生。模型对自己的编辑感到困惑，"遗忘"了架构，并开始在相同的错误上循环。
在提示工程中，这种现象被称为上下文退化（context rot）。当上下文窗口被调试日志、旧代码版本和随机消息堵塞时，生成质量会下降。GSD Core 项目正是为了解决这个问题而创建的。
项目理念
该工具是一个用于上下文管理的元提示系统。GSD Core 不是在一个混合了讨论、搜索和文件生成的冗长聊天中工作，而是通过一系列独立的子代理来组织开发工作。
与模型的主会话保持清洁。所有繁重的工作——仓库研究、规划和代码编写——都转移到后台进程中。每个子代理都从全新的 200,000 token 上下文窗口开始，完成特定的隔离任务，然后只向主流程返回一个压缩的摘要。
该框架适配了流行的 CLI 工具和环境：Claude Code、Cursor、Copilot、Codex、Windsurf、Kimi CLI 和 OpenCode。
五步开发周期
GSD Core 中的所有工作都围绕五个顺序步骤的固定循环构建：
- 讨论。在制定计划之前，你与助手锁定架构决策。这可以防止模型在编写代码时开始胡编乱造。
- 规划。子代理探索代码库，将任务分解为小步骤，并验证生成的计划是否适合上下文窗口。
- 执行。任务以并行波次启动。每个工作进程都获得全新的上下文，因此之前积累的日志量不会影响代码质量。
- 验证。代理审查编写的文件，识别不一致之处，检查功能，并在阶段完成前准备修复计划。
- 交付。该工具在 Git 中创建拉取请求，归档已完成的阶段，并进入下一步。
这种方法还解决了另一个常见问题——重启会话时的记忆丢失。所有决策、当前状态和上下文都记录在仓库根目录的 markdown 文件 STATE.md 和 CONTEXT.md 中。如果终端关闭或你在编辑器之间切换，整个历史都会被保留。
安装和核心命令
安装只需一个控制台命令即可完成：
npx @opengsd/gsd-core@latest
交互式向导会询问你使用的运行时，并提供在全局或项目目录中本地安装框架的选项。仓库作者特别要求使用安装程序而不是手动复制文件，以避免破坏代理兼容性。
设置完成后，你的工作环境中将可以使用专门的命令：
/gsd-new-project # Для старта нового проекта с чистого листа
/gsd-onboard # Для подключения фреймворка к существующему репозиторию
onboard 命令会扫描代码库，自动创建项目地图，并生成基线状态文件。
实际效果
我在一个小项目上测试了这个工具。主要的便利性在排查 bug 时体现出来。通常聊天会立即被控制台日志和堆栈跟踪弄乱，之后助手就停止理解上下文了。使用子代理分离后，主对话保持清洁，编辑也更加精确。变更历史直接存储在 Git 中，因此你可以安全地返回任何阶段。
另一方面，这种格式要求自律。如果你习惯于只是把错误截图丢进聊天窗口并期望立即修复，你就需要调整。先讨论，然后是明确的计划、验证，最后才是提交。此外，在后台运行多个具有 200,000 token 上下文的代理会明显更快地消耗 API 限额。
适用人群
对于在大于本地重构几个函数的任务上使用 AI 助手的工程师来说，GSD Core 会非常有用。如果你在 Cursor 或 Claude Code 中的会话经常在半小时工作后变得混乱，严格的阶段规划将有助于恢复模型的稳定性。
相关项目