Harness｜12 解剖·Superpowers——把"軟件工程方法論"裝進harness的嘗試
整理版優先睇
Superpowers 將軟件工程方法論強製成硬約束，讓AI agent按紀律開發
呢篇文章由Jesse Vincent（GitHub @obra）創作，佢係Simon Willison口中「coding agent最有創造力嘅用戶之一」。Superpowers 2025年10月發佈，唔似傳統harness工具專注技術細節（工具設計、context管理），而係問：如果harness嘅核心抽象係「軟件開發方法論」本身，會點？結論係：將團隊紀律物化到系統，強制agent跟足最佳實踐，避免心急跳步驟。
Superpowers倉庫有14個skill，核心係七步強制工作流：brainstorming → writing-plans → using-git-worktrees → subagent-driven-development → test-driven-development → requesting-code-review → finishing-a-development-branch。每個階段由harness hook觸發，agent冇得skip。另外有systematic-debugging、verification-before-completion等輔助skill，仲有meta skill教點用同寫新skill。特別係反模式skill，直接定義「唔應該做嘅嘢」做硬規則，例如「唔準改測試令佢pass」，每次觸發都會強制檢查。
Engr Mejba Ahmed嘅小樣本測試（12個session…
- 核心係七步強制工作流，agent必須按順序行，唔可以跳過任何一步，否則會被hook擋住。
- 反模式skill係亮點，將「唔應該做嘅嘢」（例如改測試令佢pass）寫成硬規則，有效阻止走捷徑。
- 跨平台兼容——skill用平台無關markdown格式，各plugin目錄寫薄adapter，可移植性高，唔綁死單一agent平台。
- 測試數據顯示中等複雜任務效率提升最明顯（token減14%、cost減9%），簡單/複雜任務效益有限，需按場景選用。
- 最大啟發：好嘅harness唔係幫你思考，而係逼你跟已驗證有效嘅工程方法，將團隊紀律物化到系統。
Superpowers：將方法論變成強制器
作者Jesse Vincent（obra）嘅Superpowers，問咗一個唔同嘅問題：當harness核心抽象唔係工具或context，而係軟件開發方法論本身，會發生咩事？呢個視角令Superpowers成為一個「強制器」，逼agent按你想嘅工程紀律做嘢。
呢套流程同一個十年經驗高級工程師跟團隊best practice做嘢幾乎一致。作者用Claude Code最大痛點係agent「心急」——三秒就開始寫code，唔會先確認需求或寫測試。Superpowers強制壓住呢個行為，要佢行完前面流程先可以動手。
反模式skill同跨平台兼容
Superpowers有幾個反模式skill，專門定義「唔應該做嘅嘢」。例如systematic-debugging要求4階段root cause流程（complain→hypothesize→isolate→fix），唔準跳步驟直接改code。verification-before-completion要求真係跑通曬測試先算完成，唔可以靠「我覺得冇問題」。
最特別係TDD裏面嘅testing anti-patterns規則，明確拒絕「為咗令測試通過而改測試」呢種行為。呢條唔係獨立skill，而係寫喺test-driven-development skill嘅硬規則，每次行TDD都會觸發檢查。呢種設計將負面指令變成系統層面嘅強制檢查，比就咁寫prompt有效好多。
跨平台兼容方面，Superpowers支援Claude Code、Cursor、Codex、OpenCode、Copilot CLI、Gemini CLI六個平台。做法係將skill用平台無關格式（markdown + frontmatter）寫好，再喺每個plugin目錄寫薄薄一層adapter，轉做對應平台native格式。呢種思路同ECC嘅DRY adapter pattern一致——核心不變，變嘅係適配層。
效率實證與最大啟發
Engr Mejba Ahmed做咗12個開發session對照實驗，結果顯示平均token減14%、cost減9%。但分析發現節省主要集中在中等複雜度任務：簡單任務因為planning overhead反而用多咗token；複雜任務本來就需要planning，節省有限；中等任務planning成本低過「亂搞之後返工」，整體淨賺。
最大啟發：最好嘅harness唔係幫你思考，而係逼你按已驗證有效嘅工程方法做嘢。LLM其實有開發常識——知道TDD、code review好，但實際做嘢成日走捷徑，因為好方法慢且麻煩。Superpowers解決方法唔係教育agent，而係將「必須寫測試」變成硬約束，似企業團隊管理中用流程、checklist、CI gate建立好文化一樣。
第六個項目，Superpowers。呢個我個人特別推崇，因為佢嘅視角同前面所有項目都唔同。
作者Jesse Vincent，github上面叫obra。Simon Willison評價過佢——「我認識嘅coding agent最有創造力嘅用戶之一」。Superpowers 2025年10月發佈，到2026年4月底啱啱突破121K星，入咗Anthropic官方Claude Plugin Marketplace。
前面幾個項目都係討論harness技術層面嘅事——工具點樣設計、context點樣管、subagent點樣派、skill點樣生成。Superpowers嘅命題唔喺呢度——佢問嘅係，當harness嘅核心抽象唔係工具、唔係上下文、而係「軟件開發方法論」本身，會發生啲乜嘢。
呢個視角令Superpowers唔似一個harness工具，更似一個令agent按你想要嘅工程紀律做嘢嘅強制器。
—— 七步強制工作流程
Superpowers倉庫裏面一共有14個skill，覆蓋功能開發、代碼評審、調試、技能創作幾條主線。其中行功能開發流程嘅核心係七個mandatory skill——注意，係mandatory，唔係suggestion。
按順序排——brainstorming（一開始嘅需求探討）、writing-plans（先將計劃寫清楚）、using-git-worktrees（用worktree隔離改動）、subagent-driven-development（派subagent做主任務）、test-driven-development（必須先寫測試）、requesting-code-review（寫完必須自己審）、finishing-a-development-branch（收尾必須跟流程）。
七個skill串埋就係一個完整嘅「功能開發流程」。重點在於呢套流程係強制執行嘅——agent唔係見到你寫「建議你咁做」就咁做，而係harness裏面嘅鈎子喺每個階段觸發對應嘅skill，agent必須跟skill嘅內容行。
舉個例。你叫Claude俾個項目加個新功能。裝咗Superpowers之後，agent嘅行為變成——
首先調brainstorming skill，同你確認需求邊界、問幾個關鍵問題。
然後調writing-plans skill，先寫一份detailed plan，包括拆解、依賴、風險點。
然後調using-git-worktrees skill，開一個獨立分支隔離改動。
然後調subagent-driven-development skill，將plan裏面嘅子任務派俾subagent去做。
每個subagent跟test-driven-development skill，先寫failing test、再寫implementation、最後綠燈。
全部完成之後調requesting-code-review skill，自己review一次，揾問題。
最後調finishing-a-development-branch skill，跟檢查清單收尾——文檔更新、changelog、PR description。
剩低嘅七個skill係輔助層——systematic-debugging管出bug嗰陣嘅root cause流程、verification-before-completion管「聲稱完成之前必須真係行通測試」、dispatching-parallel-agents管多任務並行、executing-plans/receiving-code-review分別配合主流程嘅對位環節、using-superpowers同writing-skills係meta層（點樣用Superpowers、點樣自己寫新skill）。呢套加埋構成完整體系。
成個流程行完，agent做嘢嘅方式同一個有十年經驗嘅高級工程師嚴格跟團隊best practice行幾乎一樣。
我自己用Claude Code做項目最大嘅痛點之一就係——佢特別容易「心急」。俾一個需求，佢恨唔得三秒鐘就開始寫代碼，根本唔理前面應該先確認需求、應該先寫測試。裝咗Superpowers呢套流程之後，呢個心急行為俾人強制壓住咗——佢必須先將前面流程行完先至可以鬱手寫。
—— 反模式skill：將「唔應該做啲乜」都寫入去
Superpowers裏面有幾個令我拍案嘅skill，專門定義反模式。
systematic-debugging——4階段root cause流程。出bug唔準你跳過中間步驟直接去改code，必須先complain、再hypothesize、再isolate、再fix。每一步都有明確嘅產出物。
verification-before-completion——你唔可以宣稱完成，必須真係將完整測試套件行通。「我覺得應該冇問題啦」呢種話唔算，必須有test runner嘅綠燈輸出。
TDD裏面嵌入嘅testing anti-patterns規則——將「為咗令測試通過而去改測試」呢種事做成顯式拒絕。如果agent發現測試fail，正確嘅做法係去改code令測試pass，唔係去改測試令佢通過。呢條唔係獨立skill，係寫喺test-driven-development skill裏面嘅硬規則，每次行TDD流程都會俾觸發。
呢種「顯式定義反模式」嘅設計思路特別有意思傳統prompt裏面你會寫「please don't change tests just to make them pass」——negative instruction。但negative instruction喺LLM裏面效果一般——模型經常會「理解」但唔「執行」。將佢做成skill，就變成咗一個俾鈎子觸發嘅檢查——每次準備改測試嗰陣呢個skill都會俾激活，問agent「你確定唔係喺度做呢個反模式嗎」。
帶過團隊嘅人都知，最難管嘅就係呢種「為咗KPI走捷徑」嘅事——為咗令測試通過而改測試、為咗令deadline過而跳過review、為咗令bug關掉而繞過root cause。呢啲行為靠人睇住都防唔住，最終都係靠流程同文化嚟兜底。Superpowers做嘅嘢，本質上就係將團隊紀律物化到系統裏面，令agent唔可以唔守。
—— 跨平台兼容性
Superpowers唔只支援Claude Code。佢嘅代碼倉庫裏面有幾個獨立嘅目錄——.claude-plugin、.cursor-plugin、.codex、.opencode對應Claude Code、Cursor、Codex、OpenCode、Copilot CLI、Gemini CLI六個平台都可以行。
呢種跨平台兼容係點樣做到嘅——核心係將skill本身用同平台無關嘅格式（基本上就係markdown加一啲約定嘅frontmatter）寫好，然後每個平台嘅plugin目錄裏面寫一層薄薄嘅adapter，將skill轉成嗰個平台嘅native格式。
呢種思路同下一篇要講嘅ECC嘅DRY adapter pattern一脈相承——核心係不變嘅（skill），變嘅係適配層（plugin format）呢個係harness跨平台嘅最優解。
跨平台支援俾Superpowers帶嚟嘅好處係——用戶唔會被綁死喺某一個agent平台上面你今日用Claude Code，聽日換Cursor，再之後換OpenCode，你嘅Superpowers skill庫一直用得著。呢種可移植性喺快速變動嘅AI生態裏面特別值錢。
—— 真實測試數據
Superpowers呢種「強制流程」聽起嚟都幾重，會唔會反而拖慢效率。Engr Mejba Ahmed做過一個小樣本對照實驗，俾出咗幾有意思嘅趨勢——
12個開發session嘅對照——平均token減14%、cost減9%。
但更加有意思嘅係分析——節省嘅趨勢主要出現喺中等複雜度任務簡單任務裝咗Superpowers反而token更多——因為planning overhead唔值得。複雜任務節省都有限——因為複雜任務本來就需要planning。中等複雜任務啱啱好甜蜜——planning成本低過「亂搞之後返工」嘅成本，整體淨省。
樣本量要先打個底——12個session拆三組每組只有4個樣本，統計上嚴格嚟講講唔上「顯著」，係個早期觀察、值得做更大對照嚟驗證。但呢個趨勢同我自己用落嚟嘅感覺好一致——Superpowers唔係萬能藥，係有明確適用區間嘅工具你做一個「改一行配置」嘅簡單事，Superpowers反而係負擔；你做一個「重構成個模塊」嘅複雜事，Superpowers嘅planning overhead都救唔到你；你做「加一個新feature、涉及3-5個文件、需要測試」嘅中等事，Superpowers最划算。
我自己嘅使用習慣係——平時CLAUDE.md裏面將Superpowers嘅skill調用做成「按需觸發」——簡單事唔強制行完整流程，只係我明確講「跟完整流程開發」嗰陣先啟用。咁樣既享受咗Superpowers嘅紀律性，又唔會被佢嘅overhead拖累。
—— 最好嘅harness唔係替你思考嘅
Superpowers俾我最大嘅啓發係呢句話——最好嘅harness唔係替你思考嘅，而係逼你跟已經俾驗證有效嘅工程方法行。
LLM其實係有「軟件開發常識」嘅——佢知道TDD、知道code review、知道systematic debugging呢啲方法係好嘅。但佢喺實際做嘢嗰陣經常唔跟好方法行——因為好方法慢、好方法繁瑣、好方法喺短期睇起嚟唔necessary。呢個行為模式同人一樣——新手程序員都知道應該寫測試，但deadline壓頭嗰陣總會跳過。
Superpowers解決呢個問題嘅方式唔係「教育agent寫測試有幾重要」——呢種說教喺prompt裏面多少都做過，效果有限。佢係將「必須寫測試」變成harness裏面嘅硬約束——agent你想跳過都跳唔過去，每個工作階段都有skill喺度卡住。
呢個思路對管理過工程團隊嘅人嚟講太熟悉啦——好嘅工程文化唔係靠「大家都自覺」建立嘅，係靠流程、checklist、code review、CI gate呢啲機制建立嘅Superpowers將呢套企業級團隊管理智慧搬咗去AI agent度。
下一篇拆Garry Tan嘅gstack同gbrain——YC CEO自用嘅production系統，主打「組織角色化」——將公司入面嘅唔同角色都做成skill令一個人扮演十個人。呢個係另一種將「團隊智慧」物化到agent度嘅嘗試，同Superpowers形成有意思嘅對比。
第六個項目，Superpowers。這個我個人特別推崇，因為它的視角跟前面所有項目都不一樣。
作者Jesse Vincent，github上叫obra。Simon Willison評價過他——"我認識的coding agent最有創造力的用戶之一"。Superpowers 2025年10月發佈，到2026年4月底剛好突破121K星，進了Anthropic官方Claude Plugin Marketplace。
前面幾個項目都在討論harness技術層面的事——工具怎麼設計、context怎麼管、subagent怎麼派、skill怎麼生成。Superpowers的命題不在這——它問的是，當harness的核心抽象不是工具、不是上下文、而是"軟件開發方法論"本身，會發生什麼。
這個視角讓Superpowers不像一個harness工具，更像一個讓agent按你想要的工程紀律幹活的強制器。
—— 七步強制工作流
Superpowers倉庫裏一共14個skill，覆蓋功能開發、代碼評審、調試、技能創作幾條主線。其中跑功能開發流程的核心是七個mandatory skill——注意，是mandatory，不是suggestion。
按順序排——brainstorming（一開始的需求探討）、writing-plans（先把計劃寫明白）、using-git-worktrees（用worktree隔離改動）、subagent-driven-development（派subagent幹主任務）、test-driven-development（必須先寫測試）、requesting-code-review（寫完必須自審）、finishing-a-development-branch（收尾必須按流程）。
七個skill串起來就是一個完整的"功能開發流程"。重點在於這套流程是強制執行的——agent不是看到你寫"建議你這麼做"就這麼做，而是harness裏的鈎子在每個階段觸發對應的skill，agent必須按skill的內容走。
舉個例子。你讓Claude給項目加個新功能。裝了Superpowers之後，agent的行為變成——
先調brainstorming skill，跟你確認需求邊界、問幾個關鍵問題。
然後調writing-plans skill，先寫一份detailed plan，包括拆解、依賴、風險點。
然後調using-git-worktrees skill，開一個獨立分支隔離改動。
然後調subagent-driven-development skill，把plan裏的子任務派給subagent去做。
每個subagent按test-driven-development skill，先寫failing test、再寫implementation、最後綠燈。
全部完成後調requesting-code-review skill，自己review一遍，找問題。
最後調finishing-a-development-branch skill，按檢查清單收尾——文檔更新、changelog、PR description。
剩下的七個skill是輔助層——systematic-debugging管出bug時的root cause流程、verification-before-completion管"聲稱完成前必須真跑通測試"、dispatching-parallel-agents管多任務並行、executing-plans/receiving-code-review分別配合主流程的對位環節、using-superpowers和writing-skills是meta層（怎麼用 Superpowers、怎麼自己寫新skill）。這套加起來構成完整體系。
整個流程跑下來，agent幹活的方式跟一個有十年經驗的高級工程師嚴格按團隊best practice走幾乎一致。
我自己用Claude Code做項目最大的痛點之一就是——它特別容易"心急"。給一個需求，它恨不得三秒鐘就開始寫代碼，根本不管前面應該先確認需求、應該先寫測試。裝了Superpowers這套流程後，這個心急行為被強制壓住了——它必須先把前面流程走完才能動手寫。
—— 反模式skill：把"不該做什麼"也寫進去
Superpowers裏有幾個讓我拍案的skill，專門定義反模式。
systematic-debugging——4階段root cause流程。出bug不准你跳過中間步驟直接去改code，必須先complain、再hypothesize、再isolate、再fix。每一步都有明確的產出物。
verification-before-completion——你不能宣稱完成，必須真的把完整測試套件跑通。"我覺得應該沒問題了"這種話不算，必須有test runner的綠燈輸出。
TDD裏嵌的testing anti-patterns規則——把"為了讓測試通過去改測試"這種事做成顯式拒絕。如果agent發現測試fail，正確的做法是去改code讓測試pass，不是去改測試讓它通過。這條不是獨立skill，是寫在test-driven-development skill裏的硬規則，每次走TDD流程都會被觸發。
這種"顯式定義反模式"的設計思路特別有意思。傳統prompt裏你會寫"please don't change tests just to make them pass"——negative instruction。但negative instruction在LLM裏效果一般——模型經常會"理解"但不"執行"。把它做成skill，就變成了一個被鈎子觸發的檢查——每次準備改測試時這個skill都會被激活，問agent"你確定不是在做這個反模式嗎"。
帶過團隊的人都知道，最難管的就是這種"為了KPI走捷徑"的事——為了讓測試通過而改測試、為了讓deadline過而跳過review、為了讓bug關掉而繞過root cause。這些行為靠人盯防防不住，最終都是靠流程和文化來兜底。Superpowers做的事情，本質上就是把團隊紀律物化到系統裏，讓agent不能不守。
—— 跨平台兼容性
Superpowers不只支持Claude Code。它的代碼倉庫裏有幾個獨立的目錄——.claude-plugin、.cursor-plugin、.codex、.opencode，對應Claude Code、Cursor、Codex、OpenCode、Copilot CLI、Gemini CLI六個平台都能跑。
這種跨平台兼容是怎麼做到的——核心是把skill本身用與平台無關的格式（基本就是markdown加一些約定的frontmatter）寫好，然後每個平台的plugin目錄裏寫一層薄薄的adapter，把skill轉成那個平台的native格式。
這種思路跟下一篇要講的ECC的DRY adapter pattern一脈相承——核心是不變的（skill），變的是適配層（plugin format）。這是harness跨平台的最優解。
跨平台支持給Superpowers帶來的好處是——用戶不被綁死在某一個agent平台上。你今天用Claude Code，明天換Cursor，再後面換OpenCode，你的Superpowers skill庫一直能用。這種可移植性在快速變動的AI生態裏特別值錢。
—— 真實測試數據
Superpowers這種"強制流程"聽起來挺重，會不會反而拖慢效率。Engr Mejba Ahmed做過一個小樣本對照實驗，給出了挺有意思的趨勢——
12個開發session的對照——平均token減14%、cost減9%。
但更有意思的是分析——節省的趨勢主要出現在中等複雜度任務。簡單任務裝了Superpowers反而token更多——因為planning overhead不值得。複雜任務節省也有限——因為複雜任務本來就需要planning。中等複雜任務恰好甜蜜——planning成本低於"亂搞之後返工"的成本，整體淨省。
樣本量要先打個底——12個session拆三組每組只有4個樣本，統計上嚴格說不上"顯著"，是個早期觀察、值得做更大對照來驗證。但這個趨勢跟我自己用下來的感覺很一致——Superpowers不是萬能藥，是有明確適用區間的工具。你做一個"改一行配置"的簡單事，Superpowers反而是負擔；你做一個"重構整個模塊"的複雜事，Superpowers的planning overhead也救不了你；你做"加一個新feature、涉及3-5個文件、需要測試"的中等事，Superpowers最划算。
我自己的使用習慣是——平時CLAUDE.md裏把Superpowers的skill調用做成"按需觸發"——簡單事不強制走完整流程，只在我明確說"按完整流程開發"的時候才啓用。這樣既享受了Superpowers的紀律性，又不被它的overhead拖累。
—— 最好的harness不是替你思考的
Superpowers給我最大的啓發是這句話——最好的harness不是替你思考的，而是逼你按已經被驗證有效的工程方法走。
LLM其實是有"軟件開發常識"的——它知道TDD、知道code review、知道systematic debugging這些方法是好的。但它在實際幹活時經常不按好方法走——因為好方法慢、好方法繁瑣、好方法在短期看起來不necessary。這個行為模式跟人一樣——新手程序員都知道應該寫測試，但deadline壓頭時總會跳過。
Superpowers解決這個問題的方式不是"教育agent寫測試有多重要"——這種說教在prompt裏多少都做過，效果有限。它是把"必須寫測試"變成harness裏的硬約束——agent你想跳過都跳不過去，每個工作階段都有skill在卡門。
這個思路對管理過工程團隊的人來說太熟悉了——好的工程文化不是靠"大家都自覺"建立的，是靠流程、checklist、code review、CI gate這些機制建立的。Superpowers把這套企業級團隊管理智慧搬到了AI agent裏。
下一篇拆Garry Tan的gstack和gbrain——YC CEO自用的production系統，主打"組織角色化"——把公司裏的不同角色都做成skill讓一個人扮演十個人。這是另一種把"團隊智慧"物化到agent裏的嘗試，跟Superpowers形成有意思的對比。