核心要点：

• Claude 模型选择决定了所使用的固定权重集合，或者说模型整体的能力范围。虽然可以给模型提供上下文或进行引导，但模型整体的知识库和能力是固定的。
• 努力水平不仅仅意味着“思考时间”。它控制着 Claude 为处理你的请求所投入的总工作量，包括读取的文件数量、使用的工具数量，以及在向你汇报进展之前所执行的步骤数量。
• 对于更常规的任务，选择较小的模型；对于更复杂或更模糊的任务，选择较大的模型。从每个模型的默认努力水平开始，并根据你从事的工作类型（而非逐项任务）将其调整为一个通用偏好。
• 如果 Claude 拥有所有相关上下文，明确尝试过但仍然出错，那说明需要选择一个能力更强的模型。如果 Claude 因跳过了某个文件、没有运行测试、或在重构中途放弃而出错，那就选择更高的努力水平。

Claude Code 努力水平与模型选择

Claude Code 提供了两个看似都能“让答案更好”的设置：模型设置和努力水平。你可能会认为，像 Claude Fable 5 这样更大的模型能比 Claude Sonnet 产生更智能的输出，而更高的努力水平意味着 Claude 在回答前会思考更久。

第一个假设是正确的。根据行业标准基准测试，我们最大的模型能力更强。

但努力水平不仅仅意味着“思考时间”。努力水平控制着 Claude 为处理你的请求所投入的总工作量。这确实包括模型思考的时间，但也包括：

• 它读取了多少个文件；
• 它进行了多少验证；
• 以及在向你汇报之前，它在一个多步骤任务中推进到了什么程度。

在更高的努力水平下，Claude 会在向你回报之前采取更多这些行动（例如，读取文件、运行测试和二次检查）。在较低的努力水平下，它宁愿向你询问更多上下文，也不愿自己花费 token 去搞清楚问题。

模型选择的工作原理

当你按下回车键时，Claude Code 会将你的消息与系统提示词、工具定义、你的 CLAUDE.md 文件、对话历史以及上下文中的任何文件组合在一起。所有这些都会作为一个请求发送到 API。

不过，模型并不会以纯文本形式看到这些内容。服务器上发生的第一件事就是 token 化：文本被分割成多个片段，每个片段都被映射到一个固定词汇表中的整数上，这个词汇表是模型在训练时使用的。`const` 可能映射到 1978，`await` 可能映射到 4293。从这一步开始，你的提示词就是一个整数数组了。

模型的任务是接受这个数组，并预测下一个 token 是什么。它通过计算词汇表中每个 token 的概率，并从最高概率的 token 中选取来完成预测。在 `const x = await` 之后，一个训练良好的模型会对 `fetch` 给出很高的概率（非常可能），而对 `banana` 给出接近零的概率（几乎不可能）。

将你的输入 token 转化为这些概率的是权重（也称为参数）。这些是组织成大型矩阵的数十亿个数字。为了预测一个 token，模型会将你的输入通过这些矩阵运行，经历一长串的矩阵乘法运算，并在最后读出概率值。权重中存储着模型“知道”的一切。

每个模型的权重都是在训练过程中设定的，当你发送请求时，它们已经是只读的了。你的提示词、你的 CLAUDE.md 文件或者你的上下文都不会改变它们。（如果你遇到过“推理”这个词，它的意思就是：在训练完成后，以权重固定不变的方式使用模型。）

Claude 关于 TypeScript、流行框架、地道 Go 语言或任何其他通用编程知识的一切，都是在训练时编码到那些模型权重中的。

你的提示词和上下文仍然可以引导预测（将你的真实代码放在 Claude 面前就是一种引导，而且效果很好），但它们不会对权重本身添加任何内容。

如果某个库在模型训练时不存在，它就不会在权重中。你可以把文档放在上下文里，Claude 会使用它们，但那是引导，而不是教授知识。Claude 的回应只会受到那个请求的影响；底层模型并未保留这些信息。

因此，当 Claude 自信地调用一个不存在的 API（模型幻觉）时，那是权重根据训练模式生成一个看起来合理的模型 token 序列，而不是一次失败的查找。

那么，更换模型实际上做了什么？它切换了处理你请求的那组冻结权重。

模型不会一次性生成整个答案。它会预测一个模型 token，将其追加到序列中，然后重新运行整个计算来获取下一个 token。200 个 token 的响应需要 200 次独立的权重遍历。你的大部分等待时间和输出成本都来自这个循环。

因此，模型设置决定了哪些权重处理你的请求，也决定了每个输出 token 的成本。

它不决定的是生成多少个 token。对于相同的提示词，这个数字可能变化很大，取决于 Claude 决定做多少工作。

这就是努力级别所控制的内容：Claude 决定为每个回合做多少工作。

努力级别的工作原理

当 Claude Code 在处理任务时，它生成的 token 分为几类：

• 思考：你在操作之前和操作之间看到的流式传输的推理过程。
• 工具调用：命名工具（如 Read 或 Edit）及其参数的结构化代码块，Claude Code 随后会解析并执行这些工具调用。
• 给你的文本：计划、进度更新以及最后的总结。

这些都来自同一个循环的普通输出 token，按相同费率计费。例如，思考 token 的生成方式与其他输出 token 完全一样，并且在该轮次的后续部分保留在上下文中。

当 Claude 转而编写代码时，它之前的推理就像它读取过的文件一样，成为输入的一部分。

投入程度如何改变这一切？投入程度作为请求的一部分与你的提示词一同发送给模型。模型经过训练，能够理解在每个投入程度下该如何表现，而这种学到的行为被固化在冻结的权重中。

当你的请求到达时，投入程度是模型响应的又一个输入，其方式与模型响应你的提示词文本相同。这设定了 Claude 的行为，决定了它在认为任务完成之前需要达到的彻底性和确定性。

这在每一轮中都会得到考虑，并导致生成更多 token 以产生更高置信度的答案。

在更高的投入程度下，Claude 通常会先创建一个计划，而投入程度会影响该计划的深度和广度。然而，计划并非固定不变。随着 Claude 从自身行动中接收结果，它会更新已取得的进展以及对累积结果的确定性。

因此，当包含三个假设的调试计划中的第一步发现了错误，那么“调查假设 2 和 3”可能就不再是必要的行动。Claude 通常会明确地说：“第一次检查找到了它，所以不需要剩下的检查了”，然后跳过后续步骤。你在 Claude Code 中可以看到这种情况：任务列表在运行过程中被修改。

Claude 在更高的投入程度下会更容易倾向于反复检查额外的假设或验证正确性，但它在处理简单任务时通常不会人为地增加使用量。事实上，我们的团队在模型训练期间非常关注“过度思考”的问题，因为它会降低效率。

选择投入程度

我们的建议是，对于大多数任务，你应该使用模型默认的投入级别。默认值是 Claude 会根据大多数人愿意为某任务花费的 token 量来调整其 token 使用量的级别。

可以把投入理解为一种手动调整，用来控制 Claude 工作的强度和时长。当你对任务的彻底性或速度有强烈偏好时（基于你的领域或工作类型），可以特意选择它。请将其视为一种通用偏好，而非针对每个任务逐一调整的决策。

以下是一些实用洞察，可能有助于你在 Claude Opus 4.8 上线后做出选择：在我们的测试中，我们发现，对于相同任务，使用 Opus 4.8 的默认投入设置时，其产生的效果比使用 Opus 4.7 默认投入设置更好，而 token 消耗量大致相同。

Claude 出错时该如何调整

当 Claude 出错时，你的第一反应不应该是去调整某个旋钮，而是检查你提供的上下文。你的提示词是否过于模糊？Claude 是否连接了正确的工具？是否配备了正确的技能？

如果你在某个本不需要高投入的任务上提高投入，问题往往出在上游：你的上下文、你的 CLAUDE.md，或者任务的范围界定。

但假设你已经提供了清晰的上下文，Claude 仍然出错，那么要问自己的问题是：是它努力不够，还是它知识不足？

模型层面：问题太难了

当问题确实困难时，选择更大的模型。例如：微妙的 bug、不熟悉的领域或架构决策这类问题。对于较小的模型，无论你提供多少上下文，它都可能自信地给出错误答案，此时更大的模型会更有帮助。

更大的模型也更擅长处理模糊性，而针对执行步骤给出明确指令，则是在较小模型上取得更好效果的方案。

当工作属于常规性任务时，选用较小的模型。例如，你能精确描述的编辑、机械性的改动，或者对已在上下文中的代码提出问题。没必要为任务不需要的能力付费。如果 Claude 拥有所有相关上下文、明确尝试过但仍然出错，那么这就是一个信号，提示该选用更大的模型。如果你正在使用较大的模型，而工作已持续常规一段时间，降级选用较小模型会提高速度，通常还能降低成本，同时不影响输出质量。

努力程度：Claude 没有足够努力

如果 Claude 因跳过某个文件、没有运行测试或没有复核自己的成果而出错，则选择更高的努力程度。这在你将努力程度设置为低于模型默认值的情况下最为相关。

努力程度、模型与 token 消耗

那么模型选择、努力程度和 token 消耗三者如何相互作用？这取决于任务类型。

在相同努力程度下处理常规工作时，两个模型通常都能正确完成。较大的模型会通过额外的验证步骤消耗更多 token，且每个 token 单价更高。这就是为什么在常规任务中切换到较小的模型，能在不牺牲质量的前提下真正节省成本。

在更困难、多步骤的工作中，情况则不同。较小的模型必须逼近自身能力极限，反复迭代消耗资源；而较大的模型能用更少的步骤达到同样的质量水平。

使用较大模型每 token 的成本更高，但在那些确实会令较小模型感到吃力的任务上，每个任务的总成本反而可能更低。此外更重要的是，较大的模型能够完成较小模型即使设置最高努力程度也无法完成的任务。

这一点在 Fable 上最为突出。在处理长流程、多步骤任务时，它拉开的最大差距。在我们的测试中，它完成了 Opus 和 Sonnet 在任何努力程度下都无法企及的任务。同时它的每 token 成本也最高，这也是将其保留给真正需要的任务的另一个原因。

上述图表的关键在于：努力程度决定了 Claude 愿意沿着曲线走多远，但这并不意味着 Claude 必须走那么远才能完成任务。

另一个细微之处是：努力程度影响 token 消耗，但并不限制它。系统中唯一的硬性上限是 max_tokens，一旦达到该值，响应会被中途截断。这是一种比较粗暴的手段，主要适用于 API 开发者。而像任务预算或在提示词中要求 Claude 简短回答这类软性控制，则是更有用的工具。它们充当模型经过训练会遵循的指引——当模型接近限制时会倾向于结束任务——而不是一道它撞上去的墙。

从默认设置开始，再根据需要调整旋钮

大多数情况下，你无需考虑这两个设置。当结果不理想时，问问自己：“是 Claude 了解不够，还是它尝试得不够？”然后按需调整。

本文由 Claude Code 团队技术成员 Lydia Hallie 撰写。

使用 Claude 改变您组织的运营方式