最近在AI編程社區(qū)里“superpowers”這個關(guān)鍵詞出現(xiàn)的頻率高得嚇人。隔三差五就有人問superpowers具體怎么使用它到底有那些skills怎么把這些技能引入到我正在用的編輯器還有不少人直接說“想要安裝superpowers”結(jié)果搜到的全是英文倉庫頁面不知道從哪下手。我一開始也以為這是什么新出的IDE或者某個模型的名字后來把GitHub上最流行的那套superpowers技能包實際跑了幾周才搞明白它和普通提示詞、普通插件的本質(zhì)區(qū)別。這篇文章不玩概念就按我實測的經(jīng)歷來聊它到底是什么、里面有哪些核心skills、怎么裝、裝完怎么用、以及我踩過的坑。如果你正在用Cline、Claude Code這類支持Agent Skills機制的AI編程工具這篇文章應(yīng)該能幫你在半小時內(nèi)跑通整套流程。1. 這個被叫做superpowers的東西到底是什么1.1 先分清它不是模型也不是一套普通提示詞很多人第一反應(yīng)是“superpowers是不是一個更強的模型或者一套寫好的prompt”我第一次看到這個名字時也是這么猜的甚至在項目里直接把一整段提示詞粘給AI用結(jié)果發(fā)現(xiàn)根本不對。superpowers本質(zhì)上是一組按需加載的Markdown技能文件組成的技能包專門為支持Agent Skills機制的AI編程工具設(shè)計。所謂技能不是每次對話都塞進上下文的長篇指令而是一個個獨立、結(jié)構(gòu)化的“工作劇本”。每個技能文件里包含兩大部分前面是元信息技能名稱、用途、什么時候適合觸發(fā)后面是具體的操作流程和驗證標準。AI編程工具會先掃描所有技能的名稱和描述等用戶提出請求時再決定是否調(diào)用某個技能、把這個技能的具體內(nèi)容臨時加載進來。你可以把它理解成給AI配置了一整套“崗位手冊”不是讓它把所有手冊背下來而是什么崗位干什么活時翻開對應(yīng)那一本。這個設(shè)計最大的好處是節(jié)省上下文窗口同時讓流程非常穩(wěn)定——不會因為用戶多說了幾句話AI就跑偏去做和任務(wù)無關(guān)的事。我實際用下來最貼切的比喻是普通提示詞是“告訴AI你要什么”而superpowers是“教會AI怎么一步步把你要的東西做出來”。它把軟件開發(fā)里的經(jīng)典流程——先思考、再計劃、再編碼、再測試、再審查——變成了AI肌肉記憶的一部分。1.2 核心機制Markdown文件就是技能本體我能看到不少人在問“怎么引入這些技能”其實關(guān)鍵點就在這里superpowers的技能不是一個需要編譯的插件也不是一段只能在某個軟件里運行的腳本它就是一整套帶有約定結(jié)構(gòu)的Markdown文件。拿一個典型的技能文件舉例。每個技能文件的大致結(jié)構(gòu)是這樣頂部是YAML格式的元信息聲明技能名稱、描述、適用場景正文是分段式指令告訴AI執(zhí)行該技能時應(yīng)該按什么順序做什么事、每步完成的標準是什么正文里還可以包含示例對話、參考資料、甚至給AI預(yù)寫的思考路徑。你甚至可以直接用文本編輯器打開技能文件像改文檔一樣改掉里面的流程AI下次執(zhí)行時就會按你改過的新流程走。這是它和封閉式插件最大的區(qū)別——技能是可讀、可改、可定制的這也是我后來敢把它引入到團隊項目里的原因。1.3 目前主流支持哪些AI編碼工具從我實測和社區(qū)反饋來看這套技能包目前最活躍的使用場景是Cline支持從GitHub直接導(dǎo)入技能倉庫界面里有專門的入口屬于最省事的路徑Claude Code本身支持Agent Skills機制社區(qū)里有大量集成superpowers的示例通過目錄掛載或插件市場方式都能引入其他兼容Agent Skills的工具如Windsurf、Cursor等前提是它們能識別.claude/skills這樣的目錄結(jié)構(gòu)并讀取技能元信息。如果你平時主要用Cline那安裝流程會順暢很多如果你用Claude Code也完全可行只是配置方式稍微手動一點。下面我會把幾條路徑都寫清楚。2. 拆解superpowers的核心skills每份技能在解決什么問題2.1 從想法到計劃brainstorming和writing-plans如果只讓我推薦兩個技能我會先說這兩個。因為AI編程最大的問題不是寫代碼而是在代碼之前想清楚要做什么。沒有任務(wù)拆解就動手的AI會在需求半模糊的情況下直接生成一大堆自認為合理的文件結(jié)果往往離題萬里。brainstorming頭腦風(fēng)暴技能解決的正是需求模糊期的問題。觸發(fā)它之后AI不會急著寫代碼而是按“發(fā)散—收斂—決策”三步走先基于當(dāng)前需求列出盡可能多的方案哪怕是看似離譜的方案也會保留然后逐個方案評估折中方案比如改動量、風(fēng)險、對現(xiàn)有代碼的影響最后挑選一個方向給出明確理由。我印象最深的一次是讓它給一個內(nèi)部工具加權(quán)限校驗結(jié)果它先列出了四種權(quán)限模型比較完才動手最后選的那一套比我自己腦子里想的方案要穩(wěn)得多。writing-plans編寫計劃技能則負責(zé)把選定的方案變成可執(zhí)行的施工圖。AI會產(chǎn)出一份計劃文檔里面寫清楚本需求涉及哪些文件新增、修改、刪除各是什么每一步操作的先后順序每步完成時怎么驗證比如運行什么命令、檢查什么輸出;哪些地方有風(fēng)險需要額外關(guān)注。這份文檔不只是給AI看的你作為開發(fā)者也可以直接審閱。計劃寫得好不好直接決定后面整段開發(fā)過程的質(zhì)量。我現(xiàn)在的習(xí)慣是讓AI先跑writing-plans我自己看完計劃沒問題了再讓它開工。2.2 編碼執(zhí)行階段executing-plans、TDD和debugging需求理清楚、計劃寫完接下來才是真正的編碼環(huán)節(jié)。executing-plans執(zhí)行計劃技能是“施工隊長”。它不重新發(fā)明方案而是一步步執(zhí)行之前計劃文檔里寫好的動作每完成一個步驟就停下來自查一次確認這一步和計劃的預(yù)期一致再進入下一步。一旦執(zhí)行過程中發(fā)現(xiàn)計劃有遺漏或者和實際情況不符它會主動回頭修改計劃而不是默默繞開繼續(xù)寫。這個行為習(xí)慣特別像老手程序員發(fā)現(xiàn)問題先停下來對齊而不是悶頭硬寫。TDD測試驅(qū)動開發(fā)技能是我個人最喜歡的一個。它的工作流程非常嚴格先寫一個會失敗的測試跑一遍確認它紅了再寫最小代碼讓測試通過跑一遍確認綠燈最后考慮是否重構(gòu)但重構(gòu)的前提是測試依然通過。整個節(jié)奏是紅—綠—重構(gòu)的循環(huán)。我早期用AI寫代碼的時候經(jīng)常遇到“功能看起來對了一改就崩”的情況。引入TDD技能之后AI會先守住測試防線再往上加代碼。改動范圍風(fēng)險高的時候我會刻意在需求描述里強調(diào)“先寫測試”這樣它就會自動切換到TDD流程。debugging調(diào)試技能則是發(fā)生錯誤時的排障手冊。它不會一上來就猜原因而是要求AI先通讀完整報錯信息和堆棧列出可能的疑點然后用二分法逐步縮小范圍先確認問題在哪個模塊再定位到哪個文件、哪個函數(shù)最后給出修復(fù)建議時還會附上驗證手段。相比普通模式下一味地改代碼碰運氣這個流程能省下大量來回試錯的次數(shù)。2.3 收尾與質(zhì)量保障refactoring、code-review和finishing-work代碼寫完了技能包的工作還沒完。后面這三個技能負責(zé)把“能跑的代碼”打磨成“能交差的代碼”。refactoring重構(gòu)技能的約束是行為不能變。它要求AI在重構(gòu)前先確認有測試覆蓋然后小步修改、頻繁驗證而不是一次性翻天覆地。每次重構(gòu)建議只會做一類改動比如只提取函數(shù)、只消除重復(fù)、只優(yōu)化命名。我經(jīng)驗里這類技能最防“順手把邏輯也改了”的情況。code-review代碼審查技能做的是提交前的最后一道質(zhì)檢。它會像真人評審一樣審視diff重點關(guān)注有沒有安全隱患、有沒有明顯設(shè)計缺陷、有沒有邊界情況沒處理、改動范圍是否超出需求。審查結(jié)果按嚴重程度分類輸出而不是籠統(tǒng)一句“看起來不錯”。finishing-work收尾工作技能則把整個任務(wù)閉環(huán)補充遺漏的文檔、檢查變更文件是否都符合預(yù)期、生成清晰的提交信息、甚至整理下一步建議。它的價值在于讓AI不留下“爛尾工程”——很多AI生成代碼項目最后難以維護不是代碼寫得差而是文檔缺失、提交信息混亂。我把這套技能的大致結(jié)構(gòu)整理成了一張表方便你對照技能名稱觸發(fā)時機核心作用brainstorming需求模糊、方案未定發(fā)散方案、評估取舍、確定方向writing-plans動手編碼之前輸出包含文件、步驟、驗證方式的計劃文檔executing-plans進入編碼階段按計劃逐步執(zhí)行異常時回改計劃TDD新增功能或修改邏輯先寫失敗測試再實現(xiàn)再重構(gòu)debugging出現(xiàn)報錯或行為異常二分定位、假設(shè)驗證、結(jié)論輸出refactoring代碼質(zhì)量不達標行為不變前提下小步優(yōu)化code-review準備提交之前從安全、設(shè)計、風(fēng)險角度審查difffinishing-work任務(wù)收尾補文檔、整理變更、生成提交信息3. 安裝與引入三種主流接入方式實測記錄3.1 方式一通過Cline界面直接導(dǎo)入倉庫如果你用的是Cline這是我最推薦的第一步。具體操作是這樣打開Cline的設(shè)置頁面找到Skills相關(guān)面板找到“從GitHub安裝技能”或類似的導(dǎo)入入口粘貼技能倉庫地址也就是superpowers項目對應(yīng)的GitHub URL點確認Cline會自動拉取倉庫里的技能文件并把它們寫入本地技能目錄。整個過程差不多一分鐘就能完成不需要手動clone也不需要改目錄結(jié)構(gòu)。Cline會把倉庫中符合技能格式的文件自動識別出來之后你在對話里就能看到這些技能出現(xiàn)在可用列表里。這里有個小提醒倉庫如果發(fā)生過改名或者目錄結(jié)構(gòu)大改舊版本的導(dǎo)入邏輯可能失效。如果你是在網(wǎng)上看到的帖子最好先確認帖子里的導(dǎo)入方式和倉庫地址是否還是最新的。3.2 方式二Git clone后手動放置技能目錄如果不用Cline或者你想更清楚地掌握每個技能文件具體放在哪用Git clone是最直觀的方式。操作步驟是git clone https://github.com/obra/superpowers.git cd superpowers ls -laclone下來之后你會看到倉庫里有一個明顯的skills目錄里面就是所有技能文件。接下來只需要按你的工具要求把這個目錄里的內(nèi)容復(fù)制或軟鏈接到對應(yīng)的技能路徑。以Claude Code為例最常見的位置是項目內(nèi)的.claude/skills/或者用戶級別的~/.claude/skills/。把技能文件放進去之后重啟編輯器會話新的技能就會被掃描到。為什么我強調(diào)“手動放置也值得學(xué)”因為這種方式不受工具界面限制你想試一個技能就復(fù)制一個不想要的技能可以不放靈活性極高。而且一旦技能文件在本地你隨時可以直接打開修改內(nèi)容這是界面導(dǎo)入不太方便做的事情。3.3 方式三在Claude Code中通過插件市場方式掛載Claude Code的場景稍微特殊一點。它本身有插件市場機制也有人把superpowers打包成符合規(guī)范的插件倉庫通過市場方式引入。這個過程會涉及添加插件市場地址、安裝插件、授權(quán)等環(huán)節(jié)。我自己實際跑通的路徑其實更樸素直接clone倉庫然后把skills目錄軟鏈接到Claude Code的skills目錄。命令大致是這樣ln -s /path/to/superpowers/skills ~/.claude/skills軟鏈接的好處是以后你更新superpowers倉庫時技能內(nèi)容會自動跟著更新不用重復(fù)復(fù)制。軟鏈接方式不算官方文檔里最推薦的做法但我實測可用而且對想頻繁改動技能文件的場景特別友好。需要注意的是Claude Code不同版本對技能目錄的掃描規(guī)則可能有差異。我升級過一次版本之后發(fā)現(xiàn)舊技能的description沒有被識別重新檢查目錄結(jié)構(gòu)和frontmatter格式才恢復(fù)。所以如果你裝完發(fā)現(xiàn)技能沒生效先別懷疑操作錯了大概率是格式或目錄位置不符合當(dāng)前版本的約定。4. 引入之后代理是怎么把技能用起來的4.1 技能觸發(fā)邏輯不是所有對話都會調(diào)技能很多人裝上superpowers之后最疑惑的一點是為什么我明明裝了技能但AI沒有按技能里的流程走這里要理解觸發(fā)邏輯。AI編程工具不會把所有技能常駐在上下文里而是先讀取每個技能文件的name和description形成一個技能索引。你在對話里提出需求時工具會判斷你的請求符不符合某個技能描述中的場景符合才把技能正文加載進來。舉個例子你說“幫我把這個字符串改成大寫”這種簡單且明確的操作一般不會觸發(fā)任何復(fù)雜技能AI直接改完就結(jié)束。但如果你說“我想給列表頁加一個篩選功能但不確定用哪種方案合適”這句話里包含了“方案不確定”的信號就可能觸發(fā)brainstorming和writing-plans。所以想讓AI使用技能你需要讓需求描述里帶上技能觸發(fā)條件的關(guān)鍵詞。想要走TDD就明說“先寫測試”想要做計劃就說“先出個實施計劃”想要審查就直接說“幫我code review一下這些改動”。這不是玄學(xué)而是技能索引匹配機制的自然結(jié)果。4.2 一個真實任務(wù)跑下來的完整鏈路為了讓你看明白整個流程我描述一次我實際跑過的任務(wù)給一個內(nèi)部后臺管理系統(tǒng)加一個“按日期范圍篩選訂單”的功能。需求發(fā)出去后AI先是進入brainstorming狀態(tài)列出兩種方案一種是在后端SQL里過濾另一種是在前端拉全量數(shù)據(jù)再過濾。它分析了后端方案的優(yōu)勢——數(shù)據(jù)量大的情況下性能更穩(wěn)定也評估了前端方案實現(xiàn)起來更快最終選擇了后端參數(shù)化查詢方案理由是現(xiàn)有接口已經(jīng)支持日期參數(shù)改動面最小。緊接著writing-plans被觸發(fā)AI產(chǎn)出一份計劃文檔把要改的文件列了出來訂單查詢接口的service層、DTO里的篩選字段、前端列表頁的篩選表單。每一步都有驗證標準比如“修改service后運行已有訂單相關(guān)測試確保舊功能不受影響”。編碼階段executing-plans按文檔順序推進每完成一個文件都自行檢查是否和計劃一致。當(dāng)我看到它準備寫SQL片段時我插了一句“先給這個查詢寫測試”于是TDD技能接管先寫了一個覆蓋日期篩選邏輯的單元測試故意讓它跑紅再補實現(xiàn)代碼跑綠然后做了一次簡單的條件提取重構(gòu)。中途其實踩到一個坑前端傳過來的日期格式是YYYY-MM-DD而后端存儲的時間字段帶有時分秒直接比對總是差一天。這時候debugging技能被觸發(fā)AI先讀了接口日志定位到參數(shù)轉(zhuǎn)換那一段用二分法確認是時間邊界問題最后給出修改方案——把日期字符串轉(zhuǎn)成當(dāng)天的起止時間區(qū)間而不是直接等值比較。收尾時code-review技能對全部diff過了一遍指出一個潛在問題篩選條件沒做空值判斷可能導(dǎo)致SQL異常。它據(jù)此補了一段邏輯。最后finishing-work技能補了接口文檔、更新了頁面說明、生成了一條結(jié)構(gòu)清晰的提交信息。整個過程下來我基本只做了兩件事一是開頭把需求描述清楚二是在中途插了一句“先寫測試”。剩下的拆解、編碼、驗證、收尾全是技能按部就班完成的。這種體驗和普通模式下“AI直接甩一大段代碼”是完全不同的——它更像是在和一個思路清晰的后端同事合作。4.3 哪些情況技能不會被觸發(fā)反過來我也遇到過不少技能“裝死”的場面。主要有這么幾種需求描述里沒有明確的信號詞AI識別不到適用場景就只會走普通對話流程需求太瑣碎比如改個文案、調(diào)個顏色技能本身也沒有匹配的場景描述自然不會觸發(fā)當(dāng)前模型推理能力較弱或工具版本較舊對技能文件的解析不完整導(dǎo)致加載失敗技能文件本身格式有問題比如description過于含糊工具無法判斷何時該用。如果你發(fā)現(xiàn)技能沒觸發(fā)先把需求描述寫詳細是關(guān)鍵。描述得越像“場景說明書”技能越容易被喚醒。5. 我踩過的坑和實際優(yōu)化建議5.1 全量導(dǎo)入技能上下文開銷反而變大第一次裝superpowers時我也很興奮一口氣把倉庫里所有技能全放進去了。結(jié)果發(fā)現(xiàn)雖然技能是“按需加載”的但工具在會話開始時仍然要掃描并維護技能索引列表。技能數(shù)量過多時這個索引本身就會占用不少上下文窗口有時候甚至還沒來得及用技能前面的可用token就被占掉一截。后來我的做法是只保留當(dāng)前階段最需要的幾個技能。日常開發(fā)常用的是brainstorming、writing-plans、executing-plans、TDD、debugging、code-review需要項目收尾時再把finishing-work加回來。其他不常用的技能直接移出目錄需要時再放回。這一改上下文明顯寬松了很多。5.2 技能默認流程和自己團隊的規(guī)范沖突怎么辦superpowers里的流程是通用最佳實踐但每個團隊有自己的約定。比如它的finishing-work技能默認生成的提交信息格式和我們團隊用的PR模板就是兩套風(fēng)格code-review技能關(guān)注點偏安全和高風(fēng)險而我們團隊更看重業(yè)務(wù)邏輯完備性。好在技能是可讀的Markdown文件我沒有去適應(yīng)它而是直接改了文件內(nèi)容。把提交信息格式改成自己團隊的模板把code-review的檢查清單里加上業(yè)務(wù)字段校驗項。改完重啟會話后AI執(zhí)行的就是我改過的流程。這個定制能力是我認為superpowers最值得安利的地方——它把AI的工作習(xí)慣變成了你可以維護的文檔。5.3 別讓環(huán)境權(quán)限卡住技能流程另一個我踩過的坑和技能本身無關(guān)但影響巨大TDD技能要求AI能運行測試命令debugging技能要求AI能執(zhí)行調(diào)試命令。如果AI工具沒有命令行執(zhí)行權(quán)限或者項目環(huán)境里測試命令本身是壞的技能會卡在第一環(huán)。我一度以為是TDD技能寫得有問題后來發(fā)現(xiàn)是項目里測試腳本缺依賴跑起來就報錯。修復(fù)環(huán)境之后整個流程立刻順了。所以裝技能之前先確認你的AI工具能正常跑測試命令和構(gòu)建命令否則后面全是折騰。5.4 自己動手新增一個技能其實很簡單如果你用了一段時間覺得現(xiàn)有技能不夠用完全可以自己寫一個新技能。技能文件不需要任何編程基礎(chǔ)只要按約定格式寫Markdown就行。我給你看一個最簡示例--- name: commit-and-changelog description: 當(dāng)用戶要求生成提交信息或更新changelog時使用。 --- 1. 讀取當(dāng)前git diff內(nèi)容 2. 按團隊模板生成提交信息 3. 如有版本變更同時更新changelog文件。把這段內(nèi)容保存成一個.md文件放到技能目錄里重啟會話之后工具就能識別它。描述寫得越準確AI觸發(fā)它的概率就越高。我記得自己第一次寫完自建技能看到它生效時感覺這套東西真的像個“工具箱”——你想要什么工具放進去就能用。至于網(wǎng)上總有人問“想要安裝superpowers”我個人建議是別一上來就追求裝全裝新。先把Cline或Claude Code跑通一套基礎(chǔ)流程用一個真實的小需求走一遍“brainstorm → writing-plans → TDD → debugging → code-review”感受一下節(jié)奏再決定要保留哪些技能、裁剪哪些技能。技能這個東西多了不一定是好事能讓AI穩(wěn)定地把事情做完整比什么都強。