MAI Code 本機版與 HydraFusion：GitHub Copilot 如何分配本機與雲端工作？
MAI Code 與 HydraFusion 讓 GitHub Copilot 朝本機、雲端混合工作發展。本文核對預覽時程與模型條件，說明如何用完整任務比較品質、等待與資源。
開發者想降低 AI 費用，常會先問能不能把模型搬到自己的電腦。但模型放得下，並不代表整個寫程式流程都能離線完成。
Microsoft 與 GitHub 在十月七日介紹 MAI Code 1.1 Flash 的本機方案，以及讓 Copilot 分配本機、雲端工作的 HydraFusion。
值得準備的是一套完整任務的比較方法：看模型怎麼處理檔案、工具和長對話，而不只看回答速度。
截至十月九日，官方說明這項混合體驗預計在十月稍晚提供實驗性預覽。本文是依官方資料整理的匯入與驗收指南，沒有宣稱讀者現在已可在所有電腦啟用。
本機推論、任務分配與工具執行是三件事
本機推論，是模型在你的裝置上處理輸入並產生回答。任務分配，是系統決定哪些工作交給本機或雲端。工具執行，則是代理讀寫檔案、執行命令或連線服務。
三者可能發生在不同地方，所以選了本機模型，不能直接推論整個工作都不會連網。
這個差異會影響實際決策。例如你讓代理修改一個網站，本機模型可以生成程式碼，但安裝依賴仍可能需要套件網站，遠端 MCP 仍可能連到外部服務，版本控制也可能推送到雲端。
若你的目的是降低推論費用，就測費用與完成率。若目的是資料留在內部，就必須逐一檢查各條資料路徑。
HydraFusion 的方向，是讓 Copilot 可以協調模型與執行環境。官方介紹自動選擇，以及明確選擇本機模型兩種方式。
你可以把前者理解為交給系統排程，後者理解為自己指定供應者或端點。哪一種較適合，應由任務需求決定，不能只以「自動比較聰明」作為理由。
MAI Code 本機版為什麼需要看記憶體？
官方把 MAI Code 1.1 Flash 描述為混合專家模型，總引數與每次啟用的引數不同。本機版本採用量化等方法縮小需求。
這能降低負擔，但模型權重只是記憶體的一部分，作業系統、應用程式與對話累積的快取都需要空間。
因此，一臺電腦能載入模型，和它能一邊開發、一邊處理長任務，是不同的標準。瀏覽器、編輯器、測試服務與設計軟體同時開啟時，剩餘資源可能少很多。
採購或部署前，應使用接近同事日常工作的環境測試，不要只在剛開機、沒有其他程式的狀況下看結果。
量化則可以理解為用較省空間的表示方式儲存模型資料。它可能改變品質，所以要看實際程式任務是否完成。一次錯誤的識別名稱或工具引數，就可能使整個修改失敗。
官方比較結果可以作為線索，但自己的專案語言、套件與測試仍是匯入判斷的主要依據。
先選三種工作，建立自己的比較組
第一種是小範圍修改。挑一個沒有敏感資料的專案，要求代理修正一個表單訊息或簡單函式。任務應有清楚的完成條件，例如指定畫面顯示正確文字、既有測試透過，且只修改相關檔案。
這組能看出日常小工作的反應與穩定度。
第二種是需要找線索的錯誤。提供錯誤訊息與重現步驟，要求代理先定位原因，再修改。這組不要預先把答案塞進提示詞，否則測到的只是照抄能力。
保留相同的專案狀態與輸入，才能公平比較本機與雲端是否找到相同問題。
第三種是較長的跨檔案任務。選擇一個已有明確規格的小功能，涉及幾個相關檔案，但避免把整個系統重寫當成測試。
觀察代理是否記得前面的要求、能否處理測試回饋，以及接近完成時是否仍維持相同品質。這組比較能反映長對話與記憶體壓力。
比較時，把完成率放在速度前面
每種工作都使用同一份起始副本。先記錄模型、工具版本、硬體與其他正在執行的程式，再開始計時。完成後，由同一套測試與人工檢查判斷結果。
若一組只花三分鐘但功能錯誤，另一組花五分鐘卻能交付，不能只按時間把前者排第一。
可以用一張表記錄：任務名稱、是否完成、修改檔案數、需要人工介入次數、總時間與推論用量。另記錄載入時間與長對話的等待，因為它們會影響每天的使用感受。
測試只跑一次容易受偶然因素影響，重要任務可以在相同條件下重複少量次數，再看差異是否穩定。
對程式任務而言，輸出長度也會影響數字。快速產生一大段無用程式，不等於完成工作更快。可以要求代理只說明必要資訊，並將新增功能與測試結果分開。
比較時看完整任務走完的時間，會比每秒文字數更接近日常成本。
自動排程模式要觀察哪些資訊？
自動模式的重點，是讓系統依任務選擇適合的處理位置。你仍需知道哪些資訊可被送到雲端，是否有組織政策，以及失敗時如何回復。實際介面能顯示哪些路由與用量資訊，應以預覽版本為準。
未確認前，不應在內部檔案寫成所有工作都會優先使用本機。
如果你希望特定資料只在內部處理，可以先把這項需求轉成可驗證的條件：禁止哪些外部端點、允許哪些工具、是否需要離線完成，以及誰能調整政策。單寫一句「請保密」不能建立技術邊界。
排程方便與資料控制需要同時設計，兩者不會自然等同。
團隊也可先選低敏感工作試用，例如公開專案的整理或測試報告。確認工具行為與觀測方式後，再評估其他任務。如果預覽功能缺少你需要的記錄，不必急著把重要工作搬過去。
先保留雲端或既有方案，等待功能符合條件即可。
明確指定本機模型時，先驗證連線邊界
官方描述本機模型選擇可涉及 Windows ML 供應者與相容端點。使用者應確認端點所在位置、模型名稱與認證方式，而不是只看到「本機」兩字就開始操作。
若服務開在自己電腦的回環位址，和服務開在整個辦公室網路上，存取範圍會不同。
第一次連線可以先用不含私人資料的短請求，確認模型有回應，再嘗試只讀的檔案工作。記錄錯誤時保留必要的狀態與訊息，避免把完整憑證放入聊天或工單。
設定失敗先查官方支援範圍與版本，再檢查網址、服務狀態與可用模型。
當測試開始涉及修改檔案，請使用專案副本或分支。模型服務正確回應，只證明推論路徑可用，沒有證明代理的檔案許可權合理。讓它先完成一個小修改，檢視變更，再進入較長任務。
這能把連線問題與程式品質問題分開診斷。
本機呼叫沒有推論費，不代表整個方案零成本
Microsoft AI 在 X 宣傳本機模型呼叫沒有推論收費。這與 Copilot 方案、硬體採購、電力、維護以及仍使用的雲端呼叫，是不同專案。
計算時應把它們分開，而非把一個宣傳句延伸成所有工作免費。尤其硬體主要為 AI 購買時，不能忽略折舊與維修。
一個簡單方法，是先記錄目前每月相關工作量與人工時間。接著估算新方案中仍需要的雲端費用，以及維護服務的人力。若工作量很少，既有電腦加雲端服務可能已經足夠。
若有大量穩定任務，才更有理由測試本機能否持續降低成本。
同樣要看品質是否改變。模型省下推論費，但每次需要人工修復半小時，總成本未必下降。把人工介入次數與修復時間一起記錄，才能理解節省來自哪裡。對團隊而言，可預測的交付通常比偶爾非常快更有價值。
工具隔離仍要另外設定
代理可能執行的命令，比模型本身更直接影響電腦。官方介紹 Copilot 與 MXC 的沙箱整合，但不同工具的邊界並不完全相同。
部署時應閱讀對應版本的工具政策，不要把所有檔案讀取、遠端服務與子程式一概視為相同隔離。
測試可從三項許可權開始：工作副本可寫、來源資料只讀，以及必要以外的網路不開放。先跑一個正常工作，再用無害的測試檔確認超出範圍的操作會被阻止。
若碰到合理需求被擋住，應調整具體資源，而非直接放寬整個使用者目錄。
每天的自動化也應留下結果。比如測試是否成功、報告是否寫到正確位置，以及工作是否卡在許可權。自動排程降低了選模型的負擔，不能取代對自動化結果的檢查。
需要人做決定的地方，應在工作流程中保留清楚的停止點。
常見問題：現在是否應該換電腦？
只因為公告出現就換機，證據還不夠。先確認功能推出時間、支援裝置與自己的工作量，再安排試用。官方測試是在特定硬體、模型與設定下取得的結果，不能保證既有筆電會有相同表現。
若目前瓶頸是需求不清或測試不足，換模型與硬體也不會直接解決。
比較理想的匯入結果，是小任務可以穩定完成，長任務的品質與等待可接受，而資料路徑與維護責任都能說清楚。未達到這些條件時，可以先保留觀察與試作。
當預覽功能真正可用，再用同一組工作比較，才有可靠的前後依據。
寫一份同事可以重做的試用紀錄
每次比較都保留起始版本與提示詞。只記錄「修得比較好」很難讓另一個人確認。可以先用一個包含錯誤的表單函式，要求輸入空白時顯示正確訊息，再記錄模型找到哪些檔案、修改什麼，以及測試結果。
下一次換模型時，同一份工作就能成為比較基準。
人工檢查也應固定範圍，例如是否誤改付款邏輯、是否加入多餘依賴，以及錯誤訊息是否保留原本語言。若每次由不同人用不同標準打分，模型差異就可能只是評審差異。
第一次只需少量明確規則，之後有新問題再補。
比較表可以保留「不適用」欄位。像是某條本機路徑尚未開放、裝置不支援或服務沒有需要的工具，應直接記錄條件。不要為了湊完整比較，把尚未可用的功能算成失敗，也不要使用別人的速度代替自己的結果。
最後把未解決問題列在下一次試用的起點。若主要差異來自長對話，就增加一組長任務。若主要差異來自工具錯誤，就先檢查工具版本。每輪只回答新的問題，才能讓比較持續累積，而不是重新做一堆相同測試。
