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 直接写代码，而是生成一个结构化的变更提案：
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 应该像一个「偏执的高级工程师」，专门找竞态条件和安全漏洞。
当你需要发布时，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
技术架构锁定：
「预约模块需要以下组件：
- AppointmentService：业务逻辑层
- AppointmentRepository：数据访问层
- AppointmentConflictDetector：冲突检测器
- AppointmentController：API 接口
数据流：Controller → Service → ConflictDetector → Repository
状态机：Pending → Confirmed → Cancelled → Completed
边界条件：
- 并发预约：使用乐观锁
- 时间精度：分钟级
- 跨天预约：不支持（当前版本）」
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
偏执工程师审查：
「发现问题：
- 严重：AppointmentRepository 的 Save 方法没有使用事务，可能导致数据不一致
- 严重：ConflictDetector 没有考虑并发场景，两个请求同时检测可能都通过
- 中等：缺少日志记录，调试困难
- 低：方法命名不规范，建议改为 SaveAsync」
修复所有严重问题后，审查通过。
5.6 Step 5：QA 测试（GStack）
/qa
系统化 QA：
「测试结果：
- 功能测试：通过
- 边界测试：通过（空值、超长输入、特殊字符）
- 并发测试：通过（10 个同时预约）
- 性能测试：平均响应时间 45ms
- 健康评分：95/100
发现问题：
- 预约时间选择器在 Safari 浏览器上显示异常（已修复）」
5.7 Step 6：发布（GStack）
/ship
一键发布：
「发布清单：
- 同步 main 分支
- 运行所有测试（通过）
- 推送功能分支
- 创建 Pull Request
- 填写 PR 描述
- 请求代码审查
PR 已创建：#123 - 添加患者预约功能」
5.8 Step 7：归档回顾（OpenSpec + GStack）
/opsx:archive
归档变更：
「变更已归档到 openspec/specs/appointment/spec.md 规范库已更新，包含完整的预约功能规范。」
/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
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
