Superpowers 神技能還是流程負擔
整理版優先睇
流程重量應與任務風險匹配，關鍵在任務分級而非卸載Superpowers
呢篇文章係作者以AI工作流使用者嘅角度，反思Superpowers呢個廣受爭議嘅Agent Skill。佢先指出兩派觀點：一派話Superpowers令Agent更專業，另一派話令Agent變蠢、多咗好多開會步驟。作者拆解Superpowers嘅運作方式後發現，真正問題唔係裝唔裝，而係流程重量同任務規模唔匹配。
Superpowers本質係一套完整嘅軟件開發方法，要求Agent先理解需求、澄清問題、形成設計，再拆成小任務、測試驅動、審查代碼。呢套流程喺複雜任務好有價值，但喺簡單任務（例如改個按鈕文案）就會變成不必要嘅儀式，令用戶覺得Agent變得好慢。
作者嘅結論係：關鍵唔係卸載Superpowers，而係要識得控制流程重量。佢提出任務分級規則，將任務分為細、中、大三級，各自對應最小必要流程。同時提醒大家喺裝任何Skill之前，要先問四個問題：解決邊種規模、每步防咩錯誤、可否關閉環節、結果點驗證。真正好用嘅Agent，係知道幾時要停低諗，幾時直接做完。
- 結論：Superpowers嘅好壞取決於任務規模，流程重量應與任務風險匹配，唔可以一套流程走天涯。
- 方法：將任務分為低風險小任務、中等任務、大型任務三級，採用最小必要流程，避免過度儀式。
- 差異：原生Agent傾向先判斷任務大小再行動，Superpowers傾向先走流程，小任務下流程反而變阻力。
- 啟發：裝任何Skill前應先問四個問題：解決邊種規模？每步防咩錯誤？可否關閉環節？結果點驗證？
- 可行動點：喺項目規則文件（如CLAUDE.md、AGENTS.md）加入任務分級規則，令Agent開工前先分類並說明原因。
任務分級規則
請根據任務規模選擇流程，不要對所有任務使用同等重量的方法。低風險小任務（修改範圍明確，預計不超過兩個文件，結果容易驗證）：直接定位、修改並運行相關檢查，不寫完整設計和實施計劃。中等任務（原因不明確，可能涉及多個文件，但目標清楚）：先復現問題並列出可驗證假設，找到原因後再決定是否需要實施計劃。大型任務（涉及新功能、數據結構、多個模塊、兼容性或較高回退成本）：先完成需求澄清和設計確認，再編寫實施計劃，使用測試和代碼審查。
Superpowers嘅爭議源頭
上週作者想改一個按鈕文案，Agent竟然輸出咗一份三頁實施計劃。需求澄清、設計方案、子代理分配，樣樣齊全。最後啲字係改啱咗，但作者望住份計劃，忍唔住想卸載Superpowers。
最近爭論好熱鬧。一邊話Superpowers係Agent必裝技能，會先澄清需求、再做設計、寫實施計劃、拆小任務、邊寫邊測、最後代碼審查。另一邊就勸人卸載，理由好直接：裝上以後，Agent好似突然變得特別愛開會。一個話讓Agent更專業，一個話讓Agent更遲鈍。
流程越重，越需要由任務規模、回退成本和驗證難度來證明其必要性
作者拆開Superpowers嘅工作方式睇咗一遍，發現真正嘅分界線係任務大小。唔係裝唔裝，而係要問：呢個任務值唔值得行呢套流程？
Superpowers係一套開發方法
Superpowers唔係一個小插件，而係一套完整嘅軟件開發方法。基本流程大致係：理解需求 → 澄清問題 → 形成設計 → 用戶確認 → 編寫實施計劃 → 拆成小任務 → 測試驅動實現 → 子代理執行 → 規範審查 → 代碼質量審查 → 完成交付。
單睇每一步都好合理。Agent最常見嘅翻車，正正係冇搞清楚需求就開始寫，或者做到一半先發現方向錯咗。Superpowers嘅思路，就係強制補上呢啲容易跳過嘅動作：先想清楚。再動手。做完仲要證明自己冇做錯。
最簡單嘅例子：將設置頁嘅「保存設置」改成「保存」。呢類任務需求明確、修改範圍細、回退成本低。正常流程應該係定位→修改→檢查→完成。但如果仍然做需求澄清、輸出設計方案、編寫實施計劃、分配子代理、多輪審查，流程本身就會比任務更重。用戶嘅感覺只係：「我只是想改四個字，為什麼像要開一次項目啓動會？」
中等任務例如深色模式重啓閃白，原因未知，需要穩定復現、收集證據、列出假設、逐個排除、最小修改、迴歸驗證。呢度需要結構化排查，但唔一定要全套需求討論同多層子代理。最適合「拆着用」，保留調試、測試同驗證，跳過唔必要嘅儀式。
- 穩定復現問題
- 收集相關證據
- 列出所有可能假設
- 逐個排除，直到揾到原因
- 做最小修改
- 迴歸驗證所有功能
大型任務例如新增歸檔功能，牽涉數據結構、兼容性、過濾邏輯等。呢個時候Superpowers嘅完整流程就超有價值：先澄清邊界，再確定數據結構，拆成可單獨驗證嘅小步驟，每一步配測試。多花十幾分鍾做設計，唔係浪費。軟件開發最貴嘅，往往係做到八成先發現方向錯咗。
控制流程重量嘅具體做法
有人建議直接卸載Superpowers，但呢個結論太絕對。真正嘅問題係好多人將同一套流程用喺所有任務上。更實用嘅做法，係畀Agent寫一條任務分級規則，放喺CLAUDE.md或AGENTS.md度。
請根據任務規模選擇流程，不要對所有任務使用同等重量的方法。
- 低風險小任務（修改範圍明確，預計不超過兩個文件，結果容易驗證）：直接定位、修改並運行相關檢查，不寫完整設計和實施計劃。
- 中等任務（原因不明確，可能涉及多個文件，但目標清楚）：先復現問題並列出可驗證假設，找到原因後再決定是否需要實施計劃。
- 大型任務（涉及新功能、數據結構、多個模塊、兼容性或較高回退成本）：先完成需求澄清和設計確認，再編寫實施計劃，使用測試和代碼審查。仲可以叫Agent開工前先回答：請先判斷這是小型、中型還是大型任務，並說明原因，然後選擇最小必要流程。呢個「最小必要流程」好重要：流程唔係越多越專業，足夠降低風險又唔會拖慢任務，先係合適。
作者亦分享咗裝任何Skill前要問嘅四個問題，幫手判斷工具啱唔啱用：
- 1 佢主要解決邊種規模嘅問題？如果係為大型工程設計，就唔好期望佢處理小修改時仍然輕盈。
- 2 佢增加嘅每一步，分別喺防咩錯誤？講唔清每一步嘅價值，流程好易變成儀式。
- 3 我能否關閉唔需要嘅環節？一個冇得根據項目調整嘅通用方法，遲早同真實任務衝突。
- 4 最終結果點驗證？計劃更長、子代理更多、表達更專業，都唔代表結果更好。真正標準係需求有冇滿足、測試有冇通過、有冇破壞舊功能、人工仲要返工幾多。
真正可控嘅Agent工作流
作者用抄書僧做比喻：以前抄寫經典文獻需要工整核校，但如果幫人抄購物清單都用同一套儀式，就唔係嚴謹，而係固執。Superpowers唔係令Agent一鍵升級嘅智力插件，而係一套有明確傾向嘅開發方法。
真正令Agent變好用嘅，唔係永遠多走幾步，係知道幾時要停低諗，幾時直接將件事做完。
總結一句：流程重量應與任務風險匹配。學識分級同控制流程，先係掌握Agent工作流嘅關鍵。
AI WORKFLOW INSIGHT
流程嘅重量應該同任務風險匹配
上週末我讓 Agent 改一個按鈕嘅文案，佢俾我輸出咗一份三頁實施計劃。需求澄清、設計方案、子代理分配，洋洋灑灑。按鈕上嗰四個字，最後改啱咗。但我睇住嗰份計劃睇咗半分鐘，都係想剷咗 Superpowers。
最近呢個爭論吵得好熱鬧。一邊嘅人話佢係 Agent 必裝技能，會先澄清需求，再做設計，跟住寫實施計劃，執行時拆成小任務，邊寫邊測，最後仲要做代碼審查。另一邊嘅人喺度勸大家卸載，理由好直接：裝咗之後， Agent 好似突然變得特別鍾意開會。
一個話佢令 Agent 更專業。一個話佢令 Agent 更遲鈍。
我將 Superpowers 嘅工作方式拆開睇咗一遍，最後發現，呢個問題根本唔係「裝定唔裝」。真正嘅分界線，係任務大小。
核心判斷
流程越重，就越需要由任務規模、回退成本同驗證難度嚟證明佢嘅必要性。
CHAPTER 01
Superpowers 唔係一個小插件，而係一整套開發方法
好多人第一次見到 Superpowers ，會將佢理解成一個可以令 Agent 變聰明嘅 Skill 。其實更準確嘅講法係，佢俾 Agent 套咗一整套軟件開發方法。基本流程大致係咁：
理解需求
→ 澄清問題
→ 形成設計
→ 用戶確認
→ 編寫實施計劃
→ 拆成小任務
→ 測試驅動實現
→ 子代理執行
→ 規範審查
→ 代碼質量審查
→ 完成交付
單睇每一步，都好合理。 Agent 最常見嘅「翻車」（失誤），本身就係未搞清楚需求就開始寫，做到一半先發現方向錯咗；或者只改咗表面，冇驗證其他功能；再或者寫完代碼就宣佈完成，測試根本冇跑過。 Superpowers 嘅思路，就係將呢啲容易俾人跳過嘅動作強制補返。先諗清楚。再動手。做完之後仲要證明自己冇做錯。
從軟件工程角度睇，呢套方法冇問題。問題在於，佢嘅流程重量好大。如果所有任務都用同一套流程， Agent 就好容易由「助手」變成「流程管理員」。
CHAPTER 02
小任務，流程越完整，越容易顯得蠢
先睇一個最簡單嘅任務。
將設定頁入面嘅「保存設置」改成「保存」，按鈕寬度縮短，其他內容唔變。
呢類任務嘅特點係需求非常明確，修改範圍好細，出錯容易發現，回退成本好低。正常情況下， Agent 只需要定位文字同樣式，完成修改，再檢查頁面有冇受影響。流程應該係咁：
定位 → 修改 → 檢查 → 完成
如果呢個時候仍然先做需求澄清、輸出設計方案、編寫實施計劃、分配子代理、做多輪審查，流程本身就會比任務更重。佢當然可以解釋話，呢個係為咗嚴謹。但用戶嘅感受只會係：我只係想改四個字，點解好似要開一次項目啟動會？
呢個就係好多人覺得 Superpowers 「令 Agent 變蠢」嘅來源。唔係模型真係變蠢咗，而係佢將本來可以直接完成嘅小事，套咗入唔必要嘅重流程。對於低風險、結果一眼就驗證到嘅任務，最重要嘅係快速執行同最小檢查，而唔係完整方法論。
CHAPTER 03
中等任務，真正需要嘅係系統排查，唔係全套流程
再睇一個中等難度嘅問題。
應用程式切換到深色模式之後，重啟時會先閃一下白色背景，請定位原因並修復，唔可以影響淺色模式。
呢個任務同改文案完全唔同。現象好清楚，但原因未知。佢可能來自窗口建立時嘅默認背景、頁面樣式加載得太遲、主題配置讀取順序、 WebView 初始化階段，亦可能係某個系統層根本冇辦法俾 CSS 控制。
呢類任務最怕 Agent 見到一個可疑位置就直接修改。改完發現冇用，再換一個地方繼續試。最後文件改咗好幾個，真正原因都未揾到。呢個時候， Superpowers 入面強調嘅系統化除錯（調試）就有價值了。更合理嘅流程係：
穩定復現 → 收集證據 → 列出假設 → 逐個排除 → 最小修改 → 迴歸驗證
呢度需要嘅係結構化排查，但唔一定需要完整嘅需求討論、長篇設計同多層子代理。即係話，中等任務最適合「拆開嚟用」，保留除錯、測試同驗證，跳過唔必要嘅儀式。如果已經揾到明確原因，仲繼續寫一份好長嘅計劃，就又開始變重啦。
中等任務嘅關鍵唔係用唔用 Superpowers ，而係只調用當前真正需要嗰一部分。
CHAPTER 04
大任務，流程越完整，反而越有價值
再睇一個更大嘅任務。
俾任務列表增加歸檔功能。已完成任務可以歸檔，歸檔後默認唔出現喺主列表中，用戶可以進入歸檔頁面查看同恢復，同時要保留舊數據。
呢類任務睇起嚟只增加咗一個功能，實際上牽涉嘅問題遠不止表面呢啲，例如歸檔同刪除有咩分別、舊數據冇歸檔字段時點處理、恢復後任務回到咩狀態、主列表過濾邏輯點寫、邊啲測試可以證明數據冇遺失。
如果 Agent 一嚟就改，好容易做到一半先發現前面嘅設計唔合理。呢個時候， Superpowers 嘅完整流程就開始有價值啦。先澄清邊界，再確定數據結構，跟住寫實施計劃，將任務拆成可以單獨驗證嘅小步驟，每一步都配測試，完成後再做一次需求審查同代碼質量審查。
喺呢種任務裏面，多花十幾分鐘做設計，唔係浪費。
軟件開發裏面最貴嘅，往往唔係前面多想一陣，而係做到八成之後先發現方向錯咗。
CHAPTER 05
佢到底會唔會令 Agent 變蠢？
「 Superpowers 會令 Agent 變蠢」呢句話好有傳播力，但嚴格嚟講唔準確。佢唔會降低模型本身嘅推理能力，佢改變嘅係 Agent 嘅行為優先級。原生 Agent 可能會先判斷任務大小，再決定直接修改，定係先分析。 Superpowers 就更加傾向先走流程，再開始行動。
呢個變化有兩面。
當需求模糊、風險高、涉及文件多時，強制停低好有價值。 Agent 唔會因為「好似知道點做」就即刻動手，而係先將假設、設計同驗證方式寫出嚟。
當任務好細、目標明確、結果容易驗證時，同樣嘅流程就會變成阻力。 Agent 睇起嚟更專業，但唔一定更高效。
所以更準確嘅講法應該係： Superpowers 令 Agent 更守流程，但守流程係咪等於更好，要睇任務係咪值得呢套流程。喺大任務裏面，呢個係紀律。喺小任務裏面，可能就係遲鈍。
判斷標準
模型有冇變聰明並唔重要，關鍵係流程係咪令結果更可靠、更容易驗證。
CHAPTER 06
真正嘅問題唔係卸載，而係唔識控制流程重量
有人建議直接卸載 Superpowers 。呢個結論太絕對啦。佢真正嘅問題，唔係流程本身錯咗，而係好多人將同一套流程用喺曬所有任務度。
更實用嘅做法，係俾 Agent 寫一條任務分級規則。可以放入 CLAUDE.md 、 AGENTS.md 或項目規則文件入面：
請根據任務規模選擇流程，不要對所有任務使用同等重量的方法。
低風險小任務（修改範圍明確，預計不超過兩個文件，結果容易驗證）：
直接定位、修改並運行相關檢查，不寫完整設計和實施計劃。
中等任務（原因不明確，可能涉及多個文件，但目標清楚）：
先復現問題並列出可驗證假設，找到原因後再決定是否需要實施計劃。
大型任務（涉及新功能、數據結構、多個模塊、兼容性或較高回退成本）：
先完成需求澄清和設計確認，再編寫實施計劃，使用測試和代碼審查。
仲可以叫 Agent 喺開始前先回答一句：
請先判斷這是小型、中型還是大型任務，並說明原因，然後選擇最小必要流程。
「最小必要流程」呢幾個字好重要。流程唔係越多越專業。足夠降低風險，又唔會明顯拖慢任務，先至係合適嘅流程。
CHAPTER 07
裝 Skill 之前，我而家會先問四個問題
呢件事亦令我重新思考，點解咁多高星 Skill 裝完之後反而唔好用。問題往往唔喺 Skill 本身，而在於我哋只睇佢做到啲乜，冇睇佢適合啲乜。
以後再遇到類似工具，我會先問四個問題。
佢主要解決邊種規模嘅問題？如果佢係為大型工程設計，就唔好期望佢處理小修改時仍然輕盈。
佢增加嘅每一步，分別喺度防啲咩錯誤？講唔清每一步嘅價值，流程好容易變成儀式。
我可唔可以關閉唔需要嘅環節？一個冇辦法根據項目調整嘅通用方法，遲早會同真實任務衝突。
最終結果點樣驗證？計劃更長、子代理更多、表達更專業，都唔可以證明結果更好。真正嘅標準仍然係需求有冇滿足、測試有冇通過、有冇破壞舊功能、人工仲要返工幾多。
1任務規模係咪匹配呢套方法
2每個流程環節具體喺度防啲咩錯誤
3唔需要嘅環節可否關閉
4最終結果可唔可以直接驗證
CHAPTER 08
最後
歷史上有一種職業叫抄書僧。喺印刷術出現之前，佢哋負責手工複製一切知識。每一個字都要寫得工整，每一份副本都要經過反覆核校。嗰套流程，對於複製一本經典文獻係必要嘅。但如果只係幫人抄一張購物清單，用同一套儀式去做，就唔係嚴謹，而係固執。
Superpowers 唔係令 Agent 一鍵升級嘅智力插件，佢係一套有明確傾向嘅軟件開發方法。佢相信先設計比直接開寫更穩陣，相信任務拆解、測試驅動、獨立執行同雙重審查可以降低錯誤。喺複雜任務裏面，呢啲動作好有價值。喺簡單任務裏面，佢哋亦可能製造過量流程。
我嘅判斷只有一句：任務越複雜、越難回退、越難驗證， Superpowers 越有價值。任務越簡單、越明確、越容易檢查，就越應該只使用最小必要流程。
真正令 Agent 變好用嘅，唔係永遠多走幾步。係知道幾時要停低諗下，幾時要直接將事情做完。
寫喺最後
知道幾時停低諗下，幾時直接完成，先至係真正可控嘅 Agent 工作流。
AI WORKFLOW INSIGHT
流程重量應該與任務風險匹配
上周我讓 Agent 改一個按鈕的文案，它給我輸出了一份三頁實施計劃。需求澄清、設計方案、子代理分配，洋洋灑灑。按鈕上那四個字，最後改對了。但我盯着那份計劃看了半分鐘，還是想把 Superpowers 卸掉。
最近這個爭論吵得很熱鬧。一邊的人說它是 Agent 必裝技能，會先澄清需求，再做設計，接着寫實施計劃，執行時拆成小任務，邊寫邊測，最後還要做代碼審查。另一邊的人在勸大家卸載，理由很直接：裝上以後， Agent 好像突然變得特別愛開會。
一個說它讓 Agent 更專業。一個說它讓 Agent 更遲鈍。
我把 Superpowers 的工作方式拆開看了一遍，最後發現，這個問題根本不是「裝還是不裝」。真正的分界線，是任務大小。
核心判斷
流程越重，越需要由任務規模、回退成本和驗證難度來證明其必要性。
CHAPTER 01
Superpowers 不是一個小插件，而是一整套開發方法
很多人第一次看到 Superpowers ，會把它理解成一個能讓 Agent 變聰明的 Skill 。其實更準確的說法是，它給 Agent 套上了一整套軟件開發方法。基本流程大致是這樣：
理解需求
→ 澄清問題
→ 形成設計
→ 用戶確認
→ 編寫實施計劃
→ 拆成小任務
→ 測試驅動實現
→ 子代理執行
→ 規範審查
→ 代碼質量審查
→ 完成交付
單看每一步，都很合理。 Agent 最常見的翻車，本來就是沒搞清楚需求就開始寫，做到一半才發現方向錯了；或者只改了表面，沒有驗證其他功能；再或者寫完代碼就宣佈完成，測試根本沒跑。 Superpowers 的思路，就是把這些容易被跳過的動作強制補上。先想清楚。再動手。做完以後還要證明自己沒有做錯。
從軟件工程角度看，這套方法沒有問題。問題在於，它的流程重量很大。如果所有任務都套同一套流程， Agent 就很容易從「助手」變成「流程管理員」。
CHAPTER 02
小任務，流程越完整，越容易顯得笨
先看一個最簡單的任務。
把設置頁中的「保存設置」改成「保存」，按鈕寬度縮短，其他內容不變。
這類任務的特點是需求非常明確，修改範圍很小，出錯容易發現，回退成本很低。正常情況下， Agent 只需要定位文字和樣式，完成修改，再檢查頁面有沒有受影響。流程應該是這樣：
定位 → 修改 → 檢查 → 完成
如果這時候仍然先做需求澄清、輸出設計方案、編寫實施計劃、分配子代理、做多輪審查，流程本身就會比任務更重。它當然可以解釋說，這是為了嚴謹。但用戶的感受只會是：我只是想改四個字，為什麼像要開一次項目啓動會？
這就是很多人覺得 Superpowers 「讓 Agent 變蠢」的來源。不是模型真的變笨了，而是它把本來可以直接完成的小事，套進了不必要的重流程。對於低風險、結果一眼就能驗證的任務，最重要的是快速執行和最小檢查，而不是完整方法論。
CHAPTER 03
中等任務，真正需要的是系統排查，不是全套流程
再看一箇中等難度的問題。
應用切換到深色模式後，重啓時會先閃一下白色背景，請定位原因並修復，不能影響淺色模式。
這個任務和改文案完全不同。現象很清楚，但原因未知。它可能來自窗口創建時的默認背景、頁面樣式加載過晚、主題配置讀取順序、 WebView 初始化階段，也可能是某個系統層根本無法被 CSS 控制。
這類任務最怕 Agent 看到一個可疑位置就直接修改。改完發現沒用，再換一個地方繼續試。最後文件改了好幾個，真正原因還沒找到。這時候， Superpowers 裏強調的系統化調試就有價值了。更合理的流程是：
穩定復現 → 收集證據 → 列出假設 → 逐個排除 → 最小修改 → 迴歸驗證
這裏需要的是結構化排查，但不一定需要完整的需求討論、長篇設計和多層子代理。也就是說，中等任務最適合「拆着用」，保留調試、測試和驗證，跳過不必要的儀式。如果已經找到明確原因，還繼續寫一份很長的計劃，就又開始變重了。
中等任務的關鍵不是要不要用 Superpowers ，而是隻調用當前真正需要的那一部分。
CHAPTER 04
大任務，流程越完整，反而越值錢
再看一個更大的任務。
給任務列表增加歸檔功能。已完成任務可以歸檔，歸檔後默認不出現在主列表中，用戶可以進入歸檔頁面查看並恢復，同時要保留舊數據。
這類任務看起來只增加了一個功能，實際上牽涉的問題遠不止表面這些，比如歸檔和刪除有什麼區別、老數據沒有歸檔字段時怎麼處理、恢復後任務回到什麼狀態、主列表過濾邏輯怎麼寫、哪些測試能證明數據沒有丟失。
如果 Agent 一上來就改，很容易做到一半才發現前面的設計不合理。這時候， Superpowers 的完整流程就開始有價值了。先澄清邊界，再確定數據結構，接着寫實施計劃，把任務拆成可以單獨驗證的小步驟，每一步都配測試，完成後再做一次需求審查和代碼質量審查。
在這種任務裏，多花十幾分鍾做設計，不是浪費。
軟件開發裏最貴的，往往不是前面多想一會兒，而是做到八成以後才發現方向錯了。
CHAPTER 05
它到底會不會讓 Agent 變蠢？
「 Superpowers 會讓 Agent 變蠢」這句話很有傳播力，但嚴格來說不準確。它不會降低模型本身的推理能力，它改變的是 Agent 的行為優先級。原生 Agent 可能會先判斷任務大小，再決定直接修改，還是先分析。 Superpowers 則更傾向於先走流程，再開始行動。
這個變化有兩面。
當需求模糊、風險高、涉及文件多時，強制停下來非常有價值。 Agent 不會因為「好像知道怎麼做」就馬上動手，而是先把假設、設計和驗證方式寫出來。
當任務很小、目標明確、結果容易驗證時，同樣的流程就會變成阻力。 Agent 看起來更專業，但不一定更高效。
所以更準確的說法應該是： Superpowers 讓 Agent 更守流程，但守流程是否等於更好，要看任務是否值得這套流程。在大任務裏，這是紀律。在小任務裏，可能就是遲鈍。
判斷標準
模型有沒有變聰明並不重要，關鍵是流程是否讓結果更可靠、更容易驗證。
CHAPTER 06
真正的問題不是卸載，而是不會控制流程重量
有人建議直接卸載 Superpowers 。這個結論太絕對了。它真正的問題，不是流程本身錯了，而是很多人把同一套流程用在了所有任務上。
更實用的做法，是給 Agent 寫一條任務分級規則。可以放進 CLAUDE.md 、 AGENTS.md 或項目規則文件裏：
請根據任務規模選擇流程，不要對所有任務使用同等重量的方法。
低風險小任務（修改範圍明確，預計不超過兩個文件，結果容易驗證）：
直接定位、修改並運行相關檢查，不寫完整設計和實施計劃。
中等任務（原因不明確，可能涉及多個文件，但目標清楚）：
先復現問題並列出可驗證假設，找到原因後再決定是否需要實施計劃。
大型任務（涉及新功能、數據結構、多個模塊、兼容性或較高回退成本）：
先完成需求澄清和設計確認，再編寫實施計劃，使用測試和代碼審查。
還可以讓 Agent 在開始前先回答一句：
請先判斷這是小型、中型還是大型任務，並說明原因，然後選擇最小必要流程。
「最小必要流程」這幾個字很重要。流程不是越多越專業。足夠降低風險，又不會明顯拖慢任務，才是合適的流程。
CHAPTER 07
裝 Skill 前，我現在會先問四個問題
這件事也讓我重新思考，為什麼很多高星 Skill 裝完以後反而不好用。問題往往不在 Skill 本身，而在於我們只看它能做什麼，沒有看它適合什麼。
以後再遇到類似工具，我會先問四個問題。
它主要解決哪種規模的問題？如果它是為大型工程設計，就不要期待它處理小修改時仍然輕盈。
它增加的每一步，分別在防什麼錯誤？說不清每一步的價值，流程很容易變成儀式。
我能不能關閉不需要的環節？一個無法根據項目調整的通用方法，遲早會和真實任務衝突。
最終結果怎麼驗證？計劃更長、子代理更多、表達更專業，都不能證明結果更好。真正的標準仍然是需求有沒有滿足、測試有沒有通過、有沒有破壞舊功能、人工還要返工多少。
1任務規模是否匹配這套方法
2每個流程環節具體在防什麼錯誤
3不需要的環節能否關閉
4最終結果能否被直接驗證
CHAPTER 08
最後
歷史上有一種職業叫抄書僧。在印刷術出現之前，他們負責手工複製一切知識。每一個字都要寫得工整，每一份副本都要經過反覆核校。那套流程，對於複製一本經典文獻是必要的。但如果只是幫人抄一張購物清單，用同一套儀式去做，就不是嚴謹，而是固執。
Superpowers 不是讓 Agent 一鍵升級的智力插件，它是一套有明確傾向的軟件開發方法。它相信先設計比直接開寫更穩，相信任務拆解、測試驅動、獨立執行和雙重審查能夠降低錯誤。在複雜任務裏，這些動作很有價值。在簡單任務裏，它們也可能製造過量流程。
我的判斷只有一句：任務越複雜、越難回退、越難驗證， Superpowers 越有價值。任務越簡單、越明確、越容易檢查，越應該只使用最小必要流程。
真正讓 Agent 變好用的，不是永遠多走幾步。是知道什麼時候該停下來想，什麼時候該直接把事情做完。
寫在最後
知道什麼時候停下來想，什麼時候直接完成，才是真正可控的 Agent 工作流。