Claude Opus 5 迁移别只改模型名，先做一张任务级验收表

Anthropic 在 2026 年 7 月 24 日发布 Claude Opus 5API 模型名为claude-opus-5。官方价格与 Opus 4.8 相同每百万输入 token 5 美元、输出 token 25 美元同时提供约为默认速度 2.5 倍的 Fast mode价格是基础价两倍。新模型还可以通过 effort 调节思考投入。这些信息看起来很适合直接迁移但“同一 token 价格”并不等于“同一任务账单”。模型可能少走几轮也可能在高 effort 下生成更多推理 tokenFast mode 改变时延也改变单价。真正需要验证的是同一个业务任务能否一次过线、总共消耗多少、失败后如何恢复。先把任务、档位和结果放在同一条记录里迁移样本不要只选简单问答。应该从生产记录中抽取三类任务当前模型稳定完成的常规任务、经常需要人工补救的边界任务、以及曾经出现严重错误的回归任务。数据要先脱敏并保留原来的验收标准而不是为了新模型临时降低门槛。每次运行至少记录这些字段case_id固定任务编号 modelclaude-opus-5 / 原模型 effort测试使用的档位 modedefault / fast input_tokens、output_tokens实际用量 turns从开始到交付共几轮 tool_calls、tool_errors工具使用与失败 wall_time端到端时间 accepted是否通过原有验收 human_minutes人工检查和修订耗时 failure_type事实、逻辑、工具、格式或权限问题这里不需要先假定哪个 effort 最好。对每类任务选低、中、高几个档位运行比较的是“被接受任务的总成本”而不是单次请求价格。若低 effort 首答便宜但经常要补问两次最后可能比高 effort 一次完成更贵。官方在 Frontier-Bench v0.1 和 CursorBench 3.2 中展示了 Opus 5 的性能与任务成本优势其中 CursorBench 在 max effort 下接近 Fable 5 的峰值分数官方称任务成本约为其一半。这些结果能说明 effort 曲线值得测却不能替代团队自己的仓库、工具和完成标准。把“会自我验证”变成能观察的事件Anthropic 特别强调 Opus 5 更善于核对工作并持续修正。发布文章列了几个案例它为看不到原图的 FreeCAD 任务自行写视觉处理流程修复开源包 bug 时找到根因和社区补丁遗漏的边界在没有实时行情可对照时为交易所数据接入自行搭建测试 harness。迁移测试不能只在最后给一个主观质量分。应把过程拆成可观察事件模型是否先识别未知条件是否运行测试测试失败后修改了什么是否把表面症状误当根因最终报告是否与实际测试结果一致。代码任务可以要求保存补丁、测试命令、退出码和失败日志。数据任务可以保存校验规则、异常样本和重跑结果。模型说“已经验证”不算证据只有可重放的命令或对照结果才算。还要设计诱导失败。给一个已有表面修复但仍留有边界问题的样本观察模型会不会停在显眼答案移除一个外部验证源看它是说明无法确认还是建立合理替代测试。这样才能判断官方描述的“更彻底”是否出现在自己的任务里。上线顺序由失败类型决定不由总分决定一轮评测后把任务分成四类。第一类是 Opus 5 在较低 effort 已稳定过线可以优先迁移第二类需要高 effort 才过线适合低频、高价值工作第三类只有 Fast mode 满足时延要求需要单独计算加速溢价第四类仍出现不可接受的事实、权限或工具错误继续留在旧流程。迁移时保留小流量对照。记录每个请求的模型、effort、模式和配置版本出现回归时能切回 Opus 4.8而不是只能回滚整套应用。安全分类器也可能影响结果官方说明部分被标记的 Opus 5 请求可 fallback 到其他模型。若启用 API 自动 fallback日志必须标出实际执行模型否则团队会把降级模型的结果记在 Opus 5 名下。验收还应把人工时间算进去。一项任务模型费用下降但审查从五分钟增加到二十分钟业务成本并没有改善。相反token 单价相同、总用量略高却把多轮返工变成一次交付也可能值得迁移。Opus 5 的发布数据给出了候选方向同价升级、可调 effort、可选 Fast mode以及更强的长任务核对能力。工程团队真正需要交付的不是一张模型榜单而是一张能回答“哪类任务、用哪个档位、花多少钱、怎样证明完成”的验收表。官方来源Introducing Claude Opus 5Anthropic2026-07-24Claude models explainedAnthropic2026-07-24。