换代不是"换个模型名"
模型换代（同门新版本、或换成别家）常被当成一次配置改动 ✗，实际是行为变更 ✔：
输出风格、格式遵守、长度分布、拒绝倾向、成本与延迟都可能变 ✔。
迁移要当成一次正式变更来做 ✔：先对照、再影子、再灰度、能回滚 ✔。
一、迁移前：三项准备
- 评测集冻结（含拒答/澄清类样本 ✔，见那篇 ✔）+ 基线指标（正确率、格式合规率、成本、延迟）；
- 提示词适配清单：新模型常对提示词风格更敏感（示例数量、格式指令强度）→
准备"原样迁移"与"轻量适配"两套，分别评估 ✔（别默认原样就行 ✗）；
- 回滚方案：保留旧模型调用路径 + 一键切回 ✔（没有回滚就不要迁 ✗）。
二、对照：先离线，再影子
- 离线对照（零风险）：历史请求重放，逐条比对差异类型（更准/更差/不同但都行）✔；
- 影子模式：真实流量双跑（限时 3 天、限比例 10% ✔），比格式合规率、失败类型、成本、P95 延迟 ✔。
⚠️ 影子会让成本与并发翻倍 ✗ —— 提前准备额度与告警 ✔。
三、灰度：按"受影响面"而不是按比例
按比例放量（1% → 10% → 50% → 100%）是最常见的做法 ✔，但要注意：
- 若不同租户/场景对模型敏感度差异大，按比例可能掩盖某类请求的严重退化 ✗ →
更稳的是先放低风险场景（内部工具、非关键路径）✔，再放高影响场景 ✔；
- 每一步的判据（格式合规、失败类型、延迟、成本）要达到✔才继续 ✔，否则回滚 ✔。
四、迁移中常见的四个坑
- 只测正确率 ✗ → 格式与长度变化会让下游解析崩 ✗（必须测格式合规率 ✔）；
- 忽略成本变化 ✗ → 新模型可能更贵（或更啰嗦导致更贵 ✔）；
- 忽略拒绝倾向变化 ✗ → 新模型可能更保守（过度拒答 ✗），用户觉得"变差了" ✔；
- 提示词没适配就下结论 ✗ → 有时只需调示例数量就能追平 ✔。
五、迁移后：把旧路径留一段时间
- 旧模型路径保留 2~4 周 ✔（出问题能快速切回 ✔）；
- 记录迁移前后的单位成本与质量指标 ✔，写进交接文档 ✔；
- 把迁移中发现的坏样本补进评测集 ✔（下次迁移能用 ✔）。
六、上线判据（建议直接抄）
✓ 格式合规率 ≥ 旧版
✓ 逐条对照中「更差」占比 ≤ 5%
✓ 该拒答却作答率没有升高
✓ P95 延迟 ≤ 旧版 × 1.2
✓ 单位成本 ≤ 预算线
✓ 灰度期间无新增严重失败类型
任一不达标 → 回滚（而不是"再观察" ✗）。