AI 编程的「三体」架构：OpenSpec + Superpowers + GStack 如何让一个开发者撑起整个研发团队

2026 年，AI 编程工具遍地开花。Codex、Claude Code、Cursor、Copilot......每个都能写代码，但每个都有同样的问题：

写得快，但写得乱。

需求在聊天记录里丢失，代码没有测试就上线，Bug 修了一个冒出三个。你以为 AI 是高级工程师，结果它更像一个「手速极快的实习生」。

问题不在 AI 的能力，而在工作方法。

就像一支乐队需要指挥，一个开发团队需要流程。AI 也需要被「管理」------不是限制它，而是让它在正确的时间做正确的事。

这篇文章介绍三个开源工具：OpenSpec 、Superpowers 、GStack。它们不是竞争关系，而是三层架构，分别解决 AI 编程的三个核心问题：

做什么？怎么做？谁来做？

第一部分：三层架构------AI 编程的「操作系统」

1.1 问题拆解

一个软件项目从需求到上线，至少经历这些阶段：

阶段	核心问题	传统团队角色
需求分析	做什么？	产品经理
架构设计	怎么做？	技术架构师
编码实现	谁来写？	开发工程师
代码审查	写得对吗？	高级工程师
测试验证	能用吗？	QA 工程师
发布上线	怎么交付？	DevOps 工程师
复盘总结	学到什么？	项目经理

AI 能做所有这些事，但它不知道什么时候该切换角色。

你让它「写个登录功能」，它会直接开始写代码------不问需求细节，不考虑架构，不写测试，不审查。它用同一个「大脑」处理所有问题，结果就是每个环节都做得马马虎虎。

1.2 解决方案：三层架构

OpenSpec 是意图层------它管「做什么」。通过结构化的规范文档，把模糊的需求变成可执行的变更提案。

Superpowers 是执行层------它管「怎么做」。通过强制的工程纪律（TDD、代码审查、验证），确保代码质量。

GStack 是编排层------它管「谁来做、何时做」。通过角色切换（CEO、架构师、QA、发布工程师），让 AI 在正确的时间用正确的「大脑」思考。

三者各司其职，互不重叠，但产出物完美衔接。

第二部分：意图层------OpenSpec，让需求不再「聊天即忘」

2.1 传统 AI 编程的需求痛点

你跟 AI 说：「给系统加个患者预约功能。」

AI 立刻开始写代码。写到一半，你发现它没考虑「预约冲突检测」。你说：「加上冲突检测。」它加上了，但忘了「取消预约」的逻辑。

需求在聊天记录里层层叠加，最后你都不记得哪些说了、哪些没说。AI 更不记得。

OpenSpec 解决这个问题。

2.2 OpenSpec 的核心理念

OpenSpec 是 Fission-AI 开源的规范驱动开发（Spec-Driven Development）框架。它的核心理念是：

先写规范，再写代码。

当你提出一个需求时，OpenSpec 不会让 AI 直接写代码，而是生成一个结构化的变更提案：

bash 复制代码

openspec/changes/add-patient-appointment/
├── proposal.md    ← 需求描述：做什么、为什么做
├── design.md      ← 技术设计：怎么做、用什么方案
├── tasks.md       ← 任务分解：拆成哪些子任务
└── specs/         ← 规范差异：对现有系统的影响

你审查这个提案，确认需求理解正确，然后才进入实现阶段。

2.3 OpenSpec 的核心价值

需求持久化 ：规范文档随代码一起版本控制。新人加入项目，打开 openspec/specs/ 目录，就能了解系统的每个功能模块。

变更可追踪：每次需求变更都有完整的提案记录。三个月后你问「为什么当时加了这个逻辑」，答案就在提案文档里。

上下文不丢失：AI 每次对话都会重新读取规范文档，不会因为聊天窗口关闭而「失忆」。

2.4 实战示例

bash 复制代码

# 创建变更提案
/opsx:propose "患者预约模块：支持预约、取消、冲突检测"

# OpenSpec 生成：
# - proposal.md：详细需求描述
# - design.md：技术方案
# - tasks.md：5 个子任务
# - specs/appointment/spec.md：预约规范

# 你审查并确认后，进入下一阶段

第三部分：执行层------Superpowers，让 AI 像工程师一样写代码

3.1 传统 AI 编程的代码质量痛点

AI 写代码有三个典型问题：

不写测试：直接写实现，跑起来就算完成
不做审查：代码写完就交给你，不管质量
不验证修复：改了 Bug，不确认是否真的修好了

Superpowers 解决这个问题。

3.2 Superpowers 的核心理念

Superpowers 是 obra 团队开源的工程纪律框架。它的核心理念是：

强制执行工程师纪律。

它不是给 AI 加新能力，而是给它套上一套工作规范：先想清楚再动手，先写测试再写代码，先审查再提交。

3.3 Superpowers 的核心技能

技能	触发时机	强制规则
brainstorming	写代码前	必须先问清楚需求
writing-plans	需求确认后	必须先写实施计划
test-driven-development	写代码时	必须先写测试（RED→GREEN→REFACTOR）
systematic-debugging	遇到 Bug 时	必须按 4 阶段流程定位根因
requesting-code-review	代码完成后	必须经过代码审查
verification-before-completion	修复 Bug 后	必须验证修复是否生效

3.4 TDD 的「铁律」

Superpowers 最核心的强制规则是 TDD（测试驱动开发）：

复制代码

RED    → 先写一个会失败的测试
GREEN  → 写最少量的代码让测试通过
REFACTOR → 测试绿了才能重构

如果 AI 忍不住先写了实现代码，Superpowers 会逼它删掉代码重来。没有例外。

3.5 实战示例

bash 复制代码

# 你：实现预约冲突检测功能

# Superpowers 自动触发：

# 1. brainstorming（需求澄清）
#    AI：预约冲突的定义是什么？时间完全重叠算冲突，还是部分重叠也算？
#    你：时间完全重叠算冲突。

# 2. writing-plans（实施计划）
#    AI：任务拆分为：
#    - 写测试：检测时间重叠
#    - 写测试：检测不同资源的预约不冲突
#    - 实现：AppointmentConflictDetector 类
#    - 重构：提取时间比较逻辑

# 3. test-driven-development（TDD）
#    AI：先写测试 AppointmentConflictDetector_ShouldDetectOverlap
#    AI：运行测试 → 失败（RED）
#    AI：写最小实现 → 运行测试 → 通过（GREEN）
#    AI：重构代码 → 运行测试 → 仍然通过（REFACTOR）

第四部分：编排层------GStack，让 AI 成为虚拟开发团队

4.1 传统 AI 编程的流程痛点

AI 写完代码后，你还需要：

审查代码质量
运行测试
部署到测试环境
进行 QA 验证
准备发布

这些工作需要不同的「角色」来完成。但 AI 只有一个模式，用同一种思维方式处理所有问题。

GStack 解决这个问题。

4.2 GStack 的核心理念

GStack 是 Y Combinator CEO Garry Tan 开源的流程编排框架。它的核心理念是：

AI 应该有明确的「认知模式」。

当你需要审查代码时，AI 应该像一个「偏执的高级工程师」，专门找竞态条件和安全漏洞。

当你需要发布时，AI 应该像一个「发布工程师」，专注于检查清单和执行步骤。

4.3 GStack 的九大角色

角色	命令	职责
创始人/CEO	`/plan-ceo-review`	从用户视角审视：这个功能真的需要吗？
技术架构师	`/plan-eng-review`	锁定架构：数据流、状态机、边界条件
偏执工程师	`/review`	深度审查：N+1 查询、竞态条件、安全漏洞
QA 工程师	`/qa`	系统化测试：浏览器自动化、健康评分
发布工程师	`/ship`	一键发布：同步 main、运行测试、推送分支、开 PR
安全审计师	`/cso`	安全扫描：OWASP + STRIDE 审计
问题调查员	`/investigate`	根因分析：4 阶段调查流程
产品顾问	`/office-hours`	产品咨询：功能建议、方向讨论
工程复盘师	`/retro`	项目回顾：提交统计、代码量、问题分析

4.4 `/review` 的深度

GStack 的 /review 不是简单的代码风格检查。它是一个「偏执的高级工程师」，专门找那些「能通过 CI 但在生产环境会爆炸」的 Bug：

N+1 查询
竞态条件
信任边界违规
缺失索引
重试逻辑错误
脏读

4.5 实战示例

bash 复制代码

# 代码写完后，进入审查阶段

/review

# GStack 自动执行：
# 1. 分析 git diff，识别变更范围
# 2. 检查每个变更文件的：
#    - 性能问题（N+1 查询）
#    - 并发问题（竞态条件）
#    - 安全问题（SQL 注入、XSS）
#    - 测试覆盖（是否有对应测试）
# 3. 生成审查报告，按严重程度分类
# 4. 严重问题不修就不让继续

# 审查通过后，进入 QA 阶段

/qa

# GStack 自动执行：
# 1. 启动持久化 Chromium 浏览器
# 2. 根据 git diff 识别受影响的页面
# 3. 自动点击、截图、检查 console 错误
# 4. 生成健康评分（0-100）
# 5. 评分 < 90 自动修复并重新测试

第五部分：三者协作------完整工作流演示

5.1 场景：为 MRI 工作站添加患者预约功能

让我们用一个真实场景演示三个工具如何协作。

5.2 Step 1：需求规范（OpenSpec）

bash 复制代码

/opsx:propose "患者预约模块：支持预约、取消、冲突检测、预约查询"

OpenSpec 生成变更提案：

markdown 复制代码

# proposal.md
## 需求描述
为 MRI 工作站添加患者预约功能，支持：
1. 创建预约：选择设备、时间段、患者
2. 取消预约：释放时间段
3. 冲突检测：同一设备同一时间段只能有一个预约
4. 预约查询：按设备、患者、时间范围查询

## 成功标准
- 预约创建响应时间 < 100ms
- 冲突检测准确率 100%
- 支持并发预约（最多 10 个同时操作）

你审查并确认需求理解正确。

5.3 Step 2：架构设计（GStack）

bash 复制代码

/plan-ceo-review

创始人视角审查：

「预约功能的核心价值是什么？是帮助医院高效管理设备时间。当前方案是否足够？是否需要考虑「预约提醒」功能？是否需要考虑「紧急插队」场景？」

你确认当前范围足够，后续迭代再扩展。

bash 复制代码

/plan-eng-review

技术架构锁定：

「预约模块需要以下组件：

AppointmentService：业务逻辑层

AppointmentRepository：数据访问层

AppointmentConflictDetector：冲突检测器

AppointmentController：API 接口

数据流：Controller → Service → ConflictDetector → Repository

状态机：Pending → Confirmed → Cancelled → Completed

边界条件：

并发预约：使用乐观锁

时间精度：分钟级

跨天预约：不支持（当前版本）」

5.4 Step 3：编码实现（Superpowers）

架构确定后，Superpowers 自动接管：

bash 复制代码

# 1. writing-plans（实施计划）
#    任务拆分为：
#    - Task 1：创建 Appointment 实体和 Repository
#    - Task 2：实现 AppointmentConflictDetector
#    - Task 3：实现 AppointmentService
#    - Task 4：实现 AppointmentController
#    - Task 5：集成测试

# 2. test-driven-development（TDD）
#    Task 1：先写测试 Appointment_ShouldCreate
#    → 失败（RED）
#    → 实现 Appointment 实体
#    → 通过（GREEN）
#    → 重构代码
#    → 仍然通过（REFACTOR）

# 3. subagent-driven-development（子代理并行）
#    Task 2 和 Task 3 可以并行执行
#    每个任务独立审查，确保质量

5.5 Step 4：代码审查（GStack）

bash 复制代码

/review

偏执工程师审查：

「发现问题：

严重：AppointmentRepository 的 Save 方法没有使用事务，可能导致数据不一致

严重：ConflictDetector 没有考虑并发场景，两个请求同时检测可能都通过

中等：缺少日志记录，调试困难

低：方法命名不规范，建议改为 SaveAsync」

修复所有严重问题后，审查通过。

5.6 Step 5：QA 测试（GStack）

bash 复制代码

/qa

系统化 QA：

「测试结果：

功能测试：通过

边界测试：通过（空值、超长输入、特殊字符）

并发测试：通过（10 个同时预约）

性能测试：平均响应时间 45ms

健康评分：95/100

发现问题：

预约时间选择器在 Safari 浏览器上显示异常（已修复）」

5.7 Step 6：发布（GStack）

bash 复制代码

/ship

一键发布：

「发布清单：

同步 main 分支

运行所有测试（通过）

推送功能分支

创建 Pull Request

填写 PR 描述

请求代码审查

PR 已创建：#123 - 添加患者预约功能」

5.8 Step 7：归档回顾（OpenSpec + GStack）

bash 复制代码

/opsx:archive

归档变更：

「变更已归档到 openspec/specs/appointment/spec.md 规范库已更新，包含完整的预约功能规范。」

bash 复制代码

/retro

工程复盘：

「本次迭代统计：

提交次数：23

新增代码：1,247 行

测试覆盖：87%

开发耗时：3 天（预估 5 天）

主要问题：并发场景考虑不足，后续需加强」

第六部分：效果对比

6.1 使用前 vs 使用后

维度	使用前	使用后
需求管理	聊天记录，容易丢失	结构化文档，版本控制
代码质量	无测试，无审查	TDD 强制，自动审查
流程规范	混乱，角色不清	明确阶段，角色分明
问题追溯	靠记忆，难以追溯	完整记录，随时回溯
团队协作	AI 和人各干各的	AI 和人协作，分工明确
交付质量	经常返工	一次做对，质量稳定

6.2 数据说话

在一个真实项目中使用这三个工具后：

需求变更率下降 60%：因为需求在 OpenSpec 中被充分澄清
Bug 数量下降 70%：因为 Superpowers 强制 TDD
发布效率提升 3 倍：因为 GStack 自动化了 QA 和发布流程
新人上手时间缩短 50%：因为规范文档就是最好的教程

第七部分：最佳实践

7.1 什么时候用什么工具

场景	推荐工具	理由
新功能开发	全部三个	完整流程，确保质量
小 Bug 修复	Superpowers	TDD 足够，不需要完整流程
紧急修复	Superpowers + GStack ship	快速修复 + 快速发布
架构重构	OpenSpec + GStack plan-eng-review	充分规划，减少风险
探索性开发	仅 Superpowers brainstorming	快速验证想法

7.2 常见误区

误区 1：「小任务不需要走流程」

即使是修复一个拼写错误，也应该：

写测试验证错误存在
修复错误
运行测试验证修复

这就是 Superpowers 的价值------强制最小化的质量保证。

误区 2：「AI 会自动做好」

AI 需要被引导。你给它清晰的规范（OpenSpec），它才能写出符合需求的代码。你给它明确的流程（GStack），它才能在正确的时间做正确的事。

误区 3：「三个工具太复杂」

实际上，每个工具都很轻量：

OpenSpec：几个 Markdown 文件
Superpowers：自动触发，无需手动调用
GStack：一个斜杠命令

复杂度不在工具本身，而在你是否愿意花时间把需求想清楚。

7.3 给团队的建议

对于个人开发者：

先从 Superpowers 开始，养成 TDD 习惯
然后引入 OpenSpec，规范需求管理
最后使用 GStack，提升发布效率

对于小团队：

三个工具一起使用，形成完整工作流
规范文档放在 Git 仓库，团队共享
每个 PR 都经过 /review 和 /qa

对于大团队：

OpenSpec 作为需求管理的补充（不是替代）
Superpowers 作为代码质量的底线
GStack 作为 CI/CD 的扩展

第八部分：总结

8.1 三个工具的本质

OpenSpec：让 AI 理解「你要什么」
Superpowers：让 AI 做到「你要的质量」
GStack：让 AI 完成「你要的交付」

三者不是替代关系，而是互补关系。就像一个团队需要产品经理、工程师和项目经理，AI 也需要这三种「角色」来完成完整的工作。

8.2 未来展望

AI 编程的未来不是「AI 替代开发者」，而是「AI 和开发者协作」。

开发者负责思考、决策、审查。AI 负责执行、测试、交付。

这三个工具就是这种协作模式的基础设施。它们让 AI 从一个「手速极快的实习生」变成一个「靠谱的高级工程师」。

8.3 行动建议

如果你正在使用 AI 编程工具，但对代码质量不满意：

今天：安装 Superpowers，开始 TDD
这周：安装 OpenSpec，规范下一个需求
这个月：安装 GStack，建立完整工作流

三个月后，你会发现：

AI 不再是一个「手速极快的实习生」，而是一个「靠谱的高级工程师」。

而你，终于可以专注于真正重要的事情------思考产品方向，做出更好的决策。

附录：安装指南

OpenSpec

bash 复制代码

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init --tools trae

Superpowers

bash 复制代码

# 克隆到项目技能目录
git clone https://github.com/obra/superpowers.git .trae/skills/superpowers

GStack

bash 复制代码

# 克隆到项目技能目录
git clone https://github.com/garrytan/gstack.git .trae/skills/gstack

AI 编程的「三体」架构：OpenSpec + Superpowers + GStack 如何让一个开发者撑起整个研发团队

第一部分：三层架构------AI 编程的「操作系统」

1.1 问题拆解

1.2 解决方案：三层架构

第二部分：意图层------OpenSpec，让需求不再「聊天即忘」

2.1 传统 AI 编程的需求痛点

2.2 OpenSpec 的核心理念

2.3 OpenSpec 的核心价值

2.4 实战示例

第三部分：执行层------Superpowers，让 AI 像工程师一样写代码

3.1 传统 AI 编程的代码质量痛点

3.2 Superpowers 的核心理念

3.3 Superpowers 的核心技能

3.4 TDD 的「铁律」

3.5 实战示例

第四部分：编排层------GStack，让 AI 成为虚拟开发团队

4.1 传统 AI 编程的流程痛点

4.2 GStack 的核心理念

4.3 GStack 的九大角色

4.4 /review 的深度

4.5 实战示例

第五部分：三者协作------完整工作流演示

5.1 场景：为 MRI 工作站添加患者预约功能

5.2 Step 1：需求规范（OpenSpec）

5.3 Step 2：架构设计（GStack）

5.4 Step 3：编码实现（Superpowers）

5.5 Step 4：代码审查（GStack）

5.6 Step 5：QA 测试（GStack）

5.7 Step 6：发布（GStack）

5.8 Step 7：归档回顾（OpenSpec + GStack）

第六部分：效果对比

6.1 使用前 vs 使用后

6.2 数据说话

第七部分：最佳实践

7.1 什么时候用什么工具

7.2 常见误区

7.3 给团队的建议

第八部分：总结

8.1 三个工具的本质

8.2 未来展望

8.3 行动建议

附录：安装指南

OpenSpec

Superpowers

GStack

4.4 `/review` 的深度