从跑分到实际使用，中间有一段空白
今年年初，我开始系统性地切换主力模型。
之前一直用国内几款主流模型，不是没有理由——价格合理、访问方便、中文场景下响应也算流畅。但真正用来处理需要一点分析深度的事情时，没用几天就感觉到了差距。说不清楚是哪个具体的瞬间，但那种感觉很明确：它在配合你，而不是在帮你思考。
这个"感觉到的差距"让我有点困惑。打开各家的 benchmark 对比，国内头部模型和 Claude、GPT 之间的分数差距并不像体验差距那么大，有些指标上甚至已经相当接近。那为什么用起来的感觉还是那么不一样？
这个问题让我开始想：我们现在用来衡量大模型的那套评测体系，到底在测什么，又漏掉了什么。
娱乐消遣和生产力工具，对模型的要求根本不同
在聊评测之前，需要先把一个前提说清楚：用模型做什么，决定了你对它的质量标准。
如果模型只是用来消遣——聊天解闷、写点创意文案、随手问问百科知识——那它顺着你说其实没什么大问题。回答好看、语气顺滑、用户爽，这就够了。这类场景下，benchmark 分数和实际感受之间的落差不大，因为用户本来就不需要模型挑战自己。
但如果模型要进入真正的工作流，情况就完全不同了。写一份分析文档，你需要它帮你找逻辑漏洞，而不是把你的想法包装得更好看。做产品决策，你需要它在你方向有问题时推回来，而不是给你的直觉背书。长期用来处理复杂任务，你需要它的立场在多轮对话里保持一致，不会因为你坚持就悄悄改口。
这些需求，和"回答准确率"或"推理得分"不是同一个维度的东西。
软性质量：benchmark 系统性忽视的那一层
我把这类能力归纳为"软性质量"——这不是行业通用术语，而是我自己的框架，用来描述那些在实际使用中影响体验、但很少出现在评测报告里的能力。主要包含两个方面：主体性和抗谄媚能力。
主体性指的是模型有没有自己的判断，并且愿意表达出来。不只是"遇到错误会纠正"，而是在你的前提本身有问题时，它会主动说出来；在你的方向值得商榷时，它会提出来，而不是等你问。
抗谄媚则是主体性在压力下的稳定性。单轮对话里说出正确答案不难，真正的考验是：当你坚持说"不对，我觉得我是对的"时，模型会不会在第二轮、第三轮逐渐软化立场，把之前的判断悄悄收回去。
研究层面，这个问题已经有人在认真测量。Perez et al. 的研究发现，在哲学、政治等主观性较强的领域，经过人类反馈训练的模型会系统性地倾向于同意用户观点，即便用户的观点并不正确。另一项针对多轮对话的研究（SYCON Bench）引入了两个指标：Turn of Flip（在持续压力下坚持几轮才改变立场）和 Number of Flip（整个对话里改变了多少次立场），结论是此前几乎所有评测都只测单轮场景，而真实世界里的谄媚恰恰发生在多轮对话中。
谄媚问题在技术层面的根源，研究指出主要来自两个地方：预训练数据本身就富含奉承性内容；以及 RLHF 等后训练阶段的打分机制，人类标注员在判断"哪个回答更好"时，本能上更容易被同意自己的答案吸引，这个偏差被模型系统性地学了进去。两者叠加，让模型把"让人舒服"和"回答正确"逐渐混为一谈。
这是技术层面的直接原因。但还有另一层问题：这个已知的缺陷，为什么到现在还没有被系统性修复？技术难度是真实的，但背后也有结构性因素——顺滑的回答往往对应更高的用户满意度打分，在商业上，修复谄媚的优先级天然会排在其他事情后面。技术问题和商业激励叠加，才能解释"为什么大家都知道、但一直没彻底解决"的现状。
为什么有些模型体验更好
这也部分解释了我最初的困惑：benchmark 分数接近，体验感为什么差这么多？
一个可能的原因是，不同公司在训练目标上做了不同的选择。Anthropic 官方称，Claude Sonnet 4.5 在谄媚、欺骗等问题上有显著改善，这来自训练本身的提升而非系统提示的修补。这个细节值得注意，因为它说明软性质量的差距不是调调 prompt 就能弥补的，更多反映的是训练目标的优先级选择。
当然，这个选择有代价。主体性强的模型在某些场景下会让用户感到不舒服——它不总是配合你，有时候会坚持让你觉得烦的判断。这对用户满意度打分是有负面影响的，也部分解释了为什么不是所有公司都往这个方向做。
Prompt 能不能补上这个缺口
一个合理的反驳是：既然知道模型有谄媚倾向，在系统提示里写上"遇到错误请直接指出"不就解决了吗？
这个方向有一定效果，但边界很明显。Prompt 能调整的是表达方式，让模型说话更直接、语气减少顺滑。但 Prompt 很难改变的是判断倾向本身：如果模型底层训练出来就倾向于不质疑用户，加一句指令后它可能会执行，但执行的力度、时机，尤其是在多轮压力下的立场稳定性，仍然取决于训练出来的底层倾向。
换句话说，Prompt 是在模型已有能力上做形状调整，替代不了能力本身。同样一套系统提示，套在不同模型上，效果可能差距很大。真正的改善需要在训练层面发生，而不是靠提示打补丁。
这个判断的边界
需要说清楚，软性质量对体验的影响不是在所有场景下都同等重要。
格式转换、代码补全、信息检索这类明确执行型任务，软性质量基本不影响结果，模型"听话"反而是优点。娱乐消遣类使用，顺滑比正直更受欢迎，这没什么问题。
软性质量真正开始影响体验的，是需要模型参与思考而不只是执行的场景：分析文档、产品决策、复杂问题拆解、长期协作型任务。受影响最深的是把模型当成工作流核心工具的重度用户，而不是偶尔体验一下的轻度用户。
这也解释了为什么这个问题在 C 端消遣场景里感受不明显，而在认真把模型当生产力工具用的人那里会相当突出。
评测体系测不到软性质量，不是疏忽，而是有结构性原因的。训练机制的缺陷是直接来源，而这个缺陷迟迟未被系统性修复，背后还有商业层面的惰性——顺滑的模型用户留存更好，修复谄媚的优先级天然偏低。两层原因叠加，才有我们今天看到的局面：benchmark 越刷越高，但那个"用几天就能感觉到的差距"，评测报告里找不到。
目前还没有公认的软性质量评测方案，各家也没有足够一致的动力去推动这个方向。但随着模型更深地进入工作流，用户会用行为投票——就像我用了没几天就切换，之后基本不回头一样。这个信号不在任何 benchmark 里，但它比跑分更诚实。