微软迅速对此进行了辟谣。
根据Windows Latest的最新消息,微软明确表示,并没有计划利用人工智能技术重写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将旧代码的高墙全部推翻,也要掉头回去寻找的,究竟是什么?
几十年来,内存安全漏洞一直是微软难以根治的顽疾。
为了方便理解,我们可以把电脑想象成一家公司。其中,系统是老板,程序是员工。
在这家二进制公司里,员工上班前,需要先向老板申请一张工位,也就是内存,用来放电脑、处理数据、与同事交接。
每张工位都有明确的使用规范。办公桌面积有限,所有员工只能用自己被分配的工位,下班后必须立刻归还。
如果员工不遵守这些规矩,硬是要超出预先的内存分配,跑去别人工位,甚至化身「老油条」,赖在新人的办公桌不走,就会打乱公司运转。轻则程序闪退、系统蓝屏,重则给黑客留下可乘之机。
针对这一问题,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
本文由主机测评网于2026-03-10发表在主机测评网_免费VPS_免费云服务器_免费独立服务器,如有疑问,请联系我们。
本文链接:https://vpshk.cn/20260330230.html