我們最新 Claude 模型最棒的一點，就是它們能在不破壞 Claude Code 中 prompt cache 的前提下，根據 effort（投入程度）來調整回應方式。不過，我也收到很多使用者關於這方面的提問：effort 到底是什麼？什麼時候該用哪一種 effort 等級？我們為什麼需要 effort？
為了回答這些問題，我決定深入研究 evals（評估測試），並針對日常工作親自測試不同 effort 的表現。
註：你可以在 https://claude.dev/blog/spending-your-effort/ 看到這篇文章的更多互動式圖表與說明。
整體來說，我發現 effort 是一個很好的機制，可以用來調整 Claude 進行驗證與邊界情況測試的程度，以及它運用自身判斷力的比例。
在硬體、程式碼審查和安全性等「驗證與邊界情況測試」特別有用的領域，較高的 effort 能帶來更好的結果。
但低與中等 effort 則非常適合快速完成工作，並讓你持續參與在與 Claude 的協作流程中。
在一般的軟體工程工作中，我現在會跑這樣一個循環：先讓模型訪談我，接著用低／中等 effort 實作，檢視它完成的內容，最後再用高 effort 進行驗證。
什麼是 effort？
概括來說，effort 能讓模型大致了解你希望它在這個任務上投入多少運算資源。這在某種程度上也反映了你對任務難度的預期。
你可以這樣想：如果有人要求你連續工作 12 小時來完成一件事，你可能會認為對方只想要你拚命把東西做出來。但如果有人要你在一小時內完成同樣的任務，你會試著先交出最符合需求、品質最好的版本，然後再從那裡開始迭代。
或者，你也可能會反駁說這個任務「至少」需要 3 小時，然後花 3 小時把它完成。
你應該用同樣的方式來理解 effort。Claude 永遠都會合理地嘗試完成你的任務，但較高的 effort 會讓 Claude 採取更多自主行動來進行判斷與驗證。
Effort 曲線
Fable 5.1 和 Opus 5.5 的 effort 曲線是我們目前表現最好的——在每個等級上，基準測試分數與 token 消耗量都會隨之提升。下圖是我為這篇文章執行 eval 時所測得、依 effort 區分的 Terminal Bench 3.0 分數圖表。
但這在實際應用中代表什麼意思？為了評估這一點，我用不同的 effort 等級嘗試了多項任務，並仔細研究了各項基準測試數據。
使用 effort 進行開發
要理解模型的運作方式，最好的方法就是動手實驗。我在 Opus 5.5 上用幾種不同的 effort 等級執行相同的任務，藉此觀察它會怎麼處理工作。我測試了各種類型的工作，這裡先用幾個簡單的範例來說明。
規格不明確的開發任務
如果我請 Claude「做一個個人健身與訓練紀錄 App」，effort 會大幅影響這個 App 的完整度，同時也會讓 Claude 在過程中做出更多決策。在低 effort 下，健身 App 只是一個紀錄表和一張簡單的圖表；在較高的 effort 等級下，App 會變得更複雜、細節更豐富；而在最高 effort 下，甚至會出現熱力圖。
如果我想要的是一個可以繼續迭代的簡單基礎，低 effort 就能搞定。而最高 effort 則適合我想讓 Claude 一次就拿出最佳成果的時候。
規格略為明確的設計任務
如果任務本身已經有相當明確的規格，但我還是想跟 Claude 一起探索看看呢？舉例來說，我請它重新設計 Claude Code 中的 /config 選單。每一次執行的核心想法都差不多：使用子選單和更好的搜尋功能。
在低 effort 下（花了 1 分鐘），我得到了一個能傳達概念的互動式草圖，但看起來不太像 Claude Code。
在最高 effort 下（花了 28 分鐘），我拿到了一份非常接近 Claude Code 風格的 mockup，還附上好幾種操作流程的導覽說明。
如果我的目標是迭代並提供回饋，低 effort 能讓我更快達到目的。但最高 effort 一開始就能給我精緻得多的成果。就這個特定任務而言，我認為自己比較偏好使用低 effort 來理解 Claude 的設計構想。
規格高度明確的開發任務
如果我給 Claude 非常多細節呢？我試著請 Claude 針對健身 App 對我進行深度訪談，然後把這份規格交給不同的模型、用不同的 effort 等級去實作。
我發現有了這份規格後，各模型的行為變得相似許多。我拿到的設計看起來相當接近，實作方式也類似，只是細節有所不同；而在最高 effort 下，Claude 會多花一些時間來簡化部分細節。
重點整理
對於一般的軟體工程工作，尤其是新功能開發，該用哪個 effort 等級很大程度上取決於我希望自己參與到什麼程度。低 effort 讓 Claude 能快速回應並提供起點；較高的 effort 等級能完成更多工作，但 Claude 也會替我做出更多假設。
在功能開發上，我一直在用的一個特別有效的循環是：
- 給 Claude 一份規格，並請它針對我遺漏的任何細節訪談我
- 用低 effort 實作
- 檢視成果，確認它是否掌握了正確方向，必要時用低 effort 迭代
- 用高 effort 進行驗證與測試
Effort 等級如何影響困難任務的輸出
當然，以上都是些簡單的範例，Claude 本來就能輕鬆完成。那麼，當差異在於「Claude 能不能完成任務」時，又會是什麼情況？
要找出這類難題，就得去看基準測試，所以我深入研究了一個我很喜歡的測試：Terminal Bench 3，這是一個由社群貢獻的基準測試。
Terminal-Bench 3.0 的問題大致可分為安全性、硬體、ML、科學、軟體、維運和媒體等類別。你可以在這裡看到所有問題：https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0，這些題目都來自社群，任何人都可以貢獻。
這些題目很值得一讀，能讓你了解這類模型面對的是什麼樣的問題。我發現自己對其中許多任務的規模與企圖心感到驚訝，它們比我平常遇到的任務複雜得多。
舉例來說，部分任務包括：
- 硬體 (retro-console-soc)：用 Verilog 打造一台能放進小型 FPGA 且可渲染測試 ROM 的 8 位元遊戲機。
- 科學 (takens-embedding-lean)：在 Lean 4 中形式化證明 Takens 嵌入定理。
- ML (mp-checkpoint-consolidation)：將 mixture-of-experts checkpoint 的 16 個分片合併成單一檔案，並重現參考 logits。
- 維運 (intrastat-meldung)：端到端完成一家公司的歐盟月底貿易統計申報。
- 媒體 (layout-config-recreation)：將海報圖片重建為可編輯的版面檔案。
邊界情況多時，較高的 effort 更有幫助
閱讀 Terminal Bench 3 的結果後，我最大的心得是：對於隱藏大量邊界情況的任務，較高的 effort 效果最好。
一個很清楚的例子是 html-js-filter，這是 Terminal-Bench 3.0 中的一個任務，要求寫出一個 HTML 過濾器，攔截所有將 JavaScript 偷偷注入頁面的手法。Fable 5.1 在低 effort 下的成績是 1/5，到了 xhigh 則提升到 5/5。
低 effort 的典型嘗試大約耗時 2 分鐘。每次嘗試幾乎都是一次就把過濾器寫完，然後只用一個手寫的頁面進行測試。
高 effort 的執行則大約需要 33 分鐘。在我追蹤的那次執行中，它以對抗性的角度審視了自己的初稿，接著閱讀已安裝解析器的原始碼來檢查 bug，跑了許多乾淨的測試案例直到輸出與輸入一致，執行標準的 XSS 測試套件，最後還寫了一個隨機文件模糊測試工具。
對於像 HTML 過濾器這種充滿邊界情況的東西，多花這些 effort 絕對值得。對於效能優化或安全性審查這類生產環境要求高、又十分複雜的任務，多消耗一些 token 來換取嚴謹度也很合理。
但你不需要對每個任務都投入這麼高的 effort。
下圖展示了所有 Terminal-Bench 3.0 的結果，以及在不同模型與 effort 等級下的失敗原因。整體而言，提高 effort 往往能減少因漏掉邊界情況而導致的失敗（紫色區塊），但無法修正模型採用錯誤解法的情況（藍色區塊）。
Effort 真正派得上用場的問題領域
在 TerminalBench 上評估這些模型時，我最感興趣的發現之一是：某些問題領域比其他領域更能從 effort 中獲益。你可以從下圖看到詳細分類：
為了說明這一點，我從 Terminal Bench 3.0 的不同領域中挑了幾個問題——Opus 5.5 在低 effort 下失敗，但在高 effort 下成功，主要原因就是它進行了測試並考量了邊界情況：
mvcc-lsm-compaction： Terminal-Bench 3.0 的一個任務，要求根據崩潰報告修復儲存引擎的 bug，且不能破壞 compaction。Opus 5.5 在低 effort 下是 0/5，在 xhigh 下則是 4/5。
在低 effort 下（每次嘗試約 1 分鐘），Claude 會在編譯或執行重現腳本之前就修改程式碼，而且沒有檢查新寫的測試是否真能抓到原本的 bug。
在 xhigh 下（約 11 分鐘），Claude 會先重現崩潰，接著針對一個永不 compaction 的參考實作撰寫隨機測試，並確認自己的測試在半成品修復上會失敗。
cli-2ph-simple： Terminal-Bench 3.0 的一個任務，要求用 Python 寫一個 CLI 線性規劃求解器。Opus 5.5 在低 effort 下是 0/5，在高 effort 下則是 5/5。
低 effort 的嘗試會一次寫完求解器，用幾個小問題檢查後，在大約 10k token 時就停下來。在最後一則訊息中，Claude 警告說遇到大問題時可能會很慢，但並沒有實際驗證。
在高 effort 的嘗試中，Claude 會用隨機問題測試它的求解器，並與另一個暴力求解器比對，接著計時較大的問題，遇到執行過久或崩潰的情況，然後重新調整搜尋策略。
gsea-proteomics：Terminal-Bench 3.0 的一個任務，要求對蛋白質體學資料執行基因集富集分析（GSEA），找出八種療法中哪些與目標組織相似。Opus 5.5 在低 effort 下是 0/5，在高 effort 下則是 4/5。
在低 effort 下，Claude 挑了一種聽起來合理的方式來準備資料，用那一種方式跑完分析，然後回報結果。
在高 effort 下，Claude 嘗試了兩種資料準備方式，發現顯著療法的清單因此改變，於是深入探究原因，最後才選擇正確的做法。
如果有使用者參與在流程中，Claude 可能會詢問使用者該如何設定這個問題；但在沒有使用者參與的情況下，高 effort 的表現更好。
在 Claude Code 中何時該使用不同的 effort 等級
以下是我決定何時使用哪種 effort 等級的經驗法則：
- Low：當我想要快速回應並保持參與感時，例如腦力激盪、畫草圖、簡單的修改。
- Medium：用於我大部分的日常軟體工程工作，例如新功能實作。
- High：用於驗證很重要或存在邊界情況的工作，例如修復 brownfield 程式碼庫中的 bug。
- Max：當我希望 Claude 完全自主地解決困難問題時，例如端到端建構並驗證一個 App，或在關鍵軟體中找出安全漏洞。
你可以根據任務需求，甚至在對話中途，透過在 Claude Code 中使用 /effort 來切換 Opus 5.5 和 Fable 5.1 的 effort 等級。試玩之後，歡迎跟我分享這是否符合你的直覺。
