正文
如果团队在 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 给出的替代关系如下。它是开始测试的候选，不代表可以跳过回归验证。
| 将下线模型 | 下线日期 | GitHub 建议替代 |
|---|---|---|
| Gemini 3.1 Pro | 2026-09-01 | Gemini 3.6 Flash |
| Claude Opus 4.5 | 2026-09-01 | Claude Opus 4.7、4.8 或 Opus 5 |
| Claude Opus 4.6 | 2026-09-01 | Claude Opus 4.7、4.8 或 Opus 5 |
| Claude Sonnet 4.5 | 2026-09-01 | Claude Sonnet 5 |
| Claude Sonnet 4.6 | 2026-09-01 | Claude Sonnet 5 |
| Raptor Mini | 2026-09-01 | MAI-Code-1-Flash |
有一个例外：Claude Sonnet 4.6 会继续向采用年付方案的个人 Copilot 用户提供。这个例外不应成为团队工作流的依赖，因为组织、企业和不同账户的可用范围并不相同。
先找出哪些工作流绑死了模型名
不要只让每位开发者打开一次模型下拉框。先从仓库和团队配置里找固定名称：
rg -n "Gemini 3\.1 Pro|Claude Opus 4\.[56]|Claude Sonnet 4\.[56]|Raptor Mini" .github .vscode docs README.md再检查这四类位置：
| 位置 | 常见遗漏 |
|---|---|
| IDE 与 CLI | 已保存的默认模型、团队设置、自动选择规则 |
| Skills 与提示词 | SKILL.md、agent instructions 中写死的模型能力假设 |
| 自动化 | issue、PR、定时任务或外部系统触发的 Copilot Agent |
| 评测与预算 | 基准任务使用的模型名、预估 token 和 AI Credits 上限 |
如果搜索不到模型名，也不等于没有依赖。还要查“只有 Opus 才能做”“使用旧 Sonnet 保持低成本”这类描述，以及管理员策略中是否仅允许旧模型。
先确认替代模型已经对团队可用
个人账户能在模型选择器里看到替代模型，不代表企业成员也能看到。Copilot Business 和 Copilot Enterprise 的管理员需要检查模型策略；GitHub 的公告也明确提示，替代模型可能要在 Copilot settings 中启用。
管理员应先完成这三个动作：
- 在一个测试团队中启用候选模型，不立刻全员默认切换。
- 用普通成员账号确认模型同时出现在所需表面，例如 VS Code、github.com、Copilot CLI 或 cloud agent。
- 记录每个团队允许使用的模型、适用数据范围和成本上限。
不要把“默认启用所有新模型”当成唯一策略。对有数据驻留、供应商准入或成本中心要求的团队，按团队或任务类型分批开放更容易审计。
用真实任务比较，不要只问同一道算法题
模型迁移的成功标准应该是交付质量，而不是聊天体验。挑选 4 到 6 个已经有人工结论的真实任务，至少覆盖：
- 一个局部 bug 修复：检查能否定位根因并保持改动范围小。
- 一个跨文件功能：检查能否理解类型、调用链和测试边界。
- 一个代码审查任务：检查是否能给出有证据、可复现的评论。
- 一个 CI 或构建失败：检查是否会区分环境问题、依赖问题和源码问题。
- 一个权限或安全相关改动：检查是否会越权扩大改动、泄露凭据或遗漏验证。
每个任务都记录同一组字段：
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"不要把 API Key、客户日志、生产数据或真实 token 放进评测样本。模型切换前后的提示词、输出和上下文保留策略也应符合团队数据规则。
迁移时最容易忽略的三个差异
输出格式和工具调用节奏会变
替代模型可能更愿意列计划、更多次搜索文件，或在同一任务中改动更多文件。原来依赖“模型会自动停在这里”的提示词，需要改成可验证约束：限定目录、声明禁止修改的文件、要求先展示计划，或要求运行明确的测试命令。
不要把旧模型的偶然行为当契约。把真正需要的边界写入项目规则和验收条件。
成本不等于单价变化
即使新模型的标价接近，推理深度、上下文长度、工具调用次数和失败重试也会改变 AI Credits 消耗。对 cloud agent 和批量自动化，至少比较：
- 单任务的 credits、执行时长和重试次数。
- 每周高频任务的总成本。
- 因为人工返工、测试失败或审查噪音产生的额外成本。
先为候选模型设置小范围预算和告警，再扩大使用范围。成本数据应按任务类型和模型拆分，而不是只看一个团队的总账单。
模型可用性本身需要 fallback
一款替代模型被启用，不代表它对全部账户、全部客户端和全部任务持续可用。至少为关键自动化准备一个第二候选：
默认模型不可用
-> 记录失败的客户端、模型和时间
-> 切换到已验证的候选模型
-> 重新运行测试和人工审查
-> 回写迁移记录fallback 不应该自动绕过数据策略或审批规则。模型换了，仓库权限、网络边界和 PR 合并要求仍然保持一致。
推荐的两周迁移节奏
| 时间 | 要完成的事 | 可观察结果 |
|---|---|---|
| 第 1-2 天 | 搜索旧模型名，列出受影响团队和自动化 | 有一份负责人明确的依赖清单 |
| 第 3-5 天 | 启用候选模型，跑真实任务评测 | 每个任务有 diff、测试和人工结论 |
| 第 6-8 天 | 修正项目规则、预算与 fallback | 旧模型依赖被替换或标记为例外 |
| 第 9-10 天 | 在一个团队默认切换并观察 | 发现失败路径和成本偏差 |
| 9 月 1 日前 | 完成全量切换，保留回退与审计记录 | 不再有自动化引用下线模型 |
如果团队规模很小，也不要省略评测和回退。把周期压缩成两天可以，但至少保留一个真实代码改动和一个真实 CI 失败的验证样本。
下线当天出现“模型找不到”时
先确认是不是策略没有启用，还是工作流仍在请求旧模型。
- 在受影响账号的模型选择器中确认替代模型是否可见。
- 检查企业或组织的模型策略，以及该成员所在团队的策略覆盖。
- 搜索仓库自动化、Skills 与文档中的旧模型名。
- 用已验证的 fallback 模型重跑任务，并保留原始失败信息。
- 重新执行构建、测试、安全扫描和 PR 审查，不复用旧模型输出直接合并。
处理完成后，把旧模型名从文档、提示词模板和自动化中删掉。GitHub 说明下线后无需手动“移除”模型，但团队自己的引用不会自动更新。
结论
9 月 1 日的 Copilot 模型下线是一次典型的 AI Coding 运行时变更：模型会消失，替代模型未必默认可见，输出与成本也会变化。
现在开始盘点固定模型名、确认企业策略、用真实任务回归、设置预算和 fallback，迁移就会变成一次可审查的配置更新，而不是截止日当天的生产事故。