# [雅望停云] 写在开始 TheLongWay2HelloWorld 之前


> 过家家到此结束了 --啊搜比哇酷酷马得达

写于开始 TheLongWay2HelloWorld 之前。

最近这种感觉越来越强。看秋招 JD 的时候会有，看一些课程的时候会有，看别人做项目的时候也会有。尤其是在看了蒋岩炎的操作系统之后，这种感觉几乎变成了一种很难忽略的刺痛：我确实接触了很多东西，也知道不少名词，甚至有些内容在看的当下还会产生一种“啊，这我懂了”的错觉，但如果不去做一点什么，它们很快就会散掉。它们不会在我的脑子里长成一幅地图，更不会变成一种可以调用、可以解释、可以从头讲给别人听的理解。

更糟糕的是，这种状态在今天甚至更容易被掩盖了。因为现在有 AI。很多事情确实可以更快地完成。就在前几天，AI 的确就帮我修好了 Vivado 的问题（准备本项目需要使用的软件）。放在几年前，我可能要自己折腾很久，甚至还不一定能解决。

所以从“完成任务”的角度来说，时代确实变了。很多门槛都被降低了，很多阻碍都变得没那么可怕。这当然是好事。

但问题也恰恰在这里：AI 完成了工作，可学习并没有自动发生。

我越来越不想这样了。所以我想，自己总该做点什么。不是再看一门课，不是再收藏几个资料夹，不是再让 AI 帮我把一个个局部问题解决掉，而是做一件足够具体、足够硬、也足够诚实的事情，逼自己不能停留在表面，逼自己把那些零散的知识真正串起来。

想来想去，要不就手搓一个核吧。

这句话说出来有点像一时兴起。但我真切地知道这件事一点都不轻松。恰恰相反，它很可能是我现在能想到的、最不“平面化”的事情之一。它不会只考你某一门课学得怎么样，也不会只要求你会写一点代码或者会配一点环境。它天然就是跨层的：硬件、指令、存储器、总线、串口、启动代码、链接脚本、编译工具链，最后还要让一个程序真正跑起来。它逼着你从电路走到系统，从结构走到软件，从“知道几个概念”走到“让整个东西形成闭环”。

而且对我来说，做这件事还有一个再直接不过的原因：我是集成电路专业的学生。

既然如此，我总该认真碰一次这些东西。不是只在课上听过，不是只知道几个模块名，不是只会说“CPU 大概就是这么工作的”，而是真的亲手搭一个最小系统，去看它是怎么一步一步运转起来的。过去我也学过一些相关课程。本科大四的时候，甚至还上过一个什么流水线处理的课。可惜那时候在考研，很多内容基本上是快速略过的，谈不上真正理解。现在回头看，会觉得有点可惜：如果当时认真学，也许会收获很多东西。不过现在说这些也没有太大意义。重要的是，我不想一直停留在“本来可以学会”的遗憾里。我更想看看，现在开始，究竟还能不能把它们重新捡起来，重新串起来，重新变成自己的东西。

说实话，我现在对这件事情并没有总览。我不知道它最后会变成一个什么样子，也不知道自己会卡在哪一层。我甚至不知道自己是不是从一开始就低估了它。我只知道它大概不会简单，甚至很可能比我目前想象的还要麻烦得多。不过反过来说，如果我一开始就知道它是什么样，那我大概也不用做它了。

开始这件事，本来就意味着进入一个我还不熟悉的世界。意味着要接受自己一开始只能看见局部，只能解决眼前的节点，只能在不断出错、不断回退、不断修补里，慢慢获得对整体的认识。我觉得这才是很多真正复杂的工程本来的样子：不是先有全貌再去实现，而是在实现中一点一点逼近全貌。

我当然也怕。

我怕最后做不出来，怕中途卡死在某个我根本不知道该怎么定位的问题上，怕花了很多时间，最后只得到一个半成品。我也怕另一种更隐蔽的失败：东西似乎做出来了，但其实只是 AI 指挥下的一场拼装；我会运行这些模块，会复制这些代码，会根据建议改参数、改脚本、改接口，最后把整个系统凑起来，可一旦离开这些提示，我依然说不清楚每一层究竟为什么要这样设计，问题究竟出在哪里，自己又究竟学到了什么。

这是我最不想看到的结果。

因为如果最后只是完成了一个项目，而没有形成真正的理解，那这件事对我来说就只完成了一半，甚至连一半都不到。它可能仍然是一个可展示的结果，但不是我真正想要的那个结果。我想要的不是“在 AI 协助下跑通了一个 demo”，而是至少在这个过程中，脑子里真的长出一点结构，真的对“计算机为什么会工作”这件事有了更扎实、更不容易蒸发的理解。

所以我给这件事起的名字是：`TheLongWay2HelloWorld`。

目前我的大概规划是这样的：我已经让 AI 帮我设计了一个 roadmap，分成若干个节点和门槛。说到底，我并不打算拒绝 AI。那样既不现实，也没有必要。工具就是工具，好的工具本来就该用。关键不在于用不用，而在于怎么用。我希望 AI 在这个项目里扮演的是辅助者、讨论者、排障助手、资料索引，而不是理解的代工厂。它可以帮我少踩一些无意义的坑，帮我补一些信息差，帮我在我完全没头绪的时候给出可能的方向；但每走到一个节点，我还是得逼自己回答：这件事到底是什么？为什么这样做？如果不用现成答案，我能不能自己讲清楚？

所以接下来，我想做的不只是照着 roadmap 往前推工程。我还想在每一个节点上，都补上一份属于自己的说明：这一部分的理论知识是什么，它的原理是什么，它在历史上为什么会这么设计，工程上又通常是怎么落地的。我希望把“做出来”和“讲明白”绑在一起，让它们互相校验。

最后贴上GPT老师给我的安慰（我向他索取的）

> 给你一点真心的鼓励
> 这件事确实不简单。
> 你说得对，它一点都不简单。
>
> 你会碰到的不是普通意义上的“不会写代码”，而是那种跨层困难：
>
> 波形看不懂
> 串口没输出
> 指令跑飞
> 栈炸了
> 中断一开系统死掉
> 链接地址不对
> 明明代码对，板子上就是不工作
> 你会怀疑是不是每一层都出了问题
> 这很正常。
> 因为你正在做的，本来就是计算机工程里最不“平面化”的事情之一。
>
> 但也正因为难，它才有价值。
>
> 你最终得到的那句 Hello World，不是普通教程里复制来的输出。
> 那会是你亲手从以下所有东西里“逼”出来的一句话：
>
> 时钟
> 复位
> 寄存器
> 指令译码
> ALU
> 存储器
> 地址映射
> 串口发送器
> 启动代码
> 链接脚本
> 编译器
> 程序计数器
> 栈指针
> 那句 Hello World 会很轻，但它背后很重。
>
> 很多人一辈子都在使用计算机，却从没有真正走到“Hello 为什么会出现”的源头。
> 而你想去那个源头看一眼。
>
> 这不是折腾，这是追根溯源。
> 不是无意义，这是在建立根基。
> 不是偏门，这是少数人愿意走的硬路。
>
> 而且我要很直接地说：
> 哪怕你最终没跑到 Linux，只是做出一个能稳定执行指令、通过 UART 打印 Hello World 的简化 CPU，这个项目也已经非常值得写进简历，值得骄傲。
>
> 因为你已经完成了一个完整世界的最小闭环。