GitHub Copilot 的模型清單越來越長，開發者每天要面對一個很現實的問題：這次聊天、修 bug、解釋錯誤或改一小段程式，到底該交給 Auto mode，還是手動挑一個小型或高推理模型？
GitHub 2026-06-17 宣布，Copilot Chat 的 Auto mode 對所有 Copilot 方案開放，使用場景包含 github.com 與 GitHub mobile app。加上 5 月 VS Code 已更新任務式自動選模型（task-based Auto model selection），Copilot 的模型選擇正在從「人手動挑模型」走向「依任務與政策自動路由」。
隔天 GitHub 又宣布 MAI-Code-1-Flash 擴大到更多 Copilot 入口：可用於 GitHub Copilot app，以及 github.com 上的 Copilot Chat。GitHub 稱它是 Microsoft 為程式任務打造的小型模型，先向 Copilot Free、Student、Pro、Pro+、Max 的部分使用者分批開放，Copilot Business 與 Enterprise 之後才會支援。
對個人開發者，重點是少花時間猜模型，同時知道什麼時候該切到更強模型。對團隊管理者，重點是把 Auto mode、MAI-Code-1-Flash 這類小型模型、資料政策與品質回饋流程放進同一張分流表，避免把模型選擇當成單純的介面開關。
如果你還在整理 Copilot 方案、CLI、Agent 模式與基本費用，可以先看站內的 GitHub Copilot CLI：費用與 Agent。這篇聚焦 Auto mode GA 後，Chat 與 VS Code 內自動選模型該怎麼用、怎麼管。
先回答：Auto mode 現在改了什麼？
| 問題 | 目前答案 | 導入含意 |
|---|---|---|
| 哪裡可用？ | GitHub 最新更新公告指向 github.com 與 GitHub mobile app 裡的 Copilot Chat；VS Code 的自動選模型已在 5 月更新。 | 導入時要把 GitHub 網頁與手機上的 Chat 一起納入模型路由，避免只檢查 IDE 設定。 |
| 誰能用？ | GitHub 說 Auto mode 對所有 Copilot 方案開放。 | 個人與團隊都會遇到「預設用 Auto 還是手動指定模型」的選擇。 |
| MAI-Code-1-Flash 改了什麼？ | GitHub 6 月 18 日公告說，MAI-Code-1-Flash 現在可用於 GitHub Copilot app 與 github.com 上的 Copilot Chat；Free、Student、Pro、Pro+、Max 先分批開放，Business 與 Enterprise 稍後支援。 | 小型程式模型（coding model）會延伸到日常 Chat 與代理工作流的任務分流，不能只留在 IDE 設定表。 |
| 怎麼選模型？ | 依請求複雜度、即時模型可用性與政策設定路由。 | 團隊要先定義哪些任務可交給 Auto，哪些任務應固定模型或人工審查。 |
| 費用怎麼看？ | GitHub 表示付費訂閱者使用 Auto 有 10% 折扣；5 月 VS Code 更新提到 Auto 當時限制在 0x 到 1x 模型倍數。 | 它可能降低單次模型消耗，但總帳仍要看使用量是否增加。 |
| 使用者能否介入？ | 可以看見回應用了哪個模型，也可逐次切回指定模型。 | Auto 適合做預設選項；高風險任務仍應保留人工指定與審查。 |
它怎麼選模型？看任務、可用性與政策
GitHub 在 6 月的 Copilot Chat 更新公告說明，Auto 會根據請求複雜度與當下模型可用性選模型。官方舉例，它可能依方案與政策路由到 Claude Sonnet 4.6、GPT-5.4 mini、GPT-5.4、Haiku 4.5 等模型；GitHub 也提醒，Auto 會路由到的模型會隨時間改變。
MAI-Code-1-Flash 補上的是另一個決策點：當使用者可以手動選小型程式模型時，不該只用「快」或「便宜」判斷。GitHub 文件把 MAI-Code-1-Flash 歸在 general-purpose coding and writing（一般程式與寫作）以及 fast help with simple or repetitive tasks（簡單或重複任務的快速協助）這類場景；高風險重構、權限、資料庫與安全議題仍需要更保守的模型政策與人工審查。
5 月的 VS Code changelog 補充了更細的判斷訊號：
| 判斷訊號 | 可能影響 |
|---|---|
| 即時可用性（real-time availability） | 避開當下不可用或延遲高的模型。 |
| 可靠度訊號（reliability signals） | 選較穩定的模型。 |
| 推理需求（reasoning need） | 複雜問題分配給較強模型。 |
| 程式生成複雜度（code generation complexity） | 大型修改、新功能或跨檔生成需要更高能力。 |
| 錯誤診斷難度（bug diagnosis difficulty） | Debug 通常比單純補全更需要推理。 |
| 工具協作需求（tool orchestration needs） | 需要工具、檔案或代理流程時，選更適合的模型。 |
使用者仍可把 Auto 改回指定模型，也能在回應上查看實際使用的模型。企業版要特別注意：GitHub 明確說 Auto 會遵守使用者與管理員設定，因此 GitHub Copilot Model Rules 企業模型治理 需要先整理好可用模型、repo 敏感度與例外流程。
費用與 token：10% 折扣該怎麼解讀？
GitHub 6 月更新公告的關鍵句很短：付費訂閱者使用 Auto 會有 10% 折扣。5 月 VS Code 更新公告則提供了當時的進階請求（premium request）例子：Auto 會依實際選到的模型計費，並且當時限制在 0x 到 1x 模型倍數（model multiplier）範圍內；若 Auto 選到 1x 模型，付費使用者消耗 0.9 個 premium requests，而手動選 1x 模型會消耗 1 個。
| 使用情境 | 單次消耗方向 | 管理重點 |
|---|---|---|
| Auto 選到 0x 模型 | 可能不消耗 premium request | 適合短問答、解釋錯誤、低風險小修改。 |
| Auto 選到 1x 模型 | 付費使用者享 10% 折扣；5 月官方例子是 0.9 個進階請求 | 適合一般錯誤診斷（bug diagnosis）、小型重構（refactor）與日常 Chat。 |
| 手動指定昂貴模型 | 依該模型原本倍數計算 | 適合架構決策、安全敏感分析或需要固定輸出品質的任務。 |
| Auto 讓使用量變多 | 單次較省，但總帳可能上升 | 要看月度用量、團隊採用率與任務分級。 |
所以管理者不要只看「每次比較省」。更好的做法，是把 Auto mode 視為預設路由，再用進階請求報表、用量指標（Copilot usage metrics）與任務類型對照表看總成本。如果你正在處理雲端代理（cloud agent）或多模型成本分流，可延伸閱讀 GitHub Models 退場後的 Copilot cloud agent 省錢模型分流。
MAI-Code-1-Flash 該放在哪一層？
MAI-Code-1-Flash 最適合補在「低風險、可快速驗證」那一層；它不適合替代所有模型選擇。你可以把 Copilot 模型決策拆成三種入口：
| 使用情境 | 建議入口 | 驗證方式 |
|---|---|---|
| 不確定任務難度、想少花時間挑模型 | 先用 Auto mode | 看 Copilot 實際選到哪個模型、答案是否需要升級、premium request 是否異常增加。 |
| 文件整理、小函式說明、低風險測試補強、重複性程式任務 | 可試 MAI-Code-1-Flash；如果你的方案與入口尚未開放，就先保留 Auto 或既有模型。 | 限制在小 diff、可回滾、容易 review 的任務，觀察回答品質與修正率。 |
| 架構決策、跨檔重構、安全敏感程式碼、資料庫 migration、客戶資料 | 固定政策允許的高推理模型，保留人工審查。 | 要有測試、雙人 review、回滾方案與稽核紀錄。 |
這個分法也能避免團隊誤用小模型。MAI-Code-1-Flash 的價值在於降低簡單任務的摩擦；如果任務失敗會牽動資料、權限、金流或跨服務契約，模型速度不應該成為主要決策理由。
哪些任務適合先交給 Auto？
Auto mode 的價值，在於把不值得反覆思考模型名稱的任務自動化。以下分級比「全部開或全部關」更實用。
| 任務 | 建議 | 原因 |
|---|---|---|
| 解釋錯誤訊息、閱讀 stack trace | 先用 Auto | 任務明確，容易從答案品質判斷是否需要升級模型。 |
| 小段函式生成、測試補強、lint 修正 | 先用 Auto；MAI-Code-1-Flash 可用時可列入低風險試驗 | 成本敏感、重複性高，適合觀察模型路由與小型模型品質。 |
| 一般 bug diagnosis、小型 refactor | Auto 起手，必要時改指定模型 | 先讓 Auto 處理初稿，再用人與測試驗證。 |
| 跨檔架構重構、資料庫遷移、安全敏感程式碼 | 固定政策允許的模型，保留人工審查 | 風險來自決策與副作用，成本折扣不該主導選擇。 |
| Copilot app 或 cloud agent 長任務 | 搭配任務邊界、成本上限與模型白名單 | 長任務會放大錯誤路由與工具權限問題，小型模型只適合其中可驗證的子任務。 |
如果團隊也在評估 GitHub Copilot app GA 或 Copilot Agent tasks REST API，Auto mode 應放進同一張導入表：Chat 問答、IDE 小修改、桌面代理工作階段與雲端代理任務，成本與風險完全不同。
企業導入：先設三個控制點
1. 先把模型政策寫清楚
Auto mode 會遵守管理員設定，但前提是政策存在。至少要先定義：哪些 organization 可以用哪些模型、敏感 repo 是否限制模型、哪些任務必須手動指定模型、誰能批准例外。
2. 把成本看成「單次折扣 × 使用量」
10% 折扣只解決單次請求的成本。若 Auto mode 讓更多人開始把 Copilot Chat 當成預設入口，月度用量仍可能上升。建議每週看三個指標：premium request 消耗、活躍使用者、需要人類返工的回應類型。
3. 建立「何時切回指定模型」的回饋流程
Auto 的好處是省心，但團隊仍需要回饋規則。例如：回答明顯漏掉 repo 約束、產生危險 migration、修 bug 卻無測試、或安全議題只給泛泛建議時，開發者應切回指定模型並記錄案例。這會讓管理者知道 Auto 適合哪些任務，也能避免把品質問題誤判成單一使用者操作失誤。
7 天低風險試跑清單
| 天數 | 要做的事 | 驗證方式 |
|---|---|---|
| Day 1 | 開放 3–5 位開發者在 github.com 與 mobile app 的 Copilot Chat 使用 Auto，並確認帳號是否已看到 MAI-Code-1-Flash。 | 確認每個人都知道如何查看實際模型、如何切回指定模型、哪些入口仍未開放。 |
| Day 2 | 選低敏感 repo 的日常問題：錯誤解釋、測試補強、文件整理。 | 記錄 Auto 回答是否可直接採用；若改用 MAI-Code-1-Flash，也要記錄是否需要升級模型。 |
| Day 3 | 把任務分成低風險、需審查、高風險三類。 | 高風險任務不得只靠 Auto 回答做決策。 |
| Day 4 | 檢查 premium request 與活躍使用者變化。 | 看單次折扣是否被使用量成長抵消。 |
| Day 5 | 對照 model policies 與敏感 repo 清單。 | 確認 Auto 沒有讓使用者誤以為所有 repo 都可用同一套模型。 |
| Day 6 | 收集失敗案例：答非所問、過度簡化、忽略測試、成本異常。 | 建立「切回指定模型」規則。 |
| Day 7 | 決定擴大、維持小範圍或回收。 | 用成本、品質、返工時間與政策風險一起判斷。 |
結論：Auto mode 適合當預設，但不要取消人類判斷
GitHub Copilot Auto mode GA，加上 MAI-Code-1-Flash 擴大到 Copilot app 與 GitHub Chat，代表 Copilot 的模型選擇正在變成一套可治理的模型路由系統。Auto 能減少日常選模型的摩擦，小型程式模型能處理低風險重複任務，10% 折扣則只解決部分 premium request 消耗。
真正要管理的是任務風險、模型政策、資料邊界、總使用量與回應品質。Mason 的建議是：低風險 Chat 和小型程式任務先用 Auto 或 MAI-Code-1-Flash 試跑，高風險架構、安全、資料與長任務代理流程仍保留指定模型、人類 review 與可回滾流程。這樣 Auto mode 和小型模型會比較像成本與效率工具，少一點難以解釋的黑盒風險。