← 返回首页

Claude Code 体验变差？模型与努力水平的区别

即便底层模型未变，Claude Code 有时仍可能显得能力下降。本文解析模型选择与努力水平之间的区别，说明努力如何影响文件读取、测试、工具调用和任务完成，以及何时应提升努力程度或切换模型。

发布于 2026年7月13日•general•GEO 评分: 0
Claude Code模型选择努力水平AI 助手工具调用

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
图片展示的是Claude Code界面。背景为深色，左侧有代码编辑器界面，显示代码内容。右侧有“Claude Code”大字，中间有“<></>”符号，下方有“Ready.”字样。该图片位于文档开头部分，与文档中介绍Claude Code相关的内容相呼应，直观呈现了Claude Code的界面样式，为后续对Claude Code的介绍提供了视觉参考。

Claude Code 感觉更糟了？模型与努力水平解析

引言

当 Claude Code 产出结果较弱时，许多开发者会立刻切换到更大、更昂贵的模型。

这种反应可以理解，但往往针对了错误的设置。

Claude Code 提供了两种可以改进输出的控制项：模型和努力水平。两者相关，但职责不同。模型选择更改的是系统底层能力，而努力水平调整的是 Claude 在当前任务中愿意投入多少工作量。

这一区别解释了为什么即使模型本身没有改变，Claude 却突然感觉不够细致。它也解释了为什么一个较小模型在高努力水平下的表现，有时可以超越一个大型模型在低努力水平下的表现。

图片展示了在Claude Code中选择Claude模型和努力水平的内容。上方是一个绿色边框的图标，图标内有两只手，一只手指向另一个手指，另一只手在下方。下方文字为"Choosing a Claude model and effort level in Claude Code"。该图片与文档中介绍Claude Code的两个关键控制变量——模型和努力水平相关，直观呈现了文档所讨论的模型选择和努力水平设置这一主题。

为什么 Claude Code 突然感觉"不那么聪明了"

这种混淆在开发者注意到 Claude Code 的行为发生变化时变得尤为明显。

用户报告说，Claude 跳过了它应该读取的文件，回避运行测试，在多步骤工作中途停止，或者转而向用户寻求更多信息而不是自行探索。

一个被广泛讨论的 GitHub issue 将 Claude Code 描述为"对于复杂工程任务不可靠"。原始文章中引用的分析审查了数千个会话，并报告了推理或执行工作量的急剧下降。

图片展示的是一个GitHub issue界面，标题为"[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates #42796"，状态为"Closed"。该图片位于文档中"Why Claude Code Suddenly Felt 'Less Intelligent'"部分，与上下文紧密相关，上下文提到用户反映Claude Code在复杂工程任务中不可用，此图片直观呈现了用户对Claude Code在复杂任务中表现不佳的反馈，是文档中讨论Claude Code行为变化问题的有力证据。

许多用户最初以为他们的提示词、仓库指令或本地配置出了问题。原始来源文章指出，更直接的原因是默认努力水平设置发生了变化。

为了降低延迟，Anthropic 暂时将部分 Claude Code 用户的默认努力水平从 high 降低到 medium。模型权重并没有变弱，但 Claude 被鼓励在每个任务上花费更少的时间、更少的 token 和更少的工具调用。

可见效果很容易被误读：

  • 检查的文件更少。
  • 运行的测试更少。
  • 多步骤任务提前结束。
  • Claude 更频繁地向用户询问上下文。
  • 响应速度更快，但调查更少。

Anthropic 后来恢复了受影响用户的更高默认设置。但到那时，这一事件已经表明了一个重要观点：即使模型本身没有变化，当努力策略改变时，模型也会让人感觉"变笨"了。

图片展示了Anthropic公司Fable 5模型的设置界面。界面中"Effort"选项被红色框突出显示，其右侧为"High"字样及向右箭头，表明可进行设置。下方"More models"选项也被红色框标出，同样有向右箭头。该图片与文档中介绍Anthropic公司对模型设置进行调整的内容相关，直观呈现了模型设置界面中"Effort"和"More models"选项的位置，帮助理解文档中提到的模型设置变化。

模型改变的是大脑，努力改变的是工作量

Anthropic的解释可以归结为一句实用的话：

模型改变大脑。努力程度决定这个大脑在当前任务上工作的彻底程度。

模型选择决定能力上限

一个模型由一组固定的训练权重定义。

训练完成后，这些权重决定了模型的通用知识、学习到的模式、推理能力、编程经验以及能力范围。提示词、仓库文件、CLAUDE.md 和上下文中的文档可以引导模型，但无法重写这些权重。

这意味着模型选择主要回答了这个问题：

这个模型能否解决这类问题？

如果某个库是在模型训练数据截止日期之后发布的，你可以在当前会话中提供文档让模型使用。但这并不会永久教会模型这个库。相关知识仅存在于当前上下文之内。

同样的限制也解释了为什么模型可能会自信地编造一个不存在的 API。它是在根据学到的模式生成最可能的后续内容，而不是在查询一个保证函数有效性的内部数据库。

文本是如何到达模型的

在 Claude 处理代码或文本之前，输入会被分割成 token。

例如这样一行代码：

const x = await fetch(...)

会从模型的词表中被转换为 token ID。模型使用这些数值表示进行处理，而不是像人类那样读取字符。

这张图展示了Claude大模型处理输入的核心过程：左侧呈现输入文本“const x = await fetch (”被转化为对应数字ID的内容，每个token都有专属的ID编号，如“const”对应1078；右侧则是Claude的词表，约包含10万个词汇，标注了token与对应内容的映射关系，其中高亮了图中用到的7个token的对应条目，呈现了文本输入转化为模型可处理数字形式的具体示例，对应文档中“Claude处理内容前需将输入拆分为token并转化为词表中的ID”的相关说明。

然后模型一次预测一个 token。每生成一个 token 后，序列会被重新处理以预测下一个。

这个重复生成的过程是延迟和成本的主要来源之一。能力更强的模型可以产生更好的预测，但这并不意味着模型会自动检查每个文件、运行每个测试，或者持续完成每个长任务的每个阶段。

而这类行为正是努力发挥作用的地方。

努力控制的不只是思考时间

许多用户将更高的努力度理解为“让模型多思考几秒钟”。

这种理解不完整。

Anthropic 的努力参数会影响模型整体上愿意花费 token 和执行工作的意愿。它可以影响：

  • Claude 会读取多少个文件
  • 它会调用多少个工具
  • 是否运行测试
  • 进行多少验证
  • 是否重新检查编辑内容
  • 在多步骤任务中能持续多深
  • 多快向用户询问更多信息
  • 进行多少扩展推理

在低努力度下，Claude 为速度和 token 效率进行了优化。它可能只读取最明显的文件，做一个狭窄的修改，然后快速返回。

在高努力度下，Claude 更可能检查周围代码、读取配置、运行测试、验证结果，并持续到任务更完成为止。

图片展示了Anthropic官方指南中“修复失败测试”任务的低、高努力度示例。低努力度下，模型读取测试文件，编辑后返回，耗时约400个token；高努力度下，模型读取测试文件、源文件、配置文件，思考后编辑源代码，再运行测试并验证，耗时约2,800个token。此图直观呈现了不同努力度下模型处理任务的步骤差异，与上下文解释努力参数对模型行为的影响相呼应。

Anthropic 指南中的图表使用了一个说明性示例:

  • 低投入路线可能使用约 400 个 token。
  • 高投入路线可能使用约 2,800 个 token。

具体的倍数并非固定规则。投入是一种行为信号，而非严格的 token 预算。不同的任务可能产生不同的消耗模式。

关键在于，额外的 token 不仅用于隐藏推理。它们也可以用于读取文件、生成工具参数、运行验证步骤以及编写更完整的回复。

高投入的小模型可以胜过低投入的大模型

这得出一个乍看反直觉的结果:

一个拥有足够上下文且投入度高的小模型，其表现可以超越一个只允许浅层处理的大模型。

设想两位开发者:

  • 一位是强大的通才，有整个下午的时间来检查仓库、运行应用、测试更改并验证结果。
  • 另一位是经验更丰富的专家，但只给五分钟，只能检查几个文件。

专家可能有更好的直觉，但通才有更多机会收集证据。

这类似于模型能力与投入之间的差异。

大模型确立了更高的质量上限。更高的投入决定了模型在当前任务中愿意朝这个上限移动多远。

图片是一张曲线图，展示了模型选择曲线，努力决定Claude愿意走多远。横轴为每任务花费的token数（=成本和等待时间），纵轴为结果质量。图中有两条曲线，红色为较大模型，蓝色为较小模型。两条曲线在不同token花费处有交点，表明在某些任务中，较小模型在花费较少token的情况下也能达到与较大模型相同质量的结果。该图与上下文紧密相关，直观呈现了模型大小与努力程度对结果质量的影响。

这并不意味着模型大小不重要。有些任务仍然超出了小模型的能力范围，无论投入多少。模型无法仅通过花费更多 token 来弥补缺失的能力。

这确实意味着，增大模型并不总是第一选择或最便宜的解决方案。

Claude 失败是因为无法解决任务，还是因为不够努力？

Anthropic 最有用的建议是一个诊断框架。

当 Claude 产生糟糕结果时，不要立即更换模型。首先确定失败类型。

步骤 1：检查输入和上下文

在更改任何设置之前，验证任务本身。

问：

  1. Prompt 清晰吗？
  2. Claude 有需要的文件吗？
  3. 正确的工具可用吗？
  4. CLAUDE.md 准确吗？
  5. 任务范围划分清晰吗？
  6. 重要的约束条件遗漏了吗？
  7. Claude 在正确的目录或仓库中工作吗？

许多看似是模型的问题，实际上是上下文的问题。

如果模型获得了不完整的需求、过时的指令或错误的文件，那么无论是更高的投入还是更大的模型都无法可靠地解决问题。

步骤 2：寻找投入不足的迹象

当 Claude 出现以下情况时，问题很可能是投入不足：

  • 跳过了相关文件
  • 没有检查配置
  • 避免运行可用的测试
  • 在重构期间停止
  • 进行了一次编辑但没有验证
  • 询问本可通过现有工具找到的信息
  • 在完成请求的工作流程之前就返回

在这些情况下，应提高投入水平。

模型可能已经具备足够的能力。

只需要一个更强的信号，表明任务需要更彻底地完成。

步骤 3：寻找能力限制的迹象

当出现以下情况时，问题更可能出在模型本身：

  • Claude 拥有正确的上下文
  • 它读取了相关文件
  • 它执行了预期的检查
  • 它明显尝试解决该问题
  • 它仍然得出错误结论
  • 重新表述任务也无济于事
  • 增加努力后产生更长但仍然错误的结果

在这些情况下，请切换到更强大的模型。

更高的努力为相同的权重提供了更多发挥作用的空间，但它并不会用更强的能力集来替换这些权重。

如何在 Sonnet、Opus 和 Fable 之间选择

具体的模型阵容和默认设置会随时间变化，因此请始终查看 Anthropic 的当前文档。实用的选择逻辑比任何特定的模型名称都更持久。

为常规工作使用较小或均衡的模型

对于以下任务，通常使用 Sonnet 等更快的模型就足够了：

  • 狭小的编辑
  • 重新格式化
  • 直接的错误修复
  • 已知的迁移
  • 重复的代码更新
  • 文档变更
  • 具有强测试的任务

如果任务涉及多个文件或需要验证，在转向更昂贵的模型之前，请先提高努力水平。

为含混或困难的工作使用更大的模型

当出现以下情况时，使用 Opus 等更强的模型更为合适：

  • 根本原因不明确
  • 任务跨越多个系统
  • 需求相互冲突
  • 代码库包含不熟悉的模式
  • 需要架构判断
  • 解决方案依赖于存储库中不存在的经验

优势不仅仅在于更多的 token。更大的模型可能已经学习了更强的模式，并且拥有更高的能力上限。

为最困难的问题保留最高能力的模型

来源文章将 Fable 描述为当其他模型仍然卡住时应调用的专家模型。

这类模型对以下任务最有价值：

  • 长周期 Agent 任务
  • 复杂的工程诊断
  • 困难的架构工作
  • 高度模糊性的调试
  • 其他模型付出巨大努力后仍未解决的问题

由于最高能力的模型也具有最高的 token 成本，因此应仅在它的额外能力能改变结果时使用。

实用的模型与努力矩阵

任务类型 起始模型策略 建议的努力水平
重命名、格式化、小型文本编辑 快速或均衡模型 低或中
带有清晰测试的狭小 bug 均衡模型 中
多文件 bug 修复 均衡模型 高
需求明确的大型重构 均衡或更强模型 高或极高
不明确的架构失败 更强模型 高
长自主编码工作流 强模型 极高或最大
全面调查后仍然反复失败 转向更强大的模型 保持足够高以进行验证

这是一个起点，而非固定法则。

最佳设置取决于：

  • 存储库大小
  • 任务含混度
  • 测试质量
  • 工具可用性
  • 成本限制
  • 延迟要求
  • 审查要求

为什么不应随意调整努力水平

为每个 prompt 不断更改努力水平会使成本和延迟难以预测。

Anthropic 建议从所选模型的默认努力水平开始，然后将努力水平调整为一个更广泛的工作偏好。

例如：

  • 为快速问题和大量子任务使用较低的努力。

  • 为常规开发使用中等的努力。

  • 为困难的编码和 Agent 工作流使用较高的努力。

  • 仅在需要额外周全性时才使用 xhigh 或 max。

对于 API 用户，effort 参数适用于可见文本、工具调用、工具参数和扩展思考。它不限于单一的隐藏推理预算。

这使得 effort 成为对模型尝试投入多少工作的直接操作控制。

多智能体编排与 Ultracode

源文章还提到了 Claude Code 的 ultracode 模式。

一个重要的思路是，某些长任务能从多个智能体线程中受益。与其让一个 Claude 实例顺序检查大型任务的每个部分，不如让一个协调者将独立工作委托给专用智能体。

示例包括：

  • 一个智能体审查安全性
  • 一个智能体检查测试
  • 一个智能体阅读文档
  • 一个智能体实现变更
  • 一个协调者整合结果

Anthropic 的 Managed Agents 文档描述了多智能体会话，其中智能体可以并行操作，拥有独立的对话历史。这可以在任务分解得当的情况下提高覆盖范围并减少完成时间。

多智能体执行并非自动更优。

它可能增加：

  • Token 使用量
  • 工具调用次数
  • 协调开销
  • 重复工作
  • 审查复杂度

仅在任务包含独立工作流时使用，而不是仅仅因为它可用。

从模型排名到智能体调度

更广泛的启示是，AI 编码正超越模型排名。

过去，工作流程很简单：

  1. 选择可用的最强模型。
  2. 发送任务。
  3. 接受或拒绝结果。

现代的智能体编码需要更积极的调度。

一个团队可能使用：

  • 一个较低成本的模型处理简单变更
  • 一个平衡模型配合高 effort 处理仓库范围的工作
  • 一个更大模型处理架构和诊断
  • 几个专用智能体进行并行研究
  • 确定性测试来验证最终结果

这更接近管理一个技术团队，而不是使用搜索框。

操作该系统的人需要理解：

  • 哪些任务需要更强的能力
  • 哪些任务需要更多调研
  • 哪些任务可以并行运行
  • 哪些任务需要人工批准
  • 哪些任务应在预算耗尽时停止

目标不是消耗最多的 token，而是将 token 花费在能提高结果被接受概率的地方。

实用故障排查清单

当 Claude Code 产生弱结果时，按以下顺序排查：

  1. 检查任务： 请求是否具体且可测试？
  2. 检查上下文： Claude 是否有正确的文件和指令？
  3. 检查工具： 它能否读取、编辑、运行和验证任务所需的内容？
  4. 检查行为： 它是否跳过了调研或提前停止？
  5. 提高 effort： 当模型工作不够彻底时，提高 effort。
  6. 检查能力： 它是否充分调研但仍误解了问题？
  7. 切换模型： 当能力上限是问题时，切换到更强的模型。
  8. 独立验证： 运行测试，检查差异，并审查结果。
  9. 衡量每个接受任务的成本： 不要仅凭每个 token 的价格判断。
  10. 记录重复失败： 将其添加到内部评估集。

常见问题

Claude Code 中的 Model 和 Effort 有什么区别？

模型选择会改变底层的训练权重，从而改变整体的能力范围。Effort 控制 Claude 在当前任务中被鼓励投入多少工作，包括推理、文件读取、工具调用、测试和验证。

付出更多努力能让小型模型胜过大型模型吗？

在某些任务上确实可以。拥有足够上下文和高努力程度的小型模型，可能比低努力程度的大型模型研究得更深入。然而，努力无法突破真实的能力上限。

为什么 Claude Code 有时会跳过测试或文件？

Claude 可能以较低的努力程度运行，任务范围定义不清晰，或者缺少所需的工具和上下文。请先检查提示词和仓库说明，如果 Claude 在完成可用验证前就停止，再提高努力程度。

什么时候应该切换到更强的 Claude 模型？

当 Claude 拥有正确的上下文、清晰地研究任务、运行了相关检查，却依然得出错误结论时，可以切换模型。如果它只是跳过了工作，提高努力程度通常是更好的优先步骤。

努力程度等同于 Token 预算吗？

不相等。Anthropic 将努力描述为一种行为信号，而非严格的 Token 限制。它会影响 Claude 在响应、工具调用、函数参数和扩展思考中投入 Token 的意愿程度。

编码时应该使用什么努力程度？

日常任务使用默认或中等努力程度，困难编码和代理型任务使用高努力程度，长时间运行或特别高要求的工作流使用极高或最高努力程度。根据自身任务重新评估成本和延迟。

Claude Code 中的 ultracode 是什么？

源文章将 ultracode 描述为 Claude Code 的高强度模式，它结合了非常高的努力程度，并在必要时允许协调多个代理。由于产品行为可能变化，在依赖特定实现前，请查阅当前的 Claude Code 文档。

改变努力程度会永久训练 Claude 吗？

不会。努力程度仅改变请求或会话的行为。它不会更新模型权重，也不会永久教会 Claude 新知识。

相关工具

  • Claude Code: Anthropic 的代理型编码工具，用于阅读仓库、编辑文件、运行命令和完成软件任务。
  • Claude Platform: Anthropic 的官方开发者平台，用于使用 Claude 模型和 API。
  • Claude Managed Agents: 托管代理工具包，包含沙箱、工具、会话和多代理编排。
  • Model Context Protocol: 用于将 AI 应用程序连接到外部工具和数据源的开源协议。
  • GitHub: 常用作与 Claude Code 配合使用的源代码平台，用于管理仓库、问题、代码审查和拉取请求。
  • Claude Agent Skills: 可复用的指令包，通过特定任务的工作流和资源扩展 Claude 的能力。

相关链接

摘要

即使底层模型未发生变化，Claude Code 也可能让人感觉能力下降。原因可能是投入设置较低、上下文不完整、缺少工具或任务范围不明确。

模型选择决定了能力上限。投入则决定了 Claude 通过读取文件、调用工具、运行测试和验证工作来使用该能力的充分程度。

首先从修正输入入手。当 Claude 跳过可用工作时提高投入级别。当它已充分探究任务但仍无法解决时，则切换模型。

最佳的 Claude Code 配置并不总是最大的模型——而是在足够的投入、上下文、工具和任务验证下的正确模型。