如果小组现在用的是 Sonnet 4.6我不会建议直接把默认使用的模型切到 Sonnet 5。不是因为 Sonnet 5 不值得试而是默认使用的模型一变很多隐性成本会一起变输出风格、token 统计、工具调用次数、失败重跑、用户对答案长度的期待。默认切换会影响很多小地方先做灰度更稳第一周只让内部工具、知识库问答和代码辅助走 Sonnet 5记录每次工作有没有省掉人工步骤。第二周再把经常出现的低风险工作承担起来。147AI 可以在这个阶段承担同一个入口和日志留存的角色把同一类请求在不同模型上的表现放到一张表里避免靠几次主观体验做决定。还可以保留一个人工抽检池。不是每条都看但每类工作每周至少抽几条看看模型有没有改变口径、有没有把不确定的东西说得太满、有没有把工具错误包装成正常结论。模型默认切换后很多小偏差会藏在日常过程里。先给任务分红黄绿可以特别看三件事第一长上下文工作是否真的减少切分和摘要。第二工具调用有没有少走弯路第三安全拒答和提示注入防护有没有影响正常具体业务。Anthropic 官方说 Sonnet 5 在 Agent 类 safety 上比 Sonnet 4.6 更好但公司自己的 prompt、插件和权限环境不一样还是要自己测。如果公司内部有多个小组共用模型需要不要让每个小组自己定默认研发、运营、客服、法务对失败的容忍度完全不同。同一个入口负责分配具体业务小组负责验收标准这样责任比较清楚。灰度时可以把工作分成红黄绿三类绿色是可重跑的草稿和解释黄色是需要人工确认的内部材料红色是客户承诺、财务、权限和生产写入。Sonnet 5 可以先吃绿色工作黄色工作保留确认按钮红色工作只做建议这样小组不会因为一次模型升级把风险等级混在一起。默认使用的模型还会影响小组习惯用户一旦发现模型能处理更长、更复杂的问题就会把问题越写越大这个变化要纳入测试不然最初例子很短投入使用后真实输入突然变长成本表就会失真。可以把默认切换拆成两个决定先决定哪些工作允许用 Sonnet 5再决定这些工作是否默认使用它。前者是能力判断后者是预算和风险判断两个问题混在一起会议很容易变成“支持新模型”和“反对新模型”的争论。不要让各部门各自切模型默认使用的模型这件事最后需要按工作分层普通问答可以走 Sonnet 5复杂安全工作可能还是 Opus批量离线处理再考虑 Batch这样 9 月价格切换时财务和技术都知道钱花在哪而不是月底账单来了再追原因。
