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