如何为每个编码任务选对 Claude 的模型档位

人们刚开始用 AI 编码助手时，往往会挑可用的最强模型，然后用它处理一切。这感觉很稳妥——干嘛不一直用最聪明的模型呢？但最聪明的模型同时也是最慢、最贵的，而对很多日常工作来说它属于杀鸡用牛刀。学会把模型档位与任务相匹配，是你能养成的最高杠杆的习惯之一。它省钱、回答更快，而且——有点反直觉地——有时还能产出更好的结果，因为一个能很快跑完的模型让你能多迭代几轮。

本指南以 Anthropic 的 Claude 产品线为例，但这个原则适用于每一个发布模型家族的供应商。

从轻到重的各个档位

截至 2026 年年中，Claude 有四个档位，每一档大致是能力和价格上的一级台阶（官方定价）：

• Haiku 4.5——每百万输入/输出 token 1 / 5 美元。又快又便宜。非常适合简单、定义明确的工作。
• Sonnet 4.6——3 / 15 美元。主力。在编码和大多数生产任务上很强。
• Opus 4.8——5 / 25 美元。为复杂的多步问题做更重的推理。
• Fable 5——10 / 50 美元。全新的 Mythos 档旗舰，2026 年 6 月 9 日发布，面向最难的问题。

注意每个档位的输出 token 都是输入 token 的五倍，而从 Sonnet 跳到 Fable 是超过 3 倍的涨价。这些差距正是档位选择为何重要的原因。

Anthropic 自己的经验法则

Anthropic 的定价文档给出了一条干脆利落的建议："简单任务选 Haiku，大多数生产负载选 Sonnet，最复杂的推理选 Opus。" Fable 5 把这道阶梯又往上延伸了一级，面向前沿级别的问题。

翻译成编码工作：

• 够用 Haiku 当任务是机械性的：重命名变量、写一个正则、格式化 JSON、生成样板测试、总结一个 diff，或者回答一句快速的"这个函数是干嘛的？"
• 默认用 Sonnet 处理大部分真实编码：实现一个功能、修一个普通 bug、写一个组件、审查一个 pull request。这应该是你的大本营。
• 升级到 Opus 当一个任务需要在大量上下文中进行真正的推理：一个没有明显成因的含糊 bug、一个改动相互影响的跨文件重构，或者架构设计决策。
• 省着用 Fable 5 留给那些连 Opus 都搞不定的罕见问题——一次庞杂的迁移、一个微妙的并发 bug，或者在单个会话中横跨一个非常大的代码库的工作。

一个实操示例

假设你在给一个 web 应用加一个新的"导出为 CSV"功能。一个有档位意识的工作流可能是这样：

1. 用 Opus 做规划。 "这是我的代码库结构。导出逻辑应该放在哪里，我该处理哪些边界情况？" 这一步推理量大，并设定了方向——值得用更好的模型。
2. 用 Sonnet 做实现。 "写出导出函数并把它接到一个按钮上。" 标准编码，主力模型处理得很好。
3. 用 Haiku 做测试和收尾。 "为这个函数生成单元测试"以及"重新格式化这个文件"。便宜、快速、机械。

昂贵的模型只触碰这份工作中真正需要它的那 10%。在 Claude Code 中你可以在会话中途用 /model sonnet 或 /model haiku 切换；在 Cursor 中你从模型下拉框里选。整个功能的花费只是让 Opus 或 Fable 做每一步的一个零头——而且完成得更快，因为便宜的步骤几乎瞬间返回。

不降档也能省成本

档位选择是最大的杠杆，但还有两个内置功能可以叠加在它之上：

• 提示缓存（Prompt caching）。 如果你反复发送同一段大上下文（一个很大的 system prompt、一个你不断引用的文件），把它缓存起来会让后续读取的成本只有输入价格的 10%。对每一轮都重发上下文的 agent 循环来说，这个收益巨大。
• 批处理（Batch processing）。 对于不紧急、大批量的任务——为 200 个文件生成测试、翻译一个文档文件夹——Batch API 以异步方式运行，输入和输出都打 5 折。

两者都不改变模型的质量；它们只改变你为同样的工作所付的钱。

要点

别出于谨慎就默认用最大的模型。默认用 Sonnet，任务琐碎时降到 Haiku，只有当一个问题确实需要更深的推理时才爬到 Opus 或 Fable。你会花得更少、等得更短，而且——因为你负担得起多迭代——往往能交付更好的代码。目标不是用最聪明的模型；而是为眼前这件事用对的那个。