← 返回主页 2026 实战版 中文文档

AI 编码三剑客对比指南

gstack · OpenSpec · Superpowers — 三种哲学，三套方法，如何选 / 如何配 / 如何不踩坑

1. 三剑客全景

2026 年，给 AI Coding Agent 加 buff 的开源项目里，有三个最值得认真研究：

gstack

把 AI 当一支虚拟工程团队
作者：Garry Tan（YC 总裁）
License: MIT · v1.40 · 47 skills
  • 角色化：CEO / 设计 / 工程经理 / QA / 安全官 / 发布工程师
  • 主导思想：用 slash command 模拟创业团队的角色对话
  • 强项：产品视角的需求挑战 + 真实浏览器 QA + 一键 ship

OpenSpec

轻量级规范驱动开发框架
作者：Fission AI
License: MIT · v1.3 · npm 包
  • 规范优先：每个变更先生成 proposal/specs/design/tasks 四件套
  • 主导思想：人和 AI 在写代码前先在 spec 上对齐
  • 强项：Brownfield 项目（已有代码库）、长期维护的需求文档化

Superpowers

完整的软件开发方法论
作者：Jesse Vincent（obra）
License: MIT · 14 skills · Plugin 生态
  • 方法论驱动：TDD、子 Agent 委派、Git Worktree、系统化调试
  • 主导思想：让 Agent 像一个有纪律的工程师而非野生大模型
  • 强项：自主长时执行（数小时不偏离）+ 严格 TDD + 红绿重构
一句话区分
  • gstack 关心的是 "做对的产品"（What & Why）
  • OpenSpec 关心的是 "在共识上动手"（Spec & Alignment）
  • Superpowers 关心的是 "把代码做对"（How & Quality）

2. OpenSpec 详解

OpenSpec 来自 Fission AI（孵化于 YC），核心理念用一段官方哲学概括：

→ fluid not rigid       （流动而非刚性）
→ iterative not waterfall（迭代而非瀑布）
→ easy not complex      （简单而非复杂）
→ built for brownfield  （为遗留项目设计，不只是新项目）
→ scalable from personal projects to enterprises（个人到企业全适用）

2.1 安装与初始化

前置：Node.js 20.19.0+。

# 1. 全局安装 CLI
npm install -g @fission-ai/openspec@latest

# 2. 进入项目，初始化
cd your-project
openspec init

# 这会创建：
# openspec/
#   ├── changes/    # 每个变更一个文件夹
#   ├── specs/      # 项目级规范
#   └── config.yaml # 项目上下文 + 自定义规则

之后在 OpenCode / Claude Code 里直接说：

/opsx:propose 添加暗黑模式
# AI 会自动在 openspec/changes/add-dark-mode/ 下生成：
#   ✓ proposal.md  — 为什么做、要改什么
#   ✓ specs/       — 需求 + scenarios
#   ✓ design.md    — 技术方案
#   ✓ tasks.md     — 实现 checklist

2.2 核心工作流

propose
生成提案
→
explore
探索讨论
→
apply
按 tasks.md 实现
→
archive
归档到 specs/
命令用途什么时候用
/opsx:propose <name>一次生成 4 件套有清晰想法、想直接产出可执行计划
/opsx:explore探索模式，不动文件想法模糊、需要先和 AI 头脑风暴
/opsx:apply按 tasks.md 逐项实现提案已 review，准备动工
/opsx:archive归档变更到 specs/实现完成且测试通过
/opsx:new / continue / ff / verify展开版命令多人协作 / 复杂变更（需 openspec config profile 切换）

2.3 OpenSpec 实战经验

1Brownfield 项目的救命草

如果你接手一个已有 5 年代码的老项目，/opsx:propose 会先扫描你的 specs/ 和 config.yaml，生成符合现有风格的提案。比 gstack/Superpowers 更适合"已经有人写了一半"的场景。

2把 config.yaml 当作项目的 AI 宪法

# openspec/config.yaml
context: |
  Tech stack: TypeScript + Next.js + Prisma + PostgreSQL
  Conventions: 强制 conventional commits，禁止 default export
  Domain: B2B SaaS，多租户，主要用户是 IT 管理员

rules:
  proposal:
    - Keep proposals under 500 words
    - Always include "Non-goals" section
  tasks:
    - Each task max 2 hours
    - Test file path required for every code change

每次生成 proposal 都会自动套用这些约束，比每次提示词手写有效得多。

3提案生成后必读 design.md，不要直接 apply

AI 在 design 阶段经常做出"看似合理实则不符"的技术选型，比如给一个 5 人小项目引入 Kafka。建议：

/opsx:propose ...     # 生成
# 人工读 design.md 和 tasks.md
# 在 chat 里直接修正："把 Kafka 换成 BullMQ"
# AI 会更新文件，然后再
/opsx:apply

4archive 是宝藏，不要跳过

archive 会把变更归并入 openspec/specs/。半年后回看，相当于一份精确的 changelog + 设计决策史。比 git log 更有意义。

5用高推理模型，开干净 context

官方明确建议：Opus 4.5 或 GPT-5.2。OpenSpec 对模型推理深度敏感——弱模型会生成看起来对实际有逻辑漏洞的 spec。每次 propose 前 /clear 一下 context。

OpenSpec 的局限
  • 没有内置 QA 工具，找 bug 还得靠你
  • 没有 PR 自动化（不会帮你跑测试、推 PR）
  • 对"快速试 demo"场景偏重——你写一行能跑就好的 script，OpenSpec 反而拖你后腿

3. Superpowers 详解

Superpowers 来自 Jesse Vincent（前 Twitter / Best Buy 工程师，blog.fsck.com）。它最大的特点是：

Superpowers 不是命令集合，而是一套"软件工程方法论" TDD（测试驱动）、YAGNI（你不会用到）、DRY（不要重复）、子 Agent 委派、系统化调试、Git Worktree 隔离——这些被编码成 Skill，Agent 在做事前会自动检查并加载相关 Skill。

3.1 安装

Superpowers 已支持 8 种 Coding Agent，对应 8 套安装命令：

宿主安装命令
Claude Code（官方）/plugin install superpowers@claude-plugins-official
Claude Code（社区）/plugin marketplace add obra/superpowers-marketplace → install
Codex CLI/plugins → 搜 superpowers
Factory Droiddroid plugin install superpowers@superpowers
Gemini CLIgemini extensions install https://github.com/obra/superpowers
OpenCode对 Agent 说："Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md"
Cursor/add-plugin superpowers
GitHub Copilot CLIcopilot plugin marketplace add obra/superpowers-marketplace
验证：本机已通过 OpenCode 装好 Superpowers 在 ~/.cache/opencode/packages/superpowers@.../node_modules/superpowers/skills/ 下有 14 个 skill 目录。OpenCode 会在每次对话开始前自动检查并加载相关 skill。

3.2 14 个技能（按类别）

测试类

Skill用途
test-driven-developmentRED → GREEN → REFACTOR 循环。会强制删掉先写的实现代码，逼你先写 test。

调试类

Skill用途
systematic-debugging4 阶段根因分析：reproduce → isolate → fix → verify。包含根因追溯、纵深防御等子技术。
verification-before-completion声称"完成"前必须验证。证据先于断言。

协作类（核心）

Skill用途
brainstorming苏格拉底式设计精炼。写代码前用对话挖掘真实需求。
writing-plans把设计变成详细实施计划，每个任务 2-5 分钟，含完整代码 + 验证步骤。
executing-plans批量执行计划，含人工 checkpoint。
subagent-driven-development每个任务派一个新 subagent，两阶段 review（spec 合规 → 代码质量）。Superpowers 的招牌。
dispatching-parallel-agents并行子 Agent 工作流，处理 2+ 个独立任务。
using-git-worktrees用 git worktree 创建隔离工作区，干净 baseline。
requesting-code-review提交 review 前的 checklist。
receiving-code-review收到 review 后的处理流程，反对盲目同意。
finishing-a-development-branch分支完工选项：merge / PR / 保留 / 丢弃，并清理 worktree。

元能力

Skill用途
using-superpowers系统介绍，每次对话首条加载，强制 Agent 先 check skill 再行动。
writing-skills给团队写自己的 skill 用——遵循最佳实践 + 测试方法。

3.3 Superpowers 实战经验

1核心红利：长时自主执行

这是 Superpowers 与 gstack 最大的区别。Jesse 在 README 写道：

It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan you put together.

实测下来：写一个 plan（用 writing-plans skill），开 subagent-driven-development，喝杯咖啡回来 1-2 小时进度可以推进 60%-80% 还不偏离。核心机制是每个 task 派独立 subagent，跑完就退出，不会越界。

2TDD 是真的强制，不是口号

test-driven-development 这个 skill 写得最狠的一句：「Deletes code written before tests.」如果你违反 RED-GREEN-REFACTOR 顺序写了实现代码，Skill 会让 Agent 把你的代码删了，重新先写 test。第一次见到时会很震撼。

3用 git worktree 实现真并行

using-git-worktrees + dispatching-parallel-agents 组合可以同时开 3-5 条独立分支让多个 subagent 并行工作。每个分支隔离的好处是即使一个 subagent 写崩了，不影响主分支和其他分支。

4brainstorming 是入口 skill，永远先用

Superpowers 的 system prompt 里有一句：

You MUST use this before any creative work - 
creating features, building components, 
adding functionality, or modifying behavior.

意思是：Agent 看到任何"创造性任务"都必须先 invoke brainstorming。这避免了 Agent 在你模糊的需求上瞎写。

5verification-before-completion 是反"AI 装作完成"的终极武器

AI 经常会说"已修复"但实际没跑测试。这个 skill 强制：声明完成 = 必须出示运行命令的输出截图 / log，否则不算完。

Superpowers 的局限
  • 没有产品视角的"挑战需求"机制（gstack 强项）
  • 没有 spec 文件持久化（OpenSpec 强项）——所有约束在 skill 里，repo 里看不到
  • 对真实浏览器 QA、PR 自动 ship 这些工程后段动作不太管
  • 新手常觉得"Agent 太啰嗦"——它确实会反复确认，因为它真要做对

4. 三方对比

4.1 一图概览：哲学维度

gstack
产品视角
角色化对话
团队模拟
OpenSpec
规范优先
文档驱动
Brownfield
Superpowers
方法论纪律
子 Agent
TDD 强制

4.2 维度对比表

维度 gstack OpenSpec Superpowers
核心定位 虚拟工程团队 规范驱动框架 软件工程方法论
主要资产 47 个 slash command 4 件套 markdown（proposal/specs/design/tasks） 14 个自动激活的 skill
触发方式 显式调用 /xxx 显式调用 /opsx:xxx 自动触发（系统 prompt 注入）
Repo 持久化 部分：DESIGN.md/AGENTS.md 强：openspec/ 目录全部 commit 无：约束都在 skill 里
需求挑战 很强 /office-hours, /plan-ceo-review 中等 propose 自带 很强 brainstorming（苏格拉底）
架构设计 强 /plan-eng-review 强 design.md 强 writing-plans
TDD 支持 弱 仅在 /ship 提及 无 极强 强制 RED-GREEN-REFACTOR
子 Agent 委派 无 无 招牌 subagent-driven-development
真实浏览器 QA 招牌 /qa, /browse 无 无
PR / 部署自动化 强 /ship, /land-and-deploy 无 部分 finishing-a-development-branch
安全审计 强 /cso (OWASP+STRIDE) 无 无
调试方法论 中 /investigate 无 强 systematic-debugging
Brownfield 友好 中 设计目标 中
新手上手难度 中（命令多） 低（4 个命令） 低（自动触发）
团队协作 强 --team 模式自动同步 强 spec 直接 commit 中 各自安装
支持的宿主 10+（claude/codex/opencode/cursor/factory/kiro/hermes…） 25+（最广） 8（claude/codex/opencode/cursor/factory/gemini/copilot）
开源时间 / 体量 2024 / 大（含 browser、design 等二进制） 2024 / 中（CLI + spec 模板） 2025-10 / 小（纯 markdown skill）

4.3 SDLC 各阶段覆盖图

把软件开发生命周期切成 8 个阶段，看每个工具覆盖到哪儿：

阶段 动作 gstack OpenSpec Superpowers
① 需求 挑战需求、定义 What/Why ★★★★★ /office-hours ★★★ /opsx:propose ★★★★ brainstorming
② 设计 架构 + UI 设计 ★★★★ /plan-eng-review + /design-shotgun ★★★★ design.md ★★★ writing-plans
③ 任务拆分 把设计变成可执行任务 ★★★ /autoplan ★★★★★ tasks.md ★★★★★ writing-plans (2-5 min/task)
④ 实现 写代码 ★★★ Agent 自己 ★★★ /opsx:apply ★★★★★ subagent-driven-development
⑤ 测试 单元测试 + E2E ★★★★ /qa（真浏览器） ★ 仅作为 task 检查项 ★★★★★ TDD 强制
⑥ 审查 Code Review ★★★★ /review + /cso ★★ 提案审查为主 ★★★★ requesting/receiving-code-review
⑦ 发布 PR + 合并 + 部署 ★★★★★ /ship + /land-and-deploy ★ archive 仅文档归档 ★★★ finishing-a-development-branch
⑧ 复盘 Retro / 学习 ★★★★ /retro + /learn ★★ archive 历史 ★★ writing-skills（可写新技能）
互补图谱
  • gstack 在第 ① 和第 ⑦ 阶段最强（产品 + 发布）
  • OpenSpec 在第 ② 和第 ③ 阶段最强（设计文档 + 任务）
  • Superpowers 在第 ④ 和第 ⑤ 阶段最强（实现 + 测试）
三者几乎完美互补——这就是为什么"组合搭配"是更强的玩法。

5. 组合搭配指南

5.1 决策树：你应该用哪个？

Q1: 你的项目类型是？
个人脚本 / 一次性原型 → 三个都不需要，原生 Agent 够了。
新创业项目（greenfield） → 优先 gstack，因为你需要"挑战需求 + 快速 ship"。
遗留代码库（brownfield） → 优先 OpenSpec，因为你需要"先写 spec 再动代码"。
需要数小时无人值守 → 优先 Superpowers，因为它的 subagent + plan + TDD 链最稳。
Q2: 你最痛的问题是什么？
"AI 写得快但方向错" → gstack /office-hours 或 Superpowers brainstorming
"AI 改一处坏一片，没文档对齐" → OpenSpec
"AI 一会儿就跑偏，需要不断纠正" → Superpowers subagent-driven-development
"我要 ship，PR 流程太碎" → gstack /ship + /land-and-deploy
"测试太少，重构总崩" → Superpowers TDD
"需要真实浏览器测前端" → gstack /qa

5.2 经典组合配方

🥇 配方 A：黄金三件套（推荐生产项目）

OpenSpec  →  Superpowers  →  gstack
（规范）      （实现）         （发布）

实战流程：
1. /opsx:propose feature-x        # 产生提案 4 件套
2. 人工 review proposal/design
3. （由 superpowers 自动激活）brainstorming 二次精炼需求
4. （由 superpowers 自动激活）writing-plans 把 tasks.md 细化到 2-5 min
5. （由 superpowers 自动激活）subagent-driven-development 长时执行
6. （由 superpowers 自动激活）test-driven-development 强制 TDD
7. /qa https://staging.app        # gstack 真实浏览器 QA
8. /review                        # gstack staff 工程师审
9. /ship                          # gstack 推 PR
10. /land-and-deploy              # gstack 部署
11. /opsx:archive feature-x       # 把 spec 归档进 specs/

适用：有 1-3 人小团队、目标线上稳定运行的 SaaS / 工具产品。

🥈 配方 B：单兵作战双件套

Superpowers  +  gstack
（纪律）          （角色 + 浏览器）

跳过 OpenSpec 的场景：
- 你一个人开发，spec 主要在脑子里
- 改动不需要长期文档化
- 但要 TDD 纪律 + 真实浏览器 QA

流程：
1. /office-hours          # gstack：挑战需求
2. （superpowers）brainstorming 进一步追问
3. （superpowers）writing-plans 写计划
4. （superpowers）subagent-driven-development 执行
5. /qa                    # gstack 浏览器测
6. /ship                  # gstack 推 PR

适用：个人开发者的中型项目（几千到几万行代码）。

🥉 配方 C：极简文档双件套

OpenSpec  +  gstack
（规范）       （角色 + 工程后段）

跳过 Superpowers 的场景：
- 你的代码主要写少量逻辑、大量 glue
- TDD 反而拖慢进度
- 但你要保留团队对齐用的 spec 文档

流程：
1. /opsx:propose          # 写规范
2. /plan-ceo-review       # gstack CEO 视角再 push
3. /opsx:apply            # 实现
4. /review + /qa + /ship  # gstack 工程后段
5. /opsx:archive          # 归档

适用：研究 / Prototype / 数据脚本 + 内部工具。

🎯 配方 D：纯 Superpowers（极简方案）

个人写小工具、Hack、不打算长期维护，只要 14 个 skill 就够了：

brainstorming → writing-plans → 
subagent-driven-development → 
test-driven-development → 
finishing-a-development-branch

适用：单人 hackathon / 兴趣项目 / 学习练习。

🚨 配方 E：纯 gstack（产品创业团队）

YC 风格创业团队、CEO 兼工程师、一切以 ship 为先：

/office-hours → /autoplan → 
/qa → /ship → /land-and-deploy → 
/retro

适用：早期创业公司 (≤5 人)，要求每周 ship 多个功能。

📐 配方 F：纯 OpenSpec（强治理团队）

金融 / 医疗 / 政府等强合规行业，需要每个变更都有可审计文档：

/opsx:propose → 评审 → /opsx:apply → 
人工 PR review → /opsx:archive

适用：合规要求高、变更需要审计追踪的企业项目。

5.3 反模式（不要这样做）

❌ 反模式 1：三个都装但都不用 最常见的错误——一开始三个都装了，结果默认 prompt 一句"帮我写个登录"就让 Agent 直接动手。必须显式触发 skill，否则装了等于没装。
❌ 反模式 2：spec 写完就丢，不 archive OpenSpec 的精髓是 archive 到 specs/ 形成项目记忆。如果你只 propose+apply 然后删掉 changes，那就退化成了一次性 prompt 工具。
❌ 反模式 3：用 gstack 的 /qa 跳过 TDD 看到 /qa 能自动找 bug 就以为不需要单元测试了。错——/qa 找的是"集成 / 用户流"层级的 bug，单元逻辑还得 TDD。两者互补不可替代。
❌ 反模式 4：让 Superpowers 写 spec 然后丢给团队 Superpowers 的 plan 是给 Agent 看的，不是给同事看的。团队同步还是要用 OpenSpec 的 proposal/design.md 风格。
❌ 反模式 5：在 prototype 阶段强制 TDD Superpowers 的 TDD 在你需要"快速试 50 个 idea 看哪个 work"时反而拖累。这种阶段先关掉它（用户指令优先级最高），idea 落定后再开。

6. 实战经验总结

3 句话总结哲学差异
  • gstack 让 AI 像一个 团队。强项：产品视角 + 工程后段 + 真实浏览器。
  • OpenSpec 让 AI 和你 先在 spec 上对齐。强项：可审计、Brownfield、团队协作。
  • Superpowers 让 AI 像一个 有纪律的工程师。强项：长时自主、TDD、子 Agent。

10 条总体心法

1没有银弹，组合永远 > 单体

三者都是 MIT 开源、互不冲突、可以同时安装。生产项目里"OpenSpec 写规范 + Superpowers 实现 + gstack 发布"是高 ROI 组合。

2需求阶段宁错杀不放过

无论用哪一个，第一步永远是"挑战需求"：

  • gstack：/office-hours
  • OpenSpec：/opsx:explore 或 /opsx:propose
  • Superpowers：brainstorming（自动触发）

跳过这一步，后面所有努力都是在错的方向上跑。

3实现阶段用 Superpowers 的 subagent，不要让主 Agent 边写边改

Subagent 委派的好处：每个 task 拿到全新 context，不会被前面的"上下文污染"带偏；写完即退出，不会越界。这是 Superpowers 最值钱的机制，gstack 和 OpenSpec 都没有等价物。

4测试阶段需要双层覆盖

  • 下层（单元 / 集成）：Superpowers TDD
  • 上层（用户流 / 视觉）：gstack /qa

5发布阶段直接 gstack，省事

/ship + /land-and-deploy + /canary + /retro 这条流水线在三个工具中是最完整的。OpenSpec 的 archive 和 Superpowers 的 finishing-branch 都是文档级，不替代真正的 PR / deploy 自动化。

6项目记忆三层架构

同时用三个时，建议这样分层存储项目知识：

层级工具存什么
L1 战略层OpenSpec specs/领域规则、业务约束、API 契约
L2 战术层gstack /learn项目模式、坑、偏好（per-session 累积）
L3 操作层Superpowers skill方法论纪律（跨项目复用）

7注意"用户指令优先级最高"

三个工具都遵循同一原则：用户在 CLAUDE.md / AGENTS.md 中的明确指令永远覆盖 skill 默认行为。如果你说"这个项目不要 TDD"，Superpowers 的 TDD skill 也会让步。这是好事——可以根据项目阶段灵活调整。

8团队协作上 OpenSpec 最适合公开传播

gstack 的产物（design doc）在仓库里、Superpowers 的产物在 git 历史里、OpenSpec 的产物天生就在 commit 里，code review 时同事直接能看到 proposal/design/tasks，最适合多人协作环境。

9性能 / 成本考量

  • OpenSpec：每次 propose 用 token 多但只跑一次，便宜
  • Superpowers subagent：每个 task 一个 subagent，token 消耗大，但你可以 5 分钟搞定 1 小时活
  • gstack：单 skill 调用，性价比中等

预算紧的项目优先 OpenSpec，预算够的优先 Superpowers。

10每周做一次复盘

用 gstack 的 /retro global 跨所有工具看：哪个 skill 用得多、哪些 commit 来自哪个流程、个人 ship 节奏。这是数据驱动选工具最好的反馈回路。

给不同角色的最终推荐
角色推荐组合
个人 hacker纯 Superpowers
独立开发者Superpowers + gstack
2-5 人创业团队OpenSpec + gstack（核心）+ Superpowers（实现）
合规 / 企业团队OpenSpec（核心）+ Superpowers（实现）
纯产品 / 设计 CEO纯 gstack
研究 / 数据脚本OpenSpec（轻量）

最后的话

三个项目都是 2024-2025 年才发布的产物，迭代非常快。这份对比基于 2026 年 5 月的版本（gstack v1.40 / OpenSpec v1.3.1 / Superpowers 最新主分支），半年后再读可能某些细节已变。

但底层哲学的差异不会变——它们分别代表了 AI 编码三种不同的思考路径：角色化、规范化、方法论化。理解这三种思路，比记住具体命令更有价值。