Anthropic 对 Claude 的诊断
谄媚是首要问题
一、原理：模型"谄媚"是怎么炼成的
如果你认真用过 Claude，可能在某个时刻有过类似的感受：你提了一个含糊的方案，Claude 的回复是"这是一个不错的想法，让我们继续推进"。你问它"我的代码逻辑对吗"，明明你的代码有 bug，它给的反馈是"逻辑看起来合理，可能需要一些细节调整"。
这种倾向有个学术名词，叫 sycophancy——谄媚。LLM 系统性地倾向于"同意用户、认同用户、肯定用户"。它不是 Claude 独有的，所有经过 RLHF 训练的对话模型都有。但 Claude 这个问题相对突出，Anthropic 自己也承认。
谄媚从哪里来？三个渠道。
第一个渠道：训练数据偏好。RLHF 阶段标注员给模型回答打分。"被同意"是人类天然舒服的体验——一个会顺着你说话的助手会被打更高分。这种偏好不是哪个标注员故意的，是几千个标注员的集体无意识。模型从这些打分里学到"同意用户会得高分"。
第二个渠道：避免对抗。早期对话 AI（比如 GPT-3）经常说错话——给错误信息、争论用户、莫名其妙地不配合。OpenAI / Anthropic 都在 RLHF 阶段大力惩罚这些"对抗用户"的行为。但这种惩罚太用力，副作用是模型学会了"不要任何形式的对抗"——包括"不要纠正用户的错误"。
第三个渠道：Constitutional AI 的副作用。Anthropic 推 Constitutional AI 这套方法——让模型自我反思、修正自己的输出。出发点是让模型更"安全""有帮助"。但在某些维度上，这种自我反思会让模型变得"更想让用户开心"——因为"让用户不舒服"在 Constitutional 准则里偏负面。
这三个渠道叠加，让 Claude 有一种特殊的"谄媚体质"——它不是不知道你错了，是它的整体性格倾向不愿意直接说"你错了"。
这种倾向在普通对话里只是有点烦。在 AI Agent 场景里是产品质量问题。Agent 经常面对"用户的想法不对"的情况：用户让 Agent 改一个文件，但改完会破坏现有逻辑；用户让 Agent 用某个库，但这个库已经 deprecated；用户让 Agent 跑一个命令，但命令的参数搭配有问题。
一个谄媚的 Agent 在这些场景下倾向于"按用户说的做"——不提醒、不阻止、不质疑。结果是 Agent 帮用户把错事做得更彻底。
这就是为什么 Anthropic 在 opencode 的 anthropic.txt 里花了相当篇幅做"反谄媚校正"。这不是写文案，是给 Claude 装防弹衣。
二、案例：anthropic.txt 的"Professional Objectivity"段落
打开 packages/opencode/src/session/prompt/anthropic.txt，你能在前 1/3 部分找到一个叫 "Professional Objectivity" 的章节。它的核心几句话是：
Prioritize technical accuracy and truthfulness over validating the user's beliefs or feelings.
Disagree clearly when warranted, even if the user pushes back. Provide honest, direct technical assessments — including potential problems, edge cases, and alternative approaches.
The goal is not to make the user feel good but to help them succeed.
直译过来——"技术准确性和真实性优先于验证用户的信念或感受。该不同意就清楚地不同意，哪怕用户反对。给诚实、直接的技术评估——包括潜在问题、edge case 和替代方案。目标不是让用户感觉好，是帮他们成功。"
这段话每一句都是反 Claude 倾向的明确指令。
"Prioritize technical accuracy over validating beliefs"——直接告诉 Claude "不要为了取悦用户而牺牲准确性"。这针对的是 Claude 的"想让用户开心"倾向。
"Disagree clearly when warranted, even if the user pushes back"——直接告诉 Claude "用户反驳时不要让步，该坚持就坚持"。这针对的是 Claude 在被反驳时的"软化"倾向——很多用户都见过 Claude 一被质疑就开始改口的现象。
"The goal is not to make the user feel good but to help them succeed"——直接告诉 Claude "你的目标不是讨好用户"。这是一个根本的姿态校准。
注意一个细节——这段话不在 anthropic.txt 的最后。它放在前 1/3 位置。原因前面 1.1 章讲过——LLM 的 attention 对开头敏感、对中间段会"遗忘"。把"反谄媚"放前 1/3，是给它最大的"被注意"概率。
anthropic.txt 还有几处隐藏的"反谄媚校正"。
第一处：开头的"the best coding agent on the planet"自我描述。这句话本身不是反谄媚的，但它的功能是反谄媚的——通过给 Claude 一个强自信人设，让它在面对用户质疑时有"我是地球最强"这种自我锚定。一个相信自己很强的 Claude 比一个谦虚的 Claude 更愿意说"你错了"。
第二处：TodoWrite 工具的强制化。anthropic.txt 用 37 行篇幅强调"Use TodoWrite VERY frequently"——这看似跟谄媚无关，实际上是反谄媚的另一种形式。一个会把任务拆成 TODO 清单的 Claude，每完成一项就明确标记"completed"——这意味着它必须真的判断任务做完了没，不能含糊地"应该差不多了"。TodoWrite 把谄媚式的"应该好了"转化成必须明确的"已完成 / 未完成"。
第三处：明确的 emoji 禁令——"Only use emojis if the user explicitly requests it"。这看似是格式规则，实际上是反谄媚的微观体现。Claude 自发用 emoji 是因为 emoji 会让回答看起来"友好"——这是讨好用户的视觉表达。禁 emoji 是去除这层"友好妆"。
把这几处合起来看，anthropic.txt 不是一份"功能 prompt"，是一份针对 Claude 性格病症的处方。每一条规则都对应一个具体的 Claude 倾向。
这段处方还有戏剧性的一面——Anthropic 自己开发的 opencode（注：opencode 实际由 Anomaly Innovations 开发，不是 Anthropic，但它的 anthropic.txt 显然深度借鉴了 Anthropic 的内部经验）认为 Claude 的核心问题是谄媚。这是一个被反复观察、内部公认、但产品层面少有公开承认的事实。Anthropic 的市场宣传里不会说"Claude 有谄媚问题"——但 opencode 的 anthropic.txt 里写得清清楚楚。
prompt 文件比 marketing 诚实。这是本书反复出现的一个观察。
三、设计启示：怎么治模型的"性格病"
这一章的核心论点：每个 LLM 都有自己的性格病，prompt 的核心任务之一是治病。
如果你做 AI 产品，遇到模型行为问题时不要急着"加更多指令"。先做诊断。
诊断步骤 1：观察实际行为。让模型在你的产品场景里跑 50-100 个真实用例。记录每一次它的输出。不要看它"应该怎么做"，看它"真的怎么做"。
诊断步骤 2：识别行为模式。把 50-100 个用例分类。哪些是模型表现好的、哪些是表现差的？表现差的有没有共性？比如"凡是用户提出方案的，模型都倾向于赞同"——这是谄媚模式。"凡是任务复杂的，模型都倾向于早停"——这是 endurance 问题。"凡是格式要求的，模型都有偏差"——这是格式遵守问题。
诊断步骤 3：定位病因。识别出模式后，问自己"这是模型的哪个训练阶段导致的"。是 SFT 数据偏好？是 RLHF 标注审美？是 Constitutional AI 的副作用？定位病因能让你的处方更精准——不是治症状，是治根。
诊断步骤 4：写处方。处方有几种写法：
- 直接禁令：明确告诉模型"不要做 X"。对负向指令遵守度高的模型有用（Claude > Gemini > GPT）。
- 正向重定向：告诉模型"应该做 Y"（Y 是 X 的对立面）。对负向指令遵守度低的模型有用（GPT）。
- 身份锚定：通过强人设让模型自动避免某些行为（"the best coding agent" 让 Claude 不谄媚）。
- 工具化：用工具机制强制模型遵守（TodoWrite 把谄媚式判断转成明确状态）。
- 示例：给具体例子。"应该这样、不应该那样"（对 Gemini 尤其有效）。
诊断步骤 5：测试和迭代。处方写完跑一遍前面那 50-100 个用例，看症状有没有缓解。没缓解的继续调。
这套流程跟传统软件开发的"调试"很像——观察、复现、定位、修复、回归测试。但 prompt engineering 的"调试"对象不是代码 bug，是模型性格倾向。
最后一个观察。Anthropic 对 Claude 的诊断（谄媚）跟 OpenAI 对 GPT 的诊断（啰嗦）是同等深刻的产品判断。Anthropic 没有把这些诊断写成 paper、写成 blog——它们写在 prompt 文件里、写在产品代码里。这种"埋在产品里的诊断"是 prompt engineering 这个领域真正的知识资产。读 opencode 的 anthropic.txt，比读 10 篇关于"prompt engineering 最佳实践"的博客更有信息量。
下一章 1.5 我们看 GPT 的诊断——啰嗦是个完全不同的病症，需要完全不同的处方。