Claude Extended Thinking 实战：thinking budget 调多大才合适？

上个月接了一个用 Claude API 做代码审查的活。需求不复杂------把 PR diff 扔给 Claude，让它找出潜在 bug。

第一版很快就跑通了。但有个问题：一些边界情况的逻辑错误，Claude 经常漏掉。

加了 Extended Thinking 之后，检出率从 60% 提到了接近 90%。

但这玩意不免费。thinking tokens 按输出 token 计价，budget 设大了烧钱，设小了没用。调了一个月，踩了不少坑。

Extended Thinking 是什么

简单说：让 Claude 在给出最终答案之前，先在内部做一轮"思考"。这个思考过程你会看到（也可以选择隐藏），但它消耗的 token 是要计费的。

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 4096,
  "thinking": {
    "type": "enabled",
    "budget_tokens": 2048
  },
  "messages": [
    {"role": "user", "content": "review this PR diff for bugs"}
  ]
}

budget_tokens 最小 1024，最大不能超过 max_tokens。思考内容会以 thinking content block 返回，不计入最终的 content 文本，但计入总 token 消耗。

说白了：你设置了 2048 的 thinking budget，Claude 不一定用完。它觉得想够了就停。

三种模式

Claude API 现在支持三种 thinking 配置：

1. 关闭（disabled）

{"thinking": {"type": "disabled"}}

省 token，适合简单任务：翻译、摘要、格式化、简单问答。

2. 启用（enabled）

{"thinking": {"type": "enabled", "budget_tokens": 4096}}

你指定 thinking budget。适合需要推理的任务：代码审查、数学、逻辑分析、架构决策。

3. 自适应（adaptive）--- 推荐

{"thinking": {"type": "adaptive"}}

Claude 自己判断需不需要思考、想多少。适合你不知道任务复杂度的情况。

这里有个坑：adaptive 模式在某些 SDK 版本里还标着 beta，行为不稳定。有一次我跑了 10 次同样的 prompt，3 次没触发 thinking，2 次 thinking tokens 差了 3 倍。生产环境建议先用 enabled + 固定 budget，等你摸清了任务特征再切 adaptive。

Thinking Budget 怎么调

这是最核心的问题。不同任务类型，最优 budget 差很多。

以下是我一个月来在几个典型场景下的经验数据（非严格 benchmark，同一个 prompt 跑 5 次取中位数）：

任务	budget_tokens	实际消耗	效果提升	评价
代码审查（单文件 < 200行）	2048	~1200	+30%	性价比最高
代码审查（多文件 PR）	4096	~2800	+50%	值得
架构设计建议	8192	~5000	+40%	但也看 prompt 质量
Bug 根因分析	4096	~3500	+60%	这是 extended thinking 最强的场景
翻译/摘要	0 (关闭)	0	0	开了纯浪费
简单问答	0 (关闭)	0	0	同上
数学证明	8192	~6000	+80%	但用 o1/DeepSeek-R1 更合适
SQL 生成（复杂查询）	2048	~1500	+25%	有帮助但没那么显著

几点发现：

1024 是最低门槛，但基本不够用。 Claude 的 thinking 过程是结构化的------它会先分析问题、列出可能方案、对比、然后选一个。1024 token 刚够它"热身"，真正的推理还没展开就被截断了。除非你的任务极其简单，否则至少 2048 起步。

超过 8192 之后，边际收益骤降。 我试过把 budget 设到 16000，thinking 过程确实更长，但多出来的部分基本是"绕圈"------同一个角度反复阐述，换几种说法说同一件事。真正有价值的推理在前 5000-8000 token 就已经完成了。

max_tokens 要留够余量。 如果你的 thinking budget 是 4096，max_tokens 至少要设 8192，否则 Claude 还没开始正经回答，token 就用完了。一次审查多文件 PR 时，我设了 budget_tokens=4096, max_tokens=4096，结果返回的审查意见只有两句话------后面全被截断了。

什么时候不该开

Extended Thinking 不是免费的午餐。

成本 ：thinking tokens 按 Anthropic 的标准输出价格计费。Sonnet 4.6 的输出是 <math xmlns="http://www.w3.org/1998/Math/MathML"> 15 / M T o k ，如果你每个请求都开 4096 t h i n k i n g b u d g e t ，一天 1000 次调用就是多了 15/MTok，如果你每个请求都开 4096 thinking budget，一天 1000 次调用就是多了 </math>15/MTok，如果你每个请求都开4096thinkingbudget，一天1000次调用就是多了60。

延迟：thinking 阶段是在模型内部跑的，但也要时间。budget 设到 4096 之后，首 token 延迟从 ~1s 涨到 ~3-5s。如果你在做实时对话，这个延迟用户能感觉到。

不适合的场景：

• 翻译、摘要、改写（不需要推理）
• 情感分析、分类（简单的模式匹配）
• 格式转换（markdown→HTML 之类的）
• 任何"一句话就能回答"的问题

适合的场景：

• 代码审查、bug 分析
• 多步骤推理（数学、逻辑）
• 架构设计、技术决策
• 需要"多想一步"的复杂任务

在生产环境怎么用

我现在的策略：

1. 先不开 thinking，跑一周。 收集真实的任务数据：哪些类型的请求 Claude 回答得不好？哪些需要反复追问？

2. 对"重推理"任务单独开 thinking。 不要全局开。在你的 API 网关或路由层加一个标记------reasoning_required: true 的任务走 extended thinking，其他的不走。

3. 从 adaptive 开始，再调 enabled。 先用 adaptive 模式跑几天，收集 thinking token 的实际消耗分布。然后针对你的任务，选一个覆盖 80% 情况的 budget 值，切成 enabled 模式（更稳定也更可控）。

4. 监控 thinking 效率。 记录 thinking_tokens / output_tokens 比值。如果这个值持续 > 2（thinking 比输出还多一倍），考虑降 budget 或关掉 thinking。如果 < 0.5 且输出质量不理想，考虑加 budget。

# 简单的 thinking 效率监控
thinking_ratio = thinking_tokens / max(output_tokens, 1)
if thinking_ratio > 2.0:
    logger.warning(f"Thinking overhead high: {thinking_ratio:.1f}x")

5. prompt 本身比 thinking budget 更重要。 一个结构清晰的 prompt------明确说"请先分析，再给出结论，考虑以下边界情况..."------比单纯加大 thinking budget 效果好得多。Extended Thinking 是放大器，不是替代品。

总结

• Extended Thinking 值不值？值，但不是所有任务都需要。
• budget 设多少？代码审查 2048-4096，架构/分析 4096-8192，简单任务关掉。
• adaptive vs enabled？生产环境用 enabled，摸清后再考虑 adaptive。
• 最大坑：max_tokens 没留够余量，输出被截断。

Claude 的 extended thinking 本质上是"用 token 换推理质量"。你的任务推理越深、边界情况越多，这个 tradeoff 越划算。但别无脑开------翻译一句"hello world"也要 thinking，那就是在烧钱取暖了。