有个反直觉的结论我先说：日常编码，Opus 是最差的选择。

不是因为 Opus 不强。是因为它强得用错了地方。

你让 Opus 帮你写个表单验证，它会开始考虑边界情况、提出你没问的架构问题、给你三个方案让你选。你只是想要一个能跑的函数，它在帮你做产品决策。

结果是：时间花了更多，token 烧了更多，你还得从三个方案里再做一次选择。

为什么模型选择比你想的更重要

我当时的策略是"无脑用最好的"——反正收益是正的，就一直开着 Opus，觉得这样最省心。

用了两个月，账单出来，比预期高了将近一倍。然后我开始认真研究每个模型到底适合干什么。

研究完之后，我把策略改成了"按任务类型选模型"，账单直接降了 40%，效率反而提升了——因为 Sonnet 在日常编码任务上的响应速度比 Opus 快不少，不用等那么久。

这件事让我意识到：模型选择不是"越贵越好"，是"越匹配越好"。

三个模型的核心差异，不是能力高低，而是思维方式不同：

• Opus：深思熟虑型，喜欢全局考量，给建议前会把所有角度想一遍

• Sonnet：执行力型，理解需求快，直接给解决方案，不绕弯子

• Haiku：反应速度型，对简单指令的响应极快，复杂推理是弱项

三种思维方式，对应三类任务。用对了省钱省时间，用错了花钱买焦虑。

Sonnet：你的日常主力，没有之一

我现在 80% 的编码任务都在用 Sonnet。

Sonnet 适合的场景：

写 CRUD 功能、生成 API 路由、写 React 组件、调试报错、写单元测试、重构函数、补充类型定义——换句话说，所有你知道要做什么、只是不想手打的任务，Sonnet 都比 Opus 合适。

原因很简单：这类任务对"理解深度"的要求不高，对"执行准确度"的要求很高。Sonnet 在这里恰好是最优解。

一个具体的对比数据：

我用同一个 Prompt 让两个模型写了一个 Stripe 订阅取消的 API 路由：

	Opus	Sonnet
响应时间	约 18 秒	约 6 秒
输出内容	先给三种实现方案，然后推荐其中一种，最后才写代码	直接给代码，附一段踩坑说明
代码质量	两者几乎没有差别
Token 消耗	约 2800	约 1100

Opus 的"先分析再执行"的风格，在这个任务里纯粹是负担。我就想要个能跑的路由，不需要它帮我做技术决策。

Sonnet 的唯一短板： 遇到它不确定的技术细节，它有时候会"假装会"——给你一段看起来合理但实际有问题的代码。所以 Sonnet 的输出，涉及你不熟悉的领域，要多一分审查意识。

Opus：只在这三个场景用，其他时候收着

Opus 不是不好，是被大多数人用在了不需要它的地方。

场景一：系统架构设计

当你需要设计一个新系统、做技术选型、或者思考一个复杂的业务逻辑应该怎么拆分时，Opus 的"全局考量"能力才真正发挥价值。

我在做出海 SaaS 的多租户架构时，问了 Opus 一个问题：

我的 SaaS 产品要支持多租户，每个租户有独立的数据，预计初期 100 个租户，未来可能到 10000 个。我在考虑"共享数据库+行级隔离"和"每租户独立数据库"两种方案，从成本、迁移复杂度、数据安全三个维度帮我分析，给出你的建议和判断依据。

Opus 给了一个非常完整的分析，把我没想到的迁移成本和 Connection Pool 的问题都提出来了，最后给了一个明确的建议而不是"都可以"。

这种需要"把所有角度想清楚"的场景，Opus 值那个价。

场景二：复杂 Bug 的根因分析

当一个 Bug 的表现和原因之间隔着好几层因果关系，Sonnet 容易给出"头痛医头"的方案，Opus 更容易追到根因。

我有一次 Stripe Webhook 偶尔丢事件，Sonnet 给我的建议是"加重试机制"。Opus 追问了我几个问题之后，发现真正的问题是我的 Webhook 处理函数没有在 5 秒内返回 200，导致 Stripe 认为处理失败，触发了重发——根本原因是数据库操作没有异步化。

场景三：不熟悉的技术领域

进入一个你完全不懂的技术领域时，用 Opus 当"向导"，它能帮你建立正确的认知框架，避免一开始就走弯路。

等你对这个领域有了基本判断，再换回 Sonnet 做具体实现。

Haiku：被严重低估的效率工具

很多人把 Haiku 当成"穷人版 Claude"，这是误解。

Haiku 的定位是高速、低成本的简单任务处理器。它不适合复杂推理，但对于简单明确的任务，它比 Sonnet 快 3-5 倍，价格便宜 10 倍以上。

Haiku 真正适合的场景：

- 生成样板代码（组件骨架、接口定义、类型声明）
- 代码格式化和注释补充
- 变量命名建议
- 简单的代码翻译（JS → TS、Class → Function）
- 批量处理小任务（CLI 脚本里处理大量文件）

一个我真实在用的场景：

我的 CLI 批处理脚本里，对每个文件做"加 JSDoc 注释"这个任务，用的是 Haiku：

#!/bin/bash
# 为所有工具函数批量加 JSDoc，用 Haiku 省钱省时间
find src/lib -name "*.ts" | while read file; do
  claude -p "为这个文件里所有没有 JSDoc 的导出函数加上注释，
  包括 @param、@returns、@example。
  只输出修改后的完整文件，不要任何解释。" \
  --model claude-haiku-4-5-20251001 \
  < "$file" > "${file}.tmp" && mv "${file}.tmp" "$file"
done

说人话就是： 加 JSDoc 是个机械性任务，不需要深度推理，Haiku 完全够用，速度还快，批处理 30 个文件，比用 Sonnet 省了大约 70% 的费用。

大多数教程不告诉你的细节： Haiku 在"生成代码"任务上有一个明显短板——它对项目上下文的"消化能力"较弱。如果你的 CLAUDE.md 写了很多约束，Haiku 可能只执行了一半。所以用 Haiku 时，Prompt 要更明确、更具体，不要依赖它从上下文里推断规范。

我的模型分配策略（可直接抄）

任务类型                    推荐模型    理由
─────────────────────────────────────────────
架构设计 / 技术选型          Opus       需要全局视角
复杂 Bug 根因分析            Opus       需要深度推理
不熟悉领域的入门学习         Opus       需要建立认知框架

日常功能开发（CRUD）         Sonnet     执行准确，速度快
代码重构                    Sonnet     理解需求好
写单元测试                  Sonnet     覆盖率判断需要一定推理
跨文件改动                  Sonnet     上下文理解要求较高
调试报错                    Sonnet     首选，必要时升 Opus

生成样板代码                 Haiku      机械性任务，不需推理
批量加注释 / 格式化          Haiku      CLI 批处理首选
简单类型补充                 Haiku      速度快，够用
变量 / 函数命名建议          Haiku      反应速度比质量更重要

踩坑环节

坑一：用 Opus 做迭代开发，越改越乱

有一次做一个功能，需求不太清晰，我想边做边想，就开着 Opus 反复让它给方案、否掉、再给方案。

结果聊了大概 20 轮，Opus 的每次方案都在前一个方案的基础上"进化"，越来越复杂，最后给我生成了一套我自己都看不懂的架构。

我发现的方式： 想实现的时候才发现根本不知道从哪下手，整个对话变成了思维发散，没有收敛。

怎么解决的： 现在的做法是，需求不清晰时，先用 Opus 做一轮"问题拆解"，输出一份简洁的需求文档；然后关掉这个 Session，用 Sonnet 开新 Session，按需求文档做实现。Opus 负责"想清楚"，Sonnet 负责"做出来"，分开不混。

坑二：Haiku 批处理时，部分文件输出格式乱

我用 Haiku 批量处理文件，有几次它输出的不是纯代码，而是带了一些解释文字，导致文件被覆盖后直接报语法错误。

我发现的方式： 跑完脚本执行 npx tsc --noEmit，一堆语法错误，打开文件一看，文件开头多了一行"以下是修改后的代码："。

怎么解决的： Prompt 结尾加上约束：

严格规定：只输出代码文件本身，第一个字符必须是代码（比如 import 或 //），不要任何前言、解释、markdown 代码块标记。

同时在脚本里加验证——如果输出文件的前 10 个字符不像代码，就跳过覆盖，保留原文件并报警。

模型选择的本质是任务分工，不是能力排名。 就像你不会用博士去做数据录入，也不会用实习生去做架构评审。

Opus 是博士，Sonnet 是高级工程师，Haiku 是执行效率极高的助理。知道什么时候用谁，才是真正的效率。

---

你现在默认用的是哪个模型？有没有遇到过"明明用了最贵的，结果反而更差"的情况？

什么任务让你觉得用 Opus 是浪费，什么任务又觉得非 Opus 不可？