Copilot 的模型下个月就停，你写死在配置里了吗

AI TOOL · 配置审计 ｜ 2026-10-02 两个模型退役窗口，相隔 17 天 · 10 个模型已停或待停 · 回去查一遍只要 5 分钟 据 GitHub 官方 changelog，2026-09-18 公告

PART 01 · THE DEADLINE · 两份名单

你 Copilot 里选的那个模型，可能下个月就没了。

不是吓你。GitHub 在 9 月 18 日发了一条 changelog，标题很平淡——「Upcoming deprecation of selected GitHub Copilot models in mid-October」。内容不平淡：10 月 19 日，6 个模型在全部 Copilot 体验里停掉，包括 Copilot Chat、inline edits、ask mode、agent mode，还有代码补全。

名单我对着原文抄了一遍，别信二手翻译：

但这只是第二批。第一批早在 9 月 3 日就公告了，10 月 2 日——也就是今天——已经停掉 4 个：Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7。

两周之内退掉 10 个模型，两个窗口相隔 17 天。GitHub 自己在公告里写的是「suggested alternatives」——建议替代，不是等价替换。这一点被几乎所有二手报道吞掉了。

PART 02 · THE TRAP · 为什么"建议替换"这四个字很危险

如果你只是在 Copilot 的下拉菜单里选模型，你什么也不用做——菜单会跟着变，旧名字消失，新名字出现。

但如果你把模型名写进了任何地方，你就有麻烦了。

哪些地方会"写死"模型名，我列了个单子，你照着扫一遍：

1. Copilot settings 里的 model policy，尤其是 Business 和 Enterprise 的管理员策略
2. 组织级配置里显式关闭 global default 后手动 enable 的模型名
3. 内部 agent 定义、共享配置文件、saved prompt
4. 调用 Copilot 集成的脚本和工作流文件
5. 扩展代码里硬编码的 model 字段

GitHub 的原话是「update your workflows and integrations before the date」。它没说的是：真正会炸的不是你选了哪个模型，而是你把那个选择写下来然后忘了。

这就是为什么我说这条新闻值得你花 5 分钟。它不是"又出新功能"的 PR 稿，是运维级别的依赖变更。你的 CI 流水线、你的 agent 编排、你团队里那个去年配好再也没人碰过的配置文件——这些地方埋着定时炸弹。

而且别以为换个名字就完事。GPT-5.5 换成 GPT-5.6 Sol，GPT-5 mini 换成 GPT-5.6 Luna——Sol 和 Luna 的定价、上下文、工具选择风格、patch 写法，跟被换掉的那两个不是一回事。GitHub 明确说了这不是 behavior-equivalent replacement。你以为是平滑升级，实际是静默换芯。

PART 03 · THE FIX · 5 分钟自查清单

不用搞大动作，按下面三步走：

第一步：找到所有写死模型名的地方。 在组织设置里搜 model policy，在代码仓库里 grep 模型名（GPT-5.5、Gemini 3.7 Flash、Grok 4.5 这类关键词），在 CI 配置里查 Copilot 相关的 model 字段。

第二步：对照两份名单打勾。 10 月 2 日那批已经停了，如果你的配置里还有 Gemini 3.5/3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7，它们现在就已经在报错，只是你可能没看到——因为 agent 跑在后台。

第三步：换成替代模型后跑一轮回归。 别只改配置就跑。挑 3-5 个你们团队日常用的任务，跑一遍新旧模型的输出对比，看 patch 风格、token 消耗、工具调用有没有漂移。这是 GitHub 没提但你必须做的事。

CASE 1｜一家 20 人团队的 Copilot 模型迁移

需求：20 人的工程团队，去年统一把 Copilot Business 的默认模型设成了 GPT-5.5，配置写在组织级 policy 里，没人记得改过；10 月 19 日到期，需要在不阻断日常开发的前提下完成迁移。

方案：1. 管理员登录 Copilot settings，确认 global default 状态，在 model policy 里把 GPT-5.5 替换为 GPT-5.6 Sol。2. 用 grep 扫全仓库，找出所有脚本和 workflow 里硬编码的 model: gpt-5.5，逐一替换。3. 选 5 个典型 PR 做 A/B：同一份 diff 分别用 GPT-5.5（迁移前）和 GPT-5.6 Sol 跑 review，对比发现数量和误报率。4. 给团队发一条变更通知，附替代模型名单和回退路径。

输出：更新后的组织级 model policy 一份；硬编码位置清单与替换记录；5 个 PR 的 review 差异对比表；团队通知邮件。

PART 04 · THE BIGGER PICTURE · 模型退役不是新闻，是常态

真正让我写这篇的不是 Copilot 本身，而是它暴露的一件事：

AI 编程工具的模型选择，已经变成一种需要维护的依赖。

以前你换一个 linter 版本，至少有个 changelog 告诉你 breaking change 在哪里。现在你选了一个模型，它可能在两周后突然从菜单里消失，而你的自动化流程还在用旧名字调用——然后静默降级到一个你根本没测过的替代品。

这不是 Copilot 一家的问题。Cursor 9 月 10 日上了 Projects，协调器不写代码，调度几千个子 Agent 并行；GitHub 同一天上了 HydraFusion，让 CLI 自动在本地、云端和复合模型之间路由。方向很清楚了：模型本身正在变成基础设施，而不是功能。

基础设施就得按基础设施的规矩来：有版本、有回退、有监控、有退役通知的接收人。

所以别把这条当成"哦知道了"就滑过去。回去查一遍你的配置，5 分钟的事。查完你会发现，你忘的东西比你想的多。

SUMMARY · 一句话结论

模型退役不是产品新闻，是运维事件——你的配置里写死了哪个模型，决定了它是平滑升级还是无声炸掉。

适合场景

• 团队在用 Copilot Business / Enterprise，且配置过 model policy
• 有自动化流程通过 API 或集成调用 Copilot
• 想知道自己团队对模型选择的"技术债务"埋在哪

参考资源

• GitHub 官方公告：github.blog/changelog/2026-09-18-upcoming-deprecation-of-selected-github-copilot-models-in-mid-october
• GitHub 9 月 10 日周更（HydraFusion + Sentry 画布 + Jira 集成）：github.blog/changelog/2026-09-10-github-copilot-weekly-releases-september-7
• Cursor Projects 官方 changelog：cursor.com/changelog（2026-09-10）

以上事实均来自 GitHub 官方 changelog 及公开报道，未做额外推测。模型退役日期与替代关系以 GitHub 公告为准。