Superpowers、GSD、OpenSpec、Spec-kit、Gstack
AI 编程智能体 Skill 框架深度对比
在 AI 辅助编程的浪潮中，“vibe coding”（随心所欲地让 AI 写代码）已经暴露出诸多问题：需求遗漏、上下文丢失、代码质量参差不齐。为了解决这些问题，社区涌现出一批 Skill 框架——它们通过结构化工作流、持久化规范和角色分工，将 AI 编程智能体从”聊天机器人”升级为”虚拟工程团队”。
本文将深入介绍五个主流框架：Superpowers、GSD、OpenSpec、Spec-kit 和 Gstack，并进行全面对比。
一、Superpowers —— 自动触发的开发方法论
仓库：obra/superpowers ⭐ 164k 作者：Jesse Vincent（Prime Radiant） 许可证：MIT
1.1 核心理念
Superpowers 不仅仅是一组工具，它是一套完整的软件开发方法论。它的核心哲学是：
- 测试驱动开发（TDD）：永远先写测试
- 系统化优于随意：流程优于猜测
- 复杂度缩减：以简洁为首要目标
- 证据优于声明：验证后再宣布成功
最大的特点是 Skill 自动触发——你不需要手动调用命令，智能体会根据当前任务上下文自动激活相应的 Skill。
1.2 包含的 Skill（方法）
Superpowers 包含以下核心 Skill，按开发流程分类：
核心开发流程
| Skill | 触发时机 | 功能描述 |
|---|---|---|
brainstorming |
写代码之前 | 苏格拉底式提问，提炼需求，探索替代方案，分段展示设计文档供验证 |
using-git-worktrees |
设计批准后 | 在新分支上创建隔离工作区，运行项目设置，验证测试基线 |
writing-plans |
设计批准后 | 将工作拆分为 2-5 分钟的小任务，每个任务包含精确文件路径、完整代码、验证步骤 |
executing-plans |
有计划后 | 分批执行任务，设置人工检查点 |
subagent-driven-development |
有计划后 | 为每个任务分派独立子智能体，两阶段审查（规范符合性 + 代码质量） |
test-driven-development |
实现阶段 | 强制执行 RED-GREEN-REFACTOR 循环：写失败测试→观察失败→写最少代码→观察通过→提交 |
requesting-code-review |
任务间隔 | 根据计划审查代码，按严重度报告问题，关键问题阻止进度 |
finishing-a-development-branch |
任务完成后 | 验证测试，提供选项（合并/PR/保留/丢弃），清理 worktree |
调试与验证
| Skill | 功能描述 |
|---|---|
systematic-debugging |
四阶段根因分析流程（包含 root-cause-tracing、defense-in-depth、condition-based-waiting） |
verification-before-completion |
防止”幻觉式成功”，强制执行最终验证检查 |
协作与元技能
| Skill | 功能描述 |
|---|---|
dispatching-parallel-agents |
并发子智能体工作流 |
receiving-code-review |
响应代码审查反馈 |
writing-skills |
创建新 Skill 的 TDD 框架（智能体可以编写自己的升级） |
using-superpowers |
Skill 系统的入门引导 |
1.3 命令（Commands）
| 命令 | 功能 |
|---|---|
/brainstorm |
启动结构化头脑风暴会话 |
/write-plan |
生成详细的实现计划 |
/execute-plan |
启动计划执行（通常涉及子智能体） |
1.4 钩子（Hooks）
- Session Start Hook：会话启动时自动注入
using-superpowers上下文，智能体立即感知自身能力
1.5 平台支持
支持 Claude Code（官方市场）、Gemini CLI、Cursor、OpenAI Codex CLI/App、OpenCode、GitHub Copilot CLI 等多平台。
二、GSD（Get Shit Done）—— 对抗上下文腐烂
仓库：gsd-build/get-shit-done ⭐ 56k 作者：TÂCHES 许可证：MIT 安装：
npx get-shit-done-cc@latest兼容平台：Claude Code、Gemini CLI、OpenCode、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Qwen Code、Cline、CodeBuddy 等 15+ 运行时
2.1 核心理念
GSD 要解决的核心问题是 “上下文腐烂”（Context Rot）：在长时间的 AI 编程会话中，随着上下文窗口被聊天噪声、部分决策和过时信息填满，智能体逐渐丢失需求跟踪、自相矛盾、代码质量下降。
GSD 的解决方案是： - 将大型项目拆分为原子任务 -
将项目状态外部化到持久文件（.planning/
目录），而非依赖聊天历史 -
每个执行单元在全新的上下文窗口中运行
2.2 核心工作流
GSD 将开发组织为结构化流程，每个阶段产出持久化的 Markdown 文档：
项目初始化
| 命令 | 功能 | 产出 |
|---|---|---|
/gsd-new-project |
一站式初始化：提问→研究→需求提取→路线图 | PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md |
/gsd-map-codebase |
扫描分析现有代码库的架构、技术栈和约定 | .planning/research/ |
四阶段开发循环
| 阶段 | 命令 | 说明 |
|---|---|---|
| 讨论（Discuss） | /gsd-discuss-phase 1 |
分析阶段灰色地带，捕获偏好（布局、交互、错误处理等），生成
CONTEXT.md |
| 计划（Plan） | /gsd-plan-phase 1 |
研究技术栈，创建结构化原子任务计划 |
| 执行（Execute） | /gsd-execute-phase 1 |
逐功能实现计划；每个任务在干净的上下文窗口中执行 |
| 验证（Verify） | /gsd-verify-phase 1 |
对照原始计划和需求检查输出，而非仅完成任务列表 |
其他实用命令
| 命令 | 功能 |
|---|---|
/gsd-spike |
运行 2-5 个聚焦实验，给出 Given/When/Then 判定 |
/gsd-sketch |
生成 2-3 个交互式 HTML 原型方案 |
/gsd-settings |
配置 GSD 行为（如讨论模式切换为 assumptions） |
/gsd-help |
显示所有可用命令帮助 |
2.3 关键技术概念
- 上下文工程：使用持久文件（
PROJECT.md、STATE.md、ROADMAP.md）维护状态，每次新会话加载这些文件以”全新启动” - 智能体编排：使用专门的智能体担任不同角色——研究者调查依赖、规划者创建任务、执行者编写代码、验证者/调试者确保质量
- 目标反向验证：验证阶段不仅检查代码是否运行，还检查结果是否匹配讨论和计划阶段定义的具体目标
- 内置质量门控：Schema 漂移检测、安全强制锚定威胁模型、范围缩减检测防止规划器静默丢弃需求
三、OpenSpec —— 规范先行的增量开发
仓库：Fission-AI/OpenSpec ⭐ 42.1k 作者：Fission AI（@0xTab） 安装：
npm install -g @fission-ai/openspec@latest许可证：MIT
3.1 核心理念
OpenSpec 认为 AI 辅助编码的瓶颈在于规范不足（Under-specification）。它确保人类和 AI 在实现之前就”做什么”和”怎么做”达成一致，并将这些需求版本化在 Git 中，而非埋在临时聊天历史里。
核心特色： - Delta 驱动：专为存量项目设计，追踪”增量规范”（新增、修改、删除的内容），无需重新规范整个系统 - 持久化上下文：规范作为 Markdown 文件存在于仓库中，可跨会话、跨开发者持久化 - 工具无关：通过斜杠命令支持 25+ AI 编程工具
3.2 核心工作流（三步生命周期）
核心配置（Core Profile）
| 命令 | 功能 | 产出物 |
|---|---|---|
/opsx:propose |
创建新变更，生成规划产物 | proposal.md（为什么和范围）、specs/（增量规范）、design.md（技术方案）、tasks.md（实现清单） |
/opsx:apply |
逐项实现任务 | 代码实现，逐项勾选任务清单 |
/opsx:archive |
归档已完成的变更 | 将增量规范合并到项目主规范目录，移动到归档目录 |
扩展配置（Expanded Profile）
| 命令 | 功能 |
|---|---|
/opsx:new |
创建新的变更目录 |
/opsx:continue |
继续之前的工作 |
/opsx:ff |
快进执行 |
/opsx:verify |
验证实现 |
/opsx:sync |
同步规范 |
/opsx:bulk-archive |
批量归档 |
/opsx:onboard |
项目引导 |
3.3 目录结构
1 | |
四、Spec-kit —— 规范即活文档
仓库：github/spec-kit ⭐ 90.1k 作者：GitHub 官方 安装：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git许可证：MIT 兼容：GitHub Copilot、Claude Code、Gemini CLI、Codex CLI 等
4.1 核心理念
Spec-kit 的核心思想是将开发重心从编写代码转向定义和精炼规范，以减少”vibe coding”并改善项目成果。规范不是静态文档，而是智能体持续引用和更新的活文档（Living Artifacts）。
关键特色： - 人在回路（Human-in-the-Loop）：设计为迭代式人工监督，每个阶段通常需要明确的人工批准 - 宪法驱动：通过 Constitution 阶段建立项目级别的治理原则
4.2 核心工作流（五阶段）
| 阶段 | 命令 | 功能 |
|---|---|---|
| 1. 宪法 | /speckit.constitution |
建立项目级治理原则、编码标准和指导方针 |
| 2. 规范 | /speckit.specify |
定义功能的”做什么”和”为什么” |
| 3. 计划 | /speckit.plan |
概述技术架构、设计选择和技术栈 |
| 4. 任务 | /speckit.tasks |
将计划拆分为小型、可操作、可测试的任务 |
| 5. 实现 | /speckit.implement |
指示智能体根据精炼的规范、计划和任务列表构建项目 |
4.3 高级功能
- 自动化：使用 Skills 自动化 SDD 流程的重复部分（如自动生成状态报告）
- 自定义：创建自定义 Skill 处理团队特定需求，强制合规，或与内部工具（Jira、GitHub Issues）集成
- 社区生态：支持依赖可视化、自动功能状态跟踪、自然语言项目管理等高级功能
五、Gstack —— 虚拟工程团队
仓库：garrytan/gstack ⭐ 80k 作者：Garry Tan（Y Combinator CEO） 许可证：MIT
5.1 核心理念
Gstack 是一个高度自主化（Opinionated）的框架，将 AI 编程智能体变成一支虚拟工程团队。每个斜杠命令对应一个专家角色：CEO、设计师、工程经理、发布经理、文档工程师、QA 等。
Garry Tan 的洞察是：不同开发阶段需要不同的认知模式。通过专门角色约束智能体关注特定职责，防止范围蔓延，确保产品规划、架构和质量保证不被忽视。
其推崇的完整冲刺流程为：Think → Plan → Build → Review → Test → Ship → Reflect
5.2 包含的 Skill（30+ 命令）
Gstack 提供了目前最丰富的命令集，按功能分类如下：
思考与规划阶段
| 命令 | 角色 | 功能 |
|---|---|---|
/office-hours |
顾问 | 起点命令，压力测试你的想法，挑战前提假设，提取具体能力 |
/plan-ceo-review |
创始人级策略师 | 挑战产品范围、排序和功能优先级 |
/plan-eng-review |
资深工程师 | 锁定架构，映射数据流，识别故障模式，浮现性能假设 |
/plan-design-review |
设计评审 | 从设计角度审查计划 |
/plan-devex-review |
开发者体验评审 | 从 DevEx 角度审查计划 |
/plan-tune |
计划调优 | 微调计划细节 |
/autoplan |
自动规划 | 自动生成完整计划 |
设计阶段
| 命令 | 功能 |
|---|---|
/design-consultation |
设计咨询会话 |
/design-shotgun |
快速生成多种设计方案 |
/design-html |
生成 HTML 设计原型 |
/design-review |
设计师-工程师混合审查，审计 UI 美学并原子化修正 |
/devex-review |
开发者体验审查 |
构建与审查阶段
| 命令 | 功能 |
|---|---|
/review |
资深工程师代码审查，发现通过标准 CI 的 bug，提供自动修复 |
/pair-agent |
结对编程智能体 |
/investigate |
问题调查 |
/careful |
谨慎模式，额外小心地执行操作 |
测试与安全阶段
| 命令 | 功能 |
|---|---|
/qa |
基于 Playwright 的真实浏览器测试，点击流程、捕获回归、提交修复 |
/qa-only |
仅执行 QA 测试，不修复 |
/cso |
安全官角色，执行自动化 OWASP + STRIDE 安全审计 |
/benchmark |
性能基准测试 |
发布与部署阶段
| 命令 | 功能 |
|---|---|
/ship |
发布工程师，处理部署并内置覆盖率审计 |
/land-and-deploy |
合并并部署 |
/canary |
金丝雀发布 |
/document-release |
生成发布文档 |
反思与运维
| 命令 | 功能 |
|---|---|
/retro |
冲刺回顾 |
/retro global |
全局回顾 |
/learn |
学习新知识 |
工具命令
| 命令 | 功能 |
|---|---|
/browse |
Web 浏览 |
/context-save / /context-restore |
上下文保存/恢复 |
/freeze / /unfreeze |
冻结/解冻文件 |
/guard |
守护模式 |
/codex |
调用 Codex |
/gstack-upgrade |
升级 Gstack |
5.3 工作流传递
Gstack 的强大之处在于各角色之间的信息传递： 1.
/office-hours 生成设计文档 2. /plan-ceo-review
读取设计文档进行范围审查 3. /plan-eng-review
基于审查结果编写测试计划 4. /qa 拾取测试计划验证实现 5.
/review 捕获 bug → /ship 验证修复 6.
/retro 反思整个过程
5.4 多平台支持
Gstack 支持 10+ AI 编程智能体：Claude Code、Codex、OpenCode、Cursor、Factory、Slate、Kiro、Hermes、GBrain 等。
六、全面对比
6.1 基本信息对比
| 维度 | Superpowers | GSD | OpenSpec | Spec-kit | Gstack |
|---|---|---|---|---|---|
| GitHub Stars | 164k | 56k | 42.1k | 90.1k | 80k |
| 作者 | Jesse Vincent | TÂCHES | Fission AI | GitHub 官方 | Garry Tan (YC CEO) |
| 许可证 | MIT | MIT | MIT | MIT | MIT |
| 安装方式 | 插件市场/CLI | npx 一键安装 |
npm 全局安装 |
uv tool install |
Git clone + setup |
| 命令数量 | ~15 个 Skill + 3 命令 | 10+ 核心命令 | 3-8 个命令 | 5 个核心命令 | 30+ 命令 |
| 仓库地址 | obra/superpowers | gsd-build/get-shit-done | Fission-AI/OpenSpec | github/spec-kit | garrytan/gstack |
6.2 设计哲学对比
| 维度 | Superpowers | GSD | OpenSpec | Spec-kit | Gstack |
|---|---|---|---|---|---|
| 核心定位 | 开发方法论 | 上下文管理 | 规范管理 | 规范驱动开发 | 虚拟工程团队 |
| 触发方式 | 自动触发 | 手动命令 | 手动命令 | 手动命令 | 手动命令 |
| 设计隐喻 | 超级英雄技能树 | 四阶段闭环 | 增量规范存档 | 宪法-规范-计划-任务 | 公司组织架构 |
| 解决的问题 | AI 开发混乱 | 上下文腐烂 | 需求欠规范 | vibe coding | 缺乏工程纪律 |
| 复杂度 | 中等 | 低 | 中等 | 中等 | 高 |
6.3 开发生命周期覆盖对比
| 阶段 | Superpowers | GSD | OpenSpec | Spec-kit | Gstack |
|---|---|---|---|---|---|
| 需求讨论 | ✅ brainstorming | ✅ discuss | ✅ propose | ✅ specify | ✅ office-hours |
| 产品审查 | ❌ | ❌ | ❌ | ❌ | ✅ plan-ceo-review |
| 架构设计 | ✅ writing-plans | ✅ plan | ✅ design.md | ✅ plan | ✅ plan-eng-review |
| 设计审查 | ❌ | ❌ | ❌ | ❌ | ✅ design-review |
| UI 设计 | ❌ | ❌ | ❌ | ❌ | ✅ design-html |
| 任务拆分 | ✅ writing-plans | ✅ plan | ✅ tasks.md | ✅ tasks | ✅ autoplan |
| 代码实现 | ✅ executing-plans | ✅ execute | ✅ apply | ✅ implement | ✅ (直接编码) |
| TDD | ✅ test-driven-dev | ❌ | ❌ | ❌ | ❌ |
| 子智能体 | ✅ subagent-driven | ❌ | ❌ | ❌ | ✅ pair-agent |
| 代码审查 | ✅ code-review | ❌ | ❌ | ❌ | ✅ review |
| 调试 | ✅ systematic-debug | ❌ | ❌ | ❌ | ✅ investigate |
| QA 测试 | ❌ | ✅ verify | ✅ verify | ❌ | ✅ qa (真实浏览器) |
| 安全审计 | ❌ | ❌ | ❌ | ❌ | ✅ cso |
| 发布部署 | ✅ finishing-branch | ❌ | ✅ archive | ❌ | ✅ ship/deploy |
| 回顾反思 | ❌ | ❌ | ❌ | ❌ | ✅ retro |
| 规范归档 | ❌ | ❌ | ✅ archive | ❌ | ❌ |
6.4 上下文管理策略对比
| 维度 | Superpowers | GSD | OpenSpec | Spec-kit | Gstack |
|---|---|---|---|---|---|
| 状态存储 | Skill 自动注入 | .planning/ 持久文件 |
openspec/ 目录 |
工作区活文档 | context-save/restore |
| 跨会话持久化 | 部分（通过 Hook） | ✅ 核心设计 | ✅ Git 版本化 | ✅ 文件持久化 | ✅ 显式保存/恢复 |
| 防上下文腐烂 | 子智能体隔离 | 原子任务+全新窗口 | 增量规范分离 | 活文档引用 | 冲刺式分阶段 |
6.5 适用场景推荐
| 场景 | 推荐框架 | 理由 |
|---|---|---|
| 个人开发者，快速上手 | Superpowers | 自动触发，零配置，安装即用 |
| 大型项目，长周期开发 | GSD | 专治上下文腐烂，原子任务隔离 |
| 存量项目，需求变更频繁 | OpenSpec | Delta 驱动的增量规范，与 Git 完美集成 |
| 团队协作，需求管理严格 | Spec-kit | 宪法驱动，人在回路，规范即活文档 |
| 全栈独立开发者/创始人 | Gstack | 覆盖全生命周期，虚拟团队角色分工 |
| 注重 TDD 和代码质量 | Superpowers | RED-GREEN-REFACTOR 强制执行 |
| 需要安全审计和 QA | Gstack | 内置 OWASP/STRIDE 审计 + 真实浏览器 QA |
| 需求文档溯源 | OpenSpec | 完整的 propose→apply→archive 归档链 |
6.6 组合使用建议
这些框架并非互斥，可以组合使用：
- OpenSpec + Superpowers：用 OpenSpec 管理规范和需求变更，用 Superpowers 的 TDD 和子智能体驱动开发来实现
- GSD + Gstack：用 GSD 的四阶段循环管理上下文，用
Gstack
的专家角色（
/qa、/cso、/review）补充质量保证环节 - Spec-kit + Superpowers：用 Spec-kit 的宪法和规范定义项目治理，用 Superpowers 的自动 Skill 触发来执行
七、总结
| 一句话评价 | |
|---|---|
| Superpowers | 🦸 “即插即用的超能力”——自动触发，TDD 为核，适合追求代码质量的开发者 |
| GSD | 🔄 “上下文永不腐烂”——四阶段闭环，原子任务隔离，长周期项目的守护者 |
| OpenSpec | 📋 “规范即代码”——Delta 驱动，Git 原生，存量项目的规范管理利器 |
| Spec-kit | 📜 “宪法治理”——从宪法到实现的五阶段流水线，团队协作的规范基石 |
| Gstack | 🏢 “一人即团队”——30+ 专家角色，从 CEO 到 QA 全覆盖，独立创始人的软件工厂 |
AI 编程的未来不在于更强的模型，而在于更好的工作流。选择适合你场景的 Skill 框架，让 AI 智能体从”随机生成代码”进化为”系统化交付软件”。