模型发布的速度远超团队评估能力，但多数焦虑其实没必要：对边界清晰的代码库，绝大多数新模型根本不需要改动。决定因素不是你跟得多紧，而是抽象边界划在哪。
剥离营销话术后，新模型与现有版本只可能有四类差异：数字（价格、上下文窗口、限速、延迟、跑分，属于模型数据而非新能力）、标识符（新模型字符串，旧模型可能带日期弃用）、请求或响应面（新参数、新响应字段、新内容类型、新工具调用形态）、行为（同一请求产出不同文本）。前两类几乎都是配置问题，第三类才真正需要写代码，第四类需要评估——那是工作，但不是开发工作，而且最可能悄悄伤到你。
什么完全不用动
新模型上线：模型标识符来自配置或目录而非代码字面量，新模型就是一行数据。价格变动：价格是数据就更新数据，是代码常量就得发版——更糟的是没注意到的价格变动是静默的，账目完美对平但系统性地多收或少收。跑分：基准分数不是关于你工作负载的证据，只是跑一遍评估集的理由。更大的上下文窗口：能发更多不是该发更多的理由，成本随实际发送量线性增长，质量并不单调递增。
什么只需配置
带日期的弃用：工作是选替代品并跑评估集，不是改代码。把日期放在能提醒真人的地方，文档里的日期依赖某人当天恰好重读文档。客户端库新默认值：SDK 升级改了重试次数、超时或默认模型，是伪装成依赖升级的行为变更，要固定版本并专门读变更日志。价格变动跨过路由阈值：按成本路由的话，竞品降价会静默改道你的流量，通常正确但应当可见。
什么需要写代码
你要用的新响应字段：推理 token 统计、分部分用量、缓存命中标记，都要读取、存储和展示。请求里的新内容类型：音频、视频、文档作为一等输入，带来新校验、新大小限制、新存储。你的抽象没有槽位的能力：这是最贵的一类，要么为所有人拓宽接口，要么为某家供应商特判——后者就是抽象腐烂的开端。某些供应商静默忽略而非拒绝的参数：静默接受比拒绝更糟，全额计费的响应返回了，但代码期望的字段缺失。要在自己的边界拒绝不支持的参数。
决定边界的五条原则
模型标识符是数据：模型字符串绝不进应用代码，来自按环境的配置，每个请求记录用了哪个模型，事后能回答"谁服务的这条请求"。价格是带来源的数据：每条价格带来源页面和读取日期，硬编码在计费计算里的价格是最贵的捷径，因为失败是静默且自洽的。每家供应商一个适配器、共享同一形状：应用只说一种方言，适配器负责翻译，新能力只改一个适配器。不支持的参数拒绝而非转发：适配器无法兑现参数必须明说，否则调用方拿到带缺失字段的计费响应且无报错。评估集存在且可指向任何东西：这是回答"新模型对我们是否更好"的唯一机制，没有它每次发布都是观点之争、每次迁移都是赌博。
发布分诊流程
是否弃用你在跑的东西？这是唯一紧急项，把日期记在会提醒的地方。是否改变你计费依据的价格？更新数据，检查是否跨路由阈值。是否新增你会用到的请求或响应字段？不会就停止阅读，大多数公告到此结束。是否有合理的质量或成本收益？跑评估集和差分测试，不是三个提示词的主观感受。其余都是阅读，有趣但不可行动。保持跟进是研究活动，应按研究来预算。
需要警惕的静默情况：模型在稳定标识符下悄悄变化。供应商不提供固定版本的话，记录响应报告的模型字符串并在变化时告警，否则第一个症状是几周后的质量投诉。
正确评估候选模型
少数通过分诊的发布，四个问题决定是否值得切换，只有第一个关乎质量。在你的集上更好吗？用你自己的标注样本、和上次相同的评分方式，公共基准更好但你的抽取 schema 更差就是更差，评分方法必须跨比较固定。每单位工作的成本？不是每 token 成本，便宜 30% 但同任务多输出 40% 的模型更贵，模型间啰嗦程度差异经常这么大，要在同一集上算每完成任务的成本。你的百分位延迟成本？中位延迟很少决定什么，p95 决定用户功能是否还跟手，推理模型尤其把尾部拉得远比中位数远。哪些非质量问题会破坏？输出格式、拒绝阈值、工具调用倾向、提示词措辞是否还生效。切换要按斜坡推进、旧路由保持热备，而不是一刀切切换，回滚应是路由变更而非发版。
同时值得做且别拖的一件事：记录每个请求由哪个模型服务。没有它，斜坡三周后的质量问题没有答案，因为数据里区分不了两个群体。
@DevToolboxHub