本篇是系列序篇，不对应某个代码标签。课程进度与文章链接见系列总览。

二十多年前，我觉得操作系统课像文科

二十多年前上操作系统（Operating System，OS）课时，对当时的我来说，这门课有点像文科：要记各种设计原则、术语和机制，考试时也能把它们复述出来；可一问“这些东西在程序运行时到底怎样发生”，脑子里就容易变成一团雾。

这不是说理论不重要，也不是要评价当年的老师。问题在于我一直缺少真正动手的机会。进程、调度、文件系统、中断、虚拟内存……名字都见过，原则也背过，却很难把它们和一段正在执行的代码、一串寄存器变化、磁盘上的实际字节联系起来。

后来一直想补上这段实践，但总有别的事情排在前面。现在正好借这个机会，从一条指令开始，把整个过程重新捋一遍。

这次不从原则背起，从能观察的现象开始

我想沿着一条连续的路径做下去：

  1. 从源码和交叉编译开始，生成可执行与可链接格式（Executable and Linkable Format，ELF）文件；
  2. 找到入口并写启动汇编，设置 C 运行环境；
  3. 通过通用异步收发器（Universal Asynchronous Receiver-Transmitter，UART）得到第一行串口输出；
  4. 让 bootloader 从块设备读镜像，再逐步增加特权级、syscall、调度和 shell；
  5. 加入文件系统和持久化，再让系统自己编译、加载和动态调用程序；
  6. 最后把已经在模拟器里逐层验证的系统移到真实开发板。

每一步都尽量能回答四个问题：

  1. 现在要解决的具体问题是什么？
  2. 改动了哪些代码、寄存器或磁盘字节？
  3. 我预计运行时会看到什么？
  4. 实际测试结果是否和预测一致；哪些边界仍未覆盖？

这条路线不是“从零造出一个可替代 Linux 的 OS”。它是一套小而可复现的教学实验：从 QEMU（Quick Emulator，快速仿真器） 中的一行串口输出，逐步走向内核服务、持久化和真机验收。哪些能力尚未实现，也会明确写出来。

人工智能（Artificial Intelligence，AI）辅助的费曼学习法

我把这个过程称作 AI 辅助的费曼式学习。AI 可以帮我拆解问题、解释陌生机制、提出实现草案、一起读错误信息；但它给出的答案不是验收结果，更不能替我理解系统。

实际循环应该是：

选一个小问题
  → 让 agent 协助解释或实现
  → 我检查设计和 diff，先预测结果
  → 自己构建、运行、测试，必要时用 [GNU 调试器（GNU Debugger，GDB）](/terms/#gdb)或独立脚本核对
  → 用自己的话讲明白，并记录没验证到的部分

如果我不能解释启动时栈指针（stack pointer，sp）为什么必须先设置，或者 bootloader 读的逻辑块寻址（Logical Block Addressing，LBA）怎样对应到随机存取存储器（Random-Access Memory，RAM）地址，那就还没有真正学会。测试通过也只说明测试覆盖的那条路径通过了，不自动证明整个机制没有缺陷。

因此文章不会以聊天记录为主线，也不会把“agent 说完成了”当结论。真正值得记录的是：曾经哪里理解错了、如何定位、代码和实验给了什么证据，以及最后仍有哪些限制。

为什么选 RISC-V 和 QEMU

本系列已经选择 RISC-V 裸机和 QEMU virt 作为前期实验环境。交叉工具链让目标架构明确；QEMU 让启动、串口、块设备和 GDB 调试可以重复执行；课程代码仓库则用标签固定每一课的状态，避免文章依赖不断变化的 main。

这也有边界：QEMU 成功不是实体开发板验证，模拟出来的设备地址不是所有 RISC-V 板卡的统一地址。等路线走到真机时，仍需要重新核对启动链、内存地图、时钟、中断和存储，并实测每一层。

目前走到哪里

序篇之后，前三课已经发布：

  • 第 01 课：搭建可复现环境，进入第一条指令；
  • 第 02 课：设置启动环境、进入 C main 并输出 UART；
  • 第 03 课：从 virtio 磁盘加载 kernel 和 shell payload。

从机器模式（Machine mode，M-mode）到用户模式（User mode，U-mode）、调度、文件系统、编译器和真机移植仍在路线图上，不会因为标题出现在总览里就算已经完成。

可以从系列总览查看每一篇的状态；每篇技术课都会给出对应代码标签、复现命令和实测验收。希望多年以后再回头看时，我不只记得操作系统有哪些原则，也能沿着代码和运行结果，把它们从头讲清楚。