Superpowers Skill - 讓 Claude Code 和 Codex 按工程流程做開發
整理版優先睇
用 Superpowers Skill 將工程流程固化,令 AI coding agent 有紀律地開發
呢篇文章係基於 Superpowers 同 Startup Superpowers 嘅素材整理,拆解 Skill 係咩、適合邊啲開發場景、用同唔用嘅差別,同埋喺 Claude Code 同 Codex 入面點樣落地。作者想解決嘅問題係:AI coding agent 好容易「會寫代碼,但唔跟工程流程嚟做」,譬如直接修 bug 唔追根因、新功能唔諗清楚就開幹、重構搞到差唔多改曬。整體結論係:Skill 唔係提示詞,而係「流程約束」——佢將需求澄清、方案設計、TDD、調試、代碼審查同完成前驗證呢啲工程動作固化成一組可複用嘅程序,等 agent 唔係靠即興發揮,而係按紀律行每一步。
Superpowers Skill 嘅核心價值唔係畀 agent 多咗某個單點功能,而係改變佢嘅默認行動順序:由「直接寫代碼」變為「先走流程」。透過 brainstorming、writing-plans、systematic-debugging 等 skill,agent 會先問清楚目標、拆好可驗證計劃,再用測試鎖住行為,最後先改 code。呢樣嘢令跨會話執行保持一致,唔洗用家每次都要提醒「先諗先計劃」。
呢套流程適合新功能、複雜 bug、重構、多 agent 並行同創業驗證等場景。當然 Skill 唔係萬能,佢改善唔到架構取捨或產品判斷,但能有效減少「未問清楚就實行」「未計劃就大改」「未測試就話完成」呢類流程型錯誤。作者建議真實項目最少由 …
- Superpowers Skill 本質係將軟件工程最佳實踐編碼成 agent 可執行嘅流程約束,唔係提示詞。
- 核心做法係將任務拆成多個 skill,例如 brainstorming、writing-plans、TDD、systematic-debugging,令 agent 先走流程再寫代碼。
- 使用 Skill 同唔用嘅主要分別:需求會先澄清、計劃可執行、測試先行、調試有系統、完成前有驗證,跨會話一致性更高。
- Skill 減少嘅唔係代碼錯誤,而係流程型錯誤:未問清楚就實現、未計劃就大改、未測試就聲稱完成、未找根因就修 bug、未 review 就下一步。
- 建議真實項目最少從 systematic-debugging、writing-plans、verification-before-completion 三個 skill 開始,並將規則寫入項目規範(例如 AGENTS.md),防止 agent 跳步驟。
Superpowers GitHub
Superpowers 官方項目,包含 Composable Skills 同安裝指南
Startup Superpowers GitHub
將創業驗證流程做成 Claude Code 插件嘅範例
咩係 Superpowers Skill?——將工程紀律變做 agent 可執行嘅規矩
Superpowers Skill 唔係普通提示詞,而係一套「流程約束」。佢嘅目的係令 AI coding agent 唔再亂嚟:每次做複雜任務前,先跟住預設嘅步驟行——例如 先澄清需求、制定可驗證計劃、測試先行、系統性調試、完成前驗證。呢啲步驟唔係靠用家每次提醒,而係沉澱喺 Skill 文件入面,agent 會自動 load 相應嘅 workflow。
Superpowers 將開發任務拆成多個獨立 Skill,每個負責一個環節,例如 brainstorming(需求唔清時用)、writing-plans(將方案變做可執行步驟)、test-driven-development(新功能用 TDD)、systematic-debugging(修 bug 要追根因)、verification-before-completion(完成前一定要驗證)。呢啲 Skill 可以組合用,覆蓋由需求討論到 final 收尾嘅完整鏈路。
用同唔用嘅差別:流程型錯誤 vs 代碼錯誤
冇 Skill 嗰陣,agent 好多時會直接「估」答案:修 bug 靠經驗猜 patch,新功能直接寫 code 然後先發現理解錯。用咗 Superpowers 之後,agent 會自動行一套 系統化流程:先問清楚、再計劃、再測試、再驗證。呢種轉變唔會令代碼一定啱,但會大幅減少「流程型錯誤」——即係 冇問清楚就做、冇計劃就大改、冇測試就話搞掂、冇揾根因就修補、冇 review 就 merge。
- 需求澄清:冇 Skill -> 用家第一句就直接實現;有 Skill -> brainstorming 先問清楚目標同邊界。
- 計劃質量:冇 Skill -> 計劃可能好模糊;有 Skill -> writing-plans 要求任務可執行、可驗證。
- 測試習慣:冇 Skill -> 寫完先補測,甚至唔測;有 Skill -> TDD skill 強制先寫失敗測試。
- 調試方式:冇 Skill -> 憑經驗猜 patch;有 Skill -> systematic-debugging 要求列假設逐個驗證。
- 完成判斷:冇 Skill -> 「我已經修好啦」;有 Skill -> verification-before-completion 要求實際跑測試或手動驗證。
點樣喺 Claude Code 同 Codex 入面落地?
喺 Claude Code 入面,可以經官方插件市場安裝 Superpowers:輸入 <code>/plugin install superpowers@claude-plugins-official</code>。如果要用 Superpowers 自家 marketplace,就先註冊再安裝。裝好之後,agent 會自動根據任務類型觸發對應 Skill——例如你話「幫我修 bug」,佢就會加載 systematic-debugging,先列根因假設,先唔改 code。重點係:Skill 檢查要發生喺行動之前,即係 agent 唔應該先讀文件先改 code,而係先判斷有冇適用 Skill。
Codex 嘅安裝類似,入 Codex CLI 打 <code>/plugins</code> 搜尋 superpowers 然後安裝;或者喺 Codex App 側邊欄 Plugins 嘅 Coding 分類揾到 Superpowers。用法都係一樣:裝完插件後,讓 Superpowers 嘅 Skills 參與當前會話。例如你可以打「使用 Superpowers 嘅 writing-plans,先幫我寫一份重構計劃,等我確認先再實現」。咁樣可以減少 agent 誤判任務類型 嘅機會。
- 1 明確點名 Skill:用戶講「用 systematic-debugging 排查 login 問題」,agent 優先讀對應 SKILL.md。
- 2 語義觸發:用戶冇點名但任務明顯匹配,agent 都應自動加載對應 Skill。
- 3 加載後先聲明:agent 需要講明「我而家用緊邊個 Skill,點解用」。
- 4 跟 workflow 執行:按 Skill 嘅步驟做,唔好憑記憶跳步驟。
一個典型開發任務點樣用 Superpowers 行?
假設我要喺 Web 項目加「用戶導出賬單」功能。冇 Superpowers 嗰陣 agent 可能直接生成接口、按鈕同下載邏輯。有咗 Superpowers,合理流程係:第一步:Brainstorming——先問清楚導出格式、數據範圍、權限、同步定異步、大數據量處理、失敗訊息。呢步唔係拖慢進度,而係避免返工。第二步:Writing Plans——將方案拆成有文件邊界同驗證方式嘅任務,例如「喺 billing service 加 exportInvoiceCsv,驗證:單元測試覆蓋空數據、正常數據、越權訪問」。第三步:TDD——先寫失敗測試鎖住行為,再用最小實現通過測試。第四步:Code Review——重點檢查計劃符合度、越權風險、大數據量問題、錯誤狀態覆蓋、有冇改動唔相關文件。第五步:Verification——最後一步唔可以剩係「測試通過」,要真正行開發伺服器或用瀏覽器走關鍵路徑。
import { describe, expect, it } from "vitest";
import { exportInvoiceCsv } from "./billing-export";
describe("exportInvoiceCsv", () => {
it("exports invoices as csv rows", () => {
const csv = exportInvoiceCsv([
{ id: "inv_001", amount: 1999, currency: "USD" },
{ id: "inv_002", amount: 2999, currency: "USD" },
]);
// 先用測試固定輸出格式,避免實現時隨意漂移
expect(csv).toContain("id,amount,currency");
expect(csv).toContain("inv_001,1999,USD");
expect(csv).toContain("inv_002,2999,USD");
});
});
實戰建議:點樣用得好、避免誤區
- 1 唔好將 Skill 當成萬能藥。佢係流程約束,唔係質量保證。產品取捨、架構邊界、業務優先級呢啲終歸要靠人判斷。
- 2 複雜任務先走 plan,簡單任務唔好過度工程化。改 typo、查命令呢類可以直接做,但 bug 排查建議用 systematic-debugging,新功能建議用 brainstorming + writing-plans + TDD,跨模塊重構強烈建議用 plan + verification。
- 3 將 Skill 寫入項目規範——例如喺 AGENTS.md 或 CLAUDE.md 寫明:「複雜功能必須先計劃再實現;bug 修復必須先行 systematic debugging;完成前必須行驗證」。呢啲規則對 agent 好重要,因為佢哋默認傾向「完成用戶請求」,而唔係「最小風險咁完成」。
另外要搞清楚 Skill、Memory 同 Plan 嘅分別:Skill 規定「點做」某類任務,跨會話複用;Memory 記錄用戶偏好同項目背景,跨會話持久;Plan 係當前任務嘅執行步驟,有效期得今次任務。三者夾埋先令 agent 行為又穩定又貼合項目。常見誤區包括:「有 Skill 就唔洗寫清楚需求」、「Skill 越多越好」、「裝咗插件 agent 就自動跟流程」。正確做法係喺關鍵任務開頭明確要求用邊個 Skill,例如「請用 systematic-debugging,先列根因假設,逐項驗證,先唔好改 code」。

Superpowers Skill 嘅核心價值,唔係畀 AI 加某個單點功能,而係將需求澄清、方案設計、TDD、除錯、Code Review 同完成前驗證呢啲工程動作固定成為可重用流程。呢篇文章係根據 Superpowers 同 Startup Superpowers 嘅素材,拆解 Skill 係乜嘢、適合邊啲開發場景、用同唔用嘅分別,以及喺 Claude Code 同 Codex 入面點樣落地。
先講結論:Skill 唔係提示詞,而係「流程約束」
最近睇 Superpowers 相關資料嘅時候,我覺得最值得關注嘅唔係佢有幾多個具體 skill,而係佢試圖解決一個好現實嘅問題:
AI coding agent 好容易「識寫 code,但唔一定跟工程流程做事」。
你叫佢修 bug,佢可能即刻讀檔案、估原因、改 code。你叫佢做功能,佢可能直接開工,等寫完先發現需求理解錯咗。你叫佢重構,佢可能順手改咗一堆相鄰 code,最後風險仲大過收益。
呢個唔係模型「唔識寫 code」,而係軟件開發本身需要流程紀律:
1. 先搞清楚目標,而唔係即刻實行。 2. 先制定可驗證嘅計劃,而唔係邊寫邊諗。 3. 修 bug 要追根因,而唔係估一個修補。 4. 新功能要盡量測試先行,而唔係完成之後先補測。 5. 宣佈完成之前要驗證,而唔係憑感覺話「應該得㗎喇」。
Superpowers Skill 做嘅嘢,就係將呢啲流程變成一組可以加載、可以組合、可以重用嘅 agent 操作規程。佢唔係令 AI 「更聰明」,而係令 AI 更加似一個被流程約束住嘅工程師。
Superpowers 係乜嘢?
由官方項目描述嚟睇,Superpowers 係一套面向 coding agents 嘅軟件開發方法論。佢建立喺一組 composable skills 之上,透過初始指令確保 agent 喺合適嘅場景下調用呢啲 skills。
換個更工程化嘅講法:
Superpowers = 一套將「軟件工程最佳實踐」編碼成 agent 工作流嘅 skill 框架。
佢嘅基本思路唔係「畀模型一段更長嘅提示詞」,而係將唔同任務拆成唔同 skill:
brainstorming | ||
writing-plans | ||
test-driven-development | ||
systematic-debugging | ||
verification-before-completion | ||
requesting-code-review | ||
using-git-worktrees |
呢啲 skill 組合埋一齊,覆蓋咗由需求討論到最終收尾嘅完整開發鏈路。
Skill 到底係嚟做乜?
如果淨係睇表面,Skill 好似一份說明書:幾時要做乜嘢,先做邊一步,驗證啲乜結果。
但係喺 AI agent 場景裏面,佢嘅作用更具體:
1. 將「點樣做」由對話裏面抽離出嚟
普通使用方式之下,用戶每次都要提醒:
先別急着寫代碼。
先分析一下方案。
寫測試。
不要大範圍重構。
改完記得跑測試。咁樣好攰,而且用戶一旦唔記得提醒,agent 就可能退回默認行為。
Skill 嘅意義係將呢類重複約束沉澱落嚟。用戶只需要講「修呢個 bug」或者「實現呢個功能」,agent 根據任務類型加載對應 skill,自動進入除錯流程、TDD 流程或計劃流程。
亦即係話:
沒有 Skill:用戶反覆教 agent 怎麼做。
有 Skill:用戶只描述要做什麼,Skill 約束 agent 怎麼做。2. 降低 agent 嘅「即興發揮」
AI 寫 code 嘅一個常見問題係行動得太快。佢可以好流暢咁解釋、實現、修補、總結,但流暢唔等於正確。
Superpowers 嘅核心約束係將 agent 由「直接寫 code」拉返去「先行流程」:
粗略需求
↓
brainstorming 澄清目標
↓
writing-plans 拆成可執行任務
↓
test-driven-development 約束實現
↓
requesting-code-review 檢查風險
↓
verification-before-completion 完成前驗證呢條鏈路睇起嚟慢,但佢解決嘅係複雜項目裏面最昂貴嘅問題:方向錯、邊界錯、驗證缺失、回歸冇人發現。

3. 令流程跨會話保持一致
單次對話裏面,你可以畀 agent 好長嘅系統提示。但真實項目通常跨好多日、好多個會話。
Skill 嘅價值在於:
1. 每次會話都可以重新加載最新流程。 2. 同一類任務行同一套標準。 3. 團隊可以將流程寫入倉庫或者插件,而唔係散落喺聊天記錄裏面。
呢樣對長期項目好重要。軟件項目真正麻煩嘅地方通常唔係某一段 code,而係「今日、聽日、下星期再返嚟嘅時候,大家係咪仍然跟同一套工程紀律做事」。
使用場景:幾時值得用 Superpowers Skill?
唔係所有任務都需要重流程。問一個命令、查一個細配置、改一個明顯嘅 typo,直接做就可以。
Superpowers 更加適合呢啲場景。
場景一:新功能開發
典型輸入:
幫我給這個項目加一個會員訂閲功能。冇 skill 嘅時候,agent 好可能會即刻揾檔案、寫 UI、補 API、加狀態字段。問題係:會員能力涉及支付、權限、狀態同步、失敗回滾、測試同上線風險,唔適合直接開寫。
使用 Superpowers 之後,合理流程應該係:
1. brainstorming:先澄清功能邊界,例如套餐、試用、退款、權限降級。2. writing-plans:拆出數據結構、接口、UI、測試、驗收步驟。3. test-driven-development:先寫關鍵業務規則測試。4. executing-plans:按步驟實現。5. verification-before-completion:行測試、行關鍵路徑。
佢唔係令功能變簡單,而係令風險顯性化。
場景二:複雜 bug 排查
典型輸入:
這個列表偶爾不刷新,幫我修一下。呢類問題最怕「估」。可能係緩存、異步競態、狀態冇更新、請求失敗、視圖重用,亦可能係測試環境問題。
systematic-debugging 嘅價值喺呢度好明顯:佢會要求 agent 先列假設,再逐個驗證,而唔係同時改三處 code。好嘅除錯流程通常包含:
1. 重現現象。 2. 建立 3-5 個根因假設。 3. 由最簡單、最可能嘅假設開始驗證。 4. 每次淨係改變一個變量。 5. 揾到根因之後再做最小修復。 6. 最後用測試或真實路徑驗證。
呢樣可以減少「修補睇起嚟有效,但根因仲喺度」嘅情況。
場景三:重構同架構調整
重構最容易失控。用戶話「整理一下呢個模組」,agent 可能會改名、拆檔案、換結構、順手修格式,最後 diff 好大,review 成本好高。
Superpowers 嘅計劃類 skill 可以將重構限制喺清晰嘅邊界之內:
1. 點解要重構? 2. 邊啲檔案一定要改? 3. 邊啲行為唔可以變? 4. 先跑邊啲基線測試? 5. 每一步點樣驗證?
呢樣好關鍵。重構唔係「睇起嚟更優雅」,而係喺行為不變嘅前提下降低複雜度。
場景四:多 agent 並行開發
Superpowers 素材入面提到 subagent-driven-development 和 dispatching-parallel-agents。呢類 skill 適合將複雜任務拆畀多個子 agent:
1. 一個 agent 負責實現。 2. 一個 agent 檢查係咪符合 spec。 3. 一個 agent 做 code 質量 review。 4. 主 agent 負責匯總同推進。
但呢度有一個前提:任務必須拆得清楚,交付物必須可以驗證。否則並行只會放大混亂。
場景五:創業想法驗證
素材入面嘅 Startup Superpowers 係另一個好例子。佢唔係普通編碼流程,而係將創業驗證流程做成 Claude Code 插件。
佢包含呢啲 slash command:
/whats-next | |
/competitors | |
/market-research | |
/hypotheses | |
/interviews | |
/surveys | |
/mvp |
用同唔用,對項目開發有乜嘢分別?
下面呢張表係我認為最實際嘅分別。
佢真正改善嘅係「流程型錯誤」:
1. 冇問清楚就實現。 2. 冇計劃就大改。 3. 冇測試就聲稱完成。 4. 冇揾根因就修 bug。 5. 冇 review 就進入下一步。
呢啲錯誤唔會因為模型能力越強就自然消失。模型越強,寫得越快,流程失控時嘅破壞範圍反而可能越大。

一個典型開發任務應該點樣行?
假設我哋要喺一個 Web 項目入面增加「用戶導出賬單」功能。冇 Superpowers 嗰陣,agent 可能會直接生成接口、按鈕同下載邏輯。
更穩陣嘅 Superpowers 流程應該係咁:
第一步:Brainstorming,先問清楚需求
需要確認嘅問題包括:
1. 導出嘅係 PDF、CSV 定 Excel? 2. 用戶可以導出幾耐嘅數據? 3. 需唔需要權限校驗? 4. 導出係同步下載定異步任務? 5. 大數據量嗰陣點處理? 6. 失敗之後用戶見到啲乜?
呢一步唔係拖慢進度,而係避免之後返工。
第二步:Writing Plans,將方案拆成可執行任務
一個合格嘅計劃唔可以淨係寫:
實現賬單導出功能。佢應該更加似:
1. 在 billing service 中增加 exportInvoiceCsv(userId, range)。
驗證:新增單元測試覆蓋空數據、正常數據、越權訪問。
2. 在 API route 中接入導出接口。
驗證:請求無權限返回 403,請求成功返回 text/csv。
3. 在前端賬單頁增加下載按鈕。
驗證:瀏覽器點擊後能下載文件,loading 和錯誤狀態正確。呢度嘅重點係:每一步都有檔案邊界同驗證方式。咁樣 agent 執行嗰陣唔容易走樣。
第三步:TDD,用失敗測試鎖住行為
TDD skill 嘅意義唔係「為咗測試而測試」,而係先定義行為。
例如導出 CSV 嘅業務規則可以先寫成測試:
import { describe, expect, it } from "vitest";
import { exportInvoiceCsv } from "./billing-export";
describe("exportInvoiceCsv", () => {
it("exports invoices as csv rows", () => {
const csv = exportInvoiceCsv([
{ id: "inv_001", amount: 1999, currency: "USD" },
{ id: "inv_002", amount: 2999, currency: "USD" },
]);
// 先用測試固定輸出格式,避免實現時隨意漂移
expect(csv).toContain("id,amount,currency");
expect(csv).toContain("inv_001,1999,USD");
expect(csv).toContain("inv_002,2999,USD");
});
});真正嘅流程係:
1. 寫失敗測試。 2. 確認測試確實失敗。 3. 寫最小實現。 4. 確認測試通過。 5. 再重構。
呢個比「先實現再補測」更加能夠約束 agent。
第四步:Code Review,唔淨係睇行唔行得通
code 行得通唔代表可以合併。requesting-code-review 或者類似 review skill 應該重點睇:
1. 係咪符合原計劃。 2. 有冇引入越權風險。 3. 有冇大數據量問題。 4. 有冇未覆蓋嘅錯誤狀態。 5. 有冇改動咗唔相關嘅檔案。
對 AI 生成嘅 code 嚟講,review 嘅價值好高。因為 agent 好容易寫出「睇起嚟完整」嘅實現,但邊界條件同異常路徑唔夠嚴謹。
第五步:Verification,完成前必須驗證
最後一步唔可以淨係話「測試通過」。唔同項目需要唔同驗證:

喺 Claude Code 入面點樣使用?
根據素材同 Superpowers 項目說明,Claude Code 有兩種安裝路徑。
方式一:由官方插件市場安裝
喺 Claude Code 入面運行:
/plugin install superpowers@claude-plugins-official方式二:加入 Superpowers marketplace 之後安裝
如果使用 Superpowers 自己嘅 marketplace,可以先註冊:
/plugin marketplace add obra/superpowers-marketplace再安裝:
/plugin install superpowers@superpowers-marketplace安裝之後跟提示 reload 插件。如果你喺多個 workspace 用到 Claude Code,需要注意插件安裝範圍:有啲插件適合全局安裝,有啲更適合按項目安裝。
Claude Code 裏面嘅使用方式
安裝完成之後,唔應該將 skill 當成普通文檔手動複製畀模型,而係要 Claude Code 嘅 Skill / Plugin 機制加載佢。
典型觸發方式有兩類:
1. 顯式命令:例如運行某個 slash command。 2. 語義觸發:用戶話「幫我修 bug」「幫我做計劃」「實現呢個功能」嗰陣,相關 skill 介入。
需要特別強調一個原則:skill 檢查要發生喺行動之前。亦即係話,遇到除錯、計劃、TDD 等任務嗰陣,agent 唔應該先讀檔案、先改 code、先問一堆問題,而應該先判斷有冇適用 skill。
一個合理嘅 Claude Code 工作流係:
用戶:幫我修復這個接口偶發 500 的問題。
↓
Claude Code:加載 systematic-debugging skill。
↓
Agent:先建立根因假設,要求復現或查日誌。
↓
Agent:逐個驗證假設,只做最小修復。
↓
Agent:加載 verification-before-completion,跑測試或接口驗證。
↓
Agent:報告根因、改動和驗證結果。呢個先至係 Superpowers 嘅重點:唔係多一個命令,而係改變 agent 嘅默認行動順序。
喺 Codex 入面點樣使用?
Superpowers 都支援 Codex CLI 同 Codex App。根據 Superpowers 項目說明,Codex 嗰邊嘅安裝入口係官方 Codex plugin marketplace。
Codex CLI
喺 Codex CLI 入面打開插件界面:
/plugins搜索:
superpowers然後揀 Install Plugin。
Codex App
喺 Codex App 入面:
1. 打開側邊欄嘅 Plugins。 2. 喺 Coding 分類入面揾到 Superpowers。3. 㩒 +並跟提示安裝。
Codex 裏面嘅使用方式
Codex 中嘅核心用法同 Claude Code 類似:安裝插件之後,令 Superpowers 嘅 skills 參與當前會話。
實際使用嗰陣可以咁理解:
1. 用戶明確點名某個 skill 或插件嗰陣,Codex 應優先讀取對應 SKILL.md。2. 用戶冇點名,但任務明顯匹配某個 skill 嘅 description 嗰陣,都應加載對應 skill。 3. 加載之後,Codex 需要先聲明正在用邊個 skill,以及點解用。 4. 執行過程中,跟 skill 嘅 workflow 做,唔好憑記憶跳步驟。
例如你可以咁樣發起任務:
使用 Superpowers 的 systematic-debugging,幫我排查這個登錄接口偶發失敗的問題。或者:
用 Superpowers 的 writing-plans,先給這個重構任務寫一份執行計劃。喺 Codex 嘅實際工程項目入面,我更建議將 Superpowers 當作「任務進入方式」,而唔係某種一次性提示詞。亦即係話,做複雜任務嗰陣先令 agent 進入正確流程,先至開始讀 code 同修改檔案。
Startup Superpowers 畀到我哋嘅啟發
另一個項目係 Startup Superpowers。佢同 Superpowers 本體唔係同一樣嘢,但好適合用嚟做 skill 方法論嘅應用案例。
Startup Superpowers 解決嘅唔係「點樣寫 code」,而係「創業想法點樣驗證」。佢將早期創業驗證拆成:
1. 競品分析。 2. 市場研究。 3. 假設管理。 4. 用戶訪談。 5. 問卷調查。 6. MVP 設計。 7. 下一步規劃。
更重要嘅係,佢將所有狀態寫喺項目目錄嘅 startup/ 下面,用 Markdown 儲存。咁樣有幾個好處:
1. 產物可讀,唔會被 SaaS 鎖住。 2. 可以提交到 Git,睇到想法點樣演進。 3. 可以用 Obsidian 瀏覽證據圖譜。 4. agent 之間可以透過檔案交接,而唔係依賴聊天上下文。
呢個說明 skill 嘅真正價值唔係「某個模型學識咗某項技能」,而係將一個專業流程變成可執行、可追蹤、可覆盤嘅工作系統。
實戰建議:點樣用好 Superpowers?
1. 唔好將 Skill 當成萬能藥
Skill 係流程約束,唔係質量保證。佢能夠減少常見流程錯誤,但唔可以代你判斷產品取捨、架構邊界同業務優先級。
如果需求本身唔清楚,Skill 會幫助澄清;但最終取捨始終要人嚟做。
2. 複雜任務先行 plan,簡單任務唔好過度工程化
我嘅經驗判斷係:
3. 將 skill 寫入項目規範
如果團隊長期用 Claude Code 或 Codex,建議將下面內容寫入項目級說明檔案,例如 AGENTS.md、CLAUDE.md 或插件配置:
複雜功能開發必須先計劃再實現。
bug 修復必須先使用 systematic debugging。
有測試條件時必須優先 TDD。
完成前必須運行可驗證檢查,並報告結果。
禁止無關重構和大範圍格式化。呢啲規則睇起嚟普通,但對 AI agent 好重要。因為 agent 默認會傾向於「完成用戶請求」,而唔係「最小風險咁完成用戶請求」。
4. 每次都重新加載,唔好靠記憶
素材入面有一個好實用嘅提醒:Skill 內容會演進,唔好因為「我記得呢個 skill 大概係乜」就 skip 咗加載。
呢點對 agent 尤其關鍵。人可以靠經驗靈活處理,但 agent 嘅「記得」通常只係上下文入面嘅近似印象。真正可靠嘅做法係讀取當前 skill 檔案,跟當前版本執行。
5. 清楚區分 Skill、Memory 同 Plan
呢三樣嘢容易混淆:
1. Skill 規定「修 bug 要系統除錯」。 2. Memory 記錄「呢個用戶鍾意 bun,唔鍾意 npx」。 3. Plan 記錄「今次修復要睇登錄接口,再補測試,再驗證」。
呢三個加埋一齊,先會令 agent 嘅行為既穩定,又貼合當前項目。
常見誤區
誤區一:有咗 Skill,就唔使寫清楚需求
唔啱。Skill 可以幫助澄清需求,但唔能夠憑空知道真實業務。
你仍然需要提供:
1. 目標。 2. 約束。 3. 優先級。 4. 驗收標準。
Skill 只係令 agent 更有紀律咁追問同執行。
誤區二:Skill 越多越好
都唔啱。Skill 太多會導致觸發混亂,甚至互相衝突。
好嘅 skill 應該滿足三個條件:
1. 場景清晰。 2. 觸發條件明確。 3. 流程可以驗證。
如果一個 skill 只係寫咗一堆泛泛建議,佢對 agent 嘅實際幫助有限。
誤區三:只要裝咗插件,agent 就一定會跟流程做
唔可以咁理解。唔同宿主嘅插件機制、觸發規則同上文優先級會有差異。
更穩陣嘅做法係:喺關鍵任務開頭明確要求使用對應 skill。例如:
請使用 Superpowers 的 systematic-debugging 流程,先不要改代碼,先列根因假設並逐項驗證。或者:
請使用 Superpowers 的 writing-plans,先產出可執行計劃,等我確認後再實現。咁樣可以減少 agent 誤判任務類型嘅機率。
我會點樣喺真實項目入面使用佢?
如果係我嘅項目,我會咁樣分層使用。
日常小任務
保持輕量。叫 agent 直接改,但要求:
1. 改動範圍細。 2. 唔做無關重構。 3. 完成之後行必要驗證。
有風險嘅 bug
明確調用:
使用 systematic-debugging。先列可能根因,不要馬上修改代碼。然後要求 agent 將驗證結果寫清楚:
1. 邊個假設被排除。 2. 邊個假設被證實。 3. 根因係乜。 4. 點解呢個修復係最小修復。
新功能或重構
明確調用:
使用 brainstorming 和 writing-plans。先產出計劃,不要實現。計劃確認之後先叫佢進入實現階段。實現過程中盡量令測試先行。
合併或發佈前
明確調用:
使用 verification-before-completion 和 requesting-code-review,檢查是否真的可以合併。呢一步可以擋住好多「睇起嚟完成咗」嘅問題。
總結
Superpowers Skill 嘅本質,係將軟件工程流程變成 AI agent 可執行嘅規則系統。
佢解決嘅唔係「AI 識唔識寫 code」,而係:
1. 會唔會先澄清需求。 2. 會唔會制定可驗證計劃。 3. 會唔會測試先行。 4. 會唔會系統性除錯。 5. 會唔會完成前實際驗證。 6. 會唔會將複雜任務拆畀合適嘅執行單元。
喺冇 skill 嘅情況下,開發者需要不斷提醒 agent 唔好跳步驟;使用 Superpowers 之後,呢啲提醒可以沉澱為穩定流程。
對 Claude Code 同 Codex 嚟講,Superpowers 嘅正確使用方式唔係「記住一段提示詞」,而係安裝插件、加載 skill、令 agent 喺任務開始前進入正確嘅工作流。複雜項目入面,呢種流程約束嘅價值會越來越明顯。
如果你已經將 AI coding agent 用喺真實項目,我建議至少由三個 skill 開始:
1. systematic-debugging:防止亂估 bug。2. writing-plans:防止複雜任務走樣。3. verification-before-completion:防止冇驗證就宣佈完成。
呢三個 skill 唔會令開發變得神奇,但會令 agent 嘅行為更加似一個有工程紀律嘅合作者。
參考資料
1. Superpowers GitHub: https://github.com/obra/superpowers 2. Startup Superpowers GitHub: https://github.com/SergeiGorbatiuk/startup-superpowers
2026.06.06 20:54
滬 · 趙巷
📌 聲明:本文由 AI 輔助完成
寫 AI,寫成長,偶爾寫投資。關注沐風,不定期更新,全部係乾貨。

Superpowers Skill 的核心價值,不是給 AI 增加某個單點功能,而是把需求澄清、方案設計、TDD、調試、代碼審查和完成前驗證這些工程動作固化成可複用流程。本文基於 Superpowers 與 Startup Superpowers 的素材,拆解 Skill 是什麼、適合哪些開發場景、使用和不使用的差別,以及在 Claude Code 和 Codex 中如何落地。
先說結論:Skill 不是提示詞,而是“流程約束”
最近看 Superpowers 相關資料時,我覺得最值得關注的不是它有多少個具體 skill,而是它試圖解決一個很現實的問題:
AI coding agent 很容易“會寫代碼,但不一定按工程流程做事”。
你讓它修 bug,它可能馬上讀文件、猜原因、改代碼。你讓它做功能,它可能直接開幹,等寫完才發現需求理解偏了。你讓它重構,它可能順手改了一堆相鄰代碼,最後風險比收益還大。
這不是模型“不會寫代碼”,而是軟件開發本身需要流程紀律:
1. 先弄清楚目標,而不是馬上實現。 2. 先形成可驗證計劃,而不是邊寫邊想。 3. 修 bug 要追根因,而不是猜一個補丁。 4. 新功能要儘量測試先行,而不是完成後補測。 5. 宣佈完成前要驗證,而不是憑感覺說“應該好了”。
Superpowers Skill 做的事情,就是把這些流程變成一組可加載、可組合、可複用的 agent 操作規程。它不是讓 AI “更聰明”,而是讓 AI 更像一個被流程約束住的工程師。
Superpowers 是什麼?
從官方項目描述看,Superpowers 是一套面向 coding agents 的軟件開發方法論。它建立在一組 composable skills 之上,通過初始指令確保 agent 在合適場景下調用這些 skills。
換成更工程化的說法:
Superpowers = 一套把“軟件工程最佳實踐”編碼成 agent 工作流的 skill 框架。
它的基本思路不是“給模型一段更長的提示詞”,而是把不同任務拆成不同 skill:
brainstorming | ||
writing-plans | ||
test-driven-development | ||
systematic-debugging | ||
verification-before-completion | ||
requesting-code-review | ||
using-git-worktrees |
這些 skill 組合起來,覆蓋了從需求討論到最終收尾的完整開發鏈路。
Skill 到底是幹嘛用的?
如果只看表面,Skill 像是一份說明書:什麼時候該做什麼,先做哪一步,驗證什麼結果。
但在 AI agent 場景裏,它的作用更具體:
1. 把“怎麼做”從對話裏抽離出來
普通使用方式下,用戶每次都要提醒:
先別急着寫代碼。
先分析一下方案。
寫測試。
不要大範圍重構。
改完記得跑測試。這很累,而且用戶一旦忘記提醒,agent 就可能退回默認行為。
Skill 的意義是把這類重複約束沉澱下來。用戶只需要說“修這個 bug”或者“實現這個功能”,agent 根據任務類型加載對應 skill,自動進入調試流程、TDD 流程或計劃流程。
也就是說:
沒有 Skill:用戶反覆教 agent 怎麼做。
有 Skill:用戶只描述要做什麼,Skill 約束 agent 怎麼做。2. 降低 agent 的“即興發揮”
AI 寫代碼的一個常見問題是行動太快。它可以很流暢地解釋、實現、補丁、總結,但流暢不等於正確。
Superpowers 的核心約束是把 agent 從“直接寫代碼”拉回“先走流程”:
粗略需求
↓
brainstorming 澄清目標
↓
writing-plans 拆成可執行任務
↓
test-driven-development 約束實現
↓
requesting-code-review 檢查風險
↓
verification-before-completion 完成前驗證這條鏈路看起來慢,但它解決的是複雜項目裏最昂貴的問題:方向錯、邊界錯、驗證缺失、迴歸沒人發現。

3. 讓流程跨會話保持一致
單次對話裏,你可以給 agent 很長的系統提示。但真實項目往往跨很多天、很多會話。
Skill 的價值在於:
1. 每次會話都能重新加載最新流程。 2. 同一類任務走同一套標準。 3. 團隊可以把流程寫進倉庫或插件,而不是散落在聊天記錄裏。
這對長期項目很重要。軟件項目真正麻煩的地方往往不是某一段代碼,而是“今天、明天、下週再回來時,大家是否仍然按同一套工程紀律做事”。
使用場景:什麼時候值得用 Superpowers Skill?
不是所有任務都需要重流程。問一個命令、查一個小配置、改一個明顯 typo,直接做就可以。
Superpowers 更適合這些場景。
場景一:新功能開發
典型輸入:
幫我給這個項目加一個會員訂閲功能。沒有 skill 時,agent 很可能馬上找文件、寫 UI、補 API、加狀態字段。問題是:會員能力涉及支付、權限、狀態同步、失敗回滾、測試和上線風險,不適合直接開寫。
使用 Superpowers 後,合理流程應該是:
1. brainstorming:先澄清功能邊界,比如套餐、試用、退款、權限降級。2. writing-plans:拆出數據結構、接口、UI、測試、驗收步驟。3. test-driven-development:先寫關鍵業務規則測試。4. executing-plans:按步驟實現。5. verification-before-completion:跑測試、走關鍵路徑。
它不是讓功能變簡單,而是讓風險顯性化。
場景二:複雜 bug 排查
典型輸入:
這個列表偶爾不刷新,幫我修一下。這種問題最怕“猜”。可能是緩存、異步競態、狀態沒更新、請求失敗、視圖複用,也可能是測試環境問題。
systematic-debugging 的價值在這裏非常明顯:它會要求 agent 先列假設,再逐個驗證,而不是同時改三處代碼。好的調試流程一般包含:
1. 復現現象。 2. 建立 3-5 個根因假設。 3. 從最簡單、最可能的假設開始驗證。 4. 每次只改變一個變量。 5. 找到根因後再做最小修復。 6. 最後用測試或真實路徑驗證。
這能減少“補丁看似有效,但根因還在”的情況。
場景三:重構和架構調整
重構最容易失控。用戶說“整理一下這個模塊”,agent 可能改命名、拆文件、換結構、順手修格式,最後 diff 巨大,review 成本很高。
Superpowers 的計劃類 skill 可以把重構限制在清晰邊界內:
1. 為什麼要重構? 2. 哪些文件必須改? 3. 哪些行為不能變? 4. 先跑哪些基線測試? 5. 每一步如何驗證?
這很關鍵。重構不是“看起來更優雅”,而是在行為不變的前提下降低複雜度。
場景四:多 agent 並行開發
Superpowers 素材裏提到 subagent-driven-development 和 dispatching-parallel-agents。這類 skill 適合把複雜任務拆給多個子 agent:
1. 一個 agent 負責實現。 2. 一個 agent 檢查是否符合 spec。 3. 一個 agent 做代碼質量 review。 4. 主 agent 負責彙總和推進。
但這裏有一個前提:任務必須能拆清楚,交付物必須能驗證。否則並行只會放大混亂。
場景五:創業想法驗證
素材裏的 Startup Superpowers 是另一個很好的例子。它不是普通編碼流程,而是把創業驗證流程做成 Claude Code 插件。
它包含這些 slash command:
/whats-next | |
/competitors | |
/market-research | |
/hypotheses | |
/interviews | |
/surveys | |
/mvp |
使用和不使用,對項目開發有什麼差別?
下面這張表是我認為最實際的區別。
它真正改善的是“流程型錯誤”:
1. 沒問清楚就實現。 2. 沒計劃就大改。 3. 沒測試就聲稱完成。 4. 沒找根因就修 bug。 5. 沒 review 就進入下一步。
這些錯誤不是模型能力越強就自然消失。模型越強,寫得越快,流程失控時的破壞範圍反而可能越大。

一個典型開發任務應該怎麼跑?
假設我們要在一個 Web 項目裏增加“用戶導出賬單”功能。沒有 Superpowers 時,agent 可能直接生成接口、按鈕和下載邏輯。
更穩的 Superpowers 流程應該是這樣:
第一步:Brainstorming,先問清楚需求
需要確認的問題包括:
1. 導出的是 PDF、CSV 還是 Excel? 2. 用戶可以導出多久的數據? 3. 是否需要權限校驗? 4. 導出是同步下載還是異步任務? 5. 大數據量時如何處理? 6. 失敗後用戶看到什麼?
這一步不是拖慢進度,而是避免後面返工。
第二步:Writing Plans,把方案拆成可執行任務
一個合格計劃不能只寫:
實現賬單導出功能。它應該更像:
1. 在 billing service 中增加 exportInvoiceCsv(userId, range)。
驗證:新增單元測試覆蓋空數據、正常數據、越權訪問。
2. 在 API route 中接入導出接口。
驗證:請求無權限返回 403,請求成功返回 text/csv。
3. 在前端賬單頁增加下載按鈕。
驗證:瀏覽器點擊後能下載文件,loading 和錯誤狀態正確。這裏的重點是:每一步都有文件邊界和驗證方式。這樣 agent 執行時不容易漂移。
第三步:TDD,用失敗測試鎖住行為
TDD skill 的意義不是“為了測試而測試”,而是先定義行為。
例如導出 CSV 的業務規則可以先寫成測試:
import { describe, expect, it } from "vitest";
import { exportInvoiceCsv } from "./billing-export";
describe("exportInvoiceCsv", () => {
it("exports invoices as csv rows", () => {
const csv = exportInvoiceCsv([
{ id: "inv_001", amount: 1999, currency: "USD" },
{ id: "inv_002", amount: 2999, currency: "USD" },
]);
// 先用測試固定輸出格式,避免實現時隨意漂移
expect(csv).toContain("id,amount,currency");
expect(csv).toContain("inv_001,1999,USD");
expect(csv).toContain("inv_002,2999,USD");
});
});真正的流程是:
1. 寫失敗測試。 2. 確認測試確實失敗。 3. 寫最小實現。 4. 確認測試通過。 5. 再重構。
這比“先實現再補測”更能約束 agent。
第四步:Code Review,不只看能不能跑
代碼能跑不代表可以合併。requesting-code-review 或類似 review skill 應該重點看:
1. 是否符合原計劃。 2. 是否引入越權風險。 3. 是否有大數據量問題。 4. 是否有未覆蓋的錯誤狀態。 5. 是否改動了不相關文件。
對 AI 生成代碼來說,review 的價值非常高。因為 agent 很容易寫出“看起來完整”的實現,但邊界條件和異常路徑不夠嚴謹。
第五步:Verification,完成前必須驗證
最後一步不能只說“測試通過”。不同項目需要不同驗證:

在 Claude Code 中怎麼使用?
根據素材和 Superpowers 項目說明,Claude Code 有兩種安裝路徑。
方式一:從官方插件市場安裝
在 Claude Code 中運行:
/plugin install superpowers@claude-plugins-official方式二:添加 Superpowers marketplace 後安裝
如果使用 Superpowers 自己的 marketplace,可以先註冊:
/plugin marketplace add obra/superpowers-marketplace再安裝:
/plugin install superpowers@superpowers-marketplace安裝後按提示 reload 插件。如果你在多個 workspace 使用 Claude Code,需要注意插件安裝範圍:有些插件適合全局安裝,有些更適合按項目安裝。
Claude Code 裏的使用方式
安裝完成後,不應該把 skill 當成普通文檔手動複製給模型,而是讓 Claude Code 的 Skill / Plugin 機制加載它。
典型觸發方式有兩類:
1. 顯式命令:例如運行某個 slash command。 2. 語義觸發:用戶說“幫我修 bug”“幫我做計劃”“實現這個功能”時,相關 skill 介入。
需要特別強調一個原則:skill 檢查要發生在行動之前。也就是說,遇到調試、計劃、TDD 等任務時,agent 不應該先讀文件、先改代碼、先問一堆問題,而應該先判斷是否有適用 skill。
一個合理的 Claude Code 工作流是:
用戶:幫我修復這個接口偶發 500 的問題。
↓
Claude Code:加載 systematic-debugging skill。
↓
Agent:先建立根因假設,要求復現或查日誌。
↓
Agent:逐個驗證假設,只做最小修復。
↓
Agent:加載 verification-before-completion,跑測試或接口驗證。
↓
Agent:報告根因、改動和驗證結果。這才是 Superpowers 的重點:不是多一個命令,而是改變 agent 的默認行動順序。
在 Codex 中怎麼使用?
Superpowers 也支持 Codex CLI 和 Codex App。根據 Superpowers 項目說明,Codex 側的安裝入口是官方 Codex plugin marketplace。
Codex CLI
在 Codex CLI 中打開插件界面:
/plugins搜索:
superpowers然後選擇 Install Plugin。
Codex App
在 Codex App 中:
1. 打開側邊欄的 Plugins。 2. 在 Coding 分類裏找到 Superpowers。3. 點擊 +並按提示安裝。
Codex 裏的使用方式
Codex 中的核心用法和 Claude Code 類似:安裝插件後,讓 Superpowers 的 skills 參與當前會話。
實際使用時可以這樣理解:
1. 用戶明確點名某個 skill 或插件時,Codex 應優先讀取對應 SKILL.md。2. 用戶沒有點名,但任務明顯匹配某個 skill 的 description 時,也應加載對應 skill。 3. 加載後,Codex 需要先聲明正在使用哪個 skill,以及為什麼使用。 4. 執行過程中,按 skill 的 workflow 做,不要憑記憶跳步驟。
例如你可以這樣發起任務:
使用 Superpowers 的 systematic-debugging,幫我排查這個登錄接口偶發失敗的問題。或者:
用 Superpowers 的 writing-plans,先給這個重構任務寫一份執行計劃。在 Codex 的實際工程項目裏,我更建議把 Superpowers 當作“任務進入方式”,而不是某種一次性提示詞。也就是說,做複雜任務時先讓 agent 進入正確流程,再開始讀代碼和修改文件。
Startup Superpowers 給我們的啓發
另一個項目是 Startup Superpowers。它和 Superpowers 本體不是同一個東西,但很適合作為 skill 方法論的應用案例。
Startup Superpowers 解決的不是“怎麼寫代碼”,而是“創業想法怎麼驗證”。它把早期創業驗證拆成:
1. 競品分析。 2. 市場研究。 3. 假設管理。 4. 用戶訪談。 5. 問卷調查。 6. MVP 設計。 7. 下一步規劃。
更重要的是,它把所有狀態寫在項目目錄的 startup/ 下面,用 Markdown 存儲。這有幾個好處:
1. 產物可讀,不被 SaaS 鎖住。 2. 可以提交到 Git,看到想法如何演進。 3. 可以用 Obsidian 瀏覽證據圖譜。 4. agent 之間可以通過文件交接,而不是依賴聊天上下文。
這說明 skill 的真正價值不是“某個模型會了某項技能”,而是把一個專業流程變成可執行、可追蹤、可覆盤的工作系統。
實戰建議:怎麼把 Superpowers 用好?
1. 不要把 Skill 當萬能藥
Skill 是流程約束,不是質量保證。它能減少常見流程錯誤,但不能替你判斷產品取捨、架構邊界和業務優先級。
如果需求本身不清楚,Skill 會幫助澄清;但最終取捨還是需要人做。
2. 複雜任務先走 plan,簡單任務不要過度工程化
我的經驗判斷是:
3. 讓 skill 寫進項目規範
如果團隊長期使用 Claude Code 或 Codex,建議把下面內容寫進項目級說明文件,例如 AGENTS.md、CLAUDE.md 或插件配置:
複雜功能開發必須先計劃再實現。
bug 修復必須先使用 systematic debugging。
有測試條件時必須優先 TDD。
完成前必須運行可驗證檢查,並報告結果。
禁止無關重構和大範圍格式化。這些規則看似普通,但對 AI agent 很重要。因為 agent 默認會傾向於“完成用戶請求”,而不是“最小風險地完成用戶請求”。
4. 每次都重新加載,不要靠記憶
素材裏有一個很實用的提醒:Skill 內容會演進,不要因為“我記得這個 skill 大概是什麼”就跳過加載。
這點對 agent 尤其關鍵。人可以靠經驗靈活處理,但 agent 的“記得”經常只是上下文裏的近似印象。真正可靠的做法是讀取當前 skill 文件,按當前版本執行。
5. 明確區分 Skill、Memory 和 Plan
這三個東西容易混:
1. Skill 規定“修 bug 要系統調試”。 2. Memory 記錄“這個用戶偏好 bun,不喜歡 npx”。 3. Plan 記錄“這次修復要先看登錄接口,再補測試,再驗證”。
這三個合在一起,才會讓 agent 的行為既穩定,又貼合當前項目。
常見誤區
誤區一:有了 Skill,就不用寫清楚需求
不對。Skill 可以幫助澄清需求,但不能憑空知道真實業務。
你仍然需要提供:
1. 目標。 2. 約束。 3. 優先級。 4. 驗收標準。
Skill 只是讓 agent 更有紀律地追問和執行。
誤區二:Skill 越多越好
也不對。Skill 太多會導致觸發混亂,甚至互相沖突。
好的 skill 應該滿足三個條件:
1. 場景清晰。 2. 觸發條件明確。 3. 流程能驗證。
如果一個 skill 只是寫了一堆泛泛建議,它對 agent 的實際幫助有限。
誤區三:只要裝了插件,agent 就一定會按流程做
不能這麼理解。不同宿主的插件機制、觸發規則和上下文優先級會有差異。
更穩的做法是:在關鍵任務開頭明確要求使用對應 skill。例如:
請使用 Superpowers 的 systematic-debugging 流程,先不要改代碼,先列根因假設並逐項驗證。或者:
請使用 Superpowers 的 writing-plans,先產出可執行計劃,等我確認後再實現。這樣可以減少 agent 誤判任務類型的概率。
我會怎麼在真實項目裏使用它?
如果是我的項目,我會這樣分層使用。
日常小任務
保持輕量。讓 agent 直接改,但要求:
1. 改動範圍小。 2. 不做無關重構。 3. 完成後運行必要驗證。
有風險的 bug
明確調用:
使用 systematic-debugging。先列可能根因,不要馬上修改代碼。然後要求 agent 把驗證結果寫清楚:
1. 哪個假設被排除。 2. 哪個假設被證實。 3. 根因是什麼。 4. 為什麼這個修復是最小修復。
新功能或重構
明確調用:
使用 brainstorming 和 writing-plans。先產出計劃,不要實現。計劃確認後再讓它進入實現階段。實現過程中儘量讓測試先行。
合併或發佈前
明確調用:
使用 verification-before-completion 和 requesting-code-review,檢查是否真的可以合併。這一步能擋住很多“看起來完成了”的問題。
總結
Superpowers Skill 的本質,是把軟件工程流程變成 AI agent 可執行的規則系統。
它解決的不是“AI 會不會寫代碼”,而是:
1. 會不會先澄清需求。 2. 會不會制定可驗證計劃。 3. 會不會測試先行。 4. 會不會系統性調試。 5. 會不會完成前實際驗證。 6. 會不會把複雜任務拆給合適的執行單元。
在沒有 skill 的情況下,開發者需要不斷提醒 agent 不要跳步驟;使用 Superpowers 後,這些提醒可以沉澱為穩定流程。
對 Claude Code 和 Codex 來說,Superpowers 的正確使用方式不是“記住一段提示詞”,而是安裝插件、加載 skill、讓 agent 在任務開始前進入正確的工作流。複雜項目裏,這種流程約束的價值會越來越明顯。
如果你已經把 AI coding agent 用進真實項目,我建議至少從三個 skill 開始:
1. systematic-debugging:防止亂猜 bug。2. writing-plans:防止複雜任務漂移。3. verification-before-completion:防止沒有驗證就宣佈完成。
這三個 skill 不會讓開發變得神奇,但會讓 agent 的行為更像一個有工程紀律的合作者。
參考資料
1. Superpowers GitHub: https://github.com/obra/superpowers 2. Startup Superpowers GitHub: https://github.com/SergeiGorbatiuk/startup-superpowers
2026.06.06 20:54
滬 · 趙巷
📌 聲明:本文由 AI 輔助完成
寫 AI,寫成長,偶爾寫投資。關注沐風,不定期更新,全是乾貨。