模型又迭代了。这次 Anthropic 把 Claude Opus 4.7 推到全量可用，社交圈里很容易看到两种极端：一种是“榜单赢了，默认模型必须换”；另一种是“都是营销，懒得动”。说实话，这两种都偏了。你真正要关心的，通常不是谁在某张表上多赢了几分，而是你的手边那几条真实任务，在新旧模型上到底谁更稳、谁更省时间、谁更不容易在关键一步翻车。
下面这篇：不冒充替你跑过一轮私密评测（那得你自己在工位上试），只把官宣能核对的事实说清楚，再给你一套谁都能照抄的自测顺序。要是你真想认真测，网上那句夸张玩笑怎么说来着——“恨不得辞职在家研究怎么写代码”——用在心情上挺贴切，用在行动上，还是换成“今晚加一小会儿班，把基准题跑完”更靠谱。
一、先读官宣：和程序员直接相关的不是“最强”，而是这几条硬变化
把新闻读薄一点，你会看到 Opus 4.7 至少在四个方向上，和“每天写代码、改需求、出材料”的人是贴肉的。
第一是工程向能力。Anthropic 在发布页里把 advanced software engineering 放在很靠前的位置，语气也很直白：更难的那类编码任务，用户反馈里开始出现“更敢把最棘手的活交出去”的叙述。这不是让你迷信，而是提醒你：如果你平时卡在复杂重构、跨文件推理、长链路 bug 上，这次迭代值得占用你一次认真的对照实验。
第二是视觉与专业交付。发布页写得很具体：图像长边可到 2576 像素、大约 3.75 megapixel，并点名密集截图、复杂图表、需要“像素级参照”的工作。翻译一下：UI 评审截图、架构图、表格照片、PPT 里抠细节——这类活，如果以前经常因为“看不清、数不对、漏条件”而返工，这一条比抽象的“多模态更强”更有用。
第三是指令遵循变强之后的副作用。官方早期测试笔记里有一句很关键：模型更字面地执行指令，给旧模型写的提示词，可能在新模型上产出“意外结果”。这不是唱反调，是提醒一件工程现实：换模型≈要预算一点时间做 prompt 与 Skill 的回归，别指望零成本平移。
第四是产品与 API 侧的配套。同文还提到 xhigh 这一档 effort、API 的 task budgets（公测）、以及 Claude Code 里的 /ultrareview 之类的新命令。它们共同指向一件事：厂商在帮你调“推理深度、时延、花费”的旋钮。默认模型要不要换，最后往往会被这些旋钮放大成“账面上的差异”。
另外还有一句对决策很友好、但常被忽略的话：定价与 Opus 4.6 相同（输入与输出的美元单价在发布页写明）。这意味着，如果你的瓶颈是“效果”，而不是“价格门槛”，对照实验的成本结构不至于因为涨价而变形——当然，token 消耗曲线仍可能变，下文会提迁移注意事项。
二、为什么“默认模型”不该由排行榜替你一键决定
排行榜、对比表、社交媒体截图，最大的问题是：它们测的，经常不是你正在测的。
Anthropic 自己在脚注里写得很克制：例如 SWE-bench Multimodal 用的是内部实现，与公开榜单分数不能直接横向比较。这句话值得你多看一眼——不是说谁不诚实，而是在提醒：评测 harness 差一点点，分数叙事就会换一副面孔。 你把“公开榜第一名”直接映射成“我仓库里一定第一名”，跨度太大。
更现实的是分布偏移。你的代码库风格、历史包袱、评审口径、甚至你们团队对“能合并”的定义，都和基准题里的世界不一样。于是会出现一种尴尬：模型 A 在榜单上更好看，但在你那条“从需求到可合并 PR”的链路上，模型 B 更少犯你讨厌的那类错。 这类结论，只有你自己的基准题能给你。
还有一层是组织与合规。国内团队常见的变量包括：数据出境与采购路径、云厂商托管区域、账号与开票、以及某些行业对第三方模型的限制。它们不会出现在任何 benchmark 里，但会决定你能不能稳定地把“更强的模型”接到 CI、接到 IDE、接到工单系统。若这些变量没对齐，讨论默认模型就像在讨论“哪辆跑车更快”，而你小区大门还没放行。
三、给你一套可复制的自测流程：比转发对比图更像成年人
如果你今晚只想做一件事，我建议别改默认模型，先做基准题封板。做法很朴素：挑三到五个你过去两周真实痛过的任务，把它们写成可重复的输入（同样的仓库快照、同样的需求描述、同样的截图），然后在新旧模型上各跑一遍，只记录三类结果：能不能一次做对、哪里需要人兜底、以及时间与 token 体感。这比抽象形容词可靠得多。
题型上，你可以直接偷这篇选题里给的框架，按你的工种改一改：接口重构、跨模块定位 bug、根据 UI 截图改交互、把散材料整理成可汇报结构、以及一份需要“像人一样排版”的周报或幻灯片骨架。关键是固定任务，否则你会把“我这次提示词写得更好”误当成“模型更强”。
换模型后务必加一轮提示词回归。官方已经提示“旧提示可能意外”，这不是甩锅，是让你把团队里那几条高频模板、几个常用 Skill、以及你 IDE 插件里保存的 system 片段，当作小型回归集。最近中文圈里也有人用戏谑的方式讨论把经验沉淀成可复用 Skill——本质都是一件事：模型升级了，你的“组织记忆”也要跟着升级，不然就会出现“新脑子配旧说明书”的错位感。
迁移上，发布页也提醒了 tokenizer 更新与 高分辨率吃 token 的现实：同样的图，更高保真往往意味着更多花费。你可以把它纳入实验记录：别只比“好不好”，还要比“同样质量下贵不贵”。API 侧若启用 task budgets，把它当作实验变量写进笔记，而不是第一次上线就在生产里硬怼。
最后补一段中文语境落地：同样的模型，走官网、走云厂商托管、走企业采购合同，体验与合规约束可能完全不同；IDE 插件版本、代理与网络、以及团队代码审查规则，也会改变“能不能用得爽”。这些不属于玄学，属于你把模型从新闻标题拽回工位时必须支付的工程摩擦。
Opus 4.7 值得认真看，但“默认模型”这件事，应该用你自己的基准题投票，而不是用别人的截图替你投票。你把三道题封板，再决定切不切，通常比“我先换了再说”更省时间。
