告別 Vibe Coding：Claude Code + Superpowers = 頂級架構師開發流程
整理版優先睇
Superpowers 將工程紀律注入 AI 工作流，告別 Vibe Coding 嘅混亂
呢篇文章由作者整理自 Jesse Vincent 開源嘅 Claude Code 插件 Superpowers，對比 Vibe Coding 同工程化開發嘅分別。作者指出 Vibe Coding（憑感覺俾 prompt、唔細睇、能跑就得）喺寫 Demo 或一次性腳本嗰陣好爽，但一落入生產項目就會撞牆——上下文膨脹令 AI 越寫越歪，需求未澄清就動手、測試缺位、改動範圍失控，兩星期後冇人敢掂啲 Code。
Superpowers 嘅設計哲學係「把工程紀律塞返入 AI」，唔係教 AI 點樣寫好 Code，而係強制 AI 唔可以寫差。佢透過 Subagent-Driven Development（子代理驅動開發）做到上下文隔離，每個任務用全新子代理，唔帶歷史對話；再加上兩階段審查（Spec Review 先睇功能正確性，Quality Review 再睇代碼質素）同強制 TDD（一定要先寫測試，否則自動刪 Code 叫你重新嚟過），成個流程由 Brainstorming 到任務拆解、執行、審查都逐個打卡。
整體結論係：Superpowers 係 Vibe Coding 以外嘅另一條路——畀真正需要紀律嘅生產項目用。但佢非常燒 Token（消耗係 Vibe Coding 嘅 5-10 倍），公司報銷可以放心裝，個人自費就建議先喺小項目試清楚。
- Vibe Coding 喺小項目飛得起，但生產項目會因上下文膨脹而失控，三個月後無人敢改。
- Superpowers 用子代理驅動開發（Subagent-Driven Development）做到上下文隔離，每個任務由全新子代理執行。
- 兩階段審查：先 Spec Review（功能正確性），後 Quality Review（代碼質素），唔通過直接重做，唔修補。
- 強制 TDD（RED→GREEN→REFACTOR）：唔寫測試嘅 Code 會自動被刪，強迫開發者先寫測試。
- Token 消耗係 Vibe Coding 嘅 5-10 倍，建議公司報銷先用；個人自費要計清楚成本。
Superpowers GitHub 倉庫
Jesse Vincent 開源嘅 Claude Code 插件，包含完整 Skills 同安裝指引。
安裝 Superpowers（官方市場）
喺 Claude Code 執行 /plugin install superpowers@claude-plugins-official，然後重啟即可使用。
安裝注意事項
也可用作者自己嘅市場：/plugin marketplace add obra/superpowers-marketplace 再 /plugin install superpowers@superpowers-marketplace。其他平台（Cursor、Codex、OpenCode）嘅安裝方式見 README。
內容片段
AI: "這個限流器要做單機的還是分佈式的？"User: "分佈式，多個微服務共用"AI: "限流算法選哪個：固定窗口、滑動窗口、令牌桶、漏桶？"User: "令牌桶，要平滑流量"AI: "Key 維度怎麼定？按用戶、按 IP、按接口，還是組合？"User: "用戶 + 接口"AI: "存儲用 Redis 單實例、集羣，還是本地內存兜底？"...告別 Vibe Coding：工程紀律回歸
Andrej Karpathy 喺 2025 年提出嘅 Vibe Coding——憑感覺俾 prompt，睇 AI 跑，能跑就得——呢種風格喺寫 Demo 或腳本時好爽，但生產項目一定會撞牆：需求未澄清就動手、實現方案冇人評審、測試缺位、改動範圍失控。三個月後就冇人敢掂啲 Code，因為你叫 Claude 加個功能，佢順手改咗五個文件，你唔知佢改咗咩，亦唔知點解改。
呢個唔係 AI 唔得，係流程唔得。
Superpowers 係 Vibe Coding 嘅反義詞——每一步都打卡，唔畀 AI 亂飛。Jesse Vincent 開源嘅呢個 Claude Code 插件，核心哲學係「把工程紀律塞返入 AI」，用 20+ 個可組合嘅 Skills 強制 AI 唔可以寫差。
核心機制：子代理驅動開發與上下文隔離
Vibe Coding 喺大項目上一定會撞上「上下文膨脹」——對話輪次越多，模型要處理嘅歷史越長，早期決策一直影響後續，代碼質素一條單調下滑嘅曲線。Superpowers 嘅核心機制係 Subagent-Driven Development（子代理驅動開發），每個任務啟動一個全新子代理，只接收當前任務描述，歷史對話唔帶入。
- 1 上下文隔離：每個子代理從空白啟動，只接收當前任務；
- 2 職責分離：寫 Code 嘅子代理同審查 Code 嘅係兩個不同代理；
- 3 快速重試：審查唔通過直接新建子代理，唔喺原上下文反覆磨；
- 4 並行執行：獨立任務可以分發俾多個子代理同時跑。
Vibe Coding 係「一個 AI 由頭跑到尾，越跑越累」；Superpowers 係「每個任務都派一個清醒嘅新人去做」。
四條鐵律確保每個任務都喺最乾淨嘅狀態下執行，避免早期錯誤污染後續判斷。
兩階段審查與強制 TDD：唔畀 AI 偷懶
代碼審查最常見嘅失誤係一邊討論代碼風格，一邊忽略功能缺陷。Superpowers 將審查拆成兩輪，順序嚴格，關注點分離：第一輪 Spec Review 淨係睇實現係咪滿足需求（功能點全、邊界條件處理、測試覆蓋），第二輪 Quality Review 先睇代碼維護性（風格一致、DRY、命名清晰、不過度工程）。
第一輪唔通過唔係修補，係直接重做：系統創建新子代理重新執行任務，原代碼直接丟棄。
更狠嘅係強制 TDD。每個任務必須先寫測試，測試失敗之後先準寫實現，實現通過之後先準重構——RED → GREEN → REFACTOR，循環唔可以跳。如果 Claude 檢測到 Code 係冇測試嘅情況下先寫，會自動刪 Code 叫你重新嚟過。
別嘅工具勸你寫測試，Superpowers 直接沒收你唔寫測試嘅權利。
完整工作流：由 Brainstorming 到合併
Superpowers 嘅工作流分成七個階段，每個對應具體技能。第一階段 Brainstorming 會停低問你問題（例如限流器要單機定分佈式、限流算法揀邊款、Key 維度點定），確認完之後先畀 2-3 個方案你揀，定好先生成 design.md，分段確認，最後先提交 Git。
睇落慢，實際上省咗大量後期返工——需求未搞清楚就寫 Code，後面嘅麻煩只會更多。
第二階段用 Git Worktree 隔離環境，允許多個功能並行開發。第三階段寫 Plans，將任務拆到 2-5 分鐘可完成，每個任務有明確驗證步驟。之後就係執行階段：派子代理執行 → 強制 TDD → 兩階段審查 → 通過就下一個，唔通過重建子代理重做。所有任務做完可選合併到主分支、生成 GitHub PR、保留 worktree 或丟棄。
- 兩種執行模式：Subagent-Driven Development（獨立執行、自動審查，適合需求清楚嘅任務）同 Executing Plans（批量執行、人工檢查，適合探索性開發）。
- 技能透過關鍵詞自動觸發，可以組合使用，例如「用 TDD 實現訂單導出接口，完成後幫我做代碼審查」會同時觸發 test-driven-development 同 requesting-code-review。
成本與實操建議：Token 消耗要計清楚
Superpowers 好用但非常燒 Token：子代理隔離令每個任務都要重載上下文；兩階段審查同一段 Code 至少跑三次（實現 → Spec Review → Quality Review，唔通過仲要重做）；強制 TDD 多一倍測試 Code 生成。一個簡單功能落嚟，Token 消耗輕鬆係 Vibe Coding 嘅 5-10 倍。
喺 Token 計費越來越緊嘅當下，呢個成本係要計清楚嘅。
安裝方法最簡單係用官方市場命令：/plugin install superpowers@claude-plugins-official，重啟 Claude Code 就用得。其他平台（Cursor、Codex、OpenCode）嘅安裝方式請參考 README。
Superpowers 係俾真正需要紀律嘅項目用嘅，唔係俾所有場景。
👉 呢個可能幫到你的社羣
🐱 一對一交流/面試小冊/簡歷優化/求職解惑，歡迎加入「芋道快速開發平台」知識星球。下面係星球提供嘅部分資料：
《項目實戰（視頻）》：從書中學，事上練“練” 《互聯網高頻面試題》：對住簡歷嚟學，春暖花開 《架構 x 系統設計》：摧枯拉朽，掌握面試高頻場景題 《精進 Java 學習指南》：系統學習，互聯網主流技術棧 《必讀 Java 源碼專欄》：知其然，知其所以然
👉呢個係一個可能幫到你嘅開源項目
國產Star破10萬嘅開源項目，前端包括管理後台、微信小程序，後端支援單體、微服務架構
RBAC權限、數據權限、SaaS多租户、商城、支付、工作流、大屏報表、ERP、CRM、AI大模型、IoT物聯網等功能：
多模塊：https://gitee.com/zhijiantianya/ruoyi-vue-pro 微服務：https://gitee.com/zhijiantianya/yudao-cloud 視頻教程：https://doc.iocoder.cn
來源：
vibe coding 喺小項目可以飛，大項目會冧 Superpowers 真正做緊嘅事：將工程紀律塞返入 AI 元問題：上下文膨脹令到 AI 越寫越歪 兩階段審查：等 AI 學識揀自己嘅錯 強制 TDD：AI 唔主動寫測試，咁就唔好俾佢揀 完整工作流：由頭腦風暴到合併 兩種執行模式點揀 安裝方法：官方市場最省心 技能速查同觸發方式 最後講兩句：好用，但好燒 token
vibe coding 喺小項目可以飛，大項目會冧
Andrej Karpathy 喺 2025 年提出一個詞叫 vibe coding ——憑感覺畀 prompt，睇 AI 跑，唔仔細睇，行到就得。呢種風格喺寫一個 demo、跑一個腳本嗰陣確係好爽。
國內開發者近半年幾乎都俾 AI 編程工具洗版——Cursor、Trae、通義靈碼、CodeBuddy、CodeWhisperer 國內版 輪住出新版本，朋友圈裏面「昨晚 Cursor 幫我 vibe 出一個 SaaS」嘅截圖越來越多。但圈子裏面都開始有反向聲音：vibe 出嚟嘅代碼，三個月後冇人敢掂 。呢個唔係工具嘅問題，係 vibe 呢種工作方式本身喺生產項目上有天花板。
但 vibe 喺生產項目一定會撞牆：
需求未釐清就開工； 實現方案冇人評審； 測試缺位； 改動範圍失控。
代碼的確行得到。問題係兩星期後冇人敢掂——你叫 Claude 加個功能，佢順手改咗五個文件，你唔知佢改咗咩，亦唔知佢為什麼 改。
呢個唔係 AI 唔得，係流程唔得 。軟件工程嗰套「需求澄清 → 設計評審 → 拆任務 → TDD → Code Review」唔係整嚟拖慢人，係用嚟防止上面呢啲事。
Superpowers 係 vibe coding 嘅相反詞 ——佢唔畀 AI 飛，每一步都要打卡。
基於 Spring Boot + MyBatis Plus + Vue & Element 實現嘅後台管理系統 + 用戶小程序，支援 RBAC 動態權限、多租户、數據權限、工作流、三方登錄、支付、短信、商城等功能
項目地址：https://github.com/YunaiV/ruoyi-vue-pro 視頻教程：https://doc.iocoder.cn/video/
Superpowers 真正做緊嘅事：將工程紀律塞返入 AI
Jesse Vincent（GitHub: obra）喺 2025 年 10 月開源嘅 Claude Code 插件，而家已經上咗官方市場。
佢嘅設計哲學好反潮流：喺所有人追求「AI 寫得更快 」嘅時候，佢要 AI「寫得更穩 」。具體做法係將軟件工程嘅核心環節做成 20+ 可組合嘅 Skills——需求澄清、設計評審、任務拆解、TDD、代碼審查——每個 Skill 有觸發條件、執行流程、產出物，全部行 Git 留痕。
一句話概括：佢唔教 AI 點樣寫好代碼，佢強制 AI 唔可以寫差。
系統分四層：
技能文件係 YAML Frontmatter + Markdown，輕量、可讀、可自定義——呢個意味住你可以自己寫 Skill，唔係淨係用得作者嗰 20 個 。
基於 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現嘅後台管理系統 + 用戶小程序，支援 RBAC 動態權限、多租户、數據權限、工作流、三方登錄、支付、短信、商城等功能
項目地址：https://github.com/YunaiV/yudao-cloud 視頻教程：https://doc.iocoder.cn/video/
元問題：上下文膨脹令到 AI 越寫越歪
vibe coding 喺大項目一定會撞上一道牆——上下文膨脹 。
對話輪次越多，模型要處理嘅歷史越長，早期決策一直影響後續。AI 寫到第 50 輪仲俾第 5 輪嘅錯誤判斷拖住行，代碼質量係一條單調下滑嘅曲線。
Superpowers 嘅核心機制叫 Subagent-Driven Development（子代理驅動開發） ——每個任務啟動一個全新嘅子代理，淨係俾佢當前任務嘅描述，歷史對話唔帶入 。做完之後專門開一個審查子代理做質量檢查。
四條鐵律：
上下文隔離 ：每個子代理由空白啟動，淨係接收當前任務； 職責分離 ：寫代碼嘅子代理同審查代碼嘅係兩個唔同嘅； 快速重試 ：審查唔通過就直接新建子代理，唔喺原上下文裏面反覆磨； 並行執行 ：獨立任務可以分派俾多個子代理同時跑。
理解一下呢個意味住咩：vibe coding 係「一個 AI 由頭跑到尾，越跑越攰」；Superpowers 係「每個任務都派一個清醒嘅新人去做 」。
兩階段審查：等 AI 學識揀自己嘅錯
代碼審查最常見嘅失誤係咩？一邊討論代碼風格，一邊忽略功能缺陷 。Superpowers 將呢件事拆成兩輪——順序唔可以掉轉，關注點嚴格分離：
| 第一輪：Spec Review | |||
| 第二輪：Quality Review |
將兩件事拆開係因為人類做 review 都好易走神 ——望住括號位置嗰陣會唔記得邊界條件未處理。等兩個唔同嘅子代理各管一件事，至少可以逼住 AI 都跟呢個分工行。
第一輪唔通過——唔係修補，係直接重做 ：系統創建一個新嘅子代理重新執行任務，原代碼直接丟棄。
呢個機製表面睇好暴力，邏輯係啱嘅：錯嘅實現修補兩次都係錯嘅，直接重做反而更慳時間 。
強制 TDD：AI 唔主動寫測試，咁就唔好俾佢揀
Superpowers 最反直覺嘅設計係強制 TDD 。
你可能會寫測試，但你嘅同事 Claude 大概率唔寫。佢嘅默認行為係將功能行返著先，測試係「得閒先補」——呢個唔係 AI 懶，係訓練數據偏差：大部分公開代碼本身就冇測試 。
Superpowers 直接將呢件事砍掉：每個任務必須先寫測試，測試失敗之後先準寫實現 ，實現通過之後先準重構。RED → GREEN → REFACTOR，循環唔可以跳。
仲狠嘅係：如果 Claude 檢測到代碼係冇測試嘅情況下先寫，會自動刪咗叫你重來 。Jesse Vincent 喺博客度寫：「同一個懶得寫測試嘅初級工程師共事嘅感覺，系統直接將呢個習慣掐掉。」
呢個係成套 Superpowers 裏面最有「紀律感 」嘅一節——第啲工具勸你寫測試，佢直接沒收你唔寫測試嘅權利。
完整工作流：由頭腦風暴到合併
七個階段，每個對應具體技能。
階段一：Brainstorming（頭腦風暴）
呢個係同普通 AI 編程工具差距最大嘅地方——佢會先停低問問題 。
AI: "這個限流器要做單機的還是分佈式的？"
User: "分佈式，多個微服務共用"
AI: "限流算法選哪個：固定窗口、滑動窗口、令牌桶、漏桶？"
User: "令牌桶，要平滑流量"
AI: "Key 維度怎麼定？按用戶、按 IP、按接口，還是組合？"
User: "用戶 + 接口"
AI: "存儲用 Redis 單實例、集羣，還是本地內存兜底？"
...
確認完之後畀出 2-3 個實現方案俾你揀，揀定先生成 design.md，分段（200-300 字）俾你逐段確認，最後提交到 Git。
呢一步睇落慢，實際慳咗大量後期返工——需求未搞清楚就寫代碼，後面嘅麻煩只會更多 。
階段二：Git Worktree（環境隔離）
git worktree add ../rate-limit-worktree -b feature/rate-limit
cd ../rate-limit-worktree
允許多個功能喺唔同目錄下並行開發，IDE 唔會頻繁重索引。
階段三：Writing Plans（任務拆解）
任務粒度控制在 2-5 分鐘 ，每個任務有明確驗證步驟：
## Task: 實現令牌桶算法 (3 分鐘)
- 編寫 TokenBucket 類，支持 capacity 和 refillRate
- 實現 tryAcquire(tokens) 方法（線程安全）
- 單元測試：突發流量 / 持續低流量 / 超額請求
驗證步驟：
- [ ] 測試通過
- [ ] 1 秒內不超過 refillRate 的請求全部成功
- [ ] 併發場景下不出現負數令牌
任務之間盡量減少依賴，方便子代理並行。
階段四 → 階段七
簡單粗暴：派子代理執行 → 強制 TDD → 兩階段審查 → 通過就下一個，唔通過新建子代理重做 。所有任務做完，提供選項：合併到主分支 / 生成 GitHub PR / 保留 worktree / 丟棄。清理 worktree，結束。
兩種執行模式點揀
一句話揀法：需求清楚、測試完整就用第一種；探索性開發、要中途轉方向就用第二種 。
安裝方法：官方市場最省心
/plugin install superpowers@claude-plugins-official
或者用作者自己嘅市場：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
裝完重啟 Claude Code 就可以用。
其他平台：
Cursor ：Agent chat 裏邊搜 "superpowers" Codex ：叫佢獲取 https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md按說明操作OpenCode ：路徑換成 .opencode/INSTALL.mdGitHub Copilot CLI / Gemini CLI ：睇 README
技能速查同觸發方式
brainstorming | ||
writing-plans | ||
executing-plans | ||
test-driven-development | ||
systematic-debugging | ||
verification-before-completion | ||
requesting-code-review | ||
subagent-driven-development | ||
using-git-worktrees |
技能透過關鍵詞自動觸發，可以組合使用：
用 TDD 實現訂單導出接口，完成後幫我做代碼審查
呢條同時觸發 test-driven-development 和 requesting-code-review。
最後講兩句：好用，但好燒 token
vibe coding 冇錯。喺 demo / 原型 / 一次性腳本場景，佢係目前最高效嘅寫法——唔需要嘅工程紀律就係浪費。
但生產項目唔係 vibe 可以頂得住。Superpowers 畀嘅唔係「比 vibe 更好嘅 prompt」，係 vibe 之外嘅另一條路 ——將軟件工程嗰套真正起作用嘅紀律，重新裝返入 AI 工作流 。
不過裝之前先講一句好現實嘅事：Superpowers 真係好燒 token 。
子代理隔離 = 每個任務都重載上下文； 兩階段審查 = 同一段代碼至少跑三次（實現 → Spec Review → Quality Review，唔通過仲要重做）； 強制 TDD = 多一倍嘅測試代碼生成。
一個簡單功能落嚟，token 消耗輕鬆係 vibe coding 嘅 5-10 倍 。喺 token 計費越嚟越緊嘅當下，呢個成本係要計清楚嘅。
實操建議好簡單：
公司報銷 / 團隊預算夠 ：放心裝，長期可維護性嘅回報遠大過 token 成本。 個人自費 ：先喺小項目上試，跑過幾次再決定要唔要喺主力項目上鋪開。 vibe 已經搞得掂嘅場景 ：唔好硬上工程化，Superpowers 係俾真正需要紀律嘅項目用嘅 。
工程化唔係免費午餐——質量提上去嘅同時賬單都跟住上去。諗清楚先裝。
GitHub 地址：https://github.com/obra/superpowers
歡迎加入我嘅知識星球，全面提升技術能力。
👉 加入方式，“長按”或“掃描」下方二維碼噢：
星球的內容包括：項目實戰、面試招聘、源碼解析、學習路線。
文章有幫助的話，在看，轉發吧。
謝謝支持喲 (*^__^*）
👉 這是一個或許對你有用的社羣
🐱 一對一交流/面試小冊/簡歷優化/求職解惑，歡迎加入「芋道快速開發平台」知識星球。下面是星球提供的部分資料：
《項目實戰（視頻）》：從書中學，往事上“練” 《互聯網高頻面試題》：面朝簡歷學習，春暖花開 《架構 x 系統設計》：摧枯拉朽，掌控面試高頻場景題 《精進 Java 學習指南》：系統學習，互聯網主流技術棧 《必讀 Java 源碼專欄》：知其然，知其所以然
👉這是一個或許對你有用的開源項目
國產Star破10w的開源項目，前端包括管理後台、微信小程序，後端支持單體、微服務架構
RBAC權限、數據權限、SaaS多租户、商城、支付、工作流、大屏報表、ERP、CRM、AI大模型、IoT物聯網等功能：
多模塊：https://gitee.com/zhijiantianya/ruoyi-vue-pro 微服務：https://gitee.com/zhijiantianya/yudao-cloud 視頻教程：https://doc.iocoder.cn
來源：
vibe coding 在小項目能飛，大項目會塌 Superpowers 真正在做的事：把工程紀律塞回 AI 元問題：上下文膨脹讓 AI 越寫越歪 兩階段審查：讓 AI 學會挑自己的刺 強制 TDD：AI 不主動寫測試，那就別給它選 完整工作流：從頭腦風暴到合併 兩種執行模式怎麼選 安裝方法：官方市場最省心 技能速查和觸發方式 最後說兩句：好用，但很燒 token
vibe coding 在小項目能飛，大項目會塌
Andrej Karpathy 在 2025 年提了個詞叫 vibe coding ——憑感覺給 prompt，看 AI 跑，不細看，能跑就行。這風格在寫一個 demo、跑一個腳本時確實很爽。
國內開發者最近半年幾乎都被 AI 編程工具刷屏——Cursor、Trae、通義靈碼、CodeBuddy、CodeWhisperer 國內版 輪番出新版本，朋友圈裏"昨晚 Cursor 幫我 vibe 出一個 SaaS"的截圖越來越多。但圈子裏也開始有反向聲音：vibe 出來的代碼，三個月後沒人敢碰 。這不是工具的問題，是 vibe 這種工作方式本身在生產項目上有天花板。
但 vibe 在生產項目上一定會撞牆：
需求沒澄清就動手； 實現方案沒人評審； 測試缺位； 改動範圍失控。
代碼確實能跑。問題是兩週後沒人敢碰——你讓 Claude 加個功能，它順手改了五個文件，你不知道它改了啥，也不知道它為什麼 改。
這不是 AI 不行，是流程不行 。軟件工程那套「需求澄清 → 設計評審 → 拆任務 → TDD → Code Review」不是給人類拖慢速度用的，是用來防止上面這些事的。
Superpowers 是 vibe coding 的反義詞 ——它不讓 AI 飛，每一步都打卡。
基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後台管理系統 + 用戶小程序，支持 RBAC 動態權限、多租户、數據權限、工作流、三方登錄、支付、短信、商城等功能
項目地址：https://github.com/YunaiV/ruoyi-vue-pro 視頻教程：https://doc.iocoder.cn/video/
Superpowers 真正在做的事：把工程紀律塞回 AI
Jesse Vincent（GitHub: obra）在 2025 年 10 月開源的 Claude Code 插件，現在已上官方市場。
它的設計哲學很反潮流：在所有人追求「AI 寫得更快 」的時候，它要 AI「寫得更穩 」。具體做法是把軟件工程的核心環節做成 20+ 可組合的 Skills——需求澄清、設計評審、任務拆解、TDD、代碼審查——每個 Skill 有觸發條件、執行流程、產出物，全部走 Git 留痕。
一句話概括：它不教 AI 怎麼寫好代碼，它強制 AI 不能寫差。
系統分四層：
技能文件是 YAML Frontmatter + Markdown，輕量、可讀、可自定義——這意味着你可以自己寫 Skill，不是隻能用作者那 20 個 。
基於 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的後台管理系統 + 用戶小程序，支持 RBAC 動態權限、多租户、數據權限、工作流、三方登錄、支付、短信、商城等功能
項目地址：https://github.com/YunaiV/yudao-cloud 視頻教程：https://doc.iocoder.cn/video/
元問題：上下文膨脹讓 AI 越寫越歪
vibe coding 在大項目上一定會撞上一堵牆——上下文膨脹 。
對話輪次越多，模型要處理的歷史越長，早期決策一直影響後續。AI 寫到第 50 輪還在被第 5 輪的錯誤判斷拖着走，代碼質量是一條單調下滑的曲線。
Superpowers 的核心機制叫 Subagent-Driven Development（子代理驅動開發） ——每個任務啓動一個全新的子代理，只給它當前任務的描述，歷史對話不帶入 。做完之後專門起一個審查子代理做質量檢查。
四條鐵律：
上下文隔離 ：每個子代理從空白啓動，只接收當前任務； 職責分離 ：寫代碼的子代理和審查代碼的是兩個不同的； 快速重試 ：審查不通過直接新建子代理，不在原上下文裏反覆磨； 並行執行 ：獨立任務可以分發給多個子代理同時跑。
理解一下這意味着什麼：vibe coding 是「一個 AI 從頭跑到尾，越跑越累」；Superpowers 是「每個任務都派一個清醒的新人去做 」。
兩階段審查：讓 AI 學會挑自己的刺
代碼審查最常見的失誤是什麼？一邊討論代碼風格，一邊忽略功能缺陷 。Superpowers 把這件事拆成兩輪——順序不能顛倒，關注點嚴格分離：
| 第一輪：Spec Review | |||
| 第二輪：Quality Review |
把兩件事拆開是因為人類做 review 也容易走神 ——盯着括號位置時會忘了邊界條件沒處理。讓兩個不同的子代理各管一件事，至少能逼着 AI 也按這個分工走。
第一輪不通過——不是修補，是直接重做 ：系統創建一個新的子代理重新執行任務，原代碼直接丟棄。
這個機制乍看暴力，邏輯很對：錯的實現修補兩次還是錯的，直接重做反而更省時間 。
強制 TDD：AI 不主動寫測試，那就別給它選
Superpowers 最反直覺的設計是強制 TDD 。
你或許寫測試，但你的同事 Claude 大概率不寫。它的默認行為是先把功能跑起來，測試是「有空再補」——這不是 AI 偷懶，是訓練數據偏差：大部分公開代碼本身就沒測試 。
Superpowers 直接把這件事幹掉：每個任務必須先寫測試，測試失敗之後才允許寫實現 ，實現通過之後才允許重構。RED → GREEN → REFACTOR，循環不能跳。
更狠的是：如果 Claude 檢測到代碼是在沒測試的情況下先寫的，會自動刪掉讓你重來 。Jesse Vincent 在博客裏寫：「跟一個懶得寫測試的初級工程師共事的感覺，系統直接把這個習慣掐掉了。」
這是整套 Superpowers 裏最有「紀律感 」的一節——別的工具勸你寫測試，它直接沒收你不寫測試的權利。
完整工作流：從頭腦風暴到合併
七個階段，每個對應具體技能。
階段一：Brainstorming（頭腦風暴）
這是和普通 AI 編程工具差距最大的地方——它會先停下來問問題 。
AI: "這個限流器要做單機的還是分佈式的？"
User: "分佈式，多個微服務共用"
AI: "限流算法選哪個：固定窗口、滑動窗口、令牌桶、漏桶？"
User: "令牌桶，要平滑流量"
AI: "Key 維度怎麼定？按用戶、按 IP、按接口，還是組合？"
User: "用戶 + 接口"
AI: "存儲用 Redis 單實例、集羣，還是本地內存兜底？"
...
確認完之後給出 2-3 個實現方案讓你選，定完才生成 design.md，分段（200-300 字）讓你逐段確認，最後提交到 Git。
這一步看着慢，實際省了大量後期返工——需求沒搞清楚就寫代碼，後面的麻煩只會更多 。
階段二：Git Worktree（環境隔離）
git worktree add ../rate-limit-worktree -b feature/rate-limit
cd ../rate-limit-worktree
允許多個功能在不同目錄下並行開發，IDE 不會頻繁重索引。
階段三：Writing Plans（任務拆解）
任務粒度控制在 2-5 分鐘 ，每個任務有明確驗證步驟：
## Task: 實現令牌桶算法 (3 分鐘)
- 編寫 TokenBucket 類，支持 capacity 和 refillRate
- 實現 tryAcquire(tokens) 方法（線程安全）
- 單元測試：突發流量 / 持續低流量 / 超額請求
驗證步驟：
- [ ] 測試通過
- [ ] 1 秒內不超過 refillRate 的請求全部成功
- [ ] 併發場景下不出現負數令牌
任務之間儘量減少依賴，方便子代理並行。
階段四 → 階段七
簡單粗暴：派子代理執行 → 強制 TDD → 兩階段審查 → 通過就下一個，不通過新建子代理重做 。所有任務做完，提供選項：合併到主分支 / 生成 GitHub PR / 保留 worktree / 丟棄。清理 worktree，結束。
兩種執行模式怎麼選
一句話選型：需求清楚、測試完整就用第一種；探索性開發、要中途換方向就用第二種 。
安裝方法：官方市場最省心
/plugin install superpowers@claude-plugins-official
或者用作者自己的市場：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
安裝完重啓 Claude Code 就能用。
其他平台：
Cursor ：Agent chat 裏搜 "superpowers" Codex ：讓它獲取 https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md按說明操作OpenCode ：路徑換成 .opencode/INSTALL.mdGitHub Copilot CLI / Gemini CLI ：見 README
技能速查和觸發方式
brainstorming | ||
writing-plans | ||
executing-plans | ||
test-driven-development | ||
systematic-debugging | ||
verification-before-completion | ||
requesting-code-review | ||
subagent-driven-development | ||
using-git-worktrees |
技能通過關鍵詞自動觸發，可以組合使用：
用 TDD 實現訂單導出接口，完成後幫我做代碼審查
這條同時觸發 test-driven-development 和 requesting-code-review。
最後說兩句：好用，但很燒 token
vibe coding 沒錯。在 demo / 原型 / 一次性腳本場景，它是當前最高效的寫法——不需要的工程紀律就是浪費。
但生產項目不是 vibe 能扛住的。Superpowers 給的不是「比 vibe 更好的 prompt」，是 vibe 之外的另一條路 ——把軟件工程那套真正起作用的紀律，重新裝回 AI 工作流 。
不過裝之前先說一句很現實的事：Superpowers 真的很燒 token 。
子代理隔離 = 每個任務都重載上下文； 兩階段審查 = 同一段代碼至少跑三次（實現 → Spec Review → Quality Review，不通過還要重做）； 強制 TDD = 多一倍的測試代碼生成。
一個簡單功能下來，token 消耗輕鬆是 vibe coding 的 5-10 倍 。在 token 計費越來越緊的當下，這個成本是要算清楚的。
實操建議很簡單：
公司報銷 / 團隊預算夠 ：放心裝，長期可維護性的回報遠大於 token 成本。 個人自費 ：先在小項目上試，跑過幾次再決定要不要在主力項目上鋪開。 vibe 已經能解決的場景 ：別硬上工程化，Superpowers 是給真正需要紀律的項目用的 。
工程化不是免費的午餐——質量提上去的同時賬單也跟着上去。想清楚再裝。
GitHub 地址：https://github.com/obra/superpowers
歡迎加入我的知識星球，全面提升技術能力。
👉 加入方式，“長按”或“掃描”下方二維碼噢：
星球的內容包括：項目實戰、面試招聘、源碼解析、學習路線。
文章有幫助的話，在看，轉發吧。
謝謝支持喲 (*^__^*）