會思考的模型：
CoT 與 Reasoning Model
同一題、同一顆模型、同樣 temperature=0——只差一句話的問法， 答案一個錯一個對。這是真實紀錄（qwen3.5-2b，2026-08 實測；你跑同一題結果可能不同）， 自己按按看：
右邊的實驗場是真的 Python（在你的瀏覽器裡跑，不用安裝任何東西）。 首次載入約需 30–60 秒，正好夠你讀完第 1 節。每一格程式碼都能改、能重跑， 改壞了重新整理就復原——這是你的沙盒，盡量玩。
CoT：讓模型把步驟寫出來
為什麼有效？回想第 1 課：模型是自迴歸的， 一次吐一個 token、吐出去就不能回頭改。問法 A 逼它「一口氣直接吐答案」， 等於要它憑直覺搶答——它抓了 110÷2 的直覺就輸出 55。 問法 B 讓它把中間步驟寫出來，寫下的每一步都成為後面步驟的輸入 （前文越完整、下一個 token 越有依據）——紙上談兵的「紙」本身就是工作記憶。
你在 hero 看到的就是這兩種問法的完整原文，程式上只差一行：
這招 2022 年被命名為 Chain-of-Thought prompting，現在已經是基本功—— 連「把答案抽出來」都有慣用款式（要求固定格式的最後一行，方便程式解析）。
Reasoning Model：把「先想再答」內建進模型
你不用再手寫「請一步一步想」，模型自己會想，而且想多深是訓練出來的—— 用強化學習獎勵「想了之後答對」（第 2 課的 GRPO 正是 DeepSeek-R1 用的配方；訓練中模型自發長出檢查、回溯的行為， 論文稱之為「aha moment」）。API 的介面也跟著變：思考和答案是兩個欄位。
Claude 的 extended thinking（真實 API，2026-08 規格）：
DeepSeek-R1 這一系開源模型走同樣的介面慣例（思考在 reasoning_content）：
工程備忘：reasoning model 的 max_tokens 要給足（思考也算 token）—— 給太小，思考還沒想完就被截斷，有的服務會回空答案。
Test-time Compute：拿算力換正確率
「想更久」是一條路，「多抽幾次、投票表決」是另一條。實測： 問 qwen3.5-2b「47 × 38 = ?」只准直接答，temperature=1 抽 9 次—— 單次答對率只有 6/9，但 9 個答案投票，正解 1786 以 6 票勝出 （錯誤答案 1451、1466、1446 各自只有 1 票：對的答案只有一種， 錯的各錯各的）。到右邊看真實開票結果，再用二項分布算清楚 「該投幾票」。
反面是 overthinking：簡單題也長篇思考，多付延遲與 token 費用、 正確率卻沒得漲，深度思考甚至可能把原本對的直覺推翻。所以現代 API 把 「想多深」做成可調參數（Claude 的 adaptive thinking 讓模型自己判斷、 OpenAI o 系列的 reasoning effort 檔位）——難題才值得深思， 簡單題直答就好，這個判斷本身成了工程決策。
ToT／GoT：從一條鏈到一棵樹（進階閱讀）
知道有這回事就好：ToT 適合「走錯要能回頭」的搜尋型問題（解謎、規劃）， GoT 再加上「把幾條思路的成果合併」。代價都是多很多次模型呼叫—— 它們是 test-time compute 的重型版本，日常任務用不到； 你在 3️⃣ 玩的多數決（self-consistency）就是這家族裡最便宜實用的一招。
本課名詞速查卡
發講義用的濃縮版——一個名詞一句話：
| Chain-of-Thought | 要求模型先寫步驟再答——一句提示詞，數學正確率大增（實測：直接答 55 錯、CoT 答 5 對）。 |
| Reasoning Model | 把「先想再答」內建的模型（o 系列、R1、Claude extended thinking）；思考與答案分欄回傳。 |
| Test-time Compute | 回答當下多花算力（想久、多抽投票）換正確率；效益遞減，且單次答對率須過半投票才有用。 |
| Overthinking | 簡單題想太多——多付延遲與費用、正確率不漲反跌的反效果；「想多深」因此成為可調參數。 |
| ToT / GoT | CoT 的樹狀／圖狀進階：分支、回溯、合併、投票——重型 test-time compute，特定搜尋型問題才划算。 |
換你動手
在右邊 2️⃣ 把單次答對率 p 拉到 0.45（低於一半），看多數決曲線發生什麼事。投越多票越準的前提是什麼？
用 1️⃣ 的實測答對率（6/9）算：投 3、9、21、41 次的多數決答對率各是多少？從哪裡開始「加倍算力買不到幾個百分點」？（實驗區已備好起點程式。）
二項分布模型假設「每次抽樣獨立」。看 1️⃣ 的三個錯誤答案（1451、1466、1446），找出它們共同的規律——這個規律說明真實模型的錯誤哪裡不獨立？什麼情況下投票會整組翻車、反而該用 CoT？
卡住了？三題在 notebook 最後一格都有折疊解答——先自己做，再打開對照。
情境測驗
離開前試試看：下面的情境都真的會遇到。每題選一個你認為的最佳做法，選了馬上看得到解釋。
Q1 情境題
你的產品有兩條 LLM 功能線：(1) 客服 FAQ 快答（一天十萬次、使用者等在線上）、(2) 每晚跑一次的財務對帳異常分析（複雜、錯了很貴）。reasoning model 該用在哪？
套本課的判斷式：難題才值得深思。對帳分析是多步推理、離線執行（延遲無感）、錯誤成本高——多花的思考 token 都買在刀口上。FAQ 是簡單題＋大流量＋使用者在線等：reasoning model 的思考時間直接變成使用者的等待，token 費用乘十萬倍，正確率卻沒得漲——教科書級的 overthinking 場景。A 忽略成本與延遲是真實約束；C 因噎廢食，o 系列與 R1 已在生產環境大量使用；D 剛好把兩邊都放錯位置。
Q2 情境題
你的報表工具用 LLM 把自然語言轉成 SQL，複雜查詢常轉錯。老闆說「換最貴的模型」。在那之前，最便宜、最該先試的一步是？
成本階梯由低到高：改提示詞 → 多抽投票 → 換模型 → 微調。CoT 站在階梯最底層：一行話的成本，對「多步推理型」錯誤（join 邏輯、條件遺漏）常有立竿見影的改善——本課 hero 就是活例子。B 混淆了穩定與正確：temperature=0 只是每次錯得一樣（hero 實測就是 temp=0 照樣答 55）。D 可行但比 C 貴 20 倍，而且 SQL 字串比對「同一答案」不容易，該在 C 之後才考慮。A 是最後手段：貴、慢，且 CoT 沒試過之前你根本不知道需不需要。
Q3 錯誤診斷
同事的自動閱卷程式用下面的問法呼叫模型（temperature=0），球棒與球那題模型回了「55」。他說「temperature 已經是 0 了，輸出最穩定的答案還是錯，這模型數學不行，只能換模型」。他的診斷哪裡有問題？
這正是本課 hero 的實測：同一顆 qwen3.5-2b、同樣 temperature=0，禁止解釋→ 55（錯）、要求逐步推理→ 5（對）。「只給數字」不是無害的格式要求，它剝奪了自迴歸模型唯一的工作記憶——寫在紙上的中間步驟。B 說反了：temp=0 與對錯無關，調高只是讓錯法多樣化（想穩定又想推理，就 CoT＋temp=0）；D 無中生有，題目數學上沒有歧義；A 下結論太早——換模型可能也有幫助，但一行提示詞就能修好的問題，先用一行提示詞修。診斷順序：先檢查「問法是否允許模型推理」，再懷疑模型能力。