用AI代码替换Windows里每一行C/C++！微软回应了

Jay 发自 凹非寺量子位 | 公众号 QbitAI

微软光速辟谣了。

Windows Latest消息，微软表示并未打算用AI重写Windows 11

这与此前内部杰出工程师，声称要用AI+Rust淘汰C/C++的言论大相径庭：

• 2030年，彻底消除微软代码中的每一行C/C++代码。策略是将AI和算法结合，重写微软最大的代码库。

路径图也相当粗暴——

• 一名工程师，一个月，一百万行代码。

该言论一经发布，迅速在互联网引起轩然大波。

有网友对微软拥抱AI的决断力表示佩服，但也有不少网友担心强推AI风险过高，称微软「异想天开」。

• 这样做只会给用户带来风险。就我个人经验而言，AI生成的代码，错误率远高于我手写的。

• 这就是新版Office 365漏洞百出的原因吗？

见事态愈演愈烈，点燃这一导火索的微软工程师火速公关，又给原文打了补丁。

• 澄清一下…Windows「绝」不是拿AI用Rust重写的。这只是我团队的研究项目。

微软光速辟谣

「一名工程师，一个月，一百万代码」，用Rust干爆C/C++，拿AI重写Windows 11。

这并非什么小道消息，而是微软杰出工程师Galen Hunt，在领英发布招聘帖时的激情发言。

此文一出，迅速在互联网上引起了轩然大波。不少网友质疑微软「不负责任」，完全是形式化地在追求所谓的「AI率」，而没有考虑到这样做可能带来的严重后果。

网友们担心的点在于：Windows的历史包袱实在太重，数百万行遗留代码中不知道有多少「碰巧可运行」的bug。重写后如果出现问题，想要找出病灶，无异于大海捞针。

还有网友指出，除了「质量」不可控，「速度」也不一定真的更快。

• 目前的AI技术距离交付如此高质量的代码还差了大约五个数量级，每十行代码一个bug。如果写一百万行代码，就意味着十万个bug。

确实，鉴于如今Vibe Coding的交付质量，微软有审核这「每个月一百万代码」的功夫，还不如找人手敲。

Galen或许也没想到，一条招聘帖竟会引发如此巨大的舆论轰动。他很快在原帖基础上叠了层甲，解释称发帖只是为了寻找理念一致的工程师，大家有些过度解读了。

• 看来我的帖子引起了比我预期更多的关注，很多人对我的帖子进行了各种猜测和解读……在此澄清一下，Windows并没有被用Rust重写并加入AI。
  这个研究项目，我们正在开发让不同编程语言之间迁移成为可能的技术。我发帖的目的，是寻找志同道合的工程师，而不是为Windows11+制定新战略，也并非暗示Rust是终点站。

但在此前那番「雄心壮志」的映衬下，这一解释难免显得些许苍白。

毕竟，当微软杰出工程师，Azure Sphere（微软IoT平台）领导者——Galen Hunt，开始公开使用「淘汰C/C++」「用AI重写代码库」等大胆字眼时，很难让人不怀疑这是微软内部已达成的某种共识。

更何况，Galen在帖子中频繁使用「我们」作为主语，仿佛真的是在代表微软发言。至少，内部应该是有相关支持声音的。

微软这只大象，不惜考虑用AI将旧的代码高墙全部推翻，也要掉头回去寻找的，究竟是什么？

触不可及的Rust，摸得着了

几十年来，内存安全漏洞一直是微软抠破脑袋也无法解决的问题。

为了方便理解，我们可以把电脑想象成一家公司。其中，系统是老板，程序是员工

在这家二进制公司里，员工上班前，需要先向老板申请一张工位，也就是内存，用来放电脑、处理数据、与同事交接。

每张工位都有明确使用规范。办公桌面积有限，所有员工只能用自己被分配的工位，下班后必须立刻归还。

如果员工不遵守这些规矩，硬是要超出预先的内存分配，跑去别人工位，甚至化身「老油条」，赖在新人的办公桌不走，就会打乱公司运转。轻则程序闪退、系统蓝屏，重则给黑客留下突破口。

针对这一问题，C/C++版员工手册的管理哲学是：我相信你不会出问题哒～

是的，C/C++不在乎程序是否遵守内存使用规范，只要能编译，它就放你过去。

2019年，微软公开承认，Windows系统中约70%的安全漏洞，其罪魁祸首正是C/C++

在此背景下，微软对Rust产生了兴趣。

与C/C++的放养式教育不同，Rust从第一天就为解决内存安全而设计。

万事起源于2006年。一位名叫格雷顿老哥（Graydon Hoare）住的那栋公寓，电梯又坏了。

第n次，他一边骂骂咧咧一边努力爬向自己位于21楼的家。他想不通，一个电梯系统咋就这么容易崩溃呢？不应该呀！

结果发现……这些电梯软件往往是也用C/C++编写的。

为了不再爬楼，格雷顿老哥决定搞个新编程语言出来。

于是，Rust诞生了。

具体而言，为了根除内存安全漏洞，Rust版员工手册全方位制定了更严格的工位管理方案：

• 不能随便乱指内存；
• 不能偷看同事的工位；
• 工作结束后要立马收拾干净并归还……

虽然设置了这么多限制，但由于特殊设计，不会浪费资源，所以程序员也不用担心这些限制会牺牲性能。

同时，由于Rust与C/C++具备良好的互操作性，微软可以直接调用现有Windows API，循序渐进地替换旧代码，而不必从头重写多达4000多万行的系统代码

这正是微软如此热衷于Rust的原因。毕竟，一旦这场大换血取得成功，长期困扰Windows系统的安全顽疾，或许能得到根治。

不过，Rust也存在缺点，比如难度比较高，最初的开发速度也比Go、Java慢很多。但对于微软这样的巨头来说，这些也称不上是阻力。

事实上，早在2023年，微软便已开始用Rust重写Windows内核。但直到今天，这一尝试依然止步于少数模块，始终未能大规模铺开。

技术之外的考量，才是阻碍微软大象转身的真正原因。

首先，是沉重的历史包袱

Windows内核起源于20世纪80年代，几十年积累下来，代码规模庞大而复杂。若要转向Rust，意味着需要重写跨越数十年的数百万行代码。

而在这堆代码中，沉淀着无数边缘案例。许多看似古怪、难以理解的实现，可能实际上是这栋大厦的重要支柱。

一旦重写过程中出现问题，很可能连病灶都找不着，因为本就没人理解这个庞然大物是怎么运作的。

其次，Rust本身的生态仍不够成熟

数以百万计的第三方驱动、硬件厂商和旧软件，高度成熟的工具链，比起技术基因，这些才是C/C++最重要的护城河。

相比之下，Rust对新手并不友好，上手门槛较高。更现实的是，在许多细分领域，Rust缺乏足够成熟的解决方案，开发者需要投入大量时间积累经验，才能勉强追上C/C++多年沉淀下来的生态基础。

因此，想要切换成Rust，不是微软一家能说了算的，所有开发者都面临高昂的学习成本

AI编程能力的突飞猛进，让这颗明珠第一次变得触手可及。

如果AI这个中间层，能够承接并消化上述转换成本，那么无论是微软，还是Windows开发者，掉头的阻力都会被大大削弱。这或许正是Galen提出「一名工程师，一个月，一百万行代码」的背后洞察。

但这套逻辑有一个前提：AI真的有能力胜任这「翻译工具」

而现实情况是，即便Gemini 3 Pro再次带来了质变，也还不至于让程序员成为甩手掌柜。更不用说让AI深度参与足以撼动Windows根基的内核级工程。

或许正如Galen所言，这目前仍只是一个研究项目。微软确实有意推动换血，但他们也清楚技术条件尚未成熟。

无风不起浪

也不怪网友反应激烈，微软此前确实很爱释放「全力拥抱AI」的信号。

2025年4月，微软CEO Satya Nadella在Meta举办的开发者大会上颇为自豪地表示，微软已有约30%的代码由AI编写，而且这一比例还在持续上升。

• 我估计，我们代码库中大约有20%到30%的代码，以及部分项目，可能都是由软件写出来的。

同月，微软CTO的表态则更加激进。他预计，到2030年，高达95%的代码将由AI生成。

而在微软内部，这把「AI改革」的火，更是在CEO Nadella全力押注的东风下，彻底燎原。

据悉，Nadella将AI视为决定微软生死存亡的重要时刻，这将决定微软是否能继续屹立科技行业顶峰。对Nadella而言，这同样是一次百年难遇的机会。

这项使命既关乎职业，也关乎个人。

因此，这位微软CEO对内部高管下达的最后通牒是：要么拥抱AI，要么滚蛋

不过，此次事件一出，微软或许需要重新规划下驶向「AI原生企业」的行驶速度。

像苹果那样坐在金矿上发呆显然不行，但如果步子迈得太大，市场同样会担心企业栽个大跟头。

先规划三步，再退两步。

这或许是如今技术高速迭代背景下，最稳妥的选择。

[1]https://www.windowslatest.com/2025/12/24/microsoft-denies-rewriting-windows-11-using-ai-after-an-employees-one-engineer-one-month-one-million-code-post-on-linkedin-causes-outrage/
[2]https://techpreneurr.medium.com/why-microsoft-tried-to-rewrite-windows-in-rust-32e5dd63ecf3
[3]https://www.linkedin.com/posts/galenh_principal-software-engineer-coreai-microsoft-activity-7407863239289729024-WTzf/
[4]https://www.businessinsider.com/microsoft-ceo-satya-nadella-ai-revolution-2025-12