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 拥有者大概也会有类似动作——那么竞争战场就不再是”排行榜上最好的模型”，而变成”已经坐在开发者工作之处、最便宜且堪用的模型”。独立模型供应商应该为这样一个世界做准备：默认位置被占据，而他们的切入点是那个小型默认模型做不到的困难任务——而不是它如今免费就能完成的日常任务。