0. 给你介绍一套组合拳

这套组合拳要解决的根本问题是：让 AI 像一个守纪律的工程师团队，而不是一个情绪化的实习生。

工具	本质定位	解决的核心痛点
gstack	虚拟工程团队 + 治理框架	需求混乱、方向跑偏、没有 Review
OpenSpec	规格驱动开发（SDD）框架	AI "瞎猜"、上下文丢失、变更无迹可查
Superpowers	编码纪律执行器（TDD + 技能包）	AI 跳过测试、不写文档、风格随意
Ralph	自主迭代循环引擎	人一直盯着 AI、大任务跑不完、上下文腐化

四者形成一条完整的链路：治理 → 规格 → 纪律 → 自动化执行。

---

1. 前置条件

在安装任何工具之前，你需要：

1. Claude Code CLI：这四个工具都基于 Claude Code 运行。前往 claude.ai/code 下载并安装。
2. Node.js ≥ 18（Ralph 运行所需）
3. Git：项目必须在 git 仓库内，Ralph 的自动提交才能生效。

最简上手路径（推荐第一次只装 Superpowers）：

# 1. 克隆 Superpowers

git 
clone
 https://github.com/obra/superpowers ~/.superpowers


# 2. 按照仓库 README 运行安装脚本，或手动将 skills/ 目录加入 Claude Code 配置

# 完成后在项目根目录运行 Claude Code，/tdd、/debug 等斜杠命令即可用

四个工具都安装妥当后，再进入完整工作流。

---

2. 工具仓库和安装

工具	仓库	安装方式
gstack	garrytan/gstack（请以 GitHub 实际地址为准）	下载 Skill 文件，按 README 配置到 Claude Code
OpenSpec	Fission-AI/OpenSpec	同上，斜杠命令通过 Skill 文件注册
Superpowers	obra/superpowers	同上，Jesse Vincent 的仓库
Ralph	snarktank/ralph	独立脚本，按 README 配置后运行

四个都是开源免费的，全部 MIT 协议。

---

3. 工具详解

3.1 gstack：给 AI 装上虚拟团队

YC CEO Garry Tan 做的这个工具，是一套基于 Markdown Skill 文件的角色系统，让 Claude Code 扮演不同专家角色。

核心思想很直接：不要跟一个泛用 AI 谈需求，召唤一组专家来协作。它内置了 23 个专家角色，从 CEO（战略决策）、Engineering Manager（任务拆解）、QA Lead（测试策略）到 Security Reviewer（安全审计）。

关键命令速查：

/office-hours    
# YC 风格的想法验证，暴力追问你需求的合理性

/plan            
# 工程经理视角做任务分解

/review          
# 代码 Review，含安全 + 标准合规检查

/ship            
# 最终发布前的检查清单

/careful         
# 开启安全护栏，防止 AI 乱跑破坏性命令

/freeze          
# 冻结当前代码状态，禁止 AI 随意修改

---

3.2 OpenSpec：规格是唯一的真相来源

传统 AI 编程有个绕不过去的坑：聊了两小时，AI 已经忘了开头定好的约束，开始自由发挥。OpenSpec 是个 Spec 驱动开发框架，它的答案很简单：把所有约定写进文件系统，让 AI 每次从文件里读，而不是靠聊天记录。

三步工作法：

Propose（提案）→ Apply（实施）→ Archive（归档）

• Propose：/opsx-propose，AI 基于你的描述生成技术设计 + 任务清单，这是人工 Review 的检查点
• Apply：/opsx-apply，对齐后 AI 按规格逐步实施，不再即兴发挥
• Archive：/opsx-archive，完成后自动将变更合并进主文档，形成活文档

Delta Spec 机制值得单说：它不重写整个文档，只记录"这次变更了什么"。对 Java 项目来说，这相当于在代码旁边维护了一份永远最新的 ADR（Architecture Decision Record）。

---

3.3 Superpowers：给 AI 装上工程纪律

Jesse Vincent 做的这套工具，是一组 Skill 文件，专门用来强制 AI 遵守工程最佳实践。如果说 gstack 负责"做对的事"，Superpowers 负责"把事做对"。它通过 SKILL.md 文件约束 AI：

• TDD（测试驱动开发）：不允许 AI 先写实现再补测试，必须先写失败的测试
• 设计先行：复杂功能必须先出设计文档，经确认后再写代码
• 系统化 Debug：不允许 AI 猜问题，必须用二分法 + 证据链定位
• 代码 Review 前置：提 PR 前必须过 Superpowers 自检清单

---

3.4 Ralph：让 AI 自己跑，你去睡觉

名字取自《辛普森一家》里的 Ralph Wiggum，那种"不聪明但死磕到底"的劲儿。它做的事情说起来很朴素：把 AI 编码工具包在一个任务循环脚本里，让它无人值守地跑完整个任务列表。

每次迭代都开启全新的 AI Session，这是 Ralph 最重要的设计决策。长会话里上下文越堆越多，AI 会越来越糊涂；Ralph 让每个任务都在一个干净的起点上完成。

任务文件示例（tasks.md）：

## Tasks

- 
[x] 初始化 Spring Boot 项目骨架

- 
[x] 设计 User 实体和 Repository 层

- 
[ ] 实现用户注册 Service（含密码加密）

- 
[ ] 实现 JWT 鉴权过滤器

- 
[ ] 编写集成测试：注册 + 登录完整流程

- 
[ ] Swagger 文档接入

Ralph 会自动摘取第一个 [ ] 任务，完成后打勾，继续下一个。

---

4. 四工具如何配合

以一个典型 Java 后端项目（Spring Boot + MyBatis Plus + Redis + RocketMQ）的新功能开发为例：

人工干预点只有两个：

阶段 3-4 可以完全无人值守；阶段 5 的 Review 是质量门禁，不是方向决策。

---

5. 积分系统-后端开发实战

Step 1：用 gstack 做需求验证（5 分钟）

你：需要做一个用户积分系统，用户消费、签到、推荐好友都能得分，积分可以兑换优惠券。


/office-hours

gstack 的 CEO 角色会反问你：

• 积分是否有有效期？过期如何处理？
• 并发场景下积分扣减如何保证幂等？
• 兑换失败是否要回滚积分？

然后用 /plan 让工程经理视角拆分任务：

## 工程任务拆解（gstack 输出）

1. 
设计积分流水表（points_ledger）+ 余额快照表

2. 
实现积分入账 Service（含幂等键设计）

3. 
实现积分扣减 Service（乐观锁 + 余额校验）

4. 
积分过期定时任务（xxl-job 集成）

5. 
积分兑换 Service（分布式事务：积分扣减 + 优惠券发放）

6. 
对外 API + Swagger 文档

7. 
集成测试：并发扣减场景验证

Step 2：用 OpenSpec 锁定规格（10 分钟）

/opsx-propose 积分入账 Service 实现


要求：

- 接口幂等，通过 bizId + bizType 去重

- 入账成功发送 MQ 事件通知下游

- 使用乐观锁防止余额超扣

OpenSpec 生成技术设计草案，你 Review 后修改两处细节（比如幂等窗口期定为 24 小时），然后：

规格锁定，写入 specs/points-service.md，后续所有 AI Session 都从这个文件读约束，不会走样。

Step 3：Superpowers 注入 TDD 约束

Superpowers 安装后通过 Skill 文件自动注入这些约束，不需要手动配置。下面是等效的手动写法，方便你看清楚它到底在 CLAUDE.md 里强制了什么：

## 强制规则（来自 Superpowers）


执行任何编码任务前，必须：

1. 
先写失败的单元测试（用 JUnit 5 + Mockito）

2. 
测试文件命名：
`[ClassName]Test.java`
，与实现类同包

3. 
实现类只能包含让测试通过的最少代码

4. 
测试通过后再考虑重构


禁止：

- 
先写实现再补测试

- 
测试里 mock 所有依赖（必须有至少一个真实断言）

Step 4：Ralph 自主执行（可以去喝咖啡了）

将 gstack 拆解的任务写入 tasks.md，启动 Ralph：

ralph run \

  --tasks tasks.md \

  --spec specs/points-service.md \

  --tool claude-code \

  --verify 
"mvn test"
 \

  --on-success 
"git add -A && git commit -m '[ralph] {task_name}'"

Ralph 会：

1. 读 tasks.md，摘第一个 [ ] 任务："实现积分入账 Service（含幂等键设计）"
2. 开新 Claude Code Session，注入 OpenSpec 规格 + Superpowers TDD 约束
3. AI 先写 PointsServiceTest.java（红灯），再写 PointsServiceImpl.java（绿灯）
4. 跑 mvn test，全部通过后自动 commit
5. 打勾，继续下一个任务

期间你不需要盯着它。一个中等复杂度的积分系统（7 个任务），Ralph 通常在数小时内跑完，具体时间视任务复杂度和 AI 响应速度而定。

Step 5：Review & 归档

gstack /review          
# 安全 + 代码规范检查

/opsx-archive           
# 变更合并进主文档

---

6. 我的常态化开发习惯

6.1 任务粒度控制

Ralph 的每个任务不能太大。经验值是：一个 AI Session 在 15-20 分钟内能完成。太大的任务上下文会越来越长，AI 开始犯糊涂。拆分原则：

6.2 Spec 先于代码

OpenSpec 的 specs/ 目录要加进 git，和代码一起提交。新人入项目看 specs/，三分钟内理解架构决策。这比读代码快 10 倍。

6.3 gstack 的 /careful 模式

在线上环境相关的代码（数据库 migration、Kafka Topic 配置）生成时，必须开启 gstack 的 /careful 模式。它会让 AI 在每个危险操作前暂停，等你确认。

6.4 测试是 Ralph 的退出条件

Ralph 的 --verify 参数就是你的质量门禁。建议分层设置：

--verify   
"mvn test -Dtest=*Test"
            
# 单元测试，每个任务完成后跑

--post-all 
"mvn verify -P integration-test"
   
# 集成测试，所有任务完成后跑一次

没有测试，Ralph 不提交，不打勾，不继续。这是硬约束。

6.5 上下文管理

每个 Ralph 迭代启动 Claude Code 时，注入一个固定的上下文文件（context.md）：

## 项目上下文（每个 Session 必读）

- 
项目：XX 教育平台后端服务

- 
技术栈：Spring Boot 3.x + MyBatis Plus + Redis + RocketMQ

- 
代码规范：@see specs/coding-standards.md

- 
当前任务规格：@see specs/points-service.md

- 
禁止事项：不引入新的第三方库，不修改 pom.xml 的 parent 版本

每个新 Session 启动时读这个文件，就不会出现"AI 不知道当前项目禁止改 pom.xml"这类低级错误。

6.6 常见出错场景处理

问题	通常原因	处理方式
Ralph 卡在某个任务不动	任务粒度太大，AI 上下文耗尽	手动拆成两个更小的任务，重新跑
OpenSpec 生成的 spec 与代码不一致	实施时临时改了设计但没更新 spec	跑 /opsx-archive 把变更同步回文档
gstack /office-hours 的问题答不上来	需求本身没想清楚	先回去想清楚再进入工具链，别硬撑
mvn test 全绿但功能表现不对	测试覆盖的是假设而非真实行为	手动跑集成测试，或补充端到端场景用例

---

7. 适合场景 vs 不适合场景

场景	适合程度	说明
新功能开发（有清晰需求）	⭐⭐⭐⭐⭐	四工具全上，效果最好
老代码重构	⭐⭐⭐⭐	OpenSpec 先做变更分析，Ralph 逐模块重构
Bug 修复	⭐⭐⭐	推荐只用 Superpowers Debug Skill 定位根因，不启 Ralph Loop
探索性原型	⭐⭐	规格还不清晰，用 gstack /office-hours 就够了
紧急线上问题	⭐	别用 AI Loop，直接上手，Ralph 的延迟你等不起

---

8. 总结

“

gstack 帮你想清楚，OpenSpec 帮你说清楚，Superpowers 帮你做规范，Ralph 帮你自动跑完。

四个工具各守一道关口，缺了哪个都会漏。

• 只用 Ralph 没有 OpenSpec：AI 自由发挥，最终代码和需求南辕北辙
• 只用 OpenSpec 没有 Superpowers：规格对了，但 AI 跳过测试，质量无保证
• 只用 Superpowers 没有 gstack：代码写得规范，但方向可能从一开始就错了
• 只用 gstack 没有 Ralph：人还是得盯着 AI 一步步做，效率翻不了数量级