「Superpowers」安利一個19萬Star的必裝插件，能讓你的Agent體驗直接質變。

前兩日我又去睇咗一眼 Superpowers。

結果發現一件有啲離譜嘅事。

之前大家仲話佢係 11 萬 Star 嘅項目，而家 GitHub 上已經接近 19 萬 Star 喇。

倉庫喺度：

https://github.com/obra/superpowers

我知，一見到呢啲 Star 數，好多人第一個反應係：

又來？

又係啲乜嘢一鍵令 Agent 變強十倍嘅玄學插件？

但係 Superpowers 呢樣嘢，我覺得真係有啲唔同。

佢唔係令模型突然間變聰明。

亦都唔係畀 Agent 塞一個新嘅 MCP 工具箱。

佢更加似係畀 Agent 裝咗一套工作習慣。

或者講得直接啲：

佢唔係畀 Agent 加外掛。

佢係將 Agent 由「聰明但係莽撞嘅實習生」，強行訓練成「識得流程嘅工程師」。

呢樣就真係要命喇。

因為而家絕大多數人用 Agent，真正嘅問題已經唔係「模型識唔識寫 code」。

佢梗係識寫啦。

佢甚至寫得太快添。

真正嘅問題係：佢太容易搶跑。

你叫佢「幫我做個功能」，佢口講「我幫你分析嚇」，手上面已經開始開新 file。

你仲未諗清楚邊界，佢已經寫好第一個版本。

你仲未確認方案，佢已經信心滿滿咁話「完成咗」。

然後你打開嚟睇。

嗯。

的確完成咗。

完成咗一個你並唔想要嘅嘢。

1. Superpowers 究竟係乜嘢

Superpowers 官方自己嘅定義好簡單。

佢係一套畀 Coding Agent 用嘅完整軟件開發方法論，建立喺一組可組合嘅 Skills 上面。

講人話就係：

一堆專門管流程嘅 Skill，加一套強制 Agent 幾時要用佢哋嘅規則。

佢而家支持嘅範圍都幾廣。

Claude Code、Codex CLI、Codex App、OpenCode、Cursor、Gemini CLI、GitHub Copilot CLI 呢啲都用得。

呢點我覺得好關鍵。

因為佢唔係某一個 Agent 嘅細路玩具，而係更加似一套跨平台嘅「Agent 工作流協議」。

你今日用 Claude Code，佢管你。

你聽日用 Codex，佢都管你。

你後日換 OpenCode，佢一樣管你。

呢樣嘢最有意思嘅地方係，佢唔係一個單點能力。

唔係「幫你寫測試」嘅 Skill。

亦都唔係「幫你開分支」嘅 Skill。

而係一成套鏈路：

諗清楚需求。

隔離工作區。

拆計劃。

測試先行。

多 Agent 執行。

代碼審查。

最後驗證。

聽起身好似好傳統。

但問題係，Agent 時代最缺嘅正正就係呢種傳統。

我哋以前寫 code 慢，所以流程覺得煩。

而家 Agent 寫 code 太快，流程反而變成咗剎車同方向盤。

冇方向盤嘅跑車，馬力越大，死得越快。

2. 佢解決嘅唔係能力問題，係失控問題

好多人對 Agent 有一個誤會。

覺得只要模型夠強，咩流程都可以慳返。

我以前都咁諗過。

模型都已經可以一鑊過，仲要咩需求確認、測試、review、驗證？

直接叫佢做就得啦。

但係用多咗之後你會發現，Agent 最可怕嘅唔係唔識做嘢。

而係佢太會扮識做嘢。

佢可以將一個未諗清楚嘅需求，寫成一堆睇起嚟好完整嘅 code。

佢可以將一個有問題嘅方案，包裝成「當前實現已覆蓋主要場景」。

佢可以喺測試未過嘅時候，同你講「理論上應該可以 work」。

你話嬲唔嬲。

Superpowers 解決嘅就係呢個問題。

佢唔同 Agent 講心靈雞湯。

佢直接將流程釘入執行鏈路裏面。

例如官方 README 最核心嘅基礎工作流，大概係呢幾步：

1. brainstorming：鬱手前先將需求傾清楚
2. using-git-worktrees：確認方案後開隔離工作區
3. writing-plans：將任務拆成 2 至 5 分鐘一嚿
4. subagent-driven-development 或 executing-plans：按計劃執行
5. test-driven-development：先寫失敗測試，再寫 code
6. requesting-code-review：做 code review
7. finishing-a-development-branch：收尾、驗證、決定合併定係保留

你睇，呢套嘢一啲都唔玄學。

甚至有啲老派。

但正正因為老派，所以有效。

佢本質上係喺度提醒 Agent：

別急。

先諗清楚，先好鬱手。

呢八個字，聽起嚟好似廢話。

但而家 90% 嘅 AI 編程出事，基本上都死喺呢八個字上面。

3. brainstorming：先將你腦入面嘅霧逼出嚟

我覺得 Superpowers 裏面最重要嘅第一個 Skill，就係 brainstorming。

好多人一聽到「腦力激盪」，就以為係叫 AI 陪你發散諗法。

不是。

佢更加似一個好煩人嘅產品經理。

你話你想做個功能。

佢唔會即刻話「好，我開始實現」。

佢會先問你：

你到底想解決咩問題？

邊個會用？

成功標準係咩？

邊界喺邊度？

邊啲嘢今次唔做？

方案 A、B、C 各有咩代價？

聽起嚟煩啫。

的確煩。

但我而家越嚟越覺得，好嘅 Agent 就應該喺呢個階段煩你。

因為人類提需求嘅時候，大腦多數時候唔係一個清晰規格，而係一團霧。

我哋會話「幫我做個好用啲嘅管理頁面」。

但係乜嘢叫好用？

係篩選更快？

係批量操作更順？

係權限更加清楚？

係加載速度唔好慢？

定係老細望落覺得高級？

呢個完全係五個唔同嘅需求。

如果 Agent 唔問，佢就只能靠估。

而 Agent 一旦開始估，就進入咗最危險嘅狀態：

佢估得好有信心。

brainstorming 嘅價值，就係喺寫 code 之前，先將呢團霧擰成一份你會點頭嘅設計。

唔係長篇大論塞畀你。

而係分段畀你睇，叫你逐個確認。

確認完之後，先繼續做。

呢個就好似做手術前畫線。

畫線嘅時候慢啲冇問題。

真正落刀之後先話「我好似理解錯咗」，咁就真係尷尬。

4. writing-plans：將大工作切開做 Agent 食得落嘅細嚿

需求確認完，Superpowers 都唔會即刻開寫。

佢仲要行多一步：writing-plans。

呢一步我特別鍾意。

因為佢唔係寫嗰種「第一階段完成基礎功能、第二階段優化體驗、第三階段上線發佈」嘅廢話計劃。

嗰種計劃除咗顯得你好專業之外，一啲用都冇。

Superpowers 要求嘅係好仔細嘅執行計劃。

仔細到每個任務最好 2 至 5 分鐘搞得掂。

仔細到要話畀 Agent 聽改邊個 file、寫咩測試、行咩 command、預期結果係咩。

聽起嚟好似有啲誇張。

但你換個角度諗，就好合理。

Agent 嘅問題唔係做唔到複雜任務。

Agent 嘅問題係，一旦 context 太大、目標太虛，佢就會開始自由發揮。

自由發揮呢個詞，喺創作入面好靚。

喺工程入面好嚇人。

所以 writing-plans 做嘅嘢，就係將「做一個系統」拆成「先寫呢個測試，睇佢 failed；再補呢一細段實現，睇佢 pass；然後 commit」。

佢將一隻大象切成肉片。

Agent 一嚿一嚿咁食。

你唔需要相信佢有幾自覺。

你只需要令每一步都細到佢好難走歪。

呢個亦都係我覺得 Superpowers 最反直覺嘅地方。

佢唔係鼓勵 Agent 更加自由。

佢係限制 Agent 嘅自由。

但限制完之後，反而更加勁。

5. TDD：先令測試紅，再令佢綠

Superpowers 入面仲有一個好硬嘅 Skill：test-driven-development。

佢嘅態度基本上可以翻譯成一句話：

未見到失敗嘅測試之前，唔準寫生產 code。

呢句話喺傳統工程師圈子已經拗咗幾十年。

有人愛到死，有人煩到死。

但放喺 Agent 時代，我反而覺得更加有必要。

因為人類偷懶嘅時候，至少知道自己喺度偷懶。

Agent 偷懶嘅時候，會將偷懶包裝成「已完成實現並考慮咗邊界情況」。

呢樣先最離譜。

測試先行嘅好處，係逼 Agent 先講清楚：

我到底要證明咩行為？

咩輸入應該得到咩輸出？

咩失敗先算正常失敗？

冇呢個步驟，你後面見到嘅「測試通過」，含金量好低。

因為好可能佢只係幫現有 code 補咗一個永遠通過嘅測試。

Superpowers 嘅 TDD 規則好死板。

先寫測試。

運行。

見到佢因為功能唔存在而失敗。

再寫最少嘅 code 令佢通過。

再重構。

一輪一輪咁做。

呢套嘢睇落好似慢。

但 Agent 寫 code 本身就快。

而家真正稀缺嘅唔係速度。

係真實性。

我寧願佢慢啲，都唔想佢 30 秒就遞上一碟「應該可以」。

6. subagent-driven-development：唔係開多個就搞得掂

而家好多工具都講緊多 Agent。

聽起嚟好熱鬧。

一個負責寫前端。

一個負責寫後端。

一個負責寫測試。

一個負責 review。

似唔似開會？

像。

但多 Agent 呢樣嘢，如果冇流程，基本上就係多人同時亂寫。

人類團隊最怕咩？

唔係人少。

係個個都好勤力，但方向唔同。

Agent 團隊都一樣。

Superpowers 嘅 subagent-driven-development 比較有意思嘅地方，係佢唔係簡單咁「開多幾個 Agent 並行做嘢」。

佢強調嘅係：

每個任務都畀一個乾淨 context 嘅新 subagent。

做完之後，先做規格審查。

睇佢有冇按計劃做，有冇做多咗，有冇漏做。

規格過咗，再做 code 質素審查。

睇有冇複雜度、測試、維護性呢啲問題。

呢個就好似一個小型工程團隊。

唔係「大家一齊衝」。

而係「有人執行，有人驗收，有人挑剔」。

我覺得呢個先係多 Agent 真正應該有嘅樣。

唔係為咗炫耀技術。

係為咗將 context 隔離、職責分開、審查鏈路固定落嚟。

講白啲，多 Agent 如果只係多幾把口，咁冇意思。

多 Agent 真正有價值，係多幾個互相制衡嘅角色。

7. systematic-debugging：唔好再靠感覺整 Bug

仲有一個我覺得非常值得單獨講嘅，係 systematic-debugging。

呢樣嘢解決嘅係另一個 Agent 成日出事嘅場景：

整 Bug 整到變玄學。

你畀 Agent 一個 error。

佢一睇，啪，改一行。

不行。

再改一行。

都唔得。

繼續轉個姿勢。

到最後 code 畀佢整到面目全非，Bug 仲喺度。

嗰陣你問佢點解咁改。

佢會話：

「我懷疑問題可能嚟自……」

朋友們。

「我懷疑」呢三個字，喺 Debug 嘅時候真係好危險。

Debug 唔係算命。

Debug 應該係證據鏈。

systematic-debugging 呢類 Skill 嘅價值，就係將 Agent 由「估原因」拉返去「揾證據」。

先重現。

再定位。

再提出最小修復。

再驗證。

唔好一嚟就掄錘仔。

Agent 好識掄錘仔。

所以你更加需要一套流程話畀佢聽：

先將釘子揾出嚟。

8. verification-before-completion：最救到命係呢一步

我而家見到 Agent 話「完成咗」，都有啲 PTSD。

唔係話佢一定冇完成。

而係你要問一句：

你點證明你完成咗？

呢個就係 verification-before-completion 嘅價值。

好多時，Agent 嘅「完成」其實只係：

code 寫咗。

file 改咗。

logic 睇落通咗。

但測試行咗未？

build 過咗未？

lint 過咗未？

頁面打開睇咗未？

error log 清咗未？

user path 走過咗未？

呢啲先係真正嘅完成。

Superpowers 好強調一個思想：

證據先於結論。

唔好先話「整好咗」，再補一句「理論上」。

先將驗證 command 行出嚟。

先睇完結果。

再話整好咗。

呢條我覺得所有用 Agent 嘅人都應該貼喺 mon 上面。

因為 Agent 時代最平嘅係產出。

最貴嘅係確認。

你叫佢寫 1000 行 code，可能幾分鐘。

你確認呢 1000 行 code 冇將你個 project 搞冧，可能要成個下晝。

Superpowers 嘅意義，就係將「確認」呢件事前置、拆散、制度化。

唔係最後靠你執屎。

9. 佢點解可以令 Agent 體驗質變

講到呢度，你應該睇得出嚟。

Superpowers 嘅質變，唔係某一個單獨 Skill 有幾神。

而係佢將 Agent 嘅工作方式由：

「你講一句，佢做一嚿」

變成咗：

「佢先確認，再計劃，再拆解，再測試，再執行，再審查，再驗證」。

呢中間最大嘅變化，唔係 code 質素。

而係你嘅心理負擔會明顯下降。

以前你用 Agent，好似望住一個手速好快但唔多靠得住嘅人。

你一眨眼，佢就可能喺 project 開咗 8 個新 file。

你再一眨眼，佢已經改咗個架構。

你問佢點解。

佢話「為咗更好地支持未來擴展」。

你老母。

我只係想改個掣。

裝咗 Superpowers 之後，至少佢會更傾向停落嚟問你：

今次到底要唔要未來擴展？

呢個方案係咪 over-design？

測試應該點寫先？

做完之後點證明？

呢樣已經好值錢。

因為你買嘅唔係一個更加勤力嘅 Agent。

你買嘅係一個更加少自作主張嘅 Agent。

呢句說話可能有啲反常識。

但我而家真心覺得：

Agent 最稀缺嘅品質，唔係聰明。

係剋制。

10. 點樣安裝

安裝方式要睇你用邊個工具。

如果你用 Claude Code，可以經官方 plugin 市場：

/plugin install superpowers@claude-plugins-official

都可以加 Superpowers 自己嘅 marketplace：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

如果你用 Codex CLI，直接開 plugin 入口：

/plugins

然後搜：

superpowers

揀 Install Plugin 就得。

如果你用 Codex App，喺側邊欄點 Plugins，喺 Coding 分類度揾 Superpowers，撳加號安裝。

Cursor 可以搜 plugin，亦都可以喺 Agent chat 度：

/add-plugin superpowers

Gemini CLI 就係：

gemini extensions install https://github.com/obra/superpowers

OpenCode、GitHub Copilot CLI 都支援，詳細 command 可以睇 repo README。

有個小提醒。

Superpowers 唔係嗰種裝完即刻彈個靚靚面板嘅嘢。

佢更加似係靜靜雞入咗你嘅 Agent 行為裏面。

真正生效嘅時候，你會發現佢喺一啲關鍵節點開始「煩你」。

例如鬱手前提醒要先 brainstorm。

例如完成前提醒要驗證。

例如遇到 Bug 時唔畀 Agent 憑感覺亂改。

一開始你可能會覺得：

點解咁多規矩。

用兩日之後你會發現：

好彩有呢啲規矩。

寫喺最後

我而家越嚟越覺得，AI 編程正喺度進入一個好微妙嘅階段。

早期大家睇模型能力。

邊個補充得更準，邊個 context 更長，邊個生成速度更快。

但係去到而家，模型都已經夠曬打。

真正拉開差距嘅，反而係流程。

同一個 Agent。

你叫佢自由發揮，佢就係一個手速超快嘅野路子工程師。

你畀佢 Superpowers，佢先似一個被流程管住嘅團隊成員。

呢個亦都係點解我覺得 Superpowers 值得裝。

唔係因為佢可以令 Agent 變成天才。

而係因為佢可以令 Agent 少犯好多「天才最容易犯嘅錯」：

自信。

搶跑。

over-design。

唔驗證。

將猜測當結論。

呢幾個毛病，人類工程師都有。

只係 Agent 犯起嚟更快、更順、仲難頂。

所以你問我 Superpowers 到底值唔值得裝？

我嘅答案好簡單。

如果你只係偶爾叫 AI 寫個 script，可能無所謂。

但只要你真係想將 Agent 當成長期生產力，而唔係一次性玩具。

咁佢就係必裝。

唔係可選項目。

係安全帶。

以上，既然睇到呢度，如果覺得唔錯，順手畀個讚、睇、轉發三連啦，如果想第一時間收到推送，都可以畀我一個星標⭐～多謝你睇我嘅文章，我哋，下次再見。

/ 作者：可可耐特

/ 投稿或爆料，請聯絡電郵：aoshindragon@163.com

前兩天我又去看了一眼 Superpowers。

結果發現一個有點離譜的事。

之前大家還在說它是 11 萬 Star 的項目，現在 GitHub 上已經接近 19 萬 Star 了。

倉庫在這：

https://github.com/obra/superpowers

我知道，一看到這種 Star 數，很多人第一反應是：

又來？

又是什麼一鍵讓 Agent 變強十倍的玄學插件？

但 Superpowers 這個東西，我覺得真不太一樣。

它不是讓模型突然變聰明。

也不是給 Agent 塞一個新的 MCP 工具箱。

它更像是給 Agent 裝了一套工作習慣。

或者說得更直白一點：

它不是給 Agent 加外掛。

它是把 Agent 從“聰明但莽撞的實習生”，強行訓練成“懂流程的工程師”。

這就很要命了。

因為現在絕大多數人用 Agent，真正的問題已經不是“模型會不會寫代碼”。

它當然會寫。

它甚至寫得太快了。

真正的問題是：它太容易搶跑。

你給它一句“幫我做個功能”，它嘴上說“我來幫你分析一下”，手上已經開始新建文件了。

你還沒想清楚邊界，它已經寫完第一版了。

你還沒確認方案，它已經自信滿滿地說“已完成”了。

然後你打開一看。

嗯。

確實完成了。

完成了一個你並不想要的東西。

1. Superpowers 到底是個啥

Superpowers 官方自己的定義很簡單。

它是一套給 Coding Agent 用的完整軟件開發方法論，建立在一組可組合的 Skills 上。

說人話就是：

一堆專門管流程的 Skill，加上一套強制 Agent 什麼時候該用它們的規則。

它現在支持的範圍也挺廣。

Claude Code、Codex CLI、Codex App、OpenCode、Cursor、Gemini CLI、GitHub Copilot CLI 這些都能用。

這點我覺得很關鍵。

因為它不是某一個 Agent 的小玩具，而是更像一套跨平台的“Agent 工作流協議”。

你今天用 Claude Code，它管你。

你明天用 Codex，它也管你。

你後天換 OpenCode，它還是管你。

這玩意最有意思的地方在於，它不是一個單點能力。

不是“幫你寫測試”的 Skill。

也不是“幫你開分支”的 Skill。

而是一整套鏈路：

想清楚需求。

隔離工作區。

拆計劃。

測試先行。

多 Agent 執行。

代碼審查。

最後驗證。

這聽起來好像很傳統。

但問題是，Agent 時代最缺的恰恰就是這種傳統。

我們過去寫代碼慢，所以流程顯得煩。

現在 Agent 寫代碼太快，流程反而變成了剎車和方向盤。

沒有方向盤的跑車，馬力越大，死得越快。

2. 它解決的不是能力問題，是失控問題

很多人對 Agent 有一個誤會。

覺得只要模型夠強，就什麼流程都可以省。

我以前也這麼想過。

模型都能一把梭了，還要什麼需求確認、測試、review、驗證？

直接讓它幹就完事了。

但用多了以後你會發現，Agent 最可怕的不是不會幹活。

而是它太會假裝自己會幹活。

它能把一個沒想清楚的需求，寫成一堆看起來很完整的代碼。

它能把一個有問題的方案，包裝成“當前實現已覆蓋主要場景”。

它能在測試沒跑通的時候，跟你說“理論上應該可以工作”。

你說氣不氣。

Superpowers 解決的就是這個問題。

它不跟 Agent 講雞湯。

它直接把流程釘進執行鏈路裏。

比如官方 README 裏最核心的基礎工作流，大概是這幾步：

1. brainstorming：動手前先把需求聊清楚
2. using-git-worktrees：確認方案後開隔離工作區
3. writing-plans：把任務拆成 2 到 5 分鐘一小塊
4. subagent-driven-development 或 executing-plans：按計劃執行
5. test-driven-development：先寫失敗測試，再寫代碼
6. requesting-code-review：做代碼審查
7. finishing-a-development-branch：收尾、驗證、決定合併還是保留

你看，這套東西一點都不玄學。

甚至有點老派。

但正因為老派，所以有效。

它本質上是在提醒 Agent：

別急。

先想明白，再動手。

這八個字，聽起來像廢話。

但現在 90% 的 AI 編程翻車，基本都死在這八個字上。

3. brainstorming：先把你腦子裏的霧逼出來

我覺得 Superpowers 裏最重要的第一個 Skill，就是 brainstorming。

很多人一聽“頭腦風暴”，就以為是讓 AI 陪你發散想法。

不是。

它更像一個很煩人的產品經理。

你說你想做個功能。

它不會立刻說“好的，我開始實現”。

它會先問你：

你到底想解決什麼問題？

誰會用？

成功標準是什麼？

邊界在哪？

哪些東西這次不做？

方案 A、B、C 各有什麼代價？

聽起來煩吧。

確實煩。

但我現在越來越覺得，好的 Agent 就應該在這個階段煩你。

因為人類提需求的時候，腦子裏大多數時候不是一個清晰規格，而是一團霧。

我們會說“幫我做個好用一點的管理頁面”。

但什麼叫好用？

是篩選更快？

是批量操作更順？

是權限更清楚？

是加載速度別卡？

還是老闆看着覺得高級？

這完全是五個需求。

如果 Agent 不問，它就只能猜。

而 Agent 一旦開始猜，就進入了最危險的狀態：

它猜得很自信。

brainstorming 的價值，就是在寫代碼之前，先把這團霧擰成一份你能點頭的設計。

不是長篇大論糊你臉上。

而是分段給你看，讓你一塊一塊確認。

確認完之後，才往下走。

這就像做手術前畫線。

畫線的時候慢一點沒關係。

真下刀了再說“我好像理解錯了”，那就真尷尬了。

4. writing-plans：把大活切成 Agent 能啃的小塊

需求確認完，Superpowers 也不會立刻開寫。

它還要再走一步：writing-plans。

這一步我特別喜歡。

因為它不是寫那種“第一階段完成基礎功能、第二階段優化體驗、第三階段上線發佈”的廢話計劃。

那種計劃除了顯得你很專業，沒有任何用。

Superpowers 要的是非常細的執行計劃。

細到每個任務最好 2 到 5 分鐘能完成。

細到要告訴 Agent 改哪個文件、寫什麼測試、跑什麼命令、預期結果是什麼。

這聽起來有點誇張。

但你換個角度想，就很合理了。

Agent 的問題不是幹不了複雜任務。

Agent 的問題是，一旦上下文太大、目標太虛，它就會開始自由發揮。

自由發揮這個詞，在創作裏很美。

在工程裏很嚇人。

所以 writing-plans 乾的事，就是把“做一個系統”拆成“先寫這個測試，看它失敗；再補這一小段實現，看它通過；然後提交”。

它把大象切成肉片。

Agent 一片一片吃。

你不需要相信它有多自覺。

你只需要讓每一步都小到它很難跑偏。

這也是我覺得 Superpowers 最反直覺的地方。

它不是鼓勵 Agent 更自由。

它是限制 Agent 的自由。

但限制完以後，反而更強。

5. TDD：先讓測試紅，再讓它綠

Superpowers 裏面還有一個非常硬的 Skill：test-driven-development。

它的態度基本可以翻譯成一句話：

沒先看到失敗測試，就不許寫生產代碼。

這句話在傳統工程師圈子裏已經吵了幾十年。

有人愛得要死，有人煩得要死。

但放到 Agent 時代，我反而覺得它更有必要了。

因為人類偷懶的時候，至少知道自己在偷懶。

Agent 偷懶的時候，會把偷懶包裝成“已完成實現並考慮了邊界情況”。

這才是最離譜的。

測試先行的好處，是它逼 Agent 先說清楚：

我到底要證明什麼行為？

什麼輸入應該得到什麼輸出？

什麼失敗才算正常失敗？

沒有這個步驟，你後面看到的“測試通過”，含金量很低。

因為很可能它只是給已有代碼補了一個永遠通過的測試。

Superpowers 的 TDD 規則就很死板。

先寫測試。

運行。

看到它因為功能不存在而失敗。

再寫最少的代碼讓它通過。

再重構。

一輪一輪來。

這套東西看起來慢。

但 Agent 寫代碼本來就快。

現在真正稀缺的不是速度。

是真實性。

我寧願它慢一點，也不想它 30 秒給我端上來一盤“應該可以”。

6. subagent-driven-development：不是多開就完事了

現在很多工具都在講多 Agent。

聽起來很熱鬧。

一個負責寫前端。

一個負責寫後端。

一個負責寫測試。

一個負責 review。

像不像開會？

像。

但多 Agent 這件事，如果沒有流程，基本就是多人同時亂寫。

人類團隊最怕什麼？

不是人少。

是每個人都很勤奮，但方向不一樣。

Agent 團隊也一樣。

Superpowers 的 subagent-driven-development 比較有意思的點，是它不是簡單地“多開幾個 Agent 並行幹活”。

它強調的是：

每個任務都給一個乾淨上下文的新 subagent。

幹完以後，先做規格審查。

看它有沒有按計劃做，有沒有多做，有沒有漏做。

規格過了，再做代碼質量審查。

看有沒有複雜度、測試、維護性這些問題。

這就很像一個小型工程團隊。

不是“大家一起衝”。

而是“有人執行，有人驗收，有人挑刺”。

我覺得這才是多 Agent 真正該有的樣子。

不是為了炫技。

是為了把上下文隔離、職責分開、審查鏈路固定下來。

說白了，多 Agent 如果只是多幾個嘴，那沒意義。

多 Agent 真正有價值，是多幾個互相制衡的角色。

7. systematic-debugging：別再靠感覺修 Bug

還有一個我覺得非常值得單獨說的，是 systematic-debugging。

這玩意解決的是另一個 Agent 高頻翻車現場：

修 Bug 修成玄學。

你給 Agent 貼一個報錯。

它一看，啪，改一行。

不行。

再改一行。

還不行。

繼續換個姿勢。

到最後代碼被它按摩得面目全非，Bug 還在。

這時候你問它為什麼這麼改。

它會說：

“我懷疑問題可能來自……”

朋友們。

“我懷疑”這三個字，在 Debug 場景裏真的很危險。

Debug 不是算命。

Debug 應該是證據鏈。

systematic-debugging 這類 Skill 的價值，就是把 Agent 從“猜原因”拉回“找證據”。

先復現。

再定位。

再提出最小修復。

再驗證。

不要一上來就掄錘子。

Agent 很擅長掄錘子。

所以你更需要一套流程告訴它：

先把釘子找出來。

8. verification-before-completion：最救命的是這一步

我現在看到 Agent 說“完成了”，都有點 PTSD。

不是說它一定沒完成。

而是你得問一句：

你怎麼證明你完成了？

這就是 verification-before-completion 的價值。

很多時候，Agent 的“完成”其實只是：

代碼寫了。

文件改了。

邏輯看起來通了。

但測試跑了嗎？

構建過了嗎？

lint 過了嗎？

頁面打開看了嗎？

報錯日誌清了嗎？

用戶路徑走了嗎？

這些才是真正的完成。

Superpowers 很強調一個思想：

證據先於結論。

別先說“修好了”，再補一句“理論上”。

先把驗證命令跑出來。

先把結果看完。

再說修好了。

這條我覺得所有用 Agent 的人都應該貼在顯示器上。

因為 Agent 時代最便宜的是產出。

最貴的是確認。

你讓它寫 1000 行代碼，可能幾分鐘。

你確認這 1000 行代碼沒把你的項目搞炸，可能要一下午。

Superpowers 的意義，就是把“確認”這件事前置、拆散、制度化。

不是最後靠你擦屁股。

9. 它為什麼能讓 Agent 體驗質變

說到這裏，你應該能看出來了。

Superpowers 的質變，不是某個單獨 Skill 有多神。

而是它把 Agent 的工作方式從：

“你說一句，它幹一坨”

變成了：

“它先確認，再計劃，再拆解，再測試，再執行，再審查，再驗證”。

這中間最大的變化，不是代碼質量。

而是你的心理負擔會明顯下降。

以前你用 Agent，像盯着一個手速很快但不太靠譜的人。

你一眨眼，它就可能在項目裏開了 8 個新文件。

你再一眨眼，它已經把架構改了。

你問它為什麼。

它說“為了更好地支持未來擴展”。

你大爺的。

我就想改個按鈕。

裝上 Superpowers 以後，至少它會更傾向於停下來問你：

這次到底要不要未來擴展？

這個方案是不是過度設計？

測試該先怎麼寫？

做完之後怎麼證明？

這就已經很值錢了。

因為你買的不是一個更勤快的 Agent。

你買的是一個更少自作主張的 Agent。

這句話可能有點反常識。

但我現在真心覺得：

Agent 最稀缺的品質，不是聰明。

是剋制。

10. 怎麼安裝

安裝方式要看你用哪個工具。

如果你用 Claude Code，可以直接走官方插件市場：

/plugin install superpowers@claude-plugins-official

也可以添加 Superpowers 自己的 marketplace：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

如果你用 Codex CLI，直接打開插件入口：

/plugins

然後搜：

superpowers

選 Install Plugin 就行。

如果你用 Codex App，在側邊欄點 Plugins，在 Coding 分類裏找 Superpowers，點加號安裝。

Cursor 裏可以搜插件，也可以在 Agent chat 裏：

/add-plugin superpowers

Gemini CLI 則是：

gemini extensions install https://github.com/obra/superpowers

OpenCode、GitHub Copilot CLI 也都支持，具體命令可以看倉庫 README。

有個小提醒。

Superpowers 不是那種裝完馬上彈個炫酷面板的東西。

它更像是悄悄住進你的 Agent 行為裏。

真正生效的時候，你會發現它在一些關鍵節點開始“煩你”。

比如動手前提醒要先 brainstorm。

比如完成前提醒要驗證。

比如遇到 Bug 時不讓 Agent 憑感覺亂改。

一開始你可能會覺得：

咋這麼多規矩。

用兩天之後你會發現：

幸好有這些規矩。

寫在最後

我現在越來越覺得，AI 編程正在進入一個很微妙的階段。

早期大家拼的是模型能力。

誰補全更準，誰上下文更長，誰生成速度更快。

但到了現在，模型都已經足夠能打了。

真正拉開差距的，反而是流程。

同一個 Agent。

你讓它自由發揮，它就是一個手速超快的野路子工程師。

你給它 Superpowers，它才更像一個被流程管住的團隊成員。

這也是為什麼我覺得 Superpowers 值得裝。

不是因為它能讓 Agent 變成天才。

而是因為它能讓 Agent 少犯很多“天才最容易犯的錯”：

自信。

搶跑。

過度設計。

不驗證。

把猜測當結論。

這幾個毛病，人類工程師也有。

只不過 Agent 犯起來更快、更絲滑、更難繃。

所以你問我 Superpowers 到底值不值得裝？

我的答案很簡單。

如果你只是偶爾讓 AI 寫個腳本，可能無所謂。

但只要你真的想把 Agent 當長期生產力，而不是當一次性玩具。

那它就是必裝。

不是可選項。

是安全帶。

以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章，我們，下次再見。

/ 作者：可可耐特

/ 投稿或爆料，請聯繫郵箱：aoshindragon@163.com