剛接觸 Claude Code 的人很容易遇到一個瓶頸單輪對話里讓它寫個小函數(shù)沒問題一旦任務(wù)變成要做一個完整功能、要改十幾個文件它的表現(xiàn)就開始飄忽。一會思路清晰給你列一二三四一會又在一個小 bug 上原地打轉(zhuǎn)。superpowers 這個名字中二感十足但它解決的正巧是這個問題——它把 Claude 的思維方式結(jié)構(gòu)化等于給模型配了一套工地級別的施工流程。這篇文章不會去復述官方 README而是以我實際使用兩個月、踩過不少坑之后的視角把 superpowers 到底是什么、具體有哪幾個 skills、怎么裝、怎么引入、以及實戰(zhàn)效果如何一次性講清楚。1. 先說結(jié)論superpowers 實際解決的是Claude 越用越亂的問題1.1 它不是一個代碼庫而是一套行為說明書集合第一次看到這個項目的人十有八九以為它是個工具鏈或函數(shù)庫。實際上 superpowers 是一個基于 Claude Code 插機制分發(fā)的能力包里頭的核心資產(chǎn)不是代碼而是一批 Markdown 格式的SKILL.md文件。Claude Code 在對話過程中讀到這些文件之后會改變自己的行為方式遇到復雜需求時先問清楚邊界動手之前先寫方案執(zhí)行計劃時一次只做一個小任務(wù)出錯之后按固定套路定位問題而不是無頭蒼蠅一樣亂改。用一句話概括它把臨時抱佛腳地使用 AI 編程變成了按施工圖干活。我在沒有安裝它之前給 Claude 布置一個跨文件改造任務(wù)經(jīng)常要反復補充上下文甚至中途因為對話太長、上下文窗口被各種試探性操作塞滿最后只能新開對話從頭講一遍。superpowers 的思路是讓 Claude 在動手前就把方案固化成一個可審查的文檔執(zhí)行時嚴格照著文檔走這樣就算對話被迫切斷新對話也能基于計劃文件快速續(xù)上。1.2 你需要重新看待技能這個概念很多用過 ChatGPT 或 Gemini 的人對技能的理解是像 App 一樣裝一個插件然后多出一個功能按鈕。superpowers 里的 skills 完全不是這種形態(tài)。它更像是給 Claude 的一份崗位工作手冊Claude 會在恰當?shù)臅r機主動閱讀這些手冊然后按照手冊里的流程來組織自己的思考過程。舉個例子我讓它幫我 brainstorm 一下這個 CLI 工具的命令參數(shù)設(shè)計它會先加載 brainstorming 這個 skill然后做一個我之前沒想到的動作——先不急著給方案而是反問我這個工具面向誰、一次性使用還是長期維護、出錯時的容忍度如何。這些追問并不是隨機生成的而是 SKILL.md 里明確要求它做的。換句話說superpowers 不是給 Claude 增加新功能而是給 Claude 增加新規(guī)矩。這也是它最容易被誤解的地方你以為裝了一個工具包實際上你裝了一套質(zhì)檢流程。1.3 什么樣的人值得裝如果你只是偶爾讓 Claude 寫個正則表達式、轉(zhuǎn)個數(shù)據(jù)格式、問點 API 用法superpowers 對你來說可能感知很弱。但如果你符合下面任意一條我建議你認真考慮日常用 Claude Code 寫完整功能模塊一個任務(wù)涉及五六個文件以上需要它做代碼重構(gòu)、跨模塊改造又擔心改壞原有邏輯經(jīng)常遇到 Claude 在長對話中失憶——前面定的方案執(zhí)行到一半被它悄悄改掉了希望 AI 不僅產(chǎn)出代碼還能在動手前與你對齊設(shè)計決策團隊里有人用 Claude Code 協(xié)作同一個倉庫需要留下可追溯的計劃和痕跡我屬于前三條全中的重度用戶。安裝后最大的感受是Claude 從一個聰明但毛躁的實習生變成了一個雖然沒那么快但每一步都先匯報、先確認、留記錄的可靠同事。代價是對話變啰嗦了、執(zhí)行變慢了但返工率顯著降低這筆賬怎么算都劃算。2. 拆包看貨這套技能包到底裝了哪些 skills2.1 核心目錄結(jié)構(gòu)速覽superpowers 的倉庫里有一個skills目錄下面每個子目錄對應(yīng)一個獨立技能。每個技能目錄內(nèi)部必有一個SKILL.md里面寫著觸發(fā)場景、工作流程、輸入輸出格式、注意事項。以當前倉庫版本為例我實際使用中真正發(fā)揮作用的主要有這幾個技能名稱英文標識核心用途我給它打的標簽頭腦風暴brainstorming需求澄清、方案生成、多方案對比動工之前先用它制定計劃writing-plans將方案落地為分步驟可執(zhí)行計劃方案與代碼之間的橋梁執(zhí)行計劃executing-plans按計劃推進逐項驗證避免跑偏大任務(wù)的軌道系統(tǒng)化調(diào)試systematic-debugging用結(jié)構(gòu)化流程排查 bug根因分析救火隊員代碼審查code-review對修改過的代碼按標準做評審合并前的最后一道閘測試驅(qū)動開發(fā)TDD先寫失敗測試、再寫實現(xiàn)、再重構(gòu)需要紀律時啟用還有一些輔助類技能我沒有全部列出來它們發(fā)揮作用的頻率因人而異。核心邏輯是superpowers 不試圖讓 Claude知道更多而是讓 Claude更有條理地使用它已經(jīng)知道的東西。2.2 幾個主力技能的觸發(fā)時機與行為差異brainstorming是我最常主動調(diào)用的技能之一。它適合在任務(wù)描述還不清晰的時候使用典型觸發(fā)話術(shù)是use the brainstorming skill to help me think through this。加載之后Claude 會要求我補充背景信息然后給出多個方案而不是直接選一個。它甚至會在方案后面附上每個方案的適用場景和代價逼著我想清楚自己到底想要什么。writing-plans則會做一件讓傳統(tǒng)編程者非常舒服的事把方案變成一份帶檢查點的任務(wù)清單。正確的用法不是讓 Claude 自己把方案生成完就直接執(zhí)行而是你在對話里確認方案沒問題之后再讓它 write a plan。生成的計劃文件會對齊方案中的每個環(huán)節(jié)拆成若干個一次只做一件的小任務(wù)并注明驗收標準。executing-plans是讓本來容易失控的長任務(wù)保持穩(wěn)定的關(guān)鍵。它讀取已有的計劃文件一個任務(wù)一個任務(wù)地往下執(zhí)行每一步做完都會標記完成狀態(tài)而不是一口氣把所有代碼寫出來。這非常像我們平時用項目管理軟件拆解任務(wù)的感覺只不過干活的是 AI。2.3 怎么查看當前到底有哪些 skills裝完插件之后很多人會困惑技能都在哪。最直接的辦法是打開倉庫目錄看如果是通過 Claude Code 插件市場安裝的可以在~/.claude/plugins下面的對應(yīng)目錄里找到 SKILL.md 文件如果你是手動 clone 到項目里的通常就在項目的.claude/skills目錄下。這些目錄里躺著所有技能說明書完全可以打開當操作手冊讀。另外在實際對話中你還可以直接問 Claude 本身它可以列出當前可用的技能并說明用途因為它能讀取到這些目錄。我習慣在新項目開始時專門問一句你現(xiàn)在可以用哪些技能分別什么時候用讓 Claude 自己復述一遍。這個做法一方面能讓我確認安裝是否生效另一方面能讓 Claude 在后續(xù)對話里更自覺地調(diào)用它們——因為它知道我知道它有什么工具。3. 安裝與引入從零到能跑起來的最短路徑3.1 方式一通過 Claude Code 插件市場安裝如果你用的是較新版本的 Claude Code最省事的路徑是使用插件市場命令。我當時的安裝過程非常順利全程兩條命令/plugin marketplace add obra/superpowers /plugin install superpowerssuperpowers第一條命令把作者的倉庫注冊為插件市場來源第二條命令從該市場安裝 superpowers 插件。執(zhí)行完之后Claude Code 會提示插件已啟用。這里有一個容易忽略的細節(jié)啟用插件之后需要重啟當前會話或者至少讓 Claude 重新掃描插件目錄否則它可能不會立刻意識到自己已經(jīng)掌握了新技能。如果你的 Claude Code 版本還沒有內(nèi)置插件市場命令也可以直接手動安裝。原理非常簡單先 clone 倉庫再把倉庫里的skills目錄鏈接到 Claude Code 的配置目錄下git clone https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers然后在 Claude Code 的配置文件通常是~/.claude/settings.json里確保插件目錄被加載。不同版本字段略有差異但思路一致讓它能讀到這個目錄下的SKILL.md文件。我自己的經(jīng)驗是手動安裝沒有太多技術(shù)難度但每次更新比較麻煩所以后來還是切回了插件市場方式。3.2 方式二把 skills 放進具體項目里還有第三種更輕量的方案只把需要的技能塞進單個項目。Claude Code 支持項目級技能目錄也就是項目根目錄下的.claude/skills/里面的技能只在該項目對話中生效。如果你手頭已有某個技能的 SKILL.md直接復制到這個目錄里就行。這種做法適合不想全局引入、只想在某個特定倉庫里試驗的情況。比如我在公司一個多人協(xié)作的倉庫里就沒有全局開啟 superpowers因為擔心行為變化會影響同事的日常提交風格只在個人項目里全局使用。項目級引入的另一個好處是可以和團隊約定項目內(nèi)統(tǒng)一的技能目錄大家共享同一套工作流這比每人都改全局配置要干凈得多。3.3 安裝完成后的第一件事確認技能確實生效了裝完別急著開工先做一個冒煙測試。我的做法是新開一個 Claude Code 會話輸入一句很簡單但能觸發(fā)技能的話比如use the brainstorming skill to help me decide between a CLI tool and a web UI for a small internal dashboard觀察 Claude 的反應(yīng)。如果它開始讀文件、然后反過來追問我需求細節(jié)說明技能生效了。如果它只是像平時一樣直接給結(jié)論那八成是加載失敗或者沒有匹配到技能觸發(fā)條件。順帶一提Claude 在調(diào)用某個技能后通常會在回復里明確提到我已經(jīng)讀取了 brainstorming 技能或者類似的話這是最直觀的生效標志。提示不要一上來就讓 Claude全程使用所有技能。superpowers 里的每一個 skill 都有明確的適用場景強制全部用反而會讓簡單任務(wù)變得臃腫。我見過有人為了體驗技能讓 Claude 給一個純展示網(wǎng)頁先寫三頁技術(shù)方案完全是殺雞用牛刀。4. 實戰(zhàn)記錄用 superpowers 從零完成一個小工具文字介紹再多不如跑一遍真實流程來得直觀。下面我用最近做的一個實際任務(wù)來拆解寫一個 Python 批量重命名工具要求支持名字映射規(guī)則、預覽模式、操作日志回滾。這個任務(wù)不算大但足夠展示整套技能的協(xié)同方式。4.1 第一階段用 brainstorming 把需求邊界釘死一開始我的需求描述非常含糊寫個腳本批量改名要安全。如果直接讓 Claude 寫它大概率會產(chǎn)生一個看起來能用、但邊界一塌糊涂的版本。這次我明確要求它先加載 brainstorming。Claude 果然沒有直接寫代碼而是先問了幾個關(guān)鍵問題重命名規(guī)則是簡單替換還是正則匹配是否需要處理文件名沖突預覽模式需要展示到什么粒度安全具體指什么——是防止覆蓋還是要能回滾這些問題看似普通但現(xiàn)在回看它們?nèi)荚诤罄m(xù)開發(fā)中成了分水嶺如果沒問是否處理文件名沖突生成的腳本大概率會直接覆蓋同名文件如果沒問預覽粒度用戶可能只能看到新舊文件名列表看不到具體差異。brainstorming 的價值在于它把我在需求階段懶得多想的問題全部給撈了出來。這一輪下來我們確認了三個方案純 Python 腳本、Python dry-run 參數(shù)、以及帶變更日志的進階版。Claude 甚至給了每個方案的推薦場景。4.2 第二階段writing-plans 把方案變成施工圖需求確認后我讓它基于選定方案寫計劃。關(guān)鍵一步在這里計劃必須寫成獨立文件而不是只存在于對話里。我讓 Claude 調(diào)用writing-plans技能生成一份計劃并且明確要求它保存成文件之后執(zhí)行階段再調(diào)出來。生成的計劃結(jié)構(gòu)大致如下# 批量重命名工具實施計劃 ## 目標 - 支持前綴/后綴添加、指定字符串替換兩種規(guī)則 - 支持 dry-run 預覽 - 記錄變更日志支持按日志回滾 ## 任務(wù)清單 1. 搭建項目結(jié)構(gòu)與入口模塊 - 創(chuàng)建 main.py定義命令行參數(shù) - 驗收python main.py --help 能列出所有參數(shù) 2. 實現(xiàn)映射規(guī)則引擎 - 規(guī)則數(shù)據(jù)結(jié)構(gòu)定義與解析 - 驗收單元測試覆蓋替換與前后綴規(guī)則 3. 實現(xiàn) dry-run 預覽 - 輸出 舊名字 - 新名字 對照表 - 驗收執(zhí)行 dry-run 不實際改動文件系統(tǒng) 4. 實現(xiàn)實際重命名與沖突檢測 - 沖突時跳過并提示 - 驗收兩個文件映射到同一新名字時只保留第一個 5. 實現(xiàn)日志記錄與回滾 - 記錄到 rename_log.json - 驗收根據(jù)日志能還原原文件名這份計劃的每一個條目都帶著明確的驗收標準。我覺得這比讓 Claude 一口氣生成代碼重要的多因為驗收標準意味著 Claude 在執(zhí)行時知道自己做到什么程度才算完成而不是自己覺得差不多就收手。4.3 第三階段executing-plans 按圖施工執(zhí)行計劃時我直接告訴 Claude讀取之前的計劃文件并開始執(zhí)行。它做了幾個我特別滿意的動作第一步是重讀了計劃全文然后開始一個任務(wù)一個任務(wù)地推進每完成一個小任務(wù)就用簡短的話報告進度并且對照驗收標準自檢。在實現(xiàn)映射規(guī)則引擎時它還主動補寫了幾個針對邊界情況的單元測試比如空字符串替換、正則特殊字符轉(zhuǎn)義、超長文件名沖突。這讓我很意外因為我并沒有要求它寫測試但它從計劃里的驗收單元測試覆蓋讀到了隱含要求于是自作主張把測試補上了。這種按圖施工但不機械照搬的表現(xiàn)正是技能文檔和模型能力結(jié)合得好的結(jié)果。4.4 第四階段systematic-debugging 收拾爛攤子當然計劃再周密也會出問題。實際跑起來的時候回滾功能在 Windows 路徑上出了 bug日志記錄的是絕對路徑但文件名含有特殊字符時 JSON 反序列化報錯。我沒有直接告訴 Claude 怎么改而是讓它走一遍systematic-debugging流程。令人欣慰的是它沒有上來就大改代碼而是先復現(xiàn)問題、縮小范圍、提了一個臨時加日志的命令讓我?guī)兔ε茏罱K定位到問題根源是json.load時對反斜杠的轉(zhuǎn)義處理不當而不是回滾邏輯本身出錯。整個過程大約 15 分鐘比我在 Stack Overflow 上翻答案再手動驗證的方案快得多。更關(guān)鍵的是它最后在代碼注釋里寫了根因說明避免后人再踩一遍。4.5 實戰(zhàn)體驗總結(jié)三個最直觀的變化反復橫跳明顯減少。以前 Claude 可能在方案 A 和方案 B 之間自動切換現(xiàn)在它只按計劃執(zhí)行計劃外的想法會先提出來征求我的意見而不是自己悄悄改變方向。驗收標準缺位的場景變少。它每完成一個小任務(wù)會自己對照驗收標準檢查很多時候不用我再特意說你測一下。對話中斷可恢復。計劃文件獨立存在即使中途新開對話也能讓新會話讀計劃文件繼續(xù)執(zhí)行不用重新解釋需求。這一點在公司里交接給同事新開對話時尤其好用。5. 用了一段時間后的體會和踩坑清單5.1 最大的坑計劃文件堆積成山superpowers 的流程天然會產(chǎn)生計劃文件、進度標記、變更日志。我第一個項目跑完項目目錄里多了至少五個 markdown 文件——計劃、子計劃、執(zhí)行狀態(tài)、復盤。這些文件對長期項目來說是好東西但對一次性小工具來說就是噪音。我的做法是給一次性的小實驗單獨建臨時目錄跑完直接刪掉整個目錄只有真正要持續(xù)維護的功能才放項目根目錄下保存計劃。如果你用 git 管理項目記得把這類自動生成的計劃文件納入版本決策不要一股腦提交否則每個 Pull Request 里都混著一堆計劃 markdownreviewer 會抓狂。5.2 不是所有任務(wù)都值得走完整流程superpowers 讓我最猶豫的地方在于它有些過度工程化的傾向。現(xiàn)在我對任務(wù)做分級處理改動一個文件以內(nèi)的簡單改動直接讓 Claude 改不調(diào)任何技能一個功能模塊邏輯清晰但沒有太多歧義讓它寫計劃但不強制 brainstorming跨文件、或者需求本身還不清晰的任務(wù)完整走 brainstorming → writing-plans → executing-plans如果不分級讓一個改 README typo 的任務(wù)也先來一輪頭腦風暴體驗會非常糟糕。技能是給人用的不是給人表演的把它當錘子不代表所有東西都是釘子。5.3 與自定義系統(tǒng)指令的配合方式如果你在 Claude Code 里已經(jīng)有自定義的系統(tǒng)指令或項目約定的 CLAUDE.me 文件注意它們和 superpowers 可能產(chǎn)生指令沖突。我一開始的項目說明里寫了一句盡量直接給出代碼不要解釋結(jié)果與 brainstorming 技能要求的先問問題再給方案直接打架導致 Claude 行為變得飄忽不定。后來我把系統(tǒng)指令改成了與技能兼容的表述把直接給代碼調(diào)整為對于簡單明確的任務(wù)可以直接給代碼對于復雜任務(wù)先按可用技能流程處理?，F(xiàn)在兩者基本能協(xié)同工作不再互相拆臺。注意如果你發(fā)現(xiàn)安裝 superpowers 之后 Claude 的行為和預期不一致先別卸載檢查一下是不是自己的系統(tǒng)指令在跟技能文檔搶方向盤。技能可以通過自然語言說得更具體這次不要用 brainstorming直接按你的理解寫計劃。5.4 更新和升級的節(jié)奏作為第三方插件superpowers 的更新頻率并不低核心技能的流程說明時不時會有調(diào)整。我出現(xiàn)過一次問題版本升級后舊計劃文件里引用了舊的技能行為描述執(zhí)行時 Claude 按新版技能流程處理結(jié)果和計劃文件里的舊標記格式對不上。我的經(jīng)驗是升級插件后不要立刻啟動大任務(wù)先跑一個 10 分鐘內(nèi)的小任務(wù)試探一下行為變化跨版本更新的情況更建議舊項目繼續(xù)使用舊計劃文件新項目再體驗新流程。盲目追求最新版本沒有必要穩(wěn)定執(zhí)行比新特性重要得多。5.5 關(guān)于agent 到底有沒有變聰明的最誠實觀察最后說一點可能和很多人預期不符的體會。superpowers 沒有讓 Claude 變得更聰明也沒有增加我不知道的新能力它甚至讓對話變得更笨——開場總是問東問西執(zhí)行總是拆得碎碎的節(jié)奏明顯變慢。但它的確讓最后交付質(zhì)量提高了。原因也很簡單復雜任務(wù)翻車通常不是因為模型不夠聰明而是目標沒對齊、約束沒人記錄、方案在中途悄悄漂移。superpowers 提供的全部內(nèi)容本質(zhì)上是給這些軟性問題裝上護欄。對于自己寫代碼超過十年、習慣先設(shè)計再動手的人來說這套流程非常自然幾乎不需要適應(yīng)如果你本身是先跑起來再說的風格那你會覺得它極其啰嗦。我在實際使用中逐漸接受了一種觀念讓 AI 干活和帶人干活是一樣的你越是把流程說清楚結(jié)果就越可控superpowers 只是把這件事工業(yè)化了而已。