【Claude】Claude Code 扩展思考模式深度指南：think / ultrathink 让 AI 突破推理瓶颈

---

前言

你有没有发现，有些问题 Claude 回答得飘忽不定——同样的问题，今天给出方案A，明天给出方案B，或者在复杂的多步推理中途"跑偏"，最终给出一个似是而非的答案？

这是大语言模型的固有特性：默认情况下，模型的推理深度是有限制的。当问题足够复杂时，Claude 可能在没有充分推理的情况下就输出了答案，导致表面上看起来合理但实质上有缺陷的结论。

**Extended Thinking（扩展思考）**机制正是 Anthropic 为解决这一问题而设计的核心技术。通过给 Claude 分配更多的"思考预算"，让它在输出之前进行更深层次的推理，从而在复杂问题上达到质的飞跃。

本文基于官方文档与社区实战，带你全面掌握扩展思考的使用方法和最佳场景。

---

一、扩展思考的工作原理

1.1 思考预算：给 AI 分配"思考时间"

普通 LLM 的工作方式：

输入 → [单次前向传播] → 输出

Extended Thinking 的工作方式：

输入 → [思考阶段：N次推理迭代] → [输出阶段：基于深度推理的回答]

思考阶段的内容对用户不可见，但会消耗 Token 预算。不同思考级别分配的 Token 预算：

思考指令	思考 Token 预算	适用场景
think	~4K tokens	需要轻度推理的问题
think hard	~8K tokens	需要多步推理的问题
think harder	~16K tokens	复杂算法、架构设计
ultrathink	~32K tokens	最复杂的推理任务
/effort max	最大预算	极限推理

注意： 思考 Token 同样计费，使用前请考虑成本/收益比。

1.2 扩展思考与 /effort 的关系

# 两种方式等价
/effort max      # 通过设置激活最大推理
ultrathink       # 在提问时直接说这个词

# 分级对应
/effort low      ≈ 不使用扩展思考
/effort medium   ≈ think
/effort high     ≈ think hard
/effort max      ≈ ultrathink

---

二、四级思考指令的使用方法

2.1 基础 think（轻度推理）

适用场景：

• 需要理清思路的中等复杂问题
• 有一定逻辑推导的算法题
• 需要权衡几个选项的设计决策

使用方法：

你：think：分析这个 React 组件的性能问题，它每次父组件渲染都会重新渲染

[Claude 内部思考：分析组件依赖、memo 使用情况、回调函数引用...]

Claude（输出）：
  分析发现以下问题：
  1. onSubmit 回调在每次父组件渲染时创建新的函数引用...
  2. 建议使用 useCallback 包裹...

2.2 think hard（中度推理）

适用场景：

• 多文件重构方案的设计
• 算法的正确性证明
• 复杂 bug 的根因分析

使用方法：

你：think hard：设计一个分布式锁方案，需要支持超时自动释放、
    锁续期、以及服务崩溃后的自动恢复

Claude 输出：[基于更深层推理的详细方案设计...]

2.3 think harder（深度推理）

适用场景：

• 系统架构设计（需要考虑多维度权衡）
• 复杂的并发安全问题
• 大型代码库的依赖分析

使用方法：

你：think harder：我们的微服务之间存在循环依赖，
    Service A 依赖 B，B 依赖 C，C 又依赖 A，
    请设计一个解耦方案，不能破坏现有接口

Claude 输出：[深度分析循环依赖的原因，提出事件驱动解耦、引入中间层等多个方案并详细对比...]

2.4 ultrathink（极限推理）

适用场景：

• Claude 之前回答出错或陷入循环的情况
• 极复杂的算法设计（如分布式共识算法）
• 需要考虑极端边界条件的安全设计

使用方法：

你：ultrathink：设计一个无锁的高并发计数器，
    在多核 CPU 上需要精确计数，不能有 ABA 问题，
    同时要最小化 CPU 缓存行竞争（false sharing）

Claude 输出：[极深层的并发安全推理，包括内存屏障、CPU 缓存行对齐等底层细节...]

---

三、何时使用扩展思考（判断标准）

3.1 适合使用的信号

信号一：问题有多个约束条件

❌ 普通思考够了：
"给这个函数加上错误处理"

✅ 需要扩展思考：
"给这个函数加上错误处理，要求：
- 区分可恢复错误和不可恢复错误
- 可恢复错误自动重试3次（指数退避）
- 不可恢复错误触发 Circuit Breaker
- 所有错误记录到分布式追踪系统
- 不影响主链路延迟（P99 < 10ms）"

信号二：Claude 之前给出了错误答案

当 Claude 在某个问题上屡次出错，或者你能感知到它的答案"不够深入"时，加上 think harder 往往能显著改善：

你：这段并发代码有竞争条件，你之前给的修复方案还是有问题，
    ultrathink 帮我彻底分析清楚

信号三：需要多步逻辑推导

适合扩展思考的场景：
✅ 证明某个算法的时间复杂度
✅ 分析数据库查询的执行计划优化
✅ 设计需要向后兼容的 API 变更
✅ 分析安全漏洞的完整攻击链

信号四：答案需要权衡多个相互冲突的目标

你：think hard：我们需要同时满足：
    1. 高可用（99.99%）
    2. 强一致性
    3. 低延迟（< 5ms）
    请分析在 CAP 定理的约束下，如何尽可能地接近这三个目标

3.2 不适合使用的场景

❌ 简单直接的任务（浪费 Token）：
"把这个变量名从 x 改成 userId"
"给这个函数写一行注释"
"把 if-else 改成三元运算符"

❌ 主要是信息检索而非推理的任务：
"这个库的 API 怎么用？"（查文档比推理更有效）
"帮我搜索一下这个错误信息"

❌ 创意性任务（推理深度对创意帮助有限）：
"给这个变量起一个好听的名字"
"写一段欢迎邮件"

---

四、实战案例

案例 1：复杂 Bug 分析

问题描述：

生产环境每隔几天出现一次内存泄漏，重启可以恢复，
但无法稳定复现。初步怀疑是某个缓存没有被正确清理。

普通询问（效果不佳）：

你：我们有内存泄漏，帮我看看代码

Claude：可能是以下几个原因：1. 全局变量积累...
（给出的是泛泛的可能性列表，缺乏针对性）

使用 think harder（效果显著）：

你：think harder：分析以下几个文件，找出可能导致内存泄漏的位置。
    特征：每隔几天才出现，重启恢复，与用户请求量相关。
    @src/cache/manager.py @src/session/store.py @src/background/jobs.py

Claude 深度分析：
  基于这三个文件的详细分析：

  在 cache/manager.py 第 127 行，发现了一个潜在的内存泄漏：
  `self._pending_cleanup` 字典只在 `_do_cleanup()` 中清理，
  但 `_do_cleanup()` 仅在缓存条目**被命中时**才触发清理，
  如果某些缓存条目长期没有被访问，它们会一直积累在 `_pending_cleanup` 中。
  
  与"每隔几天"的特征匹配：在低流量时段，某些缓存可能数天没有被访问，
  导致 _pending_cleanup 持续增长...

  建议的修复方案：添加基于时间的强制清理任务...

案例 2：系统设计审查

场景： 需要 Claude 审查一个分布式系统设计方案，找出潜在问题

你：think harder：我设计了以下分布式消息系统架构，
    请从以下几个维度深度分析潜在问题：
    - 单点故障风险
    - 消息丢失场景
    - 消息重复消费风险
    - 在网络分区时的行为
    - 扩容/缩容时的影响
    
    [系统架构描述...]

Claude 输出：[逐维度的深度分析，包括具体的失败场景举例和修复建议...]

案例 3：算法优化

场景： 当前算法时间复杂度 O(n²)，需要优化到 O(n log n)

你：ultrathink：以下是一个求最长递增子序列的实现，
    当前是 O(n²)，我需要优化到 O(n log n)。
    请不只给我结论，要一步步推导为什么这个优化可行，
    以及关键的正确性证明。
    
    [当前代码...]

Claude 输出：
  [详细的算法推导过程，包括为什么可以用二分搜索维护一个单调序列，
   正确性证明，以及与原算法等价性的严格论证...]

---

五、与 /effort 配合使用

5.1 全局设置推理级别

# 整个会话使用高推理级别
/effort high

# 之后的所有问题都使用 think hard 级别的推理
# 适合：整个会话都在处理复杂设计问题

5.2 单次覆盖

即使全局设置了 /effort medium，你也可以在单个问题里用更高级别的关键词覆盖：

（全局设置：/effort medium）

你：ultrathink 分析这个并发 bug
（这一次会用 ultrathink 级别，下一次回归 medium）

---

六、成本控制策略

6.1 估算扩展思考的额外成本

普通 Sonnet 请求（1K input + 500 output）≈ $0.003
+ think（4K 思考 token）≈ $0.012 额外消耗
+ ultrathink（32K 思考 token）≈ $0.096 额外消耗

一个 ultrathink 请求的费用 ≈ 普通请求的 33 倍

6.2 使用原则

✅ 一次 ultrathink 找到了之前反复探索都找不到的 bug
   = 节省了 5 次普通请求 + 1 小时排查时间 → 值得

✅ 用 ultrathink 做系统架构设计
   = 避免了架构决策失误的重构成本 → 值得

❌ 用 ultrathink 问"这个变量名好不好"
   = 浪费

原则：扩展思考是"高收益问题"的加速器，不是所有问题的默认选项。

6.3 分层使用策略

先用 think 尝试 → 如果答案不够深入 → 升级到 think hard
think hard 还是不满意 → 升级到 think harder
think harder 仍然出错 → 考虑 ultrathink

不要一开始就直接用 ultrathink，逐步升级

---

七、调试扩展思考效果

7.1 如何判断扩展思考是否真正起效

有些情况下，增加思考级别不一定有帮助，比如：

• 问题的答案取决于外部信息（如最新的库文档），而不是推理
• 问题过于主观，没有"更正确"的答案
• 问题已经足够简单，普通推理就能解决

判断方法： 用不同思考级别分别问同一个问题，对比答案质量。如果 ultrathink 和 think 的回答质量没有明显差异，说明这个问题不需要扩展思考。

7.2 常见无效场景

❌ 询问库的使用方法
→ Claude 的知识来自训练数据，更多思考不能创造新知识
→ 正确做法：直接提供文档链接或使用 MCP 工具获取最新文档

❌ 要求 Claude 记住上次的对话内容
→ 这是记忆问题，不是推理问题
→ 正确做法：使用 CLAUDE.md 或在对话中重新提供上下文

❌ 生成大量重复性代码
→ 这是生成任务，不需要深度推理
→ 正确做法：普通模式 + 良好的模板/示例

---

八、避坑清单

1. 不要把扩展思考当成万能药：有些问题的根本在于信息不足，而不是推理不够深

2. 监控 Token 消耗：扩展思考的 Token 消耗可能比你想象的高，用 /cost 追踪

3. 先提供充足上下文：扩展思考加上充足的上下文 = 最佳效果；缺乏上下文时，再深的推理也无法弥补

4. 不要依赖扩展思考代替测试：即使 Claude 经过深度推理给出的方案，也需要通过测试验证

5. 对扩展思考的结论保持批判性：更多的推理 ≠ 一定正确，复杂推理也可能有错误，特别是涉及具体业务逻辑时

---

总结

扩展思考（Extended Thinking）是 Claude Code 最独特的竞争力之一。通过四个层级（think → think hard → think harder → ultrathink）分配不同的推理预算，你可以在关键问题上获得远超普通 AI 工具的推理质量。

使用建议：

• 日常任务：普通模式或 /effort low，节省成本
• 有一定复杂度的问题：think 或 /effort medium
• 架构设计、复杂 bug：think hard/harder
• Claude 反复出错、极复杂并发/算法问题：ultrathink

把扩展思考用在值得用的地方——这是提升 Claude Code 输出质量最直接、最有效的方法。