Anthropic 放出 Claude Sonnet 5.5 的同一天，官网上多了一份《Building with Claude Sonnet 5.5》构建指南。真正值得读的不是模型卡上的分数，而是这份指南本身——它罕见地把"你该选哪个型号"摆到台面上讲。Sonnet 5.5 与 Opus 5.5 之间的取舍、从 Sonnet 5 迁过来的路径、Claude Code 里的用法差异，三条线拧在一起，说的其实是同一件事：模型选型早就不是"挑最强的那个"，而是挑一条你养得起的成本曲线。
选型不是排行榜问题，是账本问题
Sonnet 5.5 和 Opus 5.5 的分界线画在哪里
指南没有给出"谁更强"这种结论，这恰恰是关键信息。Sonnet 5.5 面向的是高频、可批量、错了还能重来的调用场景；Opus 5.5 留给那些一步走偏、后面全盘皆输的硬骨头。两者的差距不在"能不能做对"，而在"做对的概率落在哪个位置"。举个假设的例子：某类任务准确率从九成提到九成七，单次成本涨三倍，这笔账划不划算，取决于下游要为此付出多少人工复核。复核一小时的成本，往往比多跑几百次调用贵得多。
什么活儿值得为 Opus 5.5 多付钱
我倾向于把任务分成两类来想。一类是"错了能发现"的活，比如生成草稿、分类打标、批量改写，这类交给 Sonnet 5.5 完全够用，多花的钱买不到额外安心。另一类是"错了要很久才知道"的活，比如架构级重构、复杂状态机推理、涉及资金或权限的判断链路——这种场景里，Opus 5.5 的溢价更像是保险费，而不是性能消费。
一个常被忽略的指标：返工率
大部分团队评估模型时只看首轮成功率，但生产环境里的真实成本藏在返工里。一个模型如果第一次没做对，你要付出的是重新编排提示、重新调上下文、再由人去核对的三重开销。Sonnet 5.5 在这件事上的表现，比它单轮的正确率更值得测。测量方式也不复杂：挑二十条真实请求跑两轮，看有多少条需要人工兜底，这个数字比任何榜单都贴近你的账单。
迁移的坑不在模型名，在参数
effort 这个旋钮，比换模型更容易翻车
把代码里的 sonnet-5 改成 sonnet-5.5，然后跑一遍测试，绿灯，上线——这条路看着最省事，也最容易在两周后出事。指南里专门提到要从 Sonnet 5 迁移并重新调整 effort，原因很简单：新旧版本对推理投入的敏感度不同。你在旧版上调到"刚刚好"的那个档位，换到新版可能就是过度思考，延迟翻倍，或者反过来思考不足、边界情况漏掉。这个旋钮不是可选项，它是迁移的一部分。
旧提示词里那些说不出口的假设
长期迭代的提示词通常积累了隐性依赖。比如某句"请一步步分析"在 Sonnet 5 上能稳住输出格式，到 5.5 上新模型可能直接给了结论——因为它判断这一步不值得展开。文档里没写，测试用例也覆盖不到，只有线上真实流量会把它撞出来。迁移前把核心提示词过一遍，删掉那些纯粹为了"压住旧模型脾气"的指令，比加新指令更有用。
灰度迁移比一次性切换便宜得多
别做全量切换。把新模型放到流量占比一成的位置上，跑够一个完整业务周期——包括月末结算、批量任务、异常高峰这些平时测不到的时刻——再决定加不加码。这套做法听起来保守，但它的成本只是一次配置改动；一次性切换的成本，是事故之后所有人回头看日志的那些小时。
在 Claude Code 里，Sonnet 5.5 是另一种用法
多文件改动和长任务才是它的主场
终端里的编码助手跟 API 调用不是一回事。Claude Code 面对的是跨越十几个文件的重构、需要反复读代码才能定位的 bug、以及持续几十分钟的任务链。这种场景下，模型需要的不是单点聪明，而是长时间不跑偏。Sonnet 5.5 在这个位置上比较合适：它足够快，能在交互节奏里给出反馈；也足够稳，不会在三轮工具调用之后忘记自己本来要干什么。
把 effort 拧低，反而跑得更顺
这一点听着反直觉。很多人在 Claude Code 里习惯把思考强度拉满，觉得编码任务复杂，就该多算。实际体验经常相反：高强度推理让模型在每一步都反复权衡，工具调用轮次变多，上下文迅速膨胀，最后被自己的中间结论带偏。改代码这类任务，方向确认之后执行是机械的，把 effort 放到中档，配合明确的任务边界，往往比拉满跑得更干净。
用它的正确姿势是切小任务
别指望一句话让它完成整个模块。把"重构用户服务"拆成"先列出所有调用点""再逐个替换接口""最后跑测试"，每一步单独交付。这么做不只是为了模型好受，也为了你自己好受——每一步都能验证，出错时定位成本压到最低。模型的上下文窗口再大，也救不了任务描述本身的含糊。
什么时候动手，什么时候再等等
适合第一批切换的团队
如果你的产品已经在用 Sonnet 5 扛主力流量，任务类型以生成、改写、分类、检索增强为主，那这次升级路径很短：调整 effort、跑通灰度、观察返工率。收益是现成的——延迟和单位成本大概率都有改善。这类团队没必要等，等来的只是竞争对手先跑一个月的量。
观望的代价被高估了
另一类团队该按住手：提示词体系庞大、迁移窗口紧、业务对输出格式极度敏感。对你们来说，Sonnet 5.5 的新能力不是重点，稳定性才是。晚一个季度切换不会损失什么，尤其在 Sonnet 5 仍然可用的情况下。真正要避免的不是"错过新模型"，而是"在业务高峰期做一次没测透的切换"。
先做这三件事，再谈上线
不管属于哪一类，动作顺序可以统一。先建一套小规模评测集，用真实请求而不是造出来的样例；再把 effort 当成独立变量跑对照，固定其他条件；最后把返工率和人工兜底时长记进监控，跟首轮成功率放在同一张看板上。这三件事做完，选 Sonnet 5.5 还是 Opus 5.5，答案会自己浮出来，不需要靠猜。
