在 Claude Code 中选择 Claude 模型与 effort 级别
原文链接：claude.com/blog/claude...
原文作者：Lydia Hallie
2026 年 7 月 7 日（原文发布日期）
要点摘要：
- Claude 模型选择决定使用哪一套固定权重，也就是模型的整体能力区间。虽然可以为模型提供上下文或进行引导（steering），但模型的整体知识库与能力边界是既定的。
- effort 的含义远不止「思考时间」。它控制 Claude 在处理你的请求时整体投入多少工作，包括读取多少文件、使用多少工具，以及在与你会合之前走多少步。
- 常规任务选较小模型，复杂或模糊任务选较大模型。每种模型先从默认 effort 级别起步，再按你所做工作的类型作为一般偏好来微调，而不是逐个任务临时决定。
- 若 Claude 已掌握所有相关上下文、显然已经尽力尝试却仍然出错，这是该换更强模型的信号。若 Claude 因跳过某个文件、未运行测试，或在重构中途半途而废而出错，则应提高 effort 级别。
Claude Code 的 effort 级别与模型选择
Claude Code 提供两个看似能「让答案更好」的设置：模型设置与 effort 级别。你可能会预期，像 Claude Fable 5 这样的较大模型比 Claude Sonnet 输出更聪明，而更高的 effort 级别意味着 Claude 在回答前思考更久。
第一个假设是对的。根据行业标准基准测试，我们最大的模型能力更强。
但 effort 的含义远不止「思考时间」。effort 级别控制 Claude 在处理你的请求时整体投入多少工作。这确实包括模型思考多久，但也包括：
- 读取多少文件；
- 进行多少验证；以及
- 在多步任务中推进多远才回来与你确认。
在更高 effort 下，Claude 会在回来找你之前采取更多这类行动（例如读文件、跑测试、复核）。在较低 effort 下，它更愿意向你索要更多上下文，而不是自己花 token 去琢磨。
模型选择如何工作
当你按下回车时，Claude Code 会把你的消息与系统提示词、工具定义、你的 CLAUDE.md、对话历史以及上下文中的任何文件组装在一起。所有这一切作为一次请求发送到 API。
Claude Code 拥有的一切都被打包进一次 API 请求。在服务端，文本在到达模型之前就会先被分词（tokenize）。
不过，模型看到的并不是纯文本。服务端发生的第一件事是分词（tokenization） ：文本被拆成片段，每个片段映射到模型训练时使用的固定词表中的一个整数。const 可能映射到 1978，await 可能映射到 4293。从此刻起，你的提示词就是一个整数数组。
分词器把文本拆成片段，并将每个片段映射到固定词表中的整数。顶行每个块都会变成其 token ID（底行）；所示 ID 仅为示意。
模型的任务是接收该数组并预测下一个 token。它通过为词表中每个 token 计算概率 并从排名靠前的候选中选取来实现这一点。在 const x = await 之后，训练良好的模型会给 fetch 很高概率（非常可能），给 banana 接近零（几乎不可能）。
模型的预测是对词表中每个 token 的概率。排名最高的猜测与无关选项之间的差距极大。
把你的输入 token 变成这些概率的，是权重 （也称为参数）。这是组织成大矩阵的数十亿个数字。要预测一个 token，模型会让输入通过这些矩阵------一长串矩阵乘法------并在末尾读出概率。权重就是模型所「知道」的一切所在。
每个模型的权重在训练期间设定，到你发送请求时它们已是只读的。 你的提示词、CLAUDE.md 或上下文中的任何内容都不会改变它们。（若你遇到过 inference 这个词，它的含义就是如此：在训练完成后、权重固定的情况下使用模型。）
提示词进去，概率出来。中间的权重不会改变。
Claude 关于 TypeScript、流行框架、地道 Go，或任何其他通用编程知识的一切，都在训练时被编码进这些权重。
你的提示词与上下文仍然可以引导 预测（把真实代码放在 Claude 面前就是引导，而且效果很好），但它们不会向权重本身添加任何内容。
若某个库在模型训练时不存在，它就不在权重里。你可以把文档放进上下文，Claude 会使用它们，但那是引导 ，不是教学。Claude 的回复只会在该次请求中受影响；底层模型并未保留这些信息。
因此，当 Claude 自信地调用一个不存在的 API（幻觉）时，那是权重根据训练模式生成一段看起来合理的 token 序列，而不是一次失败的查找。
那么更换模型实际做了什么？它切换哪一套冻结权重来处理你的请求。
模型不会一次生成完整答案。它预测一个 token，将其追加到序列中，然后再次运行整套计算以得到下一个。200 个 token 的回复意味着对权重进行 200 次独立遍历。这个循环占用了你大部分等待时间与输出成本。
序列每步恰好增长一个 token。模型每次都会重读整个数组以预测接下来是什么。
因此，模型设置 决定哪套权重处理你的请求，也决定每个输出 token 的成本。
它不能决定的是会生成多少 token。对同一提示词，这个数字可能差异很大，取决于 Claude 决定做多少工作。
这正是 effort 级别 所控制的：Claude 决定每轮做多少工作。
effort 如何工作
当 Claude Code 处理任务时，它生成的 token 大致分为几类：
- 思考（Thinking）：你在动作之前与之间看到流式输出的推理。
- 工具调用（Tool calls） ：命名工具（如
Read或Edit）及其参数的结构化块，Claude Code 随后解析并执行。 - 给你的文本：计划、进度更新、末尾总结。
这些都是同一循环中的普通输出 token，按相同费率计费。例如，思考 token 的生成方式与其他输出 token 完全相同，并在该轮剩余时间内留在上下文中。
当 Claude 继续写代码时，它先前的推理会像它读过的文件一样成为输入的一部分。
Claude 的全部输出都是 token。思考、工具调用与给你的文本都来自同一循环。
effort 如何改变这一切？effort 级别作为请求的一部分与提示词一并发送给模型。模型经过训练，能理解在每个 effort 级别应如何表现，这种习得行为被烘焙进冻结权重。
当你的请求到达时，effort 级别是模型响应的又一个输入，就像它响应你的提示词文本一样。这设定 Claude 在认为任务完成之前需要做到多细致、多确定。
这在每一轮都会被考虑，并且会产生更多 token 以给出更高置信度的答案。
同一提示词，两种 effort 级别。高 effort 路径大约生成 7 倍 token 以达到更高置信度的答案。
在更高 effort 级别，Claude 往往先制定计划，effort 级别影响该计划的深度与广度。不过，计划并非冻结不变。随着 Claude 从行动中收到结果，它会更新已取得的进展以及对累积结果的确定程度。
因此，当三假设调试计划的第 1 步找到 bug 时，「调查假设 2 和 3」可能不再是必要行动。Claude 通常会明确说明，「第一次检查就找到了，所以剩余检查不需要了」，然后跳过。你在 Claude Code 中会看到任务列表在中途被修订时发生这种情况。
在更高 effort 级别，Claude 更倾向于复核额外假设或验证正确性，但通常不会在简单任务上人为抬高用量。事实上，我们团队在模型训练期间非常关注「过度思考（overthinking）」，因为它会降低有效性。
如何选择 effort 级别
我们的建议是：对大多数任务，应使用该模型的默认 effort 级别。默认级别是 Claude 会根据大多数人在一项任务上愿意花费的程度来缩放 token 用量的级别。
把 effort 视为手动覆盖，用来调节 Claude 工作有多用力、持续多久。当你基于领域或工作类型对细致程度或速度有强烈偏好时，再有意识地选择它。更应把它当作一般偏好，而非逐个任务的决定。
Claude Opus 4.8 发布后，以下实践经验或许对你有指导意义：在我们的测试中，对同一任务使用 Opus 4.8 的默认 effort 设置，与使用 Opus 4.7 的默认 effort 设置相比，大约以相同 token 数量产出更好结果。
Claude 出错时该改什么
当 Claude 出错时，你的第一反应不应该是去拧某个旋钮，而是检查你提供的上下文。提示词是否太模糊？Claude 是否连接了正确的工具？是否配备了正确的技能？
若你在本不需要 高 effort 的任务上提高 effort，修复往往在上游：你的上下文、CLAUDE.md，或任务范围如何界定。
但假设你已提供清晰上下文，Claude 仍然出错，你要问自己的问题是：它是没有足够努力 ，还是没有足够了解？
两个问题，一个后备方案。用这个启发式方法选起点，而非硬性规则。
模型：问题太难了
当问题确实很难时，选较大模型。例如隐蔽 bug、陌生领域或架构决策等问题。在较小模型无论你给多少上下文都自信地错的情况下，较大模型很有帮助。
较大模型也更擅长处理歧义，而对较小模型来说，给出指导执行的具体指令往往是更成功的配方。
当工作是常规性质时，选较小模型。例如你能精确描述的编辑、机械性变更，或关于已在上下文中的代码的问题。没有理由为任务不需要的能力付费。
若 Claude 拥有所有相关上下文且显然已经尽力尝试却仍然出错，这是该选较大模型的信号。若你已在较大模型上且工作已常规化一段时间，降档会提高速度，通常还能降低成本，而不影响输出质量。
effort：Claude 不够努力
若 Claude 因跳过文件、未运行测试或未复核工作而出错，应提高 effort 级别。若你选择的 effort 级别低于该模型默认值，这一点最为相关。
Fable 与 Opus 与 Sonnet：专家、行家与通才
我喜欢用这样一种方式理解两个设置的关系：Fable 是见过几乎没人见过的问题的专家，Opus 是行家，Sonnet 是非常优秀的通才。effort 级别决定他们中的任何一个在你的任务上花多少时间。
低 effort 的 Opus 就像与一位对你这类问题有深厚经验的专家聊五分钟。他们带来代码库中不存在的知识：他们见过的模式、他们知道要检查的坑，只有解决过大量类似问题才会有的那种东西。但只给五分钟意味着快速扫一眼你的代码，而不是仔细研读。
高 effort 的 Sonnet 就像给一位非常优秀的通才整个下午。他们会读完一切、运行东西、复核工作，最终彻底理解你的具体代码。他们较少带来的是「我确切见过这个」的识别能力。
即使低 effort，Fable 也是那位扫一眼大家都卡住的地方仍能发现别人发现不了的东西的专家。这种识别能力正是你付费最多的部分，因此值得留给真正需要的任务。
这些没有哪一种普适地更好。模型设置大致是能力有多强 ；effort 设置大致是工作有多细致。大多数真实任务需要两者兼有。
effort、模型与 token 消耗
那么模型选择、effort 与 token 消耗如何相互作用？取决于任务。
在相同 effort 级别的常规工作上，两种模型通常都能做对。较大模型会以更高的每 token 价格，用额外验证步骤消耗更多 token。这就是为什么在常规阶段降到较小模型能在不损失质量的情况下节省真金白银。
曲线仅供说明，展示的是两种模型都能快速完成的单一简单任务。它们不代表真实基准数据。
在更困难的多步工作上，等式不同。较小模型必须硬磨到能力极限，消耗大量迭代，而较大模型用更少步骤达到相同质量门槛。
你为较大模型支付更高的每 token 价格，但在真正考验较小模型的任务上，每项任务的总成本可能反而更低。而且更重要的是，较大模型能完成较小模型即使在最高 effort 设置下也无法完成的任务。
这一点在 Fable 上最为明显。在长、多步工作上它领先最多。在我们的测试中，它完成了 Opus 与 Sonnet 在任何 effort 级别都无法达到的工作。它的每 token 成本也最高，这是另一个原因------把它留给真正需要的工作。
曲线仅供说明，展示的是足够困难、足以考验两种模型的单一任务。它们不代表真实基准数据。
上述图表的关键点是，effort 级别选择 Claude 愿意沿曲线走多远 ，但再次强调，这并不意味着 Claude 需要走那么远才能完成任务。
另一个细微之处：effort 塑造 token 消耗但不限制它。系统中唯一的硬上限是 max_tokens，命中时会在中途截断回复。这是生硬的手段，主要与 API 开发者相关。更柔和的控制，如 task budgets 或在提示词中要求 Claude 简短一些，是更有用的工具。它们作为模型被训练去遵循的指引------接近上限时会倾向于收尾任务------而不是一道撞上去的墙。
从默认设置起步，需要时再拧旋钮
大多数时候，你不该想着这两个设置。当结果未达预期时，问：「Claude 是不够了解，还是不够努力？」然后按需调整。
本文由 Claude Code 团队技术员工 Lydia Hallie 撰写。