GitHub Copilot 的 Gemini 2.5 Pro、3 Flash 停用後：模型與工作流檢查

先判斷是哪一種依賴#

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

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

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

企業帳號先看替代模型政策#

GitHub 說明企業管理員可能需要先在 Copilot settings 啟用替代模型。這表示「舊模型已停用」與「新模型立刻可選」是兩個不同事件：前者已由服務端完成，後者還受政策與 rollout 影響。

排查順序可以固定成：

1. 在實際使用的入口確認登入帳號與方案。
2. 在組織或企業的 Copilot model policies 查看 Gemini 3.1 Pro、Gemini 3.5 Flash 是否允許。
3. 重新開啟 model picker，確認替代模型是否出現。
4. 以一個範圍固定、可人工 review 的任務測試，不要直接拿正式長任務驗證。
5. 把驗證日期、入口與 policy 結果記錄在團隊文件中。

若只是想繼續使用 Copilot Chat，通常不需要自己「移除」舊模型；GitHub 公告明確表示停用後不需要額外刪除舊模型。需要主動處理的是你自己維護的工作流、文件與固定模型選擇。

不要把替代模型當成逐字相容替換#

即使替代模型名稱已出現在選單，也不代表原本的 prompt、工具呼叫或輸出格式一定完全相同。對有自動化的團隊，至少保留一組小型回歸任務：

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

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

如果你也在評估 GitHub Copilot 的其他模型，可以參考 Claude Opus 5 在 Copilot 的可用性檢查；那篇處理的是方案、rollout 與組織政策，不是這次 Gemini 停用的公告。

這次遷移完成的判斷#

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

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

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

常見問題#