从ChatGPT到Claude：多模型提示工程的适配实践

做了三年多AI应用落地，我最明显的感受是：提示工程这个活儿，已经从一个“会写自然语言就行”的辅助技能，变成了一套需要成体系设计、跨模型适配的工程技术。两年前，团队里一个人死磕ChatGPT系产品的提示词就够用；现在不一样了，评估大模型、选型大模型、切换供应商，成了常态。而每次换模型，最先崩的往往不是代码，而是那些看似写得很好的提示词。今天写下这篇总结，想跟各位聊聊，从ChatGPT到Claude，一个提示工程架构师在做多样性实践时，到底在做什么，以及那些踩过坑之后才总结出来的适配方法。

这篇文章适合三类人：正在做AI应用落地的开发者、需要给团队搭提示工程规范的技术负责人、以及想从“会写提示词”进阶到“设计提示系统”的进阶学习者。我会尽量把差异讲透，把适配步骤写具体，不整虚的。

1. 为什么要做多模型提示实践

1.1 单一模型的舒适区陷阱

先说一个真实的教训。去年我做某个ToB项目时，整套语义分析流程全部构建在一家大模型厂商的产品上。当时提示词写得相当顺手，格式输出靠它的JSON模式，工具调用靠它的function calling，角色设定走它的system消息，一切都像是为这个模型量身定做的。结果进入灰度测试阶段后，对方调整了服务策略和价格体系，整个方案的成本瞬间失控，被迫考虑第二供应商。这个时候我才发现：所谓的“提示词写得好”，其实有很大一部分不是我的能力，而是模型的能力在托底。

这个问题在行业内有一个普遍叫法——单一模型绑定。它的本质风险在于：你的产品功能、评估标准、工具体系和成本模型，全部建立在某个模型的内部偏好上。一旦模型升级、服务关停、价格变化、或者因为合规要求必须换供应商，整个应用层的投入就要重来。我见过不少团队，死磕一个模型的提示词优化了几周，换模型后准确率掉得厉害，连问题出在提示词还是代码都分不清。

所以多样性实践的第一步，不是“我全都要”，而是建立一种意识：提示词不再归某个模型所有，它应该归属于业务逻辑本身。提示工程架构师在这里扮演的角色，很像传统软件工程里的接口设计者——我定义输入输出的契约，至于底层是哪个模型在跑，应该是我可以替换的部分。

1.2 从“写提示词”到“设计提示系统”

很多人以为提示工程就是写几条高质量的Prompt，这个理解在单模型时代勉强成立，在多模型时代远远不够。真正的提示工程架构师，维护的是一整套“提示系统”，它包括：

• 需求层：这个环节要完成什么业务目标，输入什么，输出什么；
• 策略层：用几步推理、是否拆解任务、要不要给示例、怎么给示例；
• 表达层：用自然语言、结构化标记、还是代码块表达指令；
• 适配层：针对具体模型，调整指令风格、参数取值、输出约束方式；
• 评估层：不同模型之间如何比较、如何度量优劣。

我用一个类比来解释：单模型提示词像用手写一份菜谱，只要你自己能看懂就行；多模型提示系统像开连锁餐厅，你必须保证任何一个分店（模型）照着标准操作手册（提示架构）做出来的菜，口味偏差在可接受范围内。这比“写一份好菜谱”难得多，也更接近“架构师”这个头衔的本职。

所以这篇文章里我最想传递的，不只是一些“ChatGPT系和Claude系的差异清单”，而是一套跨模型的迁移方法论——你在任何模型上拿到一套表现不错的提示，怎么才能快速、稳定、可评估地搬到另一个模型上，并且不把业务逻辑带到沟里去。

2. 两种模型的“性格差异”与工作机制

2.1 ChatGPT系模型群体的典型偏好

先说训练路线上的差异。ChatGPT系的产品在指令遵循、开放域对话、多轮上下文衔接上打磨得相当成熟，它对“自然语言命令”的容忍度很高。你给它一段不太规范的指令，甚至口语化地夹杂示例，它大概率也能跑通。这种“抗噪性”是它的一大优势，但也埋了一个隐患：团队容易因此写出糊成一团的提示词，靠模型来兜底。

在工程使用上，ChatGPT系有几个典型特性要注意：

• 消息结构：严格的system/user/assistant三段结构，很多能力（比如格式约束）是通过system消息来下发的，user消息主要负责业务输入。
• 格式输出：提供JSON Mode、JSON Schema等机制，尤其是结构化输出能力，基本上只需要响应格式声明，就能稳定返回标准JSON。
• 工具调用：function calling是单独的工具注册协议，模型会自己决定何时调用工具、传什么参数。
• 参数体系：它有temperature、top_p、frequency_penalty、presence_penalty等多维调节旋钮，可调空间大，但也意味着同样一组参数，换个模型版本可能效果完全不一样。

我实测下来，ChatGPT系模型的容错能力很强，但你需要给它“显式的轨道”。比如你要求它输出JSON，但它不保证字段一定符合某种复杂嵌套结构，所以JSON Schema补充说明很重要。它更习惯“你规定什么，我严格执行”的模式，不太擅长从一堆模糊背景里自己提炼规则。

2.2 Claude系模型群体的典型偏好

再来看Claude系产品。它在长上下文理解、指令遵循、代码生成、以及多文件梳理上做得非常细致，而且它的系统提示对“结构化”有很强的偏好。社区里有一个很明显的实践共识：用XML标签而不是Markdown、用正向指令而不是否定句式，效果会稳定很多。

工程视角下，Claude系有几个明显的个性：

• 消息结构：同样是system/user/assistant，但它更习惯把system当作“完整约束文档”来用，而不是一句两句的简短设定。
• 格式输出：没有像ChatGPT系那样的JSON Mode，但在提示中嵌入XML结构描述、甚至用输出前填充（prefill）引导，可以得到非常稳定的结构化结果。
• 工具调用：同样支持工具注册，但在工具选择上更依赖你对“何时用、怎么用”的文字说明；只给一堆函数定义而不给使用策略，它可能不调用或乱调。
• 参数体系：温度参数也有，但整体调节幅度更小、更偏向确定性；对否定指令（比如“不要输出解释”）反馈不稳定，正向描述（比如“请只输出结果”）反而更有效。

有个很经典的社区观察：把给ChatGPT系产品用的一套提示原封不动搬到Claude系产品上，最常见的失败是“格式输出飘了”，其次就是“角色扮演过度，输出一堆不必要的解释”。这不是Claude不聪明，而是它的训练目标更在意“对话的完整与得体”，你得通过结构化的指令给它划出清晰边界。

2.3 差异对照速查表

直接上个表，方便你对照参考：

这张表不是说你必须按表里的每一个格子去写提示，而是提醒你：做跨模型适配时，优先从这些维度自查，往往能快速定位问题出在哪层。

3. 从ChatGPT到Claude的提示迁移实操

3.1 从“命令式”到“原则式”的改写

我自己的习惯是：拿到一套ChatGPT系产品上表现良好的提示，先不改业务逻辑，先做三层检查：指令风格、输出格式、工具策略。第一层最容易出问题的，就是否定句式的使用。

举例。在ChatGPT系产品上，我们常写这种提示：

系统：你是数据提取助手。用户会提供一段文本，请提取实体和关系。 要求：不要输出解释，不要输出多余内容，只输出JSON格式结果。

这段话在ChatGPT系上通常没太大问题，JSON模式也会兜底。但搬到Claude系产品上时，我实测发现它仍然大概率能工作，只是偶尔会多出几句“根据您提供的文本，我提取了以下实体……”之类的废话，把纯输出打破。你越是写“不要解释”，它越容易在结构外补解释，就像越说“别想白熊”，人就越容易想白熊。

我的改写方案是把否定句全部转成正向原则：

你是数据提取助手。用户会提供一段文本，你的任务是提取其中的实体和关系。 输出要求： 1. 只输出一个JSON对象，包含实体列表和关系列表； 2. 实体对象包含name和type两个字段； 3. 关系对象包含source、target和relation三个字段； 4. 回复中不包含JSON以外的任何文字。

看到区别了吗？第4条仍然隐含了“不要解释”，但它是用正向的“不包含……以外文字”来表达的，同时前面的“输出要求”提供了具体结构。对Claude系产品来说，这条提示的效果远比“不要输出解释”稳定。

3.2 输出格式迁移：JSON与XML的结构之争

这是我在迁移中花时间最多的一层。ChatGPT系产品有JSON Mode，你只需要在API参数里声明response_format，模型就能给出合法JSON。但Claude系产品没有这种硬约束，直接说“输出JSON”，它也可能给你一段放在JSON代码块里的内容，甚至偶尔字段都不对。

我的做法是在提示里显式写清结构模板，并配合prefill（预填充）来引导。prefill的意思是，在Assistant消息的开头先填一小段内容，让它沿着这个方向继续输出。典型的Claude系提示长这样：

你是数据提取助手。用户会提供一段文本，你的任务是提取实体和关系，并把结果整理为一个JSON对象。 输出格式必须如下： { "entities": [{"name": "实体名称", "type": "实体类型"}], "relationships": [{"source": "头实体", "target": "尾实体", "relation": "关系类型"}] } 请严格按格式输出，不要添加任何额外的文字或代码块标记。

注意我用“代码块标记”而不是“不要用```”。前者是正向描述，后者是否定描述。这样调整之后，我在实际项目中把结构解析失败率从大约7%降到了0.5%以内，代价只是提示词多写了二十几行。

如果解析还是不稳定，可以再试一个策略：让模型在系统消息里把输出样例完整写一遍，然后user消息里填入真实文本，并且要求“按上面的样例格式输出”。这个“先给样例再给任务”的模式，对Claude系产品尤其有效。

3.3 角色设定与上下文管理的适配

在ChatGPT系产品中，强大而简短的system提示通常就够了，因为它不需要太长，太长了反而可能被模型选择性失明。但在Claude系产品上，系统提示更适合做成一份“任务说明书”，它对你长篇、结构化的指令接受度明显更高。

我重构系统提示时的框架是这样的：

任务定位：一句话说明你负责什么。 工作流程：分步骤说明你将如何处理用户输入。 输出约束：写明格式要求，正向来表达。 边界说明：说明哪些情况拒绝处理、哪些情况必须请求用户补充信息。

这样一个结构我最早是在ChatGPT系产品上用的，效果不错；搬到Claude系产品后，保留同样的业务逻辑，只调整了语言风格，效果同样稳定。也就是说，做适配时不要什么都改，先把“可迁移的结构骨架”挑出来，再针对模型特性调整皮肤上的细节。

上下文管理上还有一个差异值得提：ChatGPT系对长上下文的定位比较“宽”，你把多个任务塞进一个会话里它也能硬跑；Claude系更在意“当前重点”，如果历史消息里有一堆无关示例，反而可能干扰结果。所以换用Claude系产品时，我习惯把无关内容提取出来，只留当前任务所需的最小子集。

3.4 参数与工具调用的适配细节

参数层面，ChatGPT系产品的temperature、top_p、penalty系列参数组合让我经常调；Claude系产品我给“确定性”场景直接设temperature为0，需要创意性的场景设0.6左右，其他参数很少动。这种差异决定了你必须在应用层多做一层“参数适配”，不能把一套配置原封不动地打到所有模型上。

工具调用层面，两边的差异更值得留意。ChatGPT系产品的function calling更像“主动型”：模型看到工具定义和用户需求匹配时，会自主决定调用。而Claude系产品更像“指令型”：即便给了工具定义，它也倾向于先回复用户再等下一步指令，或者干脆忽略工具。我踩过最狠的一次坑，就是工具定义齐全但忘了写“当用户请求中包含XX关键词时，你必须调用工具”，结果模型全程跟用户聊天，一个函数都没触发。

修正办法是：在系统提示里加一节明确的“工具使用策略”，正向来写。比如：

工具使用策略： 1. 当用户请求涉及订单查询时，必须调用查询订单工具； 2. 当用户请求涉及退款操作时，必须先调用用户身份验证工具； 3. 如果用户的请求无法匹配任何工具，请直接告诉用户当前功能不可用，并且不要自行编造结果。

这样改写后，工具调用触发率明显回升。

4. 构建一套可移植的提示架构

4.1 三层解耦：意图层、策略层、表达层

跨模型实践做得越久，我越强烈地意识到：提示词不能是一个平铺的大文本，它应该被拆成三个清晰层次，否则每次适配都是一次彻底重写。

我目前项目中用的分层方式是这样的：

• 意图层：描述业务功能本身，跟模型无关。比如“从用户反馈文本中提取负面情绪原因”；
• 策略层：描述解决路径，跟任务有关但跟具体模型关系不大。比如“先判断情绪极性，再提取对应的原因短句，最后归类到预定义类别”；
• 表达层：把意图和策略翻译成某类模型更懂的语言、结构和样例。这一层是适配的主战场。

用这个框架后，大部分迁移工作只发生在表达层。意图层和策略层基本不动，等于每次换模型，我只需要重写一小段“翻译”，而不是重构整个业务流程。

4.2 适配器模式：一套业务逻辑，多个模型实现

软开经验在这里很有用。我把“提示架构”实现成轻量的适配器结构，每个模型分支负责自己专属的表达层。伪代码如下：

class ModelAdapter: def build_messages(self, task_prompt, user_input): raise NotImplementedError class ChatGPTAdapter(ModelAdapter): def build_messages(self, task_prompt, user_input): return { "system": task_prompt, "user": user_input } class ClaudeAdapter(ModelAdapter): def build_messages(self, task_prompt, user_input): return { "system": task_prompt, "user": user_input }

从表面看，两者代码差不多，但真正的差异在task_prompt内部。我们在数据库里存两份“表达层提示”：

• 一份是ChatGPT系友好版，结构简洁，强调直接指令；
• 一份是Claude系友好版，结构完整，强调正向规则和XML样例。

业务代码只跟统一接口打交道，不关心底层在跑谁，这样切换模型只需要改配置，不需要改主流程。

4.3 评估体系先行：没有度量就没有迁移

多模型实践的另一个核心问题是如何判断“迁移成功了”。很多人比较模型只靠肉眼抽几个例子，这在单条对话上也许够用，但用在评估一套提示架构时远远不够。我的做法是建一个固定的评测集，至少包含50条覆盖典型、边界、异常情况的输入样本，每条都有预期输出标准，然后批量跑完，用脚本统计成功率、格式合规率、平均响应时长、token消耗。

测评集里必须包含四类样本：

• 常规样本：正常业务输入，预期稳定输出；
• 边界样本：输入接近超长、缺字段、空值等极端情况；
• 对抗样本：用户故意诱导模型偏离规则（比如要求忽略指令、输出其他格式）；
• 回归样本：早期版本跑通过的关键case，确保新模型没有倒退。

我一般是先跑20条快速初筛，通过后再跑全量，否则一次50条全量跑完再分析，遇到低级错误会很浪费时间。

在评测结果分析上，还有一个容易忽略的点：同样一条提示，模型不同版本也会有波动。所以我会在评估报告里记录模型版本号、当日接口参数、测试时间，避免过两天查问题时发现“当时的结果是用旧版本测出来的”。

5. 常见问题与排查技巧实录

5.1 多模型迁移问题速查表

下面这张表是我在跨模型实践中最常遇到的故障现象和排查路径，可以直接拿来当排查手册用：

5.2 我的独家避坑心得

第一个避坑点：千万不要大规模切换前不做全量回归。我见过有团队把生产环境的模型供应商切了，提示词也改得“差不多”，上线之后才发现有5%的用例会间歇性垮掉，而且垮得很随机，查了大半天才定位到是某个示例模板在Claude系产品上产生了误导。后来我们定了个铁律：任何模型切换，一律先跑全量评测集，哪怕多花一两小时，也绝不直接人肉抽样看两三个效果就放行。

第二个避坑点：系统提示里的每条规则都要能解释“为什么存在”。我最早喜欢堆规则，一个系统提示写二十条，看起来很严谨。结果换模型后一堆规则互相冲突，表现反而不如三条核心规则加两个样例。后来我只保留可验证的硬性约束，能在代码层解决的问题（比如JSON Schema校验）绝不塞进提示里。提示是最后一道闸，不是第一道防线。

第三个避坑点：跨模型实践一定要记录“提示版本”。我用的是最简单的方案，每个提示文件头写一个注释块，包括用途、适配模型、修改日期、改动人。这样某天换模型后发现效果波动，至少能回溯到哪一版提示引入的。

第四个避坑点：中英文表达效果差异比想象中大。同一个提示翻译成英文后，在两边模型上表现都可能变化，而且不是线性提升。我不建议盲目全英文，最好用你目标场景的真实语料来评测，谁表现好就用谁。中文提示在Claude系产品上确实需要更强调结构，比如多用“输出要求：”这样的显式标签，而不是用冒号带过。

第五个避坑点：成本估算要单独跑，不要拍脑袋。Claude系产品在长系统提示场景下，token消耗可能比你想的高得多；而ChatGPT系产品在开启输出约束后也可能额外消耗token。我习惯在评测集上统计每次请求的平均token数，然后按业务量级换算成本，再决定到底用哪套适配方案。

最后分享一个实用技巧

做了这么久跨模型实践，我最常说的一句话是：别让你的提示词太“聪明”，要让它足够“稳”。所谓稳，就是换一个模型、改一个版本，输出的结构、格式和核心质量仍然在你可控范围内。想做到这一点，最有效的手段就是——把不确定性尽量从自然语言层搬到代码层。结构化校验、重试机制、格式清洗、回退策略，这四样东西永远是提示工程最好的补刀工具。提示词负责开路，代码负责兜底，两者配合，你才敢在多个模型之间游刃有余地切换。