如果我用的模型已經不接受自訂 Temperature 值，是不是代表 Temperature 這個概念完全過時、不用再理解了？
不是。即使某個模型層級的參數不再可調，理解 Temperature 這個機制本身依然有價值，原因有兩個：第一，並不是所有模型都同時停用了這個參數，如果你會在不同模型之間切換（例如某些場景用較舊的模型），還是可能遇到 Temperature 仍然生效的情況；第二，理解「選詞隨機性」跟「推理深度」是兩個獨立維度，能幫助你更準確地描述自己遇到的問題——當你發現輸出缺乏變化時，才不會誤以為調高 Effort 就能解決，因為那其實是 Temperature（或者在新模型上，是提示詞本身的措辭）該處理的範疇。
Effort 有明確的等級名稱（像 low、medium、high），Temperature 是連續數值，這個差異本身重不重要？
這個差異某種程度上反映了兩者被設計來服務的對象不同。Temperature 作為一個連續數值（通常 0 到 1），是比較貼近底層取樣機制的參數，需要使用者自己去感受、實驗不同數值帶來的差異；Effort 用具名等級取代連續數值，某種程度上是把「這個任務該花多少心思」這個判斷，轉譯成更貼近人類日常思考方式的語彙——你不需要知道「high 對應到多少 token 的思考預算」，只需要判斷這個任務屬於「顯而易見」還是「牽涉多方取捨」。
這也呼應了前面提到的趨勢：Effort 的設計目標本來就是取代相對抽象的取樣參數控制，改用更直觀的分級語彙，讓使用者不需要理解底層機率分布，也能做出合理的選擇。
Effort 調高會不會像 Temperature 調高一樣，讓輸出變得更「隨機」、更不可預測？
不會，這正是兩者最容易被搞混、但實際上完全相反的地方。調高 Temperature 確實會讓輸出的隨機性、變化程度增加；但調高 Effort 通常會讓輸出在「正確性」與「涵蓋的細節」上更穩定、更一致，因為 Claude 花了更多推理步驟去驗證、比對不同做法，反而更不容易漏掉邊界情況。高 Effort 搭配低 Temperature 是需要正確性場景（例如程式碼生成）常見的組合，就是因為這兩個維度的效果不但不衝突，反而是互補的——一個負責讓思考更周全，一個負責讓最終選詞更收斂。
我平常只用 Claude Code 寫程式，不碰 API，這篇講的東西對我有實際幫助嗎？
有幫助的部分是判斷邏輯，不是操作介面本身。Claude Code 使用者確實接觸不到 Temperature 這個參數，但 Effort 是你日常就在用的東西（透過 /effort 指令切換等級），理解「Effort 調的是思考深度」這個心智模型，能幫助你更準確判斷什麼時候該往上調——例如遇到一個牽涉多個檔案、需要判斷架構取捨的重構任務，卻發現 Claude 給出的方案漏掉了明顯的邊界情況，這時候該做的是調高 Effort，而不是重新描述你的需求或抱怨模型不夠聰明。
反過來，如果你發現的問題是「同樣的重構任務問兩次，得到的程式碼風格差異很大、缺乏一致性」，這其實跟 Effort 無關——這種情況下更該檢查的是你的提示詞或專案設定裡有沒有清楚定義程式碼風格規範，而不是去調整一個你根本碰不到的 Temperature 參數。
如果你同時看過討論 Temperature 和討論 Effort 的文章，很容易把兩者混成同一件事——畢竟兩者都常被形容成「調整 Claude 輸出方式的旋鈕」。但這兩個參數控制的其實是完全不同的機制，而且其中一個在較新的模型上已經悄悄失去作用，如果你的心智模型還停留在舊版本，很可能會踩到一個不容易察覺的坑。
Temperature 影響的是 Claude 在生成每一個 token（詞或詞的片段）時，從機率分布裡挑選結果的隨機程度。設為 0 時，Claude 每次都選機率最高的那個選項，同樣的輸入會產生高度一致、接近確定性的輸出；設為 1（多數模型的預設值與上限）時，Claude 更願意選擇機率較低的選項，輸出會更有變化，也更容易出現天馬行空的內容。這個機制跟 Claude「想得多深」完全無關——即使 Temperature 設為 0，Claude 依然可能給出一個膚淺、沒有深入思考的答案，因為 Temperature 管的只是「選詞時的隨機性」，不是「思考的徹底程度」。
Effort 這個參數則是完全不同的維度：它決定 Claude 在給出最終答案之前，願意投入多少推理（thinking）預算去分析問題。低 Effort 時，Claude 更傾向直接依賴已經訓練好的模式匹配給出答案，跳過深入的逐步推理，適合答案顯而易見、不需要多想的任務；高 Effort 時，Claude 會花更多內部推理步驟去拆解問題、比對多種可能的做法，適合牽涉多個系統、需要判斷取捨的複雜任務。這個維度影響的是「用了多少心思去想」，跟最終選詞時挑高機率還是低機率選項是兩回事。
正因為這是兩個獨立的維度，理論上你可以組合出四種極端：低 Effort、低 Temperature（快速給出一個保守、一致的答案）；高 Effort、低 Temperature（深入推理後，穩定地選擇最有信心的那個結論，這是程式碼生成等需要正確性場景常見的組合）；低 Effort、高 Temperature（不特別深思，但選詞天馬行空）；高 Effort、高 Temperature（深入推理，但最終選詞仍保留較大隨機性，適合需要創意但又不想太隨便的場景）。實務上，多數任務只需要調整其中一個維度，同時大幅調動兩者的情況比較少見。
這裡有一個對正在學習這兩個參數的人特別容易誤導的地方：從 Claude Opus 4.7 開始，傳入非預設的 Temperature 數值會直接收到 API 錯誤（400 錯誤）——也就是說，在這些較新的模型上，Temperature 這個參數實質上已經被拿掉了，不再是一個可以自由調整的旋鈕。這個變化背後的脈絡，是 Anthropic 把「思考深度」的控制權逐漸集中到 Effort 與 thinking 參數上，用更貼近「這個任務該想多深」的語彙，取代原本相對抽象的取樣參數。
如果你參考的教學是比較舊的文章、或是針對舊版模型寫的，裡面提到「調整 Temperature 讓輸出更穩定」這類建議，在新模型上可能根本無法照做——這也是為什麼理解 Effort 跟 Temperature 是兩個不同維度，而不是「新舊版本的同一個東西」，會直接影響你能不能正確排查為什麼某個參數設定不生效。
如果你主要透過 Claude.ai 網頁版聊天，或使用 Claude Code 這個終端機工具，Temperature 從來就不是一個你能直接調整的介面選項——這兩個介面都沒有暴露數值化的 Temperature 滑桿，平台會用固定的預設值運作。相對地，Effort 在 Claude Code 裡是可以直接透過指令切換的（例如輸入 /effort 搭配等級名稱），這也是為什麼多數一般使用者實際上更常打交道的是 Effort，而不是 Temperature——後者主要活在 API 開發情境裡。
下次想「調整 Claude 的輸出」時，先問自己一個問題：我要解決的是「答案想得不夠深、漏掉了該考慮的情況」，還是「輸出太死板、每次都一樣、缺乏變化」？前者該調的是 Effort，後者才輪到 Temperature——如果你在使用較新的模型，且透過 API 呼叫，也要先確認這個模型是否還接受自訂 Temperature 值，避免對著一個已經失效的參數反覆除錯。