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

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 模块没更新”的隐蔽 bugSonnet 经常视而不见。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):returnopus# 架构评审必须上 Opus# 检测变更范围iflen(changed_files)10orany(core/infforfinchanged_files):returnopus# 核心模块变更别省这个钱# 常规代码变更Sonnet 足够returnsonnet场景二代码生成与补全这是 Haiku 的主场。但有个前提你必须把上下文喂得足够干净。我犯过的错误让 Haiku 生成一个微服务接口给了它整个项目的目录结构。结果 Haiku 在 2000 token 内根本消化不了输出了一堆“根据项目结构建议创建 controller 层”这种废话。后来改成只给接口定义文件和依赖的 DTO 类Haiku 的输出质量直接起飞。经验值Haiku 的上下文窗口虽然大但它的有效推理深度大概只有 4000 token。超过这个量它的输出质量会断崖式下跌。所以用 Haiku 时输入要精炼输出要短小。# 别这样写把整个项目上下文都塞给 Haiku# haiku.generate(根据这个项目结构帮我写一个用户注册接口, contextfull_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_resultsonnet.analyze(error_log,code_context)# 如果 Sonnet 的置信度低或者问题涉及系统级ifsonnet_result.confidence0.7or可能insonnet_result.suggestion:# 这里踩过坑别直接覆盖 Sonnet 的结果要对比分析opus_resultopus.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。最后给三个实操建议在 Claude Code 的配置里写一个模型选择函数根据任务特征自动路由。别手动切人总会偷懒一偷懒就出事。给每个模型设置 token 预算上限。Opus 的 token 消耗是 Sonnet 的 3-5 倍不加限制的话一个复杂任务能吃掉你一天的配额。建立反馈闭环。每次模型输出后记录它的表现。如果某个场景下 Sonnet 频繁出错就把它升级到 Opus。反过来如果 Opus 在某个场景下表现平平就降级到 Sonnet 省钱。模型选择不是一劳永逸的事。Claude 的模型在迭代你的业务也在变化。保持对模型能力的敏感度比任何固定策略都重要。