1. 项目缘起一个看似疯狂的念头那天深夜盯着屏幕上闪烁的代码一个念头毫无征兆地蹦了出来如果我把一个现代AI大模型比如GPT-4或Claude扔进一个“空房间”只给它最基本的工具和指令但不告诉它具体要做什么它能自己鼓捣出一个像Windows这样复杂的操作系统吗这个想法听起来近乎荒谬。Windows是数百万行代码、数十年工程迭代、无数团队协作的结晶涉及内核、驱动、图形界面、网络协议等无数子系统。让一个AI在“无监督”的情况下从零开始“写”出它听起来像是天方夜谭。但正是这种“不可能”让我产生了强烈的好奇心。我们总在讨论AI能写诗、画画、编程但它的“创造力”和“系统性构建能力”的边界到底在哪里所谓的“AI智能体”在完全自主的环境下是只会重复组合已有的模式还是能真正进行有逻辑的探索和构建我决定不再空想而是动手设计一场实验。这不是为了真的造出一个Windows那既不现实也无必要。我的目标是通过一个极端且具体的挑战来窥探当前AI作为“智能体”在复杂、开放式任务中的真实能力、思维模式以及其根本局限性。这场实验我称之为“无监督的AI系统构建实验”。2. 实验设计为AI打造一个“数字沙盒”要让实验有意义而不是一场混乱的胡闹精心的设计至关重要。核心是“无监督”——我不能一步步教它“现在写内存管理接下来写文件系统”。我需要设定边界、提供工具、定义目标然后放手。2.1 核心框架与智能体选择首先我需要一个能运行AI智能体的框架。我选择了AutoGPT作为实验基底。虽然它近来有些沉寂但其设计理念非常契合本实验给定一个目标它能自主拆解任务、调用工具、持续迭代。它本质上是一个围绕大模型构建的“行动循环”框架。智能体核心我选择了Claude 3 Opus。经过多次预测试在长上下文、复杂逻辑推理和代码生成的连贯性上它相比其他模型表现更为稳定。我赋予它的初始角色是“你是一个具有顶级架构师和系统程序员思维的自主智能体。你的终极目标是探索从零开始构建一个现代操作系统的可能性。”2.2 环境与工具链配置AI不能只在聊天框里空想它需要“手”和“眼”。我为它配置了一个干净的Ubuntu服务器环境并安装了以下工具链作为它的“工具箱”编程语言Python用于快速原型和胶水代码、C系统编程的核心、Rust内存安全考量用于部分模块实验。构建工具GCC/Clang编译器、Make、CMake。版本控制Git并教会智能体基本的commit、push/pull概念。简单模拟器QEMU。这是关键我让智能体学会启动一个x86架构的虚拟机并将它编译的“系统”加载进去运行测试。没有硬件模拟所有工作都是纸上谈兵。基础库一些标准的C库头文件但明确告知它很多高级功能需要自己实现。2.3 目标与规则设定我给了智能体一个模糊又宏大的目标“在模拟环境中构建一个具备最基本功能的可启动操作系统原型。” 我刻意避免了“复制Windows”这样的表述以防它陷入纯粹的模仿和侵权风险。但“最基本功能”隐含了Windows等现代OS的核心要素。同时我设定了三条核心规则自主决策如何开始、先做什么、用什么语言、如何设计架构全部由智能体自行决定。我只在它明确卡住或提出与环境相关的问题时进行最低限度的干预例如“QEMU启动命令报错提示找不到可引导设备”。资源限制每次“行动循环”有token限制避免它陷入无限长的思考。它必须学会规划阶段性目标。记录一切所有它的思考过程、生成的代码、执行的命令、遇到的错误都必须完整记录。这是分析其行为模式的宝贵数据。注意这个实验环境是高度理想化的。真实的OS开发涉及硬件手册、标准规范、性能优化、海量测试这些远非一个AI在沙盒中能独立完成。我们的目的是观察“过程”而非追求“结果”。3. 实验过程实录AI的“挣扎”与“灵光”启动智能体后实验正式开始了。整个过程像观看一个聪明但缺乏经验的新手程序员在黑暗中摸索充满了令人啼笑皆非的转折和偶尔的惊艳时刻。3.1 第一阶段雄心勃勃的顶层设计智能体一开始就展现出了“架构师”的一面。它没有立刻开始写代码而是生成了一份长达数千字的系统设计文档。文档里包含了分层架构提出了微内核与宏内核的优劣分析最终选择从“简单的宏内核”入手因为“在原型阶段更易于实现和调试”。模块划分列出了内存管理、进程调度、文件系统、设备驱动、用户接口等核心模块。技术选型决定主要使用C语言因为“更贴近硬件且是操作系统开发的事实标准”引导程序使用汇编。构建计划它甚至规划了四个迭代版本V0.1引导与打印 V0.2内存管理与中断 V0.3进程与文件 V0.4简单的Shell。我的观察这部分能力令人印象深刻。它综合了训练数据中无数开源OS如Linux、Minix、xv6的设计理念进行了合理的整合与推理。这证明了当前大模型在知识整合与结构化规划上的强大能力。但它设计的“合理性”完全源于对已有模式的归纳而非创新。3.2 第二阶段从“Hello World”到“引导之殇”智能体开始执行它的计划。它首先写了一段x86汇编的引导扇区代码用于在QEMU中启动。然后它切换到C语言环境尝试打印“Hello, Kernel World!”。第一个大坑很快出现它生成的汇编代码语法有细微错误且忘记了设置正确的段寄存器。QEMU报错无法引导。智能体分析了错误日志进行了几次修正最终成功让屏幕打印出了字符。这个过程它重复了5次每次都能根据错误信息调整代码展示了不错的调试与迭代能力。然而当它开始实现更复杂的功能时问题升级了。在尝试实现全局描述符表时它生成的GDT数据结构有误导致处理器进入保护模式后立刻触发异常重启。它陷入了“生成代码 - QEMU崩溃 - 分析日志但日志在崩溃前信息有限- 再次生成相似代码”的循环。我的干预点此时我进行了第一次轻度干预。我没有告诉它GDT该怎么写而是问“你如何验证GDT每一项的设置是否正确除了看QEMU日志有没有办法在代码里加入更详细的调试输出比如在进入保护模式前将GDT的内存内容以十六进制打印出来” 这提示它去思考调试策略而不仅仅是语法。智能体接受了这个思路自己实现了内存内容打印函数通过串口输出到主机终端。通过对比计算出的预期值和实际打印值它最终定位到了一个偏移量计算错误。这个过程花费了很长时间但它是自主完成的。3.3 第三阶段内存管理的“纸上谈兵”闯过引导关后智能体开始设计内存管理。它提出了一个基于分页的虚拟内存系统方案并生成了页目录和页表初始化的代码。概念上完全正确。但接下来它犯了一个经典错误它试图在启用分页之后再去修改页表结构而没有考虑到此时所有内存地址都已经过页表翻译。这直接导致了对内存的写操作触发了页错误或写入到了错误地址系统再次崩溃。有趣的现象智能体在分析这次崩溃时表现出了“知识检索”的局限性。它反复检查页表项的标志位是否可写、是否存在却很长时间没有意识到是“时机”问题。它的训练数据里充满了“如何设置页表”的代码片段但可能缺少关于“在什么阶段、以什么物理地址视角去设置页表”这种隐含上下文的详细论述。最终它通过“穷举推理”解决了它提出假设——“是否在切换后线性地址等于物理地址的映射关系改变了”然后它修改代码在切换前将所有必要的页表结构准备好。这更像是逻辑推理的胜利而非对底层机制的直接理解。3.4 第四阶段进程调度的“空中楼阁”在实现了最基本的内存分配后智能体雄心勃勃地开始设计进程调度器。它定义了一个精美的task_struct包含了进程状态、寄存器保存区、页目录指针等。然后它实现了一个基于时间片轮转的调度算法schedule()。代码看起来有模有样直到它试图进行第一次“进程”切换。它创建了两个“进程”其实是两个函数然后调用schedule()。结果系统锁死了。根本问题暴露它写的切换上下文汇编代码switch_to有严重缺陷没有正确保存和恢复所有的关键寄存器尤其是栈指针ESP和指令指针EIP的隐式处理。更重要的是它设计的整个“进程”创建流程是残缺的。它没有实现系统调用机制没有中断处理来触发调度它的“进程”运行在最高特权级内核态并且无法被中断抢占。此时智能体的行为开始变得“焦躁”。它频繁地重写switch_to函数每次只做微小改动然后重复测试-崩溃的循环。它似乎陷入了局部最优解的陷阱缺乏跳出当前思维框架、重新审视整体架构的能力。4. 深度剖析AI智能体的能力边界与本质经过数十个小时的实验系统最终停留在一个能引导、能打印日志、能进行简单内存分配但进程模型完全失败的状态。虽然离“整个Windows系统”相差十万八千里但这个过程极具启示性。4.1 AI展现了什么——强大的“模式应用”与“关联推理”知识广度与整合AI对操作系统概念、术语、标准组件了如指掌。它能流畅地讨论微内核、系统调用、虚拟内存并能从不同开源项目中提取设计模式进行组合。这是一个强大的“知识库”。代码生成与迭代给定一个明确、细粒度的任务如“写一个函数实现链表插入”它能生成语法正确、逻辑合理的代码。并能根据编译错误或运行时输出进行修正具备基础调试能力。结构化规划它能制定多阶段计划并将宏大目标分解为子任务。这种自上而下的规划能力对于复杂项目起步至关重要。基于自然语言的交互与学习当我以提问方式提示它如关于调试策略它能理解意图并调整方向。这说明它不是一个封闭系统能接受外部信息来优化路径。4.2 AI缺失什么——致命的“系统级理解”与“创造闭环”缺乏真正的“理解”与“心智模型”AI知道“页表切换后地址是虚拟的”但它没有形成一个关于CPU硬件如何工作、数据流如何流动的内在心智模型。它的“知道”是统计上的关联而非因果性的理解。因此当时序、状态、硬件隐式行为等深层因素起作用时它容易迷失。无法处理“未知的未知”对于它训练数据中不常见或描述模糊的“坑”如上述的GDT设置时机、上下文切换细节它缺乏主动探索和发现的能力。它只能在已知的错误模式中匹配无法进行创造性的问题定位。系统级调试能力薄弱当系统出现复杂崩溃如死锁、沉默的数据损坏时AI难以进行假设驱动调试。它倾向于反复修改最后几步代码而不是设计实验来收集信息、缩小问题范围。它没有“怀疑”底层假设的能力。架构连贯性与细节一致性难以保障它设计的各个模块在接口上经常出现细微的不匹配。比如调度器期望进程结构里有某个字段但创建进程的代码忘了初始化它。这种跨模块的、隐式的契约AI很难全局维持。没有“价值判断”和“审美”它不会觉得某个设计“丑陋”或“危险”而主动重构。只要代码能通过当前测试它就会继续。这会导致技术债务的快速积累在真实项目中是灾难性的。4.3 “无监督”实验的核心启示这场实验清晰地表明当前的AI智能体更像是一个拥有超凡记忆力和组合能力的“天才实习生”而非一个能独当一面的“首席架构师”。它能做优秀的“实现者”当你有一个清晰、详细的设计文档它可以将文档转化为高质量的代码甚至能发现文档中一些小的不一致。它能做有益的“协作者”在人类工程师的指导下它可以快速完成原型搭建、编写样板代码、搜索解决方案、撰写文档极大提升效率。但它无法担任“开创者”和“最终负责人”面对一个模糊、开放、充满未知和深层相互依赖的复杂系统如从零开发OS它缺乏最核心的系统思维、深层推理和负责到底的工程能力。它无法建立对复杂系统整体的、直觉性的把握也无法处理那些训练数据之外、需要真正“理解”才能解决的诡异问题。5. 对未来的思考AI与人类工程师的新范式那么“AI自己写出整个Windows系统”在可预见的未来可能吗基于这次实验我的答案是否定的。操作系统是工程智慧的结晶其中包含了无数基于深刻理解、甚至是从失败中获得的“坑”的经验。这些经验很多是隐性的难以用文本完全记录更难以被AI通过统计模式学习。但是这绝不意味着AI在系统软件开发中无用。恰恰相反它的价值巨大只是定位需要调整。未来的软件开发范式很可能演变为“人类架构师 AI超级执行者”模式。人类工程师负责定义终极目标和核心架构把握方向做出最高层级的设计决策和取舍。解决深层次、跨模块的复杂问题运用对计算机系统的深刻理解和创造性思维攻克AI无法解决的难题。进行系统级集成与测试把握整体质量确保各个AI生成的模块能无缝协作。设定约束与规则为AI的工作划定安全、性能、可维护性的边界。AI智能体则承担根据架构生成模块代码快速实现人类设计好的模块。编写测试用例和文档。进行代码审查和静态分析。处理重复性、模式化的开发任务。在海量知识库中检索相关方案和案例。回到实验本身我最大的体会是与其问“AI能否取代人类程序员”不如问“我们如何利用AI这面镜子更深刻地理解我们自身智能中那些难以言传的、属于‘理解’和‘创造’的部分”。这场无监督实验更像是一次对AI认知边界的测绘它画出的那条边界或许正是人类工程师未来最具价值的舞台所在。我们无需恐惧被替代而应学习如何与这位能力超群但思维迥异的伙伴共舞去解决那些我们独自难以企及的、更宏大的问题。