开篇：一场正在重塑 AI 编程的运动
2026 年初，一个数字让整个 AI 开发者社区侧目：110,000+ GitHub Stars——这不是某个明星框架的单独成绩，而是三个工具的合计。它们都在做同一件事：让 AI 编程助手在动手写代码之前，先把事情想清楚。
这个运动有个名字——规范驱动开发（Spec-Driven Development, SDD）。Martin Fowler 发表了对 SDD 工具的系统分析（覆盖 Kiro、Spec Kit、Tessl 等工具）[1]；GitHub 推出 Spec Kit[2]，AWS 发布基于规范的 IDE——Kiro。当行业权威和云巨头都开始下注，SDD 从实验性工具变成了不可忽视的趋势。
而在这个赛道的开源前沿，三个项目脱颖而出，代表了三种截然不同的哲学：
轻量级规范对齐层——在写代码前让人和 AI 达成共识。解决 "写什么" 的问题。
AI 编程代理的完整开发方法论——强制 TDD、头脑风暴、代码审查全流程。解决 "怎么写" 的问题。
上下文工程系统——用独立子代理解决长会话的质量退化。解决 "怎么让 AI 一直写好" 的问题。
三者分别切入 AI 编程链条的不同环节，理论上甚至可以组合使用。这篇研报将从 11 个维度拆解三者的异同，帮你做出选型决策。
§1 SDD 是什么？为什么现在爆发？
Spec-Driven Development（规范驱动开发）的核心思想很直白：在让 AI 写代码之前，先用结构化文档描述清楚要做什么、为什么做、怎么做。这个"规范"（spec）可以是需求文档、技术设计、任务分解，甚至是验收标准——关键是，它是人类和 AI 都能理解的共识。
为什么 2025-2026 年突然爆发？因为行业碰到了天花板。
从 Vibe Coding 到工程化的四步进化：
阶段 1 Copilot 时代 — AI 补全代码行，开发者掌控全局
阶段 2 Vibe Coding — 扔给 AI 一句话需求，它写一整个功能
阶段 3 质量危机 — 代码能跑但不对，上下文丢失，大项目失控
阶段 4 SDD 兴起 — 用规范约束 AI，在自由和纪律间找平衡
行业信号密集出现：Martin Fowler 在个人网站发布对 Kiro、Spec Kit、Tessl 等 SDD 工具的系统分析[1]；GitHub 官方推出开源 Spec Kit[2]；AWS 发布基于规范的 IDE——Kiro；Apple Xcode 内置 Claude 和 Codex，代理编码走向主流。2026 年被预测为"代理编排年"，SDD 正是这个预测的具体落地。
"SDD 不是回到瀑布模型，而是在 AI 时代找到了'设计先行'的新形式。它承认了一个事实：AI 代码的质量，取决于输入的规范质量。"
§2 产品定位对比：各自解决什么问题？
三个工具虽然都归属 SDD 阵营，但它们解决的是 AI 编程链条上的不同痛点。理解这一点，是做选型决策的前提。
OpenSpec 的问题域
"我和 AI 对齐了吗？"
OpenSpec 插入在编码之前，生成提案（proposal）、任务分解（tasks）、技术设计（design）和规范差异（spec delta）四类文档。这些文档与代码共存于仓库，按"能力"（capability）组织，不依赖任何聊天会话。
核心哲学：流动而非刚性，迭代而非瀑布，为棕地项目而生。
目标用户：在已有代码库上做 AI 辅助增量开发的团队；使用多种 AI 工具（20+）的开发者；需要审查流程但不想要重型框架的人。
Superpowers 的问题域
"AI 能像高级工程师一样工作吗？"
Superpowers 不只管需求，它接管了从需求到交付的完整开发流程：苏格拉底式头脑风暴 → Git Worktree 隔离 → 微任务规划 → 严格 TDD（测试前写的代码会被删除）→ 自动代码审查。它利用心理学原理"说服"AI 代理遵循最佳实践。
核心哲学：测试优先，用证据而非假设验证，系统化降低复杂度。
目标用户：追求代码质量的 Claude Code 重度用户；需要让 AI 长时间自主运行（2 小时+）的高级工程师；信奉 TDD 的开发者。
GSD 的问题域
"为什么 AI 越用越差？"
GSD 瞄准的是一个让所有 AI 编码用户头痛的技术问题——上下文腐烂（context rot）。当对话越来越长，AI 代理的输出质量逐渐退化。GSD 的解决方案是为每个任务生成独立子代理，每个拥有全新的 200K token 上下文窗口。第 50 个任务和第 1 个任务，质量一致。
核心哲学：复杂性在系统中，不在你的工作流里。少数命令，刚好够用。
目标用户：受困于上下文腐烂的开发者；需要并行任务编排的项目；喜欢简单流程的"vibe coder"。
一句话区分：OpenSpec 是「写什么」的对齐工具，Superpowers 是「怎么写」的方法论框架，GSD 是「怎么让 AI 一直写好」的上下文引擎。三者不是竞品关系，更像是 AI 编程工具链的不同层。
§3 核心功能对比
以下矩阵覆盖 AI 编程助手用户最关心的 15 个功能维度。✅ 表示原生支持，⚠️ 表示部分支持或有替代方案，❌ 表示不支持。
关键差异解读：
TDD 执行力是最鲜明的分水岭。Superpowers 是唯一一个真正强制 TDD 的——它会删除在测试之前就写好的代码，这不是建议，是执行。GSD 的 /gsd:add-tests 提供了测试生成能力，但属于"后置"而非"先行"。OpenSpec 完全不涉及执行层。
上下文管理是 GSD 的杀手锏。独立子代理架构是技术维度上最优雅的解决方案。OpenSpec 用持久化文件"间接"保持上下文，Superpowers 用工作流一致性"软保持"，而 GSD 是架构层面的解决。
规范差异（Spec Delta）是 OpenSpec 的独特卖点——生成变更对比文档，让审查者无需看代码即可理解修改意图。这在团队协作和代码审查场景下价值巨大，是另外两个工具没有的。
§4 技术架构对比
三个项目都是 MIT 开源，但技术实现路径完全不同，反映了各自对"AI 编程助手该怎么被管理"的不同理解。
OpenSpec · 架构
TypeScript CLI——独立、纯粹、无依赖
技术栈：TypeScript 98.7%，Node.js 20.19.0+，支持 npm/pnpm/yarn/bun/nix 五种包管理器。
OpenSpec 的架构理念是"零耦合"。它不需要 API Key，不依赖 MCP 协议，不绑定任何特定 AI 工具。安装后，它在你的代码仓库中创建 .openspec/ 目录，规范文件以 Markdown 存储，与代码一起版本管理。
扩展性：通过 Profiles 系统（core/expanded）控制工作流复杂度。企业可通过自定义 Schema 强制额外产物（如 threat-model.md、compliance-review.md）。Workspaces 团队功能正在开发中。
Superpowers · 架构
Shell + Markdown 技能文件——"说服" AI 的心理学
技术栈：Shell 76.4%、JavaScript 12.4%、Python 5.7%、TypeScript 4.3%。无外部运行时依赖。
Superpowers 的架构特殊之处在于，它本质上是一套精心设计的 Prompt 工程。技能文件（Markdown）被注入 AI 代理的上下文，利用心理学原理引导代理行为。有人称之为"提示词巫术"，但效果确实存在——Hacker News 上 435 分、231 条评论 的讨论就是证明[3]。
扩展性：可组合技能系统，社区可贡献自定义技能。已入驻 Anthropic 官方插件市场，一键安装。但主要围绕 Claude Code 生态，其他平台支持较弱。
GSD · 架构
子代理编排 + 上下文隔离——解决根因问题
技术栈：JavaScript/Node.js，通过 npm 分发。基于 prompt 工程 + XML 格式化 + 子代理编排 + 状态管理。
GSD 的核心架构创新是子代理隔离。它不是在一个越来越长的对话中续写，而是为每个任务启动全新的子代理进程，每个拥有独立的 200K token 上下文窗口。通过 PostToolUse hook 实时监控上下文用量，在窗口不够时自动告警。波次执行（wave-based execution）允许独立任务并行、依赖任务顺序执行。
扩展性：支持 Claude Code、OpenCode、Gemini CLI、Codex 四个平台。提供 Quick Mode 跳过完整流程。Codebase Mapping 自动理解现有项目结构。
架构哲学对照
OpenSpec——工具无关（tool-agnostic），把规范做成独立的信息层
Superpowers——深度集成（deeply integrated），利用 AI 心理学驱动行为
GSD——架构解耦（architecturally decoupled），用进程隔离解决根因