Temperature 該設多少才「正確」？有沒有一個萬用的建議值？
沒有真正萬用的數字，因為適合的數值完全取決於任務性質。Anthropic 官方給的是方向性建議：分析型、選擇題導向、需要精確一致的任務適合接近 0；創意型、生成型、需要多樣化表達的任務適合接近 1。
實務上比較有參考價值的做法，是先從預設值（1.0）或一個中間值（例如 0.5）開始測試，觀察輸出結果是否符合你的需求，再依照「太發散就往下調、太死板就往上調」的方向微調，而不是一開始就套用某個聽來的固定數字。不同任務、不同 prompt 結構，最適合的 temperature 也會不一樣。
如果我不小心同時設定了 temperature 跟 top_p，會發生什麼事？該怎麼修？
如果你用的是 Claude 4.1 Opus 之後的模型，同時傳入 temperature 跟 top_p 兩個參數會直接觸發 API 的 400 錯誤，請求會被拒絕，錯誤訊息會明確寫出「temperature and top_p cannot both be specified for this model」。這不是網路不穩或帳號問題，是 API 端主動擋下這種請求。
修法很直接：檢查你的程式碼或串接的第三方工具設定，確認只保留其中一個參數（Anthropic 建議優先保留 temperature，因為它比較直覺、也是大多數情境下唯一需要調整的參數），把另一個拿掉或設為 null／不傳送。如果你用的是別人開發的工具或外掛，且找不到地方關掉其中一個參數，這通常代表該工具的維護者還沒更新對應這個 API 變更，值得去對應的 issue tracker 回報或搜尋看看是否已有人回報。
除了 temperature 跟 top_p，Claude API 還有其他控制輸出風格的參數嗎？
有，Claude API 還提供 top_k 這個進階採樣參數，作用是限制模型每一步只能從機率排名前 k 個候選字裡做選擇，理論上能進一步收窄輸出的隨機範圍。不過官方文件把它標註為「僅建議進階使用情境使用」，一般情況下只需要調整 temperature 就足夠了，不需要額外疊加 top_k。
另外要特別區分的是，Claude 較新的模型（例如支援 Extended Thinking 的版本）還有一個「effort（努力程度）」的概念，控制的是推理深度（低／中／高／最高），這跟 temperature 控制的「輸出隨機性」是完全不同的維度——temperature 影響的是「怎麼選字」，effort 影響的是「花多少力氣推理」，兩者不能混為一談，且部分較新模型（如 Opus 4.7 之後）如果收到非預設 temperature 值甚至會直接回傳錯誤，這種情境下改用 effort 參數才是正確方向。
如果我想開始練習調整 temperature，可以怎麼上手？
最實際的起手式，是挑一個你經常重複使用 Claude API 的任務（例如固定格式的資料摘要，或是固定風格的行銷文案生成），先用預設值（1.0）跑幾次，記錄下輸出結果的變化程度；接著把 temperature 調到 0.2 左右再跑幾次，比較兩組結果的差異——你會很直觀地感受到，低溫時的輸出彼此之間相似度明顯提高，高溫時則每次都有不小的變化。
做完這個對照之後，回頭看你原本的任務需求：如果你要的是「這件事每次都做得一樣好、一樣穩」，就往低溫靠；如果你要的是「這件事每次都能給我新想法」，就往高溫靠。這個練習做過一輪，你對「這個任務該用什麼溫度」就會建立起比查表格更直覺的判斷依據。
如果你在網路上查過怎麼讓 Claude 的回答「更有創意一點」或「更穩定一點」，大概率會撞見「temperature」這個詞。但這個參數常被誤解成某種「聰明度」或「品質」的開關，實際上它只跟一件事有關：Claude 在選下一個字的時候，要多聽話還是多冒險。
Claude 產生文字的方式，是每一步都在一堆候選字裡依照機率高低做選擇。Temperature 決定的是這個選擇過程要多保守：數值設成 0.0，Claude 幾乎每次都會挑機率最高的那個字，回答會顯得穩定、一致；數值設成 1.0（這也是 API 的預設值），Claude 會更常在多個候選字之間取捨，回答會顯得更有變化，但也更難預測。
有一個細節值得特別記住：即使把 temperature 壓到 0.0，Anthropic 官方文件也明確寫著結果並不會因此變成完全確定性——同一個問題問兩次，答案還是可能有些微差異，只是差異幅度會小很多。如果你的應用場景需要百分之百可重複的輸出，temperature 本身並不能單獨保證這件事。
Anthropic 官方的建議方向很直白：分析型、選擇題導向、需要精確一致的任務，適合把 temperature 調低，接近 0；創意型、生成型、需要多樣化表達的任務，適合調高，接近 1。實務上常見的分類是：程式碼生成、資料分類、法律或財務文件摘要，這類任務通常希望每次跑出來的結果都差不多，適合低溫；腦力激盪行銷文案、小說對白、需要多個不同版本的創意發想，適合高溫，讓模型願意嘗試機率較低但可能更有趣的選字。
值得一提的是，有經驗的開發者社群裡流傳一個延伸提醒：如果你在做的是 RAG（檢索增強生成）應用，目標是讓 Claude 忠實引用你檢索到的資料而不是自由發揮，這種情境即使不是嚴格的「分析任務」，也建議把 temperature 壓低（大約 0 到 0.3），因為溫度太高會增加模型「講得煞有其事卻偏離檢索內容」的機率，這種現象使用者體驗上會覺得像是幻覺，但根源其實是採樣設定，不是檢索本身出了問題。
Temperature 還有一個進階採樣參數叫 top_p（核採樣），兩者都在調整同一套機率分佈的取捨方式。Anthropic 官方文件一直都建議「調整 temperature 或 top_p 兩者擇一，不要同時調整」，因為同時調整會讓結果變得難以預測跟除錯。
但這條建議在 Claude 4.1 Opus（2025 年 8 月）之後，從「建議」變成了「強制」：API 現在會直接對同時收到 temperature 與 top_p 兩個參數的請求回傳 400 錯誤，訊息是「temperature and top_p cannot both be specified for this model」。這個變化在開發者社群裡引發了一波不算小的踩雷潮——VSCode 的 GitHub Copilot 擴充功能、LiteLLM 代理層、n8n 自動化平台、LangChain.js 等多個第三方工具，都曾經因為預設同時傳送兩個參數而觸發這個錯誤，相關 issue 回報從 2025 年底一路延續到 2026 年都還在出現，可以說是這波 Claude 4 系列 API 變更裡，最容易在不知情狀況下踩到的一個坑。
如果你剛好在用某個串接 Claude API 的第三方工具，突然開始收到類似錯誤，第一件事不是懷疑帳號或網路，而是去檢查那個工具的設定裡，是不是同時把 temperature 跟 top_p 兩個欄位都填了值。
如果你有啟用 Claude 的 Extended Thinking（進階推理）功能，temperature 同樣無法自訂——啟用 thinking 時，temperature 必須維持在預設值，這是 API 端強制的限制，不是風格上的建議。背後的邏輯不難理解：推理過程需要模型能完整地在候選路徑之間探索、回溯、重新考慮，如果額外疊加一層人為控制的隨機性調整，反而會干擾這個內部推理機制原本該有的運作方式。
這裡有一個常被忽略的事實：如果你只是透過 claude.ai 網頁版或手機 App 使用 Claude，跟本文提到的所有內容其實沒有直接關係。網頁版介面並不開放 temperature 的調整選項，Anthropic 已經幫你調好了適合一般對話的預設值。這個參數只存在於透過 API 開發應用程式的情境裡——如果你看到教學文章宣稱「在 claude.ai 對話框裡調整 temperature」，那多半是誤解或過時的資訊，值得多留一個心眼查證來源。
如果你是自己或團隊在用 API 建構產品，理解 temperature 能幫你少走很多冤枉路。「Claude 給的答案怎麼每次都不太一樣」這類客訴，很多時候檢查一下 temperature 有沒有被設得太高，會比重寫整段 prompt 更快找到問題根源，省下的是實際除錯的工時。而如果你的專案曾經同時設定 temperature 跟 top_p，突然開始跳 400 錯誤，理解這個機制能讓你在幾分鐘內定位問題，而不是花好幾個小時去懷疑帳號權限或 API 金鑰是不是失效——這正是本文開頭提到的那個坑，也是目前最容易在升級模型版本時被忽略、卻直接影響服務可用性的細節之一。