2026年，你随手就能搜到几千门“7天精通XX语言”的编程课，但我今天要安利的，是一条录制于近40年前的老录像——MIT课程6.001《计算机程序的构造和解释》（SICP）的开篇第一讲，主讲人 Gerald Jay Sussman。这门课被无数程序员称为“编程界的圣经课”，全套20讲至今仍在被一遍遍重看、翻译、转述。
为什么推荐它？因为现在最不缺的就是“教你怎么写代码”的内容，最缺的是回答一个更根本问题的内容：当软件系统大到没有任何一个人能装进脑子里时，我们靠什么把它管住？ 这门课给出的答案只有四个字——控制复杂度。1986年如此，2026年写微服务、玩AI编程代理，还是如此。工具换了一茬又一茬，这门课讲的东西一页都没过时，这本身就是对“什么才是编程的本质”最好的证明。
说明：本文写作环境的外部搜索与字幕抓取通道受限，未能实时打开播放页核对实时数据。视频为长青经典，其标题、时长、频道等元数据按公开流传信息归纳，播放量为量级估算，请以视频页实时数据为准。文中【视频主线】为课程内容归纳，【延伸分析】为笔者补充，两者均已标注。
| 项目 | 内容 |
|---|---|
| 视频标题 | Lecture 1A | MIT 6.001 Structure and Interpretation, 1986 |
| 频道 | MIT OpenCourseWare（另有多个转载版本） |
| 录制时间 | 1986年（SICP第一版教材1985年出版） |
| 时长 | 约58分钟（全套共20讲，1A至10B） |
| 播放量 | 百万量级（长青经典，估算值，以视频页为准） |
| 核心主题 | 软件复杂度的控制：黑盒抽象与Lisp入门 |
这一讲开场就没打算好好“讲课”。Sussman上来先拆名字：“计算机科学（Computer Science）”既不是一门科学，也不是关于计算机的学问——就像天文学不是研究望远镜的学问一样，计算机只是这门学问手里的工具，不是它的研究对象。他还举了个词源的例子：geometry（几何）的本义是“测量土地”，那是古埃及人丈量尼罗河泛滥后农田的手艺；后来几何学早已长成了完全不同的怪物，名字却懒得换了。他认为"computer science"正处于同样的尴尬里：这门学科真正研究的东西，叫"process"（过程）——如何造出、描述、控制那些在机器里跑起来的过程，以及其中最难的部分：控制大型系统的复杂度（complexity）。
【延伸分析】这段开场白是整门课的定调之笔，也解释了为什么这门课40年不过时：它教的东西和具体的机器、语言解耦。你今天换掉的是Python还是Rust，是x86还是ARM，都是“望远镜升级了”，而天文学的问题没变。
为什么偏偏软件需要专门学“控制复杂度”？Sussman给了个对比：土木工程师造桥，受材料强度约束；电气工程师设计电路，受摩擦、噪声、麦克斯韦方程组约束——自然定律替他们划了边界，超界的方案根本做不出来。而软件呢？软件的约束几乎只有一条：我们自己的脑子。 一个系统可以无限膨胀，抽象层数可以无限堆叠，唯一的天花板是人脑还能不能理解它。所以软件工程真正需要的，是一套“心理层面的工程技巧”——如何组织你的思想，让一个远超人脑容量的系统依然可以被人类团队理解和维护。
【延伸分析】这个视角能解释行业里很多现象：为什么微服务拆太碎反而更乱（复杂度只是从代码搬到了系统间通信里）、为什么“能跑就行”的项目最终都会反噬（复杂度是隐性负债，利息是后来者的理解成本）。物理世界的工程师靠定律兜底，软件工程师只能靠自己兜底——这是这份职业的原罪，也是它迷人的地方。
第一讲里，Sussman把整门课的骨架画在了黑板上，三个主题，对应三种控制复杂度的技术：
【延伸分析】第三条在今天看来尤其超前。你眼下熟悉的每一件东西，几乎都是元语言抽象的实例：SQL是对“查询”这件事发明的小语言、正则表达式是对“文本模式”的小语言、Kubernetes的YAML是对“系统拓扑”的小语言，甚至大模型的Prompt工程，本质也是“为一类任务设计表达方式”。学会站在语言设计者的角度看问题，是这门课给学习者的最大升维。
Sussman强调这门课关心的是过程性知识（imperative knowledge，“怎么做”），并把它和数学的陈述性知识（declarative knowledge，“是什么”）做了切分。他用开方举例子：数学书会写“√x 就是那个满足 y²=x 且 y≥0 的 y”——这句话完全正确，但对你算出结果毫无帮助；而牛顿法这类迭代算法，一步步告诉你“怎么逼近答案”。他说，传统数学长于陈述“是什么”，而计算机科学的独特贡献，是让“怎么做”本身成为可以被精确描述、被机器执行的严格对象。
【延伸分析】这条分界线是理解整门课的钥匙，也是理解很多技术演化的钥匙。有趣的是，计算机史上多次大浪潮，本质都是“陈述性知识”的回潮：你写SQL时说的是“我要什么”而不是“怎么遍历表”；React的声明式UI说的是“界面长什么样”而不是“怎么一步步改DOM”。过程式与声明式的钟摆摆了半个世纪，而Sussman在1986年就把两种知识的位置摆得清清楚楚——理解“怎么做”才有能力写出“是什么”。
进入正题前，Sussman给“语言”下了一个极简的定义：任何编程语言都由三样东西构成——基本表达（primitive expressions，语言里最简单的原子）、组合手段（means of combination，把原子拼成复合物）、抽象手段（means of abstraction，给复合物命名，让它变成新的“原子”）。然后他现场用Lisp演示：数字和加号是基本表达；用括号嵌套就能无限组合——(square 3) 可以嵌进 (+ (square 3) (square 4))；define 是抽象手段，给表达式起名后它就变成了新积木。他特别指出Lisp的妙处：整个语言建立在极简的语法规则上（前缀表达式、括号列表），而且程序和数据是同一种东西（都是列表），所以Lisp程序可以像数据一样被生成、被处理。
【延伸分析】“三个零件”是这节课最实用的思维工具。学任何新语言时，别被语法表吓到，直接问三个问题：它的原子是什么？怎么组合？怎么抽象？Java、Python、Rust、Go，答案的形状都一样，差别只在原子的丰富度和组合的灵活度。而“程序即数据”这一条，则是后来整个宏系统、REPL文化乃至Lisp方言家族的根——也是“元语言抽象”能在这门课里实现的技术前提。
开篇几讲里最出名的一幕，是Sussman在黑板上画出了这门课最经典的图：假设只会“加一”和“减一”两种运算，怎么算4加5？他给出两种写法。第一种，(inc (+ (dec a) b))——先把减到底的加法“推迟”住，一层层套住 inc，走到底再逐层弹回来：过程形状先鼓起一个包、再收回来。第二种，(+ (dec a) (inc b))——每一步把a减一、把b加一，状态全在参数里往前滚：(+ 4 5) → (+ 3 6) → (+ 2 7) → (+ 1 8) → (+ 0 9) → 9，形状是一条笔直的斜线。两个程序功能完全一样，但产生的过程形状完全不同：前者每推迟一步就要占一份内存，空间开销线性增长；后者空间恒定。他说，程序是写下来的文本，而过程是文本被“念动”之后活起来的东西——好的程序员要能看见自己程序的形状。
【延伸分析】这是全课哲学的第一个落点：区分“程序”（静态咒语）与“过程”（运行中的精灵）。它直接对应今天的性能直觉——递归深度、调用栈、尾递归优化、为什么循环写成递归在有的语言里会爆栈。看懂了那个“鼓包”，你就看懂了栈溢出的本质。
这一讲的第一个故事其实是寓言：古代巫师用咒语驱使精灵，Sussman说，程序员和这个行当的相似度高得吓人——咒语就是程序，精灵就是计算机。精灵的问题在于：它只按咒语的字面意思执行，从不问你真正想干什么，而且总倾向于把你的话往荒谬的方向理解。所以写咒语的人必须精确到苛刻，任何含糊都会变成一场事故。他把这门课的定位讲得很直白：你们来不是学某门语言的，你们是来学怎么精确地控制一个不懂变通的机器，怎么在思想的层面上组织庞大的系统。
【延伸分析】这个寓言放在2026年读，多了一层新意：今天的AI编码助手，恰恰也是一个“更聪明但依然按字面理解、偶尔一本正经骗你”的精灵——它不会问你的本意，只会执行你的字面意图，然后让你为结果负责。40年前这个寓言教人“对机器要精确”，今天它多了一条：对人机分工要保持清醒——意图的澄清者永远是你。
flowchart TD
A["SICP 第一课<br/>控制复杂度"] --> B["黑盒抽象"]
A --> C["常规接口"]
A --> D["元语言抽象"]
B --> E["语言三要素"]
E --> E1["基本表达"]
E --> E2["组合手段"]
E --> E3["抽象手段"]
B --> F["程序是咒语<br/>过程是精灵"]
F --> G["两种过程形状"]
G --> G1["递归：先攒后算"]
G --> G2["迭代：边走边算"]
第一，把“三零件”变成你学新语言的标准动作。 下次接触任何新语言、新框架，别从语法教程第一页开始啃，先回答三个问题：原子是什么（基本类型、内置函数）、怎么组合（表达式、管道、装饰器、泛型）、怎么抽象（函数、类、宏、模块系统）。三个问题答完，这门语言的“性格”你就掌握了七成，剩下三成是查文档的事。这套框架对评审技术选型同样好用——两门语言之争，往往争的是“组合手段”谁更顺手。
第二，写代码时训练“看见形状”的眼力。 提交一个递归函数前，先在纸上画它的过程形状：鼓包多深？每层推迟了什么？有没有办法把状态装进参数里把它拉直？这不只是防栈溢出——性能优化的多数场景（缓存、迭代化、流式处理），本质都是在改形状。看别人代码时也多问一句：这个程序“念”起来是什么形状？形状难看的过程，往往就是未来的事故现场。
第三，用“黑盒契约”管理协作边界。 黑盒抽象的精髓不是“封装”这个动词，而是“契约”这个名词：盒子的使用者凭契约拼装，实现者凭契约替换实现。团队里大量扯皮，源于契约从来没被显式写下来。接口文档、错误码规范、API版本承诺，都是“把黑盒契约钉死”的工程化手段。这也是为什么Sussman说软件的约束是脑力本身——契约就是团队共享脑力的接口。
第四，保留一点“元语言”的野心。 当你发现团队在用自然语言反复解释同一类规则时，那往往就是该发明“小语言”的信号：一套DSL、一个配置规范、甚至一套严格的模板。让规则变成可执行的咒语，而不是散落在口头和文档里的“大概如此”。
这门课用58分钟告诉你：编程不是和语法打交道，而是和复杂度打交道——程序是写给精灵看的咒语，但系统的形状，必须装得进人的脑子。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。