Claude Code 中的 model 与 effort：知道得更多，还是尝试得更充分

Claude Code 中的 model 与 effort：知道得更多，还是尝试得更充分

原文：*Model and effort in Claude Code: knowing more vs. trying harder*

作者：ClaudeDevs (@ClaudeDevs)

发布时间：2026-07-08

互动数据：💬 195 🔁 464 ❤️ 5227 🔖 6927 👀 727884

---

Claude Code 有两个看起来都能“让答案变好”的设置：model（模型）与 effort（投入程度）。但它们究竟怎样影响输出？什么时候应该换模型，什么时候只需调整 effort？

人们很容易认为，选择 Fable 这样的大模型会比 Sonnet 得到更聪明的结果，而提高 effort 只意味着 Claude 在回答前会多思考一会儿。

第一个判断没错。按照行业标准基准测试，我们最大的模型确实能力更强。

但 effort 的含义不只是“思考时间”。它控制的是 Claude 为你的请求总共会做多少工作。其中当然包括思考多久，但还包括：

• 读取多少文件；

• 做多少验证；

• 在回来向你确认之前，会把一个多步骤任务推进多远。

effort 越高，Claude 在回复你之前就越可能多做这些动作：读文件、跑测试、反复核对。effort 越低，它越倾向于向你索取更多上下文，而不是花 token 自己把问题查清楚。

---

model 设置怎样工作

要理解 model 设置实际控制什么，最好从最开始讲起——也就是你按下回车的那一刻。

Claude Code 会把你的消息与 system prompt、工具定义、CLAUDE.md、对话历史，以及当前上下文中的文件组装在一起，作为一次请求发给 API。

*Claude Code 拥有的一切都会被打包进同一个 API 请求。在服务器端，这些文本会先被分词，然后才进入模型。*

不过，模型从来不会以普通文本的形式看到这些内容。请求到达服务器后，第一步是分词（tokenization）：文本被切成一个个片段，每个片段再映射到模型训练时所用固定词表里的一个整数。比如，const 可能对应 1978，await 可能对应 4293。从这里开始，你的 prompt 就成了一串整数数组。

*Tokenizer 把文本拆成片段，再把每个片段映射成固定词表中的一个整数。上排的每个片段会变成下排对应的 token ID；图中的 ID 仅用于说明。*

模型的工作，就是接收这串数组并预测下一个 token。它会为词表中的每个 token 计算一个概率，再从概率最高的一组候选里选择。看到“const x = await”之后，一个训练良好的模型会给“fetch”很高的概率，而给“banana”接近于零的概率。

*模型会为词表中的每个 token 预测一个概率。最高概率候选与毫不相关的词之间，差距极大。*

把输入 token 变成这些概率的，是权重（weights，也叫参数）：数十亿个数字被组织成大型矩阵。为了预测一个 token，模型会让输入经过这些矩阵，也就是执行一长串矩阵乘法，最后读取输出概率。模型“知道”的一切，都存在这些权重里。

每个模型的权重都在训练期间确定。等你真正发起请求时，权重已经只读。你的 prompt、CLAUDE.md 或上下文都无法改变它们。如果你见过 inference 这个词，它说的就是这件事：训练完成、权重固定之后，再使用模型进行推理。

*Prompt 进去，概率出来，中间的权重不会改变。*

Claude 对 TypeScript、常见框架以及其他通用编程知识的掌握，都是在训练阶段编码进这些权重的。

当然，prompt 和上下文仍然可以引导预测。把真实代码放到 Claude 面前，就是引导，而且效果很好。但这样做不会向权重本身添加任何东西。

如果某个库在模型训练时还不存在，它就不可能存在于权重中。你可以把文档放进上下文，Claude 也能使用它，但这是引导，不是教学。文档只会影响这一次请求中的回答，底层模型并没有把它记住。

当 Claude 很自信地调用一个根本不存在的 API，也就是发生幻觉时，并不是查找失败，而是权重根据训练中见过的模式，生成了一串“看起来合理”的 token。

所以，更换 model 实际做了什么？它会换掉处理本次请求的那一套冻结权重。

模型不是一次性生成完整答案。它每次只预测一个 token，把它追加到序列末尾，再重新运行整套计算来预测下一个。一个 200 token 的回答，需要让输入经过权重 200 次。你的大部分等待时间，以及输出成本，都花在这个循环里。

*序列每一步只增长一个 token。为了预测下一个 token，模型每次都会重新读取整个数组。*

model 设置决定由哪套权重处理请求，也决定每个输出 token 的单价。

它不决定的是：最终会生成多少 token。即使 prompt 完全相同，这个数字也可能相差很大，取决于 Claude 决定为任务做多少工作。

而这正是 effort 控制的部分。

---

effort 怎样工作

Claude Code 执行任务时，生成的 token 大致分为几类：

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

• 工具调用： 结构化数据块，其中写着 Read、Edit 之类的工具名及其参数，Claude Code 会解析并执行它们。

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

这些都是同一个生成循环产生的普通输出 token，计费单价也相同。比如思考 token，与其他输出 token 的生成方式完全一样，而且会在本轮剩余过程中保留在上下文里。

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

*Claude 的全部输出都是 token：思考、工具调用和给你的文本，都来自同一个生成循环。*

那么，effort 怎样改变这一切？effort 级别会作为请求的一部分发送给模型，与 prompt 同时到达。模型已经通过训练学会在不同 effort 下如何行动，而这种行为就编码在冻结权重里。

请求到达时，effort 只是模型要响应的另一个输入，就像 prompt 文本一样。它设定 Claude 在认为任务完成之前，需要做到多详尽、达到多高的确定性。模型会在每一轮都权衡这个要求，而达到更高置信度通常需要更多 token。

*同一个 prompt、两种 effort。高 effort 路径大约生成 7 倍 token，以得到置信度更高的答案。*

在较高 effort 下，Claude 往往会先制定计划，而 effort 也会影响计划的深度和广度。但计划并不是一经写下就不能改变。Claude 每拿到一次行动结果，都会更新自己对进度和累计结果确定性的判断。

假设一个包含三种假设的调试计划，在第一步就找到了 bug，那么“继续调查假设二和假设三”可能已经没有必要。Claude 通常会明确说出来，例如“第一项检查已经定位问题，剩余检查无需继续”，然后直接跳到后面的步骤。你会在 Claude Code 中看到任务列表在执行中途被修订，原因就在这里。

较高 effort 确实会让 Claude 更愿意复核，例如验证刚刚找到的答案，或者继续查看原本可以跳过的其他假设。但它通常不会仅仅因为 effort 被调高，就在简单任务上人为拉高用量。“过度思考”会降低实际效果，也是我们团队在模型训练中特别关注的问题。

---

怎样选择 effort

对大多数任务来说，使用模型默认的 effort 即可。默认值代表 Claude 会把 token 用量调整到大多数人愿意为一项任务投入的水平。

可以把 effort 看成一个手动覆盖项，决定 Claude 工作得多认真、持续多久。当你的领域或工作类型对完整性、速度有明确偏好时，再有意识地调整它；最好把它当成一种总体偏好，而不是每个任务都重新决定一次。

在 Opus 4.8 发布后，还有一点实际说明：在我们的测试中，Opus 4.8 的默认 effort 与 Opus 4.7 的默认 effort 处理同一任务时，token 用量大致相当，但前者结果更好。

---

Claude 做错时，应该改什么

Claude 出错时，你的第一反应不应该是调整设置，而应该先检查自己给了它什么上下文。Prompt 是否太模糊？Claude 是否连接了正确的工具？它是否拿到了合适的 skill？

如果一个本来不该需要高 effort 的任务，非得提高 effort 才能完成，问题通常在更上游：上下文、CLAUDE.md，或任务范围的定义方式。

但假设你已经给了清晰的上下文，Claude 仍然出错。此时真正该问的是：它是没有充分尝试，还是知道得不够多？

Model：问题本身太难

当问题确实很难时，应选择更大的模型，例如隐蔽 bug、陌生领域或架构决策。如果无论提供多少上下文，小模型都仍然自信地给出错误答案，那就需要更大的模型。

大模型也更擅长处理歧义。使用小模型时，明确而具体、能直接指导执行的指令，成功率会更高。

如果工作很常规，就选更小的模型：你能精确描述的编辑、机械性改动，或者询问已经放进上下文的代码。任务不需要的能力，没有理由付费购买。

如果 Claude 已经拿到所有相关上下文，也确实认真尝试过，却仍然做错，这就是换大模型的信号。反过来，如果你正在使用大模型，而工作已经连续一段时间都很常规，切换到小模型会更快，通常也能降低成本，并且不影响输出质量。

Effort：Claude 尝试得不够充分

如果 Claude 出错是因为做得不够，例如漏读文件、没跑测试、没有复核，就应该提高 effort。尤其当你此前把 effort 调到模型默认值以下时，这种调整最有意义。

---

专才、专家与通才

我喜欢用下面这个类比来理解这两个设置：Fable 是能处理几乎无人能解问题的专才，Opus 是专家，Sonnet 则是一位非常优秀的通才。effort 决定他们愿意在你的任务上花多少时间。

低 effort 的 Opus，就像你只得到一位资深专家的五分钟。他对同类问题有深厚经验，能带来代码库里根本不存在的知识：曾见过的模式、知道要排查的陷阱，以及解决大量相似问题后才会形成的经验。但五分钟只够快速浏览代码，不够逐个文件认真检查。

高 effort 的 Sonnet，则像一位拥有整个下午的通才。它很会写代码，也会把材料读完、把程序跑起来、反复检查，最终对你的具体代码形成深入理解。

Fable 是所有人都卡住时才请来的专才。即使在低 effort 下，它也能发现别人看不到的东西。你付出的最高价格，很大一部分正是为了这种识别能力，所以应该把它留给真正需要的任务。

没有哪个选项在所有情况下都“更好”。model 大致决定能力有多强，effort 大致决定做得有多彻底。大多数真实任务，两者都需要一些。

---

effort、model 与 token 消耗

那么，model、effort 和 token 消耗究竟怎样相互作用？答案取决于任务。

对于常规工作，在 effort 相同的情况下，大模型和小模型通常都能做对。大模型会多做一些验证步骤，消耗更多 token，而且每个 token 的价格更高。因此，在一段连续的常规工作中切换到小模型，可以真正省钱，同时不损失质量。

*曲线仅用于说明，展示的是一个足够简单、两个模型都能迅速完成的单项任务，并不代表真实基准测试数据。*

面对更难的多步骤任务，情况会反过来。小模型必须逼近自身能力上限，反复迭代；大模型则用更少步骤就能达到同样的质量标准。

大模型的每个 token 更贵，但在真正超出小模型舒适区的任务上，单项任务的总成本反而可能更低。更重要的是，有些任务大模型能够完成，而小模型即使把 effort 调到最高也做不到。

Fable 上的差距最明显。面对长期、多步骤工作，它领先得最远。在我们的测试中，它完成了一些 Opus 和 Sonnet 在任何 effort 下都无法完成的任务。它的 token 单价也最高，这同样说明应该把它留给真正需要的工作。

*曲线仅用于说明，展示的是一个难到足以挑战两个模型的单项任务，并不代表真实基准测试数据。*

上面两张图的关键是：effort 决定 Claude 愿意沿曲线走多远，但不代表它必须走到那里才能完成任务。

最后，effort 会影响 token 消耗，却不会限制它。系统中唯一的硬上限是 max_tokens。达到上限时，响应会在生成途中直接截断；这种方式很粗暴，主要与 API 开发者有关。更柔和的控制方式，例如任务预算，或直接在 prompt 里要求 Claude 简洁一些，通常更有帮助。它们是模型经过训练会遵循的指导——接近限制时，模型会主动准备收尾——而不是突然撞上的一堵墙。

---

effort 改变 Claude 会做多少工作，model 改变 Claude 知道什么。

如果你对结果不满意，在碰任何设置之前先检查上下文：给 Claude 清晰的 prompt、正确的工具和 skill，以及验证自己工作的办法。

如果 Claude 还是做错，就问自己：它是知道得不够多，还是尝试得不够充分？知道得不够是 model 问题，尝试得不够充分是 effort 问题。

---

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