如果你只能看一节编程课，我强烈建议是这一节：1986年，MIT 教授 Hal Abelson 站在黑板前，用58分钟讲了 MIT 传奇课程 6.001《计算机程序的构造和解释》（SICP）的第一课。四十年过去，编程语言换了一茬又一茬，框架迭代了几百轮，但这堂课讨论的问题至今没有过时——计算机科学到底研究的是什么？程序员的“手艺”本质上是什么？
这节课最惊艳的地方，是它开场就推翻了几乎所有人对这个学科的认知：计算机科学（Computer Science）这个名称“糟糕透顶”，它既不是科学，也几乎不关于计算机。那它关于什么？关于如何用形式化语言表达“怎么做”的知识，以及如何在人脑的极限之内控制大型系统的复杂性。
为什么今天还要安利一门38年前的录像？因为当下 AI 都能写代码了，市面上大量教程仍在教你“怎么用某个工具”，却没人告诉你这门手艺的地基是什么。工具每年更新，地基四十年不变。这一轮我们换个角度，不讲新框架、不追热点，回到源头，看这堂被无数顶级工程师奉为“编程第一课”的录像到底讲了什么，以及它对2026年的开发者还有什么用。
小提示：本篇写作环境未联网，播放量等动态数据为写作时估计值，请以视频页面实际显示为准。
| 项目 | 内容 |
|---|---|
| 视频标题 | Lecture 1A: Functions and Processes（Overview and Introduction to Lisp） |
| 频道 | MIT OpenCourseWare（官方课程录像） |
| 时长 | 约58分钟 |
| 播放量 | 百万级（MIT OCW 长期经典，估计值） |
| 主讲人 | Hal Abelson（与 Gerald Jay Sussman 轮流主讲本系列） |
| 核心主题 | 计算机科学的本质、声明式与过程式知识、黑箱抽象、Lisp 语言设计哲学 |
视频原话层面，Abelson 开场就抛出暴论：Computer Science 是 "a terrible name"。他给了两层理由。
第一，它不是科学（science）。天文学研究的是天然存在、人无法改变的天体，那是科学；而计算机系统是人造物，研究人造物的学科更接近工程（engineering），甚至像魔法——你的“原料”是想法本身，搭建的是“思想的组件”。
第二，它跟“计算机”这个设备的关系，远没有名字暗示的那么大。Abelson 用了一个绝妙的类比：几何学（geometry）词源是“土地测量”，但你不会说几何学是研究测量仪器的学问。几何学真正研究的是空间与形式的抽象规律，测量仪器只是当年催生它的场景。同理，计算机只是催生“过程的形式化表达”这门手艺的载体，而非这门学科的本体。
【延伸分析】这个祛魅在今天格外有价值。2026年大量“学编程”焦虑的根源，是把这门学科误解成了“学会某个工具的操作”——就像把几何学误解成“学会用经纬仪”。工具会被 AI 替代，而“用形式化语言组织‘怎么做’的知识”这种核心能力不会。
这是全课最核心的一组概念，Abelson 用平方根举了例子。
Declarative knowledge（声明式知识）：说的是“是什么”。比如 √x 的数学定义——“√x 是这样一个 y，使得 y² = x 且 y ≥ 0”。这个定义完美、精确，但它没告诉你怎么把 √2 算出来。
Imperative knowledge（过程式知识）：说的是“怎么做”。Abelson 引用了亚历山大港的 Heron（Heron of Alexandria）的方法：先猜一个数 g，计算 x/g，取两者的平均作为新的猜测，反复迭代，猜测会越来越接近真值。这才是一个真正可执行的“怎么做”。
数学书里也会教你第二种知识（比如“按如下步骤计算”），但它教的对象是人——人能靠直觉、常识和临场判断糊弄过去。程序员的独特之处在于：必须把过程式知识形式化到“机器可以毫无歧义地执行”的程度——机器没有常识，不容许任何“大概如此”。Abelson 称这门手艺是介于数学和工程之间的 "meta-technical" 技艺。
【延伸分析】用今天的话说：声明式知识是“接口语义/规约（spec）”，过程式知识是“实现”。AI 时代这个区分反而更锋利了——大模型擅长生成“某种实现”，但判断“这个实现是否真的满足规约”的责任，依然落在人身上。
Abelson 明确说了这门课关心的核心问题：techniques for controlling the intellectual complexity of very large systems——控制超大型系统在智力上的复杂性。
他做了一个精彩的对比。数学里的困难问题（比如数论中的未解难题）往往具有“本质复杂性（essential complexity）”——那是问题本身带来的。而大型软件系统的复杂性多半是我们自己造出来的：机器执行任意复杂的指令集毫无怨言，“受不了”的是人的大脑。既然复杂性是人造的，我们就有理由相信可以用系统化的技术手段去驯服它——这正是这门课要教的“手艺中的手艺”（discipline of discipline）。
【延伸分析】熟悉软件工程史的读者会联想到 Fred Brooks 1986 年的名篇《No Silver Bullet》中 essential/accidental complexity 的二分——这套话语在此类课程思想中已见雏形（Brooks 的著名论断可视为这一思想脉络的延伸，具体出处请以原文为准）。近年的《A Philosophy of Software Design》把复杂性定义为“让软件难以理解和修改的一切”，也完全在这条延长线上。
课程给出了描述一切语言的通用框架，也是全课的骨架。任何强大的语言——不管它面向编程、面向数学还是面向电路设计——都靠三样东西构建：
(square (+ 2 3)) 这种可无限嵌套的前缀表达式；define。Abelson 强调这个框架不是 Lisp 特有的，而是贯穿整个课程的"lens"：后面所有内容，从数据抽象到元语言抽象（写解释器），都是在更高层面反复玩这三件事。
【延伸分析】这套框架放今天依然是评估语言和框架的利器。React 的组件 + props + hooks、SQL 的表 + JOIN + 视图，都可以拆成“积木/组合/抽象”三件套。当你学一门新语言时，有意识地去找这三样东西，学习速度会明显加快——这就是“好的框架能压缩知识”的直接体现。
课程后半段，Abelson 在黑板上现场用 Scheme 写 sqrt 程序，演示了 SICP 方法论中最动人的技巧——wishful thinking（愿望思维）。
他先假设 square、average 这些“还没实现”的过程已经存在，直接写出主逻辑：(define (sqrt-iter guess x) (if (good-enough? guess x) guess (sqrt-iter (improve guess x) x)))。逻辑清晰得像在描述 Heron 的原始算法本身。然后再回过头逐个实现 good-enough? 和 improve。
这一手打破了很多初学者的写作惯性——从“我能用的积木”出发往下凑。SICP 的主张恰恰相反：先从问题出发写出“理想中的代码”，再让积木去满足愿望。每一步程序都保持可读，因为它在每一层都直接“说人话”。
【延伸分析】这就是现代软件工程里 “interface-first design” 和测试驱动开发（TDD）的思想源头之一：先定义接口契约，再填充实现。你在 review 代码时感觉“这段逻辑读起来像散文”的舒适感，本质上就是愿望思维被贯彻到位的结果。
写完 sqrt 后，Abelson 画出了那张著名的盒子图：sqrt 包着 sqrt-iter，sqrt-iter 又调用 good-enough? 和 improve。每个盒子之间只靠接口契约连接。
他抛出的观点是：作为使用者，你不需要知道盒子里是什么，甚至不妨“相信魔法（believe in magic）”。这种“局部无知”不是缺陷，而是巨型系统能被人类智力驾驭的唯一途径——每个盒子的设计者只需对自己的契约负责，使用者只依赖契约而非实现。课程的整个路线图（过程抽象 → 数据抽象 → 模块与对象 → 元语言抽象）就是不断升维地重复这个游戏。
【延伸分析】这四十年间软件工程的所有主流实践——函数库、API、微服务、开源依赖、云服务——本质上全是“盒子与契约”的不同粒度变体。你调用 fetch() 时从不关心 TCP 窗口如何滑动，这就是黑箱抽象在替你的大脑省内存。反过来说，排查线上问题时“分层收敛”（先怀疑哪个盒子违反了契约）也正是这张图的工程化应用。
课中 Abelson 被问及 Lisp 与 Pascal 的选择（这几乎是当年课堂上的必答题），他的回答点出了语言设计的历史语境：Pascal 诞生时，机器资源极其有限，语言设计优化的目标是编译成高效机器码；而 Lisp 的根是 Lambda calculus，从血统上就是为“把过程当数据摆弄、表达递归与高阶函数”而生的。这门课关心的不是让机器跑得快，而是让思想被表达得清晰，所以选 Lisp。
他还引用了 Knuth 式的文学编程精神，其中最著名的一句也写在 SICP 扉页上："Programs must be written for people to read, and only incidentally for machines to execute."（程序首先是写给人读的，只是顺便能在机器上执行。）
【延伸分析】不必抬杠“那我该学 Lisp 吗”——这不是本课的重点，Abelson 自己也说了技术是载体。真正值得带走的是判断标准：评估任何语言/工具时，问它让哪一类思想变得更容易表达，又压抑了哪一类。当年 Lisp 与 Pascal 之争，放到今天是“AI 辅助编程时代，代码的可读性与可验证性如何排序”的同构问题。
mindmap
root((SICP 1A<br/>计算机科学的真身))
祛魅：这门学科是什么
不是科学，更像工程/魔法
几何学类比：不关于测量仪器
核心是形式化表达过程知识
两类知识
Declarative 声明式
√x 的定义：y² = x 且 y ≥ 0
只说是什么
Imperative 过程式
Heron 迭代法
必须形式化到机器可执行
学科核心问题
控制大型系统的智力复杂性
复杂性多半是人造的 → 可驯服
语言三要素
Primitive 基本实体
Means of Combination 组合
Means of Abstraction 抽象
方法论演示
Wishful Thinking 愿望思维
黑箱抽象与接口契约
程序写给人读
课程路线
过程抽象
数据抽象
模块与对象
元语言抽象：写解释器
如果你是初学者：别再把“学编程”等同于“学某门语言的操作”。看完这节课，给自己立三条规矩——第一，每写一个函数，先能用一句“人话”说清它的契约（输入什么、承诺什么输出），再动手写实现；第二，写不出来时试试愿望思维：先假设理想中的辅助函数已经存在，把主逻辑写顺，再回头填坑；第三，学新语言时主动找它的 primitive/组合/抽象三件套，用框架代替死记。
如果你是有经验的工程师：这节课给你的最大增量是“复杂性观”。大型系统让人头疼的复杂度，绝大多数不是问题本质带来的，而是我们自己堆积的——这意味着它原则上可被设计消解。下次 review 时，与其纠结某行代码的写法，不如问两个更根本的问题：这个盒子的契约是否清晰到使用者可以“相信魔法”？这层抽象是压缩了复杂性，只是搬运了它？
如果你在 AI 时代思考自身定位：这堂课的四十年前预言正在应验——机器（现在还包括大模型）能执行过程，但“选择哪个过程、验证它是否满足规约、控制整体不失控”依然是有品味的工程师的价值所在。AI 把“生成代码”的成本打到近零之后，稀缺的恰恰是这门课教的东西：契约思维、复杂性品味、以及把模糊需求形式化的能力。
注：本篇写作环境未联网核验，参考来源均为长期稳定的官方/知名站点地址；播放量、时长等动态数据为写作时估计，请以页面实际信息为准。
这堂四十年前的课最大的价值，是把“编程”从一门工具手艺还原成一种思维能力——用形式化语言表达“怎么做”，再用黑箱契约把复杂性关进人类大脑装得下的盒子里。
本文由「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 等场景全覆盖。