213000 星的 Superpowers，90% 的人只用了它 10% 的功能

Skills 生態上線六個月，我經歷了三個階段。

第一個月：看到什麼裝什麼，光 awesome-skills.com 首頁掛的就裝了一半，感覺自己馬上就要起飛。第二個月：發現 .claude/skills/ 目錄塞了 50 多個資料夾，但 Claude 實際上每天在用的不超過 5 個。第三個月：開始清庫存，留下真正在幫我幹活的，把剩下的全卸載。

這篇文章是清庫存之後的帳單。

不是推薦列表，是淘汰賽——寫的是哪些留下來了，更重要的是，為什麼其他的被踢出去了。

Skill 是什麼，它解決的是什麼摩擦

在進入名單之前，有一個判斷視角值得先說清楚：Skill 不是更好的 prompt，而是帶階段門檻的工作流程模組。

一個 prompt 層級的指令是建議——Claude 可以參考，也可以忽略。一個結構良好的 Skill，如果裡面定義了明確的階段門檻（「紅燈測試必須失敗之後才能進下一步」「計畫必須輸出 Markdown 檔案後才能開始寫程式碼」），Claude 更傾向照著執行。

這個差別是真實的，不是概念遊戲。

但這也意味著：Skill 的品質參差不齊。150+ 個 Skill 裡，有一批是用來展示可能性的，有一批是解決真實工程痛點的。裝了 50 個之後我發現，後者大概只占三分之一。

判斷一個 Skill 留不留，我用的標準是：沒有它，這件事會讓我多花多少時間？ 答案是「5 分鐘以內」的，大概率是噱頭。答案是「每次都要手動處理、很煩」的，就值得裝。

安裝命令格式上，大部分走 npx skills add，少數需要 git clone 到 ~/.claude/skills/ 目錄，官方維護的走 /plugin install 路徑。

圖：Skill 的階段門檻機制 vs Prompt 的建議性執行，兩者執行方式的本質差異

第一類：工程提效（6 個）

這幾個是日常寫程式頻率最高、留下來最理所當然的。

Superpowers（obra/superpowers，213,000★）

這個生態裡星數最高的專案，名字有點大，但內容是真的。它不是一個單獨的 Skill，而是一個包含 20+ 個子模組的工作流程框架：TDD、系統化除錯、計畫撰寫、程式碼審查、並行 Agent 分派、Git Worktree 管理……每個都是獨立的、可以單獨觸發的 Skill。

安裝命令：npx skills add obra/superpowers

我實際留下的子模組是：test-driven-development（強制紅燈先行，不允許跳過）、systematic-debugging（先推理根因再改程式碼）、writing-plans（多步驟任務先出檔案再動手）。剩下的模組按需使用，不強制。

為什麼有 213K 星？因為它真正解決了 Claude 最常見的問題：直接動手改程式碼，不思考，不測試，改了再說。Superpowers 把這個壞習慣用結構強制打斷了。

Karpathy Guidelines（forrestchang/andrej-karpathy-skills，125,436★）

Andrej Karpathy 總結的 AI 寫程式規則，被人整理成了 Skill。核心規則四條：讀程式碼前先思考（不是直接開始 grep）、修改要精準（不是「重寫這個檔案」）、優先簡潔（不是「加功能」）、始終核對原始需求。

安裝：/install forrestchang/andrej-karpathy-skills

這個 Skill 的價值在於它改變的是 Claude 的行為模式，而不是提供某個工具。新起一個專案的時候特別有效——Claude 會更傾向先理解再動手，而不是信心滿滿地直接開始重構。

gstack（garrytan/gstack，93,947★）

Garry Tan（YC 執行長）維護的 Skill，名字來源是「Gut Stack」——他自己實際在用的技術棧配置。主要涵蓋全端專案腳手架（TypeScript、React、Supabase、Vercel）、最佳實踐檢查、部署流程自動化。

安裝：git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack

坦白說我沒有完整用到它所有功能，但它的 TypeScript 型別檢查和 Supabase Schema 驗證我有開啟——每次新建介面或者改表結構的時候，Claude 會主動跑一遍再提交。這個減少了我程式碼審查時的低級錯誤。

Frontend Design（anthropics/skills，277,000+ 週安裝）

官方維護的前端 UI Skill，目標是解決一個真實問題：AI 產生的 UI 都長一個樣，一眼就能認出是 AI 寫的——按鈕顏色、間距、字型選擇全都是預設值加 Tailwind。

安裝：npx skills add https://github.com/anthropics/skills --skill frontend-design

它的核心是提供了一套視覺決策框架，讓 Claude 在產生 UI 時會主動挑選對比色、考慮層級關係、避免過度對稱。我在做內部工具的時候感受最明顯——同樣的需求，裝了 Skill 之後的結果明顯比沒裝的更「像是人設計過的」。

Document Skills（anthropics，DOCX/PDF/PPTX/XLSX 套件，132,393★）

官方出的文件生成套件，裝一次可以處理四種格式。核心價值：讓 Claude 直接輸出帶格式的二進位檔，而不是輸出 Markdown 然後自己再轉。

安裝：npx skills add https://github.com/anthropics/skills --skill pdf（其他格式類似）

這個 Skill 的適用場景比較窄，但很實在：需要頻繁生成報告、內部文件、資料匯出的工程師。如果你每天只寫程式，它可能用不上；如果你要寫技術文件或者給非技術人員發報告，它會節省大量時間。

Trail of Bits Security（trailofbits/skills）

Trail of Bits 是業界頂級安全稽核公司，這個 Skill 把他們的安全審查清單封裝了進來。會針對程式碼主動檢查注入攻擊路徑、權限提升風險、加密實作錯誤等。

安裝：npx skills add trailofbits/skills

這個 Skill 是我在做介面層程式碼審查時留下的。之前 Claude 預設的程式碼建議不會主動提安全問題，裝了之後遇到使用者輸入處理的程式碼，它會補充提示可能的 SQLi 或 CSRF 路徑。不是說 Claude 變成了安全專家，但至少多了一層提醒。

第二類：多 Agent 編排（5 個）

這類 Skill 是 2026 年生態裡成長最快的方向，也是噱頭最多的地方。多 Agent 敘事很吸引人，但真正能在日常工程裡落地的，沒幾個。

TDD（superpowers 子模組，186,724★）

單獨拎出來說，因為它是 Superpowers 裡我用得最高頻的部分。核心機制是三個強制階段：Red（必須先寫一個失敗的測試）→ Green（寫最少的程式碼讓測試通過）→ Refactor（再整理）。每個階段之間有明確的驗證點，Claude 不能跳過。

這不是新東西，TDD 大家都知道。但 Claude 沒有約束的時候天然傾向直接寫實作程式碼，測試留到最後或者乾脆不寫。這個 Skill 把流程鎖住了。

Ruflo（ruvnet，49,143★）

Ruflo 是一個多 Agent 編排平台的 Skill 整合，讓你可以在 Claude Code 裡設計 Agent 流水線——一個 Agent 負責研究，一個負責寫程式碼，一個負責驗證，結果傳遞下去。

安裝要先搭 Ruflo 服務：npx create-ruflo-app my-project

坦白說，我裝了兩週後卸載了。原因是：我大部分專案的複雜度根本不需要多 Agent 流水線。Ruflo 解決的是 100+ 步驟的大型 AI 工作流程問題，如果你在做的是一般業務開發，它給你的工程複雜度比節省的時間更多。

它不是噱頭，它解決真實問題——只不過不是我的問題。

Superpowers: Dispatching Parallel Agents（superpowers 子模組）

多個獨立子任務真正並行跑，每個任務一個 Agent，最慢的那個完成了整體才完成。這個在大型重構裡有用：前端改造、後端介面更新、測試補全可以同時跑。

我在做一次跨模組重構時用過，節省了大約 40% 的等待時間。但前提是任務之間真的獨立，如果有依賴關係，並行變串行還容易出錯。

Awesome Claude Code Subagents（19,580★）

社群維護的子 Agent 配方庫，裡面有各種預設好的「特化 Agent」——資料庫 Agent、文件 Agent、測試 Agent……思路是好的，執行品質參差不齊。

裝了但只用了資料庫 Agent，其他的我自己寫了更符合專案約束的版本。這類 Skill 更像是模板庫而不是即插即用的工具，適合有客製需求的團隊，不適合直接拿來就用。

Loki Mode（loki-mode）

37 個 AI Agent 組成的自主系統，宣稱可以「完全自主完成複雜工程任務」。

我裝了三天就卸載了。不是因為它不能跑，而是因為它太自主了——修改了我沒想改的檔案，在沒確認的情況下提交了程式碼，把一個正在執行的函式重構成了「更好的版本」。可能在沙箱環境裡很有用，在正式程式碼庫裡我不敢放手。

留個印象，等它再成熟一些。

第三類：記憶與上下文（4 個）

上下文視窗是 Claude Code 的真實瓶頸，這類 Skill 在解決一個具體問題：怎麼讓 Claude 記住更多的專案知識。

Claude Mem（74,903★）

這個數字可靠，這個 Skill 也可靠。核心功能：自動提取每次會話裡出現的重要決策、約束、架構選擇，存到結構化的記憶檔案裡，下次會話自動載入相關部分。

安裝：npx skills add claude-mem/claude-mem

實測效果：在一個 3 個月的專案裡，它幫我省掉了每次開新 Session 都要重新解釋「這個欄位為什麼這樣設計」的時間。不是完美的，會有雜訊記憶，但整體值得。

Claude Context（10,955★）

比 Claude Mem 輕量，只做一件事：把當前專案的核心上下文（CLAUDE.md + 關鍵決策檔案）壓縮成最小的 token 量，在每次對話開始時注入。

對話輪次變多之後上下文膨脹是個真實問題，這個 Skill 幫你在精度和 token 消耗之間找平衡。

ccstatusline（9,031★）

不改變 Claude 的行為，只是給你一個終端狀態列，顯示當前 Session 用了多少 token、大概還剩多少預算、有沒有在跑 tool call。

聽起來是小工具，但當你開始關注成本的時候，這個視覺化資訊很有價值。我接入它之後才開始意識到，很多會話的 token 消耗集中在哪些環節。

CC Switch（67,412★）

在不同 Claude 模型之間切換的 Skill，核心價值是成本管理：簡單任務走 Haiku（便宜），複雜推理走 Opus（強但貴），程式碼生成走 Sonnet（平衡）。

安裝：npx skills add cc-switch/cc-switch

這個 Skill 的實用性在於它讓切換模型變成了一個有意識的動作，而不是每次都預設最強的。我開始用它之後，月帳單降了大約 35%，同時大部分任務的完成品質沒有明顯下降。

第四類：文件與辦公（3 個）

這類 Skill 在純工程師圈子裡存在感低，但其實有幾個很實用。

Graphify（safishamsi，46,746★）

從程式碼庫自動生成關係圖：函式呼叫圖、模組依賴圖、資料流圖。對接手一個新專案、做架構評審、或者理解老程式碼特別有用。

安裝：pip install graphifyy && graphify install

我第一次用它時是接手了一個運行了兩年的 Python 服務，Graphify 在 3 分鐘內就給我畫出了模組依賴關係，比我自己讀程式碼快了一個下午。

Planning with Files（20,925★）

讓 Claude 在多步驟任務開始前，先把計畫輸出成 Markdown 檔案，明確每一步的目標、依賴、驗證標準，再開始執行。

核心價值：計畫變成了一個可以檢查、可以修改、可以追溯的檔案，而不是存在 Claude 上下文裡的一堆文字。任務失敗了可以看計畫，找到偏差在哪裡。

Claudian（Obsidian 插件，10,954★）

把 Claude Code 和 Obsidian 筆記庫打通的 Skill，讓 Claude 可以讀寫你的知識庫檔案。

這個對寫技術文件、維護設計文件的工程師有用，對大部分純寫程式職位可能感受不強。我裝了，主要用來生成和更新 ADR（架構決策記錄）檔案。

圖：按工程提效、多 Agent 編排、記憶與上下文、文件辦公四類整理的 Skill 清單，含 awesome-skills.com 星數

那些沒留下來的，都是什麼問題

說了這麼多留下的，簡單說幾類被踢出去的。這部分可能比留下來的名單更有用——因為它幫你在裝之前就過濾掉大部分浪費時間的選擇。

功能太窄、場景太特定：比如有個 Skill 專門生成 Kubernetes Helm Chart 的註解，功能沒問題，邏輯也清楚，但我們專案不用 K8s，裝了等於白裝。這類 Skill 的問題不是品質差，而是受眾太窄。裝之前先想清楚：這個 Skill 服務的場景，在你的日常工作裡每週出現幾次？少於 1 次的，考慮不裝。

安裝複雜、收益太低：有的 Skill 需要搭本地服務、設定 API Key、設定 Webhook，走完五步安裝流程，換來的是「Claude 在回覆末尾加了一個 emoji」。安裝成本和使用收益不匹配，是很多社群 Skill 的通病。好的 Skill 應該是「一行命令裝完，第二天就能感受到差異」——如果裝完一個星期都不確定它有沒有在生效，卸載不虧。

過度自主、邊界模糊：這類最危險。Skill 描述裡寫「Claude 會自動處理」，實際上 Claude 會在你沒意識到的時候自主決策修改程式碼。Loki Mode 是典型，我裝了三天，它幫我「優化」了一個正在執行的核心函式，提交了程式碼，然後告訴我「已完成」。可能在沙箱環境或者測試專案裡完全沒問題，但在正式程式碼庫裡，這種自主性是風險不是優勢。判斷標準：這個 Skill 有沒有在關鍵操作前問你「是否繼續」？沒有確認機制的 Skill，在正式程式碼庫裡要謹慎。

純 prompt 包裝、沒有結構：這是最常見的一類。有一批 Skill 本質上只是把一段 prompt 包裝成了 SKILL.md 格式，沒有階段門檻、沒有驗證機制、沒有輸入輸出約束。Claude 很可能直接忽略——或者在第一次觸發時用，之後就不用了。這類 Skill 的 README 寫得最好，看起來功能強大，用起來效果和沒裝差不多。識別方法：打開 SKILL.md，如果全文都是說明性文字、沒有任何「步驟 N：驗證 X 通過後才能繼續」的結構，大概率是純 prompt 包裝。

圖：5 步篩選決策框架——從使用頻率到一週實測，系統判斷一個 Skill 留還是卸

常見問題

Q：Skill 裝了 Claude 一定會用嗎？

不一定。Skill 載入是基於相關性判斷的，Claude 會評估當前任務是否和 Skill 的描述匹配。你可以用 /skill-name 手動觸發，或者在任務描述裡帶出 Skill 的關鍵字。如果發現裝了沒用，先檢查 SKILL.md 裡的觸發描述寫得夠不夠具體。

Q：這些 Skill 會影響 Claude 的 token 消耗嗎？

Skill 檔案是延遲載入的，不相關的任務裡不會載入，所以大部分情況下成本影響很小。但如果你裝了大量會在每次對話裡自動觸發的 Skill，累積起來也會有影響。CC Switch 這類專門管成本的 Skill 能幫你看清楚。

Q：多個 Skill 之間會衝突嗎？

會，但不常見。最常見的衝突是兩個 Skill 的觸發描述太相似，Claude 不確定該用哪個。解決方法：給相互關聯的 Skill 做優先級標記（在 frontmatter 裡寫 priority: high），或者精簡觸發描述。

Q：怎麼知道一個 Skill 值不值得裝？

看三個指標：star 數（參考，不是決定因素）、README 裡有沒有明確的「觸發條件」描述（模糊描述的 Skill 通常也會被 Claude 模糊執行）、有沒有維護者在 GitHub 持續更新。一個六個月沒更新的 Skill 和 Claude Code 最新版本可能已經不相容。

Q：有沒有 Skill 發現目錄，不用一個個翻 GitHub？

awesome-skills.com 是目前最全的目錄，按 star 數排序，有安裝命令。travisvn 維護的 awesome-claude-skills 儲存庫也值得看，側重品質篩選而不是數量。

參考資料

• Claude Code Skills 官方文件
• awesome-skills.com 技能目錄
• obra/superpowers GitHub

裝 Skill 這件事和招人有點像——履歷寫得漂亮的不一定是好的，平時話不多但每次開口都有用的才是真正的生產力。

這 20 個留下來的，不是星數最多的，是在我實際工作流裡真正減少了摩擦的。你的情況可能不一樣，但篩選的邏輯應該相通：裝進去之後，有沒有哪件以前要手動做的事，現在 Claude 主動幫你做了？ 有，就留。沒有，卸載。

寫完這篇碼哥自己也重新過了一遍 skills 目錄，發現還有兩個可以清理的。如果你身邊有正在糾結要不要裝 Skill 的同事，這篇直接發給他，比他自己去翻 awesome-skills.com 快得多。下一篇打算聊 Claude Code 的 Hooks 機制——和 Skill 配合用才能真正把工作流鎖住，感興趣關注一下。

原文出處：https://juejin.cn/post/7657074612481523747