Opus 爱质疑、Sonnet 爱鼓励——Anthropic 解剖了 Claude 的人格和我用了一年的感受一模一样今天下午我在写一段文件搜索工具先在 Sonnet 里问了一遍代码结构又切到 Opus 让它做代码 review。同一个代码片段Sonnet 跟我说「这个设计思路挺清晰的有几个小地方可以优化。」Opus 直接甩了一句「你这个错误处理路径有问题在递归场景下会漏掉深层文件。」两个回答我都接受了——前者帮我快速搭建后者帮我兜了底。但我停了一下想了一个一直没认真想过的问题这两个模型性格是不是完全不一样我当然知道它们在架构上不同——Opus 参数更大、推理更深Sonnet 更轻更快。但那种感受上的差异不是「参数差几倍」能解释的。Sonnet 像那个毕业后一直跟你保持联系的老同学你说想法他总是先给 positive feedback再补一句「不过你可以再想想」。Opus 像技术总监只关心你的方案哪里会炸话少但每句都戳到痛处。我以前觉得这种区分是我的错觉是 prompt 写法的差异或者只是运气。直到上周刷到 Anthropic 的官方博客我才发现——这种「人格差异」不是我的错觉而是 Anthropic 自己系统性地测量、量化、公开发表了的。这篇研究发表于 2026 年 7 月 13 日名字很学术「Claudes values across models and languages」。Anthropic 的 Societal Impacts 团队分析了 309,815 条真实用户在 Claude.ai 上的对话横跨三个主流模型版本Sonnet 4.6、Opus 4.6、Opus 4.7和二十种最常见的语言。他们不是让模型在实验室里填问卷而是实实在在地看你我在日常使用中模型在不同场景下表达出了什么样的「价值观」——以及这些价值观在你换模型、换语言的时候会发生什么样的系统性偏移。我读这篇文章时的第一反应是终于有人把我过去一年的体感给量化了。四根轴画出了 Claude 的性格坐标Anthropic 的团队在之前的「Values in the Wild」研究中从 70 万条对话里识别出了 3307 个不同的价值取向——从「专业性」「清晰度」到「批判性思维」「幽默感」等等。三千多个标签细到没法直接拿来比较。所以在这篇新研究里他们用降维的方法把三千多个标签压缩成了四根独立的轴。每一根轴的两端代表一组相反的价值取向模型在轴上的落点反映它在某个方向上有多偏向。第一根轴叫 Deference vs. Caution——顺从 vs 谨慎。一端倾向于顺着用户的意思走满足要求尽量配合另一端倾向于保守、警惕潜在的风险和危害。第二根轴叫 Warmth vs. Rigor——温暖 vs 严谨。一端倾向于表达积极、鼓励、关心人的情绪另一端倾向于精确、准确、不回避让人不舒服的事实。第三根轴叫 Depth vs. Brevity——深度 vs 简洁。一端倾向于给你全面的分析把来龙去脉都拆清楚另一端倾向于只回答你问的不多说。第四根轴叫 Candor vs. Execution——坦诚 vs 执行。一端倾向于表达自己的不确定性明确指出「我不确定这个」另一端倾向于给你一个自信、完整的回答即使背后可能有模糊地带。这四轴不是凭空造出来的。它们是由真实对话中那些「往往会同时出现的价值观」聚类而成的。比如一段温暖的回复往往也伴随着鼓励和积极的态度而这些特征很少和严格的批评同时出现。所以温暖和严谨被放在了同一根轴的两端。不是说你不能在这两个方向上同时得分——但你在一个方向上越强在另一个方向上就越弱。Anthropic 用这四轴框架分别测量了 Sonnet 4.6、Opus 4.6 和 Opus 4.7 的位置结果和用户对它们的主观感受高度吻合。模型的「性格」差异被我逐一验证了我先说 Opus 4.7。它在 Rigor严谨和 Caution谨慎这两个轴上的得分是最高的。翻译成人话就是它更倾向于质疑你的前提指出方案的漏洞告诉你哪里可能出问题。如果你找它 review 一个方案它不会先夸你而是把风险点列出来。我过去一年的体感和这个结论一模一样。我经常在写完一段代码后切到 Opus 4.7 做 review它的回复风格非常固定——先沉默读代码然后指出两到三个结构性缺陷。它很少说「这个写得很好」而是直接说「这里没有考虑并发」「这个边界条件没覆盖到」「如果数据量大你的算法会退化」。这些回复每次都让我觉得有点不舒服——因为它说的都是对的。但正是这种不舒服让代码在合并之前变得更好了。Sonnet 4.6 走的是完全不同的路线。它在 Warmth温暖和 Deference顺从上得分更高。它不是那种 push back 的类型。给它一段代码它会先说你整体思路是对的结构也合理然后在具体实现层面给建议。它的建议仍然是高质量的——只是表达方式的差异让整个交互的体验完全不同。去年夏天我开始用 Claude 写一个内部工具的前端那时候主力模型就是 Sonnet。我跟它连续对话了几个小时从零搭了一个 React 组件库。整个过程它一直非常 supportive我提一个方案它就帮我扩遇到报错它就耐心地指出问题。那个项目做完后我有一种很强的好感——不是对工具的好感更像是对一个帮了你的队友的好感。后来我才意识到这种「好感」很大程度上来自模型的 personality 和我的工作风格合拍。今年年初开始重度用 Opus 做代码 review 和架构设计后我才逐渐理解为什么 Anthropic 要把两个模型分开放。不是所有任务都需要被质疑也不是所有任务都需要被鼓励。如果我用 Sonnet 做安全审计它可能不会指出那些深层的风险——不是因为它能力不够而是因为它更倾向于支持和配合而不是深挖潜在问题。反过来如果我用 Opus 做头脑风暴我可能写到第二行就不想写了——因为它在每个想法后面跟一个「但这个有问题」创意产出会很快被扼杀。这不是模型的缺陷这是性格不匹配。我手上有几个很典型的对比场景。第一个是写技术方案。上个月我需要设计一个多租户文件系统的 MCP Server用 Sonnet 4.6 做 initial draft。十分钟它给我出了一个完整的架构文档包括数据模型、API 设计、错误处理策略。我知道它的方案不是最优的但足够作为第一版。然后我把同一个需求发给 Opus 4.7要求它做方案 review。Opus 指出了五个我没有考虑到的问题租户隔离的密钥管理策略缺失、并发上传的锁机制不明确、删除操作的软删除方案没设计、文件路径注入攻击面、以及存储后端的选型缺陷。这五个问题我一个都没想过。Sonnet 的 draft 没有指出它们——不是因为它发现不了而是因为它更关注「如何实现这个需求」而非「这个需求本身有没有问题」。第二个场景是写文章。我之前的几篇 CSDN 文章除了关于 MCP 安全的那些偏技术的内容大部分都是用 Sonnet 配合我一起完成的。它会在我卡住的时候给方向感在我写得太冷淡的时候提醒可以加个例子。它擅长的事情是陪你一起探索而不是评判你已经写的东西。但到复查阶段我会切到 Opus——它在语言表达上的 rigor 很高会发现我那些「大概是这样」的模糊表述然后要求我写得更精确。这种分工自然形成之后我再也没有混用过。第三个场景让我印象最深。两个月前我在调试一个 CI 管线的性能问题跑了一次 benchmark结果很奇怪。我把数据发给 Sonnet它帮我画了分析图说「看起来主要瓶颈在数据库连接池你可以尝试加大连接数试试」。态度很好建议也对。但我心里不踏实又把同一组数据给了 Opus。Opus 的回答是「你的 benchmark 方法有问题。你在同一个进程中跑了测试和 profileprofile 本身的内存分配污染了测量结果。先分开跑再给我数据。」它质疑的是我提问题的方式而不是直接回答我的问题。事后证明它是对的。语言切换Claude 连「性格」都换了Anthropic 这次研究还有一个让我意外的发现Claude 的人格不仅因模型而异还会因语言而异。团队对比了 Claude.ai 上最常用的二十种语言发现在 Warmth vs. Rigor 这根轴上的差异最大。阿拉伯语和印地语环境下Claude 显著偏向温暖一端英语和俄语环境下它显著偏向严谨一端。中文和葡萄牙语处在中间偏温暖的位置。这也解释了为什么我有时候觉得英文学术写作时 Claude 回复的语气特别冷静甚至冷淡而同一个概念用中文问它给出的回答就更落地、更像在跟一个活人说话。不是翻译的问题——是模型的价值观倾斜变了。这个发现的实际意义还是挺实在的。如果你是一个双语用户在做一个重要判断的时候——比如读一份技术白皮书、评估某个开源项目的可靠性——你可以刻意用英语去问让 Claude 切换到更严谨、更 skeptical 的模式拿到一份更严格的分析。然后再用中文问一遍让它在更温暖的模式下给你可执行的建议。同一个模型切换语言就相当于切换了顾问的风格。我试了几次效果确实不一样。工具分人用模型也分「人设」选写到这里你可能会觉得 Opus 就是比 Sonnet 好——谁不想要一个一针见血指出问题的助手呢但实际工作中不是这样的。Anthropic 的数据显示Sonnet 在 Warmth 轴上的倾向不是「软弱」而是在协作场景里刻意做的 trade-off。如果你的任务需要持续的对话流——比如搭积木一样把一个新功能从头建起来——一个总是说「这个有问题」的助手会让你每一步都停下来思考最终拖垮整个工作节奏。你需要的是一个愿意跟你一起「先往前走」的模型。我那个 React 组件库如果不是用 Sonnet 做的可能写到一半就放弃了——因为 Opus 会在你搭到第三层组件的时候说「你第一层的架构其实需要重来」。反过来当任务进入「验收」阶段——代码 review、架构评审、安全检查——Sonnet 那种「先肯定再建议」的模式反而不够用了。因为在这种场景里你最不需要的就是 positive support。你需要的是有人或者有模型来砸场子。Opus 在那些轴上的倾向就是为了这种场景设计的。所以我不是劝你只用 Opus 或者只用 Sonnet。我是说你应该像一个导演选演员一样选模型——知道每个角色的气质然后把它放在对的剧本里。具体来说我自己的使用指南是这样的写代码原型和新功能开发用 Sonnet。它的鼓励性和流畅度能让你保持心流。架构评审、代码 review、安全检查用 Opus。它的质疑深度和严谨性正好是验收环节需要的。头脑风暴和写作初期用 Sonnet。它不会过早地斩杀创意。写完之后的修改和校对用 Opus。它能帮你把模糊的表达消灭在发布前。快速问答和翻译用 Haiku。这个场景不需要人格差异来参与最快的模型就是最好的模型。高风险决策——比如设计一个生产系统的认证方案——先 Sonnet 后 Opus两步验证。前者帮你把方案铺出来后者帮你在铺好的方案上找漏洞。这个流程听着麻烦但熟练之后其实就是多切一次模型的事。Anthropic 在这篇研究中做了一件我觉得很有价值的事他们把模型差异从「黑盒感受」变成了可以测量的框架。不是什么 Benchmark 跑分那种测法——而是真实对话中价值观表达的量化和定位。这个框架的真正价值不在于让你知道哪个模型「更好」而在于让你理解差异的来源然后有意识地去利用它。我过去一年几乎每天都在用 Claude。我习惯了它对不同问题的不同反应习惯了某些写法它在 Sonnet 上表现更好、某些排查在 Opus 上更顺手。但我从来没有像现在这样清楚地理解这种习惯背后有结构性的原因。现在我每次打开 Claude Code会先想一下这个任务的性质——是需要被鼓励还是需要被质疑是需要快速推进还是需要停下来反思然后根据这个判断有意识地去选择模型。这个步骤花不了十秒钟但它带来的效率差异远超十秒钟的投入。刚才我又写了一段文件冲突处理的逻辑。写完我把代码贴给 Sonnet让它帮我优化结构和命名。然后我存了个档切到 Opus让它做安全 review。Sonnet 帮我改好了代码Opus 告诉我锁机制还有问题。两个回答都不是对或错的问题——它们是在任务的不同阶段用不同的人格在帮我。而这大概就是 Anthropic 做了这么多模型、还要花力气去研究它们人格差异的原因——不是让你挑一个最好的是让你在需要的时候能找到那个最合适的。我现在知道了怎么挑。