Claude Code 模型与努力度选择：什么情况下调哪个旋钮

译者按：原文发表于 2026 年 7 月 7 日，由 Claude Code 团队技术员工 Lydia Hallie 撰写。本文是 Anthropic 官方对「模型 + 努力度」这对最容易被混淆的设置的一次系统性澄清——前者决定用哪一组权重，后者决定在这次请求上花多少工作。两个旋钮都在影响「回答好不好」，但作用层面完全不同。全文翻译基础上补入译者注（带 ⚑ 标记），保留原文未公开代号。

先压三个判断

整篇文章读完能浓缩成三件事：

1. 模型（model）决定哪一组冻结权重来处理你的请求——Claude 知道什么、不知道什么，在训练结束那一刻就锁定了。你的 prompt 不会改写权重，只会引导（steer）这一次预测。
2. 努力度（effort level）决定这次请求上 Claude 愿意走多远——读几个文件、跑几次工具、验几种假设。低努力度下它倾向于先回来问你；高努力度下它自己往前推。
3. 调旋钮前先回答一个问题：是 Claude 不知道，还是 Claude 没尽力？前者挑更大的模型；后者提高努力度。把能力问题当态度问题处理、或反之，钱会烧得莫名其妙。

剩下三节把这三句话拆到机制层。

系统地图：模型、努力度、token 各管哪一摊

最后两行的关键：努力度是训练时注入到权重里的行为倾向，影响 Claude 每一步的判断，但不构成硬墙。它告诉 Claude “应该走多深”，不强迫它必须走那么深——三步调试计划在步骤 1 就定位到 bug 时，步骤 2、3 会被自动跳过。这是设计如此，不是它偷懒。

⚑ 译者注：原文用了 “frozen weights”（冻结的权重）一词。在 LLM 语境下，「冻结」指训练结束后权重就不再被更新——推理阶段的任何 prompt 都不会改写权重矩阵里的数字。这和"在线学习"或"持续微调"是两件事。Claude Code 在用户本地跑的那部分（CLI、文件读取、工具调用）也不会回传到权重里。

一个任务如何流过 Claude Code：调试示例

把抽象机制落到一个具体场景上——假设你让 Claude Code 调试一段 TypeScript 代码：

// 假设报错的代码片段（节选）
async function fetchUserData(userId: string) {
  const res = await fetch(`/api/users/${userId}`);   // ← 第 3 行
  if (!res.ok) throw new Error(`Failed: ${res.status}`);
  return res.json();
}

报错信息：TypeError: Cannot read properties of undefined (reading 'json')。

低努力度（low effort）下的 Claude Code 看到这条信息时，通常会：

• 读 1–2 个相关文件，验证 fetch 的返回值
• 给出 1–2 个最可能的修复方向（比如「res 可能是 undefined，加个判空」）
• 然后回来问你：「要不要我改？」

高努力度（high effort）下的 Claude Code：

• 先写一个三步调试计划（plan）：检查 fetch 调用 → 跑测试复现 → 验证修复
• 实际执行时读了 5+ 个相关文件、跑了测试、对比了两种修复方案
• 在步骤 1 定位到根因后，主动把计划改成「步骤 2、3 已不需要」——这一步你会从任务列表（task list）的实时更新里看到
• 最后给出修复并附上验证结果

同样一个 prompt，高努力度产出的 token 数量大约是低努力度的 7 倍——但只在任务确实需要这种深度时才值得。简单的"换个 import 路径"任务开高努力度，Claude 也不会硬凑出 7 倍 token，它会先告诉你"这活儿我用不上那么多力气"。

⚑ 译者注：7x 这个数字来自原文插图的标注（同 prompt，两个 effort 等级的 token 用量对比）。原文标注"测试中观察到大约 7 倍"，并强调"在简单任务上 Claude 不会为了凑 effort 而人工膨胀 token 用量"——这一条对很多工程师是反直觉的，因为通常"调高参数 = 输出变长"的直觉在这里不成立。

模型设置到底在切什么

Claude Code 把你的输入——system prompt、工具定义、CLAUDE.md（项目级系统提示）、对话历史、当前上下文里的文件——打包成一个 API 请求发给服务端。

服务端做的第一件事是分词（tokenize）：把你的文本切成模型训练时认识的最小单位，每一段对应词汇表里的一个整数 ID。比如 const 可能是 1978，await 可能是 4293。你的 prompt 在这一步之后变成了一串整数，模型看到的就是这串数字。

接下来才是模型工作：

• 用这串整数作为输入，模型对词表里每个可能的下一个 token 计算概率分布
• 选概率最高的那个（或按温度采样）作为下一个 token
• 把新 token 拼回去，再跑一遍

200 个 token 的回答 = 200 次这种循环。每一次循环都跑一次完整的矩阵乘法。你的等待时间和输出成本的主要来源，就是这 200 次循环。

把输入变成概率的，是模型的权重（weights，也叫 parameters）——几十亿个数字组织在多层大矩阵里。Claude"知道"的所有事——TypeScript 语法、流行框架的用法、地道的 Go 习惯写法——全部编码在这些数字里。训练结束后，权重就冻结了。你的 prompt 不会改写它们，CLAUDE.md 不会改写它们，当前上下文里的文件也不会改写它们。

这就解释了 Claude 为什么会"幻觉"——某个不存在的 API 被它自信地写出来。这不是"它查了一下没查到"，而是权重在预测下一个 token 时沿着训练时见过的模式生成了一串看起来合理的字符。如果某个库在训练截止后才发布，权重里就没有它的信息；你可以把文档塞进上下文，但那是"引导"（steering）这一次请求，不是"教"模型——模型没有真正"记住"任何东西，下次还是没记住。

所以当你切换模型时，你做的事情是：换一组冻结的权重来处理这次请求。模型不会一口气把答案吐出来；它一个 token、一个 token 地往外挤，每一次都把刚生成的 token 拼回去重跑一次循环。

模型设置决定的是两件事：

• 用哪组权重处理你的请求
• 每个输出 token 的价格

模型设置不决定的是：这次请求要输出多少个 token。那个数字会随着任务的难度、Claude 自己决定要做多少工作而大幅波动——这正是努力度在控的事情。

努力度到底在切什么

Claude Code 在做一个任务时，输出的 token 大致分三类：

这三类 token 走的是同一个循环，按同一个费率计费。思考 token 的生成机制和别的 token 完全一样，并且会一直停留在这次对话的上下文里——当 Claude 转向写代码时，它刚才的推理也会变成下次预测的输入。所有 Claude 输出都是 token；思考、工具调用、给你的文字，都是同一个循环的不同表象。

那努力度到底改了什么？努力度被作为请求的一部分发给模型，紧挨着你的 prompt。模型在训练时被教会了在每个努力度下该表现出什么行为——这套"学会的行为"已经烤进了那组冻结的权重里。

当你的请求到达时，努力度就是模型响应的又一个输入——和你 prompt 里的文字一样，模型会回应它。努力度设置的是：在这一轮里，Claude 在判定"任务完成"之前要让自己有多确定、做到多彻底。

这个判断每轮都会做一次，并且会产出更多 token 以达到更高的置信度。

高努力度下，Claude 通常会从创建一个计划开始，努力度影响这个计划的深度和广度。但计划不是冻结的——当 Claude 拿到动作结果后，它会更新进度和对自己已经积累的判断的确定度。

比如一个三假设调试计划：

• 步骤 1 跑完就找到了 bug
• “调查假设 2 和 3"这一步变成没必要
• Claude 通常会明确说出来：“第一步已经定位到，剩下的检查不需要了”
• 然后跳过步骤 2、3

你在 Claude Code 里看到的任务列表（task list）被实时修改，就是这个机制的外显。

高努力度下 Claude 更倾向于复核额外的假设、验证正确性，但通常不会为了"显得在工作"而在简单任务上人工膨胀用量。Anthropic 团队在训练期间对"过度思考”（overthinking）这件事盯得很紧——它会反过来降低效果。

选努力度时该想什么

Anthropic 的官方建议是：大多数任务用模型的默认努力度。默认值的设定目标是让 Claude 的 token 消耗与"大多数人愿意为这类任务花的钱"匹配。

把努力度想成手动覆写——决定 Claude 要花多大力气、多长时间。当你对自己工作的领域或类型有清晰的偏好（更彻底 vs 更快）时，才主动去调。把它当成全局偏好，而不是每个任务都要重新决定一次的设置。

一个值得记住的实战观察（原文标注于 Claude Opus 4.8 发布后）：用 Opus 4.8 的默认努力度处理同类任务时，结果更好、token 数与 Opus 4.7 默认努力度持平。换句话说：默认努力度是被精心校准过的，不要无端调高。

错了之后改什么

当 Claude 给出的答案不对，你的第一反应不应该是调旋钮，而是检查自己提供的上下文：提示词是不是太模糊？Claude 接的是不是对的工具？是不是加载了正确的 skill？

⚑ 译者注：这里的"skill"指 Claude Code 的 skills 机制，不是泛指"技能"。Skills 是项目级的工具/工作流定义，类似 Cursor 的 rules 或 Codex 的 custom instructions。

如果你在一个本来不需要那么高的任务上硬把努力度拉满，根因往往在上游——你的 prompt、你的 CLAUDE.md、或任务范围本身。

但假设你已经给了清晰上下文，Claude 还是错了。那要问自己的问题是：

Claude 是"没尽力"，还是"不知道"？

两种情况，两种旋钮。

不知道：模型选错了

当问题真的很难时，挑一个更大的模型。这类问题包括：

• 隐蔽的 bug
• 你不熟悉的领域
• 架构决策

更大的模型在小模型"不管给多少上下文都自信地错"时特别有用。更大的模型也更擅长处理模糊——而对明确指令驱动的执行类任务，小模型反而更合适（成本低、速度快、不浪费）。

反过来，常规任务就用小模型：可以精确描述的编辑、机械式的修改、已经在上下文里的代码问题。如果 Claude 已经掌握了相关上下文、明显尽力了还错——这就是该升级模型的信号。如果你已经在用大模型、且工作已经是常规性的了，降一级会更快，通常还更便宜，且不影响输出质量。

没尽力：努力度选低了

当 Claude 错在"跳过了文件、没跑测试、没复核自己的工作时"，挑一个更高的努力度。这种情况最相关于：你把努力度设到了模型默认值之下。

调高努力度，意味着 Claude 在"已经够了"的边界上再推一推：多读一个文件、多跑一次测试、多列一个对照假设。但它不会对简单任务也强行膨胀用量——这正是 Anthropic 在训练里压"过度思考"的回报。

模型 × 努力度的二维定位

把模型（纵轴：能力） × 努力度（横轴：彻底程度）画成一张图：

没有一个组合是普遍更好的：

• 模型设置大致是"能力上限"
• 努力度设置大致是"彻底程度"

多数真实任务需要两者各占一点。

⚑ 译者注：原文此处用「Claude Fable」命名一个未公开模型——这与 Anthropic 公开 API 上的 Claude Sonnet / Claude Opus 命名体系不一致。原文将三者并列说明"专家中的专家 / 资深专家 / 优秀通才"的层级关系。译者无法核实 Fable 是否为内部代号、产品代号或占位写法，因此保留原文不做翻译也不做引申。下文遇到 Fable 时同理处理。

模型、努力度、token 消耗：三条曲线

这三个旋钮怎么共同决定成本，看三组曲线（原文示意图，数字为示意、非真实基准数据）：

简单任务上的对比

两组曲线（示意）：任务简单到两个模型都能很快完成。

两组曲线在大努力度上分叉：较大模型在每个 token 更贵的前提下，还会做更多验证步骤。这就是为什么"在常规任务上降一级模型能省钱且不影响质量"的逻辑成立。

复杂任务上的对比

两组曲线（示意）：任务难到两个模型都需要被推一推。

小模型要"磨到能力的边界"，烧更多迭代；大模型用更少步骤就能达到同样的质量线。每 token 你付更多，但单任务总成本可能反而更低——而且更重要的是，大模型能完成小模型即使在最高努力度下也完成不了的任务。这种差距在 Fable 上最明显：长链路多步骤任务里它拉开最大，Anthropic 内部测试中它能完成 Opus 和 Sonnet 在任何努力度下都完成不了的事。它每 token 也是最贵的——这是另一个"留到真需要的任务上才用"的理由。

上图的关键点是：努力度决定 Claude 愿意沿曲线走多远，但这不意味着 Claude 需要走那么远才完成任务。

另一个细节：努力度塑造 token 消耗，但不限制 token 消耗。系统里唯一的硬上限是 max_tokens——命中时它会在中途截断响应。这是一个粗糙的工具，主要给 API 开发者用。更柔和的控制——比如 task budgets 或在 prompt 里直接说"保持简洁"——更有用。它们是模型训练时被教会遵循的指引——临近上限时模型会倾向尽快收尾——而不是一堵它会撞上的墙。

默认优先，按需才动

大多数时候不应该想着这两个旋钮。当结果不达预期，按这个顺序排查：

1. 先看上下文：提示词是不是太模糊？工具是不是接错了？skill 加载得对不对？90% 的"Claude 答得不好"根因在这里，不在旋钮上。
2. 再回答"不知道 vs 没尽力"：
   • 不知道 → 升级模型
   • 没尽力 → 提高努力度
3. 决定后只调一个：同时拉模型又拉努力度，账单涨上去你也分不清是哪一档的贡献。

什么时候该主动偏离默认？只有当你对自己工作的领域或任务类型有清晰偏好（“我做的活就是更吃推理深度"或"我做的活就是机械性的”）时，把努力度当作全局偏好来调。否则——留在默认。

⚑ 译者注：Anthropic 强调"默认努力度是被精心校准过的"——这一点和多数 LLM 产品的"默认参数偏保守、需要用户主动调高"模式相反。Claude Code 的默认 = 大多数人愿意为这类任务花的钱。如果你不确定，先用默认；不要"为了以防万一"先开高。

判断不出来的实验方法

「不知道」和「没尽力」有时候确实难分。Anthropic 给的判断信号是：

“If Claude has all the pertinent context, clearly tried, and still got it wrong, that’s a signal to pick a more capable model. If Claude got it wrong by skipping a file, not running the tests, or bailing on a refactor partway through, pick a higher effort level.”

翻译成实操：

注意最后一行：Claude 跑飞了不一定是旋钮错位，很多时候是任务太大了。把它拆成 3 个明确的小任务，比调任何旋钮都更管用。

调高努力度也有反例

原文花了相当篇幅强调一件事：高努力度不会"硬凑" token 用量。Anthropic 在训练时专门压制"过度思考"（overthinking）——即模型在简单任务上为了显得在工作而生成冗余推理。

实操中的反例：

• 机械式修改：换个 import 路径、改个变量名、补一行 CSS——高努力度下 Claude 不会"为了努力而努力"，它会先告诉你"这活儿我用不上那么多力气"。
• 已经有完整上下文的快速问答：高努力度也不会显著改变输出。
• 明确说"保持简洁"的 prompt：模型在训练时被教会遵循这条指引，会主动控制推理深度。

换句话说：高努力度是"我愿意多花 token"的可信号，不是"我必须花 token"的硬墙。Claude 不会为了吃满额度而浪费你的钱。

译者注（完整版）

关于 Fable

原文出现的「Claude Fable」未在 Anthropic 公开 API 中出现，亦无公开文档证实其含义。可能是内部代号、产品代号或占位写法——译者无法核实。本文按原文保留，不做翻译、不做引申。如果你读到的是更近的 Anthropic 公告，请以官方文档为准。

关于术语处理

关于数字

• 7x token：原文示意图标注，非严格基准测试结果
• Opus 4.8：原文在努力度选择章节引用该版本的发布观察——“默认 effort 下结果更好，token 数与 Opus 4.7 默认 effort 持平”
• 模型分档（Fable/Opus/Sonnet）：原文未给出价格、性能基准或能力边界的精确数字，本文不做推断

译后记

这篇文章对中文工程读者的最大价值，是它用工程师熟悉的"系统机制"语言重新讲了"模型 vs 努力度"——不是常见的那种"越大越好"或"看心情调"的玄学表述。它把模型还原成权重矩阵、把努力度还原成训练时注入的行为倾向、把 token 还原成循环次数 × 每 token 价格——这种拆解对日常选型、计费理解、排查"为什么这次这么贵"都直接有用。

文章没说的是：把"哪个旋钮"对应到具体场景这件事，是需要在自己项目里反复试出来的——没有任何替代品。但先把模型和努力度想清楚是同一个旋钮的两端，是入门时最重要的一件事。

最后补一句工程师视角的总结：模型 = 队伍里每个人的能力天花板（聘谁）；努力度 = 这次给这个人多少时间（加班 vs 早退）。让最贵的人坐在那里发呆，比让便宜的人加班更浪费——这是全文隐含但没明说的核心预算观。

关于本文

原文标题：Choosing a Claude model and effort level in Claude Code 原文作者：Lydia Hallie，Claude Code 团队技术员工 发布日期：2026 年 7 月 7 日 阅读时间：5 分钟 原文链接：https://claude.com/blog/claude-model-and-effort-level-in-claude-code

译者注

1. 文中出现的「Claude Fable」为 Anthropic 原文使用的命名，未在公开 API 中出现，亦无公开文档确认其含义。本文保留原文不做翻译。
2. 「effort level」译为「努力度」并括注英文——这是 Anthropic 在 Claude Code 里的一个旋钮命名，对应训练时被注入权重的"行为倾向"，不是简单的"思考时间"。
3. 「weights」译为「权重」，对应模型推理时的矩阵参数——Claude Code 用户侧的所有 prompt、skill、CLAUDE.md 都不会改写这些数字。
4. 7x token 是原文示意图标注的数字，原文强调"在简单任务上 Claude 不会为了凑 effort 而硬膨胀用量"。
5. 文中的图示曲线为示意，非真实基准测试数据。

译后记

这篇文章对中文工程读者的最大价值，是它用工程师熟悉的"系统机制"语言重新讲了"模型 vs 努力度"——而不是常见的那种"越大越好"或"看心情调"的玄学表述。它把"模型"还原成"权重矩阵"、把"努力度"还原成"训练时被注入的行为倾向"、把"token"还原成"循环次数 × 每 token 价格"——这种拆解对日常选型、计费理解、以及排查"为什么这次这么贵"都直接有用。