模型退役潮生存手册：一人项目的"换芯"SOP

10 月 2 日早上，GitHub Copilot 一天之内退役了四个模型。如果你那天打开 VS Code，会发现模型选择器里少了几个熟悉的名字——这件事我们已经在《GitHub Copilot 一天退役四个模型：AI 编程进入"模型换芯"时代》里报道过。但新闻只讲了一半：退役公告发出来之后，真正的工作才开始——你的项目里，所有写死模型名的地方，都要在截止日期前换掉、测过、灰度上线。

而 10 月只是开始。GPT-5.5 在 10 月 14 日从 Codex 退役，Copilot 第二波六个模型在 10 月 19 日退役，OpenAI API 又有一批 17 个模型标识在 10 月 23 日关停。也就是说，这个月里，一个普通的一人项目可能要经历两到三次"被迫换模型"。这不是技术升级，这是运营常态——就像服务器要续费、证书要更新一样，模型退役已经变成了每个 AI 应用生命周期里固定会发生的一件事。

这篇指南不复述新闻，只解决一个问题：当模型退役公告砸到你头上时，你手里有没有一套"换芯 SOP"——从抽象层设计、eval 基线、灰度切换、公告监控、成本核算，到一页纸 checklist，全部是可以直接抄走的实操。这套流程的核心判断只有一句：没有换芯 SOP 的项目，每次模型退役都是一次小型线上事故；有 SOP 的项目，换芯只是一次普通的发布。

一、退役潮盘点：过去两周，模型死得比你的迭代还快

先把时间线摆出来。下面这些都是近两周内真实发生或板上钉钉的退役事件，每一条都能在官方 changelog 上查到出处：

• 10 月 2 日（已执行）——GitHub Copilot 第一波：Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7 从 Copilot Chat、行内编辑、Ask/Agent 模式和代码补全中全部下线，官方给了替代映射（Gemini 3.8 Flash、Kimi K3、Claude Opus 5.5）。
• 10 月 14 日——GPT-5.5 从 Codex 退役：OpenAI 宣布 GPT-5.5 从 ChatGPT、ChatGPT Work 和 Codex（ChatGPT 账号登录）退役，替代方向是 GPT-5.6 Sol 或 GPT-6 Astra。注意这条有个关键细节，下面会展开。
• 10 月 19 日——GitHub Copilot 第二波（9 月 18 日预告）：Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5 退役，分别由 Gemini 3.8 Flash、GPT-5.6 Sol、GPT-5.6 Luna、Grok 4.6 接替。
• 10 月 22 日——Google Veo 3.1 预览版视频模型结束：如果你在做 AI 视频功能且用的是预览版模型，这条线也在本月到期。
• 10 月 23 日——OpenAI API 关停波：17 个模型标识停止服务，包括 gpt-4-0613、gpt-4-turbo、gpt-4o-2024-05-13、gpt-4.1-nano、gpt-3.5-turbo-0125、gpt-image-1、o1、o1-pro、o3-mini、o4-mini 等（这批从 2026 年 4 月 22 日起就已标记 deprecated，10 月 23 日是关停日）。
• 11 月 30 日——Anthropic Claude Sonnet 4.5 快照退役：claude-sonnet-4-5-20250929 退役，替代为 claude-sonnet-5-5。Anthropic 的政策是公开模型至少提前 60 天通知，这是三家里对开发者最友好的。
• 2027 年 1 月 6 日——OpenAI 自助微调新任务关停：如果你在旧 base 上有 fine-tune，新任务窗口正在关闭，fine-tune 的迁移比 base 模型更麻烦，要单独排期。

从这张时间线里能读出三个判断，个个都影响你的 SOP 设计：

判断一："产品界面退役"和"API 关停"是两条线，别混为一谈。GPT-5.5 的公告是最好的教材：它从 ChatGPT 和 Codex（ChatGPT 账号登录）退役，但 OpenAI API 不受影响，API key 调用的 gpt-5.5 照常用。反过来，10 月 23 日那批是纯 API 关停，ChatGPT 用户毫无感觉。一人团队最常见的误判就是看到"GPT-5.5 退役"五个字就全量恐慌，或者看到"API 不受影响"就以为自己没事——你的第一动作永远应该是：先确认你的调用走的是哪条通道，再决定动不动。

判断二：模型的"寿命"中位数在快速缩短。GPT-5.5 是 2026 年 4 月 23 日发布的，10 月 14 日退役——一款旗舰模型，寿命不到半年。Grok 4.5 更极端，上线两个月就进了 10 月 19 日的退役名单。以前我们按"年"来规划模型选型，现在要按"季度"来规划。你的架构必须假设：任何模型都可能在 6 个月内消失。

判断三：退役正在从"通知"变成"流水线"。GitHub 两波退役间隔 17 天，OpenAI 一年内排了四波。Anthropic 甚至给每个模型都预置了一个"不早于某日期"的暂定退役时间。这意味着"等公告来了再动手"的模式已经不够用了——你需要的是常态化的监控和随时可执行的换芯流程。这正是下面几节的内容。

二、换芯三层抽象：把"模型名"从你的代码里赶出去

先说结论：你的代码库里，模型的具体名字应该只出现一次——在配置文件里。如果今天全局搜一下 "gpt-5" 或 "claude-sonnet"，结果散落在十几个文件里，那每次退役你都要玩"大家来找茬"，漏掉一处就是一次线上事故。

换芯的三层抽象，每一层解决一类"换不动"的问题：

第一层：provider 抽象——"调用谁家的 API"是配置，不是代码。所有模型调用都经过同一个 complete(messages) 接口，底下是 OpenAI 兼容、Anthropic、Gemini 等不同适配器。换供应商 = 改一行环境变量，而不是改业务代码。这一层还有一个被低估的好处：当某家供应商出故障或涨价时，你的逃生通道是现成的。

第二层：model 抽象——"用多强的模型"是逻辑角色，不是具体 id。不要在代码里写 model="gpt-5.6-sol"，而是写 role="smart" / role="fast" / role="cheap"，再由一份映射表把逻辑角色翻译成具体模型 id。退役发生时，你要改的只是一个映射表；灰度时，你可以让 "smart" 角色 5% 的流量走新模型，而 "fast" 保持不动——粒度精确到任务类型。

第三层：prompt 抽象——prompt 模板版本化，与模型解耦。prompt 不要散落在业务代码的字符串里，集中放到 prompts/ 目录，按 任务名.v1.md 版本管理。换模型时最常见的返工就是"旧 prompt 在新模型上行为变了"，版本化之后，你可以对同一任务保留 v1（旧模型）和 v2（新模型调优版）两套模板，灰度期按模型路由，回滚时零成本。

这时候一定会有人问：三层抽象是不是过度设计？对 2023 年的团队可能是，对 2026 年的一人团队不是。原因很简单：在 AI 写代码的时代，抽象层的"编写成本"趋近于零——样板代码是 AI 写的，你 review 一下就行；而抽象层省下的"换芯成本"是你自己的深夜时间。用 AI 写出来的抽象，维护它的也是 AI，这笔账只会越算越划算。以前不敢抽象是因为手写样板太累，现在这个约束不存在了。

下面是一个可以直接用的最小实现（TypeScript，Node 18+ 零依赖运行）：

// llm.ts —— 换芯第一层：provider 抽象
export interface ChatMessage { role: "system" | "user" | "assistant"; content: string; }
export interface LLMResult { text: string; inputTokens: number; outputTokens: number; latencyMs: number; }

export interface LLMProvider {
  name: string;
  complete(messages: ChatMessage[], opts?: { maxTokens?: number }): Promise<LLMResult>;
}

// OpenAI 兼容接口：一套代码吃下 OpenAI / DeepSeek / Kimi / 多数国产模型
export class OpenAICompatible implements LLMProvider {
  name = "openai-compatible";
  constructor(private baseUrl: string, private apiKey: string, private model: string) {}
  async complete(messages: ChatMessage[], opts: { maxTokens?: number } = {}): Promise<LLMResult> {
    const t0 = Date.now();
    const res = await fetch(`${this.baseUrl}/chat/completions`, {
      method: "POST",
      headers: { "Authorization": `Bearer ${this.apiKey}`, "Content-Type": "application/json" },
      body: JSON.stringify({ model: this.model, messages, max_tokens: opts.maxTokens ?? 1024 }),
    });
    if (!res.ok) throw new Error(`LLM ${res.status}: ${await res.text()}`);
    const data = await res.json();
    return {
      text: data.choices[0].message.content,
      inputTokens: data.usage?.prompt_tokens ?? 0,
      outputTokens: data.usage?.completion_tokens ?? 0,
      latencyMs: Date.now() - t0,
    };
  }
}

// 第二层：逻辑角色 → 具体模型 id 的映射表（退役时只改这里）
const MODEL_MAP: Record<string, string> = {
  "smart": process.env.MODEL_SMART ?? "gpt-5.6-sol",
  "fast":  process.env.MODEL_FAST  ?? "gpt-5.6-luna",
  "cheap": process.env.MODEL_CHEAP ?? "gpt-5.4-mini",
};

export function createProvider(role: keyof typeof MODEL_MAP = "smart"): LLMProvider {
  return new OpenAICompatible(
    process.env.LLM_BASE_URL ?? "https://api.openai.com/v1",
    process.env.LLM_API_KEY ?? "",
    MODEL_MAP[role],
  );
}

注意这个设计的刻意之处：业务代码里只会出现 createProvider("smart") 这样的调用，模型 id 只在 MODEL_MAP 和环境变量里出现。10 月 19 日 Copilot 那种"一天退六个"的极端情况，你的改动面就是改几个环境变量 + 跑一遍 eval（下一节），而不是全仓 grep。

三、没有基线，别换芯：30 分钟搭出来的最小 eval

这是整个 SOP 里最容易被跳过、也最致命的一步。没有基线的换芯，本质上是在用你的用户做 A/B 测试。站内的 Evals 指南讲过完整的评估体系，那是"日常质量工程"；这里给的是它的应急子集——"最小可用基线"：30 分钟能搭起来，专门为换芯服务，回答一个问题："新模型在我的真实任务上，是不是至少和旧模型一样好？"

最小基线只需要三样东西：

1. Golden set：20~50 个真实生产用例。不要 synthetic 数据，去你的生产日志里捞：最近两周真实用户发过的、覆盖你核心任务类型的输入。每条用例只记三样：id、input、期望的"特征"（不是逐字标准答案）。特征用两条规则表达：must_include（输出必须包含的关键词）和 must_not_include（绝不能出现的反模式，比如裸 URL、"作为 AI"之类的套话）。20 条是下限——低于这个数，随机波动会淹没真实差异。

2. 四个必记指标。每次跑基线，除了通过率，还要记：p50/p95 延迟、输入+输出 token 数、单用例成本。换芯的决策不是"通过率一样就行"，而是四个指标一起看——新模型通过率高 2% 但贵一倍，对一人团队可能是亏的（第六节算这笔账）。

3. 一条跑分命令。基线必须是一条命令能跑完的，否则你不会在深夜真的去跑。下面这个脚本（Node 单文件，零依赖）就是全部：

// eval.mjs —— 用法：LLM_BASE_URL=... LLM_API_KEY=... LLM_MODEL=... node eval.mjs golden.jsonl
import { readFileSync } from "node:fs";

const cases = readFileSync(process.argv[2], "utf8").trim().split("\n").map(JSON.parse);
let pass = 0, tokens = 0, latency = 0;

for (const c of cases) {
  const t0 = Date.now();
  const res = await fetch(`${process.env.LLM_BASE_URL}/chat/completions`, {
    method: "POST",
    headers: { "Authorization": `Bearer ${process.env.LLM_API_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify({
      model: process.env.LLM_MODEL,
      messages: [{ role: "user", content: c.input }],
      max_tokens: 1024,
    }),
  });
  const data = await res.json();
  const text = data.choices[0]?.message?.content ?? "";
  latency += Date.now() - t0;
  tokens += data.usage?.total_tokens ?? 0;
  const ok = (c.must_include ?? []).every(k => text.includes(k))
          && !(c.must_not_include ?? []).some(k => text.includes(k));
  if (ok) pass++;
  else console.log(`FAIL [${c.id}]: ${text.slice(0, 120)}...`);
}

console.log(`通过率 ${pass}/${cases.length} (${(pass / cases.length * 100).toFixed(1)}%)`);
console.log(`平均延迟 ${(latency / cases.length).toFixed(0)}ms · 总 token ${tokens}`);

golden.jsonl 长这样，每行一个用例：

{"id": "summarize-1", "input": "把这段更新日志总结成一句话：v2.3 修复了导出 CSV 乱码……", "must_include": ["修复"], "must_not_include": ["http"]}
{"id": "classify-2", "input": "用户说'你们这什么垃圾，我要退款'，分类为 praise/complaint/refund 之一", "must_include": ["refund"], "must_not_include": ["praise"]}

换芯流程里的用法是固定的：旧模型先跑一遍，记下通过率/延迟/token 三个基线数字；新模型跑同样一套，对比。决策线也固定：通过率下降超过 5 个百分点，直接打回；通过率持平或上升，再看成本和延迟（第六节）。这套基线平时每个月跑一次（10 分钟），换芯时就是你唯一的客观依据。记住一句话：感觉"新模型好像还行"是最贵的幻觉，基线数字才算数。

四、灰度切换四步：影子 → 5% → 50% → 全量

基线过了，不代表可以直接全量。基线用的是历史用例，生产流量永远有你没见过的输入。灰度切换解决的是"未知未知"——四步，每一步都有明确的"继续"和"回滚"条件：

第一步：影子流量（shadow，1~3 天）。生产请求的 100% 同时发给新模型，但新模型的结果只记日志、不返回给用户。这是零风险的一步，目的是在真实流量分布上跑一遍"基线对比"。实现上就是一个包装函数：

// shadow.ts —— 影子流量：用户永远拿到旧模型结果，新模型只跑分
import type { ChatMessage, LLMProvider, LLMResult } from "./llm.js";

export async function completeWithShadow(
  primary: LLMProvider, shadow: LLMProvider, messages: ChatMessage[],
): Promise<LLMResult> {
  const main = await primary.complete(messages);
  // 影子请求：不阻塞、不抛错、只记日志
  shadow.complete(messages).then(
    (s) => console.log(JSON.stringify({
      shadow: true, latencyMs: s.latencyMs, tokens: s.inputTokens + s.outputTokens,
      primaryHead: main.text.slice(0, 200), shadowHead: s.text.slice(0, 200),
    })),
    (e) => console.log(JSON.stringify({ shadow: true, error: String(e).slice(0, 200) })),
  );
  return main;
}

影子期每天看一次日志，重点看三类：新模型报错率、平均延迟对比、输出长度分布（突然变长通常意味着啰嗦，突然变短通常意味着偷工减料）。

第二步：5% 真实流量（3~7 天）。按用户 id 哈希分流，5% 的用户真实走新模型。这一步开始，新模型的结果会影响真实用户，所以监控要上强度：错误率、p95 延迟、单任务成本、用户反馈（投诉/差评）。5% 的量级下，即使全错，影响面也可控。

第三步：50% 流量（至少一个完整业务周期）。"完整业务周期"对一人团队通常意味着 7 天——覆盖工作日和周末两种流量模式。这一步的观察重点从"不出错"变成"质量对比"：抽样 50 条新旧模型的真实输出，人工盲评（不看是哪个模型打的）打分，确认没有系统性质量滑坡。

第四步：全量，但旧模型配置保留两周。全量不是终点，回滚通道才是。旧模型的 MODEL_SMART 环境变量、旧 prompt 模板 v1、旧供应商 key，全部保留 14 天，注释写清"回滚用，某月某日可删"。真出事时，回滚 = 改一个环境变量 + 重启，一分钟内完成。

回滚触发线（满足任意一条，立即回滚，不用开会）：

• 错误率（5xx / 超时 / 空回复）比基线上升超过 2 个百分点；
• p95 延迟比基线增加超过 30%；
• 单任务平均成本上升超过 50%，且没有对应的质量提升；
• golden set 通过率下降超过 5 个百分点；
• 48 小时内用户投诉量翻倍。

把这五条写进你的 SOP 文档，贴在显示器上。回滚触发线最大的价值不是技术上的，而是心理上的：它让你在凌晨三点看到监控报警时，不需要"再观察一下"，直接执行。一人团队没有值班同事帮你做判断，判断必须前置。

五、退役公告监控：每周 10 分钟的 SOP

换芯 SOP 的一半工作其实发生在公告发布之前。退役公告最伤人的不是内容，而是"你没看到"。10 月 23 日 OpenAI API 那批 17 个模型，从 4 月 22 日就标记了 deprecated——有整整半年的窗口，但每年都有团队在关停当天才发现自己的 fine-tune 挂了。

一人团队不需要舆情系统，需要的是一份"每周 10 分钟"的固定动作：

监控清单（4 个页面 + 1 条命令）：

• OpenAI 弃用页（platform.openai.com/docs/deprecations）：API 模型的退役总表，关停日期精确到天，fine-tune 相关也在此；
• Anthropic 模型弃用页（docs.anthropic.com/en/docs/about-claude/model-deprecations）：政策是公开模型至少提前 60 天通知，每个模型还有"不早于某日"的暂定退役时间，可以提前做规划；
• GitHub Changelog（github.blog/changelog）：Copilot 模型退役走这里，10 月两波都是 changelog 首发；
• Google AI 开发者文档的 Gemini API 弃用说明页：Gemini 系列和 Veo 视频模型的退役时间表；
• 你代码库里的一条 grep：grep -rn "gpt-\|claude-\|gemini-\|grok-" --include="*.ts" --include="*.py" --include="*.yaml" --include="*.env*" .——确认生产环境实际在用的模型名，和你"以为"在用的是不是同一个。

每周一早上 10 分钟流程：前 5 分钟刷完 4 个页面，只看"未来 90 天内"有没有你栈里的模型；中间 2 分钟跑那条 grep；最后 3 分钟，把 90 天内到期的模型写进日历提醒（到期前 30 天、7 天各一条）。如果想再自动化一点，开源社区有 model-eol 这类"模型的 Dependabot"——把各家的退役时间表做成机器可读的 feed，跑在 CI 里，效果和 Dependabot 提醒依赖过期一模一样。

还有一个细节：把"退役公告"和"降价/新品公告"分开处理。新品发布（比如 GPT-5.6 Sol 上线）不等于旧模型立刻退役，中间通常有 30~90 天的重叠窗口。这个窗口是你的换芯黄金期——新模型已经可用、旧模型还没下线，灰度四步走得最从容。反过来，如果你等到退役公告才开始，那个窗口已经被你浪费了一半。

六、成本再核算：一次换芯的真实价格公式

聊钱。换芯的成本账如果只算"新模型单价 vs 旧模型单价"，一定会算错——漏掉的三项（重测、返工、双跑）往往比单价差本身更贵。下面是完整公式：

换芯总成本 = Δ单价 × 月 token 量 × 12 + 重测成本 + 返工成本 + 双跑成本

• Δ单价 =（新模型综合单价 − 旧模型综合单价）。"综合"指按你的实际输入/输出比例加权——别拿官网的输入价直接比，如果你的场景输出 token 占比高，输出价才是大头；
• 重测成本 = golden 用例数 × 单次运行成本 × 运行轮数（通常 3~5 轮）+ 你的人工小时 × 你的时薪。人工部分别省：看 FAIL 日志、调 prompt、确认误报，都是时间；
• 返工成本 = prompt 重写小时 × 时薪 + 回归 bug 修复。经验值：prompt 模板数量 × 每个模板 0.5~2 小时，再乘以你的时薪。一人团队的时薪按你接外包的市价算，别按 0 算——你的时间是项目最贵的资源；
• 双跑成本 = 灰度期影子流量的额外 token。影子期如果跑 100% 影子流量，相当于那个月的模型账单翻倍，这笔钱要预先计入。

举个具体例子（数字纯属假设，只为演示公式）：你的客服机器人每月 800 万输入 token、200 万输出 token；旧模型综合单价按 3 美元/百万 token、新模型 5 美元/百万 token 算，Δ单价 = 2 美元。月 token 总量 1000 万 → 每月多花 20 美元，一年 240 美元。重测：40 个用例 × 跑 4 轮，token 花不了几美元，但你要花 4 小时看结果、调 prompt，按时薪 50 美元算就是 200 美元。返工：6 个 prompt 模板 × 平均 1 小时 = 300 美元。双跑：影子跑 2 周 ≈ 半个月账单翻倍 ≈ (1000 万 × 5 美元/百万) × 0.5 = 25 美元。加总：这次换芯的真实成本 ≈ 240 + 200 + 300 + 25 = 765 美元，其中单价差只占三分之一。

这个例子想说明的判断是：小团队换芯，贵的主要不是 token，而是你的人力。所以"新模型便宜 20%"不构成换芯理由（省下的 token 钱可能覆盖不了你的重测时间），而"旧模型要退役了"才构成——这是被迫支出，目标是把总成本压到最低，而不是追逐单价。

还有一个反直觉的结论：别比"单位 token 成本"，比"单位任务成本"。新模型单价贵 50%，但一次生成成功率从 70% 提到 95%（少了重试和人工兜底），单位任务成本反而降了。你的 golden set 里如果记录了"平均每个任务消耗多少 token（含重试）"，这个对比可以直接算出来。很多"新模型更贵"的抱怨，用的都是错误的比较维度。

七、三个真实翻车模式：基线过了，生产还是崩了

即使前面六节都做到位，换芯依然有三种"基线测不出来"的翻车模式。它们之所以危险，是因为每一种的根因都不在模型好坏，而在你的工程假设里：

翻车一：静默降级（silent degradation）。症状：你什么都没改，但某天输出质量悄悄变了。根因有两种——一是供应商把旧模型名做了别名映射（alias），你调的还是那个名字，底下已经换了权重；二是"自动迁移"策略，供应商为了平滑退役，提前把你的流量切到了新模型。这两种都不会触发你的回滚线，因为你的监控看的是"错误率"，而静默降级没有错误，只有"味道变了"。对策：每月跑一次 golden set（就是第三节那条命令），对比通过率和输出长度分布；对核心任务，再加一条"输出 embedding 相似度"检查——语义漂移在数字上是看得见的。

翻车二：prompt 脆弱性暴露。症状：新模型基准分更高，但在你的任务上反而表现更差。根因扎心：你的 prompt 一直是错的，只是旧模型替你兜了底。典型例子——你的 prompt 里写"返回 JSON"，但没写"只返回 JSON，不要解释"；旧模型"碰巧"只返回 JSON，新模型严格遵循指令，把思考过程也吐出来了，下游解析直接炸。旧模型的"宽容"掩盖了 prompt 的不严谨，换芯把这层遮羞布撕掉了。对策：换芯时把 prompt 当作"需要重新验证的输入"，而不是"不用动的资产"；golden set 的 must_not_include 里，专门加一条"禁止解释性文字"，逼 prompt 写严谨。

翻车三：长尾能力丢失。症状：整体指标都变好了，但某个小众功能悄悄坏了。根因：公开基准（SWE-bench、MMLU 这些）测的是通用能力，而你依赖的可能是某个长尾能力——比如泰语客服话术、某种冷门数据格式的解析、超长上下文里特定位置的召回。新模型在这些长尾点上可能反而退步了，而你的 40 条 golden set 恰好没覆盖到。对策：golden set 里强制保留 20% 的"长尾用例"——那些一个月才触发几次、但触发一次就很重要的任务；另外，灰度第三步（50% 流量）的人工盲评，抽样时特意多抽长尾任务。

这三种翻车模式有一个共同点：它们都是"旧模型替你承担了本该由工程承担的东西"——别名兜底、prompt 宽容、长尾记忆。换芯的真正价值，有时候不是换上新模型，而是逼你把这些隐性依赖变成显性工程。

八、一页纸换芯 SOP：复制即用

前面七节浓缩成一张 checklist。收到退役公告的那一刻，打印出来（或复制到你的任务管理工具），逐项打勾：

模型换芯 SOP —— 触发条件：收到任一上游模型的退役/关停公告
┌─ T+0（收到公告当天，30 分钟）
│ [ ] 确认退役范围：是产品界面退役还是 API 关停？（GPT-5.5 教训：两条线）
│ [ ] 确认你的调用走哪条通道：API key / ChatGPT 登录 / Copilot / 第三方网关
│ [ ] 代码库 grep 模型名，列出所有引用点（配置、prompt、文档、runbook）
│ [ ] 在日历建三个提醒：T-30、T-7、T-1（以关停日为 T）
│ [ ] 评估是否命中：没命中 → 归档公告，结束；命中 → 继续
├─ T-30（关停前 30 天）
│ [ ] 检查三层抽象是否到位：模型名只出现在配置文件/MODEL_MAP 吗？
│ [ ] 跑旧模型 golden set，记录基线三数字：通过率 / p95 延迟 / 单任务成本
│ [ ] 选定替代模型，跑新模型 golden set，对比（通过率 -5pp 一票否决）
│ [ ] 核算换芯总成本（第六节公式），确认预算
│ [ ] prompt 模板版本化：v2 针对新模型调优，v1 保留用于回滚
├─ T-7（灰度启动）
│ [ ] 上线影子流量（第四节脚本），跑 1~3 天，看日志三类指标
│ [ ] 切 5% 真实流量，用户 id 哈希分流，监控五条回滚线
│ [ ] 切 50% 流量，跑满一个完整业务周期（通常 7 天）
│ [ ] 50 条真实输出人工盲评，重点抽查长尾任务
├─ T-1（关停前 1 天）
│ [ ] 全量切换，旧模型配置/旧 prompt v1/旧 key 保留 14 天（标注回滚用）
│ [ ] 更新 runbook 和文档里的模型名引用
│ [ ] 团队（如果有）/ 用户公告：如有可感知的行为变化，提前说明
└─ T+7 / T+30（复盘）
  [ ] T+7：对比全量后指标 vs 基线，确认无静默降级（重跑 golden set）
  [ ] T+30：删除旧模型残留配置，归档本次换芯记录（模型对、日期、基线数字、踩坑）
  [ ] 把本次的教训写进 prompt 模板注释，下次换芯少踩一次

最后说一句可能有点逆耳的话：这套 SOP 最大的敌人不是复杂度，而是"这次应该不用吧"的侥幸心理。10 月这波退役潮里，最受伤的永远是那些"先欠着，等关停那天再说"的项目——关停日当天，你面对的不再是一次从容的迁移，而是一次深夜救火。模型退役已经是运营常态，常态就该有 SOP。把这张 checklist 收好，下一次公告来的时候，你只需要 30 分钟就能从"恐慌"切换到"执行"。