Sonnet 4.6 发布，代码能力与长上下文升级

Sonnet 4.6 最值得关注的，是日常编程任务能否用中档模型完成，把 Opus 留给最难的问题。原文给出的答案偏乐观：价格沿用 Sonnet 4.5，代码表现、长任务规划和电脑操作都有提升，还加入了测试版 1M token 上下文。

但先划清证据边界：作者没有上手测试，内容全部来自其标注于 2026 年 11 月 8 日查阅的 Anthropic 公告。下面的能力与数字都应按厂商声明理解。这篇值得读，是因为它提供了一套可以拿到自己仓库里验证的模型选择思路。

日常写代码，Sonnet 能替掉多少 Opus？

原文最有分量的数字来自 Claude Code 的早期测试：用户约有 70% 的时候更偏好 Sonnet 4.6，而非 Sonnet 4.5；与 2025 年 11 月的旗舰模型 Opus 4.5 相比，偏好 Sonnet 4.6 的比例为 59%。

59% 是相对 Opus 4.5 的用户偏好，不能读成超越 Opus 4.6。

这些反馈具体落在程序员熟悉的问题上：修改前先读上下文，把重复逻辑收进共享实现，减少过度设计，更少敷衍执行，也更少在没做完时宣称成功。比起生成代码的速度，这些行为更影响审核和返工成本。

不过，偏好比例不是任务成功率。原文没有提供样本量、任务分布、统计方法，也没有独立复测。它能支持「值得尝试」，还撑不起「可以全面替换」的结论。

Anthropic 给出的分工是：Sonnet 4.6 承担大多数代码编写、审查、规划、设计和知识工作；Opus 4.6 继续处理最深层推理、大型代码库重构、多 Agent 协调，以及正确性要求最高的问题。

原文同时把整仓修改列为长上下文的用途，并不矛盾。跨越多少文件和推理有多难，是两回事。统一修改配置可能涉及很多文件；定位隐蔽的状态竞争，也可能只涉及几个函数。

作者建议先用 Sonnet，遇到浅薄、不一致或明显错误的结果，再把具体任务升级到 Opus。这个办法成立的前提是：你能判断问题来自模型能力，还是缺少需求、上下文或验证手段。

1M 上下文能装下仓库，但能理解多少？

Sonnet 4.6 的 1M token 上下文窗口处于 beta。原文设想的用途包括同时读取服务代码、测试和配置，联合分析长文档，以及让迁移任务保留计划与执行证据。

对开发者而言，价值是减少手动切片后丢失关联的问题。但「装得下」与「用得好」之间，仍然隔着一段距离。

Anthropic 用 Vending-Bench Arena 的结果说明长期规划能力：在模拟经营中，Sonnet 4.6 前十个模拟月大量投入产能，最后阶段转向盈利，并取得领先成绩。这说明的是模型能否根据长期目标调整策略，不能直接证明它能准确理解整个业务仓库。原文也没有给出具体分数和对手差距。

上下文窗口变大后，筛选相关信息依然重要。

作者提醒，每个输入 token 都有成本，把一百万 token 放进请求，比处理一万 token 需要更多工作。更合理的做法，是先提供与任务相关的实现、测试、配置和约束，信息不足时再补。

另一个配套功能是上下文压缩（context compaction），同样处于 beta。它会在对话接近限制时自动总结较早内容，延长有效对话。原文没有交代摘要会丢失哪些细节，因此验收条件、接口约定和未解决问题，最好保留明确记录，方便后续核对。

电脑操作和工具升级，离真实工作更近了吗？

电脑操作（computer use）指模型像人一样点击和输入，而非通过专门 API 完成任务。原文提到的 OSWorld，覆盖 Chrome、LibreOffice、VS Code 等真实软件中的数百项任务。

据 Anthropic 描述，Sonnet 系列在十六个月间持续进步，4.6 是明显的一步。早期用户反馈，它在复杂表格、多步骤表单和跨标签页操作等任务上达到人类水平；但 Anthropic 同时承认，它仍落后于最熟练的人类。原文没有提供 OSWorld 的具体成绩，不能据此计算提升幅度。

另一个相关声明是：提示注入抵抗能力较 Sonnet 4.5 显著改善，接近 Opus 4.6。模型读取网页时，也可能读到诱导它偏离任务的指令，所以这项能力直接影响自动化可靠性。但「抵抗能力提高」仍不能当成任意操作都可靠的保证。

平台更新也不少。Sonnet 4.6 支持 adaptive thinking 和 extended thinking；API 的 web search、fetch 工具可自动编写并执行代码，筛选搜索结果，只把相关内容留在上下文中。code execution、memory、programmatic tool calling、tool search 和 tool use examples 则被列为正式可用。

这些更新让工具先处理信息，再交给模型推理。原文认为这有助于回答质量和 token 效率，但没有提供收益数据。

获取方式方面，原文称模型已覆盖所有 Claude 套餐、Claude Cowork、Claude Code、API 和主要云平台，API model ID 为 claude-sonnet-4-6。价格与 Sonnet 4.5 相同，起价为每百万 token $3/$15，原文未展开具体计费条件。

Free、Pro 的 claude.ai 与 Claude Cowork 默认使用 Sonnet 4.6；免费层还增加 file creation、connectors、skills 和 compaction。Excel 插件则在 Pro、Max、Team、Enterprise 套餐支持 MCP connectors，包括 S&P Global、LSEG、Daloopa、PitchBook、Moody's 和 FactSet。功能入口增加，不等于各套餐额度相同，原文没有交代额度细节。

我的判断

我认同「默认模型承担日常工作，强模型处理难题」的选择方式。程序员需要优化的是完成任务的总成本，包括调用费用、检查时间和返工次数。

但原文最吸引人的几项判断，证据都有限。代码偏好来自厂商早期测试；长期规划案例不是仓库重构实验；前端布局、动画和设计感更好，以及更少迭代即可达到生产质量，来自早期客户反馈。作者没有给出自己的实测，也没有足够的对照数据。

与其直接把所有任务切到新模型，我更倾向于先挑可验证的工作试跑。继续使用已经熟悉的模型，有行为稳定的好处；采用 Sonnet 4.6，则可能降低部分任务成本，但需要重新确认它在哪些任务上可靠。

模型升级也不能替代工程反馈。共享函数有没有复用，可以查调用关系；迁移有没有完成，可以跑构建和测试；页面设计有没有改善，要看真实渲染结果。这些验证，比模型自己的完成声明更有说服力。

能拿来做什么

• 选一个边界清楚的前端或 Node 任务试用 claude-sonnet-4-6，例如消除重复工具函数或修复带测试的缺陷，记录完成质量、返工次数和费用，再决定是否调整默认模型。
• 做跨文件修改时，把相关实现、测试和配置一起提供，并要求先指出已有共享逻辑的位置，再执行修改，检查它是否真正利用了上下文。
• 为升级到 Opus 4.6 设置具体条件，例如补齐信息后仍反复违反约束，或无法解释关键设计取舍；同时保留构建、测试和人工审查作为验收依据。
• 评估 computer use 时，从可核对结果的多步骤表单或跨标签页整理任务开始，记录操作是否完成、信息是否正确，并检查网页内容是否干扰了原始指令。