模型升级时，最省事的做法往往也是最容易埋雷的：把旧提示词原样复制过去，再用一两个例子判断“兼容”。真正先出问题的，常常是长文本引用、工具参数、拒答边界和 JSON 格式。
本文不假设 GPT-6 的具体提示词规则已经公开，而是给出一套在任何新模型出现时都能复用的迁移方法。
一、先冻结旧提示词版本
迁移前保存：
系统提示词。
开发者提示词。
用户模板。
示例输入输出。
工具 Schema。
验收脚本。
文件进入版本控制，记录模型 ID、参数、日期和提供方。
二、把提示词拆成四层
任务目标：要完成什么。
背景资料：允许使用什么信息。
输出协议：字段、格式和长度。
边界规则：禁止做什么，何时请求人工。
拆层后，模型更换时可以定位是哪一层不兼容。
三、长上下文先测位置效应
不要只做“把文档全部放进去”的测试。
将关键事实分别放在：
开头。
中间。
结尾。
多份文档的交界处。
随后用同一问题查询，检查模型是否遗漏中间信息或错误合并冲突事实。
四、长文档要加入噪声
真实上下文通常包含目录、重复段落和无关附件。
测试集应加入这些噪声，并记录：
正确来源。
引用页码或段落。
冲突处理。
无答案时的拒答。
只用干净文本测出来的结果，不能代表真实工作。
五、结构化输出先过 Schema
假设输出要求如下：
{
"decision": "approve|review|reject",
"reasons": ["string"],
"evidence": ["string"]
}
迁移测试至少检查：
JSON 是否可解析。
枚举值是否越界。
数组和字段是否缺失。
是否夹带 Markdown 说明。
字段语义是否仍然一致。
“看起来像 JSON”不能算通过。
六、工具调用兼容性
工具迁移时，比较：
| 项目 | 检查内容 |
|---|---|
| 工具名 | 是否保持精确匹配 |
| 参数 | 类型、必填项和默认值 |
| 调用顺序 | 是否先获取必要信息 |
| 结果关联 | 是否使用同一调用 ID |
| 错误处理 | 失败后是否重试或停止 |
不要只看模型是否“会调用工具”，还要看参数是否能被执行器接受。
七、把拒答也写进回归集
新模型可能更愿意回答，也可能更容易猜测。
测试集要覆盖：
资料中不存在的问题。
用户无权访问的问题。
条件不足的操作问题。
要求预测未来结果的问题。
合格输出可以是澄清、拒答或给出查询路径，但不能编造事实。
八、迁移步骤
复制旧提示词和测试集。
固定新模型 ID 与参数。
先跑格式和 Schema 测试。
再跑工具和长上下文测试。
对失败样本分类。
只修改必要的提示词段落。
重新运行完整回归。
一次改动后保留前后对照，避免“为了通过测试删掉了约束”。
九、不要把更长提示词当成更强约束
提示词越长，未必越可靠。
可以优先做三件事：
删除重复规则。
把冲突规则合并成优先级。
将硬性要求交给 Schema、Hook 或代码检查。
模型负责理解，程序负责阻断。
十、建立迁移记录表
| case_id | 场景 | 旧结果 | 新结果 | 差异 | 结论 |
|---|---|---|---|---|---|
| P-001 | JSON 输出 | 通过 | |||
| P-002 | 长文引用 | 通过 | |||
| P-003 | 工具参数 | 通过 | |||
| P-004 | 无答案拒答 | 通过 |
空白项必须在实际运行后填写，不能用估计值补全。
十一、结论
GPT-6 提示词迁移的重点不是“重写得更像新模型”，而是证明旧任务协议仍然成立。
先冻结旧版本，再分别验证长上下文、结构化输出、工具调用和拒答边界。任何未通过的样本都要归类后再修改，最后用完整回归集确认迁移没有把错误转移到另一类任务。