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）框架。核心理念非常简单：当你提出需求时，它不会让 AI 直接进入编码阶段，而是先生成一个结构化的变更提案：
openspec/changes/add-patient-appointment/
├── proposal.md ← 需求描述：做什么、为什么做
├── design.md ← 技术设计：怎么做、用什么方案
├── tasks.md ← 任务分解：拆成哪些子任务
└── specs/ ← 规范差异：对现有系统的影响
你审查这份提案，确认需求理解无误，然后才进入实现阶段。这样一来，需求就和代码一起纳入了版本控制，再也不会凭空消失。
2.3 OpenSpec 的核心价值
需求持久化：规范文档随代码一起纳入版本管理。新人加入项目，只需打开 openspec/specs/ 目录，就能快速了解系统的每一个功能模块。
变更可追踪：每次需求变更都留有完整的提案记录。三个月后有人问「当时为什么加了这个逻辑」，答案就在提案文档里。
上下文不丢失：AI 每次对话都会重新读取规范文档，不会因为聊天窗口关闭而「失忆」。
2.4 实战示例
# 创建变更提案
/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 实战示例
# 你：实现预约冲突检测功能
# 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 应该像一个「发布工程师」，专注于检查清单和执行步骤。
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 实战示例
# 代码写完后，进入审查阶段
/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）
/opsx:propose "患者预约模块：支持预约、取消、冲突检测、预约查询"
OpenSpec 生成变更提案：
# proposal.md
## 需求描述
为 MRI 工作站添加患者预约功能，支持：
1. 创建预约：选择设备、时间段、患者
2. 取消预约：释放时间段
3. 冲突检测：同一设备同一时间段只能有一个预约
4. 预约查询：按设备、患者、时间范围查询
## 成功标准
- 预约创建响应时间 < 100ms
- 冲突检测准确率 100%
- 支持并发预约（最多 10 个同时操作）
你审查并确认需求理解正确。
5.3 Step 2：架构设计（GStack）
/plan-ceo-review
创始人视角审查：确认当前范围足够，后续迭代再扩展。
/plan-eng-review
技术架构锁定。
5.4 Step 3：编码实现（Superpowers）
架构确定后，Superpowers 自动接管：
# 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）
/review
偏执工程师审查：
修复所有严重问题后，审查通过。
5.6 Step 5：QA 测试（GStack）
/qa
系统化 QA。
5.7 Step 6：发布（GStack）
/ship
一键发布。
5.8 Step 7：归档回顾（OpenSpec + GStack）
/opsx:archive
归档变更。
/retro
工程复盘。
第六部分：效果对比
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，建立完整工作流
三个月后，你会发现：而你，终于可以专注于真正重要的事情——思考产品方向，做出更好的决策。
附录：安装指南
OpenSpec
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init --tools trae
Superpowers
# 克隆到项目技能目录
git clone https://github.com/obra/superpowers.git .trae/skills/superpowers
GStack
# 克隆到项目技能目录
git clone https://github.com/garrytan/gstack.git .trae/skills/gstack
