AI編程實戰：用gstack + OpenSpec + Superpowers + Ralph 做到真正的AI 驅動開發
整理版優先睇
用gstack、OpenSpec、Superpowers同Ralph組合拳，將AI編程從情緒化實習生升級為守紀律工程團隊
呢篇文章係由一位實戰經驗豐富嘅開發者分享，佢想解決嘅根本問題係：點樣令AI編程工具唔再係一個「情緒化實習生」，而係一個守紀律嘅工程團隊。作者整合咗四款開源免費工具——gstack（虛擬團隊+治理框架）、OpenSpec（規格驅動開發）、Superpowers（編碼紀律執行器）同Ralph（自主迭代循環引擎）。整體結論係：呢四個工具各守一道關口，形成一條完整鏈路：治理→規格→紀律→自動化執行，缺一不可。
作者透過自身經驗示範，以一個Java後端積分系統為例，逐步展示點樣用呢套組合拳實現真正嘅AI驅動開發。佢強調，人工幹預點只需要兩個：需求驗證同代碼Review，中間嘅開發過程可以完全無人值守。文章仲提供咗詳細嘅安裝步驟、命令速查、常見出錯場景處理方法，同埋適合與唔適合使用嘅場景分析。
呢套方法嘅精髓係：先用gstack諗清需求，再用OpenSpec寫清規格，然後Superpowers確保編碼紀律，最後Ralph自動跑完。佢特別提醒，淨係用其中一兩個工具都會漏嘢，例如冇OpenSpec，AI會自由發揮；冇Superpowers，質量冇保證；冇gstack，方向可能一開始就錯；冇Ralph，人仍然要一直盯住，效率翻唔到倍。
- gstack 提供23個專家角色，透過斜槓命令（如 /office-hours、/plan）幫你驗證需求、拆解任務、做Code Review，從源頭減少方向跑偏。
- OpenSpec 用規格驅動開發（SDD），透過 Propose→Apply→Archive 三步驟，將所有約定寫入文件系統，AI每次讀文件而唔係靠聊天記錄，解決上下文丟失問題。
- Superpowers 強制TDD、設計先行、系統化Debug等工程紀律，禁止AI跳過測試或隨意寫代碼，確保輸出質量。
- Ralph 將AI編碼工具包裝成任務循環，每個任務開新Session避免上下文腐化，可無人值守跑完整個任務列表，並用 --verify 參數做質量門禁。
- 四工具配合時，人工幹預點只有需求驗證（gstack /office-hours）同最終Review（gstack /review + OpenSpec /opsx-archive），中間開發可完全自動化，適合新功能開發同老代碼重構。
gstack 倉庫
YC CEO Garry Tan 製作嘅虛擬團隊治理框架，含23個專家角色 Skill 文件。
OpenSpec 倉庫
規格驅動開發框架，支援 Propose→Apply→Archive 流程同 Delta Spec 機制。
Superpowers 倉庫
Jesse Vincent 製作嘅編碼紀律執行器，強制TDD、設計先行等工程最佳實踐。
Ralph 倉庫
自主迭代循環引擎，將AI編碼工具包裝成任務循環，支援無人值守執行。
工具組合概念：從治理到自動化嘅完整鏈路
呢篇文章介紹嘅四款工具——gstack、OpenSpec、Superpowers同Ralph——唔係各自為政，而係一條完整嘅開發鏈路。作者指出，好多團隊用AI編程時遇到嘅問題，例如「AI自由發揮」、「上下文愈嚟愈亂」、「跳過測試」，都源於缺少系統性約束。呢套組合拳嘅定位好清晰：gstack做治理，OpenSpec做規格，Superpowers做紀律，Ralph做自動化執行。
作者強調，好多開發者淨係用其中一兩個工具，結果依然要成日盯住AI。例如淨係用Ralph但冇OpenSpec，AI會自由發揮，最終代碼同需求南轅北轍；淨係用Superpowers但冇gstack，代碼寫得規範但方向可能一開始就錯咗。
工具安裝與核心用法
安裝呢四個工具之前，你要先裝好Claude Code CLI同Node.js ≥ 18。作者推薦最簡上手路徑係淨係裝Superpowers，然後慢慢加返其他工具。佢哋全部係開源免費，MIT協議，你可以直接喺GitHub clone嚟用。
- 1 gstack：由YC CEO Garry Tan製作，提供23個專家角色，透過斜槓命令運作。關鍵命令包括 /office-hours（驗證需求）、/plan（任務分解）、/review（代碼Review）、/ship（發佈檢查）、/careful（安全護欄）、/freeze（凍結代碼狀態）。
- 2 OpenSpec：規格驅動開發框架，三步工作法：Propose（提案）→ Apply（實施）→ Archive（歸檔）。Delta Spec機制淨係記錄變更，唔會重寫整個文件，相當於維護一份永遠更新嘅ADR。
- 3 Superpowers：Jesse Vincent製作嘅Skill文件集合，強制TDD、設計先行、系統化Debug同Code Review前置。佢透過CLAUDE.md注入規則，例如「先寫失敗測試，再寫實現」。
- 4 Ralph：取自動畫《辛普森一家》嘅角色，代表「唔聰明但死磕到底」。佢將AI編碼工具包喺一個任務循環腳本，每次迭代開全新AI Session，避免上下文腐化。
git clone https://github.com/obra/superpowers ~/.superpowers
# 跟住README運行安裝腳本，或手動將skills/目錄加入Claude Code配置
# 完成後喺項目根目錄運行Claude Code，/tdd、/debug等命令即可用gstack 嘅 /office-hours 命令係暴力追問你需求嘅合理性，好似YC風格嘅想法驗證
OpenSpec 嘅 Delta Spec 機制相當於喺代碼旁邊維護一份永遠最新嘅 Architecture Decision Record
Superpowers 強制 AI 先寫失敗測試再寫實現，唔準跳過測試
Ralph 每個任務開新 Session 係最重要嘅設計決策，防止上下文愈堆愈亂
實戰：積分系統開發流程
作者用一個典型Java後端（Spring Boot + MyBatis Plus + Redis + RocketMQ）嘅積分系統做例子，展示四工具點樣配合。成個過程人工幹預點只有兩個：Step 3-4嘅無人值守，同Step 5嘅質量門禁。
- 1 Step 1 - 用gstack做需求驗證（5分鐘）：輸入/office-hours，CEO角色會反問積分有效期、併發扣減冪等、兑換失敗回滾等問題。然後用/plan將任務拆成7個子任務，包括設計積分流水錶、實現冪等入賬Service、樂觀鎖扣減、過期定時任務、分佈式事務兑換、API文檔同集成測試。
- 2 Step 2 - 用OpenSpec鎖定規格（10分鐘）：/opsx-propose積分入賬Service要求，AI生成技術設計草案，你Review後修改細節（例如冪等窗口期24小時），然後/opsx-apply鎖定規格寫入specs/points-service.md。
- 3 Step 3 - Superpowers注入TDD約束：自動透過Skill文件強制先寫失敗測試、同包命名、最少實現代碼、唔準mock所有依賴。
- 4 Step 4 - Ralph自主執行：將任務寫入tasks.md，啟動ralph run命令，指定spec同verify參數。Ralph會逐個任務開新Session，注入規格同TDD約束，先寫測試（紅燈），再寫實現（綠燈），測試通過後自動commit，打勾繼續下一個。
- 5 Step 5 - Review & 歸檔：gstack /review做安全同代碼規範檢查，/opsx-archive將變更合併進主文檔。
gstack 嘅 /office-hours 會反問你：積分是否有有效期？併發場景下扣減點樣保證冪等？
OpenSpec 嘅 /opsx-propose 生成技術設計草案後，你要人工Review再修改細節
Superpowers 禁止 AI 先寫實現再補測試，測試必須先紅後綠
Ralph 自動摘取 tasks.md 入面第一個 [ ] 任務，完成後打勾
常態化開發習慣與常見出錯場景
作者分享咗幾個日常開發習慣，幫助你更好地用呢套工具。首要係任務粒度控制：每個AI Session最好喺15-20分鐘內完成，太大嘅任務AI會開始犯糊塗。另外，Spec先於代碼，OpenSpec嘅specs/目錄要加進git，新人三分鐘就可以理解架構決策。
- gstack 嘅 /careful 模式：喺線上環境相關代碼（數據庫migration、Kafka Topic配置）生成時必須開啟，AI會喺每個危險操作前暫停等你確認。
- 測試分層設置：ralph run 用 --verify 指定單元測試，用 --post-all 指定集成測試。硬約束：冇測試唔提交。
- 上下文管理：每個Ralph迭代注入一個固定context.md文件，包含項目技術棧、代碼規範、當前任務規格、禁止事項（例如唔準改pom.xml parent版本）。
- 常見出錯處理：Ralph卡住（任務太大，手動拆細）、OpenSpec spec同代碼不一致（跑/opsx-archive同步）、/office-hours答唔上（需求未諗清，先諗清楚）、mvn test全綠但功能錯（補充集成測試或端到端用例）。
OpenSpec 嘅 specs/ 目錄要加進 git，同代碼一齊提交
gstack 嘅 /careful 模式會令AI喺危險操作前暫停等你確認
Ralph 嘅 --verify 參數就係質量門禁，冇測試通過唔會繼續
每個新Session啟動時讀 context.md，就唔會出現「AI唔知項目禁止改pom.xml」呢類低級錯誤
適合場景 vs 唔適合場景
作者好坦誠咁講明呢套組合拳嘅適用範圍。新功能開發有清晰需求嘅時候，四工具全上效果最好，評分五粒星。老代碼重構都適合，但要先用OpenSpec做變更分析，再逐模塊重構。Bug修復就唔建議用Ralph Loop，淨係用Superpowers嘅Debug Skill定位根因就夠。
- 新功能開發（有清晰需求）：⭐⭐⭐⭐⭐ 四工具全上，效果最好
- 老代碼重構：⭐⭐⭐⭐ 先用OpenSpec做變更分析，Ralph逐模塊重構
- Bug修復：⭐⭐⭐ 淨係用Superpowers Debug Skill定位根因，唔好開Ralph Loop
- 探索性原型：⭐⭐ 規格仲唔清晰，用gstack /office-hours就夠
- 緊急線上問題：⭐ 直接上手，唔好用AI Loop，Ralph嘅延遲你等唔起
新功能開發四工具全上效果最好，但緊急線上問題要直接上手
探索性原型階段，用 gstack 嘅 /office-hours 就夠，唔需要全套工具
0. 同你介紹返套組合拳
呢套組合拳要解決嘅根本問題係：令 AI 好似一個守紀律嘅工程師團隊，而唔係一個情緒化嘅實習生。
| gstack | ||
| OpenSpec | ||
| Superpowers | ||
| Ralph |
呢四個形成一條完整嘅鏈路：治理 → 規格 → 紀律 → 自動化執行。
1. 前置條件
喺安裝任何工具之前，你需要：
Claude Code CLI：呢四個工具都係基於 Claude Code 運行。去 claude.ai/code 下載同安裝。 Node.js ≥ 18（Ralph 運行所需） 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 | ||
| OpenSpec | ||
| Superpowers | ||
| Ralph |
四個都係開源免費嘅，全部用 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 小時），跟住：
/opsx-apply
規格鎖定，寫入 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 會：
讀 tasks.md，拎第一個[ ]任務：『實現積分入賬 Service（含冪等鍵設計）』開新 Claude Code Session，注入 OpenSpec 規格 + Superpowers TDD 約束 AI 先寫 PointsServiceTest.java（紅燈），再寫PointsServiceImpl.java（綠燈）跑 mvn test，全部通過之後自動 commit打剔，繼續下一個任務
期間你唔需要睇住佢。一個中等複雜度嘅積分系統（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 常見出錯場景處理
/opsx-archive 將變更同步返去文檔 | ||
/office-hours 嘅問題答唔到 | ||
mvn test |
7. 適合場景 vs 不適合場景
8. 總結
“gstack 幫你諗清楚，OpenSpec 幫你講清楚，Superpowers 幫你做規範，Ralph 幫你自動行完。
四個工具各守一道關口，缺咗邊個都會漏。
只用 Ralph 冇 OpenSpec：AI 自由發揮，最後代碼同需求南轅北轍 只用 OpenSpec 冇 Superpowers：規格啱，但 AI Skip 測試，質量冇保證 只用 Superpowers 冇 gstack：代碼寫得規範，但方向可能由一開始就錯咗 只用 gstack 冇 Ralph：人仲要睇住 AI 一步步行，效率翻唔到數量級
0. 給你介紹一套組合拳
這套組合拳要解決的根本問題是：讓 AI 像一個守紀律的工程師團隊，而不是一個情緒化的實習生。
| gstack | ||
| OpenSpec | ||
| Superpowers | ||
| Ralph |
四者形成一條完整的鏈路：治理 → 規格 → 紀律 → 自動化執行。
1. 前置條件
在安裝任何工具之前，你需要：
Claude Code CLI：這四個工具都基於 Claude Code 運行。前往 claude.ai/code 下載並安裝。 Node.js ≥ 18（Ralph 運行所需） 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 | ||
| OpenSpec | ||
| Superpowers | ||
| Ralph |
四個都是開源免費的，全部 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 小時），然後：
/opsx-apply
規格鎖定，寫入 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 會：
讀 tasks.md，摘第一個[ ]任務："實現積分入賬 Service（含冪等鍵設計）"開新 Claude Code Session，注入 OpenSpec 規格 + Superpowers TDD 約束 AI 先寫 PointsServiceTest.java（紅燈），再寫PointsServiceImpl.java（綠燈）跑 mvn test，全部通過後自動 commit打勾，繼續下一個任務
期間你不需要盯着它。一箇中等複雜度的積分系統（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 常見出錯場景處理
/opsx-archive 把變更同步迴文檔 | ||
/office-hours 的問題答不上來 | ||
mvn test |
7. 適合場景 vs 不適合場景
8. 總結
“gstack 幫你想清楚，OpenSpec 幫你說清楚，Superpowers 幫你做規範，Ralph 幫你自動跑完。
四個工具各守一道關口，缺了哪個都會漏。
只用 Ralph 沒有 OpenSpec：AI 自由發揮，最終代碼和需求南轅北轍 只用 OpenSpec 沒有 Superpowers：規格對了，但 AI 跳過測試，質量無保證 只用 Superpowers 沒有 gstack：代碼寫得規範，但方向可能從一開始就錯了 只用 gstack 沒有 Ralph：人還是得盯着 AI 一步步做，效率翻不了數量級