Claude Sonnet 5 正式上线：别再让 Claude Code 一律消耗 Opus 成本

6 月 30 日，Anthropic 发布了新一代模型 Claude Sonnet 5。

如果你日常使用 Claude Code，这条消息不应仅仅被看作“又一款更强模型登场”。

它真正触动的，是一个更实际的团队决策：以后在 Claude Code 中，究竟什么时候该用 Sonnet，什么时候该用 Opus，什么时候必须由开发人员亲自介入？

判断逻辑非常清晰：

不要默认全员选用 Opus。

也不要因为 Sonnet 5 价格更优、上下文更长，就把所有 Agent 任务一股脑切过去。

更稳妥的做法，是为 Claude Code 构建一张模型路由表：日常修 bug、补测试、模块解读，让 Sonnet 5 率先处理；跨模块重构、权限逻辑、安全边界、生产事故，则保留 Opus 或人工主导。

本文不追求“Sonnet 5 秒杀 Opus”之类的标题效应。它更应被看作一份团队迁移清单：如果你准备将 Claude Code 更深地嵌入开发流程，请先想清楚以下 5 件事。

新模型上线，首先需要调整的是默认策略

官方文档说得相当明确：Sonnet 5 是面向绝大多数开发任务的主力模型，支持 1M 上下文窗口，最大输出 128K token，并且在 8 月 31 日前享有阶段限时价格。

同一份文档中，Opus 4.8 仍然被推荐用于复杂推理和 agentic coding 场景。

这揭示了一个现实问题：

Claude Code 并非只能选择“最强模型”。

它更像一个工具调度器。

一个任务只是修改 Controller 参数校验，让 Opus 全仓扫描，很可能造成资源浪费。

一个任务涉及权限模型、数据迁移、异步任务、支付链路，让 Sonnet 直接进行大改，又可能带来风险。

过去许多团队的做法过于粗糙：

预算紧张时，一律使用便宜模型。

风险较高时，一律开启最强模型。

但 AI 编程真正融入团队之后，这两种策略都会暴露出问题。

前者容易让复杂任务交给不应独立决策的模型处理。

后者则会让大量日常任务变成高成本的后台消耗。

Claude Code 应当采用模型路由，而非模型信仰

建议团队先将 Claude Code 的任务划分为五种类别。

第一类：解释型任务。

例如阅读某个旧模块、梳理调用链、解释接口报错原因、整理测试入口。

这类任务，优先交给 Sonnet 5。其价值在于快速展开上下文，帮助开发人员节省半天寻找入口的时间。

第二类：小步修复。

例如参数校验、空指针处理、异常文案优化、单测补齐、小范围前端交互。

这类任务同样可以先交给 Sonnet 5，但需要限制 diff 范围，并要求输出测试证据。

第三类：跨文件改造。

例如新增接口、修改领域对象、缓存逻辑调整、定时任务变更、改动被多人复用的 service。

这里不能只看模型能力，更要评估 reviewer 成本。Sonnet 可以起草方案和小步补丁，但关键决策必须由人工确认。

第四类：高风险边界。

权限、密钥、生产配置、CI/CD、数据迁移、支付、审计、风控、安全策略。

这类任务不应交给“默认模型自动完成”。可以让 Opus 进行方案推演，也可以让 Sonnet 做只读分析，但最终必须由人工主导。

第五类：事故与线上问题。

这类任务最忌讳 Agent 自信地边猜测边修改。

模型可以帮助读取日志、列出假设、生成回滚检查清单，但绝不应在没有边界的情况下直接修改生产相关代码。

成本不能只看每百万 token 的单价

Sonnet 5 的价格优势会让很多团队心动。

然而 AI 编程的成本并非模型单价乘以 token 数那么简单。

真正需要核算的是以下三笔账：

生成成本。

返工成本。

Reviewer 成本。

如果一个任务 Sonnet 5 生成很快，但改动范围失控，reviewer 花费半小时仍不敢合并，那么它并不便宜。

如果一个任务 Opus 一次完成，却输出了过度设计、无关重构、复杂测试环境要求，那么它也不一定划算。

团队真正应该记录的是：

这个任务花费了多少轮对话？

修改了多少文件？

人类 reviewer 花费了多长时间？

测试是否一次通过？

是否因为 AI 输出引入了二次返工？

一周之后，你会发觉模型路由并不是凭感觉决定的。

某些仓库、任务、语言栈确实适合 Sonnet 5 作为主力模型。

某些核心模块即使使用 Opus，也必须先由人工拆分任务并确定验收标准。

升级前，先用一周真实任务板验证

如果团队准备将 Claude Code 的默认模型调整为 Sonnet 5，不建议通过会议争论。

直接拿一周的真实任务，搭建一张测试板。

选取 6 类任务：

一个旧接口的 bug 修复。

一个单测补齐。

一个小型前端改动。

一个跨 service 的后端需求。

一个安全或权限相关的分析。

一个 PR review 自查。

每个任务仅记录 5 个结果：

是否完成。

改动是否收敛。

测试证据是否可用。

reviewer 返工时长。

是否需要切换到 Opus 或人工接管。

这张表跑完之后，比任何“模型很强”的评论都有用。

它会告诉你：Sonnet 5 在你的项目中能否作为默认工作马，Opus 应该保留在哪些关键关口，哪些任务根本不应该让 Agent 自动修改。

模型变强，不等于权限也要放大

许多团队在升级模型时，只关注能力，却不调整权限。

这是最危险的地方。

模型越强，越应该收紧默认权限。

Claude Code 官方文档原本就支持模型配置、权限配置以及允许模型列表。团队应该把这些作为工程控制面，而非个人偏好。

建议如下：

Sonnet 5 默认只执行低风险开发任务。

跨模块修改必须先输出方案，再执行小步 patch。

Opus 用于复杂方案、架构推演、疑难问题复盘，不要默认用于扫描所有日常任务。

高风险目录和生产配置，默认禁止 AI 修改。

PR 中必须明确写明使用了哪个模型、完成了哪部分、人工复核到哪一步。

这并非给 AI 减速。

而是让 AI 的速度能够融入团队流程。

没有路由、没有权限、没有证据，Claude Code 再强也只是个人玩具。

只有拥有了路由、权限和验收，它才可能成为团队基础设施。

最终判断

Claude Sonnet 5 的重点，不在于让开发人员又多记住一个模型名称。

它更像一次提醒：

AI 编程工具已经进入“模型调度”阶段。

未来团队不仅要回答“是否使用 Claude Code”。

还要回答：

什么任务使用 Sonnet？

什么任务使用 Opus？

什么任务只读分析？

什么任务必须人工接管？

什么任务不允许 AI 触碰？

如果你现在仍然只是在设置里选一个默认模型，那么接下来很可能会遇到两个问题：

要么为了省钱，让复杂任务在便宜模型上硬跑。

要么为了省心，让日常任务在昂贵模型上硬烧。

这两种都不是成熟团队应有的做法。

成熟的用法是：让模型按任务分工，让权限按风险分级，让 PR 按证据验收。

下一篇 AI 工具实验室，计划做一个实际对比：同一个 Java 接口改造任务，让 Claude Code 的 Sonnet / Opus 路由、Codex、Cursor 各跑一遍，直接观察谁的返工最少。