面对AI辅助编程的不确定性？比较Spec Kit、OpenSpec与GSD三大SDD框架

切记，规范是死的，人是活的，AI也是如此。过于僵化的流程，有时容易使其陷入类似于DDD、TDD那样的尴尬境地，让开发者感到束缚而非助力。

在AI辅助编程的多种范式中，Vibe Coding模式非常自由，依赖于开发者的“感觉”来驱动。而与之相对的 Spec Coding（规范驱动开发，Spec-Driven Development，简称SDD） 则更强调稳定性与确定性。实际上，Vibe Coding、Agent Coding、Spec Coding等多种模式之间并无绝对的优劣或冲突，它们更像是工具箱中不同用途的工具，适用于不同的人群、需求、模型复杂度或项目阶段。

很多时候，当AI的输出达不到预期时，问题不一定在于模型本身的能力不足，而可能在于我们使用它的方式。换一种辅助模式，或许就能打开新的局面。在没有AI的时代，开发者常戏称自己是在“面向搜索引擎编程”。遇到问题，第一反应是去问百度或Google。而当AI成为日常搭档后，我们就不能仅仅把它当作一个更聪明的搜索引擎来用了。它虽然擅长模式识别，但仍需要明确、无歧义的指令才能发挥最佳协作效果。

引入AI后，你是否会担心代码质量下降？担心它在复杂的业务场景中迷失方向？担心传统编码下的各种问题会被无限放大？那么，引入SDD模式或许是一个值得考虑的选项。

SDD 的核心思路是：将规范（Spec）置于核心地位，代码只是规范在特定语言和框架下的具体表达。因此，维护软件意味着维护其规范，而调试则意味着修正规范中的错误描述。这是一种思维和工作重心的根本性转变。

三大SDD框架概览

为了帮助你更直观地了解它们的定位和特点，我们先来看一张对比表格。

GitHub Spec Kit：结构化流程的重量级方案

Toolkit to help you get started with Spec-Driven Development

https://github.com/github/spec-kit

Spec Kit 的核心是一套严谨的七阶段门控流程：Constitution（宪法） → Specify（规范） → Plan（计划） → Tasks（任务） → Implement（实现） → Analyze（分析） → Archive（归档）。每个阶段都必须完成并通过，才能进入下一阶段，确保了过程的完整性和可审计性。

Spec Kit 还引入了 constitution.md 文件，允许团队在项目开始前就定义那些不可违背的“宪法”级规则——比如始终要求单元测试覆盖率达到特定标准，或必须遵守某个框架的特定版本。这些原则会在生成计划时被强制执行，从而确保所有技术决策都与组织的长期标准保持一致。

为了提升其可扩展性，Spec Kit 提供了扩展系统和预设系统：扩展（Extension）用于添加全新的命令和模板，例如集成Jira、增加V-Model测试可追溯性检查等；而预设（Preset）则用于在不添加新功能的前提下，通过覆盖现有模板和命令来定制工作流的行为方式。

---

OpenSpec：变更驱动的轻量级方案

Spec-driven development (SDD) for AI coding assistants.

https://github.com/Fission-AI/OpenSpec

OpenSpec 的核心机制是其独特的 Delta规范系统。它不会在每次变更时都重新描述整个系统，而是使用 ADDED、MODIFIED、REMOVED 标记来精准追踪相对于现有功能集的增量变更。这种轻量级的文档形态，特别适合在已有的开源项目或遗留代码库上进行持续迭代。变更完成并验证后，Delta 规范会被合并回主规范文件，而变更文件夹则会以日期为前缀移入归档目录，保留完整的历史记录。

其工作流通过几个核心命令驱动：/opsx:propose（创建变更提案）、/opsx:apply（执行实现）、/opsx:verify（验证结果）、/opsx:archive（归档合并）。对于需求明确的场景，可以用 /opsx:ff (fast-forward) 一次性生成所有规划文档；若需求仍在探索阶段，则可以用 /opsx:continue 命令逐步推进。

---

GSD（Get Shit Done）：执行编排的性能优化方案

A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Kilo, Codex, Copilot, Cursor, Windsurf, Antigravity, Augment, Trae, CodeBuddy, and Cline.

https://github.com/gsd-build/get-shit-done

GSD 要解决的核心痛点是AI编程中的 “上下文腐烂”（Context Rot） 问题——即在长会话中，随着上下文的不断累积，AI的输出质量会逐渐下降。它的解决方案颇为巧妙：将整个项目拆解为一系列小型、独立的原子任务，每个任务都在一个全新的200k Token上下文窗口中独立执行。主会话仅用于协调，其上下文使用率始终保持在一个很低的水平。

GSD采用波浪式并行执行策略：根据任务间的依赖关系将其分组成多个“波次”。独立任务可以并行执行，而有依赖关系的任务则按序推进。每个任务完成后都会立即生成一个原子的Git提交。

更重要的是，它引入了多级验证机制。通过计划检查器（Plan Checker）和验证器（Verifier）等智能体节点，对每个任务的执行进行严格把关。每个阶段的输出必须通过上一节点的检查，才能进入下一阶段，不符合规范的任务会被中止或打回重做。GSD v2 已从最初的Markdown提示框架演进为一个独立的TypeScript应用，可以直接控制智能体会话，实现上下文清理、精确文件注入、Git分支管理、成本追踪等高级功能。

如何选择适合自己的框架？

这三者并非简单的竞争关系，而是在SDD工具链的不同层次上各司其职：

• 选择 Spec Kit，如果你需要跨越多款工具协作、要求严格的阶段门控与完整的审计追踪，或者极其重视“宪法”级别的项目治理原则。
• 选择 OpenSpec，如果你主要在现有的代码库上进行持续迭代（Brownfield项目），希望以最小的规范编写代价，获得最大的上下文一致性保障。
• 选择 GSD，如果你长期使用Claude Code等工具，已经明显感受到了“长会话质量下降”的困扰，或者你对执行计划的编排和质量有极高要求，重视执行阶段的自动化而不仅仅是规范的编写。

当然，也有开发者觉得这些框架都过于“重”了，更倾向于从它们之中汲取灵感，整合成适合自己的“技能包”。这种灵活运用的思路，本身也是对计算机科学实践精神的体现。

写在最后

SDD不仅仅是一种工具，更是一种思维方式的转变。它将规范而非代码作为首要的维护对象，试图将AI从“猜测执行者”转变为“精确实现者”，从而让AI编程的核心从修改代码的机械工作，升级为设计和维护规范的系统性设计工作。

这些框架是很好的起点，但最终我们应该理解它们背后的原则，发展出适合自己约束条件的系统。SDD 本质上是系统设计，而最佳设计从来都是定制的。最好的解决方案，永远是适合你特定约束的方案。

技术的发展离不开社区的交流与共享。如果你对AI辅助编程的更多模式和最佳实践感兴趣，欢迎来 云栈社区 与大家一同探讨。

本文基于 GitHub Spec Kit、OpenSpec 与 GSD 官方文档及社区反馈整理。