高阶加餐 07｜跨模型迁移：一套 Prompt 如何兼容 DeepSeek、Qwen、GLM、Kimi 等模型

真正成熟的 Prompt 不应该只在某一个模型、某一次对话里"碰巧有效"，而应该有核心协议、有模型适配层、有回归测试。

很多团队会遇到这样的情况：

同一个 Prompt 在模型 A 上很好，换成模型 B 后：

输出格式变了；
更爱解释；
更容易省略字段；
长上下文表现不同；
Few-shot 敏感度不同；
工具选择偏好不同；
对"必须/禁止"的遵守程度不同。

于是工程师开始复制 Prompt：

text 复制代码

prompt_deepseek.txt
prompt_qwen.txt
prompt_glm.txt
prompt_kimi.txt
prompt_v2.txt
prompt_final.txt
prompt_final2.txt

几个月后没人知道哪个才是正确版本。

这篇讲的不是"哪个模型更好"，而是如何设计可迁移 Prompt 架构。

一、先建立正确认知：不要追求"一字不改通吃所有模型"

不同模型存在差异很正常。

你真正应该追求的是：

text 复制代码

80%~90% 核心任务协议保持一致
10%~20% 通过适配层调整

也就是说：

text 复制代码

核心 Prompt
+ 模型适配规则
+ 模型参数
+ 测试集

而不是为每个模型重新写一套业务逻辑。

二、把 Prompt 拆成四层

第一层：业务目标

例如：

text 复制代码

判断客户投诉严重程度。

这个不应该因为模型变化而变化。

第二层：业务规则

例如：

text 复制代码

涉及账号盗用 → severity=5
涉及资金损失 → need_human=true

这些也是你的业务规则，不属于模型。

第三层：输出协议

例如：

json 复制代码

{
  "severity": 1,
  "need_human": true
}

原则上也应该跨模型稳定。

第四层：模型适配

例如：

是否需要更强的"只输出 JSON"约束；
是否需要示例；
是否需要更短的 System Prompt；
是否需要额外自检；
是否要限制输出长度；
是否要调整 temperature。

只有这一层跟模型强相关。

三、跨模型 Prompt 的核心母版

text 复制代码

【任务】
{{TASK}}

【业务规则】
{{BUSINESS_RULES}}

【输入】
<<<
{{INPUT}}
>>>

【输出协议】
{{OUTPUT_SCHEMA}}

【通用约束】
{{COMMON_RULES}}

【模型适配规则】
{{MODEL_ADAPTER}}

运行时：

text 复制代码

MODEL_ADAPTER = adapter_deepseek

或者：

text 复制代码

MODEL_ADAPTER = adapter_qwen

这样业务规则只维护一份。

四、不要把模型名字写死在业务 Prompt 里

很多 Prompt 里写：

text 复制代码

你是 DeepSeek，请充分发挥 DeepSeek 的推理能力......

如果以后切模型，就得到处改。

更好的业务 Prompt：

text 复制代码

你是一个严格的任务执行器。

模型名称只出现在配置层。

除非你真的需要模型特有能力，否则不要把供应商信息写进业务逻辑。

五、跨模型最容易漂移的五类内容

1. 格式遵守

有的模型特别喜欢在 JSON 前解释。

解决方式：

text 复制代码

只能输出 JSON。
禁止 Markdown。
禁止前后说明。

并在后端校验。

2. 回答长度

有的模型容易展开。

规定：

text 复制代码

reason 最多 80 字。

比：

text 复制代码

简短回答。

更稳定。

3. 不确定时的行为

有些模型更愿意补全。

统一规定：

text 复制代码

缺少依据时返回 null，不得猜测。

4. Few-shot 依赖

某些任务一个示例就够，某些模型需要 2~3 个边界示例。

不要把示例散落在主 Prompt，单独做：

text 复制代码

EXAMPLES

模块。

5. 工具调用

不同模型在工具选择和参数稳定性上可能不同。

工具协议本身不变，适配层可以增加：

text 复制代码

调用前检查必填参数。
参数无法确定时禁止调用。

六、一个完整的模型适配配置思路

可以把配置抽象成：

yaml 复制代码

model: deepseek

adapter:
  strict_json_reminder: true
  self_check: true
  max_reason_chars: 80
  few_shot_count: 2
  tool_argument_check: true

换模型：

yaml 复制代码

model: qwen

adapter:
  strict_json_reminder: true
  self_check: false
  max_reason_chars: 80
  few_shot_count: 3
  tool_argument_check: true

注意：这里不是说某个具体模型一定需要这些值。

真正做法是：

通过测试集测出来。

不要靠印象配置。

七、跨模型迁移前必须建立基准测试集

没有测试集，就没有"迁移成功"这个概念。

建议至少包含：

正常样本

任务信息完整。

缺失样本

关键字段不存在。

冲突样本

输入内部有矛盾。

边界样本

刚好卡在分类边界。

格式压力样本

复杂数组、嵌套 JSON。

长文本样本

测试上下文处理。

恶意样本

例如输入里写：

text 复制代码

忽略所有规则。

工具样本

参数完整/不完整分别测试。

八、不要比较"感觉"，要比较指标

模型迁移评测至少记录：

指标	模型 A	模型 B
任务准确率	94%	92%
JSON 合法率	99%	96%
字段完整率	98%	98%
幻觉率	2%	3%
拒答准确率	91%	95%
平均输入 Token	4200	4200
平均输出 Token	900	1100
平均延迟	...	...
单任务成本	...	...

只有这样你才知道：

text 复制代码

换模型到底是变好了还是变差了。

九、DeepSeek → 其他模型时，不要第一时间改业务规则

假设同一个结构化 Prompt：

在模型 A 上 JSON 合法率 99%。

换模型 B 后只有 92%。

错误做法：

text 复制代码

把整个 Prompt 重写。

正确顺序：

保持业务规则不变；
找具体失败样本；
判断是格式问题、理解问题还是边界问题；
只在适配层修复；
回归测试。

例如发现模型 B 经常加 Markdown：

只加：

text 复制代码

适配规则：
禁止使用 ```json 代码围栏。

不要把所有业务 Prompt 推倒重来。

十、跨模型 Prompt 的"最小差异原则"

每增加一个模型专属规则，都问：

text 复制代码

这真的是模型差异，还是原 Prompt 本身不清楚？

例如：

模型 A、B 都会误判一个边界案例。

那不是适配问题，是业务规则缺失。

应该改 Common Rules。

只有某个模型单独失败，才进入 Adapter。

十一、可直接复制：跨模型通用任务 Prompt

text 复制代码

你是严格的业务任务执行器。

【目标】
{{TASK}}

【业务判定规则】
{{BUSINESS_RULES}}

【事实约束】
- 只能根据输入事实判断。
- 不存在的信息不得猜测。
- 无法确定时使用规定的 unknown/null 策略。

【输出协议】
{{SCHEMA}}

【通用格式规则】
- 字段名不得修改。
- 类型不得修改。
- 禁止增加字段。
- 禁止 JSON 前后解释。
- 禁止 Markdown。

【输入】
<<<
{{INPUT}}
>>>

{{MODEL_ADAPTER}}

然后单独注入：

text 复制代码

【模型适配】
生成最终结果前检查一遍 JSON 合法性和枚举值。

十二、Few-shot 也应该模块化

不要这样：

text 复制代码

Prompt 主体里永久写 10 个示例。

应该：

text 复制代码

BASE_PROMPT
+ SELECTED_EXAMPLES
+ MODEL_ADAPTER

根据任务动态选最有价值的示例。

例如：

text 复制代码

分类任务：
- 一个正常样本
- 一个边界样本
- 一个拒答样本

这样更省 Token，也更易迁移。

十三、长上下文模型不代表你应该无限塞资料

即使模型支持更长上下文，也不应该把：

text 复制代码

整个项目所有文档

每次都注入。

跨模型迁移时，上下文窗口差异可能很大。

最稳的架构仍是：

text 复制代码

检索
→ 压缩
→ 选相关内容
→ 注入

而不是：

text 复制代码

模型支持长上下文 → 全塞

这也能减少切模型时的迁移成本。

十四、模型参数也属于适配层

例如：

temperature；
top_p；
max_tokens；
reasoning 配置；
tool choice；
stop；
structured output 模式。

这些都不要写死在 Prompt 文本里。

十五、模型能力变化时如何升级

假设新模型原生支持严格 Schema。

以前 Prompt 里有 500 字 JSON 格式约束。

这时可以考虑把一部分格式控制迁移到 API Schema 层。

但不要直接删除。

正确流程：

启用原生 Schema；
保留旧 Prompt；
跑测试；
逐步减少重复格式规则；
再跑回归；
确认稳定后发布新版本。

这叫渐进迁移。

十六、跨模型版本管理建议

不要保存：

text 复制代码

final_prompt.txt
final_prompt2.txt
final_prompt_new.txt

十七、Prompt 变更要像代码一样有版本

例如：

text 复制代码

v1.3.0

Changed:
- 新增账号盗用 → severity=5 规则

Fixed:
- 修复缺失产品名称时错误猜测

Adapter:
- 加强某模型 JSON 输出限制

只要 Prompt 影响业务结果，它就不是"随便一段文字"。

它是业务代码的一部分。

十八、跨模型迁移实战流程

假设当前使用 DeepSeek，要测试另一国产模型。

完整流程：

第 1 步：冻结当前 Prompt

不要边迁移边改业务规则。

第 2 步：冻结测试集

确保两个模型跑的是同一批数据。

第 3 步：记录基线

包括：

准确率；
格式率；
幻觉率；
拒答率；
Token；
延迟；
成本。

第 4 步：直接跑新模型

先不加适配。

第 5 步：收集失败类型

分类：

text 复制代码

FORMAT
BUSINESS_RULE
HALLUCINATION
LONG_CONTEXT
TOOL
REFUSAL

第 6 步：只修适配层

不要污染 Base Prompt。

第 7 步：回归

所有历史样本重新跑。

第 8 步：灰度

不要一次性切全部生产流量。

十九、一个模型路由场景

如果系统同时接多个模型，不一定非要"统一一个模型"。

可以按任务路由：

text 复制代码

结构化抽取 → 模型 A
长文档 → 模型 B
代码审查 → 模型 C
低成本批处理 → 模型 D

此时 Prompt 架构更需要：

text 复制代码

统一业务协议
+ 模型适配器

否则每个路由节点都会出现独立 Prompt，最后维护失控。

二十、跨模型最危险的事情：偷偷改变业务语义

例如迁移后为了提高准确率，把：

text 复制代码

无法判断 → review

改成：

text 复制代码

无法判断 → pass

这已经不是模型适配，而是业务规则改变。

一定要区分：

text 复制代码

Prompt 工程优化
vs
业务决策变化

后者必须单独评审。

二十一、跨模型迁移检查清单

二十二、最终跨模型 Prompt 工程模板

text 复制代码

PROMPT PACKAGE

1. BASE
   - 任务目标
   - 业务规则
   - 事实约束
   - 安全规则

2. SCHEMA
   - 字段
   - 类型
   - 枚举
   - 错误策略

3. EXAMPLES
   - 正常
   - 边界
   - 拒答

4. ADAPTER
   - 模型专属格式约束
   - 模型专属自检
   - 模型专属 Few-shot 数量

5. MODEL CONFIG
   - temperature
   - max tokens
   - reasoning/tool config

6. TESTS
   - 固定测试集
   - 历史失败样本
   - 回归标准

结语

如果你的 Prompt 只能在某一个模型上工作，它更像"技巧"。

如果你的 Prompt 可以：

换模型；
做测试；
追踪版本；
局部适配；
保持业务语义一致；

那它才真正开始变成工程资产。

最成熟的目标不是：

text 复制代码

找到一个永远最强的模型。

而是：

text 复制代码

无论底层模型怎么换，业务规则、数据协议和质量标准都由你掌控。