下线是可预期的常态
模型下线通常经历三个阶段：公布弃用公告、进入弃用期、到期停服。停服当天才动手是最贵的做法，因此要把迁移前置成清单化动作：盘清依赖位置，评估替代版本，用已有评测集比较差异，灰度切换验证，最后清理配置与文档。整条链路的交付物是「可回滚的切换」而不是一次性的替换。
基本信息
| 阶段 | 公告、弃用期、停服日（具体提前量以官方公告为准） |
|---|---|
| 盘点范围 | 代码、配置、提示词、评测集、文档、前端文案与客户资料 |
| 替代评估 | 用同一评测集对比替代版本，标注能力差异与成本变化 |
| 验证方式 | 灰度按比例切换，观察护栏指标后再全量 |
| 交付物 | 迁移记录、回归结论、回滚方案与切换时间点 |
| 责任人 | 指定迁移负责人与验收人，避免无人跟进 |
典型使用场景
- 收到弃用公告：按清单逐项处理，把时间点前置到停服前数周
- 多模型架构：把默认路由与专用路由分别盘点，防止漏掉影子调用
- 客户前置沟通：涉及交付承诺的功能要提前说明行为可能与成本变化
- 文档同步：示例代码、SDK 说明与内部规范一并更新
- 回归验收：迁移后跑固定集，确认通过率与格式合法率无回退
- 成本复核：替代版本的单位用量可能不同，需重算预算基线
阶段动作与交付物
| 阶段 | 动作 | 交付物 |
|---|---|---|
| 公告期 | 盘点依赖、确认影响面、初步评估替代 | 依赖清单与影响范围说明 |
| 评估期 | 同题对比替代版本、标注差异与成本 | 回归结论与能力差异表 |
| 准备期 | 改造提示词与参数、补齐错误处理 | 改造记录与配置变更单 |
| 灰度期 | 按比例切流、观察护栏指标 | 灰度报告与回滚判定记录 |
| 全量期 | 切默认路由、清理旧配置 | 切换记录与版本台账更新 |
| 收尾期 | 更新文档与评测集、归档结论 | 文档更新与验收签字 |
迁移检查清单
迁移检查清单
# 迁移检查清单（每条留痕：负责人 + 完成日期）
- [ ] 代码与配置：搜索全部模型标识出现位置，含脚本与定时任务
- [ ] 提示词：确认是否针对旧模型调过格式，新模型是否需要改写
- [ ] 评测集：确认能覆盖涉及该模型的所有场景，含边界与长尾
- [ ] 参数：核对采样、输出上限与结构化输出开关是否被延续
- [ ] 错误处理：替代版本可能返回新的错误码与结束原因
- [ ] 灰度：设置初始比例与护栏阈值，明确回滚触发条件
- [ ] 成本：按用量分布重算预算，设置费用告警
- [ ] 文档与对外材料：同步示例、说明与客户承诺表述最容易漏的是影子调用：定时任务、数据回填脚本、内部工具与测试环境常常保留着旧模型标识，生产改造完成了，它们到停服日才报错。盘点时用搜索而不是靠记忆。
替代版本的行为差异不只在质量：输出长度、结构化输出的稳定性、拒答倾向与用量计量方式都可能变。迁移验收要把这些一起纳入，否则成本与解析环节会先出问题。
不要等到停服日再切换。预留足够的灰度观察时间，并在切换前确认回滚路径仍然可用；若厂商不提供旧版本续期，回滚目标应指向另一个已验证的替代版本。