在 AI 编码助手日益普及的今天，开发者面临一个根本性挑战：随着对话上下文累积，模型输出质量会逐渐下降。这种被称为「context rot」的现象，严重影响了长周期项目的开发效率。get-shit-done（以下简称 GSD）框架正是为解决这一问题而设计的轻量级解决方案，它将 meta-prompting、context engineering 与 spec-driven development 融合为一套可操作的开发范式。
核心定位：从「对话」到「工程」
GSD 的核心思路是将 AI 辅助开发从自由对话模式转变为结构化工程流程。传统的 vibecoding 模式是「你说我写」，结果往往是不一致的垃圾代码，难以规模化。而 GSD 在用户描述与代码生成之间插入了一个完整的上下文工程层，让 Claude Code 能够始终获得清晰、完整、可验证的指令。
这个框架支持多达十五种 AI 编程运行时，包括 Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Qwen Code、CodeBuddy 和 Cline。安装方式极为简洁：通过 npx get-shit-done-cc@latest 即可完成全局或本地安装，安装过程会提示选择目标运行时和安装位置。
上下文工程：对抗 context rot 的技术本质
上下文衰减的根本原因在于大语言模型的上下文窗口容量有限，当历史信息超过阈值时，模型会开始「遗忘」早期的关键决策与约束。GSD 通过三种机制来解决这一问题。
首先是上下文分层架构。框架定义了明确的项目文件层级，每个文件承担特定的上下文角色：PROJECT.md 承载项目愿景，始终被加载；REQUIREMENTS.md 记录 v1/v2 及范围外的需求，带有阶段可追溯性；ROADMAP.md 描述开发方向与进度；STATE.md 跨会话记忆决策与阻塞点；PLAN.md 是原子化任务计划，带 XML 结构与验证步骤。这种分层确保每个阶段只加载必要的上下文，避免信息过载。
其次是子代理隔离执行。在执行阶段，框架通过「波浪式并行」机制将任务分配到独立的子代理上下文中。主上下文窗口仅保留 30% 到 40% 的占用率，大量实现工作发生在全新的 200k token 子代理上下文中。这意味着每个任务都在干净的上下文中开始，不受历史累积影响。
第三是原子化提交管理。每个任务完成后立即生成独立提交，格式为 type(phase): description。这种实践不仅便于 git bisect 精确定位失败任务，还为后续会话保留了清晰的历史轨迹，让未来启动的 Claude Code 能够快速理解项目状态。
规格驱动开发：XML 结构化任务定义
GSD 的任务计划采用 XML 结构化格式，这是实现规格驱动的关键。每个计划包含四个核心元素：<name> 定义任务名称，<files> 指定要操作的文件，<action> 给出精确的实现指令，<verify> 内置验证步骤，<done> 描述完成标准。
这种格式的优势在于消除了模糊性。传统 prompt 如「实现用户登录功能」存在大量解释空间，而 GSD 的结构化指令明确指定了使用的技术栈（如用 jose 而非 jsonwebtoken 处理 JWT）、验证方式（如 curl 测试返回 200 状态码与 Set-Cookie 头），以及成功标准。这种精确性大幅提升了代码生成的可靠性。
五阶段工作流：从概念到交付
GSD 定义了清晰的五阶段工作流，每个阶段都有明确输入与产出。
第一阶段：初始化项目。运行 /gsd-new-project，系统通过交互式问答理解项目目标、约束、技术偏好和边缘情况，然后可选地启动并行研究代理调查领域知识，最后输出 PROJECT.md、REQUIREMENTS.md、ROADMAP.md 和 STATE.md 四个核心文件。这一阶段的价值在于将模糊的创意转化为结构化的需求文档。
第二阶段：讨论阶段。运行 /gsd-discuss-phase [N]，系统在规划之前捕获实现决策。 roadmap 中的阶段描述通常只有一两句话，不足以指导实现。讨论阶段会分析每个阶段，识别灰色区域（如 UI 布局、API 响应格式、错误处理策略），通过问答直到用户满意。产出文件为 {phase_num}-CONTEXT.md，直接供给后续的研究与规划代理。
第三阶段：规划阶段。运行 /gsd-plan-phase [N]，系统首先根据 CONTEXT.md 进行研究，然后创建 2 到 3 个原子计划，每个计划都经过验证器检查是否达成阶段目标。如果验证失败，规划器会迭代改进，直到通过检查。这一机制确保了计划的可行性，避免执行阶段才发现问题。
第四阶段：执行阶段。运行 /gsd-execute-phase <N>，系统将计划分组为波浪。独立计划在同一波浪中并行执行，依赖计划在不同波浪中顺序执行。每个计划在全新的 200k token 上下文中执行，完成后立即提交。执行完成后，系统验证代码是否达成阶段目标。
第五阶段：验证与发布。运行 /gsd-verify-work [N] 进行人工验收测试，系统提取可测试的交付物，逐项询问用户是否满足预期。如果发现问题，系统自动启动调试代理诊断根本原因，并创建修复计划，用户可直接运行修复计划而无需手动调试。验证通过后，运行 /gsd-ship [N] 创建包含自动生成内容的 Pull Request。
内置质量门禁：自动化问题拦截
GSD 在 v1.34.0 引入了完整的质量门禁体系，这是实现可靠性的关键机制。框架定义了四种标准门禁类型：pre-flight（执行前检查）、revision（修订后验证）、escalation（升级判断）、abort（中止条件）。
具体实现包括：schema drift 检测标记 ORM 变更中缺失的迁移；安全 enforcement 将验证锚定到威胁模型；scope reduction 检测防止规划器静默丢弃需求；post-merge hunk 验证检测三路合并后被静默丢弃的代码块。这些门禁在 plan-checker 和 verifier 代理中自动运行，无需人工介入。
关键配置参数
对于希望采用 GSD 的团队，以下配置参数值得关注。
模型配置文件。在 .planning/config.json 中可设置 mode（yolo 或 interactive，控制自动批准还是每步确认）、granularity（coarse、standard 或 fine，控制阶段粒度）、以及各阶段使用的模型：quality 模式使用 Opus 进行规划和执行，balanced 模式（默认）使用 Opus 规划、Sonnet 执行，budget 模式使用 Sonnet 进行所有操作。
工作流开关。可独立控制 workflow.research（规划前研究）、workflow.plan_check（计划验证）、workflow.verifier（执行后验证）、workflow.auto_advance（自动链式执行 discuss → plan → execute）、workflow.discuss_mode（discuss 模式为访谈式，assumptions 模式为代码库优先）。
执行参数。parallelization.enabled 控制是否并行执行独立计划，planning.commit_docs 控制是否将 .planning/ 纳入版本控制，hooks.context_warnings 控制是否显示上下文窗口使用警告。
适用场景与采纳建议
GSD 特别适合以下场景：个人开发者或小型团队需要 AI 辅助完成完整项目；长周期项目需要跨会话保持开发上下文；需要可审计、可回滚的开发流程。
对于初次采纳的团队，建议从快速模式开始：运行 /gsd-quick --discuss --validate 进行轻量级讨论加上计划检查与验证，跳过完整的研究流程。当团队熟悉框架节奏后，再逐步启用完整的工作流开关。
GSD 的核心价值在于将 AI 编码从「对话艺术」转化为「工程实践」。通过结构化的上下文管理、精确的规格定义与自动化的质量门禁，开发者能够让 Claude Code 在长周期项目中保持稳定可靠的输出。这种思路与当前 AI 编码领域的 meta-prompting 与 context engineering 趋势高度一致，代表了 AI 辅助开发走向成熟的发展方向。
资料来源：GitHub 仓库 gsd-build/get-shit-done（MIT 许可证），36kr AI 编码研究，arXiv 论文 Context Engineering for AI Agents。