本篇要回答的问题：想做架构师，是否必须成为"全才"？以及围绕需求分析、广度与深度、继承与组合、自举与交叉编译等一批读者高频疑问，许式伟逐一作答。
本讲是专栏更新三个多月后的一次集中答疑（由编辑部主持），精选了一批留言互动。它不是主线推演，而是把前面几章引发的疑惑做一次扫盲式澄清。最核心的一问就是标题——架构师与"全才"的关系；其余问答覆盖学习方法、计算本质、需求陈述、面向对象、底层运行等多个方向。本笔记按主题归类提炼，而非逐条照抄。
架构师 ≠ 全才：广度与深度怎么平衡
这是全篇的题眼，也是多条问答的共同主题。
| 疑问 | 许式伟的回答（要点） |
|---|---|
| 通才才能做架构师吗？什么都懂岂不是不精？ | 绝不是要做全才。架构师的核心是"打通经络、内力自然流通、浑然一体"。可放弃很多实现细节的专研，但要知道这些细节存在，需要时能快速钻进去 |
| 怎样算广度够了、如何做深度学习？ | 核心是把知识串起来、构建完整认知、不留疑惑。大部分知识不需深入细节，只在需要时深入，但深入时要很深 |
| 高阶技术（Docker/k8s、微服务、DevOps、AI、OpenStack…）都要学吗？ | 按需学、按精力学，更根本的是打好基础，基础也更有助于判断是否值得深入某技术 |
| 算法对中小公司用不到？ | “用不到"更准确说是"想不到”，或已有人实现你只需调用。只有懂背后道理，才知道算法的限制与适用场景 |
关键洞见：架构师掌控全局靠的不是"无所不知"，而是把知识串成一张不留疑惑的网——平时不钻细节，需要时能瞬间深入。“广度"的标准不是面面俱到，而是"经络打通”。
需求分析：怎样才算一个合格的"需求"
| 疑问 | 回答要点 |
|---|---|
| 如何确定需求中哪些是稳定的？关注到什么层次？ | 需求分析的重要性怎么强调都不过分，是良好架构的基础。优秀架构师换新领域常需几次迭代才趋稳——除了反复推敲的严谨，更要有对客户反馈的尊重之心 |
| “我要做一个最小机器人系统，怎么考虑变化点/稳定点？” | 这是典型的需求陈述误区。合格的需求必须含三要素：① 用户（面向什么人群）② 他们要解决的问题 ③ 解决问题的核心系统。三者齐备才谈得上分析稳定点/变化点 |
关键判断：脱离"用户 + 问题"去谈稳定点与变化点是无源之水。"最小机器人系统"只说清了核心系统，缺了人群与问题，根本无法推演什么稳定、什么易变。
面向对象：继承 vs 组合
| 疑问 | 回答要点 |
|---|---|
| 为什么说继承是过度设计？不用继承拿什么替代？ | 继承只用接口继承；正常情况优先用组合；因多数语言组合能力不够强，继承可适度使用，但要意识到过度使用继承对工程有害 |
| Java 里基类+子类的复用，Go 怎么用组合实现？ | 这是受继承思维影响。继承把代码复用与多态两件事揉在一起；Go 里组合负责复用、接口负责多态，彼此独立、非常清晰 |
| 编程框架与编程范式有何区别？ | 框架通常是领域性的（如面向消息编程是多核网络服务器的框架）；范式是普适性的，不论什么领域都适用 |
精选留言（@有铭）补充了一条历史线索：对象范式的原始概念只有"对象 + 消息"，并不含类与继承；C++ 大行其道后 OOP 被扭曲为 COP（面向类编程），而 Go/Rust 等正把它拉回 OOP 本来面目——印证了"组合优于继承"。
底层运行：自举、交叉编译与 IO
| 疑问 | 回答要点 |
|---|---|
| BIOS 之前那段程序怎么跑？编译器能独立于 OS 吗？ | 程序运行不需要 OS，有 BIOS 把控制权交出即可；编译器可独立于 OS，且应先于 OS 产生 |
| 语言自举怎么实现？先有鸡还是先有蛋？ | 演进链：机器码 → 汇编 → C → C 写的汇编 / C 写的 C（自举）；靠交叉编译（C → 新平台的 C）一次性完成语言向新架构的迁移，无需每次重来 |
| 交叉编译是什么？ | 编译器本质是格式转换器（高级语言→机器码）。目标格式不必是当前运行环境；若目标格式恰好不是当前 CPU+OS，就是交叉编译 |
| 磁盘 IO 是 CPU 做的吗？"CPU 只能操作内存"矛盾吗？ | 所有外设都统一以**数据交换（IO）**方式操作。可把 CPU 理解成"一根网线"——它不负责磁盘 IO，但要等其结束以接收数据 |
| "交互也是一种计算能力"怎么理解？ | 广义计算包含有副作用的函数（有 IO 的函数），因为数据交换本身就是计算的需求，否则计算无法与现实世界相互作用 |
关键洞见：编译器先于操作系统、程序运行只需 BIOS——这些回答都在强化一个底层认知：操作系统并非计算的前提，它只是后来抽象出来的便利层。
总结
这篇答疑的主线是为"架构师必须是全才吗"祛魅：不必——架构师要的是把知识串成不留疑惑的网，平时不钻细节、需要时能极深地钻进去。其余问答反复回到三块基本功：严谨而尊重反馈的需求分析、组合优于继承的设计观、对底层运行机制（自举/交叉编译/IO）的透彻理解。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 架构师 ≠ 全才 | 核心是打通经络、串起知识网，而非无所不知 |
| 广度的标准 | 不留疑惑、构建完整认知；深入只在需要时，但要很深 |
| 需求三要素 | 用户、要解决的问题、核心系统——缺一不可才能谈稳定/变化点 |
| 组合 vs 继承 | 组合负责复用、接口负责多态；过度继承对工程有害 |
| 自举 / 交叉编译 | 机器码→汇编→C→自举；交叉编译让语言一次迁移到新平台 |
| 广义计算 | 含有副作用（IO）的函数，使计算能与现实世界相互作用 |
一句话速记
当架构师不是要"什么都精"，而是把知识串成一张不留疑惑的网——平时不钻细节，需要时一钻到底。
几条值得记住的判断
- “算法用不到"实为"想不到”：懂原理才知道何时该用什么算法。
- 一个合格的需求必须先说清用户与要解决的问题，否则谈不了稳定点/变化点。
- 继承把复用与多态揉在一起，Go 用组合+接口把它们拆清，更工程友好。
思考题
回看你最近一次"我要做一个 XX 系统"的表述，是否也犯了"最小机器人系统"那样的需求陈述误区——只说了核心系统，却没说清用户是谁、要解决他们的什么问题？补全这三要素后，你对其稳定点与变化点的判断会有什么不同？
