思考的槓桿（The thinking lever）（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這段講怎麼調 Claude 的「思考」。一個是 adaptive thinking：讓 Claude 自己決定什麼時候要想。另一個是 effort：由你告訴它這件事要多用力。講者也教你怎麼挑 effort 等級、什麼時候用大模型或小模型。常用 Claude 的人看完，比較知道該怎麼設定，才不會多花錢或拿到比較差的答案。

• 12:01 簡單問題（如 2+2）不管叫你花少或多時間，實際花的時間差不多；複雜研究任務在 low effort 和 high effort 下的思考差異可能非常大
  ↳ 問 2+2 這種題目，不管叫它想多久，它都一下就答完，沒什麼差別。但如果是複雜的研究任務，low effort（低努力）和 high effort（高努力）想的深度可能差很多。
• 12:01 Adaptive thinking 不是 model router，也不是自動的 thinking 開關；它不會依難度分類你的查詢，再決定要用 thinking 還是 non-thinking 版本的模型
  ↳ Adaptive thinking 不是 model router。model router 是分流器：先判斷題目難不難，再把題目丟給「會思考版」或「不思考版」的模型。它也不是自動幫你按思考開關。
• 12:32 差別在於：不是規定「回應一開始至少要花一個 thinking token」，而是「需要時隨時、以任何方式使用 thinking tokens」；Claude 在每一步都可以選擇要不要思考
  ↳ token 是模型處理文字的小單位，thinking token 就是它在心裡想事情花掉的 token。重點不是規定它開頭要先想一下，而是做到哪一步需要就想，不需要就直接做。
• 13:03 從 Opus 4.6 起，所有 benchmark 都用 adaptive thinking 跑；這是最大化智慧的設定，效能持平或更好，使用者體驗也更好
  ↳ 從 Opus 4.6（Claude 的大型模型）開始，官方跑 benchmark（標準化的評測考題）全部用 adaptive thinking。因為這樣分數一樣或更好，用起來也更順。
• 13:03 過去使用者常把 thinking 開關當成 effort 旋鈕，想讓 Claude 多花時間就在 Claude.ai 或 Claude Code 打開 thinking，這個直覺很合理
  ↳ 以前想讓 Claude 多用點心，大家會去 Claude.ai（網頁和 App 版）或 Claude Code（寫程式用的工具）打開 thinking 開關，把它當成「努力程度」來調。這樣想很自然。
• 13:34 但 thinking 開關只是 effort 旋鈕的拙劣替代品：它開關的是模型的核心能力，限制的是 Claude「怎麼工作」，不是「多努力工作」
  ↳ 問題是這個開關管的是「能不能思考」這個能力本身。關掉它等於限制了 Claude 的做事方法，並不是叫它多用心或少用心，所以拿來調努力程度不準。
• 14:07 Effort 旋鈕更能表達「多花 token 換更好答案」：它會一起調整 thinking、tool use 與輸出文字，而不是只切換其中一項
  ↳ Effort 才是真正的「多花點成本、換更好的答案」。調高的時候，它會一起多想、多用工具（例如搜尋、跑程式），答案也寫得更完整，不是只動其中一項。
• 14:07 類比 tool use：我們不叫 Claude 永遠搜尋或永遠不搜尋，而是讓它依問題判斷何時搜尋，這正是 Claude 能 agentic 的原因
  ↳ 我們不會規定 Claude 每題都要上網搜，或都不准搜，而是讓它看情況決定。這種自己判斷下一步的能力，就是 agentic（能自己完成多步驟任務）的基礎。
• 14:37 類比同事：我們不會叫同事開關內心獨白，而是告訴他們要多努力，再由他們決定要想多深、採取哪些行動
  ↳ 你交代同事工作，不會說「你現在不准在腦中想事情」，而是說「這案子很重要，多花點心」。至於要想多深、要做哪些事，交給對方自己判斷。
• 15:07 盡可能跑 evals 畫出 effort 曲線：x 軸放總 token、時間或成本，y 軸放效能，藉此判斷選某個 effort 等級的取捨
  ↳ 可以的話就跑 evals（用一批你自己的測試題來評分）並畫成曲線：橫軸放花掉的 token、時間或錢，縱軸放表現。這樣就能看出每個 effort 等級划不划算。
• 15:07 較高 effort 在多數受智慧限制的任務上能提升效能，但可能出現報酬遞減
  ↳ 需要動腦的任務，effort 調高通常表現會變好。但會有報酬遞減：越往上加，多花的成本換到的進步越來越少。
• 15:39 看曲線後，你可以選擇不計 token 追求最佳智慧；也可以判斷 extra high 到 max 的效能提升不值得多花的 token，因此選 extra high
  ↳ 看完曲線可以二選一：不在乎花費就直接開最高；或者你發現從 extra high（特高）升到 max（最高）只好一點點、卻貴很多，那就停在 extra high。
• 15:39 Low effort 能更快完成任務、省下很多 token，但會限制 Claude 完成任務的周延程度
  ↳ Low effort 做得快，也省很多 token。代價是 Claude 做得沒那麼周全，可能漏掉細節或少做檢查。
• 16:11 小提醒：low effort 時 Claude 會盡量省 token，有時會走出意料之外的捷徑；除了看 evals，最佳做法是花時間讀 transcripts
  ↳ 要注意 low effort 時它會拚命省，偶爾會走出你想不到的捷徑。所以除了看分數，最好也讀 transcripts（完整的對話和操作紀錄），看它實際怎麼做。
• 16:41 例子 Claude Plays Pokémon：Claude 玩原版 Pokémon Red；用 low effort 時，它把遊戲當成 speedrun 來玩
  ↳ 舉例：讓 Claude 玩經典遊戲《寶可夢 紅》，設成 low effort 時，它把遊戲當 speedrun（用最短時間破關的玩法）來玩。
• 16:41 Low effort 下的策略：跳過訓練家對戰、用囤積的回復道具而不回 Pokémon 回復中心、狂用 repel 減少遭遇戰，更快通過洞窟
  ↳ 它的做法是：能避開的訓練家對戰就避開；受傷了就用身上囤的藥，不回寶可夢中心；一直噴 repel（除蟲噴霧，可以減少遇到野生寶可夢），快速穿過洞窟。
• 17:12 我們常把 low effort 和較低智慧畫上等號，但這其實是很聰明的策略；要想出怎麼少花 token 又最快過關，本身就需要一定智慧
  ↳ 大家常以為 low effort 就等於變笨。其實這些都是聰明的策略，因為要想出怎麼少花力氣又最快過關，本身就需要判斷力。
• 17:42 Evals 永遠是最理想的做法；講者接著提供沒有 evals（或有 evals 也適用）時選 effort 的經驗法則
  ↳ 最理想的做法永遠是自己跑 evals。講者也給了幾條經驗法則：沒有 evals 的時候可以直接照著選，有 evals 的時候也能拿來當測試的起點。
• 18:12 Max effort：能在最難的任務上帶來提升，但可能報酬遞減；建議用在最吃智慧的情境測試，不要預設它是效能上限或最划算的選擇
  ↳ Max effort 對最難的題目有幫助，但加成可能越來越小。建議只在最需要腦力的情境拿來測，不要以為它一定最強或最划算。
• 18:12 降一級可能以一小部分成本得到大致相當的效能
  ↳ 往下降一級，常常只要花少很多的錢，就能拿到差不多的表現。
• 18:45 Extra high effort 是 Claude Opus 4.7 推出的新設定，對多數 coding 與 agentic 情境最好；目前是 Claude Code 和 Claude.ai 中 Opus 4.7 的預設值
  ↳ Extra high 是 Opus 4.7 才有的新等級，大多數寫程式、或讓 Claude 自己跑多步驟任務的情境最適合用它。現在 Claude Code 和 Claude.ai 裡的 Opus 4.7 預設就是它。
• 18:45 High effort：兼顧 token 用量與智慧，推薦用在任何對智慧敏感的情境；可以從 High 開始測，再往上調
  ↳ High 在花費和聰明度之間取得平衡，只要在意品質都推薦用。不確定選哪個時，先從 High 開始測，不夠再往上調。
• 19:16 Medium：適合成本敏感情境，願意犧牲一點智慧換取快很多的結果
  ↳ Medium 適合在意成本的時候用：願意少一點聰明度，換來快很多的結果。
• 19:16 Low：留給範圍小的任務和對延遲敏感的工作負載；但實際跑跑看最準，結果可能出乎意料
  ↳ Low 留給範圍小的簡單任務，或很要求回應速度的用途。不過最準的還是實際跑跑看，結果可能跟你想的不一樣。
• 19:16 Test time compute 是相對於 training time compute 的第二種擴展智慧的方式，兩者在效能、速度、成本上的取捨類似
  ↳ 讓 AI 變聰明有兩條路：training time compute 是訓練時投入更多運算，把模型練得更強；test time compute 是回答時讓它多想。兩條路都要在效能、速度、成本之間取捨。
• 19:47 大模型用 low effort：適合吃智慧、又想優化速度的情境
  ↳ 大模型配 low effort，適合題目需要聰明、但又希望快點拿到結果的情況。
• 20:17 交通號誌模擬例子：Opus 4.7 用 low effort 的輸出 token 跟 Haiku 4.5 用 max effort 差不多，只稍微慢一點，但結果好很多
  ↳ 例子：做交通號誌模擬時，Opus 4.7 開 low effort，產出的字量跟小模型 Haiku 4.5 開到 max 差不多，只慢一點點，成果卻好很多。
• 20:47 小模型適合優化成本、不太吃智慧的情境，尤其是大量處理的簡單 LLM 任務，例如分類、資訊擷取、基本摘要
  ↳ 小模型適合想省錢、不太需要深入思考的工作，特別是大量重複的簡單任務，例如把信件分類、從文件裡抓資料、做基本摘要。
• 20:47 應用需要很低的 time to first token 時，小模型也很有用，通常更快開始產出 token
  ↳ 如果你很在意 time to first token（送出問題後，到第一個字開始出現的等待時間），小模型也很好用，通常比較快開始回。
• 21:17 原則：追求快速 time to first token 用小模型；追求快速 time to last token 用大模型配較低 effort；可以的話兩者都評估，畫出不同模型與 effort 的 eval 曲線
  ↳ 想讓它「快點開始回」就用小模型；想讓它「快點全部做完」（time to last token，最後一個字出來的時間）就用大模型配較低 effort。可以的話兩種都測、畫曲線比較。
• 21:48 重點一：盡可能開啟 thinking，給 Claude 推理空間；想調整思考時間，就用 effort 等級或 budgets
  ↳ 重點一：能開思考就開，讓 Claude 有空間推理。想調整它想多久，就用 effort 等級或 budgets（設定思考可以花多少 token 的預算），不要直接關掉思考。
• 22:18 重點二：有 evals 就用；畫曲線，測不同 effort、不同 budgets、不同模型，同時別忘了讀 transcripts
  ↳ 重點二：有 evals 就用，畫曲線比較不同的 effort、預算和模型。同時別忘了讀 transcripts，看它實際怎麼做的。
• 22:48 重點三：什麼都不做、只想直接選的話，coding 和軟體工程相關工作建議選 extra high
  ↳ 重點三：不想測、只想直接挑一個的話，寫程式和軟體開發相關的工作就選 extra high。
• 22:48 North Star：Claude 在被要求時能妥善分配算力；你設定品質標準與預算，Claude 自己搞定其餘部分
  ↳ North Star（指引方向的長期目標）是：你只要定好品質標準和預算，Claude 自己決定要花多少運算、怎麼分配，其他都交給它。
• 23:18 Adaptive thinking、effort 等級與 budgets 都是朝這個方向邁進的一步，但只是開始，之後還會有更多
  ↳ Adaptive thinking、effort 等級和 budgets 都是往這個方向走的一步。講者說這只是開始，之後還會有更多。

根據講者說法，Claude Code 和 Claude.ai 中 Opus 4.7 目前的預設 effort 等級是哪一個？