2026-06-08 — views

微軟把自家程式碼模型送進 GitHub Copilot：MAI-Code-1-Flash 對開發者的意義

為什麼值得讀如果你成天泡在 GitHub Copilot 裡，本週游標下的預設模型可能已悄悄換掉了。以下是實際推出的內容，以及如何辨認。

微軟在 Build 2026 把一個 5B 自研程式碼模型放進 VS Code，並推出一個 35B 推理模型——兩者都未經 OpenAI 蒸餾訓練。

推出了什麼

6 月 2 日於舊金山舉行的 Build 2026 上，微軟做了一件前所未有的事：它把一個完全自研、未從任何第三方模型（包括 OpenAI 的）蒸餾的基礎模型，直接放到 VS Code 中 GitHub Copilot 使用者的游標下。

共宣布了兩個模型。大多數開發者最先接觸到的是 MAI-Code-1-Flash，這是一個 50 億參數的程式碼模型，當天即開始作為 Visual Studio Code 的預設模型之一陸續上線，並同時出現在模型選擇器與自動（「auto」）選擇器中。主題演講指出初期推送涵蓋約 10% 的使用者。第二個是 MAI-Thinking-1，一個稀疏混合專家（Mixture-of-Experts）推理模型，具有 350 億啟用參數（微軟稱總參數約一兆）以及 256,000-token 的上下文視窗——該公司表示，大到足以一次讀完一份 600 頁的文件。這個模型透過 Microsoft Foundry 進行私有預覽，並同時經由 OpenRouter、Fireworks 與 Baseten 發布。

對從業者而言，重點不在參數數量，而在於這個小模型被定位為日常代理式編程的更便宜、更精簡的預設選項，而且它已經進駐數百萬人每天早上都會打開的工具裡。

微軟端上檯面的數字

微軟主要將 MAI-Code-1-Flash 與 Anthropic 的 Claude Haiku 4.5 對標——這是一場「小而快」的同級比較，而非前沿對前沿的炫技。

指標	MAI-Code-1-Flash	對標點
參數量	5B	—
SWE-Bench Pro	51.2%	Claude Haiku 4.5：35.2%
SWE-Bench Verified 上的 token 使用量	最多少 60%	相較於先前作法
指令遵循（IF Bench）	領先 +28.9 分	相較於 Claude Haiku 4.5
MAI-Thinking-1，AIME 25	97%	—
MAI-Thinking-1，SWE-Bench Pro	53%	—

「最多少 60% token」這項宣稱是我會圈起來的。對於一個本就要在互動迴圈中運行的小模型——自動補全、代理步驟、反覆的工具呼叫——token 效率會複利累積。更少的 token 意味著每步更低的延遲與每項任務更低的成本，微軟將此總結為提升「token 的投資報酬」。一個在 SWE-Bench Pro 拿下 51%、同時花費明顯更少 token 的 5B 模型，足以作為大量日常編輯這條長尾的可信預設選項——即便面對最難的那 5% 時你仍會去搬出更大的模型。

為什麼這是開發者的故事，而不只是微軟的故事

如果你要交付軟體，有三件事值得在意。

第一，預設模型變了。如果你使用 Copilot 的自動模型選擇，現在你的一部分補全可能會繞道一個微軟模型，而非你以為正在運行的那個。在你為某個行為變化除錯、卻歸咎於自己的 prompt 之前，這點值得先知道。

第二，「無蒸餾」的論述是一種採購訊號，而非行銷空話。微軟反覆強調其「企業級、乾淨且具商業授權的資料來源」，且未從第三方模型進行任何蒸餾。對於處於受監管或對智慧財產敏感情境的團隊而言，訓練資料的來源出處日益成為採購準則。一個供應商願意為其資料來源背書的模型，比不願背書的更容易通過法務審核。

第三，戰略背景是真正的多元化。據 TechTimes 報導，這緊接在 2026 年 4 月微軟與 OpenAI 合作協議的一項修訂之後，該修訂終止了微軟對 OpenAI 智慧財產的獨家授權。微軟並未拋棄 OpenAI——Azure 仍提供那些模型——但它如今把 Foundry 定位為一個凌駕於模型選擇之上的協調層，並將自家第一方模型作為眾多選項之一。對開發者來說，曲線小端有更多可信的第一方選項，通常意味著價格的下行壓力，以及在供應商談判中更大的籌碼。

值得點明的隱憂

5B 模型不是前沿模型，而微軟挑選對標對象時很有心機：Claude Haiku 4.5 是一個小而便宜的級別，並非旗艦。在 SWE-Bench Pro 上勝過它，就同級別而言是貨真價實的成績，但它完全沒告訴你 MAI-Code-1-Flash 在棘手的多檔案重構上，相對於 Sonnet 級或 GPT 級模型表現如何。SWE-Bench 上的基準分數，也不見得能在面對一個雜亂的私有 monorepo 時存活下來。請把 51.2% 看作「這是一個強力的預設選項」，而非「這能取代你的重型模型」。

實務筆記

本週我實際會做的：打開 VS Code，檢查 Copilot 的模型選擇器，看看 MAI-Code-1-Flash 是否被提供、或已被我的自動選擇器選中。如果是，我會在日常補全與小幅編輯上保持啟用——token 效率這個賣點，正是一個快速小模型發揮價值之處——但我不會放任它默默處理架構層級或多檔案的變更。那些我會明確指定一個更大的模型。在信任任何供應商基準之前，我也會先跑自己的內部評測：從自家 repo 取一組固定的十張代表性工單，依通過率與 token 花費來評分，這在預測我真實成本上勝過任何 SWE-Bench 數字。至於 MAI-Thinking-1 預覽，除非我有一個具體的長上下文推理任務，且其商業授權的訓練說法確實能解決某個企業資料來源的需求，否則我會先放著不動。

被忽略的角度

每個人都把這件事解讀為「微軟對 OpenAI」。對開發者而言，更有趣的轉變是小型、自有的預設模型的崛起。當掌控 IDE 的公司同時也推出在其內部被自動選用的廉價模型時，代理式編程的經濟學就會位移：一次補全的邊際成本，會趨向於該宿主自身的推論成本，而非第三方 API 的利潤。這對掌握分發管道的一方有利。如果這個模式成立——第一方小模型被內建為 Copilot 各處的預設選項，並且其他 IDE 擁有者大概也會有類似動作——那麼競爭戰場就不再是「排行榜上最好的模型」，而變成「已經坐在開發者工作之處、最便宜且堪用的模型」。獨立模型供應商應該為這樣一個世界做準備：預設位置被佔據，而他們的切入點是那個小型預設模型做不到的困難任務——而不是它如今免費就能完成的日常任務。