update · TowCue 編輯團隊
GitHub Copilot 10 月 2 日將淘汰四款模型：開發工作流現在該怎麼準備？
GitHub Copilot 將於 2026 年 10 月 2 日淘汰 Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code 與 Claude Opus 4.7。本文整理團隊如何提前盤點固定模型依賴與遷移風險。
快速解答
GitHub 在 2026 年 9 月 3 日公告，將於 2026 年 10 月 2 日在 GitHub Copilot 各主要使用情境中淘汰四款模型：
| 即將淘汰 | GitHub 建議替代模型 |
|---|---|
| Gemini 3.5 Flash | Gemini 3.8 Flash |
| Gemini 3.6 Flash | Gemini 3.8 Flash |
| Kimi K2.7 Code | Kimi K3 |
| Claude Opus 4.7 | Claude Opus 5 |
GitHub 表示，這次變更涵蓋 Copilot Chat、inline edits、ask、agent mode 與 code completions。Copilot Business 與 Enterprise 管理員還可能需要先在模型政策中啟用替代模型，使用者才看得到新的選項。
TowCue 認為真正需要注意的，不是「又有幾個舊模型下架」，而是：不要讓模型名稱變成開發工作流裡看不見的硬依賴。 如果 CLI 指令、團隊文件、Agent 範本或測試腳本固定指定某款模型，最好在 10 月 2 日之前先盤點，而不是等流程突然報錯才處理。
若想了解主要替代選項之一，可先看 TowCue 的 Gemini 3.8 Flash 編程與 Agent 分析。團隊若正在建立 Agent 流程，也建議搭配 AI Agent 最佳實務指南 與 工作用 AI 工具選擇指南。
到底改了什麼？
這是提前一個月左右公布的淘汰通知，不是 9 月 3 日立刻停止服務。四款模型預計到 10 月 2 日才正式被移除，實際是否能使用仍取決於 Copilot 方案、客戶端與組織政策。
但「GitHub 有推薦替代模型」不代表遷移是完全無感的。新版模型可能在推理方式、延遲、token 消耗、工具呼叫與輸出格式上都不同。
所以這次遷移更適合當成一次 工作流回歸測試，而不是只在模型選單中換一個名字。
固定模型依賴可能藏在哪裡？
最明顯的是 Copilot 的模型選單，但實際團隊還可能把模型名稱寫在：
- Copilot CLI 的固定
--model指令 - shell alias 或環境變數
- 新人 onboarding 文件
- 針對特定模型行為調好的 Prompt 範本
- 內部 Agent 設定與評估腳本
- 操作手冊與截圖式 SOP
- Enterprise / Organization 的模型政策
GitHub 官方文件也明確提醒，Copilot 模型可用性會隨時間改變，而且同時受到方案與使用客戶端影響。因此同一套指令，在某位開發者電腦上正常，不代表其他成員一定能使用同一模型。
為什麼 Business 與 Enterprise 管理員要先看政策？
GitHub 在公告中特別提醒，Copilot Business 與 Enterprise 管理員可能需要在模型政策裡啟用替代模型。
GitHub 的 Default availability for released models 會決定新發布的 GA 模型在尚未被明確設定時，預設是開啟還是關閉。但部分模型不會自動跟隨這項政策，例如 pre-GA、open-weight，或不符合特定資料保留與合規政策的模型。
因此管理員真正要確認的不是：
「GitHub Copilot 支不支援這個模型？」
而是：
「我們這個組織、這個方案、這個政策與這個客戶端能不能用？」
這兩個問題不是一回事。
應該立刻切換到 GitHub 建議的模型嗎？
不建議直接全量切換，先測試比較穩妥。
對 Gemini 3.5 Flash 與 3.6 Flash，GitHub 建議改用 Gemini 3.8 Flash。GitHub 目前的模型價格文件把 Gemini 3.6、3.7 與 3.8 Flash 列在相同價格帶，而 3.8 是更新的 versatile Gemini 選項。但相同 token 單價並不代表每個完成任務的總成本相同，因為新版模型可能使用不同數量的 token，也可能減少或增加返工次數。
對 Claude Opus 4.7，官方建議 Claude Opus 5；Kimi K2.7 Code 則建議 Kimi K3。這兩組遷移也應該用真實編程任務驗證，不要只因為版本更新就直接替換。
真正值得採用的替代模型，應該在正確率、工具呼叫、延遲與人工複核成本上通過你自己的測試。
Auto model selection 能解決這個問題嗎？
一定程度上可以降低「固定指定單一模型」的營運風險。
GitHub 說明，Auto model selection 會根據即時可用性、系統健康、模型表現、訂閱方案與政策限制，從可支援模型中選擇。對付費方案，GitHub 目前也列出在支援的 Copilot 介面使用 Auto 時，可享 模型成本 10% 折扣。
但 Auto 並不是回歸測試的替代品。
如果你的流程依賴某個模型非常固定的輸出習慣，那麼 Auto 反而會增加模型行為變動的可能性。比較合理的做法是：需要高可用性、可以接受模型變化的工作使用 Auto；需要固定行為的關鍵流程則使用經過測試的指定模型，並準備第二個 fallback。
30 分鐘可以做完的遷移盤點
在 10 月 2 日之前，小團隊不需要重做整套 AI 編程系統，也能先完成一次基本盤點：
- 在 repository、腳本與內部文件中搜尋這四款即將淘汰的模型名稱。
- 檢查 Business / Enterprise 的模型政策是否已啟用推薦替代模型。
- 挑 10–20 個目前真的會使用舊模型的代表性編程任務。
- 用同一批任務測試 GitHub 建議的替代模型。
- 記錄可直接接受的結果比例、重試次數、延遲與人工修正時間。
- 通過任務測試後，再修改固定模型引用。
- 為重要流程寫下一個 fallback 模型；不需要固定模型的地方再考慮 Auto。
- 在 2026 年 10 月 2 日之前重新確認一次。
對 Agent 型編程尤其重要。模型變更影響的可能不只是最終答案，而是整個規劃、工具呼叫、修改檔案與錯誤恢復方式。
誰應該最先處理？
正在固定使用 Gemini 3.5 / 3.6 Flash 的團隊
如果共享工作流明確指定這兩款模型，現在就值得開始測試 Gemini 3.8 Flash。TowCue 已整理過 Gemini 3.8 Flash 的編程與 Agent 取捨，可以直接作為遷移背景。
用 Claude Opus 4.7 處理高難度編程的團隊
先拿最難的一批真實任務測 Opus 5。不要把「官方推薦」理解成 Prompt、工具使用與結果品質必然完全相同。
Copilot Business / Enterprise 管理員
先確認模型政策，再讓開發者搬遷。某款模型在 GitHub 技術上受到支援，不等於你的組織政策一定允許它。
一直使用 Auto 的個人用戶
直接受到淘汰的風險相對低，因為 Auto 本來就會從仍受支援的模型中選擇。但仍要知道，回覆背後實際使用的模型可能改變；生產程式碼依然需要人工審查。
哪些事情不要做？
不要等到 10 月 2 日才一次性搜尋替換所有模型名稱。
不要假設替代模型的價格、延遲、Prompt 行為與舊模型完全相同。
不要在沒有檢查資料、合規與模型政策的情況下，直接為整個組織開啟一款新模型。
也不要讓長期 Agent 工作流只有一個固定模型，卻沒有 fallback。GitHub 的官方支援文件已明確寫明，模型可用性本身就可能隨時間變更。
TowCue 觀點
這次公告作為「新品新聞」並不算大，但作為 AI 編程工作流的風險提醒很有價值。
AI coding stack 正快速變成 多模型、短生命週期的系統。真正的工程問題已經不只是「今天哪個模型最好」，而是：當今天使用的模型下個月改名、漲價、被替代或停止服務時，你的工作流能不能繼續運作？
TowCue 會把 10 月 2 日的期限當成建立三個習慣的機會：
- 模型設定可配置化：不要把模型名稱藏在程式與文件深處。
- 保留小型回歸測試集：每個重要 AI 編程流程都留一組真實任務。
- 明確定義 fallback：可以是第二款測試過的模型，也可以在適合的情境使用 Auto。
做到這三點之後，模型淘汰就不再是緊急事故，而只是一次普通的依賴更新。
研究來源
- GitHub Changelog — Upcoming deprecation of selected GitHub Copilot models（2026/09/03）
- GitHub Docs — Supported AI models in GitHub Copilot（2026/09/05 查核）
- GitHub Docs — About default availability of Copilot models（2026/09/05 查核）
- GitHub Docs — About Copilot auto model selection（2026/09/05 查核）
- GitHub Docs — Models and pricing for GitHub Copilot（2026/09/05 查核）