GitHub官方下架4款模型，管理员得连夜改配置

GitHub 官方在 10 月 2 日发了个更新公告，直接把 Copilot 里的 4 款老模型给下架了。这动作太快，连个过渡期都没给，企业管理员估计得连夜去后台改配置。

它把推理延迟和上下文窗口都推向了新一代标准。你下半年用 agent 跑长任务，等待感会明显变短，但前提是你的企业后台配置没掉链子。这波强制换代，表面上是技术升级，暗地里是平台对开发者工作流的绝对控制。

讲真，这次 GitHub 下手挺狠的。10 月 2 日直接发了个公告，一口气把 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。这次弃用涵盖了 Copilot Chat、inline edits、ask and agent modes 还有 code completions 所有场景。官方给的建议很直接，让大家赶紧更新工作流。如果是 Copilot Enterprise 的管理员，得去 Copilot settings 里改 model policies。这种一刀切的玩法，其实反映了现在大模型迭代的残酷性。旧模型哪怕昨天还在用，今天官方说砍就砍，根本不管你业务跑没跑通。开发者习惯了某个模型的脾气，刚写出顺手的感觉，官方直接给你拔网线。你想啊，前端刚适应了新框架，后端的代码补全逻辑又变了，这中间的切换成本全让一线员工自己消化了。官方文档里那句“Please update your workflows”，轻飘飘几个字，背后是无数个熬夜改 prompt 的打工人。

从产品经理和运营的角度看，这其实是在逼大家用新模型。新模型在成本、速度或者特定任务上肯定有优势，官方通过弃用旧模型，强行把流量转移到新模型上。对于企业来说，这不仅仅是换个名字的事。管理员需要去验证可用性，确认 policy 是 enabled 的。这直接让企业的 IT 部门得承担额外的沟通成本。如果管理员没看到公告，第二天开发团队就会在群里炸锅，说代码补全突然变笨了。

面对这种强制换代，企业该怎么评估新模型？不能只看官方 suggested alternative，得自己跑一遍核心业务的测试。比如 Kimi K3 在代码补全上的表现，是不是真的比 K2.7 Code 好？Claude Opus 5.5 在复杂 agent 任务里的成功率有没有提升？你得建立一个内部的评测小流程，拿真实的业务代码去跑，看看新模型在你们的特定场景下到底行不行。别官方说换就闭着眼睛换，最后出了 bug 还是得自己背锅。企业得算一笔账，新模型省下的 token 钱，能不能覆盖掉员工重新适应新模型的时间成本。如果新模型只是跑分好看，实际写业务代码经常幻觉，那这波强制升级就是纯纯的折腾。

对于 HR 和猎头来说，这事传递了一个信号：企业对 AI 工具链管理的能力要求变高了。以前只要会买账号就行，现在得有个懂模型策略的管理员。对于运营和产品经理，如果你的产品深度依赖 Copilot 的企业版，必须建立模型变更监控机制。

这里给大家列个排查清单。第一步，立刻让 IT 管理员登录 github.com 检查 Copilot settings。第二步，确认新模型的 policy 已经 enabled。第三步，在 VS Code 里打开 Copilot Chat 模型选择器，验证新模型是否可见。第四步，跑几个核心的 inline edits 任务，对比新旧模型的输出质量。有企业版账号遇到问题，可以直接找 account manager。更多模型细节可以去官方文档看：

Supported models in Copilot
GitHub Community Discussions

千万别等开发群里骂声一片了，才想起来去后台看一眼配置。

这事给所有用第三方 AI 工具的团队敲了个警钟。你把核心工作流绑在别人的平台上，就得接受人家随时改规则的代价。今天能弃用 4 款模型，明天就能改计费规则或者调整 API 限流。产品经理在做技术选型时，必须把“模型不可用”作为最高优先级的风险写进预案里。别把鸡蛋全放在 Copilot 这一个篮子里，本地部署一套开源模型做兜底，或者同时接入两三个不同平台的 API，才是长期活下去的稳妥做法。

看完想聊两句？
你主力用哪个模型？Copilot 强推的 Claude Opus 5.5 和 Kimi K3 你更看好谁？