前言：上下文腐化的困境

最近在探索 AI 辅助编程工具时，了解到了 GSD (get-shit-done) 这个规约驱动开发系统。说实话，这个名字本身就很有意思——简洁直接，透着一股务实劲儿。不过真正吸引我的，是它对上下文腐化 (context rot) 问题的治理思路。

作为一个经常使用 AI 编程工具的开发者，你可能也遇到过这样的情况：刚开始与 AI 对话时，它的输出质量很高，响应也很精准。但随着对话的进行，累积的上下文越来越多，AI 的输出质量开始明显下降。这不是模型的问题，而是一个被称为"上下文腐化"的现象。

研究表明，当单一会话的上下文总量逐渐超过 50% 之后，模型输出的质量会显著下降。这就像一个程序员在处理一个复杂项目时，需要记住的细节越来越多，但大脑的"工作记忆"是有限的，信息过载后判断力和创造力都会受到影响。

传统的 AI 编程工具往往采用单一大上下文的方式，把所有需求、设计、代码都塞进一个长对话中。这种做法在面对复杂项目时，很快就会触及上下文的瓶颈。而 GSD 的出现，正是为了解决这个问题。

GSD 的核心特点：粒度可控的工作流

作为后端程序员，我一直很看重"粒度"这个概念。好的系统设计应该是模块化的，每个模块职责清晰、边界明确。GSD 的设计理念与此不谋而合——小粒度的阶段性工作流和 subagent 实施。

GSD 将整个开发过程分解成多个阶段（phase），每个阶段都有明确的目标和边界。每个阶段由专门的 subagent 负责执行，这些 subagent 各司其职：有的负责研究需求，有的负责制定计划，有的负责执行，还有的负责验证结果。

这种设计有几个明显的优势：

首先是上下文隔离。 每个 subagent 只需要处理自己阶段相关的上下文，不会被其他阶段的信息干扰。这就像微服务架构中的服务隔离，每个服务只需要关注自己的业务逻辑。

其次是职责清晰。 研究阶段的研究员不需要知道执行阶段的具体细节，验证阶段的审核员也不需要了解规划阶段的决策过程。这种关注点分离让每个环节都能保持高质量输出。

最后是可追溯性。 每个阶段都会产生明确的产出物——研究文档、计划文档、验证报告等。这些文档不仅是开发过程的记录，也为后续的维护和迭代提供了清晰的参考。

对于习惯了后端开发思维的我来说，这种粒度可控的方式非常有吸引力。它让我能够像设计系统一样"设计"开发流程，而不是被动地跟着 AI 的节奏走。

实战体验：开发一个密码生成器

了解了 GSD 的基本理念后，我决定用它来尝试一个简单的项目——密码生成器。选择这个项目是因为它足够小，能在短时间内验证 GSD 的工作流；同时又有足够的功能点，能体现出 GSD 的各个阶段是如何协作的。

整个开发过程遵循了 GSD 的标准流程。首先是研究阶段，GSD 启动了一个研究 agent 来了解密码生成器的常见需求、安全标准和技术实现方案。这个 agent 产出了详细的研究文档，包括密码强度的定义、用户界面设计的考量点等。

接着是规划阶段，规划 agent 根据研究文档制定开发计划，将整个项目分解为多个阶段：用户界面设计、密码生成逻辑实现、安全性验证等。每个阶段都有明确的输入输出和验收标准。

执行阶段则是最实际的部分。GSD 的执行 agent 按照计划逐步实现功能，每完成一个阶段都会触发验证 agent 进行检查。这个过程很像 CI/CD 流水线——每个环节都有自动化测试把关。

特别值得一提的是，整个过程我并没有过多干预。我只是在项目开始时说明需求，然后 GSD 就自动推进了整个开发流程。这种感觉有点像在指挥一个训练有素的开发团队——你只需要说明目标，团队就会自动完成剩下的工作。

最终的结果是一个功能完整的密码生成器，界面简洁，逻辑清晰。但比结果更重要的是，我清晰地看到了 GSD 的工作流是如何把一个模糊的想法转化成具体产品的。

与 OpenSpec 的对比：规约制定的细腻之处

在探索 GSD 的过程中，我也想到了之前接触过的 OpenSpec。两者都是规约驱动开发的方式，但在规约制定的细节和严谨程度上，GSD 给我留下了更深的印象。

如果你对规约驱动开发感兴趣，可以看看我之前的文章 OpenSpec in OpenCode 使用心得。

OpenSpec 的理念是让开发者编写详细的规约文档，然后 AI 根据规约生成代码。这种方式的好处是规约编写者有充分的控制权，但问题在于规约的编写本身就需要大量时间和专业知识。而且，一旦规约有遗漏或歧义，AI 生成的代码就可能出现问题。

GSD 则采取了不同的策略。它不是要求开发者预先编写完整的规约，而是通过多个 agent 协作，逐步推导出完整的规约。研究 agent 负责收集需求和技术背景，规划 agent 负责制定实施方案，执行 agent 负责具体实现，验证 agent 负责质量把关。每个 agent 在完成自己工作的同时，也在不断地补充和完善规约。

这种方式的好处是规约的生成是动态的、迭代式的。你不需要在项目开始时就预见所有细节，系统会在推进过程中自动发现和填补规约的空白。这更像敏捷开发中的"涌现式设计"，而不是瀑布开发中的"预先设计"。

另外，GSD 在规约的验证上也更加严格。每个阶段的产出物都会被后续阶段作为输入使用，这实际上形成了一种自动的规约验证机制。如果规约不完整或有错误，后续阶段的 agent 就会遇到问题，从而暴露出规约的问题。

这种细腻和严谨，对于追求代码质量的后端程序员来说，是很大的加分项。它让我相信，用 GSD 开发的项目，不仅代码本身是可靠的，整个开发过程也是可追溯、可验证的。

结语

初次尝试 GSD，给我的感受是它确实抓住了 AI 编程的核心痛点。上下文腐化不是一个可以忽视的小问题，它会直接影响项目质量。GSD 通过粒度可控的工作流和专业的 subagent 机制，有效地控制了上下文的规模，保证了每个环节的输出质量。

作为一个后端程序员，我很欣赏 GSD 的设计哲学——它把软件工程中的一些经典原则（模块化、关注点分离、可追溯性）应用到了 AI 辅助开发中。这种融合传统智慧和新技术的方式，让 GSD 不仅仅是一个工具，更像是一套方法论。

当然，GSD 也不是银弹。对于非常简单的项目，使用 GSD 可能会有"杀鸡用牛刀"的感觉。但对于中等复杂度以上的项目，特别是需要团队协作、长期维护的项目，GSD 的价值就会充分体现出来。

关于 AI 辅助开发范式的更多讨论，可以参考我之前的文章 Vibe Coding: Harness Engineering 范式转变。

未来，我计划在更多项目中尝试 GSD，进一步探索它的能力边界。AI 辅助编程正在快速发展，而 GSD 这样的工具，让我们看到了一个可能的方向：不是用 AI 替代程序员，而是让 AI 成为程序员的得力助手，帮助我们更好地完成工作。

你试过 GSD 或其他规约驱动开发工具吗？欢迎在评论区分享你的经验。