AI 能写出 Windows 吗？基于一个“无监督操作系统实验”的技术判断

很多人问过一个很像科幻、但其实很工程的问题：如果把今天最强的代码模型、Agent、自动测试和自动修复链路都堆上去，AI 能不能自己写出一个 Windows？

我的判断很明确：现在的 AI 能写出“像操作系统的原型”，但还写不出“作为 Windows 被交付和维护的系统”。

差距不在“会不会生成内核代码”，而在 长时程约束、硬件兼容性、失败恢复、版本演进、以及没人盯着时的自我纠错能力。

为了避免把这个问题聊成玄学，我更愿意把它放进一个“无监督实验”的框架里讨论。

什么叫“无监督实验”

这里的“无监督”不是机器学习里那个术语，而是一个更朴素的工程设定：

• 不允许人类开发者逐函数手工修代码
• 不允许人类替 AI 拆任务、补规格、兜底架构
• 人类只负责给出最终目标、硬件约束、测试标准和验收条件
• AI 可以自己调用编译器、QEMU、日志系统、测试集、文档检索、回归检查
• 一旦系统出现崩溃、死锁、驱动异常、性能倒退，必须主要靠 AI 自己定位并修复

这个实验的目标不是“写出一个能启动的 toy kernel”，而是写出一个最小但完整的桌面 OS 交付链路：可启动内核、进程与内存管理、文件系统、基本驱动栈、图形界面、安装升级回滚、崩溃日志和恢复，以及对一组真实硬件和 workload 稳定通过测试。

如果 AI 连这个最小闭环都很难独立完成，就更不用谈 Windows 这种几十年积累出来的通用操作系统。

为什么“写出 Windows”不是一个代码生成问题

很多人低估了 Windows 这种系统软件的难度，是因为把它想成了一个超大仓库。

但操作系统真正难的地方，从来不只是代码量，而是 约束的密度。

Linux 内核在 2025 年已经超过 4000 万行代码，增长的大头长期来自驱动和架构适配，不是几段“聪明的核心逻辑”就能替代。Windows 的公开估算也长期在数千万行级别。这个数量本身不是重点，重点是这些代码背后对应的是海量硬件、历史兼容性、边界条件和失败模式。

一个桌面操作系统要面对的，不是“写出对的代码”这么简单，而是要在脏乱差的硬件现实里活下来，在旧驱动、旧接口、旧应用的历史债务里活下来，在异常状态下可诊断、可恢复、可升级，并在安全和性能之间持续做权衡。

这也是为什么“能写一个内核”和“能写出 Windows”之间，不是 10 倍差距，而是一个量级上的类别差异。

这个无监督实验最可能卡死在哪里

1. 规格并不完整，很多规则藏在系统行为里

LLM 很擅长在“局部目标明确”的情况下补全代码。但 OS 开发里，大量规格并没有完整写在文档里，而是埋在历史实现、驱动约定、错误恢复路径、兼容性行为和用户的隐性预期里。

也就是说，AI 不是只需要“实现需求”，它还得先发现需求。而这件事如果没有持续的人类判断，极容易滑向“让测试过掉就算完成”。

2. 调试闭环太长，错误会跨层传播

Web 服务出错，通常能在日志、接口或单元测试里比较快定位。操作系统不是这样。一个显卡驱动里的竞争条件，可能表现为桌面偶发卡死；一个内存管理问题，可能在几小时后才以文件损坏的形式出现。

这类问题的可怕之处在于：症状和根因经常不在同一层。AI 现在已经能处理不少仓库内的局部 bug，但面对跨模块、跨抽象层、跨时间窗口的问题，稳定性还远远不够。

SWE-bench 这类基准说明 AI 在“给定代码库 + 给定 issue + 给定测试”的软件修复问题上已经很强，但这离操作系统构建还差很远；更难的长时程基准仍然在强调，多步规划、环境交互和长期一致性是瓶颈。

3. 无监督条件下，AI 容易把系统推向“可演示，不可维护”

没有人盯着的时候，模型很容易优先优化那些“短期可验证”的目标：先让它编过，先让测试绿，先让界面跑起来，先把 benchmark 做漂亮。

但 Windows 级系统的价值，恰恰不在这些局部成功，而在长期维护成本。如果一个系统每增加一个驱动、一个权限模型、一个升级策略，整体复杂度就不可控地上涨，那它就不是 Windows，只是一个越来越大的演示工程。

4. 兼容性不是附加功能，而是系统本体

对个人开发者来说，做一个新 OS 原型并不神秘。真正神秘的是：你怎么让它在足够多的真实机器上都不出离谱问题。

Linux 内核规模持续膨胀，一个核心原因就是驱动支持和架构适配。换句话说，通用操作系统的本质不是“内核优雅”，而是“对现实世界足够低头”。

这件事最不适合完全无监督。因为一旦缺少人工边界判断，AI 往往会选择“缩小支持面”来换取成功率。然后你会得到一个很漂亮、但非常窄的系统。

公开证据其实已经给了我们一点答案

过去一年，关于 AI 编程最重要的现实提醒，不是又有哪个 demo 会自动拉项目，而是：一旦任务变成长周期、强约束、需要反复理解上下文的真实工程，AI 的收益并不稳定。

METR 在 2025 年对有经验的开源开发者做随机对照实验时发现，允许使用当时前沿 AI 工具的开发者，完成任务反而平均慢了 19%。到 2026 年更新结果时，数据开始出现“在部分样本中可能有提速”的迹象，但置信区间仍然很宽，说明真实效果强依赖任务类型、代码库熟悉度和使用方式。

这件事对“AI 能不能写出 Windows”有什么启发？很简单：如果在熟悉代码库、明确 issue、有人类开发者全程把关的条件下，AI 的收益都还不稳定，那么在无人监督、目标更开放、反馈更迟滞的 OS 构建任务上，它更不可能稳定完成整机级交付。

所以，AI 到底能做到哪一步

AI 已经能做到的

• 生成 toy kernel、bootloader、简化驱动、教学型文件系统
• 帮工程师快速探索 OS 原型
• 做端到端脚手架：编译、启动、测试、日志分析、回归修复
• 在明确规格下，承担某些模块的高强度样板实现和重构

AI 暂时做不到的

• 在几乎没有人类持续干预的前提下，完成通用桌面 OS 的长期集成
• 持续维护大规模硬件兼容性
• 可靠处理跨层、长反馈链、低频高损失的系统级缺陷
• 在多年演进中守住架构边界，而不是不断堆补丁

换句话说，AI 更像操作系统团队的“高吞吐实现层”和“自动化实验员”，还不是“首席系统架构师 + 兼容性负责人 + 线上事故总指挥”。

这件事对开发者意味着什么

对大公司来说，AI 最现实的用法不是“自动写一个 Windows”，而是帮现有系统做大规模代码理解、帮迁移部分历史代码、帮搭建更强的测试分析修复流水线，并把过去只能由资深工程师手工完成的一部分机械工作自动化。

最近微软研究方向里关于大规模代码迁移、希望把“一个工程师一个月改一百万行代码”这类目标抬上桌，反而更说明行业的真实方向不是“让 AI 独立写完 Windows”，而是“让 AI 在超大代码库里做可控变更”。

对独立开发者来说，这个判断也很重要：不要被“AI 可以一人写完整个平台”这种叙事骗到。真正值得做的不是和 Windows 正面竞争，而是做更窄、更可验证的系统工具，做开发者工作流自动化，做垂直场景里的本地运行环境、代理层、沙箱层、调试层，利用 AI 降低系统软件原型成本，而不是幻想一键生成成熟平台。

结论

AI 现在不能“无监督地写出 Windows”。 它能写出内核，能写出原型，能在局部模块上超过很多普通工程师的编码速度；但它还没有证明自己能在没有持续人类判断的前提下，完成一个通用操作系统最关键的工作：在复杂现实中长期保持正确、兼容、可维护。

所以这个问题真正的答案不是“AI 会不会写操作系统”，而是：AI 会先重写操作系统团队的工作分工，而不是直接取代操作系统本身。

未来几年最值得关注的，也不是“哪个模型能不能独立做出 Windows”，而是哪个公司先把 AI 变成系统软件工程里的可靠协作者：能读懂旧代码，能控制变更半径，能自动回归，能在失败时自己给出可信诊断。这比一个会写 demo 的 AI，难得多，也值钱得多。

参考资料

• SWE-bench 官方介绍与生态
• SWE-bench Pro / 长时程软件工程基准资料
• METR 关于经验开发者使用 AI 工具的生产率研究与 2026 更新
• Linux 内核 2025 年代码规模与驱动增长资料
• Windows 历史代码规模公开估算与相关技术讨论