Token 最高省 60% ：Superpowers v6 真正优化了什么？
三句話摘要
Superpowers-6 如何通過優化工作流程而非降級模型，將 AI 編程成本降低 50%。 AI 編程的成本優化關鍵不在模型選擇，而在設計工作流讓 agent 讀正確的訊息、讀一次而不是反覆讀，以及為不同任務複雜度路由合適的模型層級。 確定性資訊交給腳本而非 LLM 現查 — Coordinator 看過上下文、Implementer 改過代碼、Reviewer 審查時又跑一遍 git diff，每次重複搬運都會消耗新的 token。v6 改為由腳本預生成 review package（含 commit list、diff 統計、完整 diff），reviewer 只讀檔案，單次改造就省了 10% 的 token 和執行時間。
重點整理
重點- 1
確定性資訊交給腳本而非 LLM 現查 — Coordinator 看過上下文、Implementer 改過代碼、Reviewer 審查時又跑一遍 git diff，每次重複搬運都會消耗新的 token。v6 改為由腳本預生成 review package（含 commit list、diff 統計、完整 diff），reviewer 只讀檔案，單次改造就省了 10% 的 token 和執行時間。
- 2
Plan 不能只追求短，要保留關鍵錨點 — 實驗嘗試壓縮 plan 字數後，測試訊號下降 62%，因為被砍掉的是測試、介面、任務結構這類後續執行和審查的決定點。沒了這些錨點，每個 agent 都要自己猜，後面繞路會更多。
- 3
模型路由要看任務形態，不只看 token 價格 — 機械任務（按 plan 轉寫、跑測試）用便宜模型即可；需要多步推理、架構判斷、並發共享狀態的任務就要上等級。如果 controller 沒明確指定，harness 容易預設繼承 session 最貴模型，無聲地燒錢。
- 4
Reviewer 合併並保留「無法從 diff 驗證」狀態 — v5 把 spec compliance 和 code quality 分開成兩個 reviewer，v6 合成一個 task-reviewer 同時回傳兩個 verdict。新增「Cannot verify from diff」狀態讓 reviewer 承認邊界，交給有全局視角的 controller 判斷，避免 reviewer 為了補全視角到處 grep cat。
實用技巧與重點
乾貨- 時間與成本
- 25 個實驗、36 小時、帳面花費 165 美元（未補貼約 650 美元）
- Anthropic eval：wall-clock runtime 下降 50%、token spend 下降 60%（最高口徑）
- Release notes 更保守說法：速度快一倍、token 少近 50%、質量接近
- 優化措施與效果
- Review package 預生成：-10% token 和 wall-clock
- Task brief 獨立提取：避免重複在長 plan 裡翻找
- Reviewer 合併（2 個 → 1 個）：同步回傳 spec compliance 和 code quality
- Cannot verify from diff 狀態：新增警告標記，交由 controller 決策
- Narration Recipe：controller 敘述字元數 -54%，估算每次節省 0.1~0.3 美元
- 失敗案例
- 限制 controller thinking：turn 數從 92 → 138、輸出翻倍
- 壓縮 plan 字數（含豁免代碼部分）：測試訊號下降 62%
- 用 Sonnet 生成 plan：任務結構坍縮（平均任務數從 5.8 → 3.6）
- 核心理念
- 砍重複資訊，保留測試、介面、任務邊界、全域約束
- 確定性資料交給腳本（commit list、diff stat、單一 task brief）
- 模型分層：機械任務用便宜模型、判斷密集用高階模型
- Fable 5 在 6 月 9 日發表，6 月 12 日因美國出口管制暫停訪問，6 月 30 日管制解除，7 月 1 日恢復
結論
結論“AI 編程的成本優化關鍵不在模型選擇，而在設計工作流讓 agent 讀正確的訊息、讀一次而不是反覆讀，以及為不同任務複雜度路由合適的模型層級。”
完整解析
詳細AI 編程的高成本長期被歸咎於「模型貴」，但 Superpowers-6 的優化實驗揭露了真正的元兇：LLM 會反覆讀取同一批上下文。Coordinator 拆任務時讀了一遍 diff，Implementer 寫程式碼時處理了相關文件，Reviewer 審查時又用 git 命令重新提一遍——每一次輸出都進入 token 計數，後續對話反覆攜帶。一個中等規模重構的 diff 文字輕鬆吃掉幾萬 token，成本就是這樣一點點堆起來的。
Jesse Vincent 的優化方向不是把所有環節都降級到便宜模型，而是三個層面的調整。第一層是確定性資訊的流動。v6 在 reviewer 啟動前，由腳本預生成一份 review package，內含 commit list、文件變更統計、帶上下文的完整 diff。Reviewer 不再自己跑 git 指令探索，只讀檔案即可——單次改造就帶來了 10% 的 token 和執行時間改善。同樣的思路還延伸到 task brief，Controller 不再把整份 plan 重複塞給 subagent，而是把當前任務抽成獨立文檔，subagent 讀自己的 brief 不用在長 plan 裡翻找。
第二層是 reviewer 的合併和邊界重新定義。v5 設計中，每個任務有兩個 reviewer 分別檢查 spec compliance 和 code quality，職責拆得很細，卻更昂貴且易被 controller 提示方式影響。v6 把兩個 reviewer 合成一個 task-reviewer，讀一次 diff 同時回傳兩個 verdict。但更有趣的改動是新增「Cannot verify from diff」狀態——承認看不到全局，把無法驗證的需求標成警告交給 controller。過去 reviewer 為了補全視角會到處 grep cat，既費 token 又破壞任務邊界；現在讓 reviewer 在邊界內明確作答，更複雜的跨任務判斷交給有完整上下文的 controller。
第三層是模型分層。實驗發現，並非所有環節都需要最強模型。Implementer 如果 plan 已給完整程式碼，主要工作只是轉寫和跑測試，便宜模型就能勝任；但需要多步推理、架構邊界判斷的任務不能亂降級。Reviewer 也是如此，小 diff 的機械改動可用便宜模型，涉及並發、共享狀態、跨文件契約則要上等級。v6 強制每次 dispatch 寫明 model，因為不寫的話 harness 容易預設繼承 session 最貴模型，無聲地燒錢。
實驗過程中也踩到了幾個看似合理卻反向爆炸的想法。限制 controller thinking——想省思考 token 就給 budget——結果 turn 數從 92 飆到 138，輸出翻倍。壓縮 plan 字數，測試訊號掉了 62%，因為被砍的不是廢話而是測試、介面、任務結構這類執行的決定點。用便宜的 Sonnet 生成 plan，全局約束沒丟但任務結構坍縮成太粗的顆粒度，reviewer 無法攔住局部缺陷。這些失敗案例很有參考價值——省 token 不是粗暴刪上下文，要刪重複資訊卻保留關鍵錨點。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
