GitHub Copilot 10 月 2 日模型下架清單：Gemini、Kimi、Claude 怎麼替換

先分辨「可用模型」和「預設模型」#

模型下架時，最容易漏掉的是把兩種設定混在一起：

Business 與 Enterprise 管理員可能需要先在模型 policy 中啟用替代模型。GitHub 的公告說明，模型移除後不需要另外執行「移除」動作；但如果替代模型本來被 policy 關閉，成員仍然可能在 10 月 2 日後找不到可直接切換的選項。

若要把新對話的起始模型改成指定值，可以參考GitHub Copilot enterprise managed settings 的預設模型設定。不要把預設模型設定誤當成可用性 policy：前者改變起始選擇，後者才決定模型是否能被選用。

Gemini 使用者：先確認 Gemini 3.8 Flash 的 rollout#

GitHub 在 9 月 3 日另外公告 Gemini 3.8 Flash 已開始提供給 Pro、Pro+、Max、Business 與 Enterprise 方案，但同樣採 gradual rollout。這代表你可以先看到替代模型已出現在官方公告，卻還沒在每個 Copilot 入口都看到它。

建議先用不含機密程式碼的新對話，在團隊實際使用的入口做 smoke test：

1. 開啟模型選單，確認 Gemini 3.8 Flash 是否出現。
2. 分別測試 Chat、inline edit 或 agent 中團隊會用到的入口。
3. 記錄帳號方案、enterprise policy 與測試日期。
4. 若是 Enterprise，確認替代模型不是只對某個 organization 或 team 開放。

不要只在 VS Code 驗證就宣布完成；Copilot CLI、GitHub.com、coding agent 與 IDE 的模型選單可能因 rollout 和客戶端支援而不同。

Claude 與 Kimi：不要只做名稱替換#

Claude Opus 4.7 要替換成 Claude Opus 5，Kimi K2.7 Code 要替換成 Kimi K3。除了名稱，還應重新確認團隊對輸出品質、回應速度、上下文需求與資料處理的期待。

可以把下列資訊放進模型切換的驗證紀錄：

這不是要替每個模型做完整 benchmark，而是避免團隊在下架日才發現某個重要 workflow 依賴了未開啟的替代模型。

10 月 2 日前的 migration checklist#

• 用 GitHub API、管理頁面或團隊現有設定盤點舊模型名稱。
• 搜尋 repository、prompt template、內部文件、測試與 CI 中的四個舊名稱。
• 先為 Business 與 Enterprise 啟用對應替代模型，再測試成員實際可見性。
• 若需要統一新對話的起始模型，更新 managed settings；若要分 team 處理，再更新 team mapping。
• 在每個重要 Copilot 入口建立一個最小、無機密的測試案例。
• 把 10 月 2 日列為檢查點，確認舊名稱不再出現在新 session 的可選清單。
• 對 agent 或 completions 依賴較深的流程，準備人工 review 或短期 fallback。

搜尋時可以先從這四個精確字串開始：

1
Gemini 3.5 Flash
2
Gemini 3.6 Flash
3
Kimi K2.7 Code
4
Claude Opus 4.7

如果只在文章中提到舊模型，那是文件更新；如果出現在自動化設定、API payload 或測試斷言，就應視為需要排程處理的 migration。

這次公告後的判斷方式#

截止目前，最穩妥的做法不是立即把所有團隊切到同一個替代模型，而是先確認替代模型的 policy、入口 rollout 與實際工作案例。模型名稱替換完成後，再用小範圍 team 做一輪短測，最後才調整 enterprise 預設值。

只要把「移除日」「替代模型」「可用性 policy」「預設模型」四個欄位分開記錄，10 月 2 日就不會只剩下成員回報「模型突然不見了」。

常見問題#