---
title: "05 · AI 怎麼決定想多深"
description: "思考深度不是把 AI 變聰明，而是決定回答前走多少步推理。變數改名用 low，架構決策用 xhigh，關鍵遷移再考慮 max。"
canonical: "https://xiangyugongzuoliu.com/tag/claude-code"
verifiedAt: "2026-05-08"
---

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

> [!NOTE]
> **這一篇用 13 分鐘換什麼**：你已經理解 [01](/zh-Hant/docs/claude-code/understanding/01-what-is-claude-code) 的位置、[02](/zh-Hant/docs/claude-code/understanding/02-context-window) 的上下文、[03](/zh-Hant/docs/claude-code/understanding/03-memory) 的記憶、[04](/zh-Hant/docs/claude-code/understanding/04-prompting) 的資訊輸入。這一篇拆**資訊處理深度**：Claude 什麼時候該快答，什麼時候該慢想，什麼時候“想太多”反而會壞事。

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

你讓 Claude Code 改一個變數名：

> [!NOTE]
> **👤 你**：把 `userName` 改成 `userId`，只改 `src/auth/` 下面。

> [!TIP]
> **🤖 Claude**：找到 6 處引用，已修改，測試透過。

幾乎秒回。

然後你換一個任務：

> [!NOTE]
> **👤 你**：我們現在 Redis 快取經常穿透，幫我設計一套不會影響現有 API 的快取修復方案，先不要改程式碼。

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

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

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

> [!IMPORTANT]
> **第一性原理**：思考深度解決的不是“模型會不會”，而是“模型在回答前要不要多走幾步推理”。簡單任務多想是浪費，複雜任務少想是冒險。

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

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

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

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

這兩個不是一回事。

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

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

```mermaid
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](https://code.claude.com/docs/en/model-config#adjust-effort-level)。

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

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

> [!WARNING]
> **關鍵點**：高 effort 不是“免費增強智力”。它換來的是更深推理，同時付出延遲、token 和偶爾過度複雜化的代價。

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

| 任務 | Claude 應該怎麼處理 | 高 effort 有沒有必要 |
|------|------|------|
| 改 `userName` 為 `userId` | 查引用、改檔案、跑測試 | 通常沒有 |
| 修一個明確報錯 | 看 stack trace，定位檔案，補測試 | medium / high 足夠 |
| 設計快取修復方案 | 讀鏈路、列風險、比較方案、給 rollout | xhigh 值得 |
| 資料遷移 / 許可權模型重做 | 先審計邊界，再分階段設計 | max 可以試，但要驗證收益 |

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

## 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 文件](https://code.claude.com/docs/en/model-config#adjust-effort-level)。

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

| effort | 一句話理解 | 適合什麼 | 不適合什麼 |
|------|------|------|------|
| `low` | 快速掃一眼 | 改名、格式化、短問答、已知路徑的小修 | 架構、安全、跨模組 bug |
| `medium` | 正常工作狀態 | 成本敏感的日常編碼、普通 bug、內容整理 | 需要大量權衡的方案設計 |
| `high` | 認真想一輪 | 複雜 bug、程式碼審查、帶測試的功能改動 | 超高風險決策的最終拍板 |
| `xhigh` | 深度工作預設檔 | Opus 4.7 上的大多數 coding agent 任務 | 簡單機械任務 |
| `max` | 不給 token 預算上限地深想 | 關鍵遷移、安全審計、重大架構決策前的方案比較 | 常態預設；容易邊際收益遞減 |

> [!TIP]
> **一句話理解**：`low` 是讓 Claude 快速執行，`medium/high` 是日常工作，`xhigh` 是 Opus 4.7 的深度預設，`max` 是關鍵任務前的專項深想，不是全天候開關。

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

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

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

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

| 錯誤做法 | 實際問題 | 更合理的做法 |
|------|------|------|
| 簡單任務切 Opus + max | 模型和思考深度都過量 | Sonnet / Haiku + low 或預設 |
| 複雜任務繼續 low | 模型有能力，但沒給足推理深度 | 保持模型，先升 effort |
| 每次都寫 `ultrathink` | 把臨時指令當預設配置 | 常用深度用 `/effort`，關鍵輪次再 `ultrathink` |
| 輸出不準就只換模型 | 可能是提示詞缺上下文或邊界 | 先補 4 件套，再判斷是否升模型 / effort |

> [!NOTE]
> **判斷順序**：先看第 4 篇的資訊四件套齊不齊，再看本篇的 effort 是否匹配，最後才考慮換模型。很多“模型不行”的問題，本質是輸入資訊缺失或思考深度不匹配。

## 5. 為什麼不能永遠 max

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

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

### 第一，慢

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

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

### 第二，貴

thinking token 也是 token。官方文件明確說，即使思考內容被摺疊或被隱藏，生成的 thinking tokens 仍然會計費。完整說明在 [Extended thinking](https://code.claude.com/docs/en/model-config#extended-thinking)。

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

### 第三，會想複雜

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

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

> [!CAUTION]
> **新手坑**：高 effort 不能替代清晰邊界。你說"順便最佳化一下"，再開 max，Claude 只會更認真地順便做很多事。真正保護你的，是第 4 篇講的邊界和驗收。

**新手最常見的兩類錯配**：

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

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

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

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

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

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

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

> [!IMPORTANT]
> **關鍵點**：`max` 最適合放在“決策前”，不適合放在“所有執行步驟裡”。先讓它把路想清楚，再降回合適 effort 執行，通常比全程 max 更穩。

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

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

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

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

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

快取架構有很多分叉點：

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

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

| 分叉點數量 | 典型任務 | 推薦 effort |
|------|------|------|
| 0-1 個 | 改名、格式轉換、補一句文案 | `low` |
| 2-3 個 | 普通 bug、單模組功能、測試修復 | `medium` / `high` |
| 4-6 個 | 跨模組 bug、重構方案、釋出前審查 | `high` / `xhigh` |
| 7 個以上，且選錯代價大 | 資料遷移、許可權、安全、核心架構 | 先 `xhigh`，必要時 `max` |

```mermaid
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` 開啟互動滑塊，或者直接：

```text
/effort high
```

想回到模型預設：

```text
/effort auto
```

也可以在啟動時傳：

```bash
claude --effort high
```

或者用環境變數：

```bash
export CLAUDE_CODE_EFFORT_LEVEL=high
```

官方還支援在 settings 裡寫 `effortLevel`。這些入口完整列在 [Set the effort level](https://code.claude.com/docs/en/model-config#set-the-effort-level)。

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

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

```bash
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 里加：

```text
ultrathink
```

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

> [!IMPORTANT]
> **實際建議**：日常不用每次手動調。先用預設；遇到“它明顯想淺了”，加 `ultrathink` 或調高 `/effort`；遇到“它在小事上想太多”，調低到 `medium` 或 `low`。

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

壞例子：

```text
ultrathink 帮我优化一下缓存。
```

好例子：

```text
ultrathink

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

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

## 8. 跟 Skills 和 SubAgents 的關係

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

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

這很合理。

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

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

```mermaid
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 可以天然更深：

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

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

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

```yaml
---
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 是：

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

這種任務不需要 `ultrathink`。

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

```text
ultrathink

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

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

> [!TIP]
> **底層邏輯**：effort 要和“任務風險”匹配，而不是和“你有多焦慮”匹配。焦慮時更要寫清目標、邊界、驗收，再決定是否升 effort。

## 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。

> [!TIP]
> **過關標準**：能用一句話說清——**effort 是 Claude 處理資訊時的推理深度旋鈕；路徑少就低，分叉多就高，風險極大才臨時 max。**

<details id="glossary">
<summary>📖 本篇術語速查表</summary>

- effort：思考深度。Claude Code 控制 adaptive reasoning 深淺的引數。
- adaptive reasoning：自適應推理。模型按任務複雜度決定是否以及多少展開推理。
- extended thinking：擴充套件思考。Claude 在回答前生成的 reasoning 內容，可能摺疊顯示。
- thinking token：思考 token。推理過程消耗的 token，也會計費。
- `ultrathink`：單次深想關鍵詞。Claude Code 識別的特殊關鍵詞，用於本輪更深推理。
- frontmatter：檔案頭後設資料。Skill / SubAgent markdown 頂部的配置區。

</details>

## 官方資料

- [Claude Code settings · effortLevel](https://code.claude.com/docs/en/settings)
- [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works)

## 接下來去哪

<Cards>
  <Card title="➡️ 06 · 把重複的話寫成檔案" href="/zh-Hant/docs/claude-code/understanding/06-command-files">
    你已經知道該給 Claude 什麼資訊、讓它想多深。下一篇講怎麼把重複工作流沉澱成 Skills。
  </Card>
  <Card title="04 · 怎麼和 AI 說話（上一篇）" href="/zh-Hant/docs/claude-code/understanding/04-prompting">
    複習輸入側：目標 / 上下文 / 邊界 / 驗收。effort 再高，也救不了資訊缺失。
  </Card>
  <Card title="07 · 怎麼派出多個 AI 專家" href="/zh-Hant/docs/claude-code/understanding/07-subagents">
    想把不同 effort 繫結到不同角色，繼續看 SubAgents。審計、研究、實現可以分開跑。
  </Card>
</Cards>

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