Claude Code + Codex 实战：三套工具库让 AI 编程从"能用"到"好用"
很多人用 Claude Code 或 Codex，停留在"给一句话需求 → 等它生成代码"的模式。能用，但不好用。不好用的原因不是模型不行，而是你缺一套工作方法。今天介绍三套工具——OpenSpec、Superpowers、gstack——它们不是三个独立插件，而是一套完整的 AI 编程工作流：立项 → 方法 → 验收。
先搞清楚三者分工
一句话记住：
- OpenSpec：管"要不要做、做成什么样"——变更立项与规格管理
- Superpowers：管"怎么做、怎么保证质量"——开发方法论与过程纪律
- gstack：管"做完之后怎么验"——浏览器 QA、代码评审、安全检查、发布验证
如果你只记一句话：OpenSpec 立项，Superpowers 做事，gstack 验收。
一、OpenSpec：把需求变成可执行的变更
它解决什么问题
最常见的 AI 编程翻车：需求还没想清楚就开写，代码改了一半发现方向不对，回滚又麻烦。OpenSpec 的思路是：先落档，再动手。
核心流程
一个完整的 OpenSpec 变更分四步：
propose（立项）→ 实施（apply）→ 推进 → 归档（archive）它会帮你生成三份工件：
- proposal.md：为什么要做
- design.md：怎么做
- tasks.md：拆成什么任务
怎么开口
立一个新变更：
/opsx:propose "add user login"先探索再决定要不要做：
/opsx:explore
我想做一个实时协作功能，但还不确定是 presence、cursor 还是真正的 CRDT 协作按已有变更开始实施：
/opsx:apply add-user-login做完归档：
/opsx:archive add-user-login什么时候该用 / 不用
适合：正式新功能、多人协作、长周期项目、需要留下决策记录。不适合：改一行 typo、临时小查询、不需要沉淀过程的热修复。
二、Superpowers：让 AI 别上来就瞎改
它解决什么问题
第二大翻车：你给了一个模糊需求，AI 立刻开始改代码，改完你才发现理解偏了。Superpowers 的核心理念：先想清楚，再动手。它是一套"开发过程纪律"，覆盖从需求澄清到代码交付的每个阶段。
最常用的几个能力
1. Brainstorming——需求还没想清时
用 superpowers-brainstorming 帮我想清楚：
我到底应该做一个"通知中心"，还是只补"未读提醒"这个最小能力？2. Writing Plans——把方案拆成可执行任务
用 superpowers-writing-plans 把这个方案拆成可执行任务，
尽量细到文件级、修改点和验证步骤。3. Test-Driven Development——按 TDD 实施
这次按 superpowers-test-driven-development 来做：
先写失败测试，再做最小实现，再重构。4. Systematic Debugging——系统化排障
用 superpowers-systematic-debugging 帮我查这个问题。
现象是：偶发超时，重试后恢复，先不要急着写修复。Superpowers 的价值
不是"多问几个问题"，而是强制过程纪律。很多人觉得"我已经知道要改什么了，不需要 plan"——但大量返工恰恰来自"知道大概方向但没有可执行拆解"。
三、gstack：做完之后怎么验
它解决什么问题
第三大翻车：代码写完了，AI 说"完成了"，但上线一看——页面样式崩了、流程走不通、安全漏洞没堵。gstack 是一套专项工程工具集，覆盖浏览器验证、代码评审、安全审计和发布流程。
最常用的几个能力
浏览器 QA——真实页面验证
用 gstack-browse 打开这个页面，帮我检查登录流程和移动端布局或者只出报告不改代码：
用 gstack-qa-only 出一份 bug 清单，不要修改代码代码评审——合并前风险扫描
用 gstack-review 看一下这次改动，重点找行为回归和缺少测试安全检查——认证、授权、输入处理
用 gstack-cso 看一下这个项目的认证、权限控制和输入处理风险发版验证——上线前后检查
用 gstack-ship 做发版前检查四、怎么把三者串起来
这才是关键——单独用任何一套都只是半成品，串联起来才是完整工作流。
场景一：正式新功能（最完整流程）
# 1. 立项
/opsx:propose "add team invitation flow"
# 2. 想清楚
用 superpowers-brainstorming 帮我把最小范围、边界条件和风险聊清楚
# 3. 拆任务
用 superpowers-writing-plans 把任务拆细到文件级和验证步骤
# 4. 实施
/opsx:apply add-team-invitation-flow
# 5. 验收
用 gstack-review 看这次改动的主要风险
用 gstack-qa 测一下邀请、接受邀请、重复邀请流程
# 6. 归档
/opsx:archive add-team-invitation-flow场景二：疑难 bug 修复
# 1. 先查根因（不急着修）
用 superpowers-systematic-debugging 帮我查：
登录后偶发跳回登录页，先别急着修，先定位根因
# 2. 必要时立正式修复变更
/opsx:propose "fix-post-login-session-race"
# 3. 实施修复
/opsx:apply fix-post-login-session-race
# 4. 验证
用 gstack-qa-only 走一下登录主流程，确认是否还有复现路径场景三：前端页面验收
这类场景不需要 OpenSpec 和 Superpowers 打头，直接用 gstack：
用 gstack-browse 打开本地站点，检查注册流程、错误提示和移动端布局
用 gstack-qa 测首页、注册、登录、个人中心主流程五、日常口令速查卡
不需要背所有命令，记住下面这 8 句就够覆盖 90% 场景：
| 场景 | 怎么说 |
|---|---|
| 正式立项 | /opsx:propose "add xxx" |
| 先想清楚 | 用 superpowers-brainstorming 帮我把需求聊清楚，先不要写代码 |
| 拆任务 | 用 superpowers-writing-plans 把方案拆成可执行任务 |
| 按变更做 | /opsx:apply <change-name> |
| 严格 TDD | 这次按 superpowers-test-driven-development 来做 |
| 查复杂 bug | 用 superpowers-systematic-debugging 帮我先定位根因，不要急着修 |
| 看代码风险 | 用 gstack-review 看一下这次改动，重点找行为回归和缺少测试 |
| 测页面流程 | 用 gstack-qa 测一下这个流程 |
如果你只记一条最小工作流：
propose → brainstorming → writing-plans → apply → review → qa → archive六、三个判断让你形成条件反射
用熟之后，你不需要查表，只需要在开始前问自己三个问题：
- 这事要不要正式记录成一个变更？ → 先想 OpenSpec
- 我是不是还没想清楚，或者这个 bug 根因不明？ → 先想 Superpowers
- 做完之后是不是该在真实页面或评审流程里再验一次？ → 先想 gstack
这三个判断开始自然了，你就已经会用了。
七、什么时候别把流程搞太重
以下场景直接做就行，不用走完整流程：
- 改一个注释或 typo
- 修一行文案
- 临时查一个命令输出
- 明显的小 bug 且不需要沉淀过程
流程是为质量服务的，不是为流程本身服务的。
八、最快上手路径
如果你想在 1-2 天内真正上手，按这个顺序练：
第一步：只练 OpenSpec 生命周期。做三次 propose → apply → archive，先熟悉 change 是怎么管理的。
第二步：把 Superpowers 加进来。下一次正式功能里，固定多做两步：先 brainstorming，再 writing-plans。遇到 bug 时强制先走一次 systematic-debugging。
第三步：把 gstack 放到收尾。每次功能完成后固定补两步：review + qa。
练完这三轮，你基本就有手感了。
总结
AI 编程工具的价值不在于"能生成代码"，而在于帮你把开发过程管起来。
OpenSpec 让你不至于"聊着聊着就改了代码，后面没人知道为什么"；Superpowers 让你不至于"知道大概方向但一执行就翻车"；gstack 让你不至于"代码写完了但用户一用就出问题"。
三套工具，一个目标：让 AI 编程从能用，到好用。
附：三套工具 GitHub 仓库
- OpenSpec： https://github.com/Fission-AI/OpenSpec
- Superpowers： https://github.com/obra/superpowers
- gstack： https://github.com/garrytan/gstack