05 · AI 怎麼決定想多深

上篇講的是怎麼把資訊交給 Claude：目標、上下文、邊界、驗收。翔宇後來發現，資訊給對了還不夠——同一批資訊，簡單任務應該快速處理，複雜任務應該深度推理。Claude Code 現在把這件事做成了一個可以調的旋鈕：effort（思考深度）。——翔宇

1. 同一個 Claude，兩個完全不同的反應

你讓 Claude Code 改一個變數名：

幾乎秒回。

然後你換一個任務：

這次 Claude 明顯停了一會兒。它先讀路由、service、資料庫訪問層，再把快取穿透、擊穿、雪崩、過期策略、回源保護、灰度上線都想了一遍。

同一個工具，同一個人，同一臺電腦。為什麼一個任務像按電梯按鈕，一個任務像開技術評審會？

答案不是“Claude 突然變聰明”。答案是：任務需要的思考深度不同。

這一篇就用這兩個例子貫穿下去：變數改名和快取架構。

2. 先把“聰明”和“想多深”分開

很多人把兩個概念混在一起：

• 模型能力：Claude 本身會不會寫程式碼、能不能理解複雜系統
• 思考深度：Claude 在這一次回答前，要花多少 token 做推理

這兩個不是一回事。

同一個廚師，切蔥花和設計一桌宴席的動作不同。切蔥花不需要翻菜譜、算上菜順序、考慮賓客忌口；設計宴席才需要。你不會因為廚師切蔥花很快，就說他不會做複雜菜；也不會因為他設計宴席想了十分鐘，就說他反應慢。

Claude Code 裡的 effort 就是這個差別的控制器。

flowchart LR
    Task["🧾 任務輸入<br/>變數改名 / 快取架構"]
    Complexity{"複雜度判斷<br/>有多少合理路徑？"}
    Shallow["⚡ 低 effort<br/>少推理，快輸出"]
    Deep["🧠 高 effort<br/>多推理，再輸出"]
    Output["📦 最終回答 / 程式碼改動"]

    Task --> Complexity
    Complexity -->|路徑少，答案確定| Shallow
    Complexity -->|路徑多，需要權衡| Deep
    Shallow --> Output
    Deep --> Output

    style Task fill:#dbeafe,stroke:#3b82f6
    style Complexity fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style Shallow fill:#dcfce7,stroke:#22c55e
    style Deep fill:#f3e8ff,stroke:#a855f7

變數改名幾乎只有一條正確路徑：找引用、改名、跑測試。

快取架構有很多合理路徑：本地快取還是 Redis？寫穿還是讀穿？失敗時降級還是阻斷？灰度怎麼上？監控看什麼？每條路都有代價。

所以判斷 effort 的第一問題不是“我想要最強模型嗎”，而是：

這個任務有幾條合理但不同的解決路徑？

路徑越多，越值得讓 Claude 多想。

3. adaptive thinking：不是每一步都硬想

Claude Code 現在使用的核心機制叫 adaptive reasoning / adaptive thinking（自適應推理）。

通俗講：不是你一開高 effort，它就每個字都慢慢想；而是模型會根據當前步驟判斷要不要展開推理。簡單步驟可以直接答，複雜步驟才多想。

官方模型配置文件把 effort 解釋為控制 adaptive reasoning 的引數：低 effort 更快、更省 token，適合直接任務；高 effort 給複雜問題更深的推理。完整說明見 Claude Code model configuration。

這和第 2 篇講的上下文視窗有關：思考也會消耗 token。它不是免費的空氣，而是一次會話裡的真實成本。

adaptive reasoning 怎麼"自適應"：底層是 Anthropic 給模型一個 thinking token budget（思考預算）——effort 越高 budget 越大，模型在生成回答前可以輸出更多 thinking token 做內部推理。低 effort 時 budget 小，模型傾向直接答；高 effort 時 budget 大，模型有空間展開"先想 3 個方案再選最好"這種多步推理。關鍵事實：thinking token 不會顯示給你看（除非開 verbose mode），但會計入賬單——這就是為什麼 max effort 的費用能比 low 高几倍。

把它放回變數改名和快取架構：

思考深度的本質是資源分配。把推理花在真正需要權衡的地方，而不是所有地方。

4. 五個檔位怎麼選

截至 2026 年 5 月，Claude Code 官方文件給的 effort 檔位是：

• Opus 4.7：low / medium / high / xhigh / max
• Opus 4.6 和 Sonnet 4.6：low / medium / high / max

Opus 4.7 預設是 xhigh，Opus 4.6 和 Sonnet 4.6 預設是 high。如果你設定了當前模型不支援的檔位，Claude Code 會降到它支援的最高相鄰檔，比如 xhigh 在 Opus 4.6 上會落到 high。這些細節來自 官方 model-config 文件。

用日常工作語言翻譯一下：

注意一個細節：同名 effort 在不同模型上不代表完全相同的底層預算。官方也提醒 effort scale 是按模型校準的。所以你不要機械比較“Sonnet high”和“Opus high”誰絕對等價，只要按任務反饋調。

還有一個新手容易混淆的點：effort 不是模型選擇。

/model opus 解決的是“用哪顆腦子”。 /effort high 解決的是“這顆腦子這次要不要多想”。 ultrathink 解決的是“這一輪臨時多想一下，不改變長期設定”。

把三者混在一起，就會出現兩種錯誤：

5. 為什麼不能永遠 max

很多人的第一反應是：那我全設成 max，不就最穩？

這正是第 5 篇最需要糾正的直覺。

第一，慢

變數改名用 max，就像你去樓下拿快遞卻先做城市交通規劃。不是不能做，是沒必要。

你要的是 6 處引用改完、測試透過；Claude 如果在旁邊分析“命名體系長期一致性”和“領域模型語義演進”，你只會嫌它煩。

第二，貴

thinking token 也是 token。官方文件明確說，即使思考內容被摺疊或被隱藏，生成的 thinking tokens 仍然會計費。完整說明在 Extended thinking。

如果你一天 100 次互動裡 80 次是小任務，全用 max，成本會被大量低價值推理吃掉。

第三，會想複雜

過度思考最隱蔽的壞處不是慢，而是把簡單事複雜化。

變數改名本來只要查引用。max 可能會順手提出“是否統一領域命名”“是否抽象使用者身份模型”“是否重構 auth 層”。這些討論不是沒價值，但它們不屬於這次任務。

新手最常見的兩類錯配：

1. 簡單任務全開 max："反正 Claude 多想想沒壞處"——結果變數改名要等 30 秒（max 在思考"是否要順便重構命名規範"），費用是 low 的 5-10 倍，最後還得跟它說"別想太多按我說的改就行"。修復方式：日常預設 medium，真遇到分叉點再升。
2. 複雜任務一直 low：以為"夠用就行"——結果架構決策被秒答，給出的方案沒考慮邊界場景，照著改完才發現漏了 3 個失敗模式。修復方式：架構 / 安全 / 遷移類任務先 xhigh 出方案，確認無遺漏再降回 medium 執行。

回到快取架構任務。這裡 max 才可能有價值，因為它確實有多個風險：

• 快取 miss 時會不會壓垮資料庫
• key 設計會不會造成髒讀
• 回源失敗時要降級還是報錯
• 上線後怎麼灰度和回復
• 怎麼證明方案沒有破壞現有 API

這種任務不怕它多想，怕它想漏。

但即便是快取架構，也不要一上來就讓它“直接給最終方案”。更穩的方式是把深想拆成兩輪：

第一轮：只做方案比较，不改代码。
第二轮：选定方案后，再让 Claude 写实施计划。

第一輪的目標是暴露分叉點，第二輪才是收斂執行路徑。這樣做有一個好處：你不會把 max 的輸出直接當成命令執行，而是把它當成一份技術評審材料。

6. 一個判斷框架：看“分叉點”

選擇 effort 不靠感覺，靠分叉點。

所謂分叉點，就是任務裡那些一旦選錯，後面都會受影響的決定。

變數改名幾乎沒有分叉點：

找引用 → 修改 → 跑测试 → 结束

快取架構有很多分叉點：

缓存放哪一层？
key 怎么设计？
miss 时谁回源？
失败时降级还是阻断？
怎么灰度？
怎么观测？
怎么回滚？

所以你可以用這個表判斷：

flowchart TD
    Start["📝 拿到一個任務"]
    Count{"有幾個關鍵分叉點？"}
    Easy["⚡ low<br/>快速執行"]
    Normal["🛠️ medium / high<br/>日常編碼"]
    Deep["🧠 high / xhigh<br/>深度設計或除錯"]
    Max["🚨 max<br/>關鍵決策前專項深想"]
    Boundary["✅ 寫清邊界和驗收<br/>再讓 Claude 動手"]

    Start --> Count
    Count -->|0-1 個| Easy
    Count -->|2-3 個| Normal
    Count -->|4-6 個| Deep
    Count -->|7+ 且代價大| Max
    Easy --> Boundary
    Normal --> Boundary
    Deep --> Boundary
    Max --> Boundary

    style Easy fill:#dcfce7,stroke:#22c55e
    style Normal fill:#dbeafe,stroke:#3b82f6
    style Deep fill:#f3e8ff,stroke:#a855f7
    style Max fill:#fee2e2,stroke:#ef4444
    style Boundary fill:#fef3c7,stroke:#f59e0b,stroke-width:2px

這個框架比“複雜就開高”更實用。因為有些任務看起來大，但路徑很直；有些任務看起來小，但分叉很多。

比如“給按鈕換顏色”很小，low。 “把登入狀態從 cookie 改成 session store”看起來也只是登入模組，但分叉很多，至少 high。

7. Claude Code 裡怎麼控制

Claude Code 給了幾種控制 effort 的入口。你不需要全背，記住常用的三層就夠。

第一層：全域性 / 預設

用 /effort 開啟互動滑塊，或者直接：

/effort high

想回到模型預設：

/effort auto

也可以在啟動時傳：

claude --effort high

或者用環境變數：

export CLAUDE_CODE_EFFORT_LEVEL=high

官方還支援在 settings 裡寫 effortLevel。這些入口完整列在 Set the effort level。

這些設定的優先順序也要知道：環境變數 CLAUDE_CODE_EFFORT_LEVEL 優先順序最高；然後是你配置的 effort；最後才是模型預設值。Skill 和 SubAgent 的 frontmatter effort 會在對應 Skill / SubAgent 執行時覆蓋會話級 effort，但不會覆蓋環境變數。

所以如果你發現“我明明在介面裡調了 effort，但它還是不對”，先檢查是不是 shell 裡設了：

echo "$CLAUDE_CODE_EFFORT_LEVEL"

如果這裡固定成了 low 或 max，它會比你臨時選擇更強。

第二層：當前會話的 thinking 顯示

在 Claude Code 互動介面裡，macOS 用 Option+T，Windows / Linux 用 Alt+T，可以切換當前會話的 extended thinking。Ctrl+O 可以切換 verbose mode，看摺疊的思考摘要。

這不是替代 /effort，而是控制 thinking 模式和顯示方式。你可以把它理解成：effort 決定“傾向於想多深”，會話切換決定“當前會話是否開啟這類思考輸出 / 顯示”。

第三層：單次深想

臨時只想讓某一輪多想，不想改全域性，直接在 prompt 里加：

ultrathink

官方文件特別說明：Claude Code 會識別 ultrathink 這個關鍵詞，並在上下文里加入深度推理指令；它不會改變 API 傳送的 effort 引數。其它詞，比如 think、think hard、think more，只是普通提示文本，不是同級別的特殊關鍵詞。

這裡有一個實操細節：ultrathink 適合放在方案型 prompt 的開頭，不要塞在一句模糊指令後面。

壞例子：

ultrathink 帮我优化一下缓存。

好例子：

ultrathink

目标：比较三种缓存穿透修复方案。
边界：先不要改代码，不改公开 API。
验收：输出推荐方案、风险、灰度步骤和回滚策略。

關鍵詞只能要求它多想，不能替你補齊任務資訊。缺資訊時，深想只會把“猜”變成“認真猜”。

8. 跟 Skills 和 SubAgents 的關係

第 6 篇會講 Skills，第 7 篇會講 SubAgents。這裡先埋一個很重要的點：effort 不只控制主會話。

Claude Code 支援在 Skill（技能） 和 SubAgent（子代理） 的 markdown frontmatter 裡設定 effort。也就是說，一個工作流檔案可以宣告自己需要更深或更淺的思考。

這很合理。

一個“格式化 changelog”的 Skill，預設 low 就夠。 一個“安全審計”的 SubAgent，預設 xhigh 或 max 才合理。

這就是工程化的意義：不是你每次憑感覺調，而是把任務型別和思考深度繫結到可複用檔案裡。

flowchart TB
    User["👤 你發任務"]
    Main["🤖 主會話<br/>預設 effort"]
    Skill["🛠️ Skill<br/>可在 frontmatter 設 effort"]
    Agent["👥 SubAgent<br/>可在 frontmatter 設 effort"]
    Result["📦 彙總結果"]

    User --> Main
    Main -->|重複流程| Skill
    Main -->|專門角色| Agent
    Skill --> Result
    Agent --> Result

    style Main fill:#dbeafe,stroke:#3b82f6
    style Skill fill:#dcfce7,stroke:#22c55e
    style Agent fill:#f3e8ff,stroke:#a855f7
    style Result fill:#fef3c7,stroke:#f59e0b

把這條線和前四篇串起來：

• 第 1 篇：Claude 在你電腦上，所以能讀檔案、跑命令
• 第 2 篇：它一次能看的內容有限，所以要管上下文
• 第 3 篇：跨會話規則要進 CLAUDE.md / memory
• 第 4 篇：本次任務的資訊要用 4 件套說清
• 第 5 篇：這些資訊進入模型後，要用合適的 effort 處理

前四篇解決“資訊怎麼進來”，這一篇解決“資訊怎麼被處理”。

到這裡也能解釋為什麼 Skills 和 SubAgents 需要 effort frontmatter。因為它們不是“更高階的提示詞”，而是把任務型別、上下文來源、執行邊界、思考深度一起封裝起來。

比如一個程式碼審查 SubAgent 可以天然更深：

---
name: security-reviewer
description: Review auth, payment, and data access changes before merge.
effort: xhigh
---

這意味著你不必每次都提醒“請認真審計安全風險”。角色檔案已經告訴 Claude：這個角色的任務本來就需要更多推理。

反過來，一個 changelog Skill 可以天然更淺：

---
name: changelog-polisher
description: Clean up release notes wording without changing facts.
effort: low
---

這就是把“思考深度”從臨場手感變成工程配置。

9. 一個日常預設策略

如果你不想每次都想一遍，直接按這個策略來：

• 主要用 Sonnet 做日常開發：保持預設，必要時 /effort medium 省成本。
• 用 Opus 4.7 做複雜編碼：預設 xhigh 可以接受。
• 小修小補很多：臨時 /effort low，邊界寫清。
• 做方案、審計、遷移：先 xhigh，關鍵輪次加 ultrathink。
• 發現輸出過度複雜：降 effort，同時把邊界寫得更窄。
• 發現輸出漏風險：升 effort，同時要求列假設和反例。

變數改名任務，理想 prompt 是：

把 src/auth/ 下的 userName 改成 userId。
边界：只改命名相关引用，不做其它重构。
验收：相关测试通过，diff 里不要出现无关格式化。

這種任務不需要 ultrathink。

快取架構任務，理想 prompt 是：

ultrathink

目标：设计 Redis 缓存穿透修复方案，先不要改代码。
上下文：现有 API 不能破坏，缓存 miss 会直接打数据库，最近高峰期 DB CPU 到 90%。
边界：不要改公开 API；不要引入新存储；先输出方案和风险，不要写实现。
验收：给 2-3 个方案对比、推荐方案、灰度步骤、回滚方案、需要补的监控指标。

這裡就值得深想。因為你不是要它“快點給個答案”，你是要它在動手前儘量把風險想完。

10. 檢驗你真懂了嗎

試著用自己的話回答這 3 個問題：

1. 為什麼"模型能力"和"思考深度"不是一回事？用變數改名和快取架構解釋。對應 §1 + §2。
2. 為什麼不能把所有任務都設成 max？至少說出兩類具體代價。對應 §5。
3. 動手題 ⭐：列出你今天 / 昨天給 Claude Code 發過的 3 個真實任務，按 §6 分叉點框架給每個打分（0-1 / 2-3 / 4-6 / 7+ 分叉點），然後對照表選 effort。如果你發現 3 個任務全是 0-1 分叉點但你之前都用了預設 / xhigh——賬單可能比你預期高一截。對應 §6 + §9。

官方資料

• Claude Code settings · effortLevel
• How Claude Code works

接下來去哪

不用把 effort 當玄學。它只是一個資源分配旋鈕：該快就快，該深就深，別用 max 買心理安慰。