Anthropic 出三个模型。大多数人选一个然后用到底——或者更糟，根本不知道区别。
这是用大锤挂相框。能挂，但工具不对。
0xMortyx 的 5 秒决策框架：
Opus 深思，Sonnet 干活，Haiku 跑腿。大部分任务用 Sonnet。少数用 Opus。比你想的多得多的任务可以用 Haiku。
三个模型的真实定位
Opus：决策重要才用
Opus 不是日常模型。它用于推理质量直接影响重要结果的场景。
类比：Opus 是你请的咨询顾问。你不会请顾问写邮件。你请他做真正影响决策的事。
适合 Opus 的场景：
- 架构设计（"这个微服务应该拆还是合并"）
- 难 bug 调试（"为什么这个 race condition 偶尔触发"）
- 复杂 tradeoff（"用 Postgres 还是 DynamoDB"）
- 长文档结构（"这份白皮书章节怎么排"）
- 关键代码 review（"这个 PR 上不上 production"）
判断标准：这个任务做错的代价是 10x 时间还是 $10k 营收？前者用 Sonnet，后者用 Opus。
Sonnet：默认模型
Sonnet 应该全天候打开。它真的聪明——不是 Opus 的弱化版。
80% 的任务（写代码、改文档、做分析、跑研究），Sonnet 和 Opus 质量你分不出，但速度差距明显。
适合 Sonnet 的场景：
- 日常写代码（CRUD、bug fix、refactor）
- 文档写作（README、API 文档、内部 wiki）
- 数据分析（CSV 探索、SQL 写）
- RAG 检索（"这个文档里有 X 吗"）
- 翻译（不是文学翻译，是技术内容翻译）
- 邮件草稿、Slack 长文
判断标准：这是日常工作，质量"够好"就够。
Haiku：被严重低估
Haiku 被低估的原因是大家拿它跟 Opus 比——比硬任务就输了。拿它跟 Sonnet 比——比简单高频任务，它赢在速度。
类比：Haiku 是工厂流水线工人。每个动作都不复杂，但单位时间产出大。
适合 Haiku 的场景：
- 文本摘要（一段 → 一行）
- 分类（"这个 email 是 spam 吗"）
- 提取（"这段提到的人名、金额、日期"）
- 重写（"这个句子改得通顺点"）
- 翻译（短文本、technical 短句）
- Agent loop 里的 tool 调度（"下一个调哪个 tool"）
- 批量重格式化（100 条 JSON → CSV）
判断标准：这个任务不需要"想"——只是机械处理。
成本现实
API 用户或 Claude.ai Pro 用户需要知道这点：
- Opus：每任务最贵
- Sonnet：中价
- Haiku：每任务便宜一个数量级
实际意义：自动化 / pipeline / agent loop 跑 1000 次——
- Opus = ~$60
- Sonnet = ~$6
- Haiku = ~$1
简单任务用 Opus 和用 Haiku，成本差 60 倍。
选型决策树
这个任务如果做错，后果多严重？
│
├─ 后果严重（决策、架构、关键客户代码）→ Opus
│
├─ 后果中等（日常代码、文档、分析）→ Sonnet ← 默认
│
└─ 后果低 / 高频调用 / 简单任务 → Haiku
5 秒就能判断。
最常见的 4 个错误
1. 所有任务都用 Opus
感觉安全，但浪费时间和钱。大多数任务不需要它。Opus 不是"更聪明版 Sonnet"——它是**"慢 5 倍、贵 20 倍的 Sonnet"**。
2. 复杂写作用 Haiku
它在细微差别上偷工。结果是：生成出来你自己都不想用。
Haiku 适合结构化短文本（摘要、分类、提取），不适合有观点的长文（评论、深度分析、营销文案）。
3. 整个项目不切换模型
正确姿势：
- Sonnet 起草（快速生成）
- Opus 决断（遇到 reasoning 死胡同时升级）
- Haiku 收尾（清理、格式化、批量处理）
切换不是"降级"——是每个阶段用最合适的工具。
4. 假设 Sonnet 比 Opus "差"
Sonnet 4.5+ 在 SWE-bench、agent 任务上和 Opus 差距 < 5%。日常 80% 任务用 Sonnet 不会"少点什么"。
Sonnet 的 5% 优势在你付费 20 倍时显得重要——但只对那 5% 的任务重要。
实际工作流示例
场景：写一篇技术 blog
| 阶段 | 模型 | 原因 |
|---|---|---|
| 大纲 | Sonnet | 结构化任务，Sonnet 足够 |
| 关键论点决策 | Opus | "这个角度对不对"需要判断 |
| 第一稿 | Sonnet | 快速生成 2000 字 |
| 深度 review | Opus | 找出逻辑漏洞 |
| 翻译英文版 | Haiku | 机械翻译 |
| SEO meta 描述 | Haiku | 一句话生成 |
整个流程用 Opus 在 2-3 个关键节点，其他全是 Sonnet / Haiku。
场景：agent pipeline
| 阶段 | 模型 |
|---|---|
| 任务分解 | Sonnet |
| Tool 路由决策 | Haiku（高频简单判断） |
| 复杂推理步骤 | Opus |
| 输出格式化 | Haiku |
| 错误处理 | Sonnet |
Agent loop 每步都该问"这个用 Haiku 行不行"——能省的钱非常可观。
适合谁 vs 不适合谁
适合
- 所有 Claude API 用户——你 pay-per-token，模型选错直接亏钱
- 跑 agent loop / pipeline——1000 次调用的成本差是真实差距
- 多任务工作流（写代码 + 写文档 + 做分析 + 跑数据）——一个模型不适用所有
不适合
- 只用 Claude.ai web 版（订阅制，模型选择不影响成本）——但仍影响响应速度
- 任务极简单（"把这段翻译成中文"）——直接用默认模型就好
- 对模型能力没概念——先固定用 Sonnet 跑一个月，搞清楚"哪些任务它能做、哪些不行"，再考虑精细选型
0xMortyx 没说的两件事
1. 模型选型不只看质量，还看 reasoning effort。Opus 4.5+ 有"extended thinking"模式，可以选"想多久"。一个 Opus task 选 max effort vs min effort，成本可以差 10 倍。这条 post 只讲了"哪个模型"，没讲"同一模型用多大力"。实操经验：用 Sonnet + max thinking 经常比用 Opus + min thinking 质量高且便宜。
2. Haiku 的"快"是有边界的。Haiku 在单次调用上快，但在多步 agent loop里，因为每个 step 都要 round-trip，总延迟是 step 数 × latency——不是模型越快越好。如果一个 agent loop 5 步，Haiku 节省的 latency 是 5×(Sonnet_latency - Haiku_latency)。对短 loop（< 3 步）用 Haiku，> 5 步用 Sonnet——中段 Sonnet 性价比最高。
结论
Opus / Sonnet / Haiku 不是性能排名，是成本-质量-速度三维取舍。
- Opus = 慢、贵、想得深
- Sonnet = 中、中、中（甜点）
- Haiku = 快、便宜、简单
默认 Sonnet。遇到 reasoning 死胡同升级 Opus。比你想的多得多的任务可以下放到 Haiku。
SOTA Sync 的判断：未来 6 个月，"模型路由"会成为 agent 工程的标配——不是"一个模型跑所有"，是"按任务难度自动选模型 + 自动选 reasoning effort"。这意味着 Claude API 用户需要学prompt 级别的成本意识——同一个 prompt 选不同模型，账单差 60 倍。