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 买心理安慰。