在人工智能辅助开发工具快速演进的今天，如何让大语言模型在长时间编码任务中保持高质量输出，已成为工程实践的核心挑战。GSD（Get Shit Done）作为一个开源的元提示词与规格驱动开发系统，为这一问题提供了系统性的解决方案。该项目在 GitHub 上已获得超过三万颗星标，其核心理念是通过上下文工程与规格化实现自主且可持续的代码生成流程。
上下文损耗与规格化开发的根本矛盾
当开发者使用 Claude Code 等 AI 辅助编程工具时，有限的上下文窗口会随着任务推进而逐渐填充，导致模型输出质量下降，这种现象被称为「上下文损耗」（Context Rot）。传统做法是将所有需求、代码和对话历史堆砌在单一提示词中，期待模型能够理解全局并生成正确代码。然而，这种方式不仅浪费宝贵的令牌配额，还会让模型在信息过载中丢失重点，最终产出不符合预期的结果。
GSD 采用了截然不同的思路：将软件工程的方法论本身融入提示词设计，把开发过程分解为可独立执行的阶段，每个阶段都在全新的上下文中运行。规格化开发的核心在于，在实现之前先定义清晰的需求规格，然后让 AI 严格按照规格进行开发与验证。这种方式为 AI 提供了一个明确的「北极星」，使其在任何上下文窗口中都能聚焦于当前阶段的核心目标。
元提示词的分层架构设计
GSD 的元提示词系统采用了四层分离的架构设计，每一层都有明确的职责边界。第一层是斜杠命令（Slash Commands），定义「什么可以做」，包含权限配置和目标描述。第二层是工作流文件（Workflows），定义「如何逐步执行」，包含详细的过程步骤。第三层是参考文件（References），包含可复用的知识与技术规则。第四层是模板文件（Templates），定义输出格式的规范。
这种分层设计的优势在于模块化和可维护性。以 /gsd:new-project 命令为例，其执行上下文引用了五个文件：工作流文件定义了整个流程，询问技术文件提供提问技巧，品牌指南文件确保 UI 一致性，项目模板和需求模板则规范了输出格式。当某个环节需要调整时，只需修改对应的文件，而无需重新编写整个提示词。这种设计让元提示词本身也变得可版本化和可测试。
上下文工程的实践参数
在工程实践中，上下文工程需要关注几个关键参数。首先是上下文窗口的容量管理，GSD 通过状态栏实时显示当前上下文使用量，当使用率超过百分之七十时会变红预警，建议开发者切换到新阶段或主动压缩上下文。其次是文件引用的粒度控制，每次阶段切换时只加载当前任务所需的文件，避免加载不必要的代码或文档。
工作目录的结构化同样重要，GSD 约定使用 .planning/ 目录存储所有规划文件，包括 PROJECT.md（项目背景与目标）、REQUIREMENTS.md（需求清单）、ROADMAP.md（阶段路线图）和 STATE.md（当前状态）。每个阶段的输出都会写入对应的文件，下一阶段的入口只需读取这些文件即可重建完整的上下文。这种基于文件的持久化机制确保了任何时候都可以从断点恢复工作，而无需依赖会话记忆。
自主代理的编排模式
GSD 实现了两种代理 spawn 模式以适应不同的场景。通用模式（General-Purpose）下，代理通过提示词获得角色定义，适合处理同质化但参数不同的任务，例如四个并行运行的 researcher 代理分别负责技术栈研究、功能研究、架构研究和风险研究。注册代理模式（Registered Agent Type）下，代理类型在 Claude Code 中预先注册，适合处理固定角色的任务，如 roadmapper 和 verifier。
代理之间的通信完全通过文件进行，这避免了长对话带来的上下文膨胀问题。典型的编排流程是：先并行启动多个独立研究者代理，每个代理将结果写入独立文件；所有研究者完成后，合成器代理读取这些文件并生成汇总；最后路线图代理基于汇总和需求生成具体计划。这种「并行独立工作，序列依赖工作」的模式最大化了并行度，同时保持了上下文的高信噪比。
规格化验证与可追溯性
规格化开发的另一个核心优势是可验证性。GSD 为每个代理定义了清晰的成功标准（Success Criteria），这些标准以检查清单的形式呈现，代理在完成任务后需要逐项核对。例如，verifier 代理会检查实现是否满足 REQUIREMENTS.md 中定义的每条需求，必要时还会运行测试用例进行自动化验证。
由于所有中间产物都以文件形式保存，整个开发链路是可追溯的。如果路线图阶段出现异常，开发者可以检查合成器生成的 SUMMARY.md；如果合成结果有问题，可以回溯到各个研究者的原始输出。这种透明性不仅便于调试，也让团队成员能够理解 AI 的决策过程，建立对自动化流程的信任。
落地应用的监控要点
将 GSD 集成到实际项目中时，需要关注几个监控指标。第一是上下文使用率曲线，理想情况下应该呈现阶梯状，每个阶段开始时上升，阶段结束时回落；如果曲线持续高位运行，说明阶段划分不够清晰或单阶段任务过大。第二是代理执行时长，异常长的执行时间可能表明任务定义不够明确或代理陷入了循环。第三是提交频率，GSD 建议每个任务完成后都进行 Git 提交，过于稀疏的提交记录可能意味着任务颗粒度过大。
在回滚策略方面，由于所有阶段产物都保存在 .planning/ 目录中，任何阶段都可以单独回滚。建议在每个阶段开始前打标签（Tag），这样可以快速定位到任意历史状态进行对比分析。对于长时间运行的项目，可以设置每日自动化检查，验证 ROADMAP.md 中的进度是否与实际代码状态一致。
资料来源
本文档参考了 GSD 官方 GitHub 仓库（github.com/gsd-build/get-shit-done）以及 Codecentric 博客的技术分析文章。