小編精選 - 技術文章翻譯 · 07月14日

Superpowers：GPT-5.6 時代下的流程毒瘤

> 一個日均消耗約 3 億 token 的重度使用者，為什麼最後選擇把它從工作流裡拆掉

先說結論：我不是被模型拖慢，是被流程拖慢

今天下午，我又被一個任務折磨了一遍。

這不是一個需要數天架構設計的專案，也不是付款、權限、資料遷移這種必須多人審查的高風險改動。按正常的工程節奏，應該是理解需求、定位程式碼、做一個小改動、跑相關測試，然後結束。真正動手的時間可能並不長。

但在 Superpowers 的工作流裡，一個小任務很容易被拉成一條完整的儀式鏈：先判斷有沒有 skill 適用，再進入腦力激盪，再寫設計，再等確認，再寫計畫，再決定要不要建 worktree，再為每個任務派發實作代理，再派規格審查，再派品質審查，最後還要重新驗證、收尾、彙報。

每一步單獨看都能找到一個聽起來合理的理由。問題是，工程效率不是把所有合理步驟都疊在一起。工程效率是用足夠低的成本，獲得足夠高的正確率。

Superpowers 最大的問題，恰恰是把「謹慎」變成了預設，把「流程」變成了目的，把一個本來可以直接完成的任務變成了對流程本身的服從測試。

我不是反對測試，也不是反對審查，更不是反對子代理。我反對的是：在 GPT-5.6 這樣的強模型時代，還把一套為不穩定、低自主性代理設計的長流程，當成所有任務的統一宗教。

我是谁，以及为什么我会对这个问题这么敏感

我不是偶爾打開一次聊天視窗、問一個問題就離開的使用者。按我自己的使用統計口徑，我日均消耗大約 3 億 token。這個數字不是產業基準，也不是給任何產品做宣傳的指標，它只是我的工作現實：大量程式碼閱讀、長上下文分析、跨模組修改、除錯、部署、文件整理和反覆驗證，都在同一個 AI 工作流裡完成。

高頻使用有一個好處：很多流程在第一次體驗時看不出問題，重複幾十次以後，問題會自己浮出來。

你會開始分辨哪些步驟真的降低了錯誤率，哪些步驟只是讓模型顯得很認真；哪些輸出幫助了決策，哪些輸出只是把已經知道的事情再解釋三遍；哪些審查抓住了缺陷，哪些審查只是把「沒有發現問題」包裝成一份新的報告。

當你一天只做一個任務時，多十分鐘的流程可能不明顯。當你一天做幾十個任務，或者讓模型持續工作數小時，所有額外步驟都會變成真實的延遲、真實的 token、真實的上下文污染和真實的注意力損耗。

所以我對 Superpowers 的不滿，不是來自一次偶然的不順手，而是來自高頻使用後越來越清楚的成本帳。

Superpowers 到底把什麼疊在了一起

我盤點了本機快取中的 Superpowers v5.1.3。它一共有 14 個 skill，核心規則文字約 3207 行。它們大致分成幾組：

需求與計畫：brainstorming、writing-plans、executing-plans
子代理與並行：subagent-driven-development、dispatching-parallel-agents
工作區與交付：using-git-worktrees、finishing-a-development-branch
測試與除錯：test-driven-development、systematic-debugging
審查與驗證：requesting-code-review、receiving-code-review、verification-before-completion
全域入口與元流程：using-superpowers、writing-skills

單個 skill 的存在並不等於每次都會載入完整正文。真正讓事情變重的是它們之間的預設連接關係：

rust 代碼解讀複製代碼using-superpowers
    -> brainstorming
    -> writing-plans
    -> using-git-worktrees
    -> subagent-driven-development
    -> implementation
    -> spec review
    -> quality review
    -> verification
    -> finishing-a-development-branch

這是一條適合大型、高風險、多人成員協作專案的保守流水線，不是一條適合所有日常程式任務的預設路徑。

效率：每一步都合理，串起來就不合理

下面是這條鏈中幾類常見步驟的真實成本。

步驟它聲稱解決的問題對小任務的實際代價全域 skill 檢查避免漏掉流程每次對話都增加判斷和解釋，模型先討論「該不該開始」腦力激盪避免需求誤解設定、單函式、文件改動也被迫走設計和審批詳細計畫降低執行偏差計畫本身變成第二份規格，耗時可能超過實作worktree 隔離改動在已有隔離環境裡重複建立隔離，產生無效操作實作代理分離上下文重新傳遞背景、目標、檔案和約束，增加等待和同步規格審查檢查是否符合需求對明確的小改動，常常只是複述需求品質審查檢查程式碼品質需要再次讀取 diff 和上下文，可能提出低價值風格意見收尾流程統一合併和交付對不需要 PR 或分支操作的任務，完全是額外儀式關鍵不是某一步需要多少秒，而是這些步驟有順序依賴。前一步沒有結束，後一步不能開始。使用者需要回答更多確認問題，模型需要發更多狀態訊息，工具需要產生更多中間檔案，整個任務的尾端延遲被不斷拉長。

最荒謬的場景是：程式碼改動本身只有幾行，流程產物卻包括設計說明、計畫、任務清單、實作報告、規格審查報告、品質審查報告和最終驗證報告。最後真正改變系統行為的，可能只有一個條件判斷。

這不是嚴謹。這是流程和任務規模失配。

Token：最貴的不是程式碼，是重複解釋

很多人談 token 成本時，只盯著模型生成的程式碼。實際更昂貴的部分，往往是被流程強迫重複傳遞的上下文。

一個簡化的成本模型可以寫成：

markdown 代碼解讀複製代碼總成本
= 主代理上下文
  + 實作代理次數 × 任務上下文
  + 審查代理次數 × diff 與需求上下文
  + 失敗重試 × 全部上下文
  + 流程狀態訊息與報告

在單代理直接執行時，任務上下文通常只需要被理解一次。進入子代理開發後，同一份需求至少要被主代理整理一次、實作代理讀取一次、規格審查讀取一次、品質審查再讀取一次。任務越多，重複越明顯。

而且這些上下文並不是免費的摘要。為了讓每個代理「獨立」，控制器要把任務背景、檔案範圍、約束、預期輸出和目前狀態重新寫出來。審查代理還要重新建立自己的判斷上下文。你以為你在買更高品質，實際上也在為同一份資訊付多次入場費。

更大的問題是 token 不只影響帳單。上下文越長，模型越容易把注意力放在流程文件、狀態報告和審查意見上，而不是放在真正的程式碼因果關係上。模型開始最佳化「如何證明自己遵守流程」，而不是「如何最快地解決問題」。

對於日均消耗約 3 億 token 的工作流，這種重複不是抽象的效率損失，而是巨大的資源浪費。

審查到底有沒有用？有，但不應該成為宗教

審查當然有用。安全邊界、權限模型、付款邏輯、資料遷移、並行控制、公開 API 和跨服務契約，都值得第二雙眼睛。問題在於，審查的價值高度依賴風險，而 Superpowers 把它做成了預設稅。

可以用一個很簡單的判斷表：

任務類型自動審查的潛在收益是否值得強制多輪審查文件、設定、文案很低不值得單檔局部修復低到中通常不值得已有測試覆蓋的普通業務邏輯中一次針對性檢查即可跨模組重構高可以考慮一次獨立審查權限、付款、安全、資料遷移很高建議人工或獨立審查強制審查的問題有三個。

第一，審查代理不天然比實作代理更懂業務。它可能發現真正的缺陷，也可能把個人風格偏好當成規範問題。最後主代理還要花時間判斷審查意見是否成立。

第二，規格審查和品質審查的邊界並沒有想像中清晰。規格不完整會變成品質問題，品質風險又經常需要回到需求語意。拆成兩個代理，不一定得到兩倍的洞察，通常只得到兩份相互重疊的文字。

第三，審查會製造一種危險的安全感。報告寫得很完整，不等於系統真的正確。真正有價值的驗證仍然是可執行的測試、可重現的行為、清晰的監控和真實的使用者回饋。

審查應該是風險工具，不應該是忠誠度測試。

GPT-5.6 時代，為什麼這套東西更容易顯得逆天

早期代理確實需要更多腳手架。模型可能不理解上下文，容易忘記目標，不能穩定拆任務，也不擅長自我檢查。於是人們把工程經驗寫成一條條硬規則，試圖用流程彌補模型的不可靠。

但模型能力在變化，流程卻很容易固化。

GPT-5.6 這一代強模型已經能夠在同一個上下文裡完成程式碼理解、方案選擇、修改、測試和糾錯。它不意味著模型永遠正確，也不意味著工程紀律可以消失，但它意味著預設工作流應該允許模型根據任務風險調整策略。

如果提示詞寫成「只要有 1% 的可能就必須呼叫 skill」，模型就沒有風險判斷空間。如果寫成「任何專案都必須先設計，即使是一個設定改動」，模型就不能根據任務規模收縮流程。如果寫成「沒有失敗測試就不能寫生產程式碼」，模型就會把測試形式本身當成目標。

這不是在增強模型，而是在壓縮模型的有效自由度。

模型明明可以用十分鐘解決問題，卻被要求用十分鐘解釋為什麼現在還不能解決問題。模型明明可以根據風險選擇一次驗證，卻被要求證明自己完成了完整儀式。最終使用者看到的不是更聰明的工程師，而是一個不停填寫流程表格的工程助理。

最逆天的不是某個步驟，而是那些硬門檻措辭

Superpowers 裡有幾類措辭特別能說明問題。

using-superpowers 的原始規則要求：只要有 1% 的可能適用，就必須呼叫 skill，而且任何回覆或行動之前都要先檢查。

brainstorming 的原始規則要求：任何專案都必須先設計。它甚至把 todo、單函式工具和設定修改列為不能跳過的案例，並要求寫設計文件、提交、等待使用者審閱，再進入計畫。

test-driven-development 的原始鐵律是：沒有先看到失敗測試，就不能寫生產程式碼。

verification-before-completion 的原始規則則把成功表達、提交、建立 PR、移動到下一任務，甚至派發代理，都納入重新驗證的範圍。

這些句子單獨看都像是在保護品質。放在一起，就變成了一個優先保護流程、其次才保護結果的系統。

真正成熟的工程規範應該寫成「在風險足夠高時這樣做」，而不是「永遠這樣做」。把例外全部當成懶惰，把簡化全部當成違規，最終只能讓模型更擅長服從文字，不能讓軟體更可靠。

我最後做了一個本地實驗：14 個變成 6 個

我沒有繼續爭論「這套方法論理論上有沒有價值」，而是直接做了一個本地精簡實驗。

原來的 14 個 skill 中，我移除了：

subagent-driven-development
dispatching-parallel-agents
requesting-code-review
receiving-code-review
executing-plans
using-git-worktrees
finishing-a-development-branch
writing-skills

剩下的 6 個 skill 被改成輕量版本：

需求真的不清楚時，才做簡短 brainstorming。
多檔案、存在順序依賴時，才寫短計畫。
複雜 Bug 才做系統除錯，簡單錯誤直接修。
行為複雜、測試收益明確時才採用測試優先。
非平凡任務結束前跑一次針對性驗證。
使用者明確要求時，才考慮額外流程。

結果是，核心 SKILL.md 從約 3207 行降到 110 行。這個數字不是效能基準，也不能證明所有團隊都應該這麼做，但它證明了一件事：原來的複雜度並不是工程問題本身必然要求的，而是規則疊加出來的。

我還增加了一條更直接的全域偏好：除非使用者明確要求，否則不派子代理，不派自動審查代理，預設由主代理完成實作並做一次針對性驗證。

這才更接近我想要的 AI 工程師，而不是 AI 流程管理員。

我認為 GPT-5.6 時代的工程規範應該是什麼樣

我不主張把所有規範都刪掉。我主張把規範分級。

Lite：預設模式

適用於文件、設定、單檔修改、簡單 Bug 和明確的小功能。

rust 代碼解讀複製代碼理解目標 -> 修改 -> 針對性測試或檢查 -> 說明結果

不寫長設計，不建 worktree，不派代理，不做自動審查。

Standard：普通複雜任務

適用於多檔改動、存在介面影響或需要明顯順序的功能。

rust 代碼解讀複製代碼短計畫 -> 實作 -> 相關測試 -> 一次自我檢查

計畫的目標是減少遺漏，不是製造一份比程式碼更長的文件。

Strict：高風險任務

只在安全、付款、權限、資料遷移、公開 API、跨服務契約和重大重構中啟用。

rust 代碼解讀複製代碼設計討論 -> 計畫 -> 實作 -> 獨立審查或人工審查 -> 整合驗證

即使是 Strict，也應該由使用者或專案負責人明確選擇，而不是由一個「1% 可能性」自動觸發。

這種分級並不降低標準。它把標準用在真正需要的地方，把時間留給真正重要的判斷。

不是反對紀律，是反對把紀律變成目的

今天下午最讓我煩的，不是模型犯了一個錯。模型犯錯是可以接受的，至少錯誤是可見的，可以重現，可以修復。

讓我煩的是，在一個本來可以快速閉環的任務裡，我不斷看到新的流程、確認、報告和審查。每一項都在告訴我系統很謹慎，卻沒有同等力度地告訴我系統離結果更近了。

我寧願讓模型在一個低風險小任務上直接做出一個可以被測試發現的錯誤，也不願它先花大量 token 證明自己知道什麼叫規範。我寧願自己看一眼 diff、跑一次測試，也不願為一份低價值審查報告再啟動一個上下文、再等待一次結果、再判斷一次判斷是否值得相信。

AI 工具的價值，是把人的判斷力放大，把執行成本壓低。一個工作流如果讓人花更多時間等待流程、解釋流程、批准流程，最後才輪到解決問題，那它就已經偏離了工具的目的。

Superpowers 曾經試圖把經驗固化成護欄。問題是，護欄太多、太密、太低，最後就不再是護欄，而是一條把所有車輛都強行降速的窄路。

在 GPT-5.6 時代，我們需要的是有判斷力的工程紀律，不是無差別的流程服從。

我並不想讓模型少思考。我只是希望它把思考用在程式碼、資料和結果上，而不是用在證明自己完成了多少個儀式。

這就是我為什麼說：對高頻 AI 工程工作而言，未經分級、未經風險校準、預設強制審查和子代理的 Superpowers，已經從「能力增強」變成了「效率毒瘤」。

技術附錄：這不是情緒，而是可以定位的機制問題

原始規則裡的幾個硬觸發點

下面這些不是我對 Superpowers 的二次概括，而是它在 skill 檔案中使用的典型硬門檻。檔名就是它們在外掛裡的實際位置。

檔案原始傾向執行時後果skills/using-superpowers/SKILL.md「只要有 1% 的可能適用，就必須呼叫」低置信度判斷也會觸發完整流程skills/brainstorming/SKILL.md「這適用於每一個專案，包括簡單設定修改」小改動不能直接開始skills/writing-plans/SKILL.md要求把工作拆成完整、可執行的計畫任務計畫成本和實作成本倒掛skills/subagent-driven-development/SKILL.md每任務新建實作代理，再做規格和品質審查一次改動變成多次上下文交接skills/requesting-code-review/SKILL.md每個子任務、重大功能、合併前都要求審查審查從風險工具變成固定稅skills/verification-before-completion/SKILL.md任何完成表達、提交、下一任務前都要新鮮驗證狀態溝通也會觸發額外檢查這些規則的共同問題不是「完全錯誤」，而是把「通常有幫助」寫成了「永遠必須」。一旦觸發條件過寬，模型就無法根據任務規模和失敗代價做正常的工程取捨。