Superpowers vs agent-skills vs gstack 深入对比
分析时间：2026年4月 | 目的：理解三大 Claude Code 插件/技能体系的差异，给出选型建议
一、三个项目是什么
它们解决的核心问题
Claude Code 虽然强大，但"裸跑"有两个痛点：
- 缺乏纪律 — 没有工作流程约束，AI 容易走捷径（"回头再补测试"）
- 缺乏角色分工 — 一个 AI 完成所有事，没有视角切换（产品、工程、设计、QA）
三个项目从不同角度解决了这些问题：
裸跑 Claude Code Superpowers gstack agent-skills
───────────────── ────────────── ────────── ─────────────
▲ ▲ ▲
│ │ │
你 强制流程 虚拟团队 文化注入
↓ ↓ ↓ ↓
随便问 7个阶段必须走完 25个角色/工具 20个技能编码
→ 看运气 → 质量可控 → 视角全面 → 标准一致
二、三个项目核心对比总表
| 维度 | 🔴 Superpowers | 🟢 agent-skills | 🔵 gstack |
|---|---|---|---|
| 作者 | Jesse Vincent (Prime Radiant) | Addy Osmani (Google AI 总监) | Garry Tan (YC CEO) |
| GitHub Stars | ~107K | ~21K | ~55K |
| 定位 | 工程纪律执行器 | 编码文化注入器 | 虚拟工程团队 |
| 核心哲学 | "AI 的问题不是能力，是缺乏纪律" | "技能编码了资深工程师的工作流" | "别让一个 AI 做所有事，给它不同角色" |
| 触发方式 | 自动触发 (auto-triggered) | 手动 /command 调用 | 手动 /command 调用 |
| 阶段数/技能数 | 7 个强制阶段 | 7 个命令 + 20 个技能 | 25+ 个命令/角色 |
| 强制 TDD | ✅ 强制（写实现前必须有失败测试） | ✅ 推荐（TDD 作为独立技能） | ❌ 非强制（QA 阶段测试） |
| 多模型交叉验证 | ❌ 不支持 | ❌ 不支持 | ✅ 支持 (Claude + Codex) |
| 浏览器测试 | ❌ 无 | ✅ DevTools MCP | ✅ 原生 Chromium (持久化) |
| 跨平台支持 | Claude Code, Cursor, Codex, Gemini CLI | Claude Code, Cursor, Gemini CLI, Copilot, Windsurf, Kiro | Claude Code, Codex, Gemini CLI, Cursor |
| 协议标准 | SKILL.md | SKILL.md | SKILL.md |
| 许可证 | MIT | MIT | MIT |
三、架构设计对比
3.1 Superpowers — 管道式架构 (Pipeline)
Superpowers 架构
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ session-start hook (入口) │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 7 阶段强制管道 (Mandatory Pipeline) │ │
│ │ │ │
│ │ ① Brainstorming ──► ② Spec ──► ③ Plan ──► ④ TDD ──► │ │
│ │ │ │
│ │ ⑤ Subagent Dev ──► ⑥ Code Review ──► ⑦ Finalize │ │
│ │ │ │
│ │ 每个阶段必须完成才能进入下一阶段 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 支撑机制 │ │
│ │ • 1% Rule: 只要1%概率相关，必须触发技能 │ │
│ │ • No Placeholders: 计划不允许出现 TBD/"类似任务" │ │
│ │ • Forced TDD: 先写实现? 删了重来 │ │
│ │ • Inline Self-Review: v5.0.6+ 内置自审查，省去子代理调用的开销 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
特点：自上而下的强制流程，像工厂流水线。
适合：需要质量保障的日常开发。
3.2 gstack — 角色式架构 (Role-based)
gstack 架构
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ 入口：用户通过 /command 按需调用角色 │
│ │
│ 角色层 (18个) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ CEO视角 │ │ 设计师 │ │ 工程经理 │ │ QA │ │ 安审 │ │
│ │ /office- │ │ /plan- │ │ /plan- │ │ /qa │ │ /cso │ │
│ │ hours │ │ design- │ │ eng- │ │ /browse │ │ │ │
│ │ │ │ review │ │ review │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │ │
│ └────────────┴────────────┼────────────┴────────────┘ │
│ ▼ │
│ 工具层 (7个) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ /codex │ │ /freeze │ │ /guard │ │ /setup- │ │ /gstack- │ │
│ │ 交叉验证 │ │ 编辑锁定 │ │ 全防护 │ │ deploy │ │ upgrade │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 关键特性： │
│ • 持久化浏览器守护进程 (不依赖 MCP，延迟更低) │
│ • 多 Agent 并行 (Conductor 调度 10-15 个独立会话) │
│ • 编辑锁定 (/freeze) 防止范围蔓延 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
特点：按需调用的角色团队，像指挥一个工程部门。
适合：产品从0到1快速发货。
3.3 agent-skills — 插件式架构 (Library)
agent-skills 架构
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ 用户通过 /command 调用技能 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 技能库 (20个独立技能，按生命周期组织) │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Define │→│ Plan │→│ Build │→│ Verify │→│... │ │ │
│ │ │ /spec │ │ /plan │ │ /build │ │ /test │ │ │ │
│ │ │ idea- │ │ task- │ │ TDD │ │ debug │ │ │ │
│ │ │ refine │ │ breakdown│ │ frontend│ │ browser │ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Review │→│ Ship │ │ Cross- │ │ │
│ │ │ /review │ │ /ship │ │ cutting │ │ │
│ │ │ code- │ │ git- │ │ security │ │ │
│ │ │ simplify│ │ workflow│ │ perf │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 每个技能的内部结构 │ │
│ │ │ │
│ │ • Metadata (YAML frontmatter, ~100 tokens) │ │
│ │ • 核心流程 (编号步骤 + ASCII图) │ │
│ │ • 反理性化表 (Anti-rationalization: 预判AI会找什么借口) │ │
│ │ • 红旗告警 (Red flags: 违反技能的可观察行为) │ │
│ │ • 验证门 (Verification gates: 带证据要求的退出条件) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 关键特性： │
│ • 渐进披露 (Progressive Disclosure)：按需加载，节省 Token │
│ • 跨平台：可在任何支持 Markdown 的 AI 编码工具中运行 │
│ • 编码了 Google 内部的工程文化 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
特点：可组合的技能库，像安装了一个"资深工程师"的知识库。
适合：团队标准化、建立编码规范。
四、能力矩阵对比
4.1 开发生命周期覆盖
Superpowers agent-skills gstack
──────────── ───────────── ──────
需求澄清 ✅ Brainstorming ✅ /spec + idea-refine ✅ /office-hours
(Socratic问答) (PRD-first) (YC式逼问)
架构设计 ⚠️ 弱 ⚠️ 弱 ✅ /plan-eng-review
/plan-design-review
任务规划 ✅ Writing Plans ✅ /plan + task- ⚠️ 弱
(详细到文件路径) breakdown
编码实现 ✅ Subagent Dev ✅ /build + TDD ✅ 各角色按需调用
(并行子代理)
测试 ✅ 强制 TDD ✅ /test + Test ✅ /qa + /browse
(红-绿-重构) Pyramid (真实浏览器)
代码审查 ✅ Code Review ✅ /review + code- ✅ /review + /codex
(按严重级别分级) simplify (交叉模型验证)
安全审计 ⚠️ 弱 ✅ 独立 skill ✅ /cso (OWASP/STRIDE)
性能优化 ❌ 不支持 ✅ 独立 skill ✅ /benchmark (CWV)
部署上线 ✅ Finalize ✅ /ship ✅ /ship + /land-and-
(合并/PR) (灰度发布+监控) deploy
复盘回顾 ❌ 不支持 ❌ 不支持 ✅ /retro (团队指标)
4.2 Token 效率对比
项目启动时的 Token 开销（估算）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Superpowers ████████████████████████████ ~15K-25K tokens
(session-start加载全部技能元数据)
gstack ██████████████████ ~10K-15K tokens
(只加载匹配的命令及其依赖)
agent-skills ████████ ~3K-5K tokens
(渐进披露，只加载metadata)
裸跑 Claude ██ ~1K tokens
(无额外加载)
─────────────────────────────────────────────────────
注：实际执行阶段 token 消耗取决于具体任务复杂度
4.3 学习曲线
易上手程度
────────
agent-skills ═══╗████████████████████ ★★★★☆ (最易)
║ 20个技能命名清晰，独立使用
║ 类似"命令菜单"体验
gstack ═══╬███████████████ ★★★☆☆
║ 25+命令需要记忆
║ 但使用场景明确
Superpowers ═══╝██████████ ★★☆☆☆ (最复杂)
║ 7阶段强制流水线
║ 违反规则会被"惩罚"(删代码)
五、代表特色功能深度对比
5.1 Superpowers — 强制 TDD
这是三个项目中唯一强制 TDD 的：
普通工作流：
写代码 → 跑测试 → 通过 ✅
Superpowers 工作流：
写测试(红) → 跑测试(确认失败) → 写实现(绿) → 重构 → 跑测试
│
└── 如果先写了实现代码 → ❌ 自动删除实现，强制重新开始
5.2 gstack — 角色切换 + 浏览器测试
/qa 命令的完整流程：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 启动持久化 Chromium 实例（非 MCP，原生二进制）
2. 打开目标页面 URL
3. 模拟用户点击流程（保持 Cookies/Session）
4. 截图 + 控制台错误检查
5. 发现 Bug → 自动修复 → 生成回归测试
6. 报告：通过/失败 + 截图证据
/codex 命令：
→ 同一份代码同时发给 Codex CLI
→ 两个模型各自审查
→ 输出交叉对比：哪些发现重叠，哪些是各自独有的
5.3 agent-skills — 反理性化表 (Anti-Rationalization)
这是 agent-skills 最独特的设计——每个技能都预判了 AI 可能找的借口：
反理性化表示例（来自 code-review skill）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 可能说的借口 技能的预置反驳
────────────────── ──────────────────
"这只是个小改动，不用审查" "90%的生产事故来自'小改动'"
"测试回头再补" "回头=永远不会。现在补。"
"这个函数太复杂了，但能工作" "能工作 ≠ 应该合并。先简化。"
"我已经在脑子里审查过了" "代码审查是外显的过程，不是内隐的思考"
"改动超过100行了，是因为..." "拆成多个PR。不可审查=不可合并。"
这种设计的价值在于：AI 模型天然倾向于走捷径，反理性化表在技能层面就截断了这些倾向。
六、选型建议
6.1 决策树
你想用 Claude Code 做什么？
│
▼
┌──────────────────────────────────────────────────┐
│ 你的角色？ │
├──────────────────────────────────────────────────┤
│ │
│ 个人开发者 │
│ ├── 自己在0到1做产品 → gstack │
│ │ (CEO/设计师/QA一整套角色) │
│ │ │
│ ├── 日常编码但想要代码质量 → Superpowers │
│ │ (强制流程保障质量) │
│ │ │
│ └── 学Google的最佳实践 → agent-skills │
│ (编码了资深工程师的知识) │
│ │
│ 团队/小团队 │
│ ├── 建立统一编码规范 → agent-skills + Superpowers │
│ │ (文化注入+流程执行) │
│ │ │
│ └── 快速迭代+质量兼顾 → gstack + agent-skills │
│ (角色视角+工程标准) │
│ │
│ 企业/大团队 │
│ └── 标准化全流程 → agent-skills + gstack │
│ (标准定义+角色分工) │
│ │
└──────────────────────────────────────────────────┘
6.2 按场景推荐
| 你的场景 | 推荐方案 | 理由 |
|---|---|---|
| 新手刚接触 | agent-skills | 上手最容易，渐进披露不吓人 |
| 日常功能开发 | Superpowers | 强制流程带你养成好习惯 |
| 做自己的产品 | gstack | 一个命令集齐CEO到QA |
| 团队规范建设 | agent-skills + Superpowers | 先定义标准，再强制执行 |
| 全栈Web应用 | gstack + agent-skills | gstack测浏览器，agent-skills把关代码 |
| 高安全要求项目 | agent-skills + gstack | agent-skills有安全技能，gstack有安全官角色 |
| 不想改变工作流 | agent-skills | 手动调用，不强制流程 |
6.3 三个项目的本质差异（一句话总结）
Superpowers = 教练 → 盯着你，逼你走完标准流程
agent-skills = 教科书 → 教你怎么写生产级代码
gstack = 团队领导 → 帮你叫齐各路专家开会
七、能否一起用？
可以，而且很多人这么干。 社区流行的组合方式：
方案 A：全都要（进阶用户）
gstack (决策层) agent-skills (标准层) Superpowers (执行层)
───────────────── ──────────────────── ─────────────────────
/office-hours /spec Brainstorming + TDD
→ 想清楚做什么 → 写清楚规格 → 规范地做
/plan-ceo-review /plan Writing Plans
→ 想清楚为什么做 → 拆清楚任务 → 拆到文件级
/qa + /browse /review + /code-simplify Code Review
→ 测清楚效果 → 审清楚质量 → 合并代码
方案 B：轻量组合（实用派）
agent-skills + gstack = 你按需调用，想用什么用什么
agent-skills + Superpowers = 文化注入 + 流程强制
gstack + Superpowers = 角色视角 + 纪律执行
注意事项
- 不要一起加载全部三个的完整技能集 → Token 爆炸（可能 50K+）
- 建议只安装你实际需要的
/command前缀 - 使用
~/.claude/settings.json控制哪些技能目录被加载
八、最终结论
| 项目 | 一句话评价 | 适合人群 | 不适合人群 |
|---|---|---|---|
| Superpowers | 目前最成熟的强制工程纪律方案 | 有经验的开发者、团队 | 只想快速原型的新手、小改动频繁的人 |
| agent-skills | 最中立、可移植、教学型的方案 | 所有想写出更好代码的人 | 不想改变工作习惯的人 |
| gstack | 最功能丰富、角色最全的方案 | 独立开发者、从0到1的创业者 | 只需要简单编码辅助的人 |
个人建议：如果只能选一个开始，从 agent-skills 入手——学习成本最低，没有强制流程的压力，但能学到资深工程师的思维模式。等你熟悉了再决定是否需要 Superpowers 的纪律或 gstack 的角色。
参考链接：