最近這幾個月我?guī)缀趺刻於荚诤?Codex CLI 打交道但真正讓我從會用 AI 寫代碼變成敢把 AI 寫代碼當日常工作流的反倒是這個叫 superpowers 的項目。如果你也用過 Claude Code、Codex CLI 這類工具你大概率也遇到過同樣的問題它很聰明但像一個記性差、還總愛自作主張的實習生——你交代需求它一口氣給你吐幾百行代碼看著挺像回事一跑就發(fā)現(xiàn)要么漏了邊界條件要么根本沒按項目里的既有約定來。superpowers 解決的就是這個事。它不是一個新模型也不是一個 IDE 插件而是一套給 AI 編程代理加的技能增強層通過技能skills、工作流workflow、子代理subagent和記憶memory四個核心機制把資深工程師的工作習慣結構化地灌進 AI 的上下文里。支持接入 Codex CLI、Claude Code 等主流命令行編程工具。無論你是 Java、Python、前端還是全棧只要你愿意讓 AI 在動手前先思考、先規(guī)劃、再按紀律執(zhí)行這篇文章值得你花十分鐘讀完。1. superpowers到底解決了什么問題1.1 從代碼生成器到會工程的協(xié)作者先聊聊我自己的痛點。在接觸 superpowers 之前我對 Codex CLI 的使用方式非常簡單粗暴給它一個需求它直接生成實現(xiàn)。小型任務還行比如寫個工具函數(shù)解析這段 JSON但一旦遇到跨文件、多模塊的中型任務問題馬上暴露。印象最深的一次我讓它重構一個支付回調的處理方法它直接把整個類重寫了參數(shù)列表、異常處理、日志風格全都改了。功能確實跑通了但 code review 的時候同事直接炸毛這代碼風格跟整個項目根本不是一個路子。更麻煩的是它沒有留下任何重構說明我根本不知道它動了哪些調用方。這類問題的本質是什么是 AI 編程工具天然缺乏工程約束。它知道大量代碼但它不知道你這個項目的約定、不知道哪些模塊是敏感地帶、不知道先寫測試再寫實現(xiàn)這種基本流程。你指望靠提示詞把這一切說清楚每次會話都要重新說一遍而且說多了上下文就爆了。superpowers 的核心思路相當直白把這些工程紀律從你每次臨時輸入的提示詞變成AI 每次自動加載的文件和流程。它不追求讓 AI 更聰明而是讓 AI 按一個有經驗的人的方式工作。1.2 四個核心機制技能、工作流、子代理、記憶拆開看superpowers 的架構由四個概念組成技能Skill本質是一份結構化的 Markdown 文檔通常叫 SKILL.md。里面寫清楚這個技能解決什么問題、在什么場景觸發(fā)、執(zhí)行時遵循哪些步驟、有哪些紅線不能碰。AI 在會話中會根據描述自動判斷何時調用它。工作流Workflow多個技能的有序串聯(lián)。比如先規(guī)劃、再寫測試、再實現(xiàn)、最后審查就是一個工作流。它們被拆成模板AI 執(zhí)行時不會跳過中間環(huán)節(jié)。子代理Subagent獨立的、上下文隔離的小對話。比如你讓主 AI 開發(fā)功能同時派一個代碼審查子代理去看改動它的上下文只關注審查不會被主任務沖淡。這在大型任務里尤其好用。記憶Memory跨會話的項目狀態(tài)存儲。AI 會把重要決策、已知問題、未完成任務寫到 memory 文件里下次開新會話自動讀取。相當于給 AI 配了一個長期記憶庫不用每次從零開始。這四個機制組合起來就等于你給每個 AI 會話配備了一份崗位手冊 項目歷史檔案 工作流程模板。1.3 和多寫幾句提示詞的差別在哪有人可能覺得這不就是把提示詞換成文件嗎差別很大。提示詞是一次性的、碎片化的。你這次寫請先寫測試再寫實現(xiàn)AI 照做了下次你不寫它就忘了。而且提示詞很難承載復雜流程你很難用一段話讓 AI 同時記住先分析影響面、再定接口、寫測試、重構、跑 mvn test、審查 diff這一整套動作。技能文件則是持久的、經過驗證的。它不只是描述性文字還包含邊界條件和執(zhí)行紀律。比如一個代碼審查技能里會明確寫審查時不得修改代碼、必須按嚴重程度輸出問題清單、必須指出測試覆蓋盲區(qū)。這是普通提示詞很難做到的約束力。我給個更直白的類比提示詞像是你臨時口述的要求技能像是公司里沉淀下來的 SOP 文檔。口述的東西全靠對方記性和自覺SOP 文檔才是真正能穩(wěn)定復現(xiàn)工作質量的東西。2. 環(huán)境準備與安裝三大主流代理配置一次說清2.1 前置依賴到底需要什么superpowers 本身是一個開源項目理論上你只需要三個東西Node.js建議 18 以上安裝腳本和部分 CLI 工具依賴它Git用于從倉庫拉取代碼和后續(xù)更新你常用的 AI 編程 CLI 工具之一比如 Codex CLI、Claude Code我測試時用的是 Node 20、Codex CLI 的最新穩(wěn)定版和 Claude Code 1.x跑下來沒遇到兼容性問題。如果你本機還沒裝 Node先去官網下載 LTS 版本裝上這一步不用贅述。多說一句不要用 sudo 把 superpowers 裝到全局目錄。它本質是往你的用戶目錄寫配置和技能文件裝到全局反而容易出現(xiàn)權限混亂更新時還要反復輸密碼。老老實實裝在用戶目錄即可。2.2 拉取倉庫并執(zhí)行安裝我當時用的安裝方式大致是這樣git clone https://github.com/obra/superpowers.git cd superpowers npm install node bin/install.js安裝腳本跑完之后它會在你的用戶目錄下創(chuàng)建幾個關鍵路徑~/.superpowers/主目錄技能庫和配置都在這~/.superpowers/skills/所有技能的存放位置每個技能一個子目錄~/.superpowers/config.json全局配置決定哪些代理啟用了哪些技能不同版本路徑可能略有差異但大差不差。如果你在安裝時想自定義技能存放目錄可以在執(zhí)行腳本前設置環(huán)境變量指向自己的目錄我建議保持默認少折騰。2.3 接入 Codex CLIAGENTS.md 是那把鑰匙Codex CLI 本身有一套項目指令機制它會讀取當前工作目錄下的AGENTS.md文件把它作為項目級的系統(tǒng)提示。superpowers 接入 Codex 的關鍵就是把技能索引寫進這個文件。我當時的做法是在項目根目錄的AGENTS.md里加上這樣一段## Available Skills You have access to the following skills. Read the corresponding skill file before using them: - Planning: ~/.superpowers/skills/planning/SKILL.md - TDD: ~/.superpowers/skills/tdd/SKILL.md - Code Review: ~/.superpowers/skills/code-review/SKILL.md - Debugging: ~/.superpowers/skills/debugging/SKILL.md注意這里寫的是絕對路徑。如果你希望多個項目共用同一套技能可以把這個文件放在你的全局配置里如果你只想讓個別項目使用放在項目根目錄的 AGENTS.md 里最合適。2.4 接入 Claude Code插件配置方式如果你用的是 Claude Code接入方式類似但入口不同。Claude Code 支持在~/.claude/目錄下配置插件和技能引用。你可以在設置里聲明技能目錄或者在會話中通過/plugin命令導入。我目前同時接入了 Codex 和 Claude平時主力是 Codex遇到需要更長上下文、更復雜對話的任務會切到 Claude Code。兩邊讀的技能文件是同一套維護成本沒有增加。安裝完后怎么驗證最簡單的辦法開一個新會話直接問 AI你現(xiàn)在加載了哪些技能分別的作用是什么如果它能準確列出 planning、tdd、code-review 這些技能并且說清楚觸發(fā)條件說明接好了。如果它答不上來或者只說我沒看到任何技能文件那十有八九是路徑或文件名對不上回到上一步檢查。3. 別急著寫代碼superpowers 的核心使用姿勢3.1 用一句話觸發(fā)完整工作流工具裝好只是開始真正改變我使用習慣的是它先規(guī)劃后動手的工作方式。以前我遇到需求第一反應是直接甩給 AI實現(xiàn)一個 XX 功能?，F(xiàn)在我會說用 planning 工作流處理這個需求先分析影響面輸出 PLAN.md等我確認后再進入實現(xiàn)。這句話一出來AI 的行為模式立刻不一樣。它不會急著生成代碼而是先讀取相關模塊、梳理依賴關系、列出任務清單、標注風險點。我花兩分鐘看計劃確認方向沒問題再讓它進入下一步。這種模式本質上是在 AI 和你之間加了一道設計評審的關口。好處非常明顯大部分方向性錯誤在動手前就被攔截了而不是等代碼寫完了再推翻重來。3.2 常用技能清單什么時候該用哪個用了一段時間之后我結合自己的項目類型沉淀下來一張技能選擇表技能名稱典型觸發(fā)場景預期輸出planning需求較大、涉及多模塊改動PLAN.md含任務拆解、風險點、實施順序tdd新功能開發(fā)或 bug 修復先產出測試用例再寫實現(xiàn)code-review代碼提交前的自審按嚴重程度排列的問題清單debugging線上問題或疑難缺陷排查根因分析報告而非修改建議memory多會話長期項目更新的 MEMORY.md記錄決策與狀態(tài)選擇技能的時候我有個原則同一時間只掛載必要的技能不要全量加載。關于這點后面踩雷錄里會專門展開。3.3 記憶機制讓 AI 記住項目的前因后果記憶機制是我認為 superpowers 最被低估的功能。長期用 Codex 的人都有這種體驗新開一個會話AI 完全不記得昨天討論過的方案和踩過的坑所有上下文都要重新交代一遍。superpowers 的記憶機制改變了這一點。它會在每次會話結束時把關鍵信息寫入記憶文件本次做了什么決策為什么做這個決策哪些任務還沒完成下一步要做什么遇到了什么坑后續(xù)需要規(guī)避什么下次新會話開始時AI 自動讀取這些記憶直接進入狀態(tài)。我經常早上開工第一句就是加載昨天的記憶我們繼續(xù)那個支付模塊的重構。它真的能接上這種連續(xù)性是原生工具給不了的。3.4 手把手創(chuàng)建你自己的技能工具自帶的技能是通用的真正好用的是你自己沉淀的。我自己寫了個數(shù)據庫遷移檢查的技能每次讓 AI 改動數(shù)據庫相關代碼時自動觸發(fā)檢查有沒有給大表加索引、有沒有破壞已有外鍵關系、有沒有考慮數(shù)據回滾。創(chuàng)建步驟很簡單在~/.superpowers/skills/下新建目錄比如db-migration-check/目錄里新建SKILL.md文件文件用 frontmatter 格式聲明技能信息正文寫執(zhí)行步驟和檢查清單一個最小示例--- name: db-migration-check description: 審查所有涉及數(shù)據庫結構變更的改動在提交前調用。重點關注索引、外鍵、回滾。 when_to_use: 當 diff 中包含 migration 文件、DDL 語句或 ORM 實體變更時 --- ## 執(zhí)行步驟 1. 提取本次改動涉及的表和字段 2. 檢查變更是否需要新增索引評估現(xiàn)有數(shù)據量 3. 檢查外鍵關聯(lián)是否被破壞 4. 確認回滾腳本存在且可執(zhí)行 5. 輸出審查結論包括風險和修改建議 ## 紅線 - 禁止直接在生產環(huán)境執(zhí)行任何 DDL - 禁止在未評估數(shù)據量的情況下建議加鎖寫完這個文件后AI 會在遇到數(shù)據庫變更時自動讀取并執(zhí)行檢查。關鍵在description字段寫得越具體AI 越容易判斷什么時候該用這個技能。4. 當技能遇上 Java一次真實的重構復盤4.1 為什么 Java 項目特別吃這套Java 項目大概是所有語言里潛規(guī)則最多的那一類Maven 還是 Gradle、Lombok 用不用、Controller 層應該多薄、異常是拋還是吞、Checkstyle 規(guī)則怎么配。這些約定很少寫進文檔全靠團隊口頭傳承。原生 AI 寫 Java 代碼功能對但風格經常和團隊不一致review 成本極高。superpowers 的切入點正好卡在這。你可以把團隊所有的編碼規(guī)范寫成一個Java 編碼約束技能AI 每次生成代碼前自動加載。它的代碼風格會穩(wěn)定很多因為約束不再靠運氣而是每次都在上下文中。4.2 一次 Spring Boot 支付模塊的重構全過程我拿最近一次實踐做例子。項目是一個 Spring Boot 的支付服務核心的OrderService類膨脹到了 1200 多行里面塞了支付寶、微信、銀行卡三種支付渠道的 switch-case 邏輯。三個渠道邏輯互相糾纏只要改一處另外兩處就可能壞。沒人敢動。我當時的操作分四步第一步讓 AI 用 code-review 技能分析現(xiàn)狀。它輸出的問題清單有 6 類包括switch-case 分支過多、渠道參數(shù)校驗缺失、重復的訂單狀態(tài)流轉代碼、異常處理不統(tǒng)一、測試覆蓋嚴重不足、類職責混亂。這個清單基本和團隊一致。第二步執(zhí)行 planning 技能拆出重構階段設計渠道策略接口、編寫現(xiàn)有行為的特征測試、分渠道實現(xiàn)策略類、最后回歸。計劃產出后我確認了優(yōu)先級。第三步按 tdd 技能進入實現(xiàn)。先為三個渠道分別寫測試用例邊界情況包括退款、部分退款、金額不一致。這些測試把現(xiàn)有功能不能改壞這個底線鎖死。第四步改造完成后跑 code-review 復查 diff。結果OrderService從 1200 行降到 400 行左右三個支付渠道變成獨立的策略類舊測試全部通過新增了 20 多個特征測試。整個過程大約用了一個工作日換作以前純人工來動這塊代碼沒兩三天我不敢讓人上。4.3 Java 團隊可以復用的技能組合基于這次經驗我給 Java 團隊一個可以直接抄的技能組合建議觸發(fā)順序很重要planning先拆任務定義接口和改動邊界Java 約束檢查加載團隊規(guī)范確保生成代碼風格統(tǒng)一tdd先寫測試鎖定行為實現(xiàn)與重構只允許改動與本次任務相關的代碼code-review以審查子代理身份自查 diff這個順序的核心邏輯是先定邊界再動手比讓 AI 一口氣寫完重要得多。順序反了AI 很容易陷入邊寫邊改邊推翻的無序狀態(tài)。4.4 省時間的真相性價比體現(xiàn)在返工減少說到收益量化我做一個不算嚴謹?shù)苤庇^的對比任務類型純人工原生 AI 直寫AI superpowers簡單功能 100 行半天1-2 小時1-2 小時中型重構500-1000 行2-3 天1 天但 review 要額外半天半天review 通過率高跨模塊改造4-5 天2 天方向容易跑偏1 天我最真實的感受AI superpowers 在簡單任務上并不比原生 AI 快多少但中型以上任務省下的不是寫代碼時間而是返工和 review 時間。方向對了代碼風格對了測試兜住了后面所有環(huán)節(jié)都順了。5. 踩雷錄新手最容易翻車的五個地方5.1 裝了跟沒裝一樣技能加載不上這是反饋最多的問題我自己也踩過。癥狀是明明在技能目錄里看到了文件AI 會話里卻完全無感該直接寫代碼還是直接寫。排查鏈路按這個順序來檢查 AGENTS.md 里的路徑是否真實存在~是否被正確展開檢查文件名是否和引用一致——注意大小寫SKILL.md和skill.md在某些文件系統(tǒng)下是不同的確認文件編碼是 UTF-8不要有 BOM 頭新開會話再試因為技能是在會話啟動時加載的中途改文件不會熱更新95% 的情況是路徑寫錯或者文件名不匹配剩下的就是忘了開新會話。5.2 技能掛載太多AI 反而變笨了這是另一個極端。有人覺得技能越多越好把十幾份 SKILL.md 全寫進配置。結果 AI 的上下文被技能說明占掉一大塊真正留給業(yè)務代碼的空間就變小了而且技能之間還會互相打架。一個典型表現(xiàn)AI 同時看到代碼審查技能和重構技能搞不清楚當前該走哪個流程輸出變得猶豫不決。我的建議是常駐 3-5 個核心技能其余技能通過按需觸發(fā)來調用也就是在對話中需要時再讓 AI 讀取對應文件而不是一開始全塞進去。5.3 記憶文件越寫越長AI 在故紙堆里打轉記憶機制用久了會面臨一個新問題文件里堆了幾百條歷史記錄AI 每次加載時都要讀一遍反而降低了響應質量和速度。我的解決辦法是給記憶文件做結構化分層MEMORY.md索引層只保留當前最重要的決策和狀態(tài)一兩屏能讀完memory/archive/歸檔層按周或按月歸檔的歷史記錄不被 AI 主動加載需要時再查每周末花十分鐘整理一次記憶文件把不再相關的記錄歸檔。這樣 AI 的記憶永遠是清爽的不會變成一團亂麻。5.4 過度造技能維護成本反超收益我見過最離譜的是有人給寫一個簡單的 REST 接口都專門造了個技能。技能確實能造但每造一個都要維護內容過時了還可能誤導 AI。我給自己立了個標準同一個問題被連續(xù)卡住三次以上才值得為此寫一個技能。一次兩次偶發(fā)的問題直接在對話里說清楚就好。技能是要跟隨你很久的資產寧缺毋濫。5.5 權限和子代理邊界別讓 AI 自己審自己最后一個坑是關于子代理的權限問題。我早期配置子代理時給它終端執(zhí)行權限然后讓它同時負責寫代碼和審查。結果等于讓運動員當裁判審查流于形式什么問題都沒發(fā)現(xiàn)。正確做法是把角色和權限分開寫代碼的主代理擁有文件寫入和執(zhí)行權限審查子代理只讀代碼、跑測試、輸出報告不允許修改文件。這個邊界一旦模糊審查環(huán)節(jié)就形同虛設。6. 最后分享幾個我自己的小習慣文章到這里核心內容基本都講完了。最后說幾個我實際操作中沉淀下來的小習慣不一定適合所有人但可以參考每天早上開工我第一句永遠是讓 AI 加載項目記憶然后走一遍 planning 流程把當天要做的改動整理成計劃再動手。新項目初始化時我會先讓 AI 用 planning 技能生成一份 PLAN.md結合項目結構和團隊規(guī)范確認后再開始寫代碼。每個季度我會 review 一遍技能列表刪掉超過一個月沒用過的技能保持技能庫的新陳代謝。還有一個收益最大的習慣把整個 superpowers 配置和技能文件提交到團隊 Git 倉庫里。新人入職 clone 項目后內置的 AGENTS.md 和技能文件會自動生效團隊所有成員等于共用一份持續(xù)更新的AI 工作手冊。說到底superpowers 沒有讓 AI 變得更聰明它只是讓 AI 用上了更有紀律的工作方式。我自己的體會是換模型帶來的提升是線性的而改變工作流帶來的提升是復利式的。只要你肯花一點時間建立自己的技能庫這筆投入會一直滾下去。