转译：Claude Code 中的模型与投入等级：知道得更多，还是更肯下功夫？

原文：[Model and effort in Claude Code: knowing more vs. trying harder](ClaudeDevs on X: "https://t.co/dxoI9Nna86" / X)by@ClaudeDevs（Claude官方）原文中注明、本文由@lydiahallie撰写

Claude Code 有两个看起来都会「让答案变得更好」的设置：模型和投入等级。但它们究竟分别怎样影响输出？又该如何判断，是该换一个模型，还是只需要调高投入等级？

人们很容易以为：选 Fable 这样更大的模型，得到的结果一定比 Sonnet 更聪明；而更高的投入等级，只是让 Claude 在回答前多想一会儿。

第一个判断是对的。根据行业通用基准测试，我们最大的模型确实具备更强的能力。

但投入等级不只意味着「思考时间」。它控制的是 Claude 为你的请求总体做多少工作，其中包括思考多久，也包括：

• 读取多少文件；

• 做多少验证；以及

• 在回来向你确认之前，把一个多步骤任务推进到什么程度。

在更高投入等级下，Claude 会在回复前完成更多这类动作，比如读文件、运行测试和反复核查。在更低投入等级下，它更倾向于向你索取更多上下文，而不是自行花费 Token 去弄清问题。

模型选择到底控制了什么

要理解模型设置真正控制的东西，最好从你按下回车的那一刻说起。

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 或上下文都不会改变权重。你可能听过「推理」这个词，它指的就是：训练已经结束，在权重固定的情况下使用模型。

你的提示词输入，概率输出，中间的权重不会改变。

Claude 对 TypeScript、流行框架或任何其他通用编程知识的理解，都在训练时被编码进这些权重。

你的提示词和上下文仍然可以引导预测。把真实代码放在 Claude 面前，就是一种引导，而且效果非常好。但这不会给权重本身增加任何东西。

如果某个库在模型训练完成后才出现，它就不在权重里。你可以把文档放进上下文，Claude 会利用它们，但这属于引导，而不是教会。Claude 的回答只会在那一次请求中受到影响，底层模型并没有把新知识记下来。

当 Claude 自信地调用一个根本不存在的 API 时，也就是出现幻觉时，发生的是：权重依据训练模式生成了一串看似合理的 Token，而不是某次查询失败了。

那么，更换模型究竟改变了什么？它会换上一套不同的、冻结的权重来处理你的请求。

模型不会一次性生成完整答案。它先预测一个 Token，将它追加到序列中，再重新运行整套计算来得到下一个 Token。一段 200 Token 的回答，要穿过权重完成 200 次独立计算。这个循环构成了你大部分的等待时间，也是输出成本的主要来源。

序列每一步只增长一个 Token。模型每次都要重新读取整个数组，才能预测下一个 Token。

模型设置决定哪套权重来处理你的请求，也决定每个输出 Token 的价格。

但它并不决定会生成多少 Token。对于同一个提示词，这个数可以相差很大，取决于 Claude 决定为完成任务做多少工作。

这正是投入等级控制的部分。

投入等级如何发挥作用

Claude Code 处理任务时，生成的 Token 大致可分为几类：

• 思考：你会看到它在行动之前和行动之间流式输出的推理过程。

• 工具调用：结构化的内容块，写明像 Read 或 Edit 这样的工具及其参数，随后由 Claude Code 解析并执行。

• 给你的文本：计划、进度更新，以及最后的总结。

它们全都是同一个循环生成的普通输出 Token，按同一费率计费。以思考 Token 为例，它们和其他输出 Token 的生成方式完全一致，并且会在这一轮的剩余时间里留在上下文中。

等 Claude 开始写代码时，它先前的推理已经成为输入的一部分，就像它读过的文件一样。

Claude 的所有输出都是 Token。思考、工具调用和给你的文本，都由同一个循环生成。

那么，投入等级怎样改变这一切？投入等级会作为请求的一部分发送给模型，与提示词并列。模型在训练中已经学会如何响应不同投入等级，这种行为模式也固化在冻结的权重中。

请求抵达后，投入等级只是模型需要响应的另一个输入，和提示词文本一样。它规定了 Claude 在认定任务完成前，需要做到多全面、达到多高的确定性。模型会在每一轮都权衡这一点，而更高的确定性需要更多 Token 才能达到。

同一个提示词，两种投入等级。高投入路径会生成大约 7 倍的 Token，以获得确定性更高的答案。

在较高投入等级下，Claude 常会先制订计划，而投入等级会影响计划的深度和广度。但计划不会被固定下来。Claude 从行动中获得结果后，会持续更新自己对进度和现有结论可靠性的判断。

例如，在一个有三个假设的调试计划中，如果第一步就找到了 bug，那么「继续调查假设 2 和假设 3」可能已经没有必要。Claude 通常会明确说明这一点，例如「第一次检查已经找到问题，因此不需要再检查其余假设」，然后直接跳到下一步。你会在 Claude Code 中看到这种情况，任务清单会在运行中被修订。

更高的投入等级确实会让 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 开发者有关。更柔和的控制方式，比如 任务预算，或在提示词中要求 Claude 保持简洁，通常更有用。它们是模型受训练后会遵循的引导，模型会在接近限制时尝试收尾，而不是一堵撞上去的墙。

投入等级改变 Claude 做多少工作，模型改变 Claude 知道什么。

当你对结果不满意时，在动任何一个设置前，先检查上下文：给 Claude 清晰的提示词、正确的工具和技能，以及一条能让它验证自身工作的路径。

如果 Claude 仍然做错，就问自己：它是不知道得不够，还是没有尝试得不够？不知道得不够，是模型问题；尝试得不够，是投入等级问题。

本文由 Claude Code 团队技术人员 @lydiahallie 撰写。

原文链接：[Model and effort in Claude Code: knowing more vs. trying harder](ClaudeDevs on X: "https://t.co/dxoI9Nna86" / X)