在 AI 辅助编码工具链中，如何让 Claude Code 产生确定性、可预测且高质量的代码输出，始终是工程实践的核心挑战。传统方式依赖于人工编写复杂的系统提示词或不断在对话中补充上下文，但这种方式随着对话轮次的增加，上下文窗口会逐渐积累「垃圾信息」，导致模型输出质量下降 —— 这种现象在 GSD 项目中被称为「上下文腐烂」（Context Rot）。GSD（Get Shit Done）正是为解决这一问题而设计的元提示工程框架，它通过结构化的上下文工程、XML 格式化提示、多代理编排与原子化提交机制，为 Claude Code 构建了一套完整的规范驱动开发系统。

核心问题：上下文腐烂与规范缺失

当开发者使用 Claude Code 进行长会话开发时，上下文窗口会随着代码文件的不断修改、错误信息的累积以及对话历史的膨胀而逐渐稀释关键信息。模型在处理大量无关上下文时，其注意力机制会分散，导致对原始需求的遗忘或误解。GSD 的作者 TÂCHES 作为一名独立开发者，敏锐地捕捉到了这一痛点：其他 spec-driven 开发工具（如 BMAD、Speckit）往往引入了过于复杂的企业级流程（冲刺仪式、故事点、利益相关者同步等），而这些对于个体开发者而言完全是「企业剧场」，既增加了认知负担，又没有真正解决上下文管理的问题。

GSD 的设计哲学是将复杂性封装在系统内部，而将简洁性留给用户的工作流。开发者只需执行少数几个命令，系统便会在后台完成上下文工程、XML 提示格式化、子代理编排与状态管理等工作。这种「复杂性内聚、接口简洁」的设计思路，使得 GSD 能够在不增加开发者认知负荷的前提下，为 Claude Code 提供可靠的结构化上下文。

四大核心技术机制

上下文工程与文件结构

GSD 建立了一套完整的上下文文件体系，每个文件在系统中都有明确的职责定位。PROJECT.md 承载项目愿景，在整个会话周期内始终被加载；research/ 目录包含生态知识调研结果，涵盖技术栈特性、架构模式与常见陷阱；REQUIREMENTS.md 定义了 v1 和 v2 的功能需求，并保留与开发阶段的追溯关系；ROADMAP.md 记录项目进度与未来规划；STATE.md 维护关键决策、阻塞事项与跨会话状态；PLAN.md 以 XML 结构化格式描述原子任务及其验证步骤；SUMMARY.md 记录执行结果与变更历史；todos/ 和 threads/ 分别用于捕获待办事项与跨会话的持久化上下文。

这些文件的大小都经过严格限制，确保 Claude 的上下文质量不会因文件过大而降解。GSD 根据模型上下文窗口的实际情况设定了合理的容量阈值，开发者无需关心具体的计算逻辑，系统会自动管理文件的加载与卸载。

XML 格式化提示

GSD 强制所有任务计划采用 XML 结构化格式，这种格式对 Claude 的指令遵循具有显著优势。每个任务计划都包含 <task>、<name>、<files>、<action>、<verify> 与 <done> 等标签，清晰地定义了任务名称、涉及文件、具体操作、验证方式与完成标准。以下是一个典型的 XML 任务结构示例：

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

这种结构的优势在于：指令精确无歧义，验证步骤内置于任务描述中，Claude 无需猜测「什么是完成」，系统直接给出了可验证的完成标准。验证步骤 <verify> 的设计使得自动化验证成为可能，而 <done> 标签则从用户视角定义了功能预期，两者结合形成了完整的三层验证体系。

多代理编排与波浪式执行

GSD 的工作流在每个阶段都采用「薄编排器加专业代理」的模式。研究阶段由协调器调度四个并行代理分别调研技术栈、功能特性、架构设计与潜在陷阱；规划阶段由规划器创建计划，检查器验证计划是否符合阶段目标，循环迭代直到通过验证；执行阶段将计划分组为「波浪」（Wave），同波浪内的计划并行执行，跨波浪的计划顺序执行。

波浪式执行的核心逻辑基于依赖关系分析。独立计划被放入同一波浪并行执行，依赖其他计划的计划被放入后续波浪等待执行，文件冲突则强制顺序执行。这种设计使得垂直切片（Plan 01：用户功能端到端）比水平分层（Plan 01：所有模型，Plan 02：所有 API）具有更好的并行化效果。关键在于：主上下文窗口始终保持在 30% 到 40% 的低占用状态，大量工作在实际执行的子代理上下文中完成，主会话保持快速响应。

原子化 Git 提交

GSD 要求每个原子任务完成后立即生成独立提交，而非累积大量变更后一次性提交。这种原子化提交策略带来了多重收益：Git bisect 能够精确定位引入缺陷的任务；每个任务可以独立回滚，不影响其他已完成的任务；清晰的提交历史为未来会话中的 Claude 提供了可追溯的上下文；工作流的可见性与可观测性显著提升。

质量门禁体系

GSD v1.34.0 引入了完整的质量门禁分类体系，包含四种规范门禁类型。预检门禁（Pre-flight）在任务执行前验证前置条件；修订门禁（Revision）在代码变更后检查是否符合规范；升级门禁（Escalation）在发现潜在问题时将决策升级；中止门禁（Abort）在检测到关键问题时立即停止执行。这些门禁被集成到计划检查器与验证器代理中，实现了质量控制的自动化。

内置的质量门禁能够捕获真实问题：Schema 漂移检测会标记 ORM 变更中缺失的迁移；安全 enforcement 将验证锚定到威胁模型；范围缩减检测防止规划器在无声中放弃需求。这些机制确保了即使在完全自动化的工作流中，代码质量与安全底线也能得到保障。

可落地的工作流配置

对于希望采用 GSD 的团队，以下配置参数可作为起点。首先是模型配置文件选择，GSD 提供四档模型配置：quality 模式使用 Opus 进行规划与执行、Sonnet 进行验证，适合高价值项目；balanced 模式（默认）使用 Opus 进行规划、Sonnet 执行与验证，平衡质量与成本；budget 模式全链路使用 Sonnet/Haiku，适合原型开发；inherit 模式跟随运行时选择，适合非 Anthropic 提供商。团队可根据项目阶段与预算灵活切换，切换命令为 /gsd-set-profile <profile>。

其次是工作流代理配置。workflow.research 控制是否在规划前调研领域知识，建议保持开启；workflow.plan_check 启用计划验证循环，建议保持开启；workflow.verifier 启用执行后验证，建议保持开启；workflow.auto_advance 自动链接 discuss → plan → execute 步骤，适合高熟练度用户；workflow.discuss_mode 支持 discuss（访谈模式）与 assumptions（代码优先模式）两种讨论风格。这些配置可通过 /gsd-settings 交互式调整。

对于粒度控制，granularity 参数决定阶段的细分程度：coarse 模式阶段少、计划粗，适合快速验证想法；standard 模式平衡粒度与效率；fine 模式将工作拆分为更小的原子任务，适合复杂项目。mode 参数控制自动化程度：yolo 模式全自动化执行，interactive 模式在每步确认，适合学习阶段。

安装方面，开发者可通过 npx get-shit-done-cc@latest 一键安装，支持全局安装（所有项目共享）或本地安装（当前项目隔离）。支持 Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf 等多种运行时，安装过程会自动适配不同运行时所需的命令格式或技能文件格式。对于权限管理，GSD 推荐使用 --dangerously-skip-permissions 标志运行 Claude Code 以获得流畅的自动化体验，或在项目的 .claude/settings.json 中配置细粒度权限白名单。

与其他工具的差异化定位

在 AI 编码辅助工具链中，GSD 与现有项目形成了清晰的差异化定位。与 claude-mem（上下文压缩工具）相比，GSD 不是简单地压缩上下文，而是从根本上重构了上下文的结构与供给方式，通过规范化的文件体系与 XML 任务格式实现上下文质量的可持续管理。与 hermes-agent（多代理编排框架）相比，GSD 更侧重于单代理场景下的确定性行为优化，通过预定义工作流与质量门禁确保输出可预测，而非追求复杂的代理间协调能力。

GSD 的独特价值在于它为 Claude Code 量身定制了一套完整的「开发方法论」。它不是简单地提供更多提示词模板，而是从项目初始化、需求分析、任务规划、执行验证到交付完成的完整流程中，系统性地管理上下文质量。对于希望将 AI 辅助编码从「随机性尝试」提升为「可靠性工程」的团队，GSD 提供了一套经过实践验证的框架。

资料来源：GSD 官方 GitHub 仓库 (https://github.com/gsd-build/get-shit-done)