A11: 模型选择指南

相关章节：第 1 章安装与首次会话、第 15 章生产工作流模式

为特定任务选择合适的 Claude 模型是你作为 Claude Code 用户能做出的最有影响力的决策之一。Claude 模型家族涵盖了广泛的能力、速度和成本权衡。用 Opus 来重命名一个变量，就像雇一位高级架构师来搬桌子；用 Haiku 做复杂的多文件重构，会产出平庸的结果，并在返工上浪费你的时间。本附录提供了你做出这一选择所需的决策框架。

Claude 模型家族（2025-2026）

Claude 目前有三个层级。每个层级代表智能、速度和成本之间的不同平衡。

Intelligence ──────────────────────────────────────────────── ►
                                                              
  ┌────────────┐     ┌────────────┐     ┌────────────────────┐
  │  Haiku 4.5 │     │ Sonnet 4.6 │     │    Opus 4.7        │
  │            │     │            │     │                    │
  │  Fastest   │     │  Balanced  │     │  Most capable      │
  │  Cheapest  │     │  Mid-tier  │     │  Deepest reasoning │
  │  200k ctx  │     │  200k ctx  │     │  1M context        │
  └────────────┘     └────────────┘     └────────────────────┘
                                                              
◄ ────────────────────────────────────────────────── Speed/Cost

Opus 4.7 (claude-opus-4-7-20250219)

特点：

Claude 家族中最强大的推理和代码生成能力
1,000,000 Token 上下文窗口（1M）——比 Sonnet/Haiku 大 5 倍
支持 Extended Thinking：可以对困难问题使用结构化内部推理
在复杂多步任务上表现最佳
最强的指令遵循和细微差别理解

最佳使用场景：

涉及 20+ 个文件的复杂架构重构
调试微妙的并发或状态管理 Bug
安全审计和漏洞分析
根据需求设计新的系统架构
正确性至关重要的代码审查（支付、认证、数据完整性）
需要深入理解大型代码库的任务
需要深度推理的任务（算法设计、性能优化）

成本概况（近似值，截至 2026 年初）：

指标	值
输入 Token	$15 / 1M tokens
输出 Token	$75 / 1M tokens
缓存读取	$1.50 / 1M tokens
缓存写入	$18.75 / 1M tokens
上下文窗口	1,000,000 tokens

何时不使用 Opus：简单文件编辑、样板代码生成、格式化更改、运行测试并报告结果。这些任务浪费了 Opus 的能力（和你的预算）。

Sonnet 4.6 (claude-sonnet-4-6-20250514)

特点：

能力与速度的良好平衡
200,000 Token 上下文窗口
对标准模式的出色代码生成能力
良好的指令遵循，比 Haiku 更少的边缘情况失败
支持 Extended Thinking（但受益程度不如 Opus）
速度足以支持交互式开发工作流

最佳使用场景：

日常功能开发
标准重构（重命名、提取方法、移动文件）
为现有代码编写测试
生成样板代码和脚手架
文档编写和更新
大多数 Pull Request 审查
交互式结对编程会话

成本概况（近似值）：

指标	值
输入 Token	$3 / 1M tokens
输出 Token	$15 / 1M tokens
缓存读取	$0.30 / 1M tokens
缓存写入	$3.75 / 1M tokens
上下文窗口	200,000 tokens

默认选择：如果你不确定该使用哪个模型，Sonnet 几乎总是正确的起点。它能很好地处理 80% 的开发任务。

Haiku 4.5 (claude-haiku-4-5-20241022)

特点：

Claude 家族中最快的响应时间
200,000 Token 上下文窗口
每个 Token 成本最低
擅长定义明确的窄任务
在需要细致判断或复杂推理的任务上较弱
最适合大批量、低复杂度的操作

最佳使用场景：

分类和归类（例如，对问题分类、路由请求）
简单的代码转换（格式化、导入排序）
生成 Commit 消息、PR 描述、变更日志
快速查找和摘要
作为高并发并行任务的子 Agent
跨多个文件的 Lint 风格检查

成本概况（近似值）：

指标	值
输入 Token	$0.80 / 1M tokens
输出 Token	$4 / 1M tokens
缓存读取	$0.08 / 1M tokens
缓存写入	$1 / 1M tokens
上下文窗口	200,000 tokens

何时不使用 Haiku：任何需要多步推理、微妙判断或复杂代码生成的任务。Haiku 会产生一个答案，但它可能以某些方式出错，而调试这些错误的成本比直接使用更好的模型还要高。

在 Claude Code 中切换模型

你可以通过多种方式更改 Claude Code 使用的模型：

bash

# Set model via environment variable
export ANTHROPIC_MODEL=claude-sonnet-4-6-20250514
claude

# Set model via CLI flag
claude --model claude-opus-4-7-20250219

# Set model in settings.json (persistent)
# In .claude/settings.json:
{
  "model": "claude-sonnet-4-6-20250514"
}

在活跃会话中，你也可以使用 /model 命令切换模型：

> /model claude-opus-4-7-20250219
Model changed to claude-opus-4-7-20250219

模型一览对比

维度	Haiku 4.5	Sonnet 4.6	Opus 4.7
推理深度	基础	强	卓越
代码生成	简单模式	全栈开发	架构师级别
指令遵循	适合明确任务	非常好	最佳
速度（首个 Token 时间）	最快（~200ms）	中等（~500ms）	最慢（~1-3s）
速度（Token/秒）	~150 tok/s	~90 tok/s	~40 tok/s
上下文窗口	200K	200K	1M
Extended Thinking	否	是	是（受益最大）
输入成本（每 1M Token）	$0.80	$3	$15
输出成本（每 1M Token）	$4	$15	$75
典型任务成本	$0.01-0.05	$0.05-0.30	$0.30-2.00

Extended Thinking：何时重要

Extended Thinking 允许 Claude 在回复前使用内部思维链推理。这对复杂任务有不成比例的提升：

bash

# Enable extended thinking with a budget
claude --model claude-opus-4-7-20250219 \
  -p "Design the database schema for a multi-tenant SaaS billing system. 
  Consider edge cases around proration, currency conversion, and audit trails."

Opus + Extended Thinking 在以下任务中表现出色：

需要同时平衡多个约束
解决方案需要考虑非显而易见的边缘情况
正确性比速度更重要（安全审计、数据迁移）

Sonnet + Extended Thinking 适用于：

中等复杂的实现任务
需要推理交互关系的代码审查
规划多步变更

Haiku 不支持 Extended Thinking。对于需要此功能的任务，请升级到 Sonnet 或 Opus。

详见 A09 Extended Thinking。

模型路由策略

最具成本效益的团队不会选择一个模型然后用它做所有事情。他们将不同的任务路由到不同的模型。这称为模型路由（Model Routing）或模型级联（Model Cascading）。

策略 1：用 Haiku 分类，用 Sonnet 实现，用 Opus 审查

这是最常见的多模型工作流：

                  Haiku 4.5              Sonnet 4.6             Opus 4.7
                ┌───────────┐          ┌────────────┐         ┌──────────┐
  New task ───► │  Classify  │ ───────► │ Implement  │ ──────► │  Review  │
                │  Estimate  │          │  Generate   │         │  Verify  │
                │  Route     │          │  Test       │         │  Approve │
                └───────────┘          └────────────┘         └──────────┘
                   ~$0.01                  ~$0.15                ~$0.50
                  per task               per task              per task

示例工作流：

Haiku 读取 GitHub Issue，将其分类为 bug/feature/docs，估计复杂度（S/M/L），并进行路由
Sonnet 实现解决方案、编写测试、生成 PR
Opus 审查 Diff 的正确性、安全性和架构一致性

策略 2：oh-my-claudecode 模式

开源项目 oh-my-claudecode 框架通过拦截任务描述并选择适当的模型来实现智能模型路由：

bash

# oh-my-claudecode configuration example
# ~/.config/oh-my-claudecode/routing.yaml
rules:
  - match: "simple edit|rename|typo|format"
    model: claude-haiku-4-5-20241022
    reason: "Simple changes don't need heavy reasoning"

  - match: "implement|feature|refactor|test"
    model: claude-sonnet-4-6-20250514
    reason: "Standard development work"

  - match: "security|architecture|review|debug complex|performance"
    model: claude-opus-4-7-20250219
    reason: "Tasks requiring deep analysis"

  - default:
    model: claude-sonnet-4-6-20250514

关键洞察：模型选择应该是自动的，而不是手动的。如果开发者必须记住切换模型，他们会默认使用一个模型，浪费金钱或能力。

策略 3：失败时升级

从较便宜的模型开始。如果失败或产出质量较低，则升级：

bash

# Pseudocode for escalation pattern
attempt_with_sonnet() {
  result=$(claude --model claude-sonnet-4-6-20250514 -p "$task")
  if tests_pass "$result"; then
    echo "$result"
  else
    # Escalate to Opus
    claude --model claude-opus-4-7-20250219 -p "$task (previous attempt failed: $result)"
  fi
}

这种方式效果好是因为大多数任务用 Sonnet 就能成功，你只在必要时才支付 Opus 的溢价。

对编码任务有意义的基准测试

通用 LLM 基准测试（MMLU、HellaSwag 等）无法很好地预测编码性能。以下是与 Claude Code 效果实际相关的基准测试：

基准测试	衡量什么	与 Claude Code 的相关性
SWE-bench Verified	模型能否解决真实的 GitHub Issue？	直接相关——这正是 Claude Code 的使用场景
HumanEval+ / MBPP+	模型能否编写正确的函数？	衡量原始代码生成质量
Aider polyglot	多语言编辑准确性	专门测试 Edit/Write 工作流
Terminal-bench	模型能否有效使用 bash 工具？	测试 Bash 工具调用循环
GPQA Diamond	研究生级别推理	与调试复杂问题的能力相关

关注什么：比较模型时，重点关注 SWE-bench Verified 得分。在 SWE-bench 上得分 70% 的模型大约能在首次尝试中正确解决 70% 的真实编码任务，而得分 50% 的模型需要更多迭代。

截至 2026 年初，大致的 SWE-bench Verified 表现：

模型	SWE-bench Verified
Opus 4.7	~72%
Sonnet 4.6	~65%
Haiku 4.5	~45%

Sonnet 和 Opus 之间的差距小于 Haiku 和 Sonnet 之间的差距。这就是为什么 Sonnet 是默认选择——它覆盖了大多数任务，同时比 Opus 便宜 5 倍。

何时在会话中升级 vs 降级

应该升级到 Opus 的信号

Claude 在原地打转，反复尝试同一种方法
任务涉及多个系统之间的微妙交互
你已经在失败的 Sonnet 尝试上花费了大量 Token（沉没成本是真实的——返工成本超过了 Opus 的溢价）
任务需要理解非常大的代码库（Opus 的 1M 上下文在此具有决定性优势）
你需要高置信度的正确性（安全、金融计算、数据迁移）

应该降级到 Haiku 的信号

你正在并行运行许多小型独立任务
任务定义明确，有清晰的模板（例如，"将这个字段添加到这 20 个文件中"）
你在生成将由人工审查的内容
速度比完美更重要（快速原型、探索性编码）

选错模型的代价

Scenario: Implement a feature that touches 8 files

With Haiku (wrong choice):
  - 3 attempts, each partially correct       3 x $0.05 = $0.15
  - Manual debugging and fixing               1 hour of your time
  - Total: $0.15 + opportunity cost of 1 hour

With Sonnet (right choice):
  - 1 attempt, correct                       $0.15
  - Quick review and merge                    5 minutes
  - Total: $0.15 + 5 minutes

With Opus (overkill):
  - 1 attempt, correct with extra polish      $0.60
  - Quick review and merge                    5 minutes
  - Total: $0.60 + 5 minutes

在这个例子中，Sonnet 和 Opus 都产出了正确的结果，但 Sonnet 便宜 4 倍。Haiku 看起来每次尝试最便宜，但加上返工后实际上是最贵的。最便宜的模型是第一次就做对的那个。

1M 上下文的优势

Opus 4.7 的 1,000,000 Token 上下文窗口是一个质的飞跃，不仅仅是量的增加。借助 1M Token，你可以放入：

~25,000 行代码（一个完整的中型项目）
跨越数百个回合的完整对话历史
多个大文件同时进行交叉引用分析

这对以下任务很重要：

跨代码库重构：Opus 可以在上下文中持有整个依赖图
长调试会话：无需压缩，因此不会丢失上下文
架构审查：读取项目中的每个文件而无需摘要化

使用 Sonnet 或 Haiku（200k 上下文）时，/compact 命令对长会话至关重要。使用 Opus 时，你通常可以完成整个功能而无需进行任何压缩。

决策框架速查

Is this task simple and well-defined?
  ├── YES ──► Does it need to run in high volume?
  │             ├── YES ──► Haiku 4.5
  │             └── NO  ──► Sonnet 4.6
  └── NO  ──► Is deep reasoning or large context critical?
                ├── YES ──► Opus 4.7
                └── NO  ──► Sonnet 4.6

对于大多数开发者，默认应该是 Sonnet，将 Opus 留给困难问题，将 Haiku 留给大批量自动化。

核心要点

Sonnet 4.6 是 80% 开发任务的默认选择。除非有具体原因，否则从这里开始。
Opus 4.7 用于困难问题：复杂调试、安全审查、架构重构，以及任何需要 1M 上下文窗口的场景。
Haiku 4.5 用于大批量任务：分类、归类、简单转换和子 Agent 任务，速度比深度更重要。
自动化模型路由，而不是依赖开发者手动选择。像 oh-my-claudecode 这样的工具使之变得实用。
最便宜的模型是第一次就成功的模型。使用较弱模型导致的返工往往比直接使用更强模型更贵。
SWE-bench Verified 是预测 Claude Code 效果最重要的基准测试。

参见：A07 Token 经济学了解模型定价背后的成本机制，以及 A10 提示缓存了解如何无论选择哪个模型都能降低成本。

A11: 模型选择指南 ​

Claude 模型家族（2025-2026） ​

Opus 4.7 (claude-opus-4-7-20250219) ​

Sonnet 4.6 (claude-sonnet-4-6-20250514) ​

Haiku 4.5 (claude-haiku-4-5-20241022) ​

在 Claude Code 中切换模型 ​

模型一览对比 ​

Extended Thinking：何时重要 ​

模型路由策略 ​

策略 1：用 Haiku 分类，用 Sonnet 实现，用 Opus 审查 ​

策略 2：oh-my-claudecode 模式 ​

策略 3：失败时升级 ​

对编码任务有意义的基准测试 ​

何时在会话中升级 vs 降级 ​

应该升级到 Opus 的信号 ​

应该降级到 Haiku 的信号 ​

选错模型的代价 ​

1M 上下文的优势 ​

决策框架速查 ​

核心要点 ​

A11: 模型选择指南

Claude 模型家族（2025-2026）

Opus 4.7 (claude-opus-4-7-20250219)

Sonnet 4.6 (claude-sonnet-4-6-20250514)

Haiku 4.5 (claude-haiku-4-5-20241022)

在 Claude Code 中切换模型

模型一览对比

Extended Thinking：何时重要

模型路由策略

策略 1：用 Haiku 分类，用 Sonnet 实现，用 Opus 审查

策略 2：oh-my-claudecode 模式

策略 3：失败时升级

对编码任务有意义的基准测试

何时在会话中升级 vs 降级

应该升级到 Opus 的信号

应该降级到 Haiku 的信号

选错模型的代价

1M 上下文的优势

决策框架速查

核心要点