# 策展 · X (Twitter) 🔥🔥🔥🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：ClaudeDevs (@ClaudeDevs) · 平台：X (Twitter) · 日期：2026-07-09 > 原始來源：https://x.com/ClaudeDevs/status/2074900291062034618 ## 中文摘要 # Claude Code 中的模型與努力程度：了解更多 vs. 嘗試更努力 Claude Code 提供了兩個設定，看起來似乎都能「讓答案變得更好」：模型（Model）與努力程度（Effort）。但這些設定對輸出結果究竟有什麼影響？你又該如何判斷是該換個模型，還是調整努力程度就好？ 我們很容易認為，選擇像 Fable 這樣的大型模型會比 Sonnet 得到更聰明的輸出，而提高努力程度只是代表 Claude 在回答前會思考得更久。 第一個假設是正確的。根據業界標準的基準測試，我們最大的模型確實具備更強的能力。 但「努力程度」的意義不僅僅是「思考時間」。努力程度控制了 Claude 在處理你的請求時，整體投入了多少工作量。這不僅包含它思考的時間，還包括： - 它讀取了多少檔案； - 它做了多少驗證；以及 - 在向你回報進度前，它在多步驟任務中推進了多遠。 在較高的努力程度下，Claude 會在回覆你之前採取更多行動（讀取檔案、執行測試、雙重檢查）。而在較低的努力程度下，它寧願要求你提供更多 context，也不願花費 token 自己去推敲出答案。 --- ## 模型選擇的運作方式 要理解模型設定究竟控制了什麼，我們得從最開始說起——也就是你按下 Enter 鍵的那一刻。 Claude Code 會將你的訊息與系統提示詞（system prompt）、工具定義（tool definitions）、你的 `CLAUDE.md`、對話紀錄以及任何在 context 中的檔案組合在一起。這一切會作為單一請求發送到 API。 ![此圖表展示了將多項輸入參數整合為單一 API 請求，並經由 Tokenizer 處理後傳送至模型運算的流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/74fa3770916b2550.jpg)
展開畫面重點
圖表呈現了從客戶端發送請求至 Anthropic Server 的處理流程，包含以下區塊與文字： 1. 左側輸入區塊：包含 System prompt、Tool definitions、CLAUDE.md、Conversation history、Files in context、Your message。 2. 中間 API 請求區塊：標題為「One API request」，顯示 POST /v1/messages 的 JSON 格式範例，包含欄位："model"、"system"、"tools"、"messages" 以及 "output_config" 下的 "effort"。 3. 右側 Anthropic Server 區塊：包含一個 Tokenizer 處理單元，將程式碼片段「const x」轉換為數值「1078」與「865」，隨後將資料傳遞至下方的「Model」區塊。
然而，模型永遠不會以純文字的形式看到這些內容。伺服器端發生的第一件事是 tokenization：文字會被拆解成片段，每個片段會對應到模型訓練時所使用的固定詞彙表中的一個整數。例如 `const` 可能對應到 1978，`await` 可能對應到 4293。從這裡開始，你的提示詞就變成了一串整數陣列。 ![這張圖展示了大型語言模型（LLM）如何將程式碼片段進行 Tokenization（標記化）的過程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/68888f1d2201b6ac.jpg)
展開畫面重點
圖片展示了程式碼 `const x = await fetch(` 如何被拆解為 Token ID。 上方顯示程式碼片段，下方為對應的 Token 區塊與其 ID： - `const` : 1078 - ` x` : 865 - ` =` : 284 - ` await` : 2597 - ` fetch` : 7185 - `(` : 7 右側為「VOCABULARY」列表，顯示總計 100,257 個條目，並標示出 ID 7185 對應的詞彙為 `" fetch"`。左下角註記 `.` 代表 leading space（前導空格）。此圖解說明了模型如何將文字轉換為數值序列，其中 `fetch` 被識別為詞彙表中的第 7185 個項目。
模型的工作就是接收這個陣列，並預測下一個 token 是什麼。它透過計算詞彙表中每個 token 的機率，並從中挑選機率最高的來達成。在 "const x = await" 之後，一個訓練有素的模型會給 "fetch" 很高的機率（非常可能），而給 "banana" 近乎零的機率（完全不可能）。 ![在預測「const x = await」後續接續詞彙的機率中，「fetch」以 0.62 的高機率位居第一，顯著高於「Promise」（0.14）與「getUser」（0.07）。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5a9ac7d6f76a92cd.jpg)
展開數據表
項目數值
fetch0.62
Promise0.14
getUser0.07
new0.03
banana≈0
將你的輸入 token 轉化為這些機率的關鍵在於權重（也稱為參數）：這是數十億個組織成大型矩陣的數字。為了預測一個 token，模型會將你的輸入通過這些矩陣（一連串長長的矩陣乘法），並在最後讀取機率。模型所「知道」的一切，都存在這些權重之中。 每個模型的權重是在訓練期間設定的，當你發送請求時，這些權重是唯讀的。你的提示詞、`CLAUDE.md` 或 context 中的任何內容都不會改變它們。如果你聽過「推論」（inference）這個詞，它的意思就是：在訓練完成後，使用權重已固定的模型。 ![該示意圖說明了語言模型預測下一個 Token 的運作流程：輸入 Token 序列經過訓練後唯讀的數十億個權重參數計算，最終輸出候選 Token 的機率分佈，其中以「fetch」的預測機率最高（0.62）。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/962d9107377c6963.jpg)
展開數據表（1）INPUT TOKENS
項目數值
1078, 865, 284, 2597, ...
展開數據表（2）weights
第一列 · .12 · -1.4 · .83 · -.07
第二列 · -.31 · .09 · -1.8 · .44
第三列 · 1.7 · -.23 · .05 · -1.1
第四列 · -.64 · .91 · -.18 · .27
第五列 · .33 · -.57 · 1.2 · -.85
展開數據表（3）NEXT-TOKEN PROBABILITIES
項目數值
fetch0.62
Promise0.14
getUser0.07
banana~0
Claude 對 TypeScript、熱門框架或任何其他通用程式開發知識的了解，都是在訓練時編碼進這些權重裡的。 你的提示詞和 context 仍然可以引導預測結果。將你的真實程式碼放在 Claude 面前就是一種引導，而且效果非常好。然而，這並不會對權重本身增加任何東西。 如果某個函式庫在模型訓練時還不存在，它就不會存在於權重中。你可以將文件放入 context 中讓 Claude 使用，但那屬於「引導」，而不是「學習」。Claude 的回應只會受到該次請求的影響，底層模型並沒有保留任何資訊。 當 Claude 自信滿滿地呼叫一個不存在的 API 時（即幻覺），那是權重產生了一個從訓練模式看來合理，但實際上是錯誤的 token 序列，而不是查詢失敗。 那麼，更改模型究竟做了什麼？它只是切換了處理你請求的那組凍結權重。 模型不會一次生成完整的答案。它會預測一個 token，將其附加到序列中，然後再次執行整個計算以獲取下一個 token。一個 200 個 token 的回應，意味著權重經過了 200 次獨立的運算。這個迴圈就是你大部分等待時間（以及輸出成本）的來源。 ![此圖展示了語言模型在生成程式碼時，透過逐步預測 Token 的運作過程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5aebb65729c23e0c.jpg)
展開畫面重點
圖片呈現了語言模型生成 JavaScript 程式碼 `const x = await fetch(url);` 的五個步驟，每個步驟顯示了模型當前預測的 Token 以及對應的機率值（p）： - step 1: 預測 `fetch`，機率 p=0.62 - step 2: 預測 `(`，機率 p=0.93 - step 3: 預測 `url`，機率 p=0.71 - step 4: 預測 `)`，機率 p=0.98 - step 5: 預測 `;`，機率 p=0.99 底部說明指出此過程會針對每個輸出的 Token 重複進行，例如輸出 200 個 Token 即對應 200 個步驟。
模型設定決定了哪組權重處理你的請求，也決定了每個輸出 token 的成本。 它沒有決定的是會生成多少個 token。對於相同的提示詞，這個數字可能會因為 Claude 決定做多少工作而有很大差異。 而這正是努力程度所控制的部分。 --- ## 努力程度的運作方式 當 Claude Code 處理任務時，它生成的 token 分為幾類： - 思考（Thinking）：你在行動前後看到的串流推理過程。 - 工具呼叫（Tool calls）：結構化的區塊，命名如 Read 或 Edit 等工具及其參數，Claude Code 隨後會解析並執行這些內容。 - 給你的文字（Text to you）：計畫、進度更新、最後的總結。 這些都是來自同一個迴圈的普通輸出 token，並以相同的費率計費。例如，思考 token 的生成方式與其他輸出 token 完全相同，並且在該次對話的剩餘部分中會保留在 context 裡。 當 Claude 進入撰寫程式碼的階段時，它之前的推理過程已經成為輸入的一部分，就像它讀取的檔案一樣。 ![此圖展示了 AI 模型在處理任務時，透過「思考」、「工具呼叫」與「輸出結果」三個階段的運作流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/992371e80f8a1eb3.jpg)
展開畫面重點
圖片展示了一個 AI 模型處理資訊的循環過程，左側為「weights」（權重），右側為三個階段的運作內容： 1. thinking（思考階段）：顯示為「Let me check the config ...」。 2. tool call（工具呼叫階段）：顯示為「Read ( "src / index .ts" )」。 3. text to you（輸出階段）：顯示為「Found it : line 42 .」。 底部文字說明：「Same loop. Same per-token price. The only difference is what the tokens say.」（相同的循環。相同的每 Token 價格。唯一的區別在於 Token 的內容。）
那麼，努力程度是如何改變這一切的呢？努力程度設定會作為請求的一部分，與你的提示詞一起發送給模型。模型經過訓練，能夠理解在每個努力程度下該如何表現，而這種學習到的行為已經內建在凍結的權重中。 當你的請求到達時，努力程度只是模型回應的另一個輸入，就像它回應你的提示詞文字一樣。它設定了 Claude 在認為任務完成前，需要達到多麼徹底、多麼確定的程度。這在每一輪對話中都會被權衡，而更高的信心水準需要消耗更多的 token 才能達成。 ![高投入（High effort）模式在修復失敗測試時會執行更完整的讀取、測試與驗證流程，消耗約 2,800 tokens，相較於低投入（Low effort）模式的 400 tokens 展現出更周全的解決路徑。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/32a55c372bbdc50e.jpg)
展開數據表
Task: "fix the failing test" · Low effort · Steps: Read test file -> Think -> Edit source -> "Fixed line 42." · Tokens: ~400 tokens (illustrative) · High effort · Steps: Read test file -> Read source file -> Read config -> Think -> Edit source -> Run tests -> Re-read to verify -> "Fixed: env var wasn't loaded. Tests pass." · Tokens: ~2,800 tokens (illustrative)
在較高的努力程度下，Claude 通常會先建立一個計畫，而努力程度會影響該計畫的深度與廣度。但這個計畫並非一成不變。當 Claude 從行動中得到結果時，它會更新自己對進度與結果確定性的認知。 當一個包含三個假設的除錯計畫在執行第一步時就找到了 Bug，「調查假設 2 和 3」可能就不再必要了。Claude 通常會明確說明這一點（例如：「第一次檢查就找到了，所以不需要做剩下的檢查」）並直接跳過。當你在 Claude Code 中看到任務清單在執行過程中被修改時，就是這種情況。 更高的努力程度確實會讓 Claude 更傾向於做雙重檢查，例如驗證它找到的答案，或是去探究那些本可以跳過的假設。然而，它通常不會僅僅因為努力程度調高，就刻意在簡單任務上增加使用量。「過度思考」（Overthinking）是我們團隊在模型訓練期間特別監控的行為，因為這會降低效能。 --- ## 選擇努力程度 對於大多數任務，請使用模型的預設努力程度。預設值是 Claude 將 token 使用量調整到大多數人願意為該任務付出的水準。 將努力程度視為 Claude 工作強度與時間長短的手動覆寫。當你基於你的領域或工作類型，對徹底性或速度有強烈偏好時，請謹慎地調整它，並將其視為一種整體偏好，而不是針對每個任務的決策。 關於 Opus 4.8 發布的一個實務說明：在我們的測試中，Opus 4.8 的預設努力設定在處理相同任務時，能以與 Opus 4.7 預設設定大致相同的 token 量，產生更好的結果。 --- ## 當 Claude 出錯時該怎麼辦 當 Claude 出錯時，你的第一直覺不應該是去更改設定。你應該先檢查你提供的 context。你的提示詞是否太模糊？Claude 是否連接到正確的工具？它是否具備正確的 skill？ 如果你在一個本不需要的任務上提高努力程度，解決方案通常在更上游：在你的 context、你的 `CLAUDE.md`，或是任務的範圍界定中。 但假設你已經提供了清晰的 context，而 Claude 仍然出錯。你需要問自己的問題是：它是「嘗試得不夠努力」，還是「知道得不夠多」？ ![這是一張關於當 Claude 模型出現錯誤時，如何故障排除與優化策略的決策流程圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/982bfa8821e35fe6.jpg)
展開畫面重點
該圖表呈現了一個決策樹，用以分析「Claude 出錯」的原因並提供解決方案： 1. 頂部問題：Did it not try hard enough, or did it not know enough?（它是不夠努力，還是知識不足？） 2. 核心狀態：Claude got it wrong.（Claude 出錯了。） 3. 分支一（左側）：Skipped a file / didn't run tests / stopped partway（跳過檔案 / 未執行測試 / 中途停止） - 解決方案：Raise effort（增加努力程度），說明：more tokens, same weights（更多 token，權重相同）。 4. 分支二（右側）：Read everything, clearly tried, still confidently wrong（讀取了所有內容，明顯有嘗試，但仍然自信地給出錯誤答案） - 解決方案：Try a larger model（嘗試更大的模型），說明：different weights, different capability（不同的權重，不同的能力）。 5. 底部補充：Neither? Fix the input: context, CLAUDE.md, or how the task is scoped.（都不是？請修正輸入：上下文、CLAUDE.md 檔案，或任務的範圍界定。）
模型：問題太難了 當問題確實很難時，例如細微的 Bug、不熟悉的領域、架構決策，請選擇更大的模型。當較小的模型無論你給予多少 context 都自信地給出錯誤答案時，你需要的就是更大的模型。 更大的模型在處理模糊性方面也表現得更好。對於較小的模型，指導執行過程的具體指令是成功的更好配方。 當工作是例行公事時，請選擇較小的模型：例如你可以精確描述的編輯、機械式的變更、關於已經在 context 中的程式碼的問題。沒有理由為任務不需要的能力付費。 如果 Claude 擁有所有相關的 context，明確地嘗試過，但仍然出錯，這就是選擇更大模型的訊號。而如果你正在使用較大的模型，且工作已經有一段時間都是例行公事，降級使用通常能提高速度並降低成本，且不會影響輸出品質。 努力程度：Claude 嘗試得不夠努力 如果 Claude 因為嘗試得不夠努力而做錯，例如跳過某個檔案、沒有執行測試，或是沒有做雙重檢查，請選擇更高的努力程度。如果你之前選擇的努力程度低於模型的預設值，這一點尤其重要。 --- ## 專才、專家與通才 我喜歡將這兩個設定比喻為：Fable 是一位幾乎能處理沒人能解決的問題的「專才」（Specialist），Opus 是「專家」（Expert），而 Sonnet 則是一位非常優秀的「通才」（Generalist）。努力程度則決定了他們中的任何一位在你任務上花費多少時間。 低努力程度的 Opus 就像是與一位對你的問題有深厚經驗的專家交談五分鐘。他們帶來了你的程式庫中不存在的知識；他們曾經見過的模式、他們知道要檢查的陷阱，以及只有在解決過許多類似問題後才能獲得的經驗。但五分鐘意味著只能快速瀏覽你的程式碼，而不是仔細檢查每一個檔案。 高努力程度的 Sonnet 則是一位擁有一整個下午時間的通才。他們非常擅長寫程式，會閱讀所有內容、執行測試、雙重檢查工作，最終徹底理解你的特定程式碼。 Fable 是當所有人都束手無策時你會呼叫的專家。即使在低努力程度下，他們也能發現沒人會注意到的問題。這種識別能力也是你付出最多代價的地方，所以值得將它留給真正需要它的任務。 這些設定沒有哪一個是普遍「更好」的。模型設定大致代表能力，努力程度大致代表徹底程度。大多數真實任務都需要兩者兼具。 --- ## 努力程度、模型與 token 消耗 那麼，模型選擇、努力程度與 token 消耗是如何相互作用的？這取決於任務。 在相同努力程度下的例行工作中，較大與較小的模型通常都能正確完成。較大的模型會因為額外的驗證步驟而消耗更多 token，且每個 token 的價格更高。這就是為什麼在例行工作中降級到較小的模型，可以在不犧牲品質的情況下節省實際成本。 ![此圖比較了大型模型與小型模型在簡單任務下，消耗 Token 數量與結果品質之間的關係曲線。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0f2e81a0c0e72315.jpg) 在更困難、多步驟的工作中，情況則會反轉。較小的模型必須在能力極限邊緣掙扎，消耗大量的迭代次數，而較大的模型則能以更少的步驟達到相同的品質標準。 雖然你為較大模型支付的每個 token 成本較高，但在那些真正考驗較小模型的任務中，每個任務的總成本反而可能更低。更重要的是：較大的模型可以完成較小模型即使在最高努力設定下也無法完成的任務。 這一點在 Fable 上最為顯著。在漫長、多步驟的工作中，它的領先優勢最大。在我們的測試中，它完成了 Opus 和 Sonnet 在任何努力程度下都無法達成的任務。它也是每個 token 成本最高的模型，這也是為什麼要將它留給真正需要它的工作的原因。 ![模型決定了品質與成本的關係曲線，而努力程度（Effort）決定了沿曲線前進的距離；較大模型在「中等（med）」努力程度下，能以更少的 token 達到與較小模型在「最大（max）」努力程度下相同的輸出品質。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/9530e1a532d2aed6.jpg)
展開數據表
medmax
Larger model與 Smaller model max 品質相同但 token 較少最高品質與最高 token
Smaller model最低品質與最低 token與 Larger model med 品質相同但 token 較多
上述圖表的關鍵在於：努力程度決定了 Claude 願意沿著曲線走多遠。這並不代表 Claude 完成任務一定需要走那麼遠。 最後，努力程度會形塑 token 消耗，但不會限制它。系統中唯一的硬性上限是 `max_tokens`，它會在觸發時截斷回應，但這是一個生硬的工具，主要與 API 開發者相關。像任務預算或在提示詞中要求 Claude 保持簡潔這類較軟性的控制方式會更有幫助。它們是模型被訓練要遵循的指引（當接近限制時，它會設法收尾），而不是它會撞上的牆。 --- 努力程度改變了 Claude 做多少工作。模型改變了 Claude 知道什麼。 當你對結果不滿意時，在調整任何設定之前，請先檢查 context：給 Claude 一個清晰的提示詞、正確的工具與 skill，以及一種驗證自身工作的方法。 如果 Claude 仍然出錯，問問自己：它是「知道得不夠多」，還是「嘗試得不夠努力」？知道得不夠多是模型問題，嘗試得不夠努力則是努力程度問題。 --- 本文由 Claude Code 團隊技術人員 @lydiahallie 撰寫。 ## 標籤 Claude Code, CLI, 教學資源, 功能更新, Anthropic, Claude