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

🧑‍🏫 這支影片講的是 Claude 在回答你的當下，怎麼花力氣想和做，才能解決困難問題。講者用同一個指令做對照：讓 Claude 多花時間，成果就明顯變好。影片也說明你可以用 effort 和 budget 決定它要多認真、最多能花多少。常用 AI 的人看完，比較知道什麼時候該讓它慢慢想、什麼時候要它快點交差。

• 00:12 講者 Matt Bleifer 是 Anthropic 研究團隊的產品經理，這場談 Claude 怎麼在推論時運用算力（test time compute）解決困難的軟體工程問題
  ↳ 講者 Matt Bleifer 是 Anthropic 研究團隊的產品經理。他談 test time compute，也就是模型在回答當下實際解題花掉的運算量，以及 Claude 怎麼靠它解難寫的程式問題。
• 00:42 講者也會介紹使用者有哪些槓桿可以影響 Claude 怎麼花 token，並分享最佳實務
  ↳ 他也會講你有哪些開關能影響 Claude 花多少 token。token 是 AI 計算文字量的單位，也是計費的單位。另外會分享怎麼設定比較好。
• 00:42 近兩年 LLM 的關鍵發展之一是擴展 test time compute，因此出現了 reasoning models
  ↳ 近兩年的大突破之一，是讓模型在回答時多花力氣想。這樣做出來的就是 reasoning models（推理模型），也就是會先在內部推理一番才作答的模型。
• 00:42 訓練階段可以靠更大的模型、更長的訓練時間、更多資料來擴展算力；測試階段則可以讓模型花更多時間處理問題
  ↳ 讓 AI 變強有兩條路。一是訓練時下重本：模型做大、練更久、餵更多資料。二是真正使用時，讓它在眼前這一題上多花點時間。
• 01:12 左圖：從 Haiku、Sonnet 到 Opus，模型越聰明，agentic coding 評測分數越高
  ↳ Haiku、Sonnet、Opus 是 Claude 由小到大的三種模型。agentic coding 評測是看 AI 能不能自己動手完成寫程式的任務。圖上模型越強，分數越高。
• 01:12 右圖：同一個 Opus 花越多時間處理問題，分數也跟著越高，這就是「擴展 test time compute」的意思
  ↳ 右圖的重點是：不換模型，同一個 Opus 只要多花時間處理，分數就往上爬。「多給時間就做得更好」，就是擴展 test time compute 的意思。
• 01:42 這個現象不只出現在軟體工程，agentic search、computer use、博士級學術推理等知識工作領域也一樣
  ↳ 不只寫程式這樣。agentic search 是 AI 自己多輪上網查資料，computer use 是 AI 自己操作電腦畫面，再加上博士級學術題，都是花越多時間做得越好。
• 02:12 實例：用 Opus 4.7 在不同 effort 等級下跑同一個 prompt：模擬車輛在單行道上通過紅綠燈
  ↳ 講者做了實驗：把同一個指令交給 Opus 4.7，只調整 effort，也就是要它花多少力氣，請它寫出車子在單行道上通過紅綠燈的模擬程式。
• 02:42 low effort：約 50 秒、約 4,600 個 output tokens；車會在紅綠燈前停下，但模擬陽春、畫面有限
  ↳ low effort 花了約 50 秒，寫出約 4,600 個 output tokens，也就是模型產出的字量，可以拿來看它做了多少工作。車會停紅燈，但畫面很陽春。
• 03:13 low effort 的版本把紅綠燈放在馬路正中間，講者認為設計不佳，但功能上仍算過關
  ↳ 低 effort 版把紅綠燈放在馬路正中央，真實路口不會這樣設計。不過「紅燈要停」這個要求有做到，算是及格但粗糙。
• 03:44 high effort：時間和 output tokens 大約都是兩倍，結果更好：車種不同，紅綠燈也移到路邊
  ↳ 調到 high effort，時間和產出的字量大約都翻倍，成果明顯變好：出現不同車種，紅綠燈也移到路邊，看起來更像真的路口。
• 03:44 high effort 版本裡，Opus 說它實作了「intelligent driver model」，讓每台車依周圍車輛的動態做出反應，交通模式更逼真
  ↳ 高 effort 版的 Opus 說它實作了 intelligent driver model，一種模擬駕駛行為的模型。每台車會看周圍車況調整速度，車流因此更像真的。
• 04:14 max effort：時間和 token 都是 low effort 的 10 倍，畫面最好、紅綠燈最好看、駕駛模式最逼真
  ↳ max effort 花的時間和字量都是 low 的 10 倍，換來最好的畫面、最好看的紅綠燈，以及最逼真的駕駛行為。
• 04:45 結論：就算是同一個模型，讓 Claude 花更多時間處理問題，結果就會更好
  ↳ 結論是：模型沒換，只是讓它多花工夫，品質就上去了。所以「讓它花多少力氣」本身就是影響結果的一個關鍵因素。
• 04:45 隨著 test time compute 持續擴展，Claude 處理一個問題的時間將不只是幾秒、幾分鐘或幾小時，而會是幾天、幾週、幾個月甚至幾年
  ↳ 講者預期這個趨勢會延續。以後 Claude 處理一件事可能不只幾秒或幾分鐘，而是連續做好幾天、幾週，甚至更久。
• 05:15 test time compute 指 Claude 在推論時為了解決問題而花費的任何 token，可以分成三類
  ↳ 講者的定義很寬：Claude 為了解題花掉的任何 token 都算 test time compute。依用途可以分成三類，下面逐一說明。
• 05:52 第一類是 thinking tokens：Claude 的內心獨白，用來逐步推理、比較選項、做 chain of thought 和當 scratch pad
  ↳ 第一類是 thinking tokens，就是 Claude 在心裡打草稿。chain of thought 指一步步推理，scratch pad 像計算紙，用來比較選項、把問題想清楚。
• 06:25 第二類是 tool calling tokens：Claude 和外界互動的方式，例如執行搜尋、讀寫檔案來建構軟體專案
  ↳ 第二類是 tool calling tokens，也就是 Claude 動手做事花的量，例如上網搜尋、打開或修改檔案，一步步把軟體做出來。
• 06:25 Claude 能呼叫的工具多達數百萬種，但不管哪一種，tool calling tokens 都是它和環境互動的方式
  ↳ Claude 能用的工具可以多到數百萬種，但不管用哪種，性質都一樣：這是 Claude 碰觸外部世界、取得資訊或改變東西的管道。
• 06:55 第三類是 text tokens：Claude 和使用者溝通的方式，例如回報進度、最後總結做了什麼，或回答簡單問題
  ↳ 第三類是 text tokens，也就是 Claude 跟你說話用的量，像是回報做到哪裡、最後做總結，或直接回答一個簡單問題。
• 07:26 這三類 token 都是 Claude 運作的基礎，但都會直接讓使用者付出代價：token 費用，以及更長的等待時間
  ↳ 這三類都少不了，但每一類都有代價：token 花越多，費用越高，你也要等越久。多想不是免費的。
• 07:56 因此使用者應該能影響或限制 Claude 怎麼花 token；第一種方式是 effort 旋鈕
  ↳ 所以使用者應該能控制 Claude 怎麼花 token。第一個方法是 effort 旋鈕，像調檔位一樣，決定它要多認真做。
• 07:56 effort 讓使用者告訴 Claude 要怎麼在時間、成本和品質之間取捨：多花時間換更好的答案，或少花時間換更快的答案
  ↳ effort 等於在問你：這件事比較在意快、便宜，還是品質好？要品質就調高、多等一下；要速度就調低。
• 08:28 第二種方式是 budget。最近推出的 task budgets 功能，可以設定 Claude 做一個任務最多能花多少 token
  ↳ 第二個方法是 budget（預算）。新推出的 task budgets 功能，可以替單一任務設上限，規定這件事最多只能花多少 token。
• 08:58 例：請 Claude 做一個功能，但花超過 100,000 tokens 前要先停下來跟使用者確認
  ↳ 例如請 Claude 做一個功能，但規定花超過 10 萬 token 之前要先停下來問你，免得它悶著頭一直做、一直花錢。
• 08:58 budget 除了用 token 計，也可以用時間或成本；Claude 一次工作好幾天甚至更久時，這會越來越重要
  ↳ 預算不只能用 token 算，也能設時間或金額上限。當 Claude 一做就是好幾天，事先講好上限會越來越重要。
• 09:29 在這些偏好和限制下，由 Claude 自己決定怎麼在 thinking、tool calling、text 之間分配 token，讓成果和使用體驗最好
  ↳ 你只要給方向和上限，什麼時候該想、該動手、該回報，就交給 Claude 自己分配，目標是成果好、你用起來也順。
• 09:59 最早的 reasoning models 有固定順序：先 thinking，再 tool calling，最後輸出 text
  ↳ 早期的推理模型流程很死板：先一口氣想完，再去用工具，最後才開口。中途發現新狀況，也沒機會停下來重想。
• 09:59 interleaved thinking 做了改進：Claude 可以在工具呼叫之間思考，呼叫工具→看結果→思考→決定下一步，直到給出最終答案
  ↳ interleaved thinking（交錯思考）改善了這點：用工具、看結果、想一想、決定下一步，這樣反覆進行，像人邊做邊調整。
• 10:29 最近推出的 adaptive thinking 是 interleaved thinking 的下一步演進
  ↳ 最近推出的 adaptive thinking（自適應思考），是交錯思考的下一步升級版。
• 10:59 adaptive thinking 下，Claude 何時思考、想多少、token 用什麼順序花都沒有限制，可以依任務需要自由組合 thinking、工具和 text
  ↳ 在 adaptive thinking 下，什麼時候想、想多久、先做哪件事都沒有固定規則，Claude 依任務需要自由搭配思考、用工具和說話。
• 10:59 例：先用 text 回應確認需求 → 呼叫工具 → 思考結果 → 回報進度 → 繼續呼叫工具，直到給出最終答案
  ↳ 例如它先跟你確認需求，再去用工具查資料，想一想結果，回報進度，再繼續動手，一路做到給出最後答案。
• 11:29 遇到不需要思考的簡單問題，Claude 也可以選擇完全不思考
  ↳ 遇到很簡單、不需要思考的問題，Claude 也可以直接回答、完全不思考，省時間也省錢。
• 11:29 實務上 effort 越高，Claude 通常越常思考、想得越久，但實際情況還是要看 prompt 而定
  ↳ 一般來說，effort 調越高，Claude 越常思考、想得越久。但這不是絕對的，實際情況還是要看你的指令內容。

在紅綠燈模擬的例子中，Opus 4.7 用 max effort 時，花的時間和 token 大約是 low effort 的幾倍？