用Claude从零构建操作系统：EMBER在真实笔记本上运行的全过程

一位开发者把一台闲置的联想Yoga笔记本翻了出来，想看看Claude能走多远——目标是从零打造一个类DOS的操作系统，并且要能从U盘启动、跑在真实硬件上。几天之后，这个被命名为EMBER的系统真的跑起来了，能运行Doom、支持触摸屏、还实现了Sound Blaster声卡模拟。这个项目在Reddit上引发热议，也让人重新思考AI辅助编程的边界。

从一堆崩溃开始的迭代循环

第一个可用版本来得出乎意料地快，但绝非“一次成型”。早期构建问题一大堆：图形显示错乱、没有鼠标、没有键盘、没有声音，还有各种硬崩溃。

作者总结出的核心工作流非常朴素：描述目标 → 让Claude实现 → 编译 → 在真实硬件上启动 → 拍照/记录失败 → 继续迭代。这套循环没有任何魔法，靠的是不断把失败反馈喂给模型，再让它修正方向。

这一点值得特别注意：所谓“AI写操作系统”，并不是按一个按钮就产出成品。真实的开发过程充满了在物理硬件上验证、复现bug、否定错误方案的反复劳动。

EMBER现在能做什么

经过几天迭代，EMBER已经具备了一个相当完整的桌面操作系统雏形。作者列出的功能清单包括：

• 自有的启动流程与图形环境
• 键盘、USB鼠标、触摸板、触摸屏支持
• 屏幕虚拟键盘 / 平板模式
• 文件管理器、音频播放器、资源监视器
• DOS程序兼容层
• 运行Doom、Alley Cat、波斯王子等DOS游戏
• 完整的Sound Blaster声卡模拟
• PC喇叭（PC speaker）模拟
• UEFI启动支持的早期进展

对于一个几天时间、主要由AI生成代码的项目来说，这份清单的完整度确实令人意外。它已经不只是“能启动”，而是有了可用的图形界面和实际应用生态。

声音：这个项目最有意思的部分

作者认为声音支持是整个项目里最有趣的环节。最初Doom能跑，但完全没有声音。

第一步的临时方案是从源码重新编译Doom，让它直接调用笔记本的实际音频硬件。但这只解决了单个游戏的问题。随后团队走得更远——实现了真正的Sound Blaster硬件模拟，这样那些预期存在Sound Blaster声卡的未经修改的DOS游戏，就能正常发声了。

他们还实现了PC喇叭模拟，让那些依赖经典PC扬声器发声的老游戏也能工作。这意味着Doom和其他DOS游戏不再需要任何特殊的音频处理来出声——它们看到的就是一套“真实”的声卡环境。

性能瓶颈与缓存机制

性能是另一个大麻烦。项目一度出现拖动窗口或播放音频就把CPU占满的情况，图形界面卡顿到几乎不可用。

经过几个小时的调试，Claude实现了一套内存缓存机制，彻底改变了系统响应速度。同样的老硬件上，GUI从极度迟缓变得非常流畅。这类底层优化往往是操作系统开发中最考验功力的部分，能在AI辅助下解决，说明模型不仅能生成功能代码，也能参与性能层面的架构调整。

向UEFI迈进

EMBER最初依赖传统BIOS服务，这把它限制在了较老的硬件上。团队已经开始推进UEFI支持，让Ember能在只支持UEFI的新机器上启动。

作者坦言这个问题尚未完全解决，但已经取得了实质进展。这也符合整个项目“持续迭代、逐步扩展硬件兼容性”的调性。

AI辅助开发的真实体验

作者最大的感悟是：用这种方式使用AI，完全不是“按按钮、收软件”那种体验。

我大部分时间花在决定系统应该做什么、在真实硬件上测试、发现失败、否决糟糕的方案、引导下一步实现。没有人手动敲出这里的大部分代码，但仍然得有人来决定这个操作系统应该成为什么样子。

这句话点出了当前AI编程的核心分工：代码生成可以外包，但方向判断、验证和取舍依然属于人。AI承担了大量繁重的实现工作，而开发者的价值转向了产品定义、测试反馈与技术决策。

项目的源码目前已公开在GitHub（Made-In-Basement/ember），作者也放出了一段视频，展示从最初崩溃的启动画面到Doom运行、硬件支持、触摸屏、平板模式、性能问题直至当前EMBER GUI的完整历程。

这个项目意味着什么

EMBER并不是要取代任何主流操作系统，它更像是一次关于“AI能力边界”的公开实验。从裸机启动、驱动适配到声卡模拟，这些历来被认为门槛极高的系统级工作，如今可以在人机协作下几天内跑出可用成果。

对开发者而言，真正的启示或许在于工作方式的转变：把重复性的编码交给模型，把精力集中在架构判断和真实环境验证上。AI没有让操作系统开发变得毫无门槛，但确实大幅压缩了从想法到可运行原型的距离。