模型清单多久变一次：每月一次的核对例行

为什么是月度，而不是每天

模型清单是缓慢变化的资源。新模型上架、旧模型下线、别名调整、上下文长度或能力标注更新，这些改动通常以周甚至月为周期发生。每天刷新文档，绝大多数时候看到的是同一份内容，反而容易让人对「变化」脱敏。

把核对周期拉长到一个自然月，好处有三个：

• 单次核对有足够多的样本，diff 结果里出现有意义的条目，而不是噪声。
• 你只需要记住一个固定动作，不需要额外的工作流工具。
• 上游如果有变更公告或迁移提示，一个月的时间窗足够你从容调整代码，而不是被临时通知追着跑。

关键不是频率本身，而是「可重复」。只要例行是稳定的，你就不会因为漏看某次更新而在生产里踩空。

存档要保存什么

存档不是把文档页整页复制下来，而是抽取你真正关心的字段。建议至少包含：

• 模型标识：调用时实际填进 model 参数的那串 ID。
• 展示名：方便人眼识别。
• 供应商或系列归属（例如来自哪一家）。
• 你标记的用途：日常对话、长上下文、代码、便宜批量任务等。
• 首次在你存档中出现的日期。

最后一项很容易被忽略，但它是月度 diff 里最有价值的一列——它能告诉你某个模型是「一直都在」还是「这个月刚出现」。

存档格式用纯文本即可：一行一个模型，字段用固定分隔符。这样 diff 工具能直接对齐行，而不是把整段 JSON 当成一个巨大的改动块。

一次月度 diff 的流程

1. 打开聚合站的模型清单页面（或你使用的列表接口），导出当前全部模型标识。
2. 与上月存档做一次行级 diff。
3. 把结果分成三类：新增、删除、修改。
4. 只对新增和修改做进一步处理，删除项检查一下自己是否还在用。
5. 更新存档，写好本次核对日期。

这三类变化的含义并不一样：

• 新增：通常是好消息，意味着你的 API key 能触达的能力变多了。值得花几分钟看看它适合放进哪个已有工作流。
• 删除或改名：风险最高。如果某个模型仍出现在你的代码、配置文件或提示词模板里，本期就要处理。别名变动尤其容易漏，因为它不会报错，只会悄悄指向另一个模型。
• 修改：能力描述、上下文长度、供应商归属的调整。这类变化不一定会影响调用，但会影响你的选型判断。

用同一把 key 验证新增项

聚合站的价值在于一个 API key 可以调多个模型，所以验证新增模型不需要额外开账号、额外配密钥。一次最小验证通常包含：

• 用新模型标识发一次最简单的请求，确认能通。
• 对比同一提示词在旧模型上的输出，判断风格差异是否符合预期。
• 如果该模型打算进入生产路径，再补一次边界场景，例如长输入或结构化输出。

验证通过后，把模型写进你的用途清单，而不是只把标识抄进存档。存档记录「有什么」，用途清单记录「什么时候用它」，两者分开维护会清晰很多。

把例行固化成几个约定

月度核对最容易失败的地方不是技术，而是遗忘。几个简单约定能显著提高存活率：

• 固定日期：例如每月第一天，或每月的第一个工作日。
• 固定位置：存档放在项目仓库里，跟着代码一起被 review。
• 固定产出：每次核对结束时，存档里多一行日期，diff 里多一段说明。
• 不追求全量：如果某个月没有新增和删除，只有少量修改，这也是一次成功的核对，不需要为了「有内容」而制造工作。

与计费和额度无关的部分

核对清单只关心「有哪些模型可用」，不涉及具体扣费比例、返利或限额。这类信息变化频率和模型清单并不一致，混在同一个例行里会互相干扰。

建议把两件事拆开：模型清单按月核对，计费相关规则在有明确变更提示时单独关注。这样每次维护的目标单一，diff 结果也更容易读懂。

什么时候该打破月度节奏

月度是默认节奏，不是硬性规定。出现以下情况时，可以临时插入一次核对：

• 你的代码里出现调用失败，且错误与模型标识相关。
• 你准备把一个新模型接入生产，需要确认它的可用性和稳定性。
• 你注意到上游有较明显的变更提示，想确认影响范围。

其余时间，按月度推进即可。把注意力留给真正需要判断的选型和集成，而不是反复刷新一份大概率没变的清单。