GitHub Copilot 将弃用 MAI-Code-1-Flash：代码工作流如何完成模型切换

团队里只要有人把 Copilot 模型写进编辑器设置、脚本或内部操作手册，9 月上旬就该安排一次核对。GitHub 已确认：MAI-Code-1-Flash 将在 2026 年 9 月 10 日从全部 GitHub Copilot 使用场景中停用，官方建议改用 MAI-Code-1.1-Flash。真正容易漏掉的不是模型选择器，而是企业策略、共享配置和仍在沿用旧名称的集成。

9 月 10 日前要处理的不是“删除旧模型”

GitHub 的停用公告给出的日期是 2026 年 9 月 10 日，替代项是 MAI-Code-1.1-Flash。旧模型停用后无需管理员手工删除；迁移工作的重点，是在日期到来前让新模型可选，并把团队实际使用的入口改过去。

先列清入口比立即改配置更稳。个人开发者通常要看编辑器和 github.com；团队还可能使用 Copilot CLI、Copilot cloud agent、GitHub Copilot app、Visual Studio、JetBrains IDE、Xcode 或移动端。只在 VS Code 里点一次模型，并不能证明其他工作流已经摆脱旧名称。

先确认 MAI-Code-1.1-Flash 已对团队开放

企业与组织环境多一道权限门槛。GitHub 的发布说明指出，Copilot Business 和 Copilot Enterprise 管理员需要在 Copilot 设置里启用 MAI-Code-1.1-Flash 策略，而且该策略默认关闭。成员看不到新模型时，先找管理员核对策略，不要反复重装编辑器扩展。

管理员启用后，可用个人 Copilot 设置确认该模型策略处于允许状态；成员侧则在 Copilot Chat 的模型选择器里检查名称。建议至少核对一个编辑器入口和 github.com 入口。如果团队使用多个 IDE，再抽查一台常用开发机，避免策略已开但客户端或扩展版本仍旧。

把模型切换拆成三张核对表

第一张是“入口表”：记录团队实际使用的 VS Code、Visual Studio、JetBrains、CLI、github.com 或 Copilot app。第二张是“配置表”：搜索共享设置、项目模板、内部文档和自动化脚本中是否仍有 MAI-Code-1-Flash。第三张是“验证表”：选三类日常任务，例如补全一段业务代码、解释一个跨文件调用、根据仓库上下文修改小范围代码，确认新模型可以被选择并正常返回。

验证不必做成模型排行榜。此次迁移的目标是消除停用风险，而不是证明新模型在所有任务上都更强。团队可以保留旧模型下的几个典型结果作为人工对照，但不要因为措辞不同就直接判定失败。更值得记录的是：模型是否可选、请求是否成功、工具调用是否正常、权限是否一致，以及成员是否还能从旧文档复制出失效配置。

迁移后还要留一个回看节点

完成切换后，把 9 月 10 日设为回看节点。当天检查共享配置仓库、入职文档和常用 IDE 的默认选择；如果旧名称已经不可用，但成员仍能从某个脚本或模板里读到它，就把那处当作文档债处理。GitHub 已说明旧模型停用后不需要额外移除，因此不要设计没有必要的“清理模型”操作。

对于 Copilot Enterprise，若策略已启用但成员仍看不到替代模型，可先收集组织、IDE、扩展版本和可见模型列表，再联系 GitHub 客户经理或支持渠道。这样比只报一句“模型不见了”更容易定位到策略、客户端还是账号范围。

常见问题

个人 Copilot 用户也要手工切换吗？

如果当前工作流明确选择了 MAI-Code-1-Flash，就应在停用日前改为 MAI-Code-1.1-Flash 或其他仍受支持的模型。使用自动选择的用户也应确认常用入口没有固定旧名称。

旧模型停用后还需要管理员删除策略吗？

不需要。GitHub 的公告明确表示旧模型停用后无需执行移除操作；管理员更该关注替代模型策略是否启用，以及成员能否在实际入口看到并使用它。

总结：这次切换可以按“管理员开策略、成员改入口、团队查配置、日常任务验证”四件事收尾。把这些动作放在 9 月 10 日之前做完，才能避免模型正式停用后才发现某条 Copilot 工作流仍绑着旧名称。