GitHub Copilot 10 月 19 日模型下架：六個模型怎麼替換？

先分辨可用模型、預設模型與固定模型名稱#

下架前最容易漏掉的是把三種狀態混在一起：

Business 與 Enterprise 管理員應先確認替代模型的 policy。GitHub 也說明，組織若啟用預設模型的自動開放，新的替代模型可能會隨政策出現；但若全域預設開放被關閉，或管理員明確停用特定模型，就不能只依公告推定成員一定看得到。

如果要修改新對話的起始值，可以參考GitHub Copilot enterprise managed settings 的預設模型設定。預設模型只改變起始選擇，不等同於可用性 policy；兩者要分開留下變更紀錄。

先做一次可重複的 repository 盤點#

下列命令是盤點範本，請在自己的 repository 執行；它不是本次任務對你的程式碼所做的檢查：

1
rg -n -i \
2
  'Gemini 3\.7 Flash|GPT-5\.5|GPT-5\.4( mini)?|GPT-5 mini|Grok 4\.5' \
3
  .

搜尋結果要再依用途分級，不是全部取代成新字串：

1. 文件與 onboarding：更新模型名稱、下架日期、方案限制和驗證日期。
2. prompt template 與 agent 設定：確認新模型的上下文、工具與輸出要求仍適用。
3. API payload、CI 或測試斷言：把替換列為 migration task，避免 UI 正常但自動化在下架後才失敗。
4. 歷史紀錄與 changelog：保留原名稱，補上已下架或遷移的註記，不要破壞可追溯性。

若 repository 同時包含 Copilot CLI、IDE 設定與 GitHub Actions，還要在每個實際入口做一次小型 smoke test。單獨在 VS Code 看得到模型，不能證明 CLI、GitHub.com 或 coding agent 也已經可用。

替換前要驗證什麼#

不要把工作縮成字串替換。對每個重要 workflow 至少保留下面五欄：

這樣可以把「模型不存在」、「模型尚未 rollout」和「模型已存在但 workflow 不相容」分開。若是 Business／Enterprise，應使用測試成員帳號，而不是只用管理員帳號下結論。

10 月 19 日前的 migration checklist#

• 以官方六個模型清單盤點 repository、prompt、設定檔、CI 與內部文件。
• 確認 Gemini 3.8 Flash、GPT-5.6 Sol、GPT-5.6 Luna 與 Grok 4.6 是否受到方案或入口限制。
• Business／Enterprise 先記錄模型 policy、全域預設開放設定與例外停用清單。
• 在每個重要 Copilot 入口用不含機密程式碼的最小案例測試替代模型。
• 為 API、agent 或 completions 依賴較深的流程保留人工 review 或短期 fallback。
• 將 10 月 19 日設為再次檢查點，確認舊名稱不再被新的自動化流程使用。

如果你要處理 Grok 4.7 的新 rollout，請另外看GitHub Copilot Grok 4.7 的方案、政策與 credits 檢查；那是新增模型的可見性問題，不要和本次舊模型下架混成同一個判斷。

結論：把下架日當成驗證截止日#

這次變更真正需要管理的是四件事：移除日期、官方替代方向、組織可用性 policy，以及實際 workflow 的測試結果。先完成可重複的盤點，再由小範圍測試確認替代模型，最後才調整預設值；這比在模型消失後才從錯誤訊息回推原因更容易維護。