模型选择的原理
当你按下回车键，Claude Code 会将你的消息与系统提示、工具定义、你的 CLAUDE.md 文件、对话历史以及相关文件整合成一个请求发送到 API。
不过模型并不会直接看到纯文本，服务器端首先会进行分词（tokenization），将文本拆分成多个片段，并将每个片段映射为模型训练时使用的固定词汇表中的整数。例如，const 可能映射为1978，await 可能映射为4293。从此刻起，你的提示就变成了一个整数数组。
模型的任务是根据这个整数数组预测下一个 token。它会计算词汇表中每个 token 的概率，并从概率最高的选项中选择。比如在 "const x = await" 之后，一个训练良好的模型会给 "fetch" 很高的概率，而 "banana" 的概率几乎为零。
将输入的 token 转换为概率的是模型的权重（weights），也称为参数（parameters）。这些权重是数十亿个数字组成的大型矩阵。模型通过对输入进行一系列矩阵乘法运算，最终得到每个 token 的概率。权重中包含了模型“所知道”的所有信息。
每个模型的权重在训练时确定，发送请求时是只读的。 你的提示、CLAUDE.md 或上下文都不会改变这些权重。（所谓推理，就是指在训练完成后使用固定权重的模型。）
Claude 对 TypeScript、流行框架、惯用 Go 语言等编程知识的理解，都是在训练时编码进权重中的。
你的提示和上下文可以**引导（steer）**模型的预测，比如把你的真实代码放在前面就是一种引导，效果很好，但它们不会改变权重本身。
如果某个库在训练时不存在，权重中就不会包含它。你可以把文档放进上下文，Claude 会利用它们，但这仍是引导而非教学。Claude 的回答只会在当前请求中受影响，底层模型不会记住这些信息。
因此，当 Claude 自信地调用不存在的 API（即“幻觉”）时，那是权重基于训练模式生成了看似合理的 token 序列，而非查找失败。
那么，切换模型实际上意味着什么？就是更换哪一组固定权重来处理你的请求。
模型不会一次生成完整回答，而是逐个预测 token，追加到序列中，再重新计算下一个 token。一个 200 token 的回答就是 200 次权重计算循环。这也是等待时间和输出成本的主要来源。
因此，模型设置决定了哪组权重处理请求，也决定了每个输出 token 的成本。
但它不决定生成多少 token。生成的数量会因 Claude 决定投入多少工作量而大幅变化。
这就是**努力等级（effort level）**控制的内容：Claude 每轮决定投入多少工作量。
努力等级的工作机制
Claude Code 在执行任务时生成的 token 大致分为几类：
- 思考（Thinking）：你看到的推理过程，出现在动作前后。
- 工具调用（Tool calls）：结构化的代码块，调用如 Read 或 Edit 等工具及其参数，Claude Code 解析并执行。
- 对你的文本输出：计划、进度更新、总结等。
这些都是同一循环中的普通输出 token，按同样费率计费。例如思考 token 的生成方式与其他输出 token 一样，并且会保留在当前上下文中。
当 Claude 开始写代码时，之前的推理内容会作为输入的一部分，就像读取的文件一样。
努力等级作为请求的一部分发送给模型，与提示文本一起。模型在训练时学会了根据不同努力等级调整行为，这种行为被编码进固定权重。
请求到达时，努力等级是模型的一个输入，模型会根据它调整回答的彻底程度和确定性，决定任务完成的标准。
每轮都会考虑努力等级，结果是生成更多 token 以获得更高置信度的答案。
在较高努力等级下，Claude 通常会先制定计划，努力等级影响计划的深度和广度。但计划不是固定不变的，随着行动结果的反馈，Claude 会更新进展和对结果的确定性。
例如，三步假设调试计划的第一步找到问题后，后续步骤可能不再需要，Claude 会明确说明并跳过。
在高努力等级下，Claude 更倾向于多次验证和复查，但不会在简单任务上无谓增加使用量。团队在训练时也关注避免“过度思考”，因为那会降低效率。
如何选择努力等级
建议大多数任务使用模型的默认努力等级。默认等级会根据大多数用户对任务的期望自动调整 token 使用量。
努力等级相当于手动调节 Claude 工作的强度和时长。只有当你对彻底性或速度有明确偏好时，才应调整它。把它看作一种整体偏好，而非针对每个任务的细致调整。
根据 Claude Opus 4.8 的测试，使用默认努力等级时，Opus 4.8 在相似 token 数量下表现优于 Opus 4.7。
Claude 出错时的调整建议
当 Claude 出错时，首要不是调整参数，而是检查你提供的上下文是否清晰，提示是否明确，工具和技能是否匹配。
如果你在不需要的任务上提高努力等级，通常问题出在上下文、CLAUDE.md 或任务范围定义上。
假设上下文清晰，Claude 仍出错，你需要判断是它没尝试足够努力，还是它本身知识不足。
模型：问题太复杂
遇到真正复杂的问题时，选择更大的模型更合适，比如细微的 bug、不熟悉的领域或架构决策。更大模型能更好处理模糊性，而小模型更适合明确指令执行。
常规任务则适合小模型，比如精确描述的编辑、机械性修改或已有上下文中的代码问题。没必要为不需要的能力买单。
如果 Claude 有充分上下文且明显尝试过仍错，说明需要更大模型。反之，若任务简单且用大模型，切换到小模型能提升速度并降低成本，且不会影响质量。
努力等级：Claude 没有足够努力
如果 Claude 因跳过文件、不运行测试或不复查而出错，尝试提高努力等级。尤其当你选择了低于默认的努力等级时，这点尤为重要。
Fable、Opus 与 Sonnet：专家与通才的比喻
我喜欢这样理解两种设置的关系：Fable 是见过极少人见过问题的专家，Opus 是经验丰富的专家，Sonnet 是非常优秀的通才。努力等级决定他们花多少时间在你的任务上。
- 低努力的 Opus 就像和一位专家聊五分钟，他们带来代码库外的知识和经验，但时间有限，阅读不够细致。
- 高努力的 Sonnet 就像给一位通才整个下午，他们会仔细阅读、运行代码、复查，深入理解你的具体代码，但缺少“我以前见过这个”的直觉。
- 低努力的 Fable 是那个专家，即使时间短，也能发现别人忽略的关键点。这种识别能力是你付费最多的部分，适合真正需要的任务。
没有哪个模型绝对更好。模型设置大致代表能力，努力设置代表彻底程度。大多数任务需要两者兼顾。
努力等级、模型与 token 消耗的关系
模型选择、努力等级和 token 消耗如何相互作用，取决于任务性质。
对于常规任务，两个模型在相同努力等级下通常都能正确完成。大模型因额外验证步骤消耗更多 token 且单价更高，因此在常规任务中使用小模型能节省成本且不影响质量。
对于复杂多步骤任务，小模型需要多次迭代达到能力极限，而大模型能用更少步骤达到同样质量。
虽然大模型单个 token 价格更高，但在复杂任务中总成本可能更低，更重要的是大模型能完成小模型即使在最高努力等级下也无法完成的任务。
这在 Fable 上表现最明显，长任务中它领先最远。测试中它完成了 Opus 和 Sonnet 无法完成的工作，但它的 token 价格最高，因此应保留给真正需要的任务。
图中关键点是努力等级决定 Claude 愿意在曲线上走多远，但不代表必须走那么远才能完成任务。
另一个细节是努力等级影响 token 消耗，但不限制它。系统唯一硬限制是 max_tokens，当达到时会截断回答。这对 API 开发者更重要。更柔性的控制如任务预算或提示中要求简洁更实用，模型会据此尝试尽快完成任务，而非遇到硬墙。
从默认设置开始，再根据需要调整
大多数情况下，你无需关注这两个设置。当结果不理想时，问自己：“Claude 是知识不足还是努力不够？”然后针对性调整。
本文作者：Lydia Hallie，Claude Code 团队技术成员。
