1. 拆解“superpowers”一個(gè)被熱搜詞帶火的能力增強(qiáng)框架“superpowers”這個(gè)詞最近在技術(shù)社區(qū)和效率工具圈子里頻繁出現(xiàn)連帶“想要安裝superpowers”都成了搜索熱詞。我第一次看到這個(gè)標(biāo)題時(shí)直覺(jué)告訴我它不是一個(gè)單純的軟件包名而更像是一類能力增強(qiáng)工具集的統(tǒng)稱。事實(shí)也確實(shí)如此——在開(kāi)發(fā)者社群里superpowers通常指的是一套面向AI編程助手的能力擴(kuò)展框架它通過(guò)注入預(yù)設(shè)的“技能包”和“工作流模板”讓原本只會(huì)聊天的AI助手變成能真正動(dòng)手干活的工程搭檔。這個(gè)框架解決的核心問(wèn)題很具體你用AI寫(xiě)代碼時(shí)是不是經(jīng)常遇到它“說(shuō)得頭頭是道動(dòng)手就翻車(chē)”的情況比如讓它改一個(gè)函數(shù)它把整個(gè)文件重寫(xiě)了讓它加個(gè)日志它把日志格式搞錯(cuò)了讓它按TDD流程走它直接跳過(guò)測(cè)試寫(xiě)實(shí)現(xiàn)。superpowers的思路就是把這些工程規(guī)范、操作流程、領(lǐng)域知識(shí)打包成可復(fù)用的“超能力模塊”在需要的時(shí)候精準(zhǔn)注入讓AI的行為從“隨機(jī)發(fā)揮”變成“按套路出牌”。適合誰(shuí)來(lái)參考這篇內(nèi)容三類人最值得往下看第一類是日常用AI輔助編程但總覺(jué)得“差口氣”的開(kāi)發(fā)者第二類是想給自己團(tuán)隊(duì)搭建AI工作流的技術(shù)負(fù)責(zé)人第三類是對(duì)AI Agent能力擴(kuò)展機(jī)制好奇的技術(shù)愛(ài)好者。不管你之前有沒(méi)有接觸過(guò)類似框架這篇內(nèi)容會(huì)從設(shè)計(jì)思路、核心機(jī)制、安裝配置到實(shí)戰(zhàn)踩坑一條龍講清楚。2. 核心設(shè)計(jì)思路為什么是“技能注入”而不是“模型微調(diào)”2.1 從“萬(wàn)能助手”到“專科醫(yī)生”的轉(zhuǎn)變邏輯傳統(tǒng)使用AI編程助手的方式就像請(qǐng)了一個(gè)知識(shí)淵博但沒(méi)上過(guò)班的實(shí)習(xí)生——他什么都知道一點(diǎn)但你不告訴他具體怎么做他就按自己的理解來(lái)。superpowers的設(shè)計(jì)哲學(xué)是不改變模型本身而是改變模型接收到的上下文。這個(gè)選擇背后有三個(gè)非常務(wù)實(shí)的考量。第一微調(diào)成本太高。每次想增加一個(gè)新技能都要準(zhǔn)備數(shù)據(jù)集、跑訓(xùn)練、做評(píng)估周期以天甚至周計(jì)算。而技能注入只需要寫(xiě)一個(gè)Markdown格式的技能描述文件幾分鐘就能生效。第二微調(diào)會(huì)“污染”模型的通用能力。你為了讓它擅長(zhǎng)寫(xiě)React組件去微調(diào)結(jié)果它對(duì)Python的處理能力下降了這種蹺蹺板效應(yīng)在實(shí)際項(xiàng)目中很致命。第三技能注入是可解釋、可版本控制的。每個(gè)技能包就是一個(gè)文本文件改了什么都看得見(jiàn)團(tuán)隊(duì)協(xié)作時(shí)可以直接Code Review。我實(shí)測(cè)下來(lái)的感受是這種“外掛式”的能力增強(qiáng)在80%的日常開(kāi)發(fā)場(chǎng)景里比微調(diào)更實(shí)用。因?yàn)榇蟛糠謺r(shí)候你需要的不是模型“學(xué)會(huì)”某個(gè)知識(shí)而是它“記得”按照某個(gè)規(guī)范來(lái)做事。2.2 技能包的結(jié)構(gòu)設(shè)計(jì)一個(gè)技能解決一類問(wèn)題superpowers的技能包通常包含四個(gè)核心部分我用一個(gè)實(shí)際例子來(lái)說(shuō)明。假設(shè)你要?jiǎng)?chuàng)建一個(gè)“API接口開(kāi)發(fā)”技能包觸發(fā)條件什么情況下激活這個(gè)技能。比如用戶提到“寫(xiě)一個(gè)REST接口”或“創(chuàng)建Controller”時(shí)觸發(fā)。行為規(guī)范具體怎么做。包括文件命名規(guī)則、目錄結(jié)構(gòu)、參數(shù)校驗(yàn)方式、錯(cuò)誤碼規(guī)范等。檢查清單做完之后要驗(yàn)證什么。比如“是否添加了參數(shù)校驗(yàn)”“是否處理了異常”“是否寫(xiě)了單元測(cè)試”。示例代碼一個(gè)完整的參考實(shí)現(xiàn)讓AI有樣學(xué)樣。這種結(jié)構(gòu)的精妙之處在于它把“隱性知識(shí)”變成了“顯性指令”。團(tuán)隊(duì)里那個(gè)寫(xiě)了五年API的老手他知道接口要加限流、要記錄審計(jì)日志、要返回統(tǒng)一的錯(cuò)誤格式——這些經(jīng)驗(yàn)以前只在他腦子里現(xiàn)在可以寫(xiě)成技能包讓AI和新人一起繼承。注意技能包不是越詳細(xì)越好。我見(jiàn)過(guò)有人寫(xiě)了一個(gè)2000行的技能文件結(jié)果AI處理時(shí)反而抓不住重點(diǎn)。單個(gè)技能包控制在300-500行以內(nèi)核心規(guī)則不超過(guò)10條效果最好。2.3 與主流AI編程工具的集成方式superpowers本身不是一個(gè)獨(dú)立的IDE或編輯器它更像一個(gè)“中間層”通過(guò)標(biāo)準(zhǔn)化的接口與各種AI編程工具對(duì)接。目前常見(jiàn)的集成方式有三種第一種是提示詞前綴注入。在每次向AI發(fā)送請(qǐng)求前自動(dòng)把相關(guān)技能包的內(nèi)容拼接到系統(tǒng)提示詞里。這種方式兼容性最好幾乎任何AI工具都能用缺點(diǎn)是會(huì)占用上下文窗口。第二種是工具調(diào)用攔截。在AI決定調(diào)用某個(gè)工具比如寫(xiě)文件、執(zhí)行命令之前先經(jīng)過(guò)superpowers的規(guī)則引擎檢查符合技能規(guī)范才放行。這種方式更精準(zhǔn)但需要工具本身支持中間件機(jī)制。第三種是工作流編排。把多個(gè)技能包按順序組合成一個(gè)完整的工作流比如“需求分析→接口設(shè)計(jì)→代碼實(shí)現(xiàn)→測(cè)試驗(yàn)證”四個(gè)技能串聯(lián)執(zhí)行。這種方式適合復(fù)雜任務(wù)但配置門(mén)檻也最高。我個(gè)人的建議是新手從第一種方式開(kāi)始熟悉了技能包的寫(xiě)法之后再嘗試第二種第三種留給有明確SOP的團(tuán)隊(duì)使用。3. 安裝與配置實(shí)操?gòu)牧愦罱愕某芰ο到y(tǒng)3.1 環(huán)境準(zhǔn)備與依賴檢查在開(kāi)始安裝之前先確認(rèn)你的基礎(chǔ)環(huán)境。superpowers對(duì)運(yùn)行環(huán)境的要求不算苛刻但有幾個(gè)關(guān)鍵依賴需要提前準(zhǔn)備好。依賴項(xiàng)最低要求推薦版本檢查命令Node.js18.x20.x LTSnode -v包管理器npm 9.xpnpm 8.xpnpm -vGit2.30最新穩(wěn)定版git --versionAI編程工具支持自定義提示詞任意主流工具視工具而定Node.js的版本特別重要因?yàn)閟uperpowers的很多技能包依賴ES Module的動(dòng)態(tài)導(dǎo)入特性18以下的版本會(huì)報(bào)錯(cuò)。我踩過(guò)一次坑在一臺(tái)老開(kāi)發(fā)機(jī)上用Node 16跑技能加載一直失敗排查了半天才發(fā)現(xiàn)是版本問(wèn)題。檢查完基礎(chǔ)環(huán)境后還需要確認(rèn)你的AI編程工具是否支持以下能力之一自定義系統(tǒng)提示詞、插件機(jī)制、或者API中間件。如果都不支持那superpowers的核心功能就用不了只能手動(dòng)復(fù)制技能包內(nèi)容到對(duì)話里效率會(huì)打折扣。3.2 安裝步驟與目錄結(jié)構(gòu)說(shuō)明安裝superpowers的過(guò)程本身不復(fù)雜但目錄結(jié)構(gòu)的規(guī)劃會(huì)影響后續(xù)的使用體驗(yàn)。我推薦的做法是把它安裝在項(xiàng)目的根目錄下作為一個(gè)獨(dú)立的工具目錄存在。# 在項(xiàng)目根目錄執(zhí)行 mkdir -p .superpowers/skills cd .superpowers # 初始化配置文件 cat config.json EOF { version: 1.0, skillsDir: ./skills, autoLoad: true, maxSkillSize: 500, logLevel: info } EOF安裝完成后你的目錄結(jié)構(gòu)應(yīng)該是這樣的項(xiàng)目根目錄/ ├── .superpowers/ │ ├── config.json # 全局配置 │ ├── skills/ # 技能包存放目錄 │ │ ├── api-dev.md # API開(kāi)發(fā)技能 │ │ ├── tdd-flow.md # TDD流程技能 │ │ └── debug-helper.md # 調(diào)試輔助技能 │ └── logs/ # 運(yùn)行日志 ├── src/ # 你的項(xiàng)目代碼 └── package.json這個(gè)結(jié)構(gòu)的好處是技能包和項(xiàng)目代碼分離不會(huì)污染代碼倉(cāng)庫(kù)。同時(shí).superpowers目錄可以加入.gitignore也可以提交到倉(cāng)庫(kù)讓團(tuán)隊(duì)共享——取決于你的技能包是個(gè)人偏好還是團(tuán)隊(duì)規(guī)范。3.3 第一個(gè)技能包的編寫(xiě)與加載驗(yàn)證光說(shuō)不練假把式。我們來(lái)寫(xiě)一個(gè)最簡(jiǎn)單的技能包驗(yàn)證整個(gè)系統(tǒng)能不能跑通。這個(gè)技能包的功能是當(dāng)AI需要?jiǎng)?chuàng)建新文件時(shí)強(qiáng)制它先檢查文件是否已存在。在.superpowers/skills/目錄下創(chuàng)建safe-file-create.md--- name: safe-file-create trigger: 創(chuàng)建文件、新建文件、write file priority: high --- # 安全文件創(chuàng)建規(guī)范 ## 行為要求 1. 在創(chuàng)建任何新文件之前必須先使用文件檢查工具確認(rèn)目標(biāo)路徑不存在同名文件 2. 如果文件已存在必須向用戶報(bào)告并詢問(wèn)是覆蓋還是另存 3. 創(chuàng)建文件時(shí)必須在文件頭部添加創(chuàng)建時(shí)間和用途注釋 ## 檢查清單 - [ ] 目標(biāo)路徑是否已檢查 - [ ] 是否處理了文件已存在的情況 - [ ] 文件頭注釋是否完整 ## 示例 創(chuàng)建 src/utils/date.js 時(shí) 1. 先執(zhí)行文件存在性檢查 2. 確認(rèn)不存在后寫(xiě)入包含注釋的文件內(nèi)容寫(xiě)完之后需要驗(yàn)證技能包能否被正確加載。大多數(shù)集成方式都提供了驗(yàn)證命令以提示詞注入方式為例# 查看已加載的技能列表 npx superpowers list # 預(yù)期輸出 # ? safe-file-create (high) - 安全文件創(chuàng)建規(guī)范 # ? api-dev (medium) - API接口開(kāi)發(fā)規(guī)范 # ? tdd-flow (medium) - 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)流程如果技能沒(méi)有出現(xiàn)在列表里優(yōu)先檢查三個(gè)地方文件擴(kuò)展名是不是.md、frontmatter格式是否正確、config.json里的skillsDir路徑是否指向了正確目錄。實(shí)操心得技能包的trigger字段不要寫(xiě)得太寬泛。我一開(kāi)始寫(xiě)了個(gè)trigger: 文件結(jié)果AI每次操作文件都觸發(fā)這個(gè)技能連讀文件都要先檢查存在性反而拖慢了速度。后來(lái)改成創(chuàng)建文件、新建文件就精準(zhǔn)多了。4. 核心技能包實(shí)戰(zhàn)三個(gè)高頻場(chǎng)景的完整配置4.1 TDD流程技能包讓AI學(xué)會(huì)“先寫(xiě)測(cè)試再寫(xiě)實(shí)現(xiàn)”測(cè)試驅(qū)動(dòng)開(kāi)發(fā)是AI編程助手最容易翻車(chē)的場(chǎng)景之一。你不特別說(shuō)明它默認(rèn)就是先寫(xiě)實(shí)現(xiàn)再補(bǔ)測(cè)試甚至補(bǔ)的測(cè)試根本測(cè)不到邊界情況。TDD技能包的目標(biāo)就是強(qiáng)制AI按照“紅-綠-重構(gòu)”的節(jié)奏走。--- name: tdd-flow trigger: 實(shí)現(xiàn)功能、寫(xiě)一個(gè)函數(shù)、開(kāi)發(fā)模塊 priority: high --- # 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)流程 ## 強(qiáng)制流程 1. 收到功能需求后先輸出測(cè)試用例列表至少包含正常路徑、邊界條件、異常輸入三類 2. 等待用戶確認(rèn)測(cè)試用例 3. 編寫(xiě)測(cè)試代碼運(yùn)行測(cè)試確認(rèn)失敗紅 4. 編寫(xiě)最小實(shí)現(xiàn)讓測(cè)試通過(guò)綠 5. 重構(gòu)代碼保持測(cè)試通過(guò) 6. 輸出重構(gòu)說(shuō)明 ## 禁止行為 - 禁止在測(cè)試未通過(guò)前編寫(xiě)完整實(shí)現(xiàn) - 禁止跳過(guò)邊界條件測(cè)試 - 禁止在重構(gòu)階段改變外部行為 ## 測(cè)試用例模板 - 正常路徑輸入合法參數(shù)返回預(yù)期結(jié)果 - 邊界條件空值、極值、臨界值 - 異常輸入類型錯(cuò)誤、格式錯(cuò)誤、越界這個(gè)技能包的關(guān)鍵在于“等待用戶確認(rèn)”這一步。我試過(guò)去掉這個(gè)確認(rèn)環(huán)節(jié)結(jié)果AI自己編了一套測(cè)試用例就開(kāi)始寫(xiě)代碼測(cè)的都是它自己覺(jué)得重要的東西跟我實(shí)際關(guān)心的完全不是一回事。加上確認(rèn)環(huán)節(jié)后雖然多了一次交互但返工率大幅下降。4.2 代碼審查技能包自動(dòng)化的“第二雙眼睛”代碼審查是另一個(gè)AI能幫大忙但容易幫倒忙的場(chǎng)景。沒(méi)有約束的AI審查要么只說(shuō)“代碼看起來(lái)不錯(cuò)”這種廢話要么揪著縮進(jìn)風(fēng)格不放卻漏掉了空指針風(fēng)險(xiǎn)。審查技能包需要給AI一套明確的檢查優(yōu)先級(jí)。--- name: code-review trigger: 審查代碼、review、檢查代碼 priority: medium --- # 代碼審查規(guī)范 ## 審查優(yōu)先級(jí)從高到低 1. 安全性SQL注入、XSS、敏感信息硬編碼 2. 正確性邏輯錯(cuò)誤、邊界處理、異常捕獲 3. 性能循環(huán)嵌套、重復(fù)計(jì)算、內(nèi)存泄漏 4. 可維護(hù)性命名規(guī)范、函數(shù)長(zhǎng)度、注釋完整性 5. 風(fēng)格縮進(jìn)、分號(hào)、引號(hào)最低優(yōu)先級(jí) ## 輸出格式 每條問(wèn)題必須包含 - 嚴(yán)重程度阻斷/嚴(yán)重/一般/建議 - 具體位置文件:行號(hào) - 問(wèn)題描述 - 修復(fù)建議附代碼示例 ## 禁止行為 - 禁止只輸出“建議改進(jìn)”而不說(shuō)明具體怎么改 - 禁止在安全性問(wèn)題未解決時(shí)討論風(fēng)格問(wèn)題這個(gè)技能包我用了三個(gè)月最大的感受是“嚴(yán)重程度”這個(gè)字段太有用了。以前AI審查完給我列20條問(wèn)題我分不清哪些必須改哪些可以忽略?，F(xiàn)在按阻斷/嚴(yán)重/一般/建議分級(jí)后我只看阻斷和嚴(yán)重級(jí)別的一般和建議級(jí)別的有空再處理效率提升非常明顯。4.3 調(diào)試輔助技能包從“猜原因”到“系統(tǒng)排查”調(diào)試是AI最容易“胡說(shuō)八道”的場(chǎng)景。你給它一個(gè)報(bào)錯(cuò)信息它經(jīng)常給出一個(gè)聽(tīng)起來(lái)合理但完全錯(cuò)誤的猜測(cè)。調(diào)試技能包的核心思路是強(qiáng)制AI按照系統(tǒng)化的排查流程走而不是直接跳到結(jié)論。--- name: debug-helper trigger: 報(bào)錯(cuò)、異常、不工作、調(diào)試 priority: high --- # 系統(tǒng)化調(diào)試流程 ## 排查步驟 1. 復(fù)現(xiàn)問(wèn)題確認(rèn)報(bào)錯(cuò)是否穩(wěn)定復(fù)現(xiàn)記錄完整錯(cuò)誤信息 2. 定位范圍根據(jù)錯(cuò)誤堆棧確定問(wèn)題所在的文件和方法 3. 提出假設(shè)列出至少3個(gè)可能的原因按可能性排序 4. 驗(yàn)證假設(shè)為每個(gè)假設(shè)設(shè)計(jì)驗(yàn)證方法加日志、寫(xiě)測(cè)試、斷點(diǎn) 5. 確認(rèn)根因找到真正的原因后再提出修復(fù)方案 6. 回歸驗(yàn)證修復(fù)后確認(rèn)原問(wèn)題解決且未引入新問(wèn)題 ## 禁止行為 - 禁止在未復(fù)現(xiàn)問(wèn)題的情況下給出修復(fù)方案 - 禁止只提出一個(gè)假設(shè)就下結(jié)論 - 禁止修改代碼后不驗(yàn)證直接說(shuō)“已修復(fù)” ## 輸出要求 每個(gè)假設(shè)必須附帶驗(yàn)證命令或驗(yàn)證代碼我印象最深的一次調(diào)試經(jīng)歷一個(gè)接口偶爾返回500錯(cuò)誤AI第一反應(yīng)是“數(shù)據(jù)庫(kù)連接池滿了”。如果按以前的用法我可能就去調(diào)連接池參數(shù)了。但調(diào)試技能包強(qiáng)制它列出三個(gè)假設(shè)連接池、序列化異常、并發(fā)競(jìng)爭(zhēng)。然后逐個(gè)驗(yàn)證最后發(fā)現(xiàn)是一個(gè)日期格式化對(duì)象在多線程下共享導(dǎo)致的。如果直接按第一個(gè)假設(shè)去調(diào)參數(shù)這個(gè)問(wèn)題永遠(yuǎn)找不到根因。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 技能不生效的六種原因與排查路徑技能包寫(xiě)好了但AI不按套路出牌這是新手最常遇到的問(wèn)題。我整理了一個(gè)排查清單按出現(xiàn)頻率從高到低排列問(wèn)題現(xiàn)象可能原因排查方法解決方案完全沒(méi)反應(yīng)技能未加載運(yùn)行l(wèi)ist命令查看檢查文件路徑和擴(kuò)展名偶爾生效觸發(fā)詞不匹配查看日志中的觸發(fā)記錄調(diào)整trigger關(guān)鍵詞生效但行為不對(duì)技能內(nèi)容沖突檢查是否有多個(gè)技能同時(shí)觸發(fā)設(shè)置priority或合并技能生效但被截?cái)嗉寄芪募^(guò)大查看注入的上下文長(zhǎng)度精簡(jiǎn)技能內(nèi)容至500行以內(nèi)只在某些工具生效集成方式不兼容確認(rèn)工具支持的注入方式切換注入方式或工具之前生效現(xiàn)在失效配置被覆蓋檢查config.json變更恢復(fù)配置或重新加載其中“技能內(nèi)容沖突”是最隱蔽的問(wèn)題。我有一次同時(shí)啟用了“代碼審查”和“TDD流程”兩個(gè)技能結(jié)果AI在寫(xiě)代碼時(shí)一會(huì)兒想先寫(xiě)測(cè)試一會(huì)兒想先審查最后輸出了一堆混亂的內(nèi)容。后來(lái)我給TDD技能設(shè)置了更高的priority并明確在審查技能里加了“不干預(yù)編碼流程”的說(shuō)明才解決。5.2 上下文窗口被技能包“撐爆”的優(yōu)化策略這是superpowers使用中最實(shí)際的工程問(wèn)題。每個(gè)技能包注入時(shí)都會(huì)占用上下文窗口當(dāng)同時(shí)加載多個(gè)技能時(shí)留給實(shí)際對(duì)話的空間就被壓縮了。我做過(guò)一個(gè)粗略的測(cè)算一個(gè)500行的技能包大約占用1500-2000個(gè)token如果同時(shí)加載5個(gè)技能光技能內(nèi)容就消耗了近10000個(gè)token。優(yōu)化策略有三條按效果排序第一條是按需加載。不要把所有技能都設(shè)為autoLoad: true而是根據(jù)當(dāng)前任務(wù)類型動(dòng)態(tài)加載。比如寫(xiě)API時(shí)只加載API技能和TDD技能調(diào)試時(shí)只加載調(diào)試技能。大多數(shù)集成工具都支持通過(guò)命令手動(dòng)切換技能集。第二條是技能分層。把技能包分為“核心層”和“擴(kuò)展層”。核心層是必須遵守的硬性規(guī)范比如安全規(guī)范始終加載擴(kuò)展層是特定場(chǎng)景的輔助比如某個(gè)框架的最佳實(shí)踐按需加載。核心層控制在3個(gè)以內(nèi)擴(kuò)展層不超過(guò)5個(gè)。第三條是內(nèi)容壓縮。技能包里的示例代碼可以精簡(jiǎn)檢查清單可以合并行為規(guī)范可以用更緊湊的表述。我把自己寫(xiě)的API技能包從800行壓縮到350行后效果反而更好了——因?yàn)锳I抓重點(diǎn)更容易了。提示定期用npx superpowers stats查看各技能包的token占用情況把占用高但使用頻率低的技能包改為手動(dòng)加載。5.3 團(tuán)隊(duì)協(xié)作中的技能包版本管理個(gè)人使用superpowers相對(duì)簡(jiǎn)單但團(tuán)隊(duì)協(xié)作時(shí)會(huì)遇到“我的技能包和你的沖突”的問(wèn)題。我們團(tuán)隊(duì)摸索出了一套還算好用的管理方式。首先技能包按“個(gè)人技能”和“團(tuán)隊(duì)技能”分目錄存放。個(gè)人技能放在.superpowers/skills/personal/下加入.gitignore不提交團(tuán)隊(duì)技能放在.superpowers/skills/team/下提交到倉(cāng)庫(kù)共享。加載時(shí)個(gè)人技能優(yōu)先級(jí)高于團(tuán)隊(duì)技能這樣每個(gè)人可以在團(tuán)隊(duì)規(guī)范的基礎(chǔ)上加自己的偏好。其次團(tuán)隊(duì)技能包必須走Code Review流程。我們規(guī)定任何對(duì)team/目錄下技能包的修改都要像改代碼一樣提PR至少一個(gè)人審核通過(guò)才能合并。審核的重點(diǎn)是觸發(fā)條件是否清晰、行為規(guī)范是否可執(zhí)行、是否與其他技能沖突。最后技能包要打版本標(biāo)簽。我們?cè)诿總€(gè)技能包的frontmatter里加了version字段重大變更時(shí)遞增版本號(hào)。這樣當(dāng)某個(gè)技能包更新后導(dǎo)致AI行為異常時(shí)可以快速回滾到上一個(gè)版本。6. 進(jìn)階玩法把superpowers變成你的“第二大腦”6.1 從技能包到知識(shí)庫(kù)的擴(kuò)展路徑技能包解決的是“怎么做”的問(wèn)題但很多時(shí)候AI還需要知道“是什么”——比如你項(xiàng)目的業(yè)務(wù)規(guī)則、領(lǐng)域術(shù)語(yǔ)、歷史決策。這些內(nèi)容可以做成“知識(shí)庫(kù)技能包”和操作型技能包配合使用。知識(shí)庫(kù)技能包的寫(xiě)法不太一樣它不強(qiáng)調(diào)流程和檢查清單而是用結(jié)構(gòu)化的方式組織領(lǐng)域知識(shí)。比如我們項(xiàng)目有一個(gè)“訂單狀態(tài)機(jī)”知識(shí)庫(kù)技能包里面定義了所有訂單狀態(tài)、狀態(tài)流轉(zhuǎn)規(guī)則、每個(gè)流轉(zhuǎn)的觸發(fā)條件。當(dāng)AI需要修改訂單相關(guān)代碼時(shí)這個(gè)知識(shí)庫(kù)技能包會(huì)被加載確保它不會(huì)寫(xiě)出違反狀態(tài)機(jī)的代碼。這種玩法的價(jià)值在于把散落在文檔、注釋、老員工腦子里的領(lǐng)域知識(shí)變成AI可以隨時(shí)調(diào)用的結(jié)構(gòu)化上下文。我現(xiàn)在的習(xí)慣是每當(dāng)我發(fā)現(xiàn)自己在重復(fù)向AI解釋同一個(gè)業(yè)務(wù)概念時(shí)就把它寫(xiě)進(jìn)知識(shí)庫(kù)技能包。6.2 技能組合與工作流編排的實(shí)戰(zhàn)案例單個(gè)技能包解決單點(diǎn)問(wèn)題多個(gè)技能包組合起來(lái)就能解決復(fù)雜問(wèn)題。我分享一個(gè)實(shí)際的工作流編排案例從需求到上線的完整流程。這個(gè)工作流包含五個(gè)技能包按順序執(zhí)行需求分析技能把模糊的需求拆解成具體的功能點(diǎn)和驗(yàn)收標(biāo)準(zhǔn)接口設(shè)計(jì)技能根據(jù)功能點(diǎn)設(shè)計(jì)API接口輸出接口文檔TDD實(shí)現(xiàn)技能按測(cè)試驅(qū)動(dòng)的方式實(shí)現(xiàn)每個(gè)接口代碼審查技能對(duì)實(shí)現(xiàn)代碼進(jìn)行安全性和正確性審查文檔生成技能根據(jù)代碼和接口文檔生成用戶手冊(cè)每個(gè)技能包的輸出是下一個(gè)技能包的輸入形成一個(gè)流水線。我實(shí)測(cè)下來(lái)一個(gè)中等復(fù)雜度的功能模塊大約10個(gè)接口用這個(gè)工作流從需求到可提交代碼大約需要2-3小時(shí)而傳統(tǒng)方式至少需要一天。當(dāng)然這個(gè)工作流不是全自動(dòng)的每個(gè)環(huán)節(jié)之間需要人工確認(rèn)。但AI承擔(dān)了80%的重復(fù)性工作人只需要做判斷和決策。6.3 性能監(jiān)控與持續(xù)優(yōu)化建議superpowers用久了技能包會(huì)越來(lái)越多效果可能會(huì)下降。我建議每個(gè)月做一次“技能包體檢”檢查三個(gè)指標(biāo)觸發(fā)準(zhǔn)確率技能被正確觸發(fā)的次數(shù)除以總觸發(fā)次數(shù)。低于80%說(shuō)明觸發(fā)詞需要調(diào)整。行為符合率AI按技能規(guī)范執(zhí)行的次數(shù)除以觸發(fā)次數(shù)。低于70%說(shuō)明技能內(nèi)容需要精簡(jiǎn)或明確。沖突發(fā)生率多個(gè)技能同時(shí)觸發(fā)導(dǎo)致行為異常的頻率。高于10%說(shuō)明需要調(diào)整優(yōu)先級(jí)或合并技能。這些數(shù)據(jù)可以從.superpowers/logs/目錄下的運(yùn)行日志里提取。我寫(xiě)了一個(gè)簡(jiǎn)單的分析腳本每月跑一次把低于閾值的技能包標(biāo)記出來(lái)重點(diǎn)優(yōu)化。最后分享一個(gè)我個(gè)人的使用習(xí)慣我會(huì)把每次踩坑的教訓(xùn)直接寫(xiě)進(jìn)對(duì)應(yīng)技能包的“禁止行為”部分。比如有一次AI在重構(gòu)時(shí)把公共方法刪了導(dǎo)致其他模塊報(bào)錯(cuò)我就在重構(gòu)技能包里加了一條“禁止刪除被其他文件引用的公共方法”。技能包不是寫(xiě)一次就完事的它應(yīng)該隨著你的使用不斷進(jìn)化越用越順手。