gstack + Superpowers + OpenSpec 三器合一：AI 编程工程化共存方案

gstack + Superpowers + OpenSpec 三器合一：AI 编程工程化共存方案

引言：AI 编程的三个断层

AI 辅助编程进入 2026 年，社区已经形成共识：单靠一个 AI 模型裸写代码远远不够。实际工程中面临三个核心断层：

  1. 需求断层：AI 在聊天记录里”记住”需求，三轮回合后就开始 drift。没有结构化的规范文档，需求就是一阵风。
  2. 质量断层：AI 写代码快，但写测试慢、写文档懒、做边界检查敷衍。没有硬性约束，代码量上去了，技术债也上去了。
  3. 流程断层：从想法到上线，中间隔着设计评审、代码审查、QA 测试、安全审计、发布部署。AI 擅长单点任务，但端到端的工程流程需要有人（或规则）来编排。

三个断层催生了三个工具，恰好各管一段：

工具 管什么 核心机制 仓库
OpenSpec 做什么（需求） DAG 产物依赖图，写代码前先对齐需求 Fission-AI/OpenSpec ⭐48.8k
Superpowers 做得好（质量） HARD-GATE + TDD 铁律，自动拦截低质量代码 obra/superpowers ⭐196k
gstack 怎么做、怎么发（流程） Browse 引擎 + 7 阶段 Sprint 管线，虚拟工程团队 garrytan/gstack ⭐98.8k

关键不在于”三个工具都装上”，而在于它们之间怎么自动串联。本文用一个完整的”暗色模式”案例，拆解三者共存的完整方案。

一、三器定位：各管一段，互不冲突

1.1 OpenSpec —— 规范驱动的需求管理层

OpenSpec 由 Fission-AI 团队开发，核心理念是 Spec-Driven Development（SDD）：在写任何代码之前，人类和 AI 先在规范上达成一致。

核心工作流（三步生命周期）：

1
/opsx:propose → /opsx:apply → /opsx:archive
  • /opsx:propose "你的想法"：AI 生成 proposal.md（为什么做）、specs/（需求场景）、design.md（技术方案）、tasks.md（任务清单），全部落盘到 openspec/changes/<change-name>/。
  • /opsx:apply：按 tasks.md 逐项实现。
  • /opsx:archive：将 Delta 规范合入主规范 openspec/specs/，变更归档。

OpenSpec 的设计哲学： - 流动而非僵化：随时更新任何产物，没有严格的阶段门禁。 - 迭代而非瀑布：增量开发，持续演进。 - 为棕地而生：不假设从零开始，适配已有项目。

1.2 Superpowers —— 自动触发的质量方法论

Superpowers 由 Jesse Vincent（Prime Radiant）打造，它不是一组 slash 命令，而是一套自动触发的开发方法论。核心哲学：

  • TDD 铁律：先写失败测试，再看测试失败，再写最小实现，再看测试通过，最后重构。永远不许先写代码再补测试。
  • 系统化而非随性：流程优于猜测。
  • 证据优于声明：验证后才宣布完成。

Superpowers 的核心技能矩阵：

类别 技能 触发时机
设计 brainstorming 写代码之前，强制走设计流程
规划 writing-plans 设计批准后，拆分为 2-5 分钟的小任务
执行 subagent-driven-development 每个任务用全新子代理执行，两阶段审查
测试 test-driven-development 写代码时自动触发 RED-GREEN-REFACTOR
审查 requesting-code-review 任务完成后自动触发
收尾 finishing-a-development-branch 所有任务完成后，合并/PR/清理

Superpowers 最关键的机制是 HARD-GATE：

1
2
3
Do NOT invoke any implementation skill, write any code, scaffold
any project, or take any implementation action until you have
presented a design and the user has approved it.

这是硬门禁——设计没批准，代码一行都不许写。

1.3 gstack —— 虚拟工程团队的全流程管线

gstack 是 Garry Tan（Y Combinator CEO）的开源”软件工厂”。他将 20 年的工程经验编码为 23 个专家角色和 8 个强力工具，将 Claude Code 变成一支虚拟工程团队。

gstack 的 7 阶段 Sprint 管线：

1
Think → Plan → Build → Review → Test → Ship → Reflect

核心角色矩阵：

阶段 命令 角色 职责
Think /office-hours YC 合伙人 6 个强制问题重新框定产品
Plan /plan-ceo-review CEO/创始人 挑战范围，找 10 星产品
Plan /plan-eng-review 工程经理 锁定架构、数据流、测试矩阵
Plan /plan-design-review 资深设计师 设计维度打分，AI Slop 检测
Plan /plan-devex-review DX 负责人 开发者体验审查
Build /autoplan 评审管线 一键串行 CEO→设计→工程→DX 评审
Review /review 资深工程师 找出 CI 通过但生产爆炸的 bug
Test /qa QA 负责人 真实 Chromium 浏览器操作验收
Test /cso 安全官 OWASP Top 10 + STRIDE 威胁模型
Ship /ship 发布工程师 测试→版本→CHANGELOG→PR
Ship /land-and-deploy 发布工程师 合并→等 CI→部署→验证
Ship /canary SRE 部署后监控
Reflect /retro 工程经理 周回顾，团队维度拆分

gstack 的杀手锏——Browse 引擎： AI 通过 Playwright Chromium 获得”眼睛”。/qa 能打开真实浏览器、点击按钮、截图验证、检查 localStorage，而不仅仅是读代码。

1.4 为什么三者不冲突

三个工具在同一个 Claude Code 会话里共存，因为它们管不同层次，状态存储在不同目录：

工具 状态目录 产物形式
OpenSpec openspec/ proposal.md、specs/、design.md、tasks.md
Superpowers CLAUDE.md + skill 文件 行为规则（HARD-GATE、TDD 铁律）
gstack .gstack/ + ~/.claude/skills/gstack/ 计划文件、评审结论、学习记录

三套状态互不干扰。OpenSpec 的 /opsx:* 命令、Superpowers 的 TDD 铁律、gstack 的 /ship /review /qa 技能，全部在同一个 REPL 里可用。

二、核心：三器如何自动串联

这才是最关键的部分。三个工具不是”你用完我再用”的接力赛，而是在同一个会话里自动触发、互相衔接。四个关键串联点：

串联点 1：OpenSpec 产物 → gstack 评审输入

OpenSpec 的 /opsx:propose 生成四个文件落盘到 openspec/changes/<change-name>/。gstack 的 /autoplan 启动 CEO → design → eng → DX 四类评审时，每个评审角色会直接读取工作区文件。因为 OpenSpec 的产物就在那里，评审角色自然能读到 proposal、specs 和 design。

你不需要手动复制粘贴。 OpenSpec 写完产物，gstack 的评审直接读文件。这就是文件系统作为集成总线。

串联点 2：Superpowers HARD-GATE → 自动拦截编码

Superpowers 的 brainstorming skill 包含 HARD-GATE：没有批准的设计就不许写代码。

这意味着两件事： 1. 防御作用：即使你跳过了 OpenSpec 直接说”帮我加个功能”，Superpowers 也会强制你先走设计流程。 2. 衔接作用：如果 OpenSpec 已经生成了 design.md，你把它展示给 Superpowers 看，它会把这份设计当作”已批准的设计”，HARD-GATE 自动放行。

OpenSpec 的产物恰好满足了 Superpowers 的门禁条件。

串联点 3：Superpowers TDD → gstack /review 质量提升

Superpowers 的 TDD 铁律确保每个功能都有对应的测试。/review 不关心代码是怎么写出来的——它只看 diff。但因为 TDD 铁律的存在，/review 可以用测试作为行为契约来验证实现是否正确，审查质量因此大幅提升。

串联点 4：gstack /ship → OpenSpec /opsx:archive

/ship 发布完成后，你运行 /opsx:archive。归档过程读取 openspec/changes/<change-name>/ 下的 Delta 规范，自动合并到 openspec/specs/ 主规范里。

归档不触发发布，发布不触发归档。它们是两个独立步骤，但顺序固定：先 /ship 上线，再 /opsx:archive 收尾。归档后，openspec/specs/ 目录始终反映系统当前状态，下次再加功能时，OpenSpec 的 AI 会读取这些 specs 作为上下文。

三、实战：暗色模式功能全流程

下面用一个完整案例——给一个 Web 应用加暗色模式——展示三器合一的完整工作流。重点不是”做了什么”，而是每一步怎么触发下一步、工具之间怎么衔接。

架构总览

1
2
3
4
5
/opsx:propose → /autoplan → (Superpowers TDD 自动写代码) → /review → /qa → /ship → /opsx:archive
     │               │                    │                    │       │      │         │
     ▼               ▼                    ▼                    ▼       ▼      ▼         ▼
  生成 4 个      4 个评审角色        HARD-GATE 放行          找生产   浏览器   发布     归档到
  规范文件       读取产物评审         每步 RED-GREEN         bug    验收    上线     specs/

第 1 步：OpenSpec 生成需求产物

1
/opsx:propose add-dark-mode

输入自然语言需求：

  • 设置页加主题切换开关
  • 支持跟随系统偏好
  • 用户选择持久化到 localStorage
  • 所有页面即时切换

OpenSpec 的 DAG 引擎解析依赖关系，自动生成四个产物：

1
2
3
4
5
6
openspec/changes/add-dark-mode/
├── proposal.md          ← 为什么做：用户夜间阅读体验差，竞品已有
├── specs/ui/spec.md     ← 需求场景（GIVEN/WHEN/THEN）
├── design.md            ← 技术方案（CSS 自定义属性 + React Context）
├── tasks.md             ← 任务清单（4 组 8 个子任务）
└── .openspec.yaml       ← 变更元数据

DAG 引擎告诉你：proposal 已完成，specs 和 design 可以并行创建，tasks 等它们都完成才能开始。你不需要手动管理这个顺序——/opsx:propose 一次性生成全部产物。

🔗 串联触发： 产物落盘到文件系统后，gstack 的评审角色可以直接读取。

第 2 步：gstack /autoplan 读取产物做评审

1
/autoplan

/autoplan 自动串起四类评审，每个评审角色读取 openspec/changes/add-dark-mode/ 下的对应文件：

评审角色 读取文件 关注问题
CEO 评审 proposal.md 暗色模式是不是当前优先级最高的？范围是否合理？
工程评审 design.md CSS 变量方案的浏览器兼容性？Context Provider 的性能影响？
设计评审 specs/ui/spec.md 暗色模式的色彩对比度是否符合 WCAG AA 标准？
DX 评审 tasks.md 任务拆分是否合理？其他开发者能否扩展暗色主题？

评审结论写入 gstack 的计划文件，锁住关键设计约束：必须用 CSS 自定义属性，不能用 CSS-in-JS。

🔗 串联触发： 评审通过后，进入编码阶段。此时 Superpowers 的 HARD-GATE 检查”设计是否已批准”——OpenSpec 的 design.md + gstack 的评审结论满足了这个条件，HARD-GATE 自动放行。

第 3 步：Superpowers TDD 铁律自动生效

你没有手动调用 Superpowers 的任何命令。 TDD 铁律是 skill 文件里的规则，Claude Code 写代码时自动遵守。

开始实现 tasks.md 里的第一个任务”创建 ThemeContext”：

  1. RED：先写测试 ThemeContext.test.tsx——验证 Provider 提供默认亮色主题、useTheme hook 返回当前主题和切换函数
  2. GREEN：运行测试，确认失败（RED）
  3. REFACTOR：写最小实现——ThemeContext.tsx 用 createContext + useState
  4. GREEN：运行测试，确认通过
  5. COMMIT：feat(theme): add ThemeContext with useTheme hook

如果先写了实现代码再补测试？ Superpowers 的铁律会强制要求删掉实现代码，先写测试。不打折扣。

子代理驱动模式（如果启用）：每个 tasks.md 里的任务用一个全新的子代理执行。子代理读取 openspec/changes/add-dark-mode/specs/ui/spec.md 作为需求输入，读取 design.md 作为技术约束。执行完后做两阶段审查：先查是否符合 specs/，再查代码质量。

🔗 串联触发： 所有任务实现完成后，运行 gstack 的 /review。

第 4 步：gstack /review 审查代码

1
/review

/review 扫描当前分支的 diff。因为 Superpowers 的 TDD 铁律确保了每个功能都有测试，/review 的审查质量更高——它可以用测试作为行为契约来验证实现是否正确。

/review 发现了两个问题：

  • [AUTO-FIXED] ThemeContext.tsx 中的 useMemo 依赖数组缺少 theme 变量
  • [ASK] localStorage.setItem 没有 try-catch，在 Safari 隐私模式下会抛 QuotaExceededError 异常

你确认修复方案后，继续。

🔗 串联触发： 审查通过后，运行 /qa 做真实浏览器验收。代码审查只能发现静态问题，浏览器验收才能发现运行时 bug。

第 5 步：gstack /qa 浏览器验收

1
/qa

/qa 用 Playwright Chromium 打开你的应用，执行真实用户操作——这是 gstack 区别于其他工具的杀手级能力。AI 获得”眼睛”：

1
2
3
4
5
6
7
1. $B goto http://localhost:3000/settings    — 打开设置页
2. $B snapshot -i                            — 获取可访问性快照，找到主题切换开关
3. $B click @e5                              — 点击切换开关
4. $B screenshot                             — 截图验证暗色模式生效
5. $B reload                                 — 刷新页面
6. $B screenshot                             — 验证主题持久化
7. $B eval prefers-color-scheme              — 验证跟随系统偏好

QA 报告发现 3 个页面的文字对比度在暗色模式下不达标（WCAG AA 要求 4.5:1，实际只有 3.2:1）。AI 自动修复 CSS 变量值，重新验证全部通过，并为每个修复生成回归测试。

🔗 串联触发： QA 通过后，运行 /ship 发布。

第 6 步：gstack /ship 发布

1
/ship

/ship 自动执行完整的发布流程：

  1. git fetch origin main — 同步远程
  2. bun test — 跑全部测试（42 → 51，+9 新增）
  3. 覆盖率审计 — 检查新增代码的测试覆盖
  4. VERSION 升级 — v1.5.0.0 → v1.6.0.0（MINOR，新功能）
  5. CHANGELOG 生成 — 从 git log 提取变更摘要
  6. git push — 推送代码
  7. gh pr create — 创建 PR
1
/land-and-deploy

合并 PR、等待 CI 通过、部署到生产环境。

1
/canary

部署后 30 分钟内监控控制台错误、性能回归和页面故障。

🔗 串联触发： 发布并验证稳定后，运行 OpenSpec 的归档。

第 7 步：OpenSpec /opsx:archive 归档

1
/opsx:archive add-dark-mode

归档过程：

  1. 读取 openspec/changes/add-dark-mode/specs/ui/spec.md 中的 Delta 规范
  2. ## ADDED Requirements 追加到 openspec/specs/ui/spec.md
  3. ## MODIFIED Requirements 替换主规范中的同名需求
  4. 变更文件夹移入 openspec/changes/archive/2026-05-15-add-dark-mode/

归档后，openspec/specs/ 目录始终反映系统当前状态。下次再加新功能时，OpenSpec 的 AI 会读取这些 specs 作为上下文，知道系统已经有了暗色模式，避免重复设计。

四、全流程串联机制总结

你手动输入的命令只有 7 个：

1
/opsx:propose → /autoplan → (写代码) → /review → /qa → /ship → /opsx:archive

但背后自动发生的事情远不止这些：

你输入的 自动发生的
/opsx:propose DAG 引擎解析依赖关系，生成 4 个规范文件落盘
/autoplan 4 个评审角色读取 OpenSpec 产物，输出评审结论，锁住设计约束
（写代码） Superpowers HARD-GATE 检查设计是否批准（是），TDD 铁律自动拦截（先写测试），子代理两阶段审查（先 spec 后质量）
/review gstack 读取 diff + 测试，找出生产级 bug，自动修复明确的，标记需要决策的
/qa Playwright Chromium 执行真实浏览器操作，截图验证，生成回归测试
/ship 测试 → 版本号 → CHANGELOG → 推送 → PR，完备的发布流程
/opsx:archive Delta 规范合入主规范，变更文件夹归档，主 specs 保持最新

三器之间衔接的核心机制是文件系统：OpenSpec 把产物写到 openspec/ 目录，gstack 的评审角色读这些文件做评审，Superpowers 读设计文件判断 HARD-GATE 是否放行。不需要 API 集成，不需要插件桥接——文件就是协议。

五、安装：三者共存

5.1 安装 OpenSpec

1
2
3
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

5.2 安装 Superpowers

在 Claude Code 中：

1
/plugin install superpowers@claude-plugins-official

5.3 安装 gstack

在 Claude Code 中粘贴：

1
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

然后在项目的 CLAUDE.md 中添加 gstack 段落后，重启 Claude Code 会话。

5.4 验证安装

在一个新的 Claude Code 会话中，确认以下命令都可用：

  • OpenSpec: /opsx:propose、/opsx:apply、/opsx:archive
  • Superpowers: 说”帮我加一个功能”，AI 应该先问你设计问题而不是直接写代码（HARD-GATE 生效）
  • gstack: /office-hours、/review、/qa、/ship

装完之后，三个工具在同一个 Claude Code 会话里共存。它们不互相覆盖，因为管的层次不同。

六、避坑指南

6.1 不要重复门禁

Superpowers 的 HARD-GATE 已经卡住了”设计必须批准才能写代码”，就不要再让 gstack 的 /plan-design-review 在编码阶段重新审查同一份设计。两套门禁同时跑会产生矛盾——Superpowers 认为设计已经批准可以写代码了，gstack 的设计评审却还在挑问题。

推荐分工： - Superpowers 管设计门禁（HARD-GATE，更严格） - gstack 管代码审查（/review，有浏览器验证能力） - OpenSpec 管需求规范（specs/，唯一真相源）

6.2 specs/ 是唯一真相源

OpenSpec 的 openspec/specs/ 定义需求，gstack 的计划文件和设计文档只描述实现细节。当需求与实现描述有冲突时，以 specs/ 为准。

6.3 /ship 是唯一发布出口

OpenSpec 的 /opsx:archive 只是收尾记录，不是发布。所有代码必须通过 gstack 的 /ship 流向生产环境。确保 /ship 是唯一的发布路径，这样才能保证每次发布都经过了完整的测试→审查→QA 流程。

6.4 TDD 有三个例外

Superpowers 的 TDD 铁律不打折扣，但以下三种场景可以跟 AI 明确说”这是原型，跳过 TDD”：

  1. 一次性原型：用完就扔的探索性代码
  2. 自动生成的代码：如 OpenAPI 生成的客户端、GraphQL 类型定义
  3. 配置文件：如 ESLint、Prettier、TypeScript 配置

除此之外，TDD 铁律一概适用。

6.5 上下文窗口管理

三个工具叠加后，skill 文件、规范文档、计划文件都会占用上下文窗口。建议：

  • 开始实现前清理上下文：OpenSpec 和 gstack 都建议在开始编码前清理上下文窗口
  • 使用高推理模型：OpenSpec 推荐 Claude Opus 4.5 或 GPT 5.2 用于规划和实现
  • 子代理隔离：Superpowers 的子代理驱动模式每个任务用全新会话，避免上下文污染

6.6 团队协作

如果团队共用同一个仓库：

  • OpenSpec：openspec/ 目录提交到 Git，团队成员共享规范。
  • Superpowers：每个成员在自己的 Claude Code 中安装插件。
  • gstack：用 ./setup --team 模式，将 gstack 要求写入项目的 CLAUDE.md 和 .claude/，团队成员自动获取。

七、总结

OpenSpec 管需求，Superpowers 管质量，gstack 管流程。 三套规则在同一个 Claude Code 会话里自动生效、互相补位。你只管输入斜杠命令，剩下的串联是自动的。

维度 OpenSpec Superpowers gstack
核心价值 写代码前锁定需求 写代码时卡住质量 写完代码后包办发布
触发方式 手动 /opsx:* 命令 自动触发（skill 规则） 手动 /xxx 命令 + 自动建议
产物 proposal.md specs/ design.md tasks.md TDD 测试用例、设计文档 评审结论、QA 报告、PR
状态存储 openspec/ CLAUDE.md + skill 文件 .gstack/
适用场景 需求复杂的项目 质量要求高的项目 需要端到端流程的项目

这不是三个工具的简单拼凑，而是一个分层协作的工程化体系：

  • 需求层（OpenSpec）确保你造的是对的
  • 质量层（Superpowers）确保你造得够好
  • 流程层（gstack）确保你能稳定地、可重复地把东西送到用户手里

三器合一，AI 编程从”聊天写代码”进化为”工程化交付”。

Reference

AI Coding
#Superpowers #OpenSpec #gstack #AI Coding #SDD #TDD
gstack + Superpowers + OpenSpec 三器合一：AI 编程工程化共存方案
https://mztchaoqun.com.cn/posts/D118_SDD/
作者
mztchaoqun
发布于
2026年5月15日
许可协议