Claude Code 提供了两个设置，它们似乎都能“让答案更好”：模型和努力程度。但这两个设置对输出结果到底有什么影响？你又该如何判断是应该换一个不同的模型，还是仅仅调整努力程度？
人们很容易认为，选择像 Fable 这样更大的模型，会比 Sonnet 产生更智能的输出，而更高的努力程度只是意味着 Claude 在回答前思考更久。
第一个假设是对的。根据行业标准基准测试，我们最大的模型能力更强。
但努力程度不仅仅意味着“思考时间”。努力程度控制着 Claude 为你的请求所付出的总体工作量。这包括它思考的时间，但也包括：
- 它读取了多少文件；
- 它做了多少验证；以及
- 在向你汇报之前，它在一个多步骤任务中推进了多远。
在更高的努力程度下，Claude 在返回给你结果之前，会采取更多这些行动（读取文件、运行测试、再次检查）。在较低的努力程度下，它宁愿向你询问更多上下文，也不愿花费 tokens 自行解决问题。
模型选择的工作原理
要理解模型设置实际上控制了什么，最好从头开始，从你按下回车键的那一刻开始说起。
Claude Code 会将你的消息与系统提示、工具定义、你的 CLAUDE.md、对话历史记录以及上下文中的任何文件组合在一起。所有这些内容都作为一个请求发送到 API。
Claude Code 拥有的所有内容都被打包到一个 API 请求中。在服务器端，文本在到达模型之前就被分词了。
不过，模型从来不会以纯文本形式看到这些内容。服务器上发生的第一件事就是分词：文本被分割成小块，每个小块被映射到模型训练时使用的固定词汇表中的一个整数。\const\ 可能映射到 1978，\await\ 可能映射到 4293。从这时起，你的提示就是一个整数数组。
分词器将你的文本分割成小块，并将每个小块映射到固定词汇表中的一个整数。顶行的每个块都变成其 token ID（底行）；显示的 ID 仅供说明。
模型的工作是接收这个数组并预测下一个 token 是什么。它通过计算词汇表中每个 token 的概率并从顶部选择一个来实现。在 "const x = await" 之后，一个训练有素的模型会给予 "fetch" 很高的概率（非常可能），而给予 "banana" 接近零的概率（完全不可能）。
模型的预测是其词汇表中每个 token 的概率。最佳猜测与不相关猜测之间的差距是巨大的。
将你的输入 token 转化为这些概率的是权重（也称为参数）：数十亿个数字组织成的大型矩阵。为了预测一个 token，模型会通过那些矩阵（一长串矩阵乘法）运行你的输入，并在最后读取概率。权重是模型所“知道”的一切所在。
每个模型的权重在训练期间设置，当你发送请求时，它们是只读的。你的提示、你的 CLAUDE.md 或你的上下文中的任何内容都不会改变它们。如果你遇到过 inference（推理）这个词，它的全部含义就是：在训练完成后使用模型，权重固定不变。
你的提示进入，概率出来。中间的权重不会改变。
Claude 所知道的关于 TypeScript、流行框架或任何其他通用编程知识的一切，都在训练时被编码进了这些权重中。
你的提示和上下文仍然可以 引导 预测。将你的真实代码放在 Claude 面前就是一种引导，而且效果很好。然而，这并不会向权重本身添加任何内容。
如果一个库在模型训练时不存在，它就不在权重中。你可以将文档放入上下文，Claude 会使用它们，但那是引导，而不是学习。Claude 的响应仅受该次请求的影响，但底层模型没有保留任何东西。
当 Claude 自信地调用一个不存在的 API（幻觉）时，那是权重产生了一个从训练模式看来似乎合理的 token 序列，而不是一个失败的查找。
那么，改变模型实际上做了什么？它交换了哪一组冻结的权重来处理你的请求。
模型不会一次性生成整个答案。它预测一个 token，将其附加到序列中，然后再次运行整个计算来获取下一个 token。一个 200 token 的响应需要 200 次单独的权重传递。这个循环是你大部分等待时间（以及你的输出成本）的来源。
序列每一步只增长一个 token。模型每次重新读取整个数组以预测下一个内容。
模型设置决定了哪组权重处理你的请求，也决定了每个输出 token 的成本。
它不决定的是生成多少个 token。对于相同的提示，这个数字可能变化很大，具体取决于 Claude 决定做多少工作。
这正是努力程度所控制的。
努力程度的工作原理
当 Claude Code 在处理一个任务时，它生成的 token 属于几个类别：
- 思考： 你在操作之前和之间看到的推理过程。
- 工具调用： 结构化的块，命名了像 Read 或 Edit 这样的工具及其参数，然后由 Claude Code 解析并执行。
- 给你的文本： 计划、进度更新、最后的总结。
这些都是来自同一个循环的普通输出 token，按相同费率计费。例如，思考 token 的生成方式与其他输出 token 完全相同，并且在该轮次剩余时间内保持在上下文中。
当 Claude 继续编写代码时，它之前的推理已经成为输入的一部分，就像它读取的文件一样。
Claude 的所有输出都是 token。思考、工具调用和给你的文本都是从同一个循环生成的。
那么，努力程度是如何改变这一切的呢？努力程度是作为请求的一部分发送给模型的，与你的提示一起。模型被训练理解在每个努力程度下应该如何表现，并且这种习得的行为被固化在冻结的权重中。
当你的请求到达时，努力程度只是模型响应的另一个输入，就像它响应你的提示文本一样。它设定了 Claude 在认为任务完成之前需要达到的彻底程度和确定程度。这在每一轮中都会被权衡，更高的置信度需要更多的 token 才能达到。
相同的提示，两种努力程度。高努力路径生成大约 7 倍的 token 以达到更自信的答案。
在更高的努力程度下，Claude 通常会先制定一个计划，努力程度会影响该计划的深度和广度。但计划并非一成不变。当 Claude 从行动中获取结果时，它会更新自己关于进展和累积结果确定程度的认知。
当三个假设调试计划中的步骤 1 发现错误时，“调查假设 2 和 3”可能就不再必要了。Claude 通常会明确说明这一点（例如，“第一次检查找到了它，因此不需要剩余检查”）并跳过。当任务列表在运行中途被修改时，你在 Claude Code 中可以看到这种情况。
更高的努力程度确实使 Claude 更有可能进行双重检查，例如验证它找到的答案，或者仍然调查它本可以跳过的假设。然而，它通常不会仅仅因为努力程度调高了就在一个简单的任务上人为地增加使用量。“过度思考”是我们团队在模型训练期间特别关注的问题，因为它会降低有效性。
选择努力程度
对于大多数任务，使用模型的默认努力程度。默认是 Claude 将其 token 使用量扩展到大多数人在任务上愿意花费的水平。
将努力程度视为一个手动覆盖选项，控制 Claude 工作的努力程度和时间长短。当你在自己的领域或所做的工作类型上，对彻底性或速度有强烈偏好时，有意地使用它，并将其视为一个通用偏好，而不是逐个任务的决定。
Opus 4.8 发布后的一个实际注意事项：在我们的测试中，Opus 4.8 的默认努力设置产生的效果更好，而 token 消耗量与 Opus 4.7 在相同任务上的默认努力设置大致相同。
当 Claude 出错时该调整什么
当 Claude 出错时，你的第一反应不应该是更改设置。而应该是查看你提供给它的上下文。你的提示是否太模糊？Claude 是否连接了正确的工具？它是否具备正确的技能？
如果你在一个本不需要那么高努力程度的任务上增加努力，修复通常在上游：在你的上下文、你的 CLAUDE.md 中，或者任务的范围界定上。
但假设你已经给出了清晰的上下文，而 Claude 仍然出错。你需要问自己的问题是：它是不够努力，还是知识不足？
模型：问题太难
当问题确实很难时，选择更大的模型，比如微妙的 bug、不熟悉的领域、架构决策。当较小的模型无论你提供多少上下文都自信地犯错时，你需要的正是更大的模型。
更大的模型也更擅长处理歧义。在较小的模型上，指明执行方式的具体指令是成功更好的方法。
当工作是常规性的时，选择较小的模型：你可以精确描述的编辑、机械性的更改、关于已在上下文中的代码的问题。没有理由为任务不需要的能力付费。
如果 Claude 拥有所有相关的上下文，明显努力了，但仍然出错；这就是选择更大模型的信号。如果你已经在使用更大的模型，并且工作在一段时间内都是常规性的，降低模型级别通常会提高速度并降低成本，而不会影响输出质量。
努力程度：Claude 不够努力
如果 Claude 因为不够努力而做错了，选择更高的努力程度：跳过文件、没有运行测试、或者没有再次检查其工作。这在你选择了低于模型默认值的努力程度时最为相关。
专家、行家与通才
我喜欢思考这两个设置的一种方式是：Fable 是能处理几乎没人能解决的问题的专家，Opus 是行家，而 Sonnet 是个非常优秀的通才。努力程度决定了他们中的任何一个在你的任务上花费多少时间。
低努力程度的 Opus 就像与一位对你这类问题有深厚经验的专家交谈五分钟。他们带来了你代码库中不存在的知识；他们以前见过的模式、他们知道要检查的陷阱，只有解决过大量类似问题才能获得的那种经验。但五分钟意味着快速浏览你的代码，而不是仔细检查每一个文件。
高努力程度的 Sonnet 是拥有整个下午的通才。他们非常擅长编码，他们会阅读所有内容，运行测试，检查工作，并最终彻底理解你的具体代码。
Fable 是当其他人都卡住时你召唤的专家。即使在低努力程度下，他们也能发现别人发现不了的东西。这种识别能力也是你付出最高代价的原因，所以值得把它留给需要它的任务。
这些都不是普遍“更好”的。模型设置大致是有多强；努力设置大致是有多彻底。大多数实际任务两者都需要一些。
努力程度、模型与 token 消耗
那么，模型选择、努力程度和 token 消耗是如何相互作用的呢？这取决于任务。
在相同努力程度下的常规工作中，较大和较小的模型通常都能正确完成。较大的模型会因为额外的验证步骤消耗更多 token，且每个 token 的价格更高。这就是为什么在常规阶段降低到较小的模型可以在不牺牲质量的情况下节省真金白银。
曲线仅供说明，显示的是一个足够简单、两个模型都能快速完成的任务。它们不代表真实的基准数据。
在更困难、多步骤的工作中，等式就翻转了。较小的模型必须努力达到其能力的极限，反复迭代，而较大的模型用更少的步骤就能达到相同的质量水平。
你为较大模型的每个 token 支付更多费用，但在那些真正考验较小模型的任务上，每个任务的总成本反而可能更低。更重要的是：较大的模型可以完成较小的模型无法完成的任务，即使是在最高努力程度设置下。
这在 Fable 上最为明显。在长时间、多步骤的工作中，它领先最多。在我们的测试中，它完成了 Opus 和 Sonnet 在任何努力程度下都无法完成的工作。它的每个 token 成本也最高，这是你将其保留给真正需要它的工作的另一个原因。
曲线仅供说明，显示的是一个足够困难、足以考验两个模型的任务。它们不代表真实的基准数据。
上面图表的关键点：努力程度决定了 Claude 愿意沿着曲线走多远。这并不意味着 Claude 需要走那么远才能完成任务。
最后，努力程度影响 token 消耗，但并不限制它。系统中唯一的硬性上限是 max_tokens，当达到上限时，它会中断响应，但它是一个生硬的工具，主要与 API 开发者相关。像 task budgets 这样的软性控制，或者在提示中要求 Claude 保持简洁，更有帮助。它们是模型被训练成遵循的指导（当接近限制时，它会寻求收尾），而不是它会撞上的墙。
努力程度改变了 Claude 做多少工作。模型改变了 Claude 知道什么。
当你对结果不满意时，在调整任何一个设置之前，先检查上下文：给 Claude 一个清晰的提示、正确的工具和技能，以及一种验证其自身工作的方法。
如果 Claude 仍然出错，问问自己：它是知识不足，还是不够努力？知识不足是模型问题，不够努力是努力程度问题。
本文由 @lydiahallie 撰写，她是 Claude Code 团队的技术人员。
