給 AI 超能力：Superpowers Skill 入門
如果你用過 AI 寫程式碼，大概都遇過這種情況：
你講一長串需求，AI 興致勃勃說「好，我寫好了」，結果一跑——根本不能用，或者修一個 bug 又製造三個新的 bug。AI 看起來很聰明，但總給人一種：技術很強，態度很隨便 的感覺。
Superpowers 這套東西，就是專門來治 AI 這個「沒紀律的天才」的。
Superpowers 是什麼？不是程式碼庫，是「AI 員工手冊」
很多人第一眼以為 Superpowers 是一個框架或套件，其實不是。
它更像是一本寫給 AI Agent 的 「員工手冊」，告訴它：在不同階段，必須按什麼流程做事。
它放在 GitHub 上，有單獨的 skills 倉庫
superpowers-skills，裡面是一份份 Markdown 文件。每一份文件叫一個 Skill，描述「在某種情境下，你（AI）必須怎麼做」。
再配合 Claude Code 的外掛，把這些規則接到 AI 的日常對話和寫碼流程裡。
一句話：
Superpowers 用一堆 skills，把 AI 從「會寫程式的實習生」，訓練成「有職業素養的工程師」。
核心概念：用 15 個 Skills，管住 AI 的開發流程
作者把完整的軟體開發流程拆成一系列技能：從「先問清楚需求」到「最後合併分支」，每一步都有對應的 skill 來約束 AI。
你可以想像一條典型流程大概是這樣：
brainstorming：先問清楚需求，設計方案。writing-plans：寫一份「傻瓜也能照做」的執行計畫。test-driven-development：嚴格 TDD，先寫測試，再寫程式碼。systematic-debugging：出 bug 時，禁止亂猜，只能按步驟查根因。subagent-driven-development：交給子代理寫程式碼＋做雙重 code review。verification-before-completion：任何「完成了」的宣稱之前，必須先跑驗證。receiving-code-review、writing-skills等負責審查、寫新 skill 的規則。
下面挑幾條最有趣、對非工程師也看得懂的 skill 來講。
Skill 示例一：brainstorming —— AI 先當個好提問者
痛點：
AI 很愛「沒問完就開寫」，結果寫錯方向，你改來改去，還不如自己寫。
brainstorming 這個 skill 強制 AI 在動手前，必須先用「蘇格拉底式提問」把需求問清楚：
一次只問一個問題，不准一口氣丟十個。
能用選擇題就不用開放式問題。
設計方案要分段寫，每段結束都要問你「這樣對嗎？」再繼續。
想像一個對話：
你：我要做一個「會議記錄自動整理」的小工具。
AI（用 brainstorming skill）：
你習慣用哪種工具開會錄音？（Zoom 錄音 / 語音檔上傳 / 文字逐字稿）
你要輸出的是「條列重點」還是「完整摘要」？
這個工具是你自己用，還是整個團隊都會用？
…
問完一輪，它再寫一份 200～300 字的小設計書，最後問你：
「以上理解是否正確？如果有誤，請指出，我會重新修正設計。」
這一步看起來慢，實際上幫你省掉大量「做了才發現方向錯了」的返工。
Skill 示例二：writing-plans —— 假設執行者「什麼都不懂」
writing-plans 是很多人看了會驚呼「也太囉嗦了吧」的 skill。
它有一個很殘酷的前提：
假設執行這份計畫的人：
對專案一無所知
品味普通
不喜歡寫測試
所以計畫必須寫到「連這樣的人照做也不會出大事」。
這份 plan 會怎麼寫？大概是這種感覺：
每個步驟只做一件事，2～5 分鐘能完成。
不准寫「加上適當的測試」，要寫出完整測試程式碼和檔案路徑。
不准寫「跑一下測試」，要寫出具體指令（例如
npm test）和預期輸出長什麼樣。
舉個極簡版例子（真實 skill 會更細）：
在
src/meeting_summary.ts新增summarizeTranscript函式，內容如下：…程式碼…在
tests/meeting_summary.test.ts新增測試，內容如下：…程式碼…在終端機執行
npm test meeting_summary.test.ts，確認有 1 個新測試通過、0 失敗。
這樣的計畫有點像是：
把「高級工程師腦中的隱性經驗」，全部攤開放進文件裡。
好處是：你可以把一個任務，放心交給「一個不認識的 subagent」或「下一次新開的 AI session」，它照計畫走也不會迷路。
Skill 示例三：test-driven-development —— 沒有失敗測試，就不准寫程式碼
Superpowers 裡最「凶」的一條，就是 test-driven-development。
它寫得非常直白：
「沒有先寫測試，就不准寫 production code。」
並且把各種常見的偷懶理由全部預先堵死，例如：
覺得功能太簡單，不想寫測試？——簡單的程式碼也會出錯，寫測試只要幾十秒。
說「我先手動測過」？——手動測試沒記錄、不能重跑。
已經先寫了程式碼再補測試？——對不起，要把那段程式碼刪掉，當沒發生，重新來過。
這背後是典型的 TDD 循環：
先寫一個會失敗的測試（Red）。
運行確認它真的失敗。
寫最小的程式碼讓測試通過（Green）。
再重構，讓程式碼變乾淨。
對你有什麼啟發？
即使你不是工程師，也可以學到一個思路：
在「動手做」之前，先明確「我要如何驗證這件事算成功」。
你可以把這個方法用在：寫課程大綱、設計工作坊、甚至開新產品——先想清楚，成功的驗證標準是什麼。
Skill 示例四：systematic-debugging —— 不准瞎猜，只能系統化排查
當系統出 bug 時，很多 AI 會進入「瘋狂猜測模式」——改一行試試看、不行再改下一行，浪費大量時間。
systematic-debugging skill 規定：修 bug 要分四個階段，不能跳步：
根因調查：
把錯誤訊息讀完，而不是只看一眼。
想辦法穩定重現問題，不能重現就不准修。
看最近的程式碼 diff，是不是有可疑變更。
模式分析：
找一段「正常工作的類似程式碼」，跟有問題的地方對照。
假說與測試：
提出一個具體的假說，一次只改一個點去驗證。
實作與防禦：
寫測試重現問題，再修復。多次修不動，就要懷疑架構本身有問題。
這套流程，其實是把工程師的 debug 經驗，轉成一份 AI 也看得懂的「標準作業程序」。
你不一定全用，但你可以借 Superpowers 的思路，去寫自己的「排錯 checklist」。
Skill 示例五：verification-before-completion —— 說「完成」之前，先給證據
很多 AI 有個壞毛病：
「應該沒問題了」、「看起來 OK」、「我有信心這次可以」……但實際上根本沒跑任何檢查。
verification-before-completion 這個 skill 直接說：
「在沒有驗證證據之前宣稱完成，是不誠實，不是有效率。」
它要求 AI：
說「測試都通過了」前，必須實際跑測試，並檢查輸出、確認 0 失敗。
說「build 成功」前，要看命令的 exit code 是否為 0。
說「這個 bug 修好了」前，要重跑當初的重現步驟，確認問題真的消失。
並且給了一套「自查清單」：
證明這項宣稱的指令是什麼？
剛剛有沒有完整跑一次？
輸出有沒有仔細看？
確認結果真的支撐你的結論了嗎？
對我們人類同樣適用：
寫完一篇文、做完一支影片、上線一個新頁面，先問自己：「我真的驗證過了嗎？」
很有梗的 Skill：如何接 Code Review，還教 AI 用「暗號」
有一個很受討論的 skill 叫 receiving-code-review，專門教 AI：當你收到別人給的 code review 意見，要怎麼回應比較專業。
它明確禁止那種我們常見的客套回應：
「你說得太對了！」
「好棒的建議！」
「我馬上照做！」（但其實沒驗證過）
在這個規則裡：
禮貌不是重點，「技術上有沒有道理」才是重點。
正確做法是：
先用自己的話，複述對方的技術要求，確認沒誤解。
用程式碼和測試來驗證這個建議是不是適合當前專案。
如果判斷審查者錯了，要用技術理由推回去，而不是因為「不好意思」就照單全收。
更有趣的是：
為了防止 AI 在某些「政治敏感」或「職場微妙」的情況下直接頂撞人類，文件裡甚至設計了一個暗號句子：
「Strange things are afoot at the Circle K」
這句話本來出自一部老電影，在一般技術對話不太會自然出現，所以一旦看到，就可以理解為：
「我（AI）覺得這裡有問題，但現在不方便講明，你可以認真檢查一下。」
很少有技術文件，會教 AI 怎麼處理人際關係，這也是 Superpowers 讓很多人覺得有趣的地方。
Skill 示例六：writing-skills —— 連「寫 Skill」本身，也用 TDD
Superpowers 不只管「寫程式碼」，連「怎麼寫新的 Skill」也有專門的 skill：writing-skills。
它主張：
寫 skill 本身，就是一種「對流程做 TDD」。
流程大概是：
先設計一個高壓情境，用 subagent 在沒有這個 skill 的情況下執行任務，看它會犯什麼錯。
針對這些真實發生的問題，寫出 skill 文件。
再用同樣情境測試一次，這次載入 skill，看 AI 是否遵守。
如果 AI 又繞過了規則，就繼續補漏洞、再測一次。
它甚至把這個過程直接和傳統 TDD 對上表：
TDD 概念在 Superpowers 裡測試案例用 subagent 設計的壓力場景生產程式碼Skill 文件（SKILL.md）測試失敗（紅）沒有 skill 時，AI 亂來測試通過（綠）有 skill 時，AI 按規矩做重構在不破壞規則的前提下，補漏洞、改寫 skill
這說明一個重點：
Superpowers 不是憑空想出來的規範，而是從真實 AI 行為中，反覆「看它犯錯 → 寫規則 → 再試一次」打磨出來的。
它厲害在哪裡？也有什麼限制？
設計上幾個很有意思的點
用「必須」而不是「建議」
多數指南寫「你應該…」，Superpowers 直接寫「你必須…」，甚至寫出「違反規則字面意義，就是違反規則精神」，堵住 AI 用「我理解的是精神」來偷懶。大量列出「常見藉口 vs 現實」表格
每條規則後面都會列出 AI 可能說的各種理由，再一一反駁，這其實是在「封堵 AI 找藉口的路」。每一步都要求驗證
不只結果要驗證，連測試本身也要先確認「會失敗」，再確認「修完會通過」。
這些做法，讓 Superpowers 不只是「一組最佳實踐」，更像是「專門針對 AI 思維漏洞做的行為訓練。」
現實中的限制
當然，它也不是萬能藥：
完全依賴 AI 的「自律」
這些都只是文件，沒有硬性技術限制，AI 其實可以選擇不理會。成本很高
像subagent-driven-development一次任務要開 3 個 subagent，token 和時間都燒得很快。對小任務來說有點「牛刀殺雞」
修一個 typo、改一行配置，如果全套走完 brainstorming、plan、TDD、review，會非常重。
作者也坦白承認：
這套東西更適合「需要高品質、長期維護」的專案，而不是快速試驗的小腳本。
你可以怎麼用這個「思路」？
即使你不直接安裝 Superpowers，也很值得做三件事：
把它當作「如何指揮 AI 寫程式碼」的教材，讀一遍，你會更知道該怎麼寫指令、怎麼要求驗證。
從裡面挑幾條最適合你的流程，簡化成為自己的團隊規範，比如：
一律要求「先講測試怎麼寫，再讓 AI 寫實作」。
要求 AI 在說「完成」之前貼上完整的指令和輸出。
如果你自己在帶新人，不妨把裡頭那種「藉口 vs 現實」的表格改寫，給新人和 AI 一起看。
最後
Superpowers 真正有價值的地方，不是「我照抄它的所有規矩」，而是它提供了一套 系統化思考 AI 工作流 的範本：
把經驗寫成文字，把文字變成習慣，讓 AI 跟人一起遵守。