企业官网建设流程全解析

008、模型选择策略：Opus、Sonnet、Haiku 的定位与按场景切换方法论

上周五凌晨两点，一个生产事故把我从床上拽起来。Claude Code 在 CI 流水线里跑了一个代码审查任务，结果卡了整整 18 分钟——不是网络问题，不是 API 限流，是我手贱把 Haiku 塞进了需要深度推理的场景。那个 PR 涉及跨模块的架构重构建议，Haiku 在 token 预算内根本撑不住上下文，反复输出“建议拆分模块”这种废话，最后 timeout 了。

这事让我重新审视了一个被很多人忽略的问题：Claude 的三个模型——Opus、Sonnet、Haiku——不是简单的“大中小杯”，它们是三种完全不同的思维模式。选错了，轻则浪费钱，重则像我这回一样炸掉流水线。

三个模型的真实性格

先别急着看官方文档的参数对比，我用实际踩坑经验给你画个像。

Opus是那个在会议室里能跟你吵三个小时的老专家。它不急着给答案，会反复咀嚼你的问题，甚至反问“你确定这个前提成立吗？”代价是慢，非常慢。我做过测试，同样一段 5000 行的代码审查，Opus 平均耗时 47 秒，Sonnet 只要 12 秒。但 Opus 能发现 Sonnet 漏掉的跨模块依赖问题——那种“A 模块改了接口但 B 模块没更新”的隐蔽 bug，Sonnet 经常视而不见。

Sonnet是团队里那个干活最快的高级工程师。它理解力强，输出质量稳定，大部分日常任务交给它最省心。我现在的默认配置就是 Sonnet，只有遇到明确需要“深度思考”的场景才切 Opus。Sonnet 的弱点在于：当问题需要多步推理时，它偶尔会走捷径。比如让它设计一个分布式锁方案，它可能直接给出 Redis SETNX 的经典实现，但不会主动考虑“如果 Redis 挂了怎么办”这种边界情况。

Haiku是最容易被误解的模型。很多人觉得它“弱”，其实不是。Haiku 的优势在于极致的速度和低成本，但它需要你喂给它高度结构化的输入。它像那个执行力超强的实习生——你给清晰的指令，它跑得飞快；你给模糊的需求，它就给你一堆废话。我踩过的坑就是拿 Haiku 做代码审查，它根本 hold 不住需要全局理解的场景。

按场景切换的实战方法论

别想着用一个模型打天下。我现在的做法是：在 Claude Code 的配置里写一个场景路由层，根据任务特征自动切换模型。

场景一：代码审查与架构评审

这个场景对推理深度要求最高。我遇到过最典型的案例：一个 PR 改了数据库连接池配置，Sonnet 审查后说“配置合理”，但 Opus 发现这个改动会导致某个边缘 case 下的连接泄漏——因为新配置没有考虑事务超时后的连接回收机制。

我的规则：涉及跨模块、跨层的代码变更，或者 PR 描述里出现“重构”“架构调整”“方案设计”这些关键词，强制走 Opus。其他常规 CR 交给 Sonnet。

代码里这样写（别直接复制，这是伪代码风格）：

# 这里踩过坑：别用模型名称硬编码，用场景标签defselect_model_for_review(pr_description,changed_files):# 检测是否涉及架构级变更architecture_keywords=['重构','架构','模块拆分','接口变更']ifany(kwinpr_descriptionforkwinarchitecture_keywords):return'opus'# 架构评审必须上 Opus# 检测变更范围iflen(changed_files)>10orany('core/'infforfinchanged_files):return'opus'# 核心模块变更，别省这个钱# 常规代码变更，Sonnet 足够return'sonnet'

场景二：代码生成与补全

这是 Haiku 的主场。但有个前提：你必须把上下文喂得足够干净。

我犯过的错误：让 Haiku 生成一个微服务接口，给了它整个项目的目录结构。结果 Haiku 在 2000 token 内根本消化不了，输出了一堆“根据项目结构，建议创建 controller 层”这种废话。后来改成只给接口定义文件和依赖的 DTO 类，Haiku 的输出质量直接起飞。

经验值：Haiku 的上下文窗口虽然大，但它的有效推理深度大概只有 4000 token。超过这个量，它的输出质量会断崖式下跌。所以用 Haiku 时，输入要精炼，输出要短小。

# 别这样写：把整个项目上下文都塞给 Haiku# haiku.generate("根据这个项目结构，帮我写一个用户注册接口", context=full_project)# 应该这样：只给最小必要上下文haiku.generate("实现 UserController 的 register 方法，输入是 RegisterRequest，输出是 UserResponse",context={'interfaces':['RegisterRequest','UserResponse'],'style_guide':'使用 RESTful 风格，异常用全局处理器'})

场景三：调试与问题排查

这个场景最复杂，需要动态切换。我的策略是“先快后深”。

遇到 bug 时，先用 Sonnet 做快速诊断。Sonnet 能在 5 秒内给出初步判断，比如“这个 NullPointerException 可能是由于 service 层没有注入依赖”。如果 Sonnet 的结论能直接解决问题，那就到此为止。

但如果 Sonnet 给出的方案试了没用，或者问题涉及复杂的并发、内存、网络问题，立刻切 Opus。Opus 会从系统层面分析，比如“这个死锁不是因为锁的顺序问题，而是因为事务隔离级别导致的行锁升级”。

# 调试场景的动态切换defdebug_with_claude(error_log,code_context):# 先用 Sonnet 快速诊断sonnet_result=sonnet.analyze(error_log,code_context)# 如果 Sonnet 的置信度低，或者问题涉及系统级ifsonnet_result.confidence<0.7or'可能'insonnet_result.suggestion:# 这里踩过坑：别直接覆盖 Sonnet 的结果，要对比分析opus_result=opus.analyze(error_log,code_context)returnmerge_analysis(sonnet_result,opus_result)returnsonnet_result

场景四：批量任务与流水线

CI/CD 流水线里的任务，对成本和速度敏感。我的原则是：能用 Haiku 绝不用 Sonnet，能用 Sonnet 绝不用 Opus。

但有个例外：流水线里的“门禁”任务——比如代码规范检查、安全漏洞扫描。这些任务如果误报，会阻塞整个发布流程。所以门禁任务我强制用 Sonnet，确保判断准确。而像“自动生成 changelog”“格式化代码”这种非关键任务，全部交给 Haiku。

# pipeline 配置示例（别直接复制，这是思路）pipeline:stages:-name:code_style_checkmodel:haiku# 格式检查，快就行-name:security_scanmodel:sonnet# 安全相关，需要准确-name:architecture_reviewmodel:opus# 架构评审，必须深度-name:auto_changelogmodel:haiku# 非关键任务，省钱

成本与性能的平衡艺术

很多人问我：“Opus 那么贵，是不是大部分场景用 Sonnet 就够了？”

我的回答是：看你的业务容忍度。如果一次代码审查出错，可能导致线上故障，那 Opus 的成本就是保险。但如果你的项目是内部工具，出错影响不大，那 Sonnet 完全够用。

我算过一笔账：一个中型项目，每天 100 次代码审查。全部用 Opus，月成本约 800 美元；全部用 Sonnet，约 200 美元；混合策略（20% Opus + 80% Sonnet），约 320 美元。混合策略比全 Sonnet 多花 120 美元，但减少了大约 70% 的漏审问题。

这个账怎么算，取决于你的项目价值。

个人经验总结

写了这么多，其实就一句话：别把模型当工具，把它当团队成员。Opus 是架构师，Sonnet 是高级开发，Haiku 是实习生。你不可能让实习生去设计系统架构，也不可能让架构师去写 CRUD。

最后给三个实操建议：

1. 在 Claude Code 的配置里写一个模型选择函数，根据任务特征自动路由。别手动切，人总会偷懒，一偷懒就出事。
2. 给每个模型设置 token 预算上限。Opus 的 token 消耗是 Sonnet 的 3-5 倍，不加限制的话，一个复杂任务能吃掉你一天的配额。
3. 建立反馈闭环。每次模型输出后，记录它的表现。如果某个场景下 Sonnet 频繁出错，就把它升级到 Opus。反过来，如果 Opus 在某个场景下表现平平，就降级到 Sonnet 省钱。

模型选择不是一劳永逸的事。Claude 的模型在迭代，你的业务也在变化。保持对模型能力的敏感度，比任何固定策略都重要。