正文

如果团队在 GitHub Copilot 中固定使用 Gemini 3.1 Pro、Claude Opus 4.5、Claude Opus 4.6、Claude Sonnet 4.5、Claude Sonnet 4.6 或 Raptor Mini，现在应当开始迁移。GitHub 公告显示，这些模型会在 2026 年 9 月 1 日 从 Copilot Chat、inline edits、ask、agent mode 和 code completions 中下线。

真正需要迁移的不只是模型选择器里的一个名字。固定模型名可能出现在 IDE 说明、团队 Skills、自动化任务、培训材料和评测记录中；企业版替代模型还可能需要管理员先通过策略启用。先盘点，再小范围验证，最后切换默认值，能避免 9 月 1 日当天才发现 Agent 没有可用模型。

这次下线会影响哪些模型

GitHub 给出的替代关系如下。它是开始测试的候选，不代表可以跳过回归验证。

有一个例外：Claude Sonnet 4.6 会继续向采用年付方案的个人 Copilot 用户提供。这个例外不应成为团队工作流的依赖，因为组织、企业和不同账户的可用范围并不相同。

Gemini 3.1 Pro2026-09-01
Claude Opus 4.52026-09-01
Claude Opus 4.62026-09-01
Claude Sonnet 4.52026-09-01
Claude Sonnet 4.62026-09-01
Raptor Mini2026-09-01

先找出哪些工作流绑死了模型名

不要只让每位开发者打开一次模型下拉框。先从仓库和团队配置里找固定名称：

再检查这四类位置：

如果搜索不到模型名，也不等于没有依赖。还要查“只有 Opus 才能做”“使用旧 Sonnet 保持低成本”这类描述，以及管理员策略中是否仅允许旧模型。

IDE 与 CLI已保存的默认模型、团队设置、自动选择规则
Skills 与提示词SKILL.md、agent instructions 中写死的模型能力假设
自动化issue、PR、定时任务或外部系统触发的 Copilot Agent
评测与预算基准任务使用的模型名、预估 token 和 AI Credits 上限
Bash
rg -n "Gemini 3\.1 Pro|Claude Opus 4\.[56]|Claude Sonnet 4\.[56]|Raptor Mini" .github .vscode docs README.md

先确认替代模型已经对团队可用

个人账户能在模型选择器里看到替代模型，不代表企业成员也能看到。Copilot Business 和 Copilot Enterprise 的管理员需要检查模型策略；GitHub 的公告也明确提示，替代模型可能要在 Copilot settings 中启用。

管理员应先完成这三个动作：

不要把“默认启用所有新模型”当成唯一策略。对有数据驻留、供应商准入或成本中心要求的团队，按团队或任务类型分批开放更容易审计。

  • 在一个测试团队中启用候选模型，不立刻全员默认切换。
  • 用普通成员账号确认模型同时出现在所需表面，例如 VS Code、github.com、Copilot CLI 或 cloud agent。
  • 记录每个团队允许使用的模型、适用数据范围和成本上限。

用真实任务比较，不要只问同一道算法题

模型迁移的成功标准应该是交付质量，而不是聊天体验。挑选 4 到 6 个已经有人工结论的真实任务，至少覆盖：

每个任务都记录同一组字段：

不要把 API Key、客户日志、生产数据或真实 token 放进评测样本。模型切换前后的提示词、输出和上下文保留策略也应符合团队数据规则。

  • 一个局部 bug 修复：检查能否定位根因并保持改动范围小。
  • 一个跨文件功能：检查能否理解类型、调用链和测试边界。
  • 一个代码审查任务：检查是否能给出有证据、可复现的评论。
  • 一个 CI 或构建失败：检查是否会区分环境问题、依赖问题和源码问题。
  • 一个权限或安全相关改动：检查是否会越权扩大改动、泄露凭据或遗漏验证。
YAML
copilot_model_migration:
  task: "订单导出权限修复"
  old_model: "Claude Sonnet 4.6"
  candidate_model: "Claude Sonnet 5"
  surface: "Copilot cloud agent"
  outcome: "needs_changes"
  changed_files: 5
  validation:
    - "pnpm run typecheck"
    - "pnpm test"
  human_findings:
    - "缺少后台下载接口鉴权"
  credits_used: "record from billing"

迁移时最容易忽略的三个差异

  • 单任务的 credits、执行时长和重试次数。
  • 每周高频任务的总成本。
  • 因为人工返工、测试失败或审查噪音产生的额外成本。
输出格式和工具调用节奏会变

替代模型可能更愿意列计划、更多次搜索文件，或在同一任务中改动更多文件。原来依赖“模型会自动停在这里”的提示词，需要改成可验证约束：限定目录、声明禁止修改的文件、要求先展示计划，或要求运行明确的测试命令。 不要把旧模型的偶然行为当契约。把真正需要的边界写入项目规则和验收条件。

成本不等于单价变化

即使新模型的标价接近，推理深度、上下文长度、工具调用次数和失败重试也会改变 AI Credits 消耗。对 cloud agent 和批量自动化，至少比较： 先为候选模型设置小范围预算和告警，再扩大使用范围。成本数据应按任务类型和模型拆分，而不是只看一个团队的总账单。

模型可用性本身需要 fallback

一款替代模型被启用，不代表它对全部账户、全部客户端和全部任务持续可用。至少为关键自动化准备一个第二候选： fallback 不应该自动绕过数据策略或审批规则。模型换了，仓库权限、网络边界和 PR 合并要求仍然保持一致。

Text
默认模型不可用
  -> 记录失败的客户端、模型和时间
  -> 切换到已验证的候选模型
  -> 重新运行测试和人工审查
  -> 回写迁移记录

推荐的两周迁移节奏

如果团队规模很小，也不要省略评测和回退。把周期压缩成两天可以，但至少保留一个真实代码改动和一个真实 CI 失败的验证样本。

第 1-2 天搜索旧模型名，列出受影响团队和自动化
第 3-5 天启用候选模型，跑真实任务评测
第 6-8 天修正项目规则、预算与 fallback
第 9-10 天在一个团队默认切换并观察
9 月 1 日前完成全量切换，保留回退与审计记录

下线当天出现“模型找不到”时

先确认是不是策略没有启用，还是工作流仍在请求旧模型。

处理完成后，把旧模型名从文档、提示词模板和自动化中删掉。GitHub 说明下线后无需手动“移除”模型，但团队自己的引用不会自动更新。

  • 在受影响账号的模型选择器中确认替代模型是否可见。
  • 检查企业或组织的模型策略，以及该成员所在团队的策略覆盖。
  • 搜索仓库自动化、Skills 与文档中的旧模型名。
  • 用已验证的 fallback 模型重跑任务，并保留原始失败信息。
  • 重新执行构建、测试、安全扫描和 PR 审查，不复用旧模型输出直接合并。

结论

9 月 1 日的 Copilot 模型下线是一次典型的 AI Coding 运行时变更：模型会消失，替代模型未必默认可见，输出与成本也会变化。

现在开始盘点固定模型名、确认企业策略、用真实任务回归、设置预算和 fallback，迁移就会变成一次可审查的配置更新，而不是截止日当天的生产事故。

参考来源

Upcoming August 2026 model deprecations in GitHub CopilotGitHub ChangelogSupported AI models in GitHub CopilotGitHub DocsChoosing the right AI model for your taskGitHub DocsEnterprise teams model policy targeting in public previewGitHub ChangelogClaude Sonnet 5Anthropic

相关文章

Claude、GPT、Gemini 怎么选：AI Coding 任务分配和验证清单智能编程 / 约 12 分钟GPT-5.6 与 Claude Fable 5：前沿模型的“发布”已经不只看能力智能编程 / 约 10 分钟AI 编程开始按量计费后，团队终于得给每次 Agent 长跑算账了智能编程 / 约 11 分钟7 个关键洞察：AI Coding 工具真正改变的不是写代码，而是验证代码智能编程 / 约 18 分钟当 AI Agent 开始替人动手，企业最先缺的不是更强模型智能编程 / 约 9 分钟GitHub Actions 不是能跑就行：第三方 Action、secrets、权限和日志怎么查工程实践 / 约 13 分钟

作者信息

luowj

关注 AI Coding 工具链、开发环境排障、工程发布和安全边界。文章优先基于官方文档、 真实报错、公开事件和可复现的检查步骤整理。

luowj1998@gmail.com提交文章反馈