同一 prompt 为什么在不同模型上效果天差地别

模型有'性格'

一、原理：模型"性格"从哪里来

你写了一份精心调教的 system prompt 给 Claude 3.5 Sonnet 用，效果很好。某天你想换 GPT-4，把同一份 prompt 直接搬过去——效果突然变差了。Claude 上稳定输出 200 字的章节摘要，GPT-4 输出变成了 500 字的啰嗦版本。Claude 会按你的格式输出 markdown，GPT-4 经常忘记加代码块标记。

这不是你的 prompt 写错了。这是 LLM 之间真实存在的"性格差异"。这种差异从哪里来？要回答这个问题，我们要看 LLM 训练的三个阶段。

第一阶段：预训练（pre-training）。模型读尽互联网上的文本——网页、书、代码、论坛。这一阶段它学到"语言怎么用"，但还不会跟人对话。预训练后的模型是一个纯粹的文本续写器——你给它一段开头，它续写最可能的接续。它不知道自己是 AI、不知道有"对话"这件事、不知道该礼貌。

第二阶段：监督微调（SFT, supervised fine-tuning）。OpenAI 或 Anthropic 雇人写大量"理想对话样本"——user 问什么、assistant 该怎么回。模型通过模仿这些样本学会"对话的形式"。这一阶段决定了模型的对话格式偏好——长度、结构、礼貌程度、是否爱用列表等等。不同公司的 SFT 数据风格不同，这是 LLM "性格"的第一个来源。

第三阶段：人类反馈强化学习（RLHF）。标注员给模型的回答打分——这个好、那个不好。模型通过这些打分调整输出偏好。不同公司的标注员有不同的审美——Anthropic 的标注员可能更喜欢"承认不确定"的回答（因为 Anthropic 的 Constitutional AI 强调诚实），OpenAI 的标注员可能更喜欢"直接给答案"的回答（因为 ChatGPT 早期面向的是大众用户而非技术用户）。这种审美差异通过 RLHF 烧进了模型权重，成为我们感知的"性格"。

理解了这三阶段，你就理解了为什么 Claude 和 GPT 性格不同。它们的训练数据、标注员、审美原则全都不一样。Claude 3.5 Sonnet 的"承认不确定 + 按步骤说清楚"是 Anthropic 一系列产品决策的结果，GPT-4 的"直接给方案 + 自信猜测"是 OpenAI 一系列产品决策的结果。

这种性格差异不是 bug，也不可能通过"更好的 prompt"完全抹平。你能做的是：要么忍受差异，要么针对差异做适配。

具体差异有多大？我们看几个真实的对比维度：

输出长度偏好。同一个问题，Claude 倾向于 3-5 段回答，GPT 倾向于 1-2 段直接结论，Gemini 倾向于结构化列表。这是 SFT 数据里"理想长度"的差异。

承认不确定的频率。Claude 经常说"我不能确定"、"取决于具体情况"，GPT 更倾向给一个确定的答案（哪怕需要假设），Gemini 介于两者之间。这是 RLHF 偏好的差异。

主动性。Claude 在 Agent 场景里有"想停下来确认"的倾向（早停问题），GPT 在 Agent 场景里有"过度主动"的倾向（不该改的也改）。Beast Mode（推理模型）有"持续探索"的倾向（停不下来）。

格式遵守严格度。Gemini 在格式遵守上最严格——你说"输出 JSON"它真的只给 JSON。Claude 偶尔会在 JSON 前后加解释。GPT 经常会忘记你要的格式。这是训练时格式数据比例的差异。

对负向指令的反应。Claude 对"不要做 X"的遵守相对认真。GPT 对负向指令的遵守不如对正向指令——这是个长期被观察到的现象。Gemini 介于两者之间。这种差异决定了你怎么写 prompt（详见 1.10 章）。

这些差异每一项都是统计倾向、不是绝对规则。但在 Agent 场景里——AI 要做一连串决策——这些倾向会被放大成产品质量差异。

二、案例：同一指令在不同 LLM 上的真实表现

我们看 opencode 的一个具体设计来理解这种差异是怎么体现到产品里的。

opencode 让 LLM 编辑文件时，要求 LLM 输出"原文 → 新文 ↘"的精确替换对。Edit 工具的描述里写：

Once a Read tool is used in this session, you should use Edit / Multiedit / Write to modify files. The edit will FAIL if oldString is found multiple times. Provide more surrounding context to make the match unique.

这条指令在三个模型上的表现差别明显：

在 Claude 3.5 Sonnet 上——大部分情况下能正确按要求给出唯一匹配的 oldString。失败率约 5-10%。失败时主要是"没读文件就直接 edit"或者"oldString 写得不够具体导致多匹配"。

在 GPT-4 上——更经常出现"忘记必须先 Read 文件"的问题。GPT-4 倾向直接动手，"先读再改"这种 workflow 约束遵守度不如 Claude。失败率 15-20%。

在 Gemini 1.5 Pro 上——严格遵守"先读再改"，但经常在 oldString 里把缩进抄错（多缩或少缩了空格）。这是 Gemini 的细节处理弱点。失败率 10-15%。

这就是为什么 opencode 不写"一份 prompt 走天下"。同一份 system prompt + 工具描述在三个模型上的实际表现差异不是 5%、不是 10%，是 3-4 倍的失败率差异。这种差异在 Agent 场景里被放大成产品体验的天差地别——一个 5% 失败率的 Agent 是好用的，一个 20% 失败率的 Agent 是难用的。

opencode 的解决方案不是"调出一份所有模型都能用的 prompt"——它已经放弃这条路。它的方案是：

1. 5 张脸（详见 1.3 章）——按模型族用完全不同的 system prompt。Claude 用 anthropic.txt 强调"professional objectivity"（防谄媚），GPT 用 gpt.txt 强调"deeply pragmatic"（防啰嗦），Gemini 用 gemini.txt 强调 5 步工作流（防偷工减料），Beast Mode 用 beast.txt 强调"MUST iterate"（防早停）。

2. 9 层 Replacer 容错（详见 3.5 章）——edit 工具内部有 9 层 fallback。LLM 给的 oldString 在第 1 层（精确匹配）失败，自动 fallback 到第 2 层（按行修剪）、第 3 层（块锚点）、一直到第 9 层。这本质上是"用工具容错"补"prompt 没能彻底解决的问题"。

3. 错误信息精心设计——LLM 调用失败时看到的错误信息会教它下次怎么改。"Found multiple matches. Provide more surrounding context to make the match unique." 这是给 LLM 看的"修复指南"。

这三个机制叠加，让 opencode 在不同模型上都能跑得动。但不是因为有"统一的 prompt"，是因为有"针对差异的多层应对"。

这种姿态背后有一个产品判断：LLM 的差异不会消失，只会越来越大。两年前 GPT 和 Claude 还算相似，现在 Claude 4 / GPT-4 / Gemini 2 / Llama 4 各走各的路。Anthropic 推 Constitutional AI、OpenAI 推 reasoning model、Google 推超长 context、Meta 推 open weight——每家厂商的差异化产品策略会让"模型性格"越来越分化。"统一 prompt"只会越来越难。

opencode 选了承认差异 + 针对应对的路。Cursor / Aider 等其他多模型 Agent 也大多走同一条路（虽然实现细节不同）。这成了多模型 AI Agent 的事实标准——给每个模型族写一份独立的 prompt + 用工具容错补 prompt 的不完美。

三、设计启示：怎么应对模型差异

这一章的核心论点：模型差异不是 prompt 问题，是产品架构问题。

如果你的 AI 产品支持多模型，关于模型差异你至少要做几件事：

1. 建立"模型性格档案"。对你支持的每个模型，记录它的真实倾向——爱啰嗦还是爱简洁、爱早停还是爱继续、对禁令遵守度多高、对格式遵守度多高。这个档案应该是动态的——每次 LLM 升级（Claude 3.5 → 4、GPT-4 → 4.5）都要重新校准。

2. 不写"完美一份 prompt"。这是死路。承认差异，给每个模型族写适配版本。维护成本高，但产品质量稳定。

3. 用工具容错补 prompt 的不完美。prompt 永远不能让 LLM 100% 按要求输出。剩下的部分要靠工具的容错能力补——错误信息要友好、fallback 要充分、重试要智能。3.5 章会专门讲这一点。

4. 准备好"小模型走不通就升级大模型"。某些场景小模型怎么调都不达标。这时候不要硬调 prompt，直接换大模型可能是更简单的方案。opencode 让用户在 config 里指定 model 和 small_model——简单任务用便宜的小模型、复杂任务用大模型。这种分工是承认"模型差异不能用 prompt 抹平"的另一种应对。

5. 不要给最低能力模型当标杆。如果你的产品支持 GPT-3.5 这种老模型，不要让你的整体产品体验被它拖累。该模型不能做的事，明确告诉用户"建议升级到 GPT-4"。不要为了"兼容性"把所有模型都拉低到最差水平。

6. 监控模型行为漂移。LLM 在升级、provider 在调整他们的 API 默认参数（temperature、top_p 等）。今天调好的 prompt 明天可能就不一样了。建立监控机制——定期跑测试集看看模型行为有没有 regression。

最后一个观察。当你深入做多模型 AI 产品时，你会发现一件反直觉的事：模型差异是你的产品壁垒来源之一。如果所有 LLM 都行为一致，那 AI 产品的差异化只能在 UX、生态、价格上。但因为 LLM 之间真实存在性格差异，"谁更懂这些差异、谁能更精准地针对每个模型做适配"——这本身就是产品能力。

opencode 的 5 张脸就是这种壁垒的体现。它不是因为"对接了多个 LLM"才有竞争力，是因为"对每个 LLM 的诊断更准"才有竞争力。这是个被低估的产品维度——下一章 1.3 我们就专门看这五张脸的实况。