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