导航Claude Code：模型、层级与效能
引言
Claude Code 默认搭载了一个默认模型和一个默认效能等级，大多数开发者从未更改过这些设置。这本身不一定错——默认设置是合理的——但这意味着你在不知不觉中做了一个关于成本和质量的决策。一旦理解了模型层级和效能等级实际控制什么，你就可以更有意识地分配任务。
本文涵盖了 Claude Code 中可用的三种模型层级、两种执行模式、opusplan 别名、四种效能等级，以及在哪些具体情况下更改这些设置会产生实际影响。
模型层级
Claude Code 提供了三种模型层级，每种都有独特的速度与能力权衡：
- Haiku (4.5)：快速层级。处理查找、简单重命名、类grep的探索，以及任何主要需要模型执行而非推理的任务。响应时间近乎即时。如果正在使用子代理在开始真正工作前探索代码库，Haiku 很自然地适合这个角色。
- Sonnet (4.6)：大多数工作负载的默认模型，也是 Claude Code 启动时使用的模型（除非更改）。它处理通用编码任务表现良好——编写函数、小型重构、审查文件、解释代码。
- Opus (4.6)：旗舰模型。在复杂推理、架构决策和硬性调试问题上能力显著更强。每会话消耗的代币也更多。在 Max、Team 和企业版套餐上，Opus 自动获得 100 万 token 的上下文窗口，无需配置——这 100 万窗口使得在单个会话中加载整个大型代码库成为可能。在 Pro 套餐上，它不会自动开启；需要在 Claude Code 内通过
/extra-usage选择加入。
在会话内通过 /model 切换模型，或在 settings.json 中设置默认模型——该文件与第一篇文章中介绍的权限和基本配置相同：
{
"model": "sonnet"
}
使用别名 (sonnet, opus, haiku) 或完整模型名称 (claude-opus-4-6)。命令行的 --model 标志在该会话中优先于设置文件。
普通模式与计划模式
默认情况下，Claude Code 以普通模式运行——它可以读取文件、运行命令和编辑代码，并在每个操作前请求确认。还有另外两种模式可用，通过按 Shift+Tab 循环选择。
计划模式将 Claude 限制为只读工具。它可以探索代码库、搜索模式并草拟实现方法，但在批准之前无法写入或编辑任何内容。这不仅仅是软性指导——限制在工具级别被强制执行。Claude 在计划模式下确实无法触碰文件。也可以通过 /plan 或启动时使用 --permission-mode plan 激活。
当要进行跨多个文件的更改，或者在代码库的不熟悉区域工作并希望 Claude 在开始编辑前真正理解结构时，计划模式是正确的选择。开销是真实的——在编写任何代码之前会在探索上消耗代币——但通常比从错误触及内容的重构中恢复所消耗的总代币要少。
自动接受模式则相反：Claude 在每一步都不提示确认就直接行动。它适用于充分理解的机械性工作，但不常使用。默认模式（Claude 在每个操作前询问）是大多数任务的正确平衡。
opusplan 别名
在 /model 选择器中还有第四个模型选项，它不是三个层级之一——它是 opusplan 别名。激活时，Claude 在计划模式下使用 Opus，并在执行开始时自动切换到 Sonnet。其理念是：架构思考阶段获得 Opus 级别的推理能力，实际代码生成阶段获得 Sonnet 的效率。
在实践中，对于预期在实施前会花费大量时间在计划模式下的会话，这是一个合理的默认值。需要深入分析的规划阶段在 Opus 上运行；更机械化的实施阶段在 Sonnet 上运行。
有一点值得注意：opusplan 不会像在 Max、Team 和企业版套餐上单纯选择 opus 那样自动获得 100 万上下文窗口。Claude Code GitHub 仓库上有公开的错误报告确认了这一点——即使在 Opus 通常获得 100 万的账户上，选择 opusplan 在 /context 中显示的是 20 万窗口。如果在大型代码库中工作并需要完整窗口，请明确使用 opus[1m]。opusplan 别名因其自动模型切换而方便，但目前是以牺牲有保障的 100 万上下文为代价来获得它。
效能等级
效能是随着 Claude 4.6 模型系列推出的一个较新的控制面。它控制模型在响应前进行多少“思考”——具体来说，是在产生输出之前可以花费多少 token 进行内部推理。有四个等级：
- low：最少推理，最快响应。适用于答案显而易见的任务：修复拼写错误、运行构建命令、重命名符号。
- medium：目前 Opus 4.6 和 Sonnet 4.6 的默认值。能很好地处理大多数日常编码工作。Anthropic 在 v2.1.68 中将 Opus 4.6 的默认效能改为 medium，这引起了一些社区摩擦，因为之前的默认值是 high。
- high：更深推理。值得在复杂调试、多文件重构、架构问题，或任何注意到 medium 产生浅薄结果的情况下使用。
- max：仅在 Opus 4.6 上可用。完全移除思考的 token 上限。响应更慢、更昂贵，并且该设置不会跨会话持久化，除非使用
CLAUDE_CODE_EFFORT_LEVEL环境变量固定。
使用 /effort 后跟等级来设置效能，或在启动时使用 --effort 标志：
claude --model claude-opus-4-6 --effort high
也可以在 settings.json 中固定——但 max 在那里不被接受，只接受 low、medium 和 high。对于 max，需要使用环境变量：
export CLAUDE_CODE_EFFORT_LEVEL=max
还有一个每回合快捷键：在提示中包含 ultrathink，Claude 会将效能提升至 high 处理那一个响应，然后恢复。Anthropic 曾短暂移除此关键词，社区反对后，它在 v2.1.68 中回归了。
模型与效能的交互
模型和效能是独立的维度。可以粗略地这样理解：
| low 效能 | medium 效能 | high / max 效能 | |
|---|---|---|---|
| Haiku | 文件查找、重命名 | 简单代码生成 | 很少有用 |
| Sonnet | 机械编辑 | 大多数日常工作 | 困难调试 |
| Opus | 很少有用 | 通用推理 | 架构、复杂错误 |
极端单元格几乎从来不是正确的选择。Haiku 在 max 效能下是为模型层级无法完全使用的推理付费。Opus 在 low 效能下是为旗舰模型付费却告诉它不要思考。
实际中形成的模式是：日常工作中 Sonnet 配合 medium 效能；遇到真正困难的问题时 Opus 配合 high 效能。每周会用到 /effort max 几次——从不当默认值，只在 high 不够用时使用。
常见陷阱
对所有任务使用 Opus
如果在 Pro ($20/月) 套餐上，你在 Claude Code 和常规 Claude 界面之间共享 token 预算。对每个任务（包括文件重命名和琐碎编辑）都在 high 效能下运行 Opus，会以一种 Sonnet 配合 medium 效能不会的方式烧尽预算。对于日常任务，质量差异可以忽略不计，但 token 成本差异则不然。
将 ultrathink 视为永久模式
有时会看到这种情况：开发者将 ultrathink 添加到他们的 CLAUDE.md 或每个提示中，因为他们希望任何时候都获得最大推理。这并不奏效——ultrathink 只影响下一个响应，然后恢复。将其添加到 CLAUDE.md 尤其常见，因为 CLAUDE.md 作为每个会话的上下文被加载，开发者倾向于将其视为持久行为指令的地方。但模型读取它，注意到这个词，在处理该文件的那一个回合应用 high 效能。之后，会话恢复到任何已配置的效能等级。把 ultrathink 保留给真正需要的时刻，并让 CLAUDE.md 专注于项目上下文而非运行时行为标志。
未在子代理前置内容中固定模型
子代理默认继承会话模型。如果会话在 Opus high 效能下运行——这对于复杂工作是合理的设置——那么生成的每个子代理也会继承这个设置，包括那些做简单代码库探索（Haiku 同样能很好地处理）的子代理。因为子代理感觉像后台工作器，很容易忘记它们携带与主会话相同的成本。修复方法是在子代理定义中添加一行：
一个 Opus high 效能的探索子代理与一个 Haiku low 效能的子代理之间的成本差异是显著的。而对于类 grep 的工作，质量差异可以忽略不计。
高效能导致简单任务过度思考
更多的效能听起来总是更好。实际上，Anthropic 自己的文档警告说，更高的效能级别会导致模型对日常工作进行过度思考——在需要直接答案的任务上产生更慢、更犹豫、更冗长的输出。在简单的重构任务中见过这种情况：high 效能导致 Claude 生成了冗长的、没人要求的权衡分析，接着是一个胆怯的实现。Medium 被推荐为默认值是有原因的。把 high 和 max 保留给真正需要更深推理的任务，而不是作为永久的会话设置。
效能不跨模型切换持久化
效能仅在 Opus 和 Sonnet 上受支持——Haiku 不支持。如果为复杂任务设置了 /effort high，然后切换到 Haiku 进行快速查找，效能滑块会静默消失。切换回 Sonnet 时，会话恢复为模型默认值，而不是之前的设置。已配置的效能等级就丢失了。如果在会话中途切换模型，请在每次切换后检查效能等级。
技巧与贴士
- 在执行复杂任务前，使用
/model检查当前的效能等级——效能等级显示在模型名称旁边，可以使用箭头键在该屏幕上更改两者。 - 如果不同代码库具有不同的复杂性特征，则按项目设置效能，而不是全局设置。大型遗留单体通常比较了解模式的小型新服务更受益于更高的效能。
- 使用
ultrathink处理一次性的难题，无需更改会话默认值。在提示中输入它，为该响应获得更深推理，然后继续。 - 如果为特定任务使用子代理，在子代理前置内容中设置效能。一个在 Haiku low 效能上运行的探索子代理，与一个在 Sonnet high 效能上运行的代码审查子代理，成本特征截然不同。两者都有其用途——但应该是深思熟虑的选择。
- 在 Pro 套餐上留意 token 预算显示。警告消息会在达到限制之前出现，而不是之后。
结论
模型层级控制推理能力有多强。效能等级控制有多少这种能力被应用于提示。它们是独立的，将两者与任务匹配，正是区分有意识使用和在自动驾驶中烧毁 token 的关键。
这两个维度也都有直接的上下文成本——思考 token 与输入和输出 token 一样计入上下文窗口。在下一篇文章中，将准确介绍什么消耗了 Claude Code 会话中的上下文窗口，为什么长会话会退化，以及压缩是如何工作的。FINISHED
