Anthropic两天前（2月17日）发布了Claude Sonnet 4.6，官方说法是”接近Opus级别的智能”。这种话听多了容易免疫，但这次我实际用了两天，结论是：这话没怎么吹。
我关注的点主要三个：编码能力、computer use、长上下文推理。下面逐个说。
先说结论
如果你现在用Sonnet 4.5写代码，升级到4.6是无脑操作。如果你在用Opus 4.5但心疼费用，Sonnet 4.6可以替代大部分场景。价格还是$3/$15 per million tokens，跟4.5一样。
编码能力：终于不”懒”了
Sonnet 4.5最让人烦的问题是”懒”——多步骤任务做到一半就开始糊弄，声称完成了但其实没做完。4.6这个毛病明显好转。
我拿了一个实际场景测试：让它重构一个React表单组件，要求把受控/非受控模式统一、加上Zod校验、同时保持向后兼容。
// 给Sonnet 4.6的prompt// 重构这个FormInput组件：// 1. 统一受控/非受控模式，用useControllableState// 2. 加Zod schema校验，错误信息支持i18n// 3. 保持现有API不变，新功能通过可选props暴露// 原始组件大概200行，省略...
Sonnet 4.5的表现：能完成基本重构，但经常漏掉边界情况。比如非受控模式下defaultValue变化时的行为没处理，Zod校验的async validate场景直接跳过了。追问才补上。
Sonnet 4.6的表现：一次性产出了完整实现。不光处理了上面提到的边界，还主动加了discriminated union来区分受控/非受控的类型——这是我没要求的，但确实是更好的做法。
// Sonnet 4.6生成的类型定义（节选）type ControlledProps = { value: string; onChange: (value: string) => void; defaultValue?: never;};type UncontrolledProps = { value?: never; onChange?: (value: string) => void; defaultValue?: string;};type FormInputProps = (ControlledProps | UncontrolledProps) & { schema?: z.ZodType; validateOn?: 'change' | 'blur' | 'submit'; locale?: string;};
这种discriminated union的写法，之前我在Opus 4.5上才见到过。Sonnet级别的模型能自发产出这种代码，说明推理能力确实上了一个台阶。
Anthropic给的数据是：Claude Code用户70%的时候更偏好4.6而不是4.5，甚至59%的时候偏好4.6而不是Opus 4.5。在我的体验中，这个数据基本可信。
Computer Use：从能用到好用
这是这次升级最值得说的部分。
Anthropic 2024年10月第一次推出computer use的时候，自己都说”还很实验性，有时候笨拙且容易出错”。我当时试了一下，确实——鼠标点不准、表单填错位、多步骤操作到第三步就迷路，基本是个玩具。
Sonnet 4.6在OSWorld benchmark上的表现有了质的提升。OSWorld是目前衡量AI操作电脑能力的标准测试，任务包括在Chrome、LibreOffice、VS Code等真实软件上完成操作，没有特殊API，就是看屏幕、点鼠标、敲键盘。
| 模型 | OSWorld得分 | 发布时间 |
|---|---|---|
| Sonnet 3.5 (初版computer use) | ~14% | 2024.10 |
| Sonnet 3.5 (升级版) | ~22% | 2025.01 |
| Sonnet 4.0 | ~33% | 2025.06 |
| Sonnet 4.5 | ~42% | 2025.10 |
| Sonnet 4.6 | ~54% | 2026.02 |
16个月，从14%到54%。这个进步速度是有点吓人的。
实际体验上，早期用户反馈说”在复杂电子表格导航和多步骤表单填写上接近人类水平”。我自己试了一个场景：让它在一个多tab的Google Sheets里，从三个不同sheet里汇总数据到一个新sheet。Sonnet 4.5做这个任务大概成功率50%，经常在sheet切换时丢失上下文。4.6基本能一次搞定。
不过还是要说实话：computer use目前还是比不上熟练的人类操作。它更适合那些重复性高、步骤明确但没有API的场景——比如在一个老旧的内部系统里批量录入数据，或者在不提供API的SaaS平台上自动化操作流程。
1M上下文窗口：整个代码库塞进去
Sonnet 4.6把上下文窗口扩到了1M token（beta）。数字本身不稀奇，关键是”能不能在这么长的上下文里有效推理”。
我做了一个粗暴的测试：把一个中型Next.js项目（大概15万行代码）整个丢进去，然后问它一个跨多个模块的bug。这个bug涉及三个文件的交互——一个middleware、一个API route、一个数据库查询。
# 用repomix打包整个项目npx repomix --output /tmp/repo.txt# 大概400K tokenswc -w /tmp/repo.txt# 约320000词
Sonnet 4.5在这种大上下文场景下经常出现”遗忘”——它会引用文件A的内容，但在分析文件B的时候忘了文件A里的关键细节。4.6明显更稳，能在三个文件之间来回引用，最终准确定位到bug（middleware里的一个header处理顺序问题导致API route拿到了错误的auth状态）。
Anthropic提到一个有意思的测试叫Vending-Bench Arena——让AI模型经营一个模拟生意，看谁赚最多钱。Sonnet 4.6的策略是前10个月疯狂投资扩产能，最后几个月急转弯冲利润。这种”延迟满足”的策略规划能力，说明长上下文推理不只是”记住内容”，而是真的能基于大量信息做出战略判断。
Prompt Injection防御提升
Computer use最大的安全隐忧是prompt injection——恶意网站在页面里藏指令，让AI执行意料之外的操作。Sonnet 4.6在这方面的防御能力比4.5有”重大改善”，接近Opus 4.6的水平。
这点很重要。如果你要在生产环境部署computer use，模型不够抗prompt injection基本就是在裸奔。4.6至少让这个场景变得可以认真考虑了。
适用场景和迁移建议
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 日常编码 | Sonnet 4.6 | 性价比最优，能力接近Opus |
| 复杂重构/架构设计 | Opus 4.6 | 最深的推理能力，不差这点钱 |
| Computer use自动化 | Sonnet 4.6 | 性价比远优于Opus，能力够用 |
| 大代码库分析 | Sonnet 4.6 | 1M上下文+有效推理 |
| 多Agent协调 | Opus 4.6 | 需要最强的规划能力 |
API上模型名是claude-sonnet-4-6，支持adaptive thinking和extended thinking。如果你之前的代码里hardcode了claude-sonnet-4-5，改一下就行。
还有一个新feature值得注意：context compaction（beta）。对话太长的时候会自动压缩旧的上下文，相当于变相增加了有效对话长度。对于长会话的agent场景挺实用。
踩坑记录
用了两天也不是没遇到问题：
- 前端样式偏好变了：4.6生成的CSS明显偏爱现代写法（container queries、view transitions），如果你的项目还要兼容旧浏览器，记得在prompt里明确说
- Extended thinking开销：4.6的adaptive thinking默认会比4.5消耗更多thinking tokens。如果你对延迟敏感，可以显式关掉或设low effort
- Computer use截图分辨率：分辨率太高的时候偶尔还是会点错位置，建议把虚拟桌面分辨率控制在1920×1080以内
Sonnet 4.6是近半年Anthropic最有诚意的一次更新。不是那种”benchmark涨了两个点”的挤牙膏式升级，而是在编码、computer use、长上下文三个方向都有体感明显的提升。$3/$15的定价不变，升级没有任何理由犹豫。
