Claude Code 给了你两个看起来都能“让答案变好”的设置：模型，以及 effort 级别。但它们到底会怎样影响输出？你又该怎么判断，是该换一个模型，还是只调整 effort 级别？
我们很容易以为，选择 Fable 这样更大的模型会比 Sonnet 得到更聪明的输出，而更高的 effort 级别只是意味着 Claude 在回答前想得更久。
第一个判断是对的。按照行业标准基准测试，我们最大的模型能力更强。
但 effort 不只是“思考时间”。Effort 控制的是 Claude 为你的请求总体投入多少工作。这包括它思考多久，也包括：
- 它会读多少文件；
- 它会做多少验证；以及
- 它在回来向你确认前，会把一个多步骤任务推进到什么程度。
在更高的 effort 下，Claude 会在回到你面前之前，更多地执行这些动作（读文件、跑测试、反复检查）。在更低的 effort 下，它更倾向于向你索要更多上下文，而不是花 token 自己把事情弄明白。
模型选择是怎样工作的
要理解模型设置到底控制什么，最好从最开始讲起：从你按下回车的那一刻开始。
Claude Code 会把你的消息、系统提示词、工具定义、你的 CLAUDE.md、对话历史，以及上下文里的所有文件组装在一起。所有这些内容会作为一个请求发送给 API。
不过，模型并不会以普通文本的形式看到这些内容。服务器端首先发生的是 tokenization：文本被切分成片段，每个片段都会映射到模型训练时所用固定词表中的一个整数。const 可能映射到 1978，await 可能映射到 4293。从这一步开始，你的提示词就是一个整数数组。
模型的工作，是接收这个数组，并预测下一个 token 是什么。它会为词表里的每个 token 计算一个概率，然后从排在前面的候选里选出一个。在 “const x = await” 之后，一个训练良好的模型会给 “fetch” 很高的概率（非常可能），给 “banana” 接近于零的概率（几乎不可能）。
把你的输入 token 转换成这些概率的，是 weights（也叫 parameters）：数十亿个数字，被组织在大型矩阵里。为了预测一个 token，模型会让你的输入经过这些矩阵（一长串矩阵乘法），最后读出概率。模型“知道”的一切，都存在这些 weights 里。
每个模型的 weights 都是在训练期间确定的；到你发送请求时，它们已经是只读的。你的提示词、CLAUDE.md 或上下文都不会改变它们。如果你见过 inference 这个词，它的意思就是这个：在训练完成后使用模型，并且 weights 是固定的。
Claude 关于 TypeScript、流行框架，或者其他任何通用编程知识所知道的东西，都是在训练时被编码进这些 weights 的。
你的提示词和上下文仍然可以引导预测。把你的真实代码放到 Claude 面前就是一种引导，而且效果很好。不过，这并不会给 weights 本身增加任何东西。
如果某个库在模型训练时还不存在，它就不在 weights 里。你可以把文档放进上下文，Claude 会使用这些文档，但那是引导，不是教会。Claude 的回答只会在这一次请求里受到影响，底层模型并没有保留下任何东西。
当 Claude 自信地调用一个并不存在的 API（幻觉）时，那是 weights 根据训练模式生成了一串看起来合理的 token，而不是一次查询失败。
那么，改变模型实际改变了什么？它会换成另一组冻结的 weights 来处理你的请求。
模型不是一次性生成完整答案。它会预测一个 token，把它追加到序列里，然后再次运行整套计算来得到下一个 token。一个 200-token 的回答，就是 200 次单独穿过 weights 的计算。大部分等待时间（以及输出成本）都发生在这个循环里。
模型设置决定哪一组 weights 来处理你的请求，也决定每个输出 token 的价格。
它不决定的是：会生成多少 token。对于同一个提示词，这个数字可能差异很大，取决于 Claude 决定投入多少工作。
这正是 effort 控制的东西。
Effort 是怎样工作的
Claude Code 在处理任务时，生成的 token 会落在几个类别里：
- **思考：**你在动作之前和动作之间看到的流式推理内容。
- **工具调用：**命名 Read 或 Edit 这类工具及其参数的结构化块，随后由 Claude Code 解析并执行。
- **给你的文本：**计划、进度更新、最后的总结。
这些都是来自同一个循环的普通输出 token，并按同样的费率计费。比如，thinking token 的生成方式和其他输出 token 完全一样，并且会在这一轮剩余过程中留在上下文里。
到 Claude 开始写代码时，它前面的推理已经和它读过的文件一样，成为输入的一部分。
那么 effort 会怎样改变这一切？Effort 级别会作为请求的一部分发送给模型，和你的提示词一起发送。模型在训练中学会了在每个 effort 级别下应该如何表现，而这种学到的行为被烘焙进了冻结的 weights 里。
当你的请求到达时，effort 只是模型会响应的另一个输入，就像它会响应你的提示词文本一样。它设定了 Claude 在认为任务完成之前，需要做到多彻底、达到多大把握。这个因素会在每一轮里被权衡，而达到更高的把握需要更多 token。
在更高的 effort 级别下，Claude 往往会先制定计划，而 effort 级别会影响这个计划的深度和广度。但计划并不是固定不变的。随着 Claude 从自己的动作中拿到结果，它会更新自己对进展程度以及累积结果把握程度的判断。
如果一个包含三种假设的调试计划，在第 1 步就找到了 bug，那么“继续调查假设 2 和 3”可能就不再必要。Claude 通常会明确说出这一点（例如“第一次检查已经找到了问题，所以剩下的检查不需要了”），然后跳到后面。在 Claude Code 里，你会看到任务列表在运行中途被修改，就是这个过程。
更高的 effort 确实会让 Claude 更可能做复查，例如验证已经找到的答案，或者继续看一看原本可以跳过的那些假设。不过，它通常不会只是因为 effort 级别调高了，就在简单任务上人为增加用量。“过度思考”是我们团队在模型训练期间特别关注的问题，因为它会降低效果。
如何选择 effort 级别
对大多数任务来说，使用模型默认的 effort 级别。默认级别是这样一个水平：Claude 会把 token 使用量调整到大多数人在一个任务上愿意花费的程度。
可以把 effort 看作对 Claude 工作强度和工作时长的手动覆盖。当你基于自己的领域或工作类型，对彻底性或速度有强烈偏好时，再有意识地使用它，并把它当成一种总体偏好，而不是每个任务都要临时决定的选项。
在 Opus 4.8 发布后有一个实用观察：在我们的测试里，同一个任务上，Opus 4.8 的默认 effort 设置，用大致相同数量的 token，比 Opus 4.7 的默认 effort 设置得到更好的结果。
Claude 出错时该改什么
当 Claude 做错时，你的第一反应不应该是改设置，而应该是检查你给它的上下文。你的提示词是不是太含糊？Claude 有没有连接到正确的工具？它有没有合适的 skills？
如果你在一个本不该需要更高 effort 的任务上提高 effort，问题通常在上游：在你的上下文、CLAUDE.md，或者任务范围界定方式里。
但假设你已经给了清楚的上下文，Claude 还是做错了。这时你要问自己的问题是：它是不够努力，还是知道得不够？
模型：问题太难了
当问题真的很难时，选择更大的模型，例如微妙的 bug、不熟悉的领域、架构决策。当较小的模型无论你给多少上下文都会自信地犯错时，你需要的就是更大的模型。
更大的模型也更擅长处理模糊性。对于较小的模型，给出引导执行的具体指令，是更容易成功的做法。
当工作是例行性的，就选择较小的模型：你能精确描述的编辑、机械性修改、关于已经在上下文里的代码的问题。没有必要为任务不需要的能力付费。
如果 Claude 已经拥有所有相关上下文，明显也尝试过，但仍然做错了，这就是该选择更大模型的信号。如果你已经在用更大的模型，而这段时间做的都是例行工作，降到小模型会提高速度，通常也会降低成本，同时不影响输出质量。
Effort：Claude 不够努力
如果 Claude 做错是因为没有足够努力——跳过了一个文件、没有跑测试，或者没有复查自己的工作——就选择更高的 effort 级别。如果你选择了低于模型默认值的 effort 级别，这一点尤其相关。
专家、行家和通才
我喜欢用这样一种方式理解这两个设置：Fable 是能处理几乎没人能处理的问题的专家，Opus 是行家，Sonnet 是非常优秀的通才。Effort 级别决定的是，他们会在你的任务上花多少时间。
低 effort 的 Opus，就像你和一位对你这类问题有深厚经验的行家聊了五分钟。他们带来的是你的代码库里没有的知识：他们以前见过的模式、他们知道要检查的坑，以及只有解决过大量类似问题才会拥有的那种经验。但五分钟意味着快速读一遍你的代码，而不是仔细扫过每个文件。
高 effort 的 Sonnet，是有一整个下午时间的通才。它很会写代码，会把所有东西都读一遍，把项目跑起来，复查自己的工作，最后充分理解你的具体代码。
Fable 是在所有人都卡住时你会请来的专家。哪怕是在低 effort 下，它也会发现其他人看不到的东西。这种识别能力也是你支付最高价格的原因，所以值得把它留给真正需要它的任务。
这些模型没有哪一个普遍“更好”。模型设置大致决定能力有多强；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 保持简短，通常更有帮助。它们是模型受训练会遵循的引导（它接近限制时会尝试收尾），而不是撞上去就停止的一堵墙。
Effort 改变的是 Claude 做多少工作。模型改变的是 Claude 知道什么。
当你对结果不满意时，在碰这两个设置之前，先检查上下文：给 Claude 清楚的提示词、正确的工具和 skills，以及一种验证自己工作的方式。
如果 Claude 仍然做错，问问自己：它是知道得不够，还是不够努力？知道得不够是模型问题，不够努力是 effort 问题。
本文作者是 @lydiahallie，Claude Code 团队技术人员。