Claude Sonnet 5.5 怎么用：按任务与 effort 档位迁移，别只看跑分

如果团队正在用 Sonnet 5，迁移到 Sonnet 5.5 的问题不是“它分数高不高”，而是哪些任务可以更快完成、每次交付要花多少 token、失败时能不能退回原流程。本文给出一套可执行的试运行方法：先把工作按判断难度拆开，再针对每类任务选 effort，最后用真实任务记录成本、返工与延迟。

Anthropic 的 Sonnet 5.5 发布说明称，它沿用 Sonnet 5 的 $2/百万输入 token、$10/百万输出 token 价格，并在官方测试中对大多数工作实现最高约 30% 的单任务成本降低和 30% 以上的输出速度提升。公告也明确保留了边界：需要持续判断、目标开放且风险较高的复杂工作，Opus 5.5 仍更强。

流程图：模型与 effort 先按任务类别选，再用真实验收结果决定是否继续迁移。

上图把迁移拆成四个可验收环节。不要先改全量默认模型；先从任务样本、effort 设置、结果验收和回滚阈值开始。

先把“要迁移什么”说清楚

把工作塞进“编程”“写作”这类大类，通常得不到可复用的路由规则。更有用的是记录任务的边界、错误代价和是否需要人做最终判断。

这里的“明确”不是提示词写得长，而是验收条件能否写成检查项。例如“修复登录超时”应附上复现步骤、测试命令和不得改动的接口；“做管理层简报”应附上数据来源、页数、受众和允许下结论的范围。

effort 不是质量开关，而是预算开关

官方说明中，Claude 应用与 Claude Code 默认 Medium，Claude Platform 默认 High。effort 越高，模型会花更长时间推理和检查；这可能提高任务质量，也会提高延迟和成本。别为所有调用统一设 High。

可以从下面的路由表开始：

note: "将规则放在调用层，便于按任务替换与回滚"
routing:
  routine_fix:
    model: claude-sonnet-5-5
    effort: low
    acceptance: "tests_pass && diff_within_scope"
  documented_change:
    model: claude-sonnet-5-5
    effort: medium
    acceptance: "tests_pass && reviewer_approves"
  ambiguous_decision:
    model: claude-opus-5-5
    effort: high
    acceptance: "evidence_cited && decision_owner_approves"

note: "将规则放在调用层，便于按任务替换与回滚"
routing:
  routine_fix:
    model: claude-sonnet-5-5
    effort: low
    acceptance: "tests_pass && diff_within_scope"
  documented_change:
    model: claude-sonnet-5-5
    effort: medium
    acceptance: "tests_pass && reviewer_approves"
  ambiguous_decision:
    model: claude-opus-5-5
    effort: high
    acceptance: "evidence_cited && decision_owner_approves"

模型 ID、可选 effort 参数与 SDK 字段以 Claude Platform 文档和控制台为准。不要把示例里的字段直接当成某个 SDK 的固定写法。

用 7 天试运行，而不是一次大比拼

挑 20 到 30 个已完成、结果可回看的任务。每个任务至少记录一次旧流程和一次 Sonnet 5.5 流程；同一任务必须使用同一份输入资料、相同的工具权限和相同的验收人。

记录表至少有这几列：

任务编号 | 任务类型 | 模型 | effort | 输入/输出 token | 时延 | 是否一次通过 | 人工返工分钟 | 失败原因

任务编号 | 任务类型 | 模型 | effort | 输入/输出 token | 时延 | 是否一次通过 | 人工返工分钟 | 失败原因

不要只比 token。一次输出少 20% 的 token，却多花 40 分钟人工清理，实际没有节省。可用一个简单指标排序：

单次可用交付成本 = 模型调用成本 + 人工返工分钟 × 团队分钟成本

单次可用交付成本 = 模型调用成本 + 人工返工分钟 × 团队分钟成本

每天下班前看三件事：一次通过率是否下降、返工是否集中在某类任务、是否出现权限越界或无引用结论。出现任一高风险问题时，先把该任务类型路由回旧模型，而不是继续扩大样本。

编程工作流：把模型放在测试和审阅之间

Sonnet 5.5 在官方公布的 Terminal-Bench 4.0 上为 70.6%，但基准不能代替仓库内的真实验收。对代码任务，更稳的流程是把模型输出当作候选变更：

1. 给出 issue、复现命令、受影响目录和禁止修改的范围。
2. 要求先输出计划和风险点，再创建最小 diff。
3. 在隔离分支执行测试、lint 与类型检查。
4. 把 diff、测试输出和模型使用记录交给 reviewer。
5. 通过后再合并；失败时保存失败类型，作为下一轮路由标签。

对于需要关闭前置思考的既有流程，官方特别提示迁移时需要使用新的 between_tools 设置；具体兼容方式请参照 Anthropic 的迁移说明。先在非生产仓库验证，不要直接改全局默认项。

从 Sonnet 5 迁移 API：先过兼容检查，再谈路由

迁移不只是把 model 改成 claude-sonnet-5-5。Anthropic 的迁移说明列出了几处会直接返回 400、或让前端悄悄漏掉内容的差异。至少拿现有请求和回放测试逐项核对：

不要把表格里的字段名当作通用网关配置：平台、SDK 和旧版本可能不同。先用一条不含工具的请求、一条工具调用、一条多轮会话和一次失败重试做冒烟测试；保存请求参数、响应块类型及错误码。确认通过后，再迁移 20–30 条真实任务的路由。

知识工作：把“看起来像成品”拆成可核验结果

发布说明提到文档、幻灯片、电子表格和图表理解是 Sonnet 5.5 的重点场景。这里最容易出现的错误是版式好看，但数字、来源或范围错了。

给任务加一份交付合同：

- 受众：销售负责人
- 输入：Q3 财报、会议纪要、已批准的幻灯片模板
- 允许结论：只总结材料中明确出现的数据
- 必须附带：每个数字的页码或文件名
- 禁止：预测、补全缺失指标、改写公司口径
- 验收：10 页以内；负责人可在 15 分钟内抽查全部关键数字

- 受众：销售负责人
- 输入：Q3 财报、会议纪要、已批准的幻灯片模板
- 允许结论：只总结材料中明确出现的数据
- 必须附带：每个数字的页码或文件名
- 禁止：预测、补全缺失指标、改写公司口径
- 验收：10 页以内；负责人可在 15 分钟内抽查全部关键数字

要求模型先列出“材料中没有回答的问题”。这一步比再加一段华丽提示词更能减少编造。若任务需要跨材料归因或对未来作决定，仍应保留负责人的判断，必要时升级到 Opus 5.5 复核。

成本、缓存和安全边界要同时上线

Sonnet 5.5 的输入、输出、缓存读取价格并不等同于某次任务的总成本。长上下文是否命中缓存、工具调用次数、重试和人工返工都会改变账单。将以下字段打进调用日志：模型 ID、effort、token 用量、缓存读写、工具调用数、重试数、结束原因和验收结果。

发布说明还提到其以针对网络安全能力的防护措施上线，并支持零数据留存等选项。它们不是跳过内部安全评审的理由。实际接入前，应分别确认：数据是否允许离开当前系统、工具权限是否最小化、敏感输出是否会写入日志、以及账户切换时上下文是否符合团队策略。

用一张对照表算清“便宜”是否成立

Anthropic 官方标价为 Sonnet 5.5 输入每百万 token 2 美元、输出 10 美元、缓存读取 0.20 美元；Opus 5.5 分别为 4、20、0.20 美元。这是计费单价，不是每项任务的完整成本。以下是演算示例，并非实测：一项任务输入 100 万、输出 20 万 token，不计缓存和工具费时，Sonnet 约为 2 + 2 = 4 美元，Opus 约为 4 + 4 = 8 美元。若 Sonnet 多花 15 分钟人工返工，还要把这部分团队成本加回来。

官方所说“快 30% 以上”“任务成本最多低 30%”来自其测试条件，不是每个团队都会得到的折扣。请用同一批任务、同一工具权限和同一验收人做对照。若同时换提示词或工具，应作为另一组实验记录。

把回退规则写在上线前

按任务类设阈值，而不是全局一刀切。示例：某类任务首次通过率比旧路径低超过 5 个百分点，或 P95 用时高于旧路径 20%，或出现一次越权工具调用，就回退该类任务并复盘。这些阈值仅作示意，实际应按团队风险承受能力设定。保留旧模型配置、提示词版本、工具权限和测试集，确保回退是切换路由而非临时重建。

试运行结束时，给每类任务写一句结果：哪个 effort、多少样本、首次通过率多少、平均返工几分钟、完整交付成本如何、哪些错误仍需 Opus 或人工复核。这张表才是下一次模型升级仍能复用的资产。

发布前清单

• [ ] 任务已按边界清晰度和错误代价分层
• [ ] 每类任务都有可自动或人工执行的验收条件
• [ ] Low、Medium、High 至少各有一个真实样本
• [ ] 调用日志包含 token、缓存、时延、工具调用与返工时间
• [ ] 生产变更经过测试、代码审阅和可回滚发布
• [ ] 不能接受的错误类型已经写成路由回退规则
• [ ] 模型 ID、参数和数据留存设置已在控制台核对

Sonnet 5.5 的价值不在于把所有任务替换成同一个模型，而在于让边界清楚的工作更快进入可验收状态。先把任务、effort 和验收记录在同一张表里，团队才能知道省下的是 token，还是完整交付的时间。

一手资料

• Introducing Claude Sonnet 5.5
• Claude Platform documentation
• Building with Claude Sonnet 5.5