Claude Code 提供兩種設定，似乎都能「讓答案變更好」：模型和努力程度。但這些設定實際上對輸出產生了什麼影響？你又該如何判斷，何時該換用不同的模型，何時只需調整努力程度？
我們很容易認為，選擇像 Fable 這樣的大型模型，會比 Sonnet 產生更聰明的輸出，而更高的努力程度，只是代表 Claude 在回答前會思考更久。
第一個假設是對的。根據業界標準基準測試，我們最大的模型確實能力更強。
但努力程度代表的意義遠不止「思考時間」。努力程度控制的是 Claude 對你的請求投入的總工作量。這包括它思考的時間，但也包含：
- 讀取多少檔案；
- 驗證多少內容；
- 以及在與你確認之前，它能將多步驟任務推進到多遠。
在較高的努力程度下，Claude 在回覆你之前，會採取更多這類行動（讀取檔案、執行測試、再次檢查）。在較低的努力程度下，它寧可向你詢問更多背景資訊，也不願花費 token 自行釐清問題。
模型選擇的運作方式
要理解模型設定實際控制什麼，最好從最開始，也就是你按下 Enter 鍵的那一刻說起。
Claude Code 會將你的訊息，與系統提示、工具定義、你的 CLAUDE.md、對話歷史記錄，以及任何在上下文中的檔案組合在一起。所有這些內容會作為一個請求發送到 API。
Claude Code 的所有內容都被打包成一個 API 請求。在伺服器端，文字在到達模型之前會先被 token 化。
不過，模型從未將這些視為純文字。伺服器上發生的第一件事是 token 化：文字被分割成片段，每個片段會對應到模型訓練時所用固定詞彙表中的一個整數。const 可能對應到 1978，await 可能對應到 4293。從這裡開始，你的提示詞就是一個整數陣列。
Token 化器將你的文字分割成片段，並將每個片段對應到固定詞彙表中的一個整數。頂行中的每個區塊都會變成它的 token ID（底行所示）；顯示的 ID 僅供說明。
模型的工作是接收該陣列，並預測下一個 token 是什麼。它透過計算詞彙表中每個 token 的機率，並從機率最高的 token 中進行選擇來做到這一點。在 "const x = await" 之後，一個訓練有素的模型會對 "fetch" 賦予很高的機率（非常可能），而對 "banana" 賦予接近零的機率（非常不可能）。
模型的預測是針對其詞彙表中每個 token 的機率。最佳猜測與不相關猜測之間的差距是巨大的。
將你的輸入 token 轉換成這些機率的是權重（也稱為參數）：數十億個數字，組織成大型矩陣。為了預測一個 token，模型會將你的輸入通過這些矩陣（一長串的矩陣乘法），並在最後讀取機率。權重就是模型「知道」的一切所在。
每個模型的權重都是在訓練期間設定的，當你發送請求時，它們是唯讀的。你的提示詞、你的 CLAUDE.md 或你的上下文中的任何內容都不會改變它們。如果你遇到 推理 這個詞，它指的就是：在訓練完成後使用模型，權重是固定的。
你的提示詞輸入，機率輸出。中間的權重不會改變。
Claude 所知道的關於 TypeScript、熱門框架或任何其他一般程式設計知識的一切，都在訓練時被編碼到了這些權重中。
你的提示詞和上下文仍然可以引導預測結果。將你的實際程式碼放在 Claude 面前就是一種引導，而且效果非常好。然而，這並不會增加權重本身的內容。
如果一個函式庫在模型訓練時還不存在，那麼它就不在權重中。你可以將文件放入上下文，Claude 會使用它們，但這是引導，而非教導。Claude 的回應僅在該次請求中受到影響，但底層模型並未記住任何東西。
當 Claude 自信地呼叫一個不存在的 API（即幻覺）時，這是權重產生了一個從訓練模式看來看似合理的 token 序列，而不是一次失敗的查找。
那麼，改變模型實際上做了什麼？它會交換處理你請求的那組凍結權重。
模型不會一次生成整個答案。它會預測一個 token，將其附加到序列中，然後重新執行整個計算以獲得下一個 token。一個 200 個 token 的回應需要 200 次通過權重的獨立計算。這個循環是你大部分等待時間（以及你的輸出成本）的來源。
序列每一步只增加一個 token。模型每次都會重新讀取整個陣列，以預測接下來會發生什麼。
模型設定決定了哪些權重來處理你的請求，也決定了每個輸出 token 的成本。
它不決定的是會生成多少個 token。對於相同的提示詞，這個數字可能會有很大差異，取決於 Claude 決定做多少工作。
而這正是努力程度所控制的。
努力程度的運作方式
當 Claude Code 正在處理一個任務時，它生成的 token 會分為以下幾類：
- 思考： 你看到在操作之前和之間串流傳輸的推理過程。
- 工具呼叫： 結構化的區塊，指名一個工具（如 Read 或 Edit）及其參數，然後由 Claude Code 解析並執行。
- 給你的文字： 計劃、進度更新、最後的摘要。
這些都是來自同一個循環的普通輸出 token，並以相同的費率計費。例如，思考 token 的生成方式與其他輸出 token 完全相同，並在該輪次剩餘時間內保持在上下文中。
當 Claude 繼續編寫程式碼時，它先前的推理已成為輸入的一部分，就像它讀取過的檔案一樣。
Claude 的所有輸出都是 token。思考、工具呼叫和給你的文字都是從同一個循環生成的。
那麼，努力程度如何改變這一切呢？努力程度是作為請求的一部分，與你的提示詞一起發送給模型的。模型經過訓練，能夠理解在每個努力程度下應如何行為，而這種學習到的行為被固化在凍結的權重中。
當你的請求到達時，努力程度只是模型回應的另一個輸入，就像它回應你的提示詞文字一樣。它設定了 Claude 在認為任務完成之前需要達到的透徹程度和確定程度。這在每一輪中都會被權衡，而達到更高的信心需要消耗更多的 token。
相同的提示詞，兩種努力程度。高努力程度的路徑會生成大約 7 倍的 token 數，以達到更高信心的答案。
在較高的努力程度下，Claude 通常會先建立一個計劃，而努力程度會影響該計劃的深度和廣度。但計劃並非一成不變。當 Claude 從其行動中獲得結果時，它會更新自己對進展情況以及對累積結果的確信程度的評估。
當一個包含三個假設的除錯計劃中的步驟 1 找到了錯誤時，「調查假設 2 和 3」可能就不再必要了。Claude 通常會明確說明這一點（例如「第一次檢查找到了，所以不需要進行後續檢查」）並跳過。當任務清單在執行過程中被修改時，你可以在 Claude Code 中看到這種情況。
較高的努力程度的確會讓 Claude 更有可能進行雙重檢查，例如驗證它找到的答案，或者仍然去查看它本可以跳過的假設。然而，對於一個簡單的任務，它通常不會僅僅因為努力程度調高而人為地增加使用量。「過度思考」是我們團隊在模型訓練期間特別監控的情況，因為它會降低效能。
選擇努力程度
對於大多數任務，請使用模型的預設努力程度。預設程度是 Claude 將其 token 使用量擴展到大多數人希望在一個任務上花費的程度。
將努力程度視為一個手動覆蓋開關，用於控制 Claude 工作的努力程度和時間長度。當你根據你的領域或你從事的工作類型，對透徹性或速度有強烈偏好時，請有意識地使用它，並將其視為一個一般偏好，而不是一個逐個任務的決定。
在 Opus 4.8 推出後，有一個實用注意事項：在我們的測試中，Opus 4.8 上的預設努力程度設定，對於同一個任務，產生的結果比 Opus 4.7 上的預設努力程度設定更好，而消耗的 token 數量大致相同。
當 Claude 出錯時，該改變什麼
當 Claude 出錯時，你的第一反應不應該是改變設定。而應該是檢查你提供給它的上下文。你的提示詞是否太模糊？Claude 是否連接到正確的工具？它是否擁有正確的技能？
如果你在一個不應該需要高努力程度的任務上增加努力程度，那麼修正通常在上游：在你的上下文、你的 CLAUDE.md 中，或者任務的範圍界定方式。
但假設你已經提供了清晰的上下文，而 Claude 仍然出錯。你要問自己的問題是：它是努力不夠，還是知識不足？
模型：問題太難了
當問題確實很困難時，例如微妙的錯誤、不熟悉的領域、架構決策，請選擇更大的模型。當較小的模型無論你提供多少上下文都自信地犯錯時，你需要的是一個更大的模型。
較大的模型也更擅長處理模糊性。在較小的模型上，具體的、指導執行過程的指令是成功的更好方法。
當工作屬於例行公事時，請選擇較小的模型：你可以精確描述的編輯、機械性的更改、對已存在於上下文中的程式碼提出的問題。沒有理由為任務不需要的能力付費。
如果 Claude 擁有所有相關上下文，明顯嘗試過，但仍然出錯；這是一個信號，表示應該選擇更大的模型。如果你一直在使用較大的模型，而工作已經例行化了一段時間，那麼降低模型等級將提高速度，並且通常會降低成本，而不會影響輸出品質。
努力程度：Claude 沒有足夠努力
如果 Claude 因為不夠努力而出錯：跳過了一個檔案、沒有執行測試、或者沒有再次檢查其工作，請選擇更高的努力程度。這在你選擇的努力程度低於模型預設值時最為相關。
專家、高手與通才
我喜歡將這兩種設定理解為：Fable 是能處理幾乎無人能解問題的專家，Opus 是高手，而 Sonnet 是優秀的通才。努力程度決定了他們中的任何一位在你的任務上花費多少時間。
低努力程度的 Opus，就像你與一位對你遇到的問題有豐富經驗的專家進行了五分鐘的交流。他們帶來了你的程式碼庫中不存在的知識；他們以前見過的模式，他們知道要檢查的陷阱，只有解決過大量類似問題才能獲得的經驗。但五分鐘意味著快速瀏覽你的程式碼，而不是仔細檢查每個檔案。
高努力程度的 Sonnet 就像一位擁有整個下午時間的通才。他們擅長編碼，會閱讀所有內容、執行各種操作、再次檢查他們的工作，最終徹底理解你的特定程式碼。
Fable 是你會在所有人都卡住時召喚的專家。即使在低努力程度下，他們也能發現其他人無法發現的東西。這種識別能力正是你花費最多代價所獲得的，所以值得將其留給真正需要它的任務。
這些沒有哪一個是普遍「更好」的。模型設定大致上代表能力強弱；而努力程度設定大致上代表透徹程度。大多數實際任務都需要兩者兼備。
努力程度、模型與 token 消耗
那麼，模型選擇、努力程度和 token 消耗是如何相互作用的呢？這取決於任務。
對於相同努力程度下的例行工作，較大和較小的模型通常都能正確完成。較大的模型會消耗更多 token 進行額外的驗證步驟，且每個 token 的價格更高。這就是為什麼在例行工作階段改用較小的模型，可以在不影響品質的情況下節省實際費用的原因。
曲線僅供說明，顯示的是單一任務，該任務足夠簡單，兩個模型都能快速完成。它們不代表真實的基準測試數據。
對於更困難、多步驟的工作，情況則相反。較小的模型必須在其能力極限附近掙扎，消耗大量迭代次數，而較大的模型則可以用更少的步驟達到相同的品質標準。
你為較大模型的每個 token 支付了更高的費用，但對於那些真正考驗較小模型的任務，每個任務的總成本反而可能更低。更重要的是：較大的模型可以完成較小的模型即使使用最高努力程度設定也無法完成的任務。
這一點在 Fable 身上最為明顯。在長時間、多步驟的工作中，它的領先優勢最大。在我們的測試中，它完成了 Opus 和 Sonnet 在任何努力程度下都無法達到的任務。它的每個 token 成本也最高，這是將其留給真正需要它的工作的另一個原因。
曲線僅供說明，顯示的是單一任務，該任務足夠困難，足以考驗兩個模型。它們不代表真實的基準測試數據。
上圖的關鍵點在於：努力程度選擇了 Claude 願意沿著曲線走多遠。這並不意味著 Claude 需要走那麼遠才能完成任務。
最後，努力程度會影響 token 消耗，但並不限制它。系統中唯一的硬性上限是 max_tokens，它會在達到上限時截斷中間的回應，但它是一個粗略的工具，主要與 API 開發者相關。像 task budgets 或在提示詞中要求 Claude 保持簡潔這類軟性控制更有幫助。它們是模型經過訓練要遵循的指導方針（它會在接近限制時設法結束），而不是它會撞上的牆。
努力程度改變 Claude 做多少工作。模型改變 Claude 知道什麼。
當你對結果不滿意時，在調整任何設定之前，請先檢查上下文：給 Claude 一個清晰的提示詞、正確的工具和技能，以及一個驗證自身工作的方式。
如果 Claude 仍然出錯，問問自己：是它知道得不夠，還是它努力得不夠？知道得不夠是模型的問題，努力不夠是努力程度的問題。
本文由 @lydiahallie 撰寫，她是 Claude Code 團隊的技術人員。
