用 AI 編程助手寫代碼最大的感受是什么不是它太強了而是它強得不太穩(wěn)定。同一個需求狀態(tài)好時三分鐘給你寫完整套邏輯狀態(tài)不好時能在一個命名不規(guī)范的小函數上反復打轉。我花了不少時間研究怎么馴服這種不確定性最后發(fā)現關鍵不在模型本身而在你有沒有給 AI 一套可復用的技能體系。Superpowers 就是干這個的。它不是某個具體函數也不是普通的提示詞模板而是一組被封裝成 skills 的最佳實踐集合能讓 AI 像有經驗的老手一樣先計劃、再動手、后測試、最后復盤。如果你也想給 AI 編程助手裝上這種超能力并且正在找安裝方法和技能清單這篇文章就是為你準備的。1. Superpowers 是什么先搞懂它解決什么問題1.1 一個痛點AI 很強但發(fā)揮不穩(wěn)定用 AI 編程助手的人估摸都有過這種體驗讓它做一件邊界清晰的單點任務比如寫一個排序算法、配一個構建腳本它通常干得很利索?？梢坏┤蝿兆兂砂堰@兩個模塊解耦再把公共邏輯抽出來它就開始天馬行空了。有時候它會給你一套看似合理但根本跑不通的方案有時候又會把明明能用的代碼改出一堆新 bug。為什么因為模型本質是在做模式補全。它看到上下文里有相似場景就會照著訓練數據里的模式輸出但它缺少一個穩(wěn)定的工作流來約束自己。人寫代碼是有肌肉記憶的先想方案、再動手、寫完自測、讓同事 review。AI 沒有這個肌肉記憶除非你把這些習慣顯式地塞給它。Superpowers 解決的問題恰恰就在這里。它通過一套預制的技能包把 AI 從裸奔狀態(tài)拉回受控狀態(tài)。用打游戲來類比模型本身就是一個擁有滿級屬性的角色但如果你不給它技能欄它只會平砍Superpowers 就是那個技能欄裝上哪個技能AI 才會用哪個招數。1.2 把最佳實踐變成可加載的 skills先解釋一個基礎概念在 Claude Code 這類 AI 編程助手的體系里skill 就是一個文件夾里面放一個SKILL.md文件。這個文件開頭有一段 YAML 格式的元信息寫清楚技能的名字、用途、觸發(fā)條件正文部分則是具體的執(zhí)行步驟和注意事項。模型在會話中遇到匹配的任務時會去讀取這個文件然后按照里面的指令來行動。Superpowers 就是一整套這樣的技能集合而且它不是零散的小技巧而是把軟件開發(fā)里最常用的一整個流程全部封裝成了標準 skills。從動手前的計劃拆解到寫代碼時的實施約束再到寫完以后的測試、代碼審查、故障復盤都有對應的技能。你可以把它理解成給 AI 配了一位實戰(zhàn)經驗豐富的技術總監(jiān)。這位總監(jiān)未必比模型聰明但他知道什么時候該剎車、什么時候該加油知道每個階段應該產出什么從而讓整個開發(fā)過程變得可預期。1.3 這套體系適合誰用個人開發(fā)者是最受益的群體。一個人維護整個項目時沒人幫你做代碼審查也沒人逼你寫測試AI 又容易放飛自我這時一套強制流程就能發(fā)揮奇效。小團隊也合適特別是沒有專職 QA 的團隊讓 AI 按流程補測試、做 review能省下大量人工輪巡的時間。剛接觸 AI 編程的新手更應該用與其被 AI 的幻覺帶進溝里不如一開始就讓它走固定流程至少能建立先想再做的潛意識。不過也得說句實話如果你的項目處于強監(jiān)管行業(yè)或者公司對 AI 輸出有嚴格的合規(guī)要求那么開源社區(qū)的技能包只能做參考你必須基于它做內部定制。Superpowers 的核心價值是把成熟流程固化給 AI而不是讓 AI 替你承擔決策責任。這一點擺清楚后面用起來就不會有預期偏差。2. 安裝前準備環(huán)境與版本選擇2.1 核心依賴先裝好 Claude Code要跑 Superpowers首先得有一個能識別 skills 的 AI 編程助手。目前我用得比較多的是 Claude Code。它是 Anthropic 官方出的命令行編程工具裝在本地終端里可以直接讀寫你項目里的文件。安裝前提是環(huán)境里已經有 Node.js 18 以上版本然后一條命令就能裝完npm install -g anthropic-ai/claude-code裝完以后跑一下版本號確認claude --version能正常打印出版本號就說明安裝成功了。這里有幾個容易踩的坑。第一如果 npm 源很慢建議先換成國內鏡像我這邊直接用 npmmirror 體驗會好很多。第二如果你之前裝過舊版本升級的時候最好加--force參數避免緩存沖突導致命令失效。第三Claude Code 的很多能力需要登錄賬號才能使用裝完以后先跑一次claude按提示完成登錄別等到用的時候才發(fā)現沒登錄。2.2 獲取 Superpowers 的渠道Superpowers 不像一個獨立 App更像一個技能包。獲取渠道主要有三種項目官方的 GitHub 倉庫、npm 上的發(fā)布包、以及社區(qū)整理的鏡像。這里必須多說一句。你在 GitHub 上搜 superpowers skills會看到不少同名但來源不明的倉庫這個現象在熱門項目身上很常見。我強烈建議只從項目主頁上給出的官方倉庫地址拉取不要圖省事用第三方二次打包的版本。技能包本質上是一堆可執(zhí)行指令和提示詞腳本如果作者在某個 SKILL.md 里夾帶私貨讓模型在特定場景下執(zhí)行額外命令你會發(fā)現起來非常困難。我之前就見過有人把安裝命令改成遠程腳本結果裝完以后多了好幾個無關依賴排查了半天才發(fā)現不對勁。2.3 安裝后的目錄結構長什么樣裝好以后你會看到類似下面的目錄結構.claude/ └── skills/ ├── plan/ │ ├── SKILL.md │ └── scripts/ ├── implement/ │ ├── SKILL.md │ └── ... ├── debug/ ├── review/ └── ...每個技能一個目錄目錄里至少有一個SKILL.md。模型就是靠這個文件里的描述來判斷這個任務該不該用它。如果是全局安裝技能目錄一般放在用戶目錄下的~/.claude/skills/這樣你在任何項目里都能用如果只想在某個項目里生效就把它放在項目根目錄的.claude/skills/下。前者適合個人常用技能后者適合和項目強相關的專用技能。3. 安裝與引入實操兩種方式一步步來3.1 方式一一鍵腳本安裝最簡單的安裝方式是執(zhí)行項目提供的安裝腳本。以官方 README 里的典型方式為例大概長這樣curl -fsSL https://install.superpowers.dev/install.sh | bash不過這里我得多啰嗦一句執(zhí)行這類管道安裝腳本之前一定先下載下來看一眼內容。不是開玩笑很多安全問題的根源就是用戶跑了一行自己完全不了解的curl | bash。安裝腳本做的事情大致是檢查 Claude Code 是否存在、把技能倉庫克隆到 skills 目錄、最后給你打印一份使用說明。跑完以后不要急著進項目先確認腳本到底把它裝到哪個目錄了。有些安裝腳本默認裝到全局目錄結果你在項目里怎么調都看不到。反過來也有只裝到當前項目目錄的情況你換個項目又得重新裝。3.2 方式二手動克隆引入我更推薦手動克隆。雖然多敲幾條命令但每一步都清清楚楚出了問題也容易排查cd ~/my-project mkdir -p .claude/skills git clone https://github.com/[官方倉庫地址]/superpowers.git .claude/skills/superpowers注意把那段[官方倉庫地址]替換成你從項目主頁復制的真實地址。克隆完之后檢查一下.claude/skills/superpowers下面是不是每個技能文件夾都有SKILL.md。如果沒有說明作者可能調整了目錄結構你要么按照最新文檔調整路徑要么換個版本號重新克隆。這一步細看目錄的功夫特別重要。模型加載技能是嚴格按路徑和文件名來找的目錄不對技能就會被靜默跳過而且不會報任何錯誤你以為裝好了其實根本沒生效。3.3 引入后的驗證讓 AI 說說自己有哪些技能裝好之后進到項目目錄啟動 Claude Codecd ~/my-project claude然后在會話里直接問一句你現在可以加載哪些 skills如果配置正確它會列出一串技能名稱和用途。部分版本還支持直接輸入/skills以命令面板的形式展示可用技能列表。如果它一臉迷?；蛘吒嬖V你沒有可用技能百分之九十是路徑問題。技能目錄沒放在.claude/skills下或者SKILL.md的名字大小寫寫錯了。此時打開終端執(zhí)行l(wèi)s -la .claude/skills檢查一下確保技能文件夾確實存在并且里面的文件嚴格叫SKILL.md大寫字母不能少。另一個常見原因是 YAML 頭寫錯導致解析失敗這個我在后面常見問題里單獨說。4. 核心 Skills 清單這些超能力到底能做什么4.1 工作流級技能plan / implement / reviewSuperpowers 最核心的價值就在這套組合拳上。plan技能要求 AI 在動手前先輸出一份任務拆解包括變更范圍、涉及文件、風險點、以及實施順序。以前我直接讓 AI 做需求它經常一句好的我來實現就開始改代碼改到一半發(fā)現方向錯了。有了 plan 技能的約束它會先給你一份類似技術方案的東西你確認沒問題了再進入下一步。implement技能用來約束 AI 在實施階段一次只做一件事。每完成一小步它就會檢查是否符合預期而不是一口氣改十幾個文件最后報錯都找不到源頭。review技能則是讓 AI 以挑刺的視角檢查代碼。我第一次用就被震撼到了。以前讓它幫我看看這段代碼它只會回一句看起來沒問題。掛上 review 技能之后它會列出具體的推理鏈、可疑點、潛在安全問題甚至直接給出修改后的 diff。那種感覺就像是突然多了一個眼里揉不得沙子的結對同事。4.2 問題排查級技能debug / fix / refactor查 bug 是最考驗 AI 的場景。沒有約束時AI 會東試一下西試一下甚至直接猜一個原因就開始改。帶debug技能后它會要求你先復現問題、收集相關日志然后建立假設、驗證假設、定位根因最后才動代碼。這個流程聽上去很基礎但 AI 在執(zhí)行時卻很容易做到位因為它會一步步向你確認信息而不是一上來就給一堆猜測。fix和refactor是配套出現的。fix 聚焦以最小改動解決問題而 refactor 側重在不改變行為的前提下改善結構。這兩個技能綁定得很緊因為很多人的真實需求是幫我改得干凈點結果 AI 改著改著行為就變了。有技能約束時AI 會在動結構之前先用測試把現有行為釘住然后再動手。這一點對老項目維護尤其重要我吃過太多次只改了重構卻引入回歸 bug的虧。4.3 工程治理級技能git / test / doc / postmortem除了寫代碼Superpowers 里還會帶一批項目治理相關的技能。這些技能聽起來不怎么性感但對項目長期健康度的幫助卻很大。技能名用途典型觸發(fā)指令plan動手前輸出任務拆解與實施計劃先用 plan 規(guī)劃一下這件事implement按計劃逐步實現一次只改一件事按計劃實施debug系統(tǒng)化排查 bug先復現再定位根因幫我查一下為什么報錯review代碼審查找 bug、安全與設計問題review 一下這次改動refactor非破壞性重構保持行為不變重構一下這個模塊test分析并補充測試覆蓋給這個函數補測試git-workflow規(guī)范化提交信息與分支管理提交代碼postmortem事故復盤分析與改進項輸出復盤這次線上問題以git-workflow為例它不只是讓 AI 幫你執(zhí)行 git 命令而是約束它按照規(guī)范生成提交信息、檢查本次改動的 diff、甚至在做危險操作前提前警告。test技能也不是簡單地說寫幾個測試而是讓 AI 先分析哪些路徑需要覆蓋用哪種測試框架合適然后有目的地補測試。postmortem技能則用在事故之后它會引導 AI 按照發(fā)生了什么、為什么發(fā)生、怎么做才能避免復發(fā)三步走輸出一份結構化的復盤報告。4.4 引入技能的正確姿勢顯式指令 vs 自動觸發(fā)這里有個很多人沒搞明白的機制skill 有兩種觸發(fā)方式。一種是顯式觸發(fā)。你在會話里直接說用 plan 技能規(guī)劃一下或者用 debug 技能查一下模型就會去讀取對應的 SKILL.md然后嚴格按照里面的指令執(zhí)行。這種方式最可控特別適合重要流程。另一種是自動觸發(fā)。每個 SKILL.md 的 YAML 頭里有一個 triggers 字段用來描述哪些類型的請求會自動命中該技能。比如 debug 技能通常會寫當用戶報告程序異常、報錯、行為不符合預期時自動使用本技能。于是你只要把報錯信息貼給 AI它就會自動走 debug 流程。我實際測試下來自動觸發(fā)在多數日常場景下都能命中省去了反復強調請用某個技能的麻煩。兩種方式沒有絕對好壞。顯式更可控隱式更省心。我的建議是越重要的流程越用顯式比如上線前 review、方案計劃越是日常雜活越依賴自動觸發(fā)就好。不過自動觸發(fā)也不是萬能的如果觸發(fā)條件寫得過于寬泛模型反而會不知道該不該用。這個就牽扯到技能自描述了后面細說。5. 實際使用中的常見問題與排查技巧5.1 為什么 AI 沒有按預期加載某個 skill這是問得最多的一個問題也是最容易排查的。常見原因有三個。第一路徑問題。技能目錄不在 Claude Code 讀取的路徑范圍里。項目級技能必須放在.claude/skills/下全局技能必須放在~/.claude/skills/下兩邊不能混用。第二SKILL.md的 frontmatter 解析失敗。YAML 的語法極其脆冒號后面沒加空格、描述里用了中文逗號、多寫了一個 dependencies 字段但對應技能不存在都會導致解析失敗。一旦失敗整個技能會被靜默跳過不報錯、不提示。第三描述寫得太寬泛模型識別不了。比如你寫 處理文件模型面對具體問題時很難判斷處理文件到底指的是這個技能還是另一個更匹配的技能。描述里應該寫明適用于什么場景、能帶來什么好處、以及不用它會有什么問題。排查時我建議打開 Claude Code 的 verbose 日志模式。它會打印出是否嘗試加載某個 SKILL.md的日志記錄。看到Loaded skill說明命中看到Skipped就說明觸發(fā)條件沒滿足。我第一次排查時就是沒開日志對著項目目錄翻來覆去看了半小時最后發(fā)現只是 YAML 里一個冒號后面少了空格?，F在想想都覺得虧。5.2 如何快速自定義一個自己的 skill千萬不要覺得 Superpowers 只能用它自帶的技能。它的目錄結構完全是開放的你可以照葫蘆畫瓢寫一個屬于自己項目的技能。步驟很簡單。先在.claude/skills/下建一個新文件夾名字用短橫線連接的小寫單詞比如api-contract-check。里面放一個SKILL.md開頭是 YAML frontmatter至少寫清楚 name 和 description有條件的寫上 triggers 和 dependencies。正文就是具體的執(zhí)行步驟比如先讀取 xxx 接口文件再比對 yyy 文檔最后輸出差異表。寫完之后在會話里說用 api-contract-check 檢查一下訂單模塊馬上就能用。我自己給團隊寫過不少這類小技能比如檢查前端項目里的 console.log 殘留生成數據庫遷移腳本模板按公司規(guī)范格式化提交信息每一個都很簡單但用起來極其順手。這個自定義能力才是 skill 生態(tài)最迷人的地方。別人給的是啟動器真正能跑多遠看你自己的玩法。5.3 一些實操經驗與避坑建議最后分享幾個我用了大半年后的心得體會每一條都踩過坑。第一不要一次性引入全部技能。Superpowers 默認裝上以后會有十幾個技能但你打開一個會話時模型不一定會全部讀取如果任務比較復雜它甚至可能在讀取技能描述上浪費大量 token。我建議先挑plan、debug、review這三個用熟再逐步增加。每個技能都會在會話中占用一定的上下文空間裝太多反而拖累正常對話。第二技能里的指令不一定百分百適用你的項目該改就改。比如我們團隊的提交規(guī)范要求帶上需求單號我就把git-workflow技能里的提交信息模板改成了帶單號的格式。技能是死的項目是活的不要被默認值束縛。第三凡是涉及curl | bash的安裝方式務必先看一遍腳本再執(zhí)行。這個習慣能擋住大部分惡意安裝和錯誤安裝。第四定期更新技能包。Superpowers 這類項目更新節(jié)奏不慢作者會根據新版模型的行為調整技能描述舊描述可能會誤導模型。我一般每個月更新一次更新前先看一下 changelog避免突然變化影響自己已有的定制。我在實際使用中還有一個很深的感受這類 skill 體系真正的瓶頸從來不是安裝步驟而是你有沒有想清楚想讓 AI 遵守哪些流程。Superpowers 給你提供了一套默認的最佳實踐但默認值永遠不等于你的最優(yōu)解?；ㄊ昼姼囊桓募寄苊枋霭涯阕约簣F隊的習慣寫進去可能比換一個更強的模型更管用。工具永遠只是起點真正讓 AI 變得可靠的是你對流程的思考。