GitHub 在 2026 年 10 月 2 日退役了四个 Copilot 模型，覆盖 Chat、内联编辑、ask 与 agent 模式以及代码补全在内的全部 Copilot 体验：Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7。GitHub 对每个模型都给了官方建议替代，并说明退役模型本身无需手动移除，但 Copilot Enterprise 管理员可能需要按模型策略去启用替代模型。
这次退役值得单独写一篇，不是因为多了四个不能用的模型，而是因为它暴露了一条团队经常忽略的链条：模型会被移除，而移除之后你的组织里可能没有任何一个替代模型是被启用的，选择器里会直接空掉。
发生了什么：四个模型同日退役，替代清单已给出
按 GitHub 公布的对照，Gemini 3.5 Flash 和 Gemini 3.6 Flash 都指向 Gemini 3.8 Flash；Kimi K2.7 Code 指向 Kimi K3；Claude Opus 4.7 指向 Claude Opus 5.5。四个模型的退役日期都写的是 2026-10-02，也就是公告当日生效，没有给过渡期。
覆盖范围写得很宽：Chat、内联编辑、ask 模式、agent 模式，以及代码补全。这一点和很多人对"模型退役只影响聊天"的直觉不同——如果团队的补全或内联编辑固定选过某个被退役的模型，这些入口同样会受影响。
GitHub 同时给了两条操作性说明。一条是"无需任何操作即可移除已退役模型"，也就是说退役本身不需要团队做清理。另一条是关于替代模型的：Copilot Enterprise 管理员可能需要通过 Copilot 设置里的模型策略，启用替代模型的访问权限；确认方式是在个人 Copilot 设置里查看该模型的策略状态，启用之后它才会出现在 VS Code 和 github.com 的 Copilot Chat 模型选择器里。遇到问题的企业客户，GitHub 建议联系客户经理。
一个真实会踩的场景
假设一个团队做企业级 Java 服务，代码库很长，历史包袱重。半年前团队做过一次模型评测，结论是 Claude Opus 4.7 在跨文件重构上更稳，于是把它写进了内部开发规范，还在几套自动化脚本和 IDE 配置里固定了这个模型。
10 月 2 日之后，这个固定值失效了。更麻烦的是两个层面的问题叠在一起：一是规范里的模型名要改；二是即便规范改成了 Claude Opus 5.5，如果企业管理员没有在模型策略里启用它，成员在自己的 Copilot 设置里看不到这个模型，选择器里就是没有这一项，而"看不到"和"没有权限"在界面上不容易区分。
于是排查顺序很重要：先确认管理员是否按策略启用了替代模型，再确认成员个人设置里的策略状态，最后才去改脚本和规范里的模型名。如果顺序颠倒过来，团队会花时间改一堆配置，却发现模型根本还没被放出来。
另一个容易漏的地方是补全。团队通常只在 Chat 里认真选过模型，补全往往是"默认就行"。但这次退役范围明确包含代码补全，如果默认补全模型恰好落在退役名单上，行为会变，而成员可能只觉得"今天补全的味不对"，不会联想到模型退役。
为什么模型退役是工作流问题，而不是版本号问题
第一层是模型引用的硬编码。只要模型名被写进规范文档、脚本、IDE 配置或 CI 环境变量，它就从"临时选择"变成了"基础设施"。基础设施被上游移除，团队就必须走一次变更流程，而不是换一个下拉框。
第二层是策略与可见性的分离。企业里"模型能不能用"由管理员的策略决定，"我用不用它"由成员的选择决定，两者之间还夹着一次启用动作。这三步任何一步没走通，表现都是"选择器里没有这个模型"，很难定位。所以企业需要一份写清楚的清单：谁负责在退役公告后启用替代模型，谁负责更新内部规范。
第三层是评测结论的过期。团队半年前的选型结论是针对当时那一批模型的。当两个 Gemini Flash 一起被 3.8 Flash 取代、Kimi K2.7 Code 换成 K3、Opus 4.7 换成 Opus 5.5，原来的评测结论已经不再对应任何可用的模型。想继续沿用"我们用 X 是因为实测更好"这个说法，需要重新测；不重测也完全可以，但要明确它是默认而非结论。
限制、边界与人该在哪里接管
这条公告的边界首先在于它没有替代迁移路径。四个模型同日生效退役，没有缓冲期，也没有给出"老配置会自动映射到新模型"的说法。因此人手上有多少处硬编码的模型名，就有多少处需要人工核对——这件事工具帮不了。
其次，公告没有逐项列出每个模型在各 Copilot 体验里的确切影响面。它说的是覆盖全部体验，但"某仓库的代码补全默认模型是不是 Gemini 3.5 Flash"这种问题，答案在组织自己的设置里，不在公告里。
第三，涉及权限的动作落在管理员身上，开发者个人无法自行解决。也就是说这次退役的收尾工作，责任人是企业管理员和平台团队，而不是每个开发者。
人该接管的点很明确：管理员负责按策略启用替代模型，并确认它们真的出现在选择器里；平台或规范维护者负责把规范、脚本、IDE 配置里的模型引用改到替代模型；使用方则在补全和内联编辑这类低注意力入口上做一次抽查，确认行为没有悄悄改变。GitHub 的公告只负责告诉你哪些模型没了，后面这段路要自己走。
如何核对和操作
如果你是成员，先去 Copilot 设置里查看当前可用模型列表，确认替代模型是否已经出现；如果没出现而你需要它，联系管理员按策略启用。
如果你是 Copilot Enterprise 管理员，去 Copilot 设置的模型策略里，把本次涉及的替代模型（Gemini 3.8 Flash、Kimi K3、Claude Opus 5.5）逐项确认启用状态，启用后到 VS Code 和 github.com 的 Copilot Chat 模型选择器里验证一遍。
如果你是平台或规范维护者，检索内部文档、脚本与环境变量里对 Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7 这四个名字的引用，逐处替换为替代模型，并在替换后重新确认补全与内联编辑的行为。这次退役生效日期是 2026 年 10 月 2 日，没有过渡期，早做早省事。
信息来源
- GitHub Changelog：Selected models in GitHub Copilot deprecated，2026-10-02 — https://github.blog/changelog/2026-10-02-selected-models-in-github-copilot-deprecated
- GitHub Docs：Supported models in GitHub Copilot（各体验的可用模型以官方文档为准）
本文事实来自上述 GitHub 官方 changelog；配图为按官方公布内容编辑绘制的对照表，未添加公告之外的信息。
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
