Claude Opus 5：别只看 Token 单价，要算每个可验收结果的成本
一套面向创始人的 Claude Opus 5 评估方法，把可验收结果、effort 档位、重试、人工复核、延迟与产品风险放进同一张决策表。
Anthropic 在 7 月 24 日发布了 Claude Opus 5，API 单价与 Opus 4.8 相同：每百万输入 token 5 美元、每百万输出 token 25 美元。新模型提供五档 effort，默认启用自适应思考，支持 100 万 token 上下文，并被定位于高难度智能体和企业工作。早期独立评测也显示，更高 effort 可能提高复杂知识工作的完成质量，但单个任务的平均耗时可能超过 25 分钟。
这组信息很容易让 AI 应用构建者得出一个过于乐观的结论：能力更强、标价没涨，那就直接升级。问题是，这并不是一次免费的生产升级。思考 token、更长输出、更多轮次、工具调用、自动重试、人工复核与等待时间，都会改变“交付一个用户真正能用的结果”所需的总成本。
因此，对非技术创始人和小型产品团队来说，真正的问题不是“Opus 5 是否更强”，而是：在哪些具体工作里，Opus 5 能用更少的总成本、更少的复核时间和可接受的等待，产出更多可验收结果？
本文把模型发布转成一项产品决策。你将得到清晰的术语、一张可复用的成本记录表、effort 路由矩阵、一个客服升级场景、一套小团队可执行的评估流程、常见误区、上线规则，以及“不应默认使用 Opus 5”的边界。本文不是 YBuild 对 Opus 5 的实测报告，也不会把厂商演示或单一外部 benchmark 当成你的应用可靠性。
Claude Opus 5 改变了什么，又没有证明什么
Anthropic 的 Opus 5 官方说明 不只是宣布一个新模型名称。Opus 5 提供 100 万 token 上下文、最多 128,000 token 输出、默认自适应思考、从 low 到 max 的五档 effort、更低的 512 token prompt cache 门槛，还新增了对话中途调整工具和服务端 fallback 等 beta 能力。Anthropic 称，提升最明显的方向包括深度推理、长程智能体任务、代码审查、长上下文、办公文档和多智能体协作。
标价没有上涨。Anthropic 当前的 价格表 显示，Opus 5 的基础输入为每百万 token 5 美元，输出为 25 美元，五分钟 cache 写入为 6.25 美元，cache 命中为 0.50 美元。Fast mode 是单独的研究预览，输入与输出单价都是基础模式的两倍。AWS 也已确认 Opus 5 可通过 Amazon Bedrock 与 Claude Platform on AWS 使用，并提供不同的数据治理选项。
这些都是可靠的产品事实，但它们没有证明：
- 你的旧 prompt 在升级后仍会消耗相同数量的 token；
- 提高 effort 一定能提升你自己的验收指标；
- 既然有 100 万 token 窗口，就应该把所有资料都塞进去；
- 更长、更漂亮的回答一定更省复核时间；
- 更多轮工具调用仍能满足面向用户的延迟承诺；
- 通过通用 benchmark 的结果，就会遵守你的业务政策、引用正确来源或准确更新系统状态。
比较模型前，先定义六个术语
如果团队没有先约定“成功”“质量”和“成本”分别指什么，模型比较很快就会失真。至少先定义以下六个术语。
一次尝试（attempt）：从收到一个有效用户请求开始，到工作流进入终止状态为止的一次完整运行。如果编排层在后台静默重试两次，用户只发起了一次请求，但公司实际支付了三次尝试。 有效完成（valid completion）：用户需要的最终状态确实存在，而且整个过程遵守了必要政策。客服建议写得再流畅，如果引用的是过期政策，也不算有效完成；生成的应用页面再漂亮，如果结账流程无法使用，同样不算。 可验收结果（accepted outcome）：已经有效完成，并通过书面产品标准的结果。标准可以覆盖事实正确性、证据完整度、政策合规、结构化输出、语气、延迟、无障碍与必要的人工批准。“看起来不错”不是稳定的验收定义。 复核分钟（reviewer minute）：具备相应资格的人用于检查、修改、批准或恢复结果的时间。政策专家花掉的十分钟，不能因为 API 账单很低就从经济账里消失。 每次尝试成本（cost per attempt）：本次运行涉及的模型 token、cache、工具与检索、基础设施，以及可直接归因的人工复核和恢复成本。 每个可验收结果成本（cost per accepted outcome）：评估期内所有尝试的总成本，除以通过验收的结果数量：cost_per_accepted_outcome =
(model_cost
+ cache_cost
+ tool_and_retrieval_cost
+ infrastructure_cost
+ reviewer_cost
+ retry_and_recovery_cost)
/ accepted_outcomes
严重的政策或安全失败必须保留为单独的上线硬门槛。不要把它们“折算成钱”，再让一个便宜的平均值抵消不可接受的事故。
Token 单价不变，为什么单位经济性仍会改变
公开价格只是一个乘数。实际模型费用还取决于输入了多少上下文、产生了多少思考与答案 token、调用了多少次工具、cache 是否命中，以及工作流重试了几次。
Opus 5 让这些变量变得更重要。它的 模型总览 说明，API 与 Claude Code 中的 effort 默认是 high。迁移文档还指出，Opus 5 默认启用思考，面向用户的回答通常更长，更常汇报过程，也更愿意把任务交给子智能体；同时，max_tokens 是思考内容与可见答案共同使用的硬上限。直接照搬旧模型配置，可能导致提前截断、成本上升，或交互行为发生变化。
长上下文也会制造一个错误捷径。100 万 token 是容量，不是“请上传所有文件”的指令。上下文越大，越可能引入检索噪声、敏感信息暴露、cache 写入费用、延迟与复核负担。一个经过筛选的最小证据包，完全可能在质量和成本上同时优于未经整理的超长 prompt。
Cache 也会改变结果。如果政策、schema 或文档集相对稳定，重复使用同一前缀，强模型的成本可能因为 cache 命中而显著下降。反过来，频繁重写 system prompt 或改变文档顺序，会破坏这种收益。评估时应记录真实的 cache 读写，而不是把所有输入都按基础输入单价估算。
最后，人工复核可能比模型费用更贵。如果便宜模型给出三份看似合理的草稿，每份都需要专家检查八分钟；而较强模型一次就产出可用结果，只需两分钟复核，那么“token 更贵”的路线反而可能更省钱。相反，Opus 生成的长篇精致答案也可能更难检查，因为其中包含更多需要验证的细节。
怎样阅读早期 benchmark，而不把产品决策外包给排行榜
真正有价值的独立评测，应同时呈现质量、费用与时间的取舍，而不是只宣布一个冠军。Artificial Analysis 在私有的 AA-Briefcase 智能体知识工作 benchmark 上测试了 Opus 5 的五档 effort。其报告中，max、xhigh 和 high 占据前三位；对应的平均单任务费用分别为 17.79、14.26 和 10.41 美元，平均耗时分别为 36.2、34.3 和 25.7 分钟。提升主要来自客观评分项与分析质量，呈现质量的提升相对较小。
这类证据值得关注，因为它把质量、成本和时间放在了一张图里。但它仍然只代表一个机构的私有任务集、评分设计、工具环境与模型配置。它的“每任务成本”，并不等于你的“每个可验收结果成本”。
ARC Prize 提供了另一种信号。其 Opus 5 验证结果 显示，模型在 high effort 下的 ARC-AGI-3 Public Demo 得分为 30.2%，同时明确说明，由于测试窗口较短，ARC-AGI-3 没有完成 max 档测试。这支持模型在特定配置下具备更强的抽象推理能力，却无法回答你的入门助手是否会引用当前价格、客服流程是否会正确执行退款政策，或生成应用是否会守住租户隔离。
正确的阅读方式是：
- Opus 5 的公开证据足以支持一次面向真实工作负载的候选测试。
- Effort 是重要的产品配置，不是装饰性的“质量滑块”。
- 更强能力可能伴随更多轮次和更长等待。
- 公开排行榜可以帮助筛选候选模型，但只有你的验收集能决定生产路由。
先写验收标准，再运行模型
不要先生成一堆结果，再根据自己喜欢的输出临时发明评分标准。评估开始前，就应写清每个案例的硬门槛和评分项。
| 维度 | 硬门槛示例 | 可评分指标示例 |
|---|---|---|
| 最终状态 | 要求的产物或系统更新真实存在 | 必要部分是否完整 |
| 事实 | 不得出现无证据的关键主张 | 重要主张中具备有效证据的比例 |
| 政策 | 不得给出被禁止的建议或动作 | 边界政策处理是否正确 |
| 结构 | 输出可通过指定 schema 解析 | 需要人工修复的格式问题数量 |
| 用户价值 | 回答了用户真正要完成的工作 | 基于明确锚点的实用性评分 |
| 延迟 | 在产品超时前完成 | p50 与 p95 完成时间 |
| 复核 | 合格复核人签字确认 | 复核分钟与修改次数 |
| 恢复 | 失败后没有遗留危险状态 | 定位与恢复所需时间 |
给评分配上锚点。“质量 5/5”过于含糊；“无需修改事实、政策或格式即可发给客户”才可观察。如果两位复核人可能做出不同判断，先用若干样例校准，再比较模型。
普通案例与关键案例必须分开。一封客服回复用错称呼，和承诺了不符合条件的退款，不是同一级别的问题。总体通过率 92%，仍可能掩盖十个最重要案例全部失败的事实。
当产品本来就不应回答时，拒答或保留判断也可以是有效结果。证据不足时主动询问，往往比自信地完成所有案例更有价值。
直接复用这张“每个可验收结果成本”记录表
每次尝试记录一行，而不是每个用户请求只留一行。保留原始数据，方便团队之后审计汇总结果。
| 字段 | 需要记录的内容 |
|---|---|
| 案例 ID | 稳定标识与风险等级 |
| 模型路由 | 服务商、精确模型 ID、effort 档位 |
| 配置 | prompt 版本、检索版本、工具集、cache 策略 |
| 输入 | 基础输入、cache 写入与 cache 命中 token |
| 输出 | 可获取时记录思考与可见输出 |
| 工具 | 调用次数、失败次数、外部 API 成本 |
| 时间 | 排队、首 token、完成、复核与恢复时间 |
| 尝试 | 首次运行、自动重试与人工重试 |
| 验收 | 每项硬门槛与评分维度的通过结果 |
| 人工工作 | 复核角色、分钟数、修改内容 |
| 失败 | 类型、用户影响、是否产生持久副作用 |
| 证据 | trace 或 run ID、最终产物、批准记录 |
随后至少计算四组结果：
- 每次尝试成本：展示原始运行费用；
- 验收率：展示多少次尝试最终变成可用结果；
- 每个可验收结果成本：把费用与产出率放到一起；
- 每个可验收结果的复核分钟：揭示只看美元会遗漏的稀缺人工时间。
不要在比较新模型时，同时更换 prompt、检索系统和评分标准。最好只改变一个主要变量；如果确实整体升级，就把结果标成“系统对系统比较”。生产里最终运行的是完整系统，但团队仍需要知道改进来自哪里。
具体场景：客服升级单协作助手
假设一家 SaaS 小团队要做一个客服升级单助手。每个任务会读取工单历史、账户事实、当前退款政策、事故公告与相关帮助中心文档。助手需要判断问题、引用适用证据、建议下一步、起草客户回复；当账户信息或政策证据不足时必须停下来。它不能自行发起退款。
这是一个值得测试 Opus 5 的工作，因为它同时包含长文档、冲突证据、政策解释、结构化输出与有后果的建议。但这并不预设 Opus 5 一定获胜。
可以从经过权限与隐私处理的真实历史模式中构建评估集：
- 只有一个明确政策答案的普通问题；
- 包含大量无关细节的长对话；
- 旧帮助文档与当前政策冲突的案例；
- 名称相似的账户或套餐；
- 局部故障导致常规处理方式失效的案例；
- 语气激烈、但回复仍需保持克制的消息；
- 缺少必要账户信息的请求；
- 必须升级给人工、不能直接给出建议的案例。
low、medium、high 使用相同配置完成同一批案例。xhigh 或 max 只用于少量真正困难的案例，因为早期外部证据已经显示，这些档位的耗时可能明显增加。
硬门槛可以包括：使用正确政策版本、不编造账户事实、引用有效来源、不做越权承诺、JSON 可解析、证据不足时正确停下。随后再记录复核分钟、修改次数、API 与工具成本、总时间和可验收结果数量。
最后可能得到不同结论：
- 普通案例继续走便宜模型；
- 只有高歧义或高价值客户的升级单才进入 Opus 5；
- Opus 5 先以
medium运行，只有发现证据冲突时才升级到high； - 如果 p95 延迟破坏客服流程，就不把 Opus 5 用于交互场景；
- 如果更少重试和更少专家复核抵消了更高的单次费用，就采用 Opus 5。
按工作难度路由，而不是为所有任务选择同一个默认模型
大多数小团队不需要一个模型包办一切，而需要一套足够简单、可以解释也可以审计的路由规则。
| 工作负载 | 起始路线 | 何时升级 | 不应仅因什么而升级 |
|---|---|---|---|
| 分类、抽取、格式转换 | 快速低成本模型 | schema 持续失败或出现实质歧义 | 输入很长但任务很简单 |
| 面向客户的草稿 | Sonnet 档或当前已验证路线 | 政策冲突、高价值账户、反复被拒 | 用户只想让文字更漂亮 |
| 多文档决策支持 | 候选 Opus 5 medium 或 high | 证据冲突，或低档位未通过标准 | benchmark 把它称为“知识工作” |
| 长程智能体任务 | 有预算边界的 Opus 5 试验 | 规划、恢复或验证确有可测改进 | 更多自主性看起来更先进 |
| 高风险状态变更 | 最佳已验证模型加人工批准 | 永远不能绕过政策或人工授权 | 模型排行榜分数很高 |
路由信号应来自产品状态，例如案例风险、歧义程度、文档冲突、首轮未通过的具体标准、客户等级与延迟预算。不要让模型在没有约束时自行判断“我是不是遇到了复杂任务”，否则过多流量可能被推到昂贵路线。
同时设置升级上限。一次 high 失败后，不能无限自动重试到 max。预先定义模型费用、工具次数、轮次与总耗时上限，超过后交给人工或进入安全 fallback。
把 effort 当成产品控制，不是“越高越好”的按钮
Anthropic 的 effort 文档 把它定义为控制模型响应时使用多少 token 的直接参数。Opus 5 支持 low、medium、high、xhigh 与 max。对业务来说，更高不等于更好。
至少在同一案例集上测试三个档位，并比较：
- 硬门槛通过情况；
- 关键失败类型；
- 总 token 与输出 token；
- 轮次和工具调用数；
- 完成时间；
- 复核分钟；
- 修改严重度；
- 每个可验收结果成本。
medium 与 high 得到相同数量的可验收结果，额外思考可能只是浪费；如果 high 能在困难案例中避免昂贵复核或严重失败，它反而可能是更便宜的路线。
应显式固定 effort。不同产品界面或后续模型版本的默认值可能不同，隐藏默认值会让将来的对比失去意义。评估回执里要固定精确模型 ID、prompt、工具、检索配置、fallback 行为和 effort。
Fallback 也要谨慎处理。若结果实际由另一个模型完成，就不能算作 Opus 5 成功。记录最终执行模型、触发 fallback 的原因，以及产品是否向用户披露行为变化。
最容易得出错误答案的九种比较方式
只比公开单价。 这样会遗漏 token 量、cache、工具、重试、复核与验收产出率。 只用一个惊艳案例。 一次成功只能证明“有可能”，不能证明可重复。应使用具有代表性的案例，并在结果有随机性时重复运行。 把文风当成正确性。 Opus 5 可能写得更长、更完整，但证据、政策与最终状态仍需要检查。 填满上下文窗口。 更多文档可能降低相关性并提高成本。检索满足任务所需的最小证据集，并记录实际使用了哪些来源。 一次更换整套系统。 新 prompt、新模型、新工具和新检索索引可能让产品变好，但你无法把提升归因于 Opus 5。 忽略复核人的专业差异。 通用复核人与领域专家会放过不同错误。关键案例应由合格人员复核，并记录其角色。 把所有风险等级混在一起求平均。 大量简单案例会掩盖少量关键案例中的严重错误。关键门槛必须单独计算。 把拒答一律当失败。 当证据不足或动作超出范围时，保留判断或请求补充信息才是正确产品行为。 允许无限升级 effort。 自动重试可能把一个含糊请求变成又慢又贵的失败循环。到达上限后应询问用户或交给人工。哪些情况不应该默认使用 Opus 5
如果任务足够确定，能够用代码、规则引擎、搜索过滤、数据库查询或 schema 校验完成，就不应默认交给 Opus 5。更强的语言模型不能替代可靠的确定性组件。
也不要用它挽救一个尚未定义清楚的产品。如果团队说不清什么叫可验收结果，更强模型只会产出更有说服力的模糊结果。先修正任务边界、证据、权限与标准。
在获得自有 p95 数据前，不要把它塞进延迟很紧的交互环节。外部测试已经显示，前沿能力可能需要较长运行。自动补全、表单验证或简单分类的用户，并不会从 25 分钟的推理中获益。
不要因为模型能力强，就发送受隐私、驻留地或合规限制的数据。AWS 确实记录了零数据保留与区域选项，但部署路线、数据分类、日志、保留周期、访问控制与供应商条款仍需单独审查。
最后，更强模型不能成为取消关键动作批准的理由。能力与权限是两项不同的产品决策。即使建议本身通过验收，在资金流动、访问权限变化、对外发信或修改生产状态前，仍然可能需要人工确认。
用七天完成一次创始人评估
第 1 天：定义工作。 只选择一个接近生产的流程、一个用户群体与一个终止状态。生成任何结果前，先写好硬门槛和复核锚点。 第 2 天：整理案例。 选择 30–60 个经过权限与隐私处理的案例，覆盖普通、困难、关键和应当保留判断的情况。如果要调 prompt，保留一组冻结的 holdout 案例。 第 3 天：记录基线。 运行当前生产路线，记录尝试、token、工具、时间、验收、复核分钟与失败。 第 4 天：测试 effort。 让 Opus 5 在相同系统配置下运行low、medium 和 high。只有少量高难案例进入 xhigh 或 max。
第 5 天：盲审。 在可行时隐藏模型身份。由合格复核人使用预先写好的标准，标注修改内容与关键失败。
第 6 天：计算结果经济性。 比较验收率、每个可验收结果成本、复核分钟、p95 延迟与关键失败。按风险和难度分组，不要只给一个混合平均数。
第 7 天：做路由决定。 在“采用”“选择性路由”“继续试验”与“暂不采用”中做选择，并记录模型、effort、prompt、检索、工具、预算、fallback、批准、监控与回滚设置。
之后每次更换模型、prompt、检索、政策或工具，都重新运行关键案例集。这样，本次发布评估会变成长期回归资产，而不是一次性的采购演示。
今天真正要做的上线决定
Claude Opus 5 的重要性在于：它以现有 Opus API 单价，提供了更强推理、长上下文、智能体能力与五档 effort。早期独立结果足以让它成为复杂知识工作的认真候选，也同时揭示了真实取舍：更好的结果可能需要更多轮次、更长时间和完全不同的成本结构。
正确反应不是把所有工作流立即切换过去，而是挑一个当前被推理难度或复核成本拖累的任务。先定义可验收结果，再记录完整尝试、比较不同 effort，只在总体结果经济性确有改善，而且没有破坏延迟、政策、隐私与权限边界时，才把对应案例路由给 Opus 5。
真正胜出的不是 token 单价最低或公开分数最高的模型，而是能够以产品承受得起的成本与速度，反复交付有效、可复核、符合政策结果的那条路线。