Claude Code 中的模型與努力程度：了解更多 vs. 嘗試更努力

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。 展開畫面重點圖表呈現了從客戶端發送請求至 Anthropic Server 的處理流程，包含以下區塊與文字： 左側輸入區塊：包含 System prompt、Tool definitions、CLAUDE.md、Conversation history、Files in context、Your message。 中間 API 請求區塊：標題為「One API request」，顯示 POST /v1/messages 的 JSON 格式範例，包含欄位："model"、"system"、"tools"、"messages" 以及 "output_config" 下的 "effort"。 右側 Anthropic Server 區塊：包含一個 Tokenizer 處理單元，將程式碼片段「const x」轉換為數值「1078」與「865」，隨後將資料傳遞至下方的「Model」區塊。 然而，模型永遠不會以純文字的形式看到這些內容。伺服器端發生的第一件事是 tokenization：文字會被拆解成片段，每個片段會對應到模型訓練時所使用的固定詞彙表中的一個整數。例如 const 可能對應到 1978，await 可能對應到 4293。從這裡開始，你的提示詞就變成了一串整數陣列。 展開畫面重點圖片展示了程式碼 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" 近乎零的機率（完全不可能）。 展開數據表項目數值fetch0.62Promise0.14getUser0.07new0.03banana≈0 將你的輸入 token 轉化為這些機率的關鍵在於權重（也稱為參數）：這是數十億個組織成大型矩陣的數字。為了預測一個 token，模型會將你的輸入通過這些矩陣（一連串長長的矩陣乘法），並在最後讀取機率。模型所「知道」的一切，都存在這些權重之中。 每個模型的權重是在訓練期間設定的，當你發送請求時，這些權重是唯讀的。你的提示詞、CLAUDE.md 或 context 中的任何內容都不會改變它們。如果你聽過「推論」（inference）這個詞，它的意思就是：在訓練完成後，使用權重已固定的模型。 展開數據表（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.62Promise0.14getUser0.07banana~0 Claude 對 TypeScript、熱門框架或任何其他通用程式開發知識的了解，都是在訓練時編碼進這些權重裡的。 你的提示詞和 context 仍然可以引導預測結果。將你的真實程式碼放在 Claude 面前就是一種引導，而且效果非常好。然而，這並不會對權重本身增加任何東西。 如果某個函式庫在模型訓練時還不存在，它就不會存在於權重中。你可以將文件放入 context 中讓 Claude 使用，但那屬於「引導」，而不是「學習」。Claude 的回應只會受到該次請求的影響，底層模型並沒有保留任何資訊。 當 Claude 自信滿滿地呼叫一個不存在的 API 時（即幻覺），那是權重產生了一個從訓練模式看來合理，但實際上是錯誤的 token 序列，而不是查詢失敗。 那麼，更改模型究竟做了什麼？它只是切換了處理你請求的那組凍結權重。 模型不會一次生成完整的答案。它會預測一個 token，將其附加到序列中，然後再次執行整個計算以獲取下一個 token。一個 200 個 token 的回應，意味著權重經過了 200 次獨立的運算。這個迴圈就是你大部分等待時間（以及輸出成本）的來源。 展開畫面重點圖片呈現了語言模型生成 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 模型處理資訊的循環過程，左側為「weights」（權重），右側為三個階段的運作內容： thinking（思考階段）：顯示為「Let me check the config ...」。 tool call（工具呼叫階段）：顯示為「Read ( "src / index .ts" )」。 text to you（輸出階段）：顯示為「Fou…