Sonnet 5.5还是Opus 5.5？修Bug、审代码和复杂改动怎么选

边界清楚的编程任务，可以先评估 Sonnet 5.5；需要更复杂判断、问题含糊或反复失败的任务，可把 Opus 5.5 加进测试。这是一种按工作负载选候选模型的方法，不证明 Sonnet 必定能处理小任务，也不证明 Opus 一定赢得大任务。验收仍以仓库测试和审核标准为准。

Anthropic 把 Sonnet 定位为更快、成本更低的 Opus 补充，把 Opus 用于需要审慎判断的复杂工作。但计费项目和 effort 配置让选择不止于“Sonnet便宜一半”。本文依据 2026 年 9 月 29 日核对的文档，不声称做过原创模型对测。

价格表不能直接决定选谁

来源：Sonnet规格和Opus规格。这是厂商价格，不是订阅额度或 Ofox 报价。反复使用仓库上下文时，尤其应看缓存读取这一行：较大的缓存前缀，并不存在未缓存输入和输出那样的两倍价差。

假设两次请求都读取 100,000 个缓存 token，并产生 2,000 个计费输出 token，不计其他项目。Sonnet 的费用为 0.04 美元，Opus 为 0.06 美元。这是算术示例，因缓存读取同价，合计费用并非两倍关系。如果某款需要额外轮次，比较结果还会变化。

把任务对应到可以验收的结果

这些是测试设计，不是实测通过率。短补丁也可能需要很难的推理，大量机械修改反而可能简单。单靠文件数量或改动行数，无法可靠衡量任务难度。

看基准结论时保留测试条件

Artificial Analysis的Sonnet发布评测展示了多项较强成绩，也指出 max 档的输出消耗高得多。报告同时说明，测试用的预发布部署存在结构化输出问题，相关项目将重跑。这些结果可以支持同时评估两款模型，却不能直接确定你最省钱的配置。

拿 Opus medium 与 Sonnet max 对测，得到的是配置比较，不能称作只改变模型的对比。这样的测试仍然有价值，但要公开两边设置与实际预算。同名 effort 也不保证算力相同。

Anthropic 的发布说明也描述了不同模型的长处和评估条件。厂商主张、独立测量与自己的观察应分开记录。图表不一致，可能只是任务或设置不同，并不一定存在无法解释的矛盾。

设定简单的升级处理规则

运行前先写停止条件，例如只提出一次修复并做回归检查。检查失败后，先看失败原因再重跑。如果模型误解了任务，应先澄清输入，不要盲目提高 effort。如果方向正确却写不出有效修复，再尝试 Opus 就是一次有价值的受控升级。

新运行应带上问题说明、相关文件与测试结果。不要假设带签名的思考块可以跨模型通用。Sonnet 5.5 对模型和对话有特定规则，见迁移指南。应保留可见证据，不要依赖隐藏思考状态自动延续。

第一次尝试与升级后的费用要一起记录。否则路由系统可能把前一次失败算到一个模型头上，却只统计另一个模型最后成功的成本，让结果显得虚假便宜。审核时间也要保留：能编译、但仍需要大量清理的补丁，还不算完成任务。

同一对模型，三种不同的费用关系

下表固定 token 数量，采用标准服务的供应商牌价，不含其他收费。它们是合成算例，用来先分清计费差异，不能当作模型表现测量。

Opus 五分钟、一小时缓存创建价分别为每百万 token $5 和 $8，Sonnet 为 $2.50 和 $4。若各模型各自写入一次 100K 五分钟缓存、随后读取九次，且十次每次输出 2K token，Sonnet 小计 $0.63，Opus $1.08。具体是 Sonnet 的 $0.25 创建 + $0.18 读取 + $0.20 输出，以及 Opus 的 $0.50 + $0.18 + $0.40，约为 1.71 倍，不是固定两倍。

不要假设换模型还能沿用此前缓存；这个例子为各模型分别计算首次写入。实际生成数量和复用情况也可能不同。低费率模型如果尝试次数翻倍，优势可能消失；昂贵模型如果只是生成更长解释、依然交付同一个失败补丁，也不值得选。

什么样的“困难”值得提前加入 Opus？

难度经常来自正确行为尚不明确，而非改动量。改一行授权判断，可能比替换三十个文件的 API 名称更需要谨慎。Anthropic 对 Opus 的定位，使它适合作为长流程、重判断任务的候选，但不能保证任何一行 Bug 都需要 Opus。

先问四个问题：根因是否还不清楚？需求是否互相冲突？结果能否产生高成本副作用？验收是否需要权衡方案，而不只是核对确定答案？多个答案为“是”，可以支持在提交补丁前增加第二种配置的试验，并不意味着可以扩大工具权限。

有失败快照测试的局部格式问题，可以从 Sonnet 开始，要求目标测试和周边回归一起通过。支付重试可能重复扣款，则验收必须覆盖幂等性、部分失败与恢复；必要时让 Opus 参与调查，但敏感改动仍使用测试夹具和人工审阅。更强的模型不能替代隔离外部副作用。

架构任务可以要求两个候选都列约束、方案和可回滚迁移步骤。判断方案是否匹配实际代码和部署限制，不能只看图画得是否自信。要求引用相关模块，并说明每个中间状态如何保持有效。如果缺少这些输入，先补资料，不要把意见不一致直接归因于模型差。

首次调用前就设置升级预算

一个简单策略是：一次有范围限制的 Sonnet 尝试，失败后先诊断，再决定补充任务信息还是升级到 Opus。不要无限重发不变的提示词。缺依赖、测试夹具损坏时，换模型不会修复环境；应先修测试条件，将该事故与推理失败分开。

假设每次 Sonnet 费用 $0.06，每次 Opus 升级费用 $0.12，且每任务最多升级一次。升级比例为 e 时，每个提交任务的平均 token 成本是 $0.06 + $0.12e。e = 25% 时为 $0.09；e = 50% 时为 $0.12，等于假设下直接用一次 Opus。超过 50%，这个路由策略就比直接基线更贵。

这不是通过率预测。它没包含成功率差异、上下文准备、缓存状态、人工审阅和延迟。Opus 若也失败或增加轮次，要继续累计。报告同时展示每个合格任务成本和未解决比例。对紧急任务，平均费用更低也可能不是好策略，因为真正重要的任务总要多等一次升级。

给第二个模型一份可核对的交接材料

升级时提供简短的可见记录：预期行为、当前 commit、复现命令、真实报错、尝试过的补丁、拒收原因；只带相关文件或下一轮可访问的引用。根因仍不明确时，先要求解释根因，再改补丁，避免重复已经证伪的假设。

交接材料不能写成“上个模型说 X，因此 X 就是真的”。把实际测试输出与模型解释分开。第一轮修改过文件，则重置到共同基线，或者明确记录第二轮不同的起点。否则 Opus 的表面成功可能有 Sonnet 已完成工作的贡献，表面失败也可能继承了损坏的工作区。

审查任务要逐条验证：文件和行号、触发条件、可复现后果，以及问题是否在补丁前就存在。重叠发现先去重再计数。第二个模型可以质疑第一种解释，但两个模型同意，仍不等于缺陷已经复现。

最后把选择落实到任务类别

高频、定义清楚、容易验收的工作保留 Sonnet 候选；不确定或失败成本高的工作加入 Opus，并保留直接 Opus 的基线，判断“先试再升级”本身是否浪费。样本若显示某类任务经常升级，先排除提示词差或集成故障，再考虑直接路由。

按任务类别复盘策略。检索仓库、实现和最终审阅可能各有需要，但拆分也有交接开销；不能只测其中一段就声称整个流程省钱。订阅用户可使用同样的质量和耗时框架，但不要用 API 算式替代账户额度。最终决策应说明哪些任务交给谁、依据是什么，以及什么新证据会改变选择。

使用订阅时要另外确认什么

不能把 API 价格表直接换算成 Claude Code 的精确可用提问次数。订阅额度与使用限制受账户和服务条件影响。客户端更新或供应商变化后，尤其要确认实际选择的模型，并把计费模式与模型名分开记录。

Claude Code设置指南介绍版本检查与明确选模；effort指南区分 API 与 Claude Code 默认值。考虑其他厂商时，可按 Sonnet与Sol比较指南设计受控测试。