GitHub Copilot 四款模型将下线：迁移不只是在下拉菜单里换个模型

GitHub 已宣布，计划于 2026 年 10 月 2 日从 Copilot 中移除 Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code 和 Claude Opus 4.7。距离切换尚有时间，但影响范围不只聊天窗口。GitHub 的通知明确提到聊天、行内编辑、询问模式、代理模式和代码补全，并要求用户在截止日前更新相关工作流与集成。

因此，盘点的重点并不是找出谁偶尔手动选过旧模型，而是查明哪些流程默认某款模型会长期可用。个人开发者可能在编辑器中固定选择了某款模型；团队也可能在提示模板、自动化代理、命令行脚本或内部操作手册里默认它始终存在。企业环境还涉及管理策略：替代模型即使已经上线，也未必已向实际使用者开放。

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。不过，官方建议的迁移方向并不意味着新旧模型在答案质量、响应速度、行为特点或成本上完全相同。稳妥的做法不是批量改完模型名称便宣告结束，而是把这次下线当作一次需要验证的依赖升级。

先查清三种依赖

迁移清单至少应覆盖三类情况。第一类是明确指定：用户、脚本或工作流直接固定了即将下线的模型。第二类是默认设置：新对话看似没有指定模型，实际采用的是企业、组织或产品层面设定的默认值。第三类是不易察觉的依赖：操作说明只写着“使用 Copilot 生成测试”，后续流程却一直依赖某款模型惯常的输出长度、工具调用方式或响应速度。

管理者不能只检查后台策略，还要查看实际用户界面中的模型选择器。Copilot Business 和 Enterprise 的模型设置可能由企业所有者统一指定，也可能交由组织管理，或沿用默认可用性设置。Kimi K3 尤其需要留意：它属于开放权重模型，在 Business 和 Enterprise 中默认关闭，不会因为一般的默认可用性规则而自动开放；在没有其他限制的情况下，管理员仍需明确允许使用。

模型被标为正式可用，也不代表所有套餐、客户端和功能入口都能立即使用。GitHub 的实时文档说明，可用范围取决于方案和客户端，而且可能变化；使用新模型还可能需要更新 IDE 或扩展。目前的最低版本表本身也标为暂定，其中 Gemini 3.8 Flash 的部分数据仍待确认，Kimi K3 列出的 VS Code 版本为 1.131，Claude Opus 5 则为 1.128.0。团队需要同时核对管理策略、客户端版本以及最终用户真正能看到的选项，不能只看支持模型总表。

用真实任务回放，不凭名称判断

迁移时常见的误区，是拿几条临时提示词比较回答是否“显得聪明”。更可靠的办法，是从近期工作中选取一小组已经完成、结果可以核验的任务，分别交给旧模型和候选模型重跑。样本应覆盖团队真正依赖的场景，例如解释陌生代码、修改跨文件逻辑、补充测试、定位缺陷，以及在代理模式下调用工具。

比较前应先约定标准。首先检查正确性：修改能否通过现有测试，是否遗漏边界条件，是否引入无关改动。其次记录完成任务需要多少人工审阅和返工，而不只评价第一份回答。响应时间也值得记录，但要区分“更快给出第一句”与“更快完成整个任务”。对于会消耗 AI 点数的功能，还应观察同类任务的实际额度消耗。GitHub 的产品文档指出，各模型在延迟、产生不实内容的倾向和任务适配度上存在差异。这只是选型提示，不是独立的基准测试，更不能取代团队在自己的代码库中验证。

这轮回放不必做成庞大的排行榜。目标是尽早发现足以阻碍迁移的问题，并针对不同任务选择合适的去向。假如 Gemini 3.8 Flash 在快速问答中表现稳定，却在某个自动化流程里改变了输出结构，团队可以分别处理这两类场景，而不必强迫所有入口采用同一种配置。在取得实际测试结果之前，也不能把官方建议的后继模型写成已经证实的等价替代品。

价格只能辅助评估，不能直接推算最终账单

截至 9 月 6 日，GitHub 价格页列出的每 100 万个令牌费率为：Gemini 3.5 Flash 的输入、缓存输入和输出价格分别是 1.50、0.15 和 9 美元；Gemini 3.6 Flash 与 Gemini 3.8 Flash 均为 0.75、0.075 和 3.75 美元。Kimi K2.7 的三项价格为 0.95、0.19 和 4 美元，Kimi K3 则为 3、0.30 和 15 美元。Claude Opus 4.7 与 Claude Opus 5 的输入、缓存输入、缓存写入和输出价格相同，分别为 5、0.50、6.25 和 25 美元。

这些数字适合用来发现明显的费率变化，却不能直接变成迁移后的账单预测。最终开支还取决于输入与输出令牌数量、缓存命中情况、所用功能和订阅方案。两款模型费率相同，也不能证明它们完成同一任务时消耗相同，更不能证明每个被接受结果的成本一致。价格页会更新，正式切换前还应再次核对。

GitHub 将一个 AI 点数计为 0.01 美元，但代码补全和 next edit suggestions 不消耗 AI 点数。团队评估费用时应先区分功能入口，再用实际任务记录用量；否则，把令牌单价、点数和订阅权益混在一起，很容易得出失真的结论。

分批切换，并保留可执行的回退办法

完成盘点和任务回放后，可以先选择影响较小的一组用户或工作流试运行。每次切换都应留下明确记录：改了哪项设置、影响哪些入口、由谁观察结果、出现什么情况需要暂停。回退方案也要能立即执行，例如恢复仍可用的旧配置，或切换到另一款已验证的候选模型，而不是只在文档里写一句“必要时回滚”。

在 10 月 2 日前，旧模型仍可用于对照，但回退窗口会随着下线到来而关闭。因此，团队还需要为截止日之后准备替代路径。官方通知指出，模型下线后无需用户手动删除旧模型；真正要提前处理的是依赖旧模型的工作流、集成和配置。若把“旧选项会消失”误当成完整迁移计划，截止日后才会发现哪些自动化环节没有后路。

Auto 可以列入候选方案，但不能未经验证就当作固定模型的原样替代。GitHub 会依据可用性、系统状态和任务复杂度选择模型，同时仍受方案与管理策略约束；可选模型集合也会变化。在支持的界面中，用户可以查看实际使用的模型。团队若考虑采用 Auto，应像测试其他候选方案一样回放真实任务，并确认审计或故障排查时能否取得所需记录。

默认模型、用户明确选择的模型和 Auto 是三种不同的依赖。自 9 月 2 日起，企业托管设置可为新对话指定任何可用模型作为默认值，也可以按企业团队覆盖该默认值；GitHub 宣布该功能已面向 Business 和 Enterprise 的 Copilot app、CLI 与 VS Code 正式提供。这个范围不能自行外推到通知没有列出的其他界面。管理员既要检查企业和团队层级的设置，也要确认用户端最终呈现的结果。

截止日前应得到什么结果

一份可执行的迁移结果，不是“所有人都选了新模型”这样一句笼统结论，而应包括：旧模型依赖清单；替代模型的权限与客户端条件；基于真实任务的验证记录；按场景确定的切换安排；明确的负责人、观察指标和回退步骤。对于尚未验证的入口，应如实标注风险，不能用官方建议替代内部测试。

这四款模型的下线日期给团队留下了准备时间。最值得利用这段时间做的，并非在下拉菜单里匆忙换一个名称，而是找出隐藏依赖、验证真实效果，并把切换和回退都落实到具体流程。这样，10 月 2 日到来时，变化才会是一场受控迁移，而不是一次临时救火。

把验证结果写成可复用的记录

为了让试运行结果能够支持决策，每个样本任务都应保留相同的基本信息：任务目标、使用入口、模型选择方式、客户端版本、管理策略、测试结果、人工修改次数和完成时间。如果任务涉及 AI 点数，再单独记录实际消耗。这样既能比较候选模型，也能在结果异常时判断问题来自模型、客户端更新，还是权限设置。

记录还应说明哪些结论只适用于特定场景。例如，一款模型适合解释代码，不代表它也适合跨文件修改；在 VS Code 中可用，也不代表其他客户端已经具备相同条件。若某项最低版本仍待确认，应把它列为待核实事项，而不是自行补上数字。对尚未开放 Kimi K3 的企业用户，也应先解决策略权限，再评价模型表现，否则测试失败反映的只是配置问题。

切换后的观察期同样重要。团队可以继续跟踪测试通过率、无关改动、人工返工、任务总耗时和实际用量，并与试运行记录对照。一旦触发预先约定的暂停条件，就执行已经验证过的回退步骤，同时保留现场信息供排查。等关键流程稳定后，再扩大范围。这样的记录不仅服务于此次下线，也能成为以后模型更新时可重复使用的迁移方法。