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