# 還在糾結選哪個模型寫程式？GitHub 官方出來拆台了：選模型這件事，根本不該由你來選 這是 GitHub 官方更新日誌 2026 年 10 月 28 … · @swordBluesy · TwKit

@swordBluesy

# 還在糾結選哪個模型寫程式？GitHub 官方出來拆台了：選模型這件事，根本不該由你來選 這是 GitHub 官方更新日誌 2026 年 10 月 28 日的正式發布（經 Omid Saffari 整理、2026 年 10 月 29 日核對文件後寫成教程），標題直譯是《GitHub Copilot Fusion：它怎麼運作、何時該用》。先把結論放在前面，因為它反常識： **選 Copilot Fusion，不是選一個新模型，而是把「選模型」這件事交出去——你只選用力程度（Standard、High、Max），剩下的路由（routing，按任務特性把工作分給合適模型的機制）與協調（orchestration，多個模型分工、互審、再整合的機制）由它在一次對話裡自己決定。** 先說清詞。**Copilot Fusion**，是 GitHub Copilot 裡的模型路由與協調系統，不是某個單一模型的名字；**effort level（用力程度）**，是你告訴系統這次任務值得花多少推理與審查力氣，分 Standard（日常）、High（較難任務）、Max（最 demanding 的任務）三檔；**cascade（串聯）**，是一個模型起草、由評判者決定接受或升級重做的流程；**critique（評議）**，是草稿先被獨立批評、作者再修改的流程；**AI credits（AI 點數）**，是 GitHub 對 Copilot 用量計價的單位，按各模型實際消耗的 token（詞元，模型計價與輸入輸出的基本單位）換算。 一個真實例子：改一個標籤文字，和調查一個競態條件（race condition，多個流程搶同一份資源、結果看誰先跑到的那類 bug），不該得到同一套待遇。前者一個模型直做就夠，後者值得起草、評議、升級多走幾輪——Fusion 的工作，就是替你做這個分配，而不是讓你每個任務都手動換模型。 他們還點名了一種「眼熟的用法」：遇到難任務就切到最強模型，任務做完忘了切回來，之後每個小任務都在燒最貴的模型。GitHub 引用的 AT&T 工程師說法正好戳中這點：Fusion Standard 幫團隊省 token，省的不是某一次呼叫，而是「切過去就忘記切回來」這個習慣。 先把話說全：Fusion 仍然有不該用的時候，符合下面任何一條，就該把模型定死、不要路由： - 你需要固定模型做對照實驗、做可重現的調查； - 你的工作流程明文核准了某個模型； - 你要求離線工作——Fusion 的路由仍在雲端進行，本地模型預覽也不等於離線。 但除此之外，每天反覆「該用哪個模型」的人，正是 Fusion 要服務的人。 ## 一、開發者選模型的四種翻車方式 - **每題都用最強模型**：小任務也付大模型的帳，成本與等待時間雙雙浪費。 - **切過去忘記切回來**：一次難題之後，後面所有任務都留在高檔位，帳單悄悄變貴。 - **憑感覺換模型**：換了模型也不知道有沒有變好，因為從來沒有同一任務、同一驗收標準的對照。 - **把基準分數當成自己的節省**：GitHub 說 Fusion Max 在 Artificial Analysis Coding Agent Index（第三方程式 Agent 評測指數）拿到 60 分，只比 Claude Code 配 Opus 5.5 Max 的 62 分低 2 分，平均 API 成本約一半、耗時約少 40%——這是 GitHub 引用的基準說法，不是你倉庫的實測結果。 ## 二、替代方案：先定用力程度，再讓系統分配 Fusion 把 HydraFusion 計畫的多模型協調，和 Copilot 原有的自動選模型邏輯合併成一套。舊的 Auto、HydraFusion、HydraFusion Max 選項會對應過渡到新的用力程度檔位；舊的 HydraFusion 實驗開關不再是正確的開啟方式，客戶端要先更新。 用力程度的選擇邏輯很直白：Standard 做日常編碼與小幅有邊界的修改；High 給跨多個檔案、有可重現失敗的 bug 修復；Max 留給有多種互相競爭的解釋、值得深挖的困難故障。一個含糊的「把整個應用改好一點」不適合拿來試 Max——你連成功長什麼樣都沒定義，根本量不出多花的推理有沒有用。 ## 三、目標形態：你定任務與驗收，系統定模型組合 目標形態是三權分立：你負責寫清任務、寫清預期行為、寫清驗收標準；Fusion 負責在一次對話裡決定單模型直做、串聯評判還是多方評議；你最後負責看完整份 diff（差異比對）、跑驗收，決定接受或打回。模型組合不是承諾：官方文件不公布固定不變的完整模型名單，實際可用模型受你的方案與管理政策限制，回答下方可以查看該次實際用了哪些模型；企業管理員則可以在 AI controls → Copilot → Models → Configure Copilot Fusion models 裡限定 Fusion 可用的模型池。 ## 四、遷移步驟：一個倉庫、一週試完 ### 第一步：試之前先寫驗收 挑一個你熟的倉庫，準備三種任務：一個小修改、一個可重現的多檔 bug、一個有邊界的重構。先寫好驗收檢查，包含「哪些行為絕對不能變」，並從同一個起始提交為每種配置各開一條分支。 ### 第二步：從 Standard 開始，對照舊配置 在 Copilot App 裡點提示框下方的模型名稱，開啟 Copilot Fusion 並選一個用力程度；在 VS Code 裡先確認 `chat.copilot.dynamicAutoTiers.enabled` 已開啟，再用 Copilot harness（把模型接到 Agent 工具的執行環境）開新對話、選 Copilot Fusion；在 Copilot CLI（命令列版 Copilot）互動對話裡輸入 `/model` 選 Fusion 與檔位，或用有邊界的唯讀指令先試水，例如 `copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."`（解釋這個倉庫怎麼跑測試，不要改檔案）。同一份任務簡介，先後跑舊配置與 Fusion Standard，記下用力程度、顯示的模型、耗時、你花了多少審查時間、補了幾次提示、有沒有接受。 ### 第三步：算整次嘗試的總帳 把失敗嘗試與修正提示的用量也算進去。個人用戶看 Billing and licensing → AI usage（帳單與授權 → AI 用量），企業用戶看 Copilot 設定裡的 Usage（用量）。網站通常無法把每一點數精確歸屬到某一次提示，所以要自己記任務日誌。最後算「每個被接受的改動花了多少點數」：總點數（含失敗）除以被接受的改動數；一個都沒被接受，就老實記下零，不要算出一個誤導人的平均值。 ### 第四步：看完 diff 再定預設 只有當 Fusion 確實減少了修正或等待、且用量可接受時，才把它設為預設；否則繼續手動選模型。一個可讀的決策紀錄，比一張「最快回應」的截圖有用得多。 ## 五、團隊怎麼共建同一套用力標準 團隊預設規則可以寫成一句話：日常用 Standard，需要審查的範圍修改用 High，Max 只憑刻意決定開啟，並且每次升級都要留下「升級幫了什麼」的紀錄，否則「選最高檔」很快會變成不需理由的習慣。計價上要講清：Fusion 本身沒有額外的協調費，費用跟著各模型實際用量走，輸入、輸出與快取 token 按模型計價再換算成點數；付費方案用戶在 2026 年 11 月 30 日前享有 Fusion 模型費用 30% 折扣——但折扣是促銷，基準分數是基準，兩者不能拼成「保證省一半」的承諾。 ## 六、官方工具包 GitHub 官方文件與更新日誌就是工具包：Fusion 正式發布公告（2026 年 10 月 28 日，GitHub Universe 大會同日發布）、Fusion 概覽與行為文件、VS Code 設定文件、Copilot CLI 模型選擇文件、企業模型池設定、計價與用量文件。可用入口包括 Copilot App、VS Code、Copilot CLI、JetBrains IDE（JetBrains 出品的整合開發環境系列），且適用於各 Copilot 方案。還有一條必須知道的限制：被丟棄的草稿所做的檔案修改，不一定會自動被撤銷——所以無論哪個模型組合產出結果，完整審 diff 都是不能省的一步。 ## 結尾：原則比架構重要 路由的原則只有一句：**把選擇權交出去的前提，是驗收標準還在你手裡**。模型可以換，驗收不能換；用力程度可以升，任務定義不能含糊。可重複的動作規則是：每個新配置都用同一任務、同一驗收、同一記帳方式跑一次，算每個被接受改動的總成本，再決定預設——沒有對照的升級，只是換了一個更貴的習慣。 原文連結：https://omidsaffari.com/blog/github-copilot-fusion 原文：GitHub 官方更新日誌，經 Omid Saffari 整理（由 S1哥 編譯） ## S1哥觀點 這篇最狠的地方，是 GitHub 親自承認了一件事：過去一年大家學的「選模型」手藝，正在變成負資產。切模型、比模型、記哪個模型擅長什麼——這些本來是高手標誌，現在官方說，交給系統選，你只管把任務講清楚、把驗收寫死。 我認為真正的信號不在省錢那組數字，在那句「切過去忘記切回來」。多少人的 AI 帳單不是被難任務吃掉的，是被習慣吃掉的：一次切到最強，之後半年都在為小任務付大模型的錢。Fusion 值不值得用，根本不用吵基準分數，拿一個倉庫、一週時間、同一驗收跑一次就知道——跑不過舊配置，就繼續手動選，沒人欠你一個「必須跟上」的理由。 所以站隊問題來了：你現在是「每個任務都手動選模型」的人，還是「選完最強就忘記切回來」的人？評論區報一下你最常卡在哪個模型選擇上。

曝光 171 · 评论 1 · 点赞 1 · 书签 0