GitHub Copilot 的 GPT-5.2 / GPT-5.2-Codex 6 月要退役：手动锁模型的团队现在就该补一次排查

截至 2026-05-02，GitHub 已在官方 changelog 里写明：从 2026-06-01 开始，GPT-5.2 和 GPT-5.2-Codex 会从大多数 GitHub Copilot 体验里退役，例外只剩 Copilot Code Review 里的 GPT-5.2-Codex。短答案也很直接：如果你们平时手动选模型、给团队设过 model policies，或者把某些 Copilot 流程默认绑在旧模型上，这不是“到点自动变好”的提醒，而是现在就该补的一轮排查。 反过来，如果团队大部分人一直用 Auto model selection，组织也没锁死旧模型，这次切换的实际摩擦会小很多。

这篇不讨论哪家模型更强，只回答一个更实际的问题：当 GitHub Copilot 的 GPT-5.2 / GPT-5.2-Codex 进入退役倒计时，哪些团队配置和使用习惯最容易在 6 月第一周出问题。 如果你最近也在补开发者工具治理，可以顺手对照 TG Hubs 的 开发者工具主题页、前面那篇讲 GitHub 模型与调用边界的 GitHub App installation token 格式变更排查，以及那篇更偏代码代理落地的 GitHub 把 agent 安全训练做成闯关游戏后，团队真正该先补什么。

谁现在应该先查，谁可以先别急

建议现在就查的人：

• 你们在 Copilot Chat 里会手动固定模型，而不是长期交给 Auto model selection
• 你是 Copilot Enterprise 管理员，给组织配过 model policies
• 你们的培训文档、内部 SOP、截图教程里明确写过“用 GPT-5.2”或“用 GPT-5.2-Codex”
• 你们正在用 Copilot Chat、inline edits、ask / agent modes，或者代码补全做日常开发

可以先别把它当成紧急事故的人：

• 你平时几乎都用 Auto model selection，而且并不关心具体模型名
• 你们没有给组织锁模型，也没有把旧模型写进脚本、教程或 onboarding
• 你关心的是 Copilot Code Review，而不是其它 Copilot 入口；因为 GitHub 这次明确说了，GPT-5.2-Codex 在 Copilot Code Review 里是例外

GitHub 已经改了什么，别只看标题

GitHub 官方 changelog 这次给出的信息其实很够用，关键有 3 条：

1. GPT-5.2 的建议替代模型是 GPT-5.5
2. GPT-5.2-Codex 的建议替代模型是 GPT-5.3-Codex
3. 退役范围覆盖大多数 Copilot 体验，包括 Copilot Chat、inline edits、ask / agent modes 和 code completions

真正容易让团队误判的点，不是退役日期本身，而是：GitHub Docs 在本文写作时仍然把 GPT-5.2、GPT-5.2-Codex、GPT-5.3-Codex 列在 supported models 里。 这说明两个事实同时成立：

• 这些模型你现在可能还看得到，也可能还能选
• 但“今天还在支持列表里”不等于“6 月 1 日后你还可以继续把它当默认习惯”

所以这不是一篇“GitHub 又换模型名字了”的新闻，而是一条很具体的运维信号：如果团队曾经显式依赖旧模型，窗口期其实已经开始了。

GitHub Copilot 的 GPT-5.2 / GPT-5.2-Codex 退役前，先查这 4 处

1）先查团队现在是不是手动固定在旧模型上

GitHub Docs 已经把入口写得很清楚：在 github.com 或 IDE 的 Copilot Chat 里，都可以从底部的 CURRENT-MODEL 下拉菜单查看当前模型。

你现在最值得先做的不是争论新模型是否更强，而是先判断团队有没有这些习惯：

• 文档里写着“默认就用 GPT-5.2”
• 某些同事为了稳定输出，一直手动固定在 GPT-5.2-Codex
• 代码评审、问答、agent 任务用的是不同模型，但没人再回头看过配置

如果你们已经长期交给 Auto model selection，风险会小一些，因为 GitHub 的文档也明确说了：Auto 会基于可用性自动选模型，并帮助减少 rate limiting。可如果你们是“手动固定党”，那这次就不是自动兜底问题，而是要不要主动改默认习惯的问题。

2）再查组织的 model policies 有没有把替代模型关在门外

GitHub 在 changelog 里点得很直接：Copilot Enterprise 管理员可能需要通过 model policies，先把替代模型放出来。 这一步很容易被忽略，因为不少团队会默认觉得“模型退役了，平台自然会给我新模型”。

现实里更常见的情况是：

• 用户知道旧模型要退了
• 管理员也知道有替代模型
• 但组织策略没有放开，结果用户在模型选择器里根本看不到 GPT-5.5 或 GPT-5.3-Codex

如果你是管理员，至少要核对这两件事：

• 替代模型是否已经被组织或企业策略允许
• 用户在个人 Copilot 设置和 Chat 模型选择器里是否真的能看到这些模型

别把“文档里写支持”误读成“你们租户里已经可用”。 GitHub Docs 对这一点写得很明确：可用模型会受 model policies 影响。

3）把“Code Review 是例外”单独拎出来看

这轮变化里最容易被一句话带过、但实际最值得单列检查的，就是 GPT-5.2-Codex 在 Copilot Code Review 里是例外。

这意味着什么？

• 如果你们主要依赖的是 Code Review，这次不一定要和其它 Copilot 入口同一时间改完
• 但如果你们把 Chat / agent / completions 和 Code Review 混成一个统一“Copilot 模型”概念，6 月后就很容易出现认知错位

更直白一点说：同样叫 Copilot，不同入口的退役节奏和剩余例外不完全一样。 如果内部培训写成“GPT-5.2-Codex 全面下线”，那会误导 Code Review 用户；如果写成“没事，还能继续用”，又会误导聊天和 agent 用户。

4）最后查所有“写死旧模型名”的二级资产

这一步最不显眼，但最容易在 6 月后制造返工：

• onboarding 文档
• IDE 截图教程
• 内部最佳实践页
• 录屏培训
• prompt 模板或“推荐模型”清单

如果这些资产里把 GitHub Copilot GPT-5.2 或 GPT-5.2-Codex 写成默认选项，哪怕产品本身已经换过去了，团队的日常操作还是会继续照旧模型名说话。结果就是：

• 新同事按旧截图找模型，找不到
• 管理员以为是权限问题
• 一线使用者以为是 GitHub 抽风

这类问题通常不是技术故障，而是配置变了，文档没跟。

一份够用的最小排查清单

如果你今天就要判断这轮 GitHub Copilot GPT-5.2 退役会不会打断团队，我建议至少过这 5 条：

• [ ] 团队是否有人仍在手动固定 GPT-5.2 或 GPT-5.2-Codex
• [ ] 组织的 model policies 是否已经允许 GPT-5.5 / GPT-5.3-Codex
• [ ] 关键使用入口里，用户是否真的能在 CURRENT-MODEL 选择器里看到替代模型
• [ ] 内部文档、截图、录屏、培训材料里，是否还写着旧模型名
• [ ] 对于 Copilot Code Review，团队是否已经单独注明“GPT-5.2-Codex 仍属例外”

这 5 条里如果前 3 条还没过，就不要把它当成一条普通更新提醒。因为它已经不是“以后再说”的产品资讯，而是会直接影响团队默认操作路径的配置问题。

什么时候值得直接切到 Auto，什么时候不要偷懒

如果你的目标只是降低 GitHub Copilot GPT-5.2 退役带来的人工维护成本，那把更多日常问答交给 Auto model selection，通常是更省事的做法。尤其是：

• 团队并不刻意追求某个具体模型
• 大家主要想避免模型下线后大面积改文档
• 你更关心“别断”而不是“每次都指定最强模型”

但如果你们团队对模型选择本来就有明确理由，比如：

• 某些代码任务长期偏好 Codex 系列
• 你们对延迟、输出风格或审阅表现有固定偏好
• 你们在做教程、评估或内部对照实验

那就别把 Auto 当成万能跳过键。更稳的做法，是把旧模型依赖找出来，再逐项决定：哪里交给 Auto，哪里改成 GPT-5.5，哪里改成 GPT-5.3-Codex。

FAQ

GitHub Copilot 的 GPT-5.2 和 GPT-5.2-Codex 是 6 月 1 日一起退吗？

按 GitHub 2026-05-01 的 changelog，大多数 Copilot 体验里，GPT-5.2 和 GPT-5.2-Codex 都是 2026-06-01 退役；但 GPT-5.2-Codex 在 Copilot Code Review 里是例外，不能把这条规则直接套到所有入口。

为什么 GitHub Docs 现在还列着 GPT-5.2 / GPT-5.2-Codex？

因为本文写作时它们仍在 supported models 文档里可见，这只能说明“当前文档仍列出这些模型”，不代表 6 月 1 日后你还应该继续把它们当成默认依赖。更稳的判断方式，是同时看 changelog 和你自己租户里的 model availability。

如果我一直用 Auto model selection，还需要做什么？

通常不需要像手动固定模型那样大改，但仍建议你检查两件事：一是组织策略有没有把替代模型卡住，二是团队文档里有没有继续推荐旧模型名。Auto 能减少手工切换，不会自动替你更新培训资产。

管理员最容易漏掉哪一步？

最常见的漏项不是“没看到退役公告”，而是没有先确认替代模型在 model policies 里已经放开。公告看到了，但模型选择器里没出现，最后还是会变成一线使用者的故障单。

结论

如果你问的是 GitHub Copilot 的 GPT-5.2 / GPT-5.2-Codex 退役前要不要现在就查，我的答案是：要。 尤其是团队里只要存在手动固定模型、组织策略限模、或旧文档写死模型名这三类情况之一，就不该把这件事留到 6 月再补。

但如果你问的是 这会不会自动变成一场大迁移项目，答案也未必。对大量已经使用 Auto model selection、又没有强绑定旧模型的团队来说，这更像是一轮提前做掉的配置与文档收口。真正要避免的，不是模型名变化本身，而是 GitHub Copilot GPT-5.2 退役后，团队还在按旧默认路径操作。

来源

• GitHub Changelog: Upcoming deprecation of GPT-5.2 and GPT-5.2-Codex
• GitHub Docs: Supported AI models in GitHub Copilot
• GitHub Docs: Changing the AI model for GitHub Copilot Chat
• GitHub Docs: Configure access to AI models