Claude Code 中，模型与推理强度的选择
Claude Code 提供了两项看起来都能“让回答变得更好”的设置：模型与推理强度。但它们究竟会怎样影响输出？什么时候应该换一个模型，什么时候只需调整推理强度？
人们很容易认为，选择 Fable 这样更大的模型，会比 Sonnet 得到更聪明的输出；而提高推理强度，只是让 Claude 在回答前多思考一会儿。
第一个判断是正确的。按照业界通用 benchmark 的结果，我们规模最大的模型确实能力更强。
但推理强度不只是“思考时间”。它控制的是 Claude 为你的请求总体投入多少工作。其中既包括思考多久，也包括：
- 读取多少文件
- 做多少验证
- 在回来向你确认之前，会把一个多步骤任务推进到什么程度
推理强度越高，Claude 在回复你之前，通常会执行更多这类操作，例如读取文件、运行测试和反复检查。推理强度较低时，它更倾向于向你索取更多上下文，而不是消耗 token 自行把问题调查清楚。
模型选择如何运作
要理解模型设置究竟控制什么，不妨从最开始，也就是你按下回车的那一刻说起。
Claude Code 会将你的消息与系统提示词、工具定义、CLAUDE.md、对话历史，以及当前上下文中的文件组合起来。这些内容会作为一个完整请求发送至 API。
不过，模型并不会以纯文本形式看到这些内容。服务器首先会执行分词器：文本被拆分成若干片段，每个片段再映射为模型训练时固定词汇表中的一个整数。比如，const 可能映射为 1978，await 可能映射为 4293。从这一刻开始，你的提示词就变成了一组整数构成的数组。
模型要做的，就是接收这组数组，并预测下一个 token。它会为词汇表中的每个 token 计算概率，再从概率最高的一批候选中选择一个。面对“const x = await”，训练充分的模型会给“fetch”分配很高的概率，因为它非常可能出现；而“banana”的概率则接近于零，因为它几乎不可能出现在这里。
真正把输入 token 转换为这些概率的，是权重，也叫参数：由数十亿个数字组成，并被组织在大型矩阵中。为了预测一个 token，模型会让输入依次通过这些矩阵，执行一长串矩阵乘法，最后读取输出端的概率。模型所“知道”的一切，都存放在这些权重里。
每个模型的权重都在训练阶段确定。当你开始发送请求时，这些权重已经是只读的。无论是你的提示词、CLAUDE.md，还是上下文，都无法改变它们。你可能听说过“推理”这个词，它指的就是：模型训练结束后，在权重保持不变的情况下使用模型。
Claude 对 TypeScript、流行框架，以及其他通用编程知识的了解，都是在训练期间被编码进这些权重中的。
你的提示词和上下文依然可以引导模型的预测。把真实代码放到 Claude 面前，就是一种引导，而且通常非常有效。但这并不会向权重本身添加任何新内容。
假如某个库在模型训练时还不存在，那么它就不会存在于权重中。你可以把文档放入上下文，Claude 也会利用这些文档，但这只是引导，而不是教学。文档只会影响当前这一次请求的回答，底层模型并不会保留这些知识。
当 Claude 信心满满地调用一个根本不存在的 API，也就是出现幻觉时，本质上是权重根据训练中见过的模式，生成了一段看起来合理的 token 序列，而不是某次查询失败了。
那么，更换模型究竟改变了什么？它实际上是更换了处理你请求的那一组固定权重。
模型也不会一次生成完整回答。它会先预测一个 token，把它追加到当前序列中，然后重新执行整套计算，以预测下一个 token。一段包含 200 个 token 的回答，就意味着输入需要依次通过权重 200 次。你的大部分等待时间，以及输出费用，正是消耗在这个循环上。
模型设置决定由哪一组权重处理你的请求，也决定每个输出 token 的价格。
但它并不决定最终会生成多少 token。即使提示词完全相同，Claude 根据自己决定投入的工作量不同，生成的 token 数量也可能相差很大。
而这正是推理强度所控制的内容。
推理强度如何运作
Claude Code 处理任务时，生成的 token 大致可以分为几类：
- 思考：你在执行操作之前，以及不同操作之间看到的流式推理内容。
- 工具调用：包含 Read、Edit 等工具名称及其参数的结构化区块，随后由 Claude Code 解析并执行。
- 发送给你的文本：计划、进度更新，以及最后的总结。
它们本质上都是由同一套生成循环产生的普通输出 token，并且费率相同。例如，思考 token 的生成方式与其他输出 token 完全一致，而且会在当前轮次剩余过程中继续保留在上下文里。
等 Claude 开始编写代码时，它之前的推理已经成为输入的一部分，就像它刚刚读取过的文件一样。
那么，推理强度是如何改变这一过程的？推理强度会作为请求的一部分发送给模型，与提示词一同传入。模型在训练时已经学会了不同推理强度下该如何行动，而这种行为模式就编码在固定权重中。
当请求抵达时，推理强度只是模型需要响应的另一个输入，和你的提示词文本没有本质区别。它会影响 Claude 在认为任务已经完成之前，需要做到多么周全，以及达到多高的 确定性。每一轮处理中，模型都会把这一要求纳入权衡；而要达到更高的信心，通常需要生成更多 token。
在较高推理强度下，Claude 往往会先制定计划，而推理强度会影响计划的深度与覆盖范围。但这份计划并不是一成不变的。随着 Claude 从各项操作中获得结果，它会持续更新自己对任务进度以及当前结论可靠性的判断。
假设包含三种排查假设的调试计划，在第 1 步就找到了 bug，那么“继续调查假设 2 和 3”可能已经没有必要。Claude 通常会明确说明这一点，例如“第一次检查已经发现问题，因此无需继续剩余检查”，然后直接进入后续步骤。你在 Claude Code 中看到任务列表在执行过程中被修改，就是这种机制的体现。
提高推理强度，确实会让 Claude 更有可能进行复查，例如验证已经找到的答案，或继续调查原本可以跳过的 假设。不过，它通常不会只因为推理强度被调高，就在简单任务上刻意增加使用量。团队在模型训练期间会特别关注“过度思考”，因为这反而会降低实际效果。
如何选择推理强度
对大多数任务而言，使用模型的默认推理强度即可。默认值代表 Claude 会把 token 使用量控制在大多数人处理这类任务时愿意承担的范围内。
你可以把推理强度理解为一项手动调节项，用来控制 Claude 工作得多深入、持续多久。当你的业务领域或工作类型对严谨程度或速度有明确偏好时，再有意识地调整它。更适合把它视为一种总体偏好，而不是每个任务都要重新决定的参数。
关于 Opus 4.8 发布后还有一点值得注意：在我们的测试中，面对同一个任务，Opus 4.8 的默认推理强度与 Opus 4.7 的默认推理强度消耗的 token 大致相同，但前者的结果更好。
Claude 出错时，该调整什么
Claude 给出错误结果时，你的第一反应不应该是修改设置，而应该先检查你提供的上下文。提示词是否过于模糊？Claude 是否连接到了正确的工具？它是否具备所需的 skills？
如果一个本不该需要高推理强度的任务，必须提高推理强度才能完成，那么问题通常出在更上游：上下文本身、CLAUDE.md，或任务范围的定义方式。
不过，假设你已经提供了清晰的上下文，Claude 还是做错了。这时真正该问的是：它是没有足够 努力，还是它 知道 的不够多？
模型：问题本身太难
当问题确实很难时，例如涉及隐蔽 bug、陌生领域或 architecture decision，应当选择更大的模型。如果较小模型无论获得多少上下文都仍然 自信地给出错误答案，那么更大的模型才是你需要的。
更大的模型也更擅长处理模糊性。使用较小模型时，能够明确指导执行过程的具体指令，通常更容易得到理想结果。
如果工作内容比较常规，例如可以精确描述的编辑、机械式修改，或围绕已经放入上下文的代码进行提问，就应该选择更小的模型。任务不需要额外能力时，没有理由为这些能力付费。
如果 Claude 已经获得全部相关上下文，也明显认真尝试过，却仍然回答错误，这就是应当切换到更大模型的信号。反过来，如果你正在使用更大的模型，而最近一段时间处理的都是常规工作，那么切换到较小模型通常可以提高速度、降低成本，而且不会影响输出质量。
推理强度：Claude 做得还不够充分
如果 Claude 的错误来自投入不足，例如漏读文件、没有运行测试，或没有复查结果，就应该选择更高的推理强度。当你当前选择的推理强度低于模型默认值时，这一点尤其重要。
专家型人才、资深专家与通才
我喜欢用下面这种方式理解这两项设置：Fable 是能解决几乎无人能处理的问题的专家型人才，Opus 是资深专家，而 Sonnet 是能力很强的通才。推理强度决定他们愿意在你的任务上花多少时间。
低推理强度下的 Opus，就像你只能与一位经验深厚的专家交流五分钟。他熟悉与你的问题相似的情况，能够带来代码库中没有的知识：过去见过的模式、知道该留意的陷阱，以及只有解决过大量同类问题后才能积累的经验。但五分钟只够快速浏览代码，不足以逐个文件认真检查。
高推理强度下的 Sonnet，则像是一位愿意花整个下午的通才。它很擅长编程，会阅读全部内容、运行程序、反复核查，并最终对你的具体代码形成非常深入的理解。
Fable 则是所有人都束手无策时才会请来的专家。即使推理强度较低，它也能看见其他模型发现不了的问题。你所支付的高额费用，正是为了这种识别能力，因此最好把它留给真正需要它的任务。
它们并不存在普遍意义上的“谁更好”。模型设置大致决定能力有多强，推理强度则大致决定工作有多周全。大多数真实任务都需要两者兼具。
推理强度、模型与 token 消耗
那么，模型选择、推理强度与 token 消耗究竟如何相互影响？答案取决于任务本身。
在同一推理强度下处理常规工作时，无论模型大小，通常都能给出正确结果。更大的模型会以更高的单 token 价格，消耗更多 token 来执行额外验证。因此，在连续处理常规任务时切换到较小模型，确实可以在不损失质量的前提下节省成本。
面对更困难的多步骤任务，情况则会反过来。较小模型必须在能力边界附近反复尝试，消耗大量 iteration；而较大模型能用更少的步骤达到相同的质量标准。
虽然较大模型的单 token 价格更高，但当任务确实逼近较小模型的能力极限时，较大模型的单任务总成本反而可能更低。更重要的是：有些任务无论把较小模型的推理强度调到多高，它都无法完成，而较大模型可以。
这一差异在 Fable 身上最为明显。面对长流程、多步骤工作时，它拉开的差距最大。在我们的测试中，Fable 能够完成 Opus 和 Sonnet 在任何推理强度下都无法完成的任务。与此同时，它的单 token 成本也最高，这同样说明它应该被保留给真正需要这类能力的工作。
上图真正关键的一点是：推理强度决定 Claude 愿意沿着曲线走多远，但这并不意味着它为了完成任务一定需要走到那么远。
最后，推理强度会影响 token 消耗，但不会对其形成硬性限制。系统中唯一的硬上限是 max_tokens。达到该值时，回答会在生成过程中被直接截断。但这是一种相当生硬的控制方式，主要与 API 开发者有关。
相比之下，task budgets 这类柔性控制，或直接在提示词中要求 Claude 保持简洁，通常更有帮助。它们不是模型无法跨越的墙，而是模型在训练中学会遵循的指导：当接近限制时，它会倾向于主动收尾。
推理强度改变 Claude 愿意做多少工作。模型改变 Claude 具备多少知识与能力。
当你对结果不满意时，在修改这两项设置之前，先检查上下文：给 Claude 清晰的提示词、正确的工具与 skills，以及能够验证自身工作的手段。
如果 Claude 仍然出错，就问自己：它是 不知道得足够多，还是 做得不够充分？知识或能力不足是模型问题；投入不足则是推理强度问题。
本文作者为 @lydiahallie，Claude Code 技术团队的成员。