微软光速辟谣了。
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原生企业」的行驶速度。
像苹果那样坐在金矿上发呆显然不行，但如果步子迈得太大，市场同样会担心企业栽个大跟头。
先规划三步，再退两步。
这或许是如今技术高速迭代背景下，最稳妥的选择。
