笔者日常工作中一直在用 Claude Code，但在各项设置中，“model”和“effort”看起来都是调高就会变聪明，而对于实际上究竟改变了什么、怎么改变的，我长期以来都是模模糊糊地使用着。2026 年 7 月 9 日，Claude Code 团队的 Lydia Hallie 在官方开发者账号 @ClaudeDevs 上发布了一条帖子，从机制层面讲解了这两个设置的区别。本文以其内容为基础，并辅以 Anthropic 的 API 文档和 Claude Code 的文档加以梳理。以下所刊载的图示均出自该帖子（绘图：Anthropic）。
结论 — model 是“知道什么”，effort 是“工作多少”
| 设置 | 会变的 | 不会变的 |
|---|---|---|
| model | 负责响应的那一整套训练好的“权重”（＝知识与能力），以及每 token 的单价 | 生成的 token 数量 |
| effort | 一项任务上所花的工作量（思考的长度、读取的文件数量、验证的彻底程度） | 模型的知识与能力本身 |
原帖标题为 “Model and effort in Claude Code: knowing more vs. trying harder”（知道得更多，还是更努力），结论也凝聚在下面这一句话里。
Effort changes how much work Claude does. The model changes what Claude knows.
（effort 改变 Claude 工作多少；model 改变 Claude 知道什么）
以下依次来看每个设置分别作用于处理的哪个阶段。
model 的机制 — 把负责响应的“权重”整体替换的设置
按下 Enter 键后，Claude Code 会把消息正文与系统提示、工具定义、CLAUDE.md、对话历史以及上下文中的文件汇总在一起，作为一个 API 请求发送出去。model 和 effort 就是在这个请求中指定的参数。
图 1：所有输入都被打包进一个 API 请求，在服务器端分词后再交给模型。model 和 effort 是这个请求中的指定项
模型并不是原样读取这段文本。服务器端首先做的是分词，文本被切分成片段，每个片段被对应到模型训练时固定下来的词表（图中示例为 100,257 个词）中的一个整数。此后，提示就作为整数数组来处理。
图 2：分词器把文本切分成片段，并对应到固定词表中的整数 ID（图中的 ID 为说明用的示例）
模型的工作是预测紧接这个数组之后的“下一个 token”。它为词表中的所有 token 赋予一个概率，并从概率高的开始选取。
图 3：预测以对词表中全部 token 的概率形式输出。契合上下文的 token 与无关 token 之间的差距极大
把输入 token 转换成这些概率的，正是“权重（参数）”——整理成巨大矩阵的数十亿个数值。权重在训练时确定，在发送请求的时刻是只读的。提示、CLAUDE.md 以及放进上下文的资料都不会改写权重。它们能做的是对预测的“操控”，其影响仅限于那一次请求。训练时并不存在的库的知识不在权重之中，把文档放进上下文虽可使用，但模型并不会把某些东西作为记忆保留下来。自信满满地调用并不存在的 API 的现象（幻觉），同样不是检索的失败，而是被解释为权重生成了“在训练模式上最像样的 token 序列”的结果。
图 4：提示进去，概率出来。中间的权重在训练后不再变化，而"更换 model"就是把这一整套整体替换掉
此外，模型并不是一次性生成响应，而是每预测一个 token 就追加到数组里，从概念上说是基于此前已生成的上下文来预测下一个，如此反复地循环输出（在实现上，借助 KV 缓存，过去的 token 并不会每次都重新计算）。一段 200 token 的响应，是让权重通过 200 次的计算，等待时间和输出成本的大部分都源自这个循环。
图 5：输出是每步一个 token。从概念上说，是基于此前已生成的上下文来预测下一个 token
综上，model 设置所决定的是“由哪一套权重来处理请求”和“输出 token 的单价”。而它并不决定“生成多少 token”。同样的提示，生成量也可能大不相同——左右这一点的正是 effort。
effort 的机制 — 决定工作量的另一个输入
Claude Code 在工作中生成的 token 可分为三类——思考（在行动前后流动的推理）、工具调用（Read、Edit 等工具名和参数的结构化块）、面向用户的文本（计划、进展、总结），但它们都是从同一个循环生成的普通输出 token，并按同一单价计费。思考的内容本身不会显示在面向用户的界面上，但在 Claude Code 的内部处理中，它是用于控制工具调用和推理过程的输出 token，相应的消耗也会产生。
图 6：思考也好，工具调用也好，正文也好，都是从同一个循环诞生的同一种输出 token。区别只在于"token 在说什么"
effort 左右着这个生成量。在实现上，effort 级别是与提示并列、作为请求的一部分发送给模型的输入（在 API 中为 output_config.effort；分为 low、medium、high、xhigh、max 五个级别，high 为默认＝与未指定时行为相同 [2]），而各级别下如何表现，则通过模型的训练被固化进权重之中。其效果不止于“思考时间”。除思考的长度外，原帖还列举了 effort 所控制的以下三点。
- 读取多少文件
- 验证多少（运行测试、复查）
- 在不向用户确认的情况下，把多步骤的工作推进到什么程度
在低 effort 下，比起自己花费 token 去调查，Claude 更倾向于向用户询问上下文。在高 effort 下，在把任务视为完成之前所要求的彻底程度和确信度会提高，为达到那份确信会花费许多 token。
图 7：即便是同样的提示，高 effort 也会增加读取、验证的工序，在这个说明用的示例中花费约 7 倍的 token，抵达确信度更高的答案（token 数为示例）
API 文档把这一性质说明为“effort 是行为上的信号，而非严格的 token 预算” [2]。即便是高 effort，计划也不是固定的，会随着中途结果的到来更新对进展和确信度的估计，不再需要的步骤会被明确跳过（Claude Code 中任务列表在执行途中被修订，正是这一点的体现）。反过来，其设计不会在简单任务上因调高 effort 而人为地虚增消耗，“想过头（overthinking）“在训练时作为会降低效果的因素受到监控，原帖如此叙述。
另外，effort 级别的刻度是按模型分别校准的，同样叫“high”的名字在不同模型之间并不代表相同的值 [3]。
出错时，改哪一个
原帖首先建议的，是在动设置之前先怀疑你所给的上下文。提示是否含糊，是否连接到了合适的工具与技能，是否有自我验证工作的手段——许多让人想要调高 effort 的任务，其原因都出在这类上游环节。
在此基础上，即便给了明确的上下文仍然出错时，判断标准是“是不知道，还是没努力“。
图 8：判断流程。"没努力"就调 effort，"不知道"就换 model，两者都不是就修正输入
- 应当更换 model 的情形（不知道）：当问题本身就难——微妙的 bug、不熟悉的领域、架构判断等——无论给多少上下文，小模型都自信满满地一错再错时。处理含糊之处也是大模型更擅长，对小模型则把执行步骤具体地指示出来更容易成功
- 应当更改 effort 的情形（没努力）：因“偷工减料”而出错时，比如漏读了文件、没运行测试、疏于确认。尤其当你设置了低于模型默认值的 effort 时，多属此类
- 反过来，对于能按描述照做的编辑、机械性的改动、对已在上下文中的代码的提问等常规工作，降到小模型质量也不会下降，速度和成本反而改善
专家型、行家、通才
原帖把这两个设置的关系比作人。Fable 是处理几乎无人能解的问题的专家型选手，Opus 是行家，Sonnet 是优秀的通才，而 effort 相当于这个人用在任务上的时间。低 effort 的 Opus 是“与解过许多类似问题的行家相处的五分钟”，会带来代码库里没有的经验法则，但不会仔细通读全部文件。高 effort 的 Sonnet 是“能用上整个下午的通才”，会通读一切、实际运行、二次确认，并深入理解相关代码。并不存在哪一方总是更优，model 大致对应“有多能干”，effort 大致对应“有多彻底”。
关于如何选择 effort，原帖建议在大多数任务上保持模型的默认级别。默认值经过调校，使消耗与“大多数人愿意在该任务上花费的量”相称；effort 的更改不应作为逐个任务的操作，而应作为基于自身领域或工作性质的整体偏好覆盖来使用——这是它的定位。例如，如果平时就把大型代码库的修改或含测试的工作交出去，就调高些；如果多是简短的提问或常规编辑，就调低些。
与成本的关系 — 选曲线的是 model，走到哪里的是 effort
model、effort 与 token 消耗的关系，会随任务难度而逆转。在常规工作中，只要 effort 相同，大小两种模型都能抵达正确答案，大模型因为多做了验证而消耗更多，单价也更高。
图 9：简单任务下两种模型的曲线会收敛。此后的 token 所买到的不是质量，而是二次检查（曲线并非实测数据，而是说明用的概念图）
另一方面，在跨越多步骤的困难工作中，这种关系会反转。小模型朝着能力的极限反复迭代、消耗攀升，大模型则以更少的步骤抵达同等的质量水平。即便单价更高，按任务计的总成本反而可能更便宜。更重要的一点是，大模型能完成小模型即便把 effort 拉满也无法完成的任务。据原帖所说，这一差距在 Fable 5 上最为显著，在内部测试中它完成了 Opus 或 Sonnet 无论什么 effort 都无法抵达的工作（这也正是它拥有最高 token 单价的缘由，并建议把它留给真正需要的工作）。
图 10：困难任务下曲线本身就会分岔。model 选择曲线，effort 决定在这条曲线上走到哪里（曲线并非实测数据，而是说明用的概念图）
最后，effort 会为 token 消耗指明方向，但并不作为上限来限制它。系统中唯一的硬上限是 max_tokens，它是在触及时把响应中途截断的粗糙手段，主要面向 API 开发者。在实用上，更有用的是模型被训练去遵从的那些宽松控制——比如指定任务预算、在提示中要求简洁（在接近上限时会朝着收尾靠拢）。
在 Claude Code 中的设置方法
据 Claude Code 的文档 [3]，这两个设置的操作方式如下。
- model：用
/model切换。在选择界面上，用左右键还能同时调整 effort 滑块 - effort：用
/effort交互式设置，或用启动时的--effort标志、设置文件中的effortLevel等来指定。默认值：Fable 5、Sonnet 5、Opus 4.8、Opus 4.6、Sonnet 4.6 为high，Opus 4.7 为xhigh - 如果指定了模型不支持的级别，则向下取整为不超过它的最高受支持级别
- 在提示中写上
ultrathink，可以在不改变会话 effort 设置的前提下，仅对那一轮要求更深入的推理
另外，原帖中还有关于 Opus 4.8 的实务性注记。在内部测试中，Opus 4.8 的默认 effort 对同一任务，用与 Opus 4.7 默认 effort 大致相同数量的 token，给出了更好的结果。
小结
- 更换 model 就是把负责响应的那一整套训练好的“权重”整体替换。知识、能力和每 token 单价会变，但生成的 token 量并不由它决定
- effort 是对工作量的控制，不仅是思考时间，还包括读取的文件数量、验证的彻底程度、在不确认的情况下推进的距离。在 API 中它作为与提示并列的请求的一部分被发送，是行为上的信号，而非严格的 token 预算
- 对结果不满意时，先怀疑上下文（提示的明确度、工具、自我验证的手段），而不是先动设置
- 若仍然出错，就问“是不知道，还是没努力”。知识不足就改 model，努力不足就改 effort
- 常规工作中小模型更便宜，困难的多步骤工作中大模型按任务计反而可能更便宜。effort 基本上保持模型默认即可，要改就当作整体偏好来对待
参考资料
- Model and effort in Claude Code: knowing more vs. trying harder — @ClaudeDevs on X（2026 年 7 月 9 日，撰写：Lydia Hallie） —— 本文的主要来源。所刊载的图示均引用自该帖子（绘图：Anthropic）
- Effort — Claude Platform Docs。
output_config.effort的指定方法、五个级别，以及“Effort is a behavioral signal, not a strict token budget.”（effort 是行为上的信号，而非严格的 token 预算）等注记 - Model configuration — Claude Code Docs。effort 级别的刻度按模型分别校准（“The effort scale is calibrated per model”）、
/effort・/model的操作方法、各模型的默认值等