GitHub Copilot MAI-Code-1-Flash 已退役：替代模型與遷移檢查

先看懂退役後的新舊版本#

GitHub 對新模型的公告提到，它加入原生 vision 支援，並改善 coding quality、instruction following、tool use 和 performance。這些是官方對模型的能力描述，不等於每個 repository 的任務都會得到相同輸出；遷移完成仍要以你的驗收條件為準。

先確認方案、policy 和實際入口#

GitHub 的模型文件列出退休歷史與目前可用模型，但可選清單仍受方案、client 和管理 policy 影響。排查時把「文件存在」「帳號可見」「實際請求成功」分成三個結果：

如果 Business 或 Enterprise 成員看不到替代模型，先查 organization／enterprise policy、方案、client 版本和實際 model picker。GitHub 公告指出，企業管理員可能需要啟用替代模型的 policy；這種服務端限制不是重裝 IDE 就能修好。

若只是某一個入口不能選，先對照 GitHub Copilot 支援的模型與退休歷史；若所有模型請求都失敗，則要把它當成帳號、權限或服務問題另外排查。不要把「舊模型消失」和「Copilot 全部故障」混在同一個 incident。

搜尋 repository 裡的固定模型依賴#

先在 repository、CI 設定和團隊文件找出新舊名稱。搜尋結果只是線索，每一筆都要回到實際使用入口確認：

1
rg -n -i \
2
  'MAI[-_ ]?Code[-_ ]?1[-_ ]?Flash|MAI[-_ ]?Code[-_ ]?1[.]1[-_ ]?Flash' \
3
  --glob '!node_modules/**' \
4
  --glob '!dist/**' \
5
  .

可以把命中位置分成四類：

• .vscode、Copilot 設定或團隊文件：更新選擇說明，避免新人照著選退役模型。
• CI、script 或 agent workflow：確認是否把模型 ID 寫死，並設計可替換設定或 fallback。
• 測試 prompt 和 snapshot：保留基準輸出，但標記它是舊模型結果，不能當成新模型一定相同的契約。
• 管理政策或 onboarding：確認新模型不是只對個人帳號開放，組織 policy 也已同步。

這篇文章自己的歷史段落、release note 和測試 snapshot 也可能命中舊名稱。不要把所有含有 MAI 的文字都當成有效設定；逐筆確認比大量取代更安全，尤其不要刪掉能說明某次回歸基準的歷史紀錄。

用固定任務做替代模型回歸#

退役已經完成後，不一定還能對舊模型重跑同一個任務。可以保留舊模型先前的 snapshot 作為歷史基準，再讓替代模型在相同輸入和權限邊界下完成一次可檢查任務：

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

至少記錄以下結果：

1. 使用的 client、登入方案和模型名稱。
2. 是否能完成同一個 tool call 或 agent 步驟。
3. 輸出是否符合格式、檔案範圍和不可寫入的限制。
4. 失敗時能否回到人工處理，而不是無限重試。

如果任務使用 Copilot cloud agent，也要把 reasoning level、額度和完成條件分開記錄；可以參考 Copilot cloud agent 的 reasoning level 檢查，不要把換模型和提高推理深度當成同一個修復。用 Auto model selection 時，紀錄實際顯示的模型或 review overview 資訊，避免只記下「請求成功」。

退役後的收尾清單#

• 在測試 organization 確認 MAI-Code-1.1-Flash policy 和成員可見性。
• 更新仍會影響請求的固定模型 ID、文件、範例和 workflow 設定，保留變更前後的 diff。
• 完成至少一組固定任務的回歸，記錄輸出、tool call、權限與失敗時的人工接手方式。
• 對使用 Auto model selection 的團隊，確認實際入口能正常請求，並留下模型選擇或結果頁面的證據。
• 檢查監控、錯誤分類和 fallback 是否把「模型退役」與「服務不可用」分開記錄。

GitHub 的公告也說明，退役本身不要求你另外刪除舊模型；真正需要處理的是仍會送出舊 ID 的 workflow 或 integration。若只是歷史文件或 snapshot，可以保留並標註退役日期，讓日後追查結果時知道它不是目前可用模型。

如果你之前處理過 Gemini 模型停用，可以參考 GitHub Copilot Gemini 模型退役後的檢查順序。兩篇文章的共同點是要把模型可見、模型可選和工作流已驗證分開；這次則要把「退役前遷移」改成「退役後依賴清理與驗證」。

結論：把模型 ID 當成有生命週期的依賴#

MAI-Code-1-Flash 已退役後，排查順序應該是：先確認替代模型對實際方案和入口可用，再搜尋仍會送出舊 ID 的設定，最後用固定任務驗證輸出、工具與權限邊界。把模型 ID 當成有生命週期的依賴，才能在下一次退役時快速找到真正需要改的地方。

常見問題#