本篇要回答的问题：03 讲留下的思考题——一个"最小功能集、计算能力可自我迭代的计算机"，它的变化点和稳定点分别是什么？该拆成哪些子系统？
本讲是对 03 讲思考题的实战解读。它不是引入新概念，而是把前几讲反复强调的需求分析 + 稳定点/变化点框架，真刀真枪地走一遍。需求回顾：这台计算机要有键盘/显示器驱动、外置存储驱动、汇编编辑器、汇编编译器、执行外置存储中程序的能力。
需求分析有多重要？
做架构，第一件事是学会做需求分析。架构师至少应花三分之一精力在需求分析上。
这也解释了一个现象：优秀架构师换到新领域，一上来未必能设计出好架构，往往要几次迭代才趋稳——因为对领域需求的理解需要一个过程。所以架构师除了"在心里对需求反复推敲"的严谨，还要有对客户反馈的尊重之心。
而需求分析的核心抓手始终是:区分稳定点(核心能力)与变化点(需做扩展性设计)。
三类零件,变数在哪？
沿用冯·诺依曼三件套来逐个排查变数所在:
| 零件 | 是否有变数 | 变数在哪 |
|---|---|---|
| 中央处理器 | 已解剖清晰,不展开 | —— |
| 存储 | 有 | 主要在"计算本身"(程序):BIOS 启动程序 + 外置存储上的软件 |
| 输入输出设备 | 有 | 键盘/显示器只需驱动;主要变数在外置存储的数据格式 |
外置存储:数据怎么组织？
外置存储要保存的内容有两类:汇编源代码 + 编译出的可执行程序——是多个文件,就需要组织。组织方式并非唯一:
| 方案 | 统一抽象 | 适用 |
|---|---|---|
| 文件系统(FS) | 一棵树:节点是目录或文件,文件是叶节点,根是目录 | 通用 |
| 键值存储(K-V) | 每个文件有唯一 Key,支持 List(通配符)、Meta 元数据、Search | 早期容量极有限时也很好 |
这一步的启发:同一个需求往往有多个合理的规格选择,文件系统不是唯一可能性。
BIOS 与外置存储软件怎么分工？
分工标准很关键——BIOS 刻在主板 ROM 上,变更非常麻烦,所以它只做最稳定不变的事,越少越好。
| 需求 | 该谁做 | 原因 |
|---|---|---|
| 键盘/显示器/外置存储驱动 | BIOS | 设备不大变则驱动稳定,且是干其他事的基础 |
| 汇编编辑器 | 不是 BIOS | 交互范式模糊,有大量不确定细节 |
| 汇编编译器 | 不是 BIOS | CPU 会加指令、汇编会演进宏汇编等高阶语法 → 需迭代 |
| 执行外置存储中的程序 | 部分是 BIOS | 只做最简约的"执行引导区程序" |
关键设计是引导区:类比 CPU 加电从固定地址执行 BIOS,BIOS 也认定外置存储一个固定地址去加载并执行程序,无需关心磁盘数据格式。
引导区是 BIOS 与操作系统的边界:BIOS 只需把短小的引导程序读入内存执行,再把执行权交出去。
最终 BIOS 只负责:三类驱动 + 执行引导区程序 + 跳到固定地址移交执行权。
引导程序之后:子系统拆分
执行权交给外置存储后,剩下的需求拆成一组独立程序——这正是把变化点逐一隔离的过程:
| 子系统 | 命名 | 负责的变化点 |
|---|---|---|
| 文件系统 / K-V 存储 | —— | 外置存储的数据格式 |
| 文件管理(查询) | ls |
管理存储里有哪些文件 |
| 执行器 | sh |
用户最终会迭代出什么能力 |
| 文本编辑器 | vi |
编辑器的交互范式(其实与汇编无关) |
| 汇编编译器 | asm |
CPU 指令集迭代 + 汇编语言进化 |
sh是可自我迭代能力的灵魂:引导程序最终要把执行权交给sh。通过sh执行外置存储上的任意程序,相当于在扩展 CPU 的指令集——这就是"可自我迭代"的体现。
总结
本讲把"稳定点/变化点"框架在一个复杂例子上跑通:稳定的核心(CPU、设备驱动、BIOS)尽量少变,变化的部分(存储格式、用户能力、编辑器范式、汇编语言)各自拆成独立子系统去承接。
把变化点逐一安放
| 变化点 | 对应设计 |
|---|---|
| 外置存储数据格式 | 文件系统 / K-V 存储子系统 + ls |
| 用户会迭代出什么能力 | sh(在外置存储上执行任意程序) |
| 编辑器交互范式 | vi |
| 汇编语言使用范式 | asm(响应 CPU 指令集与汇编语言迭代) |
一句话速记
把 BIOS 这种"难改的核心"压到最小最稳,把所有会变的东西(存储格式、
sh/vi/asm)推到可独立迭代的子系统——这就是用稳定点/变化点做架构分解的范本。
几条值得记住的判断
- 需求分析占架构师三分之一精力;新领域要几次迭代才稳是正常的。
- 架构无标准答案;对比他人方案与自己的差异,才是加深决策体会的方式。
- "可自我迭代的计算机"本身就是一次需求从模糊到清晰的细化过程。
思考题
你的需求分析和系统设计跟文中的架构一致吗?不一致很正常。回到你自己的项目:有没有某个"像 BIOS 一样难改"的核心,其实承担了太多本该下放给子系统的变化点?
