GitHub Copilot 模型停用怎麼遷移？9/1 前檢查 Gemini、Claude 與 Raptor Mini

先把停用、替代與 rollout 分開#

目前可以先用這張表整理狀態：

GitHub 的 Gemini 3.7 Flash 公告列出 Pro、Pro+、Max、Business 和 Enterprise 方案，以及 Visual Studio Code、Visual Studio、Copilot CLI、cloud agent、Copilot app、JetBrains、Xcode 和 Eclipse 等入口。它同時說明 rollout 會逐步進行；所以排錯時要記錄「方案 + 入口 + 日期」，不能只截一張文件頁面。

9 月 1 日前要處理的模型#

GitHub 於 2026 年 7 月 31 日公告，以下模型預計在 2026 年 9 月 1 日從 Copilot experiences 停用：

Claude Sonnet 4.6 有一個重要例外：GitHub 說明個人 Copilot 年繳方案的訂閱者仍可使用它，以保留 Sonnet 選項。這個例外不能直接套用到 Business／Enterprise 或其他 client；仍要以帳號、方案與 model policy 的實際結果為準。

GitHub 的 supported models 文件也會列出 retirement history、各 client 支援版本與方案可用性。遷移時應把公告當成截止提醒，把文件和實際 model picker 當成驗證證據。

先搜尋 repository 內的舊模型依賴#

不要只搜尋一個模型名稱就宣布遷移完成。Copilot 的模型可能出現在使用者偏好、企業政策、文件、測試說明，或某個自動化工具的設定裡。

1
# 在 repository 根目錄執行，排除套件與建置產物
2
rg -n -i \
3
  'gemini[-_ ]?2[.]5[-_ ]?pro|gemini[-_ ]?3[-_ ]?flash|gemini[-_ ]?3[.]1[-_ ]?pro|gemini[-_ ]?3[.]5[-_ ]?flash|gemini[-_ ]?3[.]7[-_ ]?flash' \
4
  --glob '!node_modules/**' \
5
  --glob '!dist/**' \
6
  .

若要一次盤點 9 月 1 日的其他模型，也可以把查詢擴大：

1
rg -n -i \
2
  'claude[-_ ]?(opus|sonnet)[-_ ]?4[.]5|claude[-_ ]?(opus|sonnet)[-_ ]?4[.]6|raptor[-_ ]?mini|gemini[-_ ]?3[.]1[-_ ]?pro' \
3
  --glob '!node_modules/**' \
4
  --glob '!dist/**' \
5
  .

這個搜尋只是找線索，不代表每個命中都是 GitHub Copilot 的有效 model ID。每個結果都要回到實際入口確認：

若你在程式碼中找到的只是 prompt 裡的模型名稱，也不要只做全域取代；先確認它是文件範例、測試固定值，還是會真的送出模型請求。

Business／Enterprise 先看 model policy#

GitHub 公告指出，Copilot Enterprise 和 Business 的管理員可能需要在 Copilot settings 啟用替代模型的 policy，組織成員才可以選它。這代表「舊模型已停用」和「新模型已開放給成員」是兩條不同的路徑；Gemini 3.7 Flash 的 Preview policy 只是其中一個例子。

排查順序可以固定成：

1. 在實際使用的入口確認登入帳號與 Copilot 方案。
2. 對 Business／Enterprise 請管理員確認替代模型的 model policy 是否開啟；如果是 Gemini 3.7 Flash，另外確認 Preview policy。
3. 重新開啟 model picker，確認目前使用的 IDE、CLI 或 app 是否已收到 rollout。
4. 如果只有某一個入口沒有模型，記下 client 名稱與版本，不要先修改整個 organization policy。
5. 把驗證日期、入口與 policy 結果記錄在團隊文件中。

這篇更新的重點不是叫你把所有模型 policy 都打開，而是把「服務端 rollout」和「組織允許」分開，讓 9 月 1 日前的模型變更有可以交接的證據。

舊模型與新模型不要當成逐字相容替換#

GitHub 對 Gemini 3.7 Flash 的公告提到 web／app development、agentic coding、code quality、codebase research 和 verification 等早期測試觀察，但這些不是你專案的相容性保證。即使新模型已出現在選單，原本的 prompt、工具呼叫或輸出格式也不一定完全相同。

對有自動化的團隊，至少保留一組範圍固定、可人工 review 的回歸任務：

1
任務：讀取指定資料夾，列出三個測試缺口，輸出固定 Markdown 表格。
2
驗收：
3
1. 不可修改檔案。
4
2. 每個缺口要指向實際檔案或測試名稱。
5
3. 輸出欄位順序固定。
6
4. 失敗時要明確說明缺少的輸入。

先用這類任務比較原本工作流和替代模型的完成條件，再決定是否調整提示詞、工具權限或 fallback。不要用「回答看起來差不多」作為遷移完成條件。

如果你也在評估 GitHub Copilot 的其他模型，可以參考 GitHub Copilot Grok 4.6 的方案、rollout 與 AI credits 檢查；那篇處理另一個近期模型 rollout，本文則聚焦模型停用與替換的共同檢查流程。

這次遷移完成的判斷#

完成條件不是 model picker 出現一個新名稱，而是：

• repository 與文件不再把已停用模型當成必要依賴。
• Business／Enterprise 已確認替代模型 policy 的可用範圍，必要時也確認 Gemini 3.7 Flash Preview policy。
• 重要入口至少完成一個固定任務的回歸測試。
• 自動化有明確的 fallback、錯誤訊息與人工接手方式。
• 團隊知道「模型不可用」和「模型輸出不符合任務」要分別回報。

模型退役是正常的維護事件。把模型名稱抽離成可替換設定，再用小型驗收任務確認輸出，會比等到 9 月 1 日後正式 agent 工作失敗才臨時換模型穩妥。

常見問題#