通用方法 · 熟练
关掉的不是模型，是你在面板里养的东西
模型下线改一行配置；面板下线要你自己搬
「模型退役」和「平台功能关停」是两件事，但它们的通知长得几乎一样，都叫 deprecation。模型退役的动作是改一个字符串；而面板关停的动作是 —— 你在那个面板里建过的一切，得在那天之前搬到别处：评测集、复用提示词库、拖拽出来的 agent 定义、跑过的历史结果。这一页做的是一张面板资产盘点表：先把「长在面板里」的资产列出来，逐条问一句「它的导出格式是什么」；再给每条定一个去处；判据一句：只能在这里打开的东西，就等于还没有搬走。
方法 · 一图看懂
1
分清两类通知 — 先判断这条 deprecation 关的是「模型名」还是「面板功能」，两者的动手人不同
2
列面板资产清单 — 评测集 · 提示词库 · agent 定义 · 工作流 · 历史结果，逐条写清它现在活在哪里
3
逐条问导出格式 — 有导出 ⇒ 立刻导一次并打开确认；没有导出 ⇒ 按「不可移植」处理，另存纯文本
4
定一个季度核对节拍 — 面板侧的关停通知通常只提前几十天，靠临时抱佛脚来不及
原理 · 为什么有效
为什么面板关停比模型退役难处理？因为两者的失败方向相反。模型退役是运行期失败：那天之后调用报错，你会立刻知道，而且报错点就是需要改的那一行。面板关停是读取期失败：资产没有「报错」这一说 —— 它只是某一天之后打不开了，而你可能几周都不会去点开它。更麻烦的是资产的形态：模型名是纯文本，面板资产常常是「结构 + 依赖」。一个拖拽出来的 agent 定义，里面既有你写的规则，也有指向平台内建工具、内建连接、内建模板的引用 —— 导出成一段文本容易，导出成能在别处跑起来的东西难。所以判据不能是「我导出了没有」，而必须是「导出去之后，我打开过、并且它自己站得住吗」。第三条原理关于节奏：面板侧的通知通常比模型侧短，且替代路径往往指向自建（开源实现 / SDK）—— 那是一门比改配置大得多的工作量，必须在通知期内而不是通知之后开始。
适用场景
适用于把平台面板当成真正工作场所的人与团队：在面板里维护评测集 · 在面板里攒提示词库 · 用拖拽界面搭过 agent 或工作流 · 把平台的运行历史当审计材料。尤其适用于「这套东西不是我个人用，而是团队在依赖」的情形 —— 那时资产的可移植性是团队风险，不是个人习惯。不适用于：只在对话框里问答、不建任何持久资产的用法（没有面板资产就没有这个问题）；也不适用于完全自建、跑在自己机器上的方案（那属于另一条线）。
自测 · 5 问
我说得出「这条 deprecation 关的是模型名还是面板功能」吗（两者动手人不同）
面板里我建过哪些持久资产 —— 逐条能列出来吗（列不出 = 已经有一部分想不起来了）
每条资产有没有导出格式，我导出的那一份打开过并按它自己跑过一次吗
「导不出来的」那几条，我有没有另存一份纯文本（规则 / 说明 / 判定标准），哪怕它不能自动跑
有没有一个固定的核对节拍（每季度对一遍面板侧的关停公告），而不是等出事才看
怎么上手 · 验证步骤
一轮大约 40 分钟，分三步。① 先分流：把手上收到的 deprecation 通知逐条标成「模型名」或「面板功能」—— 这一步只要一句话，但它决定了后面所有工作的性质。② 再盘点：只针对「面板功能」那条线，把面板里的资产列成表（资产名 · 类型 · 现在活在哪 · 有没有导出）。导出这一步有个小纪律：导完立刻在别处打开一次，确认它不是一堆打不开的二进制、也不是只有标题没有内容。③ 后收口：给「导不出来的」各写一段纯文本备份（规则的原始表述 + 它依赖什么），并把核对节拍写进自己的日历 —— 面板侧的关停通常只提前几十天，靠临时抱佛脚来不及。
回看时先核一条最容易自欺的地方：「导出成功」不等于「搬走了」。判据是「在平台之外打开、并且照着它自己跑过一次」。第二处要核的是依赖：面板资产里引用到的内建工具 / 内建连接 / 内建模板，换到别处之后有没有对应的替代 —— 没有的话，那段资产其实只剩一个骨架，要在清单里标成「需重建」而不是「已导出」。第三处是历史结果的用途：如果你留着它只是为了审计，那纯文本导出就够；如果还要复现，那要连当时的输入一起存。