把心里想著給AI裝一個技能包變成現(xiàn)實其實是一件挺反直覺的事。大多數(shù)人第一次接觸 superpowers 時都以為它是一個插件、一個 API 或者一個需要注冊的服務(wù)裝上就能讓 AI 突然變聰明。我剛開始也是這么想的結(jié)果在配置完的第二天才發(fā)現(xiàn)superpowers 真正改變的不是模型的智力而是AI 和你協(xié)作的方式——它把原本寫在系統(tǒng)提示詞里的那些通用建議替換成了一套一個文件一個技能、按需調(diào)用的天賦樹。這篇文章我會從安裝、技能清單、實際觸發(fā)方式到踩坑記錄把 superpowers 的使用路徑完整捋一遍。1. superpowers不是插件而是一套AI技能的天賦樹1.1 從萬能AI到帶了工具箱的AI如果你用過 AI 編程助手大概有過這種體驗?zāi)阕屗鼛臀遗挪橐幌聻槭裁礃?gòu)建總是失敗它會非?？蜌獾亓谐鲆欢奈鍡l可能原因每條都正確每條都沒用。不是模型不夠聰明而是它缺少一種當(dāng)前該用什么路徑來解決這個具體問題的約束。superpowers 的思路很直接——把常用的、被驗證過的高質(zhì)量工作方式拆成一棵技能樹brainstorming、troubleshooting、writing-plans、subagent-driven-development每一類都是一個獨立的技能文件AI 在需要的時候再加載對應(yīng)的做事方法論。它和傳統(tǒng)插件有一個本質(zhì)區(qū)別插件是代碼層面的擴展superpowers 是指令層面的技能包。它在模型之外定義了一套遇到什么場景就調(diào)用什么策略的規(guī)則。拿調(diào)試來說普通的對話模式會默認讓 AI 給你一個綜合建議而加載了 debugging 技能之后AI 會先要求你給出可量化的失敗預(yù)期再引導(dǎo)你一步步構(gòu)造最小復(fù)現(xiàn)最后才確認是修代碼還是換方案。這種流程感才是它真正值錢的地方。1.2 技能文件的核心結(jié)構(gòu)SKILL.md里到底寫了什么想要理解 superpowers最快的方式是直接打開一個 SKILL.md 文件看一眼。它本質(zhì)上是一份帶元數(shù)據(jù)的 Markdown 文檔文件頭部有一段 YAML frontmatter用來告訴 AI 這個技能叫什么、在什么場景下用、什么時候不該用下面才是完整的操作指引。--- name: troubleshooting description: 當(dāng)用戶報告某個功能不符合預(yù)期或行為與文檔不一致時使用 when-to-use: 問題現(xiàn)象明確、目標結(jié)果已知、根因未知 --- # Troubleshooting 技能說明 1. 先要求用戶描述期望行為和實際行為 2. 根據(jù)差值提出一個可驗證的假設(shè) 3. 每輪只驗證一個假設(shè)避免同時引入多個變量 ...這里最重要的是description和when-to-use這兩個字段。AI 在對話中判斷現(xiàn)在該不該跳轉(zhuǎn)到這個技能靠的就是這兩個描述。我在第一次自定義技能時就吃過虧只寫了 description 沒寫 when-to-use結(jié)果 AI 永遠不知道什么時候該用它等于白裝。所以如果你要改別人的技能文件務(wù)必保留下這兩個字段并且用具體場景 觸發(fā)條件的方式寫清楚。1.3 它和普通Prompt / 系統(tǒng)提示詞的區(qū)別很多人看完會說這不就是一個比較長的 Prompt 嗎區(qū)別確實有但不是大 Prompt 和長 Prompt 的問題。普通 Prompt 是一次性的你這次寫請你按調(diào)試流程走AI 這次遵守下次上下文一斷就忘了。superpowers 則是把它固化成獨立文件 觸發(fā)機制AI 可以在任何一段對話的中間識別出當(dāng)前場景自動加載對應(yīng)技能不會因為上下文窗口滾動就把規(guī)則丟掉。更關(guān)鍵的是單個技能文件是可以組合和嵌套的。比如 AI 在處理一個崩潰 bug 時先觸發(fā)了 troubleshooting在定位過程中發(fā)現(xiàn)要修改的方案涉及多個模塊它又可以調(diào)用 writing-plans 來生成一份執(zhí)行計劃。技能之間可以互相引用這種模塊化能力是一段超長 Prompt 給不了的。我實際用下來最爽的體驗不是某一個技能多聰明而是 AI 會在正確的時機切換人格從排查者變成規(guī)劃者不需要你再額外強調(diào)接下來咱們換個思路。2. 裝一個看看安裝前置條件與兩種最穩(wěn)妥的引入姿勢2.1 先確認你的AI編程環(huán)境支持技能機制superpowers 不是一個獨立運行的軟件它是寄生在支持技能機制skills的 AI 編程環(huán)境之上的。換句話說你的 AI 助手必須能讀取本地的一個技能目錄并且在對話運行時動態(tài)加載其中的 Markdown 文件。目前主流的選擇是各類 Cli 形態(tài)的 AI 編程工具比如以 Claude Code 為代表的終端交互環(huán)境因為它們天然有項目上下文 自由讀取文件的能力。我在安裝前繞了不少彎路一開始直接往一個網(wǎng)頁版聊天窗口里塞技能描述結(jié)果當(dāng)然毫無反應(yīng)。后來我才理清楚這個道理工具本身必須支持讀取文件作為上下文的一部分網(wǎng)頁聊天窗口沒有本地文件系統(tǒng)自然接不住技能包。所以你先別急著復(fù)制粘貼先確認三件事第一你的 AI 環(huán)境能否通過命令訪問本地文件第二能否指定一個額外的指令目錄作為系統(tǒng)上下文第三對話中的系統(tǒng)提示詞是否允許追加技能說明。三條都通過再考慮怎么裝。2.2 方式一克隆倉庫后按目錄結(jié)構(gòu)映射安裝方式其實相當(dāng)樸素。把整個技能倉庫 clone 下來在 AI 環(huán)境的配置里指定額外指令 / 技能目錄指向倉庫中的 skills 文件夾即可。你不需要逐個復(fù)制文件AI 會自動枚舉目錄下的所有 SKILL.md并把它們的元數(shù)據(jù)加載進候選技能列表。git clone https://github.com/example/superpowers.git ~/.superpowers克隆完成后目錄里一般長這樣superpowers/ └── skills/ ├── brainstorming/ │ └── SKILL.md ├── troubleshooting/ │ └── SKILL.md ├── writing-plans/ │ └── SKILL.md └── subagent-driven-development/ └── SKILL.md這種方式的優(yōu)點是一次性拿全所有技能適合想先全家桶體驗一波的人。缺點是倉庫更新了要手動拉取而且全部技能都掛在候選列表里如果工具沒有良好的按需加載邏輯偶爾會看到 AI 在不太相干的場景里嘗試套用某些技能。我自己的策略是第一次裝用全家桶跑通之后再把不常用的技能從目錄里挪走只保留三四個核心技能。2.3 方式二手動復(fù)制單個技能文件按需裝載如果你已經(jīng)知道自己只需要某幾個技能方式二清爽得多。找到對應(yīng)技能的目錄把整個文件夾注意是整個文件夾不是單獨那個 SKILL.md 文件復(fù)制到你項目里的.ai/skills/之類的技能目錄下。之后在 AI 對話中只要觸發(fā)條件匹配它就會自動識別并使用。cp -r ~/.superpowers/skills/troubleshooting ./my-project/.ai/skills/為什么強調(diào)復(fù)制整個文件夾因為一些技能比如 brainstorming 的子模板、writing-plans 的示例文檔會引用同目錄下的其他資源只復(fù)制一個 Markdown 文件進去后面大概率會碰到路徑找不到的問題。我第二次安裝時就圖省事只拖了文件結(jié)果 AI 在加載技能后想?yún)⒖际纠０逯苯犹崾疚募淮嬖谀枪纱鞌「性诿钚欣镉绕涿黠@。2.4 驗證安裝成功的標志裝沒裝成功不用去翻日志直接在對話里試一次就知道。問 AI你現(xiàn)在能用哪些技能它如果返回了一串列表并且能準確說出每個技能的適用場景說明元數(shù)據(jù)加載成功。接下來再給一個實際任務(wù)比如幫我看看這段日志里為什么連接超時觀察它的回話方式如果它開始主動問你期望行為是什么、實際看到的是什么恭喜troubleshooting 技能已經(jīng)被觸發(fā)了。還有一個容易忽略的點技能是否生效取決于 AI 是否把它納入了當(dāng)前的系統(tǒng)上下文。有些環(huán)境需要你在配置里顯式開啟附加技能指令選項或者在對話開始時發(fā)送一個加載指令。如果你發(fā)現(xiàn)技能文件明明放好了但 AI 毫無反應(yīng)優(yōu)先檢查配置項而不是懷疑技能文件本身。我上次折騰了兩小時最后只是少了設(shè)置里一個開關(guān)氣得不行。3. 有哪些skills核心技能清單與各自適合的戰(zhàn)場3.1 規(guī)劃類brainstorming與writing-plansbrainstorming 是我用得最頻繁的一個技能。它在 AI 收到模糊需求時啟動核心動作是先發(fā)散再收斂。AI 不會直接給你一個方案而是先要求你提供約束條件、期望目標、已知的邊界限制然后生成 3 到 5 個差異明顯的方向供你選最后基于你挑選的方向細化成可執(zhí)行選項。這個方法本質(zhì)上是把頭腦風(fēng)暴里的結(jié)構(gòu)化流程搬給了 AI讓 AI 不再急著給答案而是先陪你聊問題。writing-plans 則是把做事的順序固化成文檔。它和普通列步驟最大的不同是計劃輸出后會被保存成項目里的一個文件AI 在后續(xù)對話中會反復(fù)引用這份計劃每完成一個階段就在計劃上做標記。這就解決了 AI 對話最大的毛病——說完就忘。我接一個涉及 6 個文件改動的小需求時讓 AI 先出 plan 再動手它后面每一步都會對照計劃檢查現(xiàn)在做到哪一步了上下文再長也不偏離軌道。3.2 排錯類troubleshooting與debuggingtroubleshooting 適合現(xiàn)象明確、根因不明的場景比如服務(wù)起不來、接口返回異常、頁面白屏。它規(guī)定的流程是先讓用戶描述期望行為與實際行為把模糊的好像不行變成具體的應(yīng)該返回 200 卻返回了 500再構(gòu)造一個最小可復(fù)現(xiàn)路徑用可控實驗排除變量最后給出針對根因的修復(fù)建議而不是頭痛醫(yī)頭。debugging 則是更偏代碼層面的技能。它要求 AI 在你提供代碼或日志后先找出失敗預(yù)期——也就是說你必須能明確說出我認為哪里不對AI 再去驗證你的假設(shè)對不對。有一次我碰到一個偶發(fā)性的內(nèi)存泄漏一直查不到原因后來按 debugging 的流程走它讓我把每次內(nèi)存增長的場景單獨寫成一個斷言跑三次看哪條失敗。跑了兩次就定位到緩存清理時機的問題效率比毫無章法地猜高太多。3.3 流程類subagent-driven-development與creating-design-docssubagent-driven-development 是偏工程管理的技能。它把一個大任務(wù)拆成多個獨立子任務(wù)每個子任務(wù)交給一個獨立的子代理去完成所有子代理共享一份任務(wù)文檔最后主線程匯總。這樣做的最大好處是上下文隔離每個子代理只需要關(guān)心自己那部分代碼不需要把整個項目的來龍去脈都塞進同一個上下文適合改一個橫跨多個模塊的大型改動。creating-design-docs 則是在動手寫代碼前先生成設(shè)計文檔。這個技能特別適合多人協(xié)作或者需要留檔的項目AI 會根據(jù)你的需求描述生成一份包含背景、目標、技術(shù)選型、接口設(shè)計、風(fēng)險點在內(nèi)的設(shè)計文檔。我實際感受是有了設(shè)計文檔之后Review 環(huán)節(jié)的沖突少了很多因為大家在動手前就對方案達成了一致而不是寫完了再爭為什么用這個方案。3.4 協(xié)作基礎(chǔ)類using-git與systematic-approachesusing-git 這個技能看似簡單實際很有用。它不會替你做任何事情而是每次涉及 git 操作時先給你解釋這條命令做了什么、會有什么影響得到你的確認才執(zhí)行。它防止了 AI 在無人監(jiān)管的情況下亂提交代碼尤其是在你不在電腦前、讓它跑一個長時間任務(wù)時這個每步確認的價值就體現(xiàn)出來了。systematic-approaches 則是一款通用型的找問題技能。它強調(diào)把大問題拆成多個小問題一次只解決一個并且對每個小問題的輸出做驗證。它適合的場景不太精確比如系統(tǒng)太慢代碼好亂這類沒有明確線索的問題。AI 會帶著你把這個大而無當(dāng)?shù)谋г怪鸩讲鸪删唧w是哪一層慢、哪段代碼亂直到變成可以直接動手的小任務(wù)。3.5 怎么選根據(jù)團隊角色和任務(wù)類型配技能技能不是越多越好。我的經(jīng)驗是如果你是單人開發(fā)者主要寫業(yè)務(wù)代碼前期只需要 brainstorming、troubleshooting、using-git 三個就夠。如果你在帶的項目涉及多模塊協(xié)作再額外加 subagent-driven-development 和 writing-plans。做架構(gòu)或者寫基礎(chǔ)庫的人把 creating-design-docs 和 systematic-approaches 也裝上。裝多了之后AI 會在無關(guān)場景里反復(fù)嘗試套技能反而拖慢對話節(jié)奏。另外要注意技能之間的互相搶活。比如 troubleshooting 和 debugging 在某些邊界場景會同時匹配AI 可能一會兒按調(diào)試流程走一會兒又按排錯流程走。我的解決辦法是保持兩種技能的when-to-use描述有明確邊界troubleshooting 負責(zé)行為不符預(yù)期debugging 負責(zé)已知代碼路徑下有 bug。這樣 AI 才能準確判斷該調(diào)用哪一個。4. 怎么把技能真正用起來觸發(fā)方式與工作流編排4.1 對話內(nèi)觸發(fā)一句話喚起對應(yīng)技能技能不是要先激活才能用。最簡單的方式就是你在對話里直接說用 brainstorming 幫我理一下思路或者現(xiàn)在進入 troubleshooting 模式。只要技能文件安裝得沒問題AI 會根據(jù)你的請求檢索到匹配的技能然后按照那份 SKILL.md 里的步驟和你對話。我比較推薦這種顯式觸發(fā)的方式尤其是在任務(wù)邊界明確的時候。比如接手一段爛代碼我會直接說用 systematic-approaches 幫我從這個項目里挑出最值得重構(gòu)的三個點。這樣 AI 會嚴格按拆小問題 → 一次解決一個 → 驗證輸出的順序來而不是泛泛地給你一份重構(gòu)建議清單。顯式觸發(fā)的另一個好處是你能感受到技能切換的瞬間改變——用詞、追問方式、要求的輸入格式都變得不一樣了。4.2 自動觸發(fā)配置里的選擇器與上下文感知自動觸發(fā)的核心邏輯在配置文件里。你可以在技能目錄的配置中聲明匹配規(guī)則比如包含gunicorn worker 崩潰這類關(guān)鍵詞時自動偏向加載 troubleshooting。實際自動化效果取決于工具實現(xiàn)我建議把自動觸發(fā)當(dāng)成保底機制來用而不是完全放手。如果工具沒有提供完善的自動觸發(fā)機制還有一個土辦法在項目根目錄放一個AGENTS.md之類的項目指令文件在里面寫清楚本項目遇到 XXX 類問題必須使用 troubleshooting 技能。AI 每次讀取項目上下文時都會看到這段指令效果和自動觸發(fā)是差不多的。這個辦法我用了一段時間穩(wěn)定可靠而且可讀性強團隊新人來了也能一眼看到約定。4.3 技能之間的引用與嵌套技能不是孤立文件它們可以互相調(diào)用。比如 AI 在 brainstorming 階段產(chǎn)出了三個潛在方向你選了一個之后它可能會自動切入 writing-plans把選中的方向變成一份帶步驟的計劃。然后執(zhí)行計劃時又切換到 subagent-driven-development把計劃里的每個步驟變成獨立子任務(wù)。這種嵌套之所以能成立是因為每個技能文件的末尾通常會寫明后續(xù)建議使用哪些技能。比如 troubleshooting 技能會在定位到根因后建議如果修復(fù)涉及多模塊請使用 writing-plans。你在自定義技能時也可以加上這一段讓 AI 在正確的時間點移交給下一個技能。講句實話這個設(shè)計比很多商業(yè)軟件的工作流編輯器還順手因為它完全是文本驅(qū)動的改起來特別靈活。4.4 一次典型工作流的完整跑通我拿一次實際的 bug 修復(fù)來演示流程。先是在日志里發(fā)現(xiàn)接口偶發(fā) 502我會用一句話喚起 troubleshooting。AI 讓我提供了期望結(jié)果成功率 100%實際結(jié)果每 100 次約 2 次 502然后構(gòu)造了一個高頻請求的復(fù)現(xiàn)腳本跑出失敗樣例后定位到是某個連接池沒有做回收。根因確認后AI 主動建議開啟 writing-plans把修改連接池配置 增加監(jiān)控指標 補回歸測試拆成三步計劃。修改過程中因為涉及兩個服務(wù)它又調(diào)用 subagent-driven-development讓一個子代理改代碼、另一個子代理補測試最后匯總結(jié)果。整個過程里我只需要在幾個關(guān)鍵節(jié)點確認方向不用反復(fù)指揮。這個工作流最大的收獲是讓我意識到提醒 AI 該用什么策略這件事不再需要我做。以前我總得在對話里反復(fù)強調(diào)先不要改先幫我理思路之類的話裝完技能之后這些口頭禪全都可以去掉因為它自己知道在哪個階段該做什么。5. 這些坑我替你踩過了配置沖突、作用域與自定義技能5.1 技能文件放錯目錄導(dǎo)致不被識別技能目錄的掃描通常有固定的約定比如只掃描根目錄下的一級級子文件夾或者只識別路徑中包含skills的目錄。我一開始把 SKILL.md 直接放在了項目根目錄AI 完全沒認出來。后來才注意到官方倉庫的結(jié)構(gòu)里每個技能都有獨立文件夾SKILL.md 要放在以技能名命名的文件夾內(nèi)部。還有一個隱蔽問題有些工具的技能目錄是全局的掃描的是用戶根目錄下的.ai/skills/而不是項目目錄下的.ai/skills/。我在項目里放了好久沒生效排查到最后發(fā)現(xiàn)要看當(dāng)前正在用的上下文環(huán)境是全局模式還是本地模式。所以裝完后一定要先用上文的驗證方法測試一下別像我一樣傻等半天。5.2 同名技能的優(yōu)先級與覆蓋規(guī)則如果你同時有全局技能和項目技能或者從別的倉庫復(fù)制了同名技能文件它們之間會有一個就近覆蓋的規(guī)則。通常項目目錄下的技能會覆蓋全局目錄下的同名技能后加載的會覆蓋先加載的。聽起來簡單但沖突起來很隱蔽——默認的 brainstorming 是英文版你從某個 fork 里裝了一個中文版結(jié)果 AI 時而說中文時而說英文就是因為配置文件里兩邊都保留著。排查辦法很簡單在對話里讓 AI 列出每個技能的實際加載來源路徑。如果看到了兩個來源把不需要的那份直接挪走。我習(xí)慣在項目目錄里固定維護一份團隊標準化技能全局目錄只放基礎(chǔ)通用技能兩者名字錯開從源頭避免覆蓋問題。5.3 自定義技能把團隊規(guī)范寫進SKILL.md用了一段時間之后你大概率不會滿足于現(xiàn)成技能尤其是有自己團隊規(guī)范的人。自定義技能其實很簡單照著現(xiàn)有 SKILL.md 的格式寫一份新文件定義好name、description、when-to-use然后把你希望 AI 遵守的流程邏輯寫在正文里。我給我們團隊寫過一個數(shù)據(jù)庫變更評審技能里面規(guī)定了所有涉及表結(jié)構(gòu)變更的操作必須先輸出影響分析、回滾腳本和灰度方案AI 在改動前會主動走這個流程。編寫時有個細節(jié)千萬不要把 SKILL.md 寫成百科全書。技能文件越精煉AI 越容易執(zhí)行文件越長越詳細反而會把它搞暈。一份好的技能文件應(yīng)該像一張工作流程圖而不是一份操作手冊。你可以把詳細規(guī)則拆成獨立文檔放到同目錄下在 SKILL.md 里用一兩句話引導(dǎo) AI需要時再查閱這樣既保留了細節(jié)又不會污染主流程。5.4 使用心得什么時候該用技能什么時候該直接對話最后說說我的真實使用心得。superpowers 不是神它不會讓每次對話都變高效。日常問答、快速驗證、寫個臨時腳本這類場景直接對話反而更快技能加載本身也有上下文開銷。技能真正發(fā)威的時刻集中在三類場景任務(wù)復(fù)雜到需要多步驟推進、問題模糊到需要結(jié)構(gòu)化拆分、改動大到需要跨模塊協(xié)調(diào)。我自己現(xiàn)在的工作習(xí)慣是先輕后重。接到需求先在普通對話里聊聊到發(fā)現(xiàn)方向太多或者問題反復(fù)出現(xiàn)再顯式調(diào)用對應(yīng)技能切入。這種混合模式比全程開技能更適合真實開發(fā)節(jié)奏。你也不用逼著自己把所有技能都用一遍找到三四個和你日常任務(wù)最匹配的反復(fù)用熟效率提升遠比裝十幾個技能卻一個都不精通來得強。