Copilot 一天退役六款模型，谁为你的提示词资产兜底

10 月 19 日，GitHub 官方 changelog 更新了一条：Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5，六款模型当天从 Copilot 的全部使用场景里退役，Chat、行内编辑、agent 模式、代码补全都算。这个决定 9 月 18 日就预告过，真落到自己头上，仍是另一回事。

退役的不只是几个名字

受影响的不只是模型选择器少几行。围绕老模型调的提示词、自定义指令、内部工具链，都绑在特定模型的脾气上：同一个提示词，GPT-5.5 给出的结构和 GPT-6.1 不一样，输出格式变了，下游解析就断。名字是换走了，行为差异跟着你来。

GitHub 的指引里还有一条容易漏：企业版管理员要在模型策略里手动启用替代型号，不点那个开关，团队的选择器里就不出现。配置文件和 CI 流水线里写死老模型名的，退役之后要么静默回退到默认，要么直接报错，报错还算好的，静默回退更麻烦，你甚至不知道现在跑的是哪一款。

输出格式的漂移是另一种隐形损失。让模型输出固定结构的 JSON，老模型配合默契，新模型偶尔多一句解释、偶尔换个字段顺序，下游解析从「稳定失败」变成「偶尔失败」，这种问题最难排，因为它不报错。

平台轮换组件是它的成本纪律，这笔账落到用户这边，就成了重调、重测、重审。

有个细节能看出轮换的节奏感：这次退役 9 月 18 日就写进了公告，留了一个月的缓冲。对个人用户，一个月换个下拉框绰绰有余；对把模型行为写进流程的团队，一个月要重放全部提示词用例、重跑回归、重审输出格式，紧得很。缓冲期的长短不取决于你迁移要多久，取决于平台下次什么时候想换。

清单攥在谁手里

模型清单攥在平台手里，换哪款、什么时候换，平台说了算。企业用户有自动迁移兜底，个人订阅和自定义集成没有，得自己动手。

这不是 Copilot 一家的问题。把「选模型」当成产品核心卖点的路线，都要面对同一个结构：能力挂在模型上，模型轮换，能力就得跟着搬家。模型厂商淘汰旧版本是行业常态，但平台把六款模型放在同一个界面里卖，一次 changelog 就能给一大批用户的默认体验洗牌，速度是别处没有的。用户的提示词写得越好、调得越细，锁进特定模型的部分就越多，轮换时摔得越疼。

清单之外那一层

模型这一层，飞算 JavaAI 分两路。一路是自有档位：极速、深度、专家、基础，在 Java 领域表现优异的开源大模型上调优封装，按任务分工，日常开发和重构走极速，架构和核心功能走深度，不指定时由智能路由挑。另一路直连第三方，智谱的 GLM-5.2、5.3，DeepSeek-V4 的几个版本都在。这些名字你在别的工具里多半已经用过，信得过的还是那几个，不用因为换工具重新赌一次。

比清单更要紧的是清单之外。需求分析、接口和表结构设计、业务逻辑、生成工程代码，这条链上的产物落在项目里：接口长什么样、表有哪些字段，是仓库里的文档，换个人打开仓库也看得见。能力的一半挂在模型上，另一半挂在工程上；模型会轮换，工程不跟着搬。

换个角度算这笔账。提示词、自定义指令、策略配置，这些资产绑定在模型行为上，模型一换就得重验；文档、表结构、接口定义，这些绑定在工程上，模型换十轮它们原地不动。把资产的大头放在哪一边，退役名单公布那天的心情就不一样。

给团队的三个动作

用 Copilot 的团队有三件事现在就能做。把提示词里绑死某个模型行为的部分，改成描述任务本身，任务描述不随模型变质；CI 里写死的模型名挪进配置统一管理，退役名单公布时改一处就行；管理员盯紧 changelog，别让团队的选择器悄悄空掉。三件事的共同点是都往「不依赖具体模型」的方向挪。

还有一条容易被忽略：把「模型行为依赖」列进技术债。评审提示词改动时多问一句，这段是不是只在当前模型上成立，换个模型还成立吗。问过这句话的团队，轮换日的动作会快很多。

这套动作换到任何工具上都成立。飞算 JavaAI 的用户同样受益于这条原则：工程产物在仓库里，模型档位怎么调，都不动它。真正要守住的不是某一版模型的表现，是模型之外那些不会过期的东西：需求文档、接口定义、表结构，还有团队在评审里立下的规矩。

也要说句公道话照顾另一头：个人用户拿 Copilot 写写脚本、改改样例，退役那天换个模型接着用，影响确实有限。受冲击最重的是中间那批团队，用量不小、定制不深不浅，提示词调过、策略配过，但没到有专人维护的程度。这批人最容易在退役名单公布之后才发现自己榜上有名。

押注别全押在模型名上。你现在用的模型，撑得过下一轮退役名单吗？