你有沒有注意過，數學考試的時候，直接在腦裡算跟在紙上列算式，答對率差很多？

不是因為你的腦子變強了。是因為紙上多了一個地方讓你放「中間結果」。你可以回頭看第三步有沒有算錯，可以比較兩個路徑哪個比較短，可以在死胡同的時候從前面某一步重來。

Extended Thinking 就是 Claude 的那張草稿紙。

草稿紙長什麼樣

Claude Code 裡，extended thinking 預設是開著的。你下一個指令，Claude 不會立刻回覆——它先在一個你看不到的區域做推理，把問題拆解、列出可能的方向、排除不合理的選項，然後才組織出最終回覆。

這個「看不到的區域」就是 thinking tokens。它們不會出現在你的 terminal 裡（除非你主動打開），但它們確實在消耗 token 預算。

類比一下：你請了一個資深工程師幫你 debug。他拿到問題之後，低頭在筆記本上畫了五分鐘——你看不到他畫什麼，但五分鐘後他抬頭告訴你「問題在第 47 行，race condition，你的 mutex 少鎖了一個 map」。那五分鐘就是 extended thinking。

沒有 thinking 的版本？他聽完問題直接說「試試看把 timeout 調大」。可能對，可能不對，但你知道他沒有真的想過。

開關在哪裡

三種方式控制 extended thinking，看你的使用場景選一個。

即時切換

在 Claude Code 裡按 Option+T（macOS）或 Alt+T（Windows/Linux），thinking 就會開/關。terminal 底部會顯示目前的狀態。

適合什麼情境？你正在跟 Claude 來回快速問答——「這個 function 回傳什麼」「那個 env var 設在哪」——這種不需要深度推理的問題，關掉 thinking 回覆更快。遇到「幫我重構這個模組的錯誤處理邏輯」，再按一下打開。

永久設定

在 ~/.claude/settings.json 加上：

1
2
3
{
  "alwaysThinkingEnabled": true
}

預設就是 true。如果你大部分時間都在做簡單操作（讀檔、搜尋、格式轉換），可以考慮設成 false，需要的時候手動 Option+T 打開。

Token 預算上限

1
export MAX_THINKING_TOKENS=10000

或在 settings.json 裡面設。這限制了 Claude 每次回覆最多花多少 token 在 thinking 上。設太低會限制推理深度，設太高會燒錢又慢。

預設值對大部分場景夠用。只有在你發現 Claude 的 thinking 太長（verbose mode 裡看到它反覆自我質疑十幾輪），才需要手動壓預算。

等等，有個功能很多人不知道。

按 Ctrl+O 可以切換 verbose mode。打開之後，你會看到 Claude 在 thinking 階段到底想了什麼——推理過程、排除的選項、自我修正的地方。

這不只是好奇心。Verbose mode 是你校準 thinking 效果的工具。如果你看到 Claude 在 thinking 裡花了 3,000 token 做你覺得不需要的分析，那就該降 effort level。如果你看到它在關鍵步驟跳過了重要的邊界條件檢查，那就該升。

Effort Level：油門而不是開關

Thinking 不是只有開跟關。/effort 讓你控制 Claude 推理的深度——像油門，不是開關。

在 Claude Code 裡輸入 /effort 會出現一個 slider。目前有四個檔位：

Effort 適合場景 思考深度
low 讀檔、grep、格式化 幾乎不思考，直接回
medium 一般 coding、小 bug 適度推理
high 架構設計、複雜重構 深度推理
xhigh 最困難的問題、多方案評估 最深度，反覆驗證

xhigh 是 Opus 4.7 推出時新增的檔位，官方建議用在「大部分 coding 工作」。但這不代表你應該永遠開 xhigh——它真的很慢，token 消耗也是 medium 的好幾倍。

這裡有個反直覺的地方。大部分人以為「effort 越高 = 結果越好」。不完全對。

Effort 越高，Claude 越容易「overthink」——在不需要深度推理的問題上花大量 token 自我質疑，最後回覆反而繞了一大圈。叫它幫你 rename 一個變數，xhigh 可能會先分析命名慣例、考慮 backward compatibility、評估 IDE refactoring 工具的差異——然後才告訴你「把 x 改成 userId」。

medium 直接就回了。而且是對的。

Adaptive Reasoning

好消息是，新版模型支援 adaptive reasoning——就算你設了某個 effort level，模型會根據問題的實際複雜度動態調整。簡單問題自動跳過深度推理，複雜問題自動加碼。

你也可以在 CLAUDE.md 裡用自然語言引導：

1
2
3
# 推理偏好
- 架構相關的問題，請深度思考，考慮所有邊界條件
- 簡單的 CRUD 操作，快速回覆即可

Claude 會讀 CLAUDE.md 並據此調整行為。

實戰：什麼時候開、什麼時候關

踩了幾次坑之後整理出來的經驗法則。

一定要開 thinking 的場景

跨檔案 bug 追蹤。 錯誤訊息在 A 檔案，根因在 B 檔案，B 又被 C 呼叫。沒有 thinking 的 Claude 會盯著 A 猜，有 thinking 的會先畫出呼叫鏈再定位。

架構決策。 「這個功能應該放在 service layer 還是 domain layer？」「用 event-driven 還是直接 call？」——這種問題沒有標準答案，需要權衡利弊。Thinking 讓 Claude 在回覆前把 pros/cons 列出來比較。

多步驟實作規劃。 「幫我把這個 monolith 的 auth 模組拆出來。」不是一步能做完的事。Thinking 讓 Claude 先規劃步驟順序、識別依賴關係、標記風險點，再開始動手。

Trade-off 評估。 「PostgreSQL 還是 DynamoDB？」「monorepo 還是 multirepo？」沒有 thinking 的回覆通常是各列優缺點。有 thinking 的回覆會考慮你的具體場景——團隊大小、預算、技術債狀態——然後給出有立場的建議。

可以關 thinking 的場景

簡單搜尋。 「package.json 裡的 express 版本是多少？」不需要推理。

格式轉換。 「把這個 JSON 轉成 YAML。」機械性操作。

已知操作。 「幫我建一個 React component 的 boilerplate。」模板化任務。

高頻輪詢。 /loop 裡每 30 秒跑一次的檢查指令。Thinking 會讓每次輪詢多花好幾秒。

講個冷知識。

Claude 的 thinking tokens 跟 output tokens 是從同一個 context window 扣的。如果你的 context 已經很滿（接近 200K tokens），Claude 分配給 thinking 的空間會被壓縮，推理品質可能下降。

這就是為什麼 /compact 指令很重要。定期壓縮對話歷史，不只是省 token——是保護 thinking 的推理空間。

如果你的任務同時需要大量 context（讀很多檔案）和深度推理（複雜架構設計），考慮分兩步：先用一個 session 讀檔收集資訊，/compact 壓縮後，再開新 session 做設計。

跟其他工具的 Reasoning Mode 比較

GPT-5.5 有自己的推理模式（之前 o1/o3 系列的延續）。Kiro 走的是 spec-centric 路線——先寫規格再寫 code，規格本身就是一種「強迫思考」。

核心差異在控制粒度。

GPT 的 reasoning 比較像「全開或全關」——你選了 reasoning model 就得等它想完，沒辦法中途說「這題不用想那麼深」。

Claude 的 effort level 讓你在同一個 session 裡動態調整。問完一個架構問題（xhigh），下一句問「這個 import 路徑對嗎？」（low），不用切模型、不用開新 session。

Kiro 把思考結構化成 spec 文件，好處是 thinking 的產出是永久的——下一個 session 還能讀。Claude 的 thinking tokens 是一次性的，session 結束就消失了。如果你需要保留推理過程，可以在 verbose mode 裡手動擷取，或用 CLAUDE.md 寫下決策結論。

三種方式沒有哪個「最好」。Claude 的強項在於彈性——你可以在同一個 terminal 裡從「快速問答」無縫切換到「深度推理」，不用換工具。

建議的預設配置

新手可以直接用這組設定，之後根據自己的工作模式調：

1
2
3
4
// ~/.claude/settings.json
{
  "alwaysThinkingEnabled": true
}

然後在 CLAUDE.md 加上：

1
2
3
4
5
# Thinking 偏好
- 預設 effort: high
- 架構設計、安全審查、效能分析：xhigh
- 簡單的檔案操作、grep、格式轉換：low
- 不確定的時候寧可多想一下

日常使用時，Option+T 切開關，/effort 調深度，Ctrl+O 偶爾打開看看 Claude 到底在想什麼。三個快捷鍵，就是你控制 thinking 的全部了。

從 Thinking 可以延伸到哪裡

學會控制 extended thinking 之後，兩條路可以接著走。

往 API 開發走——如果你在寫自己的 AI 應用，Anthropic SDK 的 extended thinking API 讓你在程式碼裡控制思考預算、讀取 thinking 內容、根據 thinking 結果做分支處理。這是從「使用者」到「開發者」的跨越。

往 Prompt 工程走——extended thinking 的效果高度依賴 prompt 品質。一個好的 system prompt 可以引導 Claude 在 thinking 階段聚焦正確的面向。Anthropic Academy 的 Advanced Prompt Engineering 課程專門教這個。

背後就兩條線：你想要 Claude 想得更好，要嘛改變它思考的框架（prompt engineering），要嘛改變它思考的深度（effort level）。兩者搭配才是完整的控制。

Extended thinking 不是什麼神秘功能。它就是一張草稿紙。但任何做過數學考試的人都知道——有沒有草稿紙，答對率差很多。

參考來源：Building with extended thinking - Claude API Docs
參考來源：Extended thinking tips - Claude API Docs
參考來源：Common workflows - Claude Code Docs