一家运行生产级 AI 分诊助手的医疗保健公司收到了一封令所有团队都心生畏惧的邮件：他们的推理服务商将在 90 天后停用他们正在使用的模型。他们更新了模型字符串，进行了快速的手动冒烟测试，然后发布了替代版本。三周后，新模型开始主动提供未经请求的诊断意见。Token 使用量暴增了 5 倍。整个 Prompt 模板由于新模型对指令表述的解读不同而失效。由于输出 Schema 发生了偏移，JSON 解析也宣告失败。
这并非个案。如果你仅仅将模型停用视为一种配置变更，而不是一次系统迁移，那么这就是你在模型停用周期中的常态体验。
大多数提示词迁移在预发布环境看起来都很顺利。90% 的测试用例通过，新模型的响应感觉更清晰，演示也运行得很流畅。然后你上线了，不到两天，结构化输出解析器开始在 12% 的响应中抛出异常，一个面向用户的分类流水线开始返回错误标签，一个工具调用 Agent 在一个之前能正常处理的 Schema 上陷入了循环。没有人改动过提示词。是模型变了。
这就是提示词-模型耦合陷阱：在某个模型上可靠运行的提示词，会悄然积累对该模型特定行为怪癖的依赖，而这些依赖在迁移日之前根本看不见。
大多数团队发现自己依赖模型的方式，和你发现承重墙的方式一样——试图拆掉它的时候。停用邮件到了，你在配置中替换了模型标识符，然后你的应用开始返回自信、格式优美、却微妙错误的答案。没有报错，没有崩溃，只是信任在缓慢流失，需要数周才能察觉，数月才能修复。
这就是模型下线悬崖：强制迁移揭示出你"模型无关"的系统其实从未无关过的那一刻。你的提示词、输出解析器、评估基线、用户的期望——所有这些都在悄悄地校准到即将按照别人的发布节奏而改变的行为特性上。
每个生产环境中的 LLM 系统都会面临模型迁移。供应商发布了新版本。你需要降低成本。竞争对手提供了更好的延迟。监管要求需要更换供应商。问题从来不是你是否会更换模型——而是你是否能安全地完成迁移，还是会由于惨痛的教训才意识到，“仅仅运行评估套件”会在预发布环境（Staging）的信心与生产环境的现实之间留下巨大的鸿沟。
大多数团队将模型迁移视为库升级：更换依赖项、运行测试、然后发布。这对于确定性软件有效。但对于概率性系统，这种方式会遭遇灾难性的失败。在这些系统中，相同的输入在不同模型版本中可能产生语义迥异的输出，而且你的提示词（Prompt）往往针对你正准备替换的模型行为特性进行了隐式调优。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
