---
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](/docs/claude-code/understanding/01-what-is-claude-code) 的位置、[02](/docs/claude-code/understanding/02-context-window) 的上下文、[03](/docs/claude-code/understanding/03-memory) 的记忆、[04](/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="/docs/claude-code/understanding/06-command-files">
    你已经知道该给 Claude 什么信息、让它想多深。下一篇讲怎么把重复工作流沉淀成 Skills。
  </Card>
  <Card title="04 · 怎么和 AI 说话（上一篇）" href="/docs/claude-code/understanding/04-prompting">
    复习输入侧：目标 / 上下文 / 边界 / 验收。effort 再高，也救不了信息缺失。
  </Card>
  <Card title="07 · 怎么派出多个 AI 专家" href="/docs/claude-code/understanding/07-subagents">
    想把不同 effort 绑定到不同角色，继续看 SubAgents。审计、研究、实现可以分开跑。
  </Card>
</Cards>

不用把 effort 当玄学。它只是一个资源分配旋钮：**该快就快，该深就深，别用 max 买心理安慰**。
