模型更迭如今是一个架构问题

Claude 4 已于 6月退役，5.5 系列在 9月登场，传闻称 Anthropic 还有更多模型在路上。模型半衰期如今以月为单位计算——这让对模型更迭的容忍度成为一项设计要求。

模型更迭如今是一个架构问题

Anthropic 于 6月 15日退役了 Claude Sonnet 4 和 Opus 4。三个月后，它接连发布了 Opus 5.5、Sonnet 5.5 和 Haiku 5.5——还有传闻称另有两款即将推出。OpenAI 和 Google 的周期与此相当。一个具体模型版本的半衰期如今以月计而非以年计，这一事实已悄然成为软件工程中最重要的设计约束之一。

那些把 6月退役当作紧急事件的团队有一个共同特征：模型身份深深织入了应用之中。提示词针对特定世代的行为精调，评估集缺失，未写入文档的怪癖成了承重结构。迁移于是一变而成考古——先重构出系统当初为何能工作，才能证明它现在仍然能工作。

那些几乎无感的团队则把这些选择反了过来。模型选择放在配置里，纳入版本管理、可随时替换。小型评估套件持续跑在真实流量上，因此“新模型对我们还管不管用”只是一份报告，而非一个项目。提示词只依赖已写入文档的行为。迁移成本与暴露面积成正比，而他们的暴露面积很小。

2026年为这门纪律增添了新工具。推理力度调节（GPT-6 的五档）让一个模型覆盖多种使用场景，减少了档位切换带来的更迭。激进的提示词缓存（Opus 5.5 缓存读取每百万 token 0.20 美元）降低了针对大型上下文重新验证的成本。而开放权重阵营——DeepSeek V4、Qwen3.8、GLM-5.3——提供永不退役的锁定版本，代价是自行运维基础设施。

最终的综合解法是路由优先架构：一层把各提供商视为可互换后端的模型调用抽象、一套让换模型变得廉价的评估框架，以及一套“什么任务跑在哪个模型上”的策略。问题已不再是最初该基于哪个模型构建，而是你的系统能多快在下个季度给出不同的答案——因为它不得不如此。