你有没有过这种体验：打开一段三个月前自己写的代码，逐行读完，却完全想不起“我当时为什么这么写”？或者更常见的：code review 时，同事的代码每行都看得懂，连起来却不知道整体思路是什么。
2026年5月底，老牌计算机科普频道 Computerphile 上线了一期22分51秒的视频 《Human Readable Code》，主讲人是帝国理工学院的 Robert Chatley 博士。视频简介只有一句话，却直戳痛点："Knuth 在四十多年前就谈过'文学编程'（Literate Programming），但怎样才算得上是一段开发者与客户都能达成共识的代码？"
这个问题在 AI 写代码的今天尤其值得重新审视：当“写出能跑的代码”变得越来越便宜，“写出人能读懂的代码”反而成了稀缺能力。这期视频把一个诞生于1984年的老想法（高德纳 Donald Knuth 的 Literate Programming）拉回当代语境——它不是怀旧，而是一剂针对当下开发流程的解药。本文基于视频主线，结合 Wikipedia、Knuth 原始论文等资料做深度展开。
| 项目 | 内容 |
|---|---|
| 视频标题 | Human Readable Code - Computerphile |
| 频道 | Computerphile（百万级订阅的英文计算机科普头部频道） |
| 主讲人 | Dr Robert Chatley（帝国理工伦敦学院） |
| 发布日期 | 2026年5月29日 |
| 时长 | 22分51秒 |
| 播放量 | 约4.3万+（页面元数据 WatchAction 计数，截至2026年8月） |
| 核心主题 | 代码可读性、Literate Programming（文学编程）的原始思想与当代实践 |
视频的切入方式很聪明：不从理论出发，而是从一个日常场景出发——开发者和客户要在同一段代码上达成共识（视频简介原话：“code that a developer and a client can agree on”）。这个场景每个做过交付、驻场、外包的开发者都不陌生：客户不关心你的设计模式，他关心的是“这段逻辑是不是我想要的那个意思”。
这里我先给出一个（延伸）判断：这段话背后其实藏着一个更根本的立场——代码首先是写给人的文档，其次是写给机器的指令。编译器不在乎你的变量叫 data2 还是 pendingInvoiceCount，但三个月后的你和你的同事在乎。Knuth 在1984年的论文里把这个立场推到了极致：程序应该像文学作品一样，是“对人的一次阐述”，而编译器需要的顺序只是副产品。
1984年，斯坦福的高德纳（Donald Knuth）在《The Computer Journal》第27卷发表了论文《Literate Programming》，正式提出这个范式（据 Wikipedia 收录的论文信息：27卷2期，97–111页）。核心想法一句话就能说清：把程序写成一篇自然语言的说明文，代码片段以宏的形式嵌在文字中间，人类读到的是“思路的展开”，机器需要的源码则由工具从同一份文件中生成。
Knuth 最初的实现系统叫 WEB（他自嘲说选这个名字是因为它是英语里少数还没被计算机界占用的三字母词），最早可追溯到1981年为排版系统 TeX 82 服务，而他在1979年就在私底下用一个叫 DOC 的雏形——灵感来自 Pierre-Arnoul de Marneffe 的工作。后来他与 Silvio Levy 合作推出了面向 C 语言的 CWEB。这些名字和日期都有据可查，细节见文末参考来源。
文学编程的工作流只有两步，但命名堪称软件史上最优雅的彩蛋：
两个名字出自沃尔特·司各特的诗句"Oh, what a tangled web we weave when first we practise to deceive"（据 Wikipedia，这句诗作为题词出现在 Knuth 与 Jon Bentley 1986年5月《Communications of the ACM》的 Programming Pearls 专栏里）。文字游戏背后是一个严肃洞察：编译器要求的代码顺序和人脑理解的逻辑顺序，是两种完全不同的排序。传统语言强迫你按编译器的口味组织代码；文学编程让你按自己思考的顺序写作，把“翻译给机器”这件事彻底外包给工具。
视频里 Chatley 演示的核心机制（结合 Wikipedia 上经典的 wc 字数统计例子来说明）：文学编程中的宏不是 C 语言那种文本替换宏，而是一个用自然语言写成的抽象名，比如 <<扫描文件>>、<<头部文件>>。你可以在讲思路的段落里随手引用它，它的实体定义可以出现在文件的任何位置，甚至可以分散在多处逐步补充。
Knuth 说自己正是在意识到这一点后开始把程序看作“一张网（web），而不是一棵树”——这是他在《Literate Programming》中的原话。传统的设计方法论强迫你在自顶向下和自底向上之间二选一，而网状结构允许你“以心理上正确的顺序”探索一个大程序（Knuth 原话是 "psychologically correct order"，意识流式地展开）。对维护过大型遗留代码的人来说，这个描述简直是对阅读体验的精准诊断：我们理解系统靠的从来不是目录树的层级，而是局部与局部之间的关系。
这是我认为整期视频最有正名价值的一点（延伸展开）：很多人一听“文学编程”，第一反应是“哦，注释写多一点、再配个 Javadoc”——方向完全反了。Wikipedia 上专门有一节澄清这个误解：Javadoc、POD 这类工具做的是“文档生成”——文档嵌在代码里、结构跟着代码走；而文学编程是代码嵌在文档里、结构跟着文档走。
区别为什么重要？因为 Javadoc 的结构仍然被编译器强制的顺序绑架，你依然无法在“思路最自然展开的地方”放置对应的实现。Knuth 甚至在2008年的一次访谈中说：文学编程是“TeX 项目中最重要的产出”，没有它，“像 MMIX 元模拟器这种复杂度的程序，我的脑子根本处理不过来”。一个工具能让 Knuth 级别的大脑说出“ indispensable（不可或缺）”，值得每个开发者认真对待。
文学编程最硬核的反驳点是“理想主义、不实用”——但战绩摆在那里。据 Wikipedia 记载：
一个人用奇怪的方法写出一两个好程序可能是天才的偶然，但一条延续40年、横跨排版、图形学、符号计算的实践路线，就只能归因于方法本身的有效性了。
文学编程真正的大规模落地，发生在 Knuth 没预料到的地方——数据科学。据 Wikipedia 引述的研究（Schulte 2012 发表于《Journal of Statistical Software》、Kery 2018 发表于 CHI），2010年代计算笔记本的流行让文学编程工具今天被数百万程序员日常使用：
（延伸）注意一个细微差别：这些现代后裔大多保留了“文字与代码混排”，但丢掉了 Knuth 的宏系统和自由排序——Wikipedia 把它们称为“半文学（semi-literate）”工具。你拿到了可复现研究的能力，但“按人的逻辑重排代码顺序”这个最激进的创新，至今仍是小众手艺。
最后是我认为这期视频在这个时间点发布最大的现实意义（延伸分析，非视频原话）：2026年，AI 辅助编码已经普及，“让代码跑起来”的边际成本趋近于零，瓶颈全面转移到理解和审查上。一个耐人寻味的细节是：连 Wikipedia 的文学编程条目都把 "Vibe coding" 列入了相关主题——这两件事的纠缠才刚刚开始。
三个具体判断：其一，AI 生成的代码默认只有机器的“正确性”，没有人的“可读性”，review 人类写的代码尚且读不懂思路，review 千行 AI 代码更是灾难；其二，文学编程“先写意图文档、代码作为附件”的结构，恰好是给 AI 时代协作准备的接口——一份讲清楚“为什么”的文档，既能让人类 reviewer 快速对齐，也是 LLM 最优质的上下文；其三，nbdev 这类工具已经验证了“文档即源码”能让库对 AI 更友好。Knuth 在1984年问的问题——“程序应该按照谁的理解顺序来组织”——在 AI 时代有了一个他没料到的第三答案：还要兼顾 AI 的理解顺序。
graph TD
A["核心问题：代码的第一读者是谁"] --> B["编译器视角：顺序由语法决定"]
A --> C["人脑视角：顺序由思路决定"]
C --> D["Knuth 1984 文学编程"]
D --> E["同一份文学源文件"]
E --> F["TANGLE 生成可编译代码"]
E --> G["WEAVE 生成排版文档"]
D --> H["宏：自然语言短语作为抽象"]
D --> I["程序是网 web 而非树"]
H --> J["经典实践：TeX 与 pbrt 与 Inform"]
E --> K["现代半文学后裔"]
K --> L["Jupyter Notebook"]
K --> M["org-mode Babel"]
K --> N["knitr 与 nbdev"]
J --> O["2026新语境：AI生成代码时代<br/>可读性成为稀缺能力"]
L --> O
M --> O
N --> O
看完视频，你不需要立刻去学 CWEB，但可以马上做五件事：
当 AI 把“写代码”变成白菜价，Knuth 42年前的这句潜台词成了2026年开发者最值钱的护城河——代码是写给人看的，顺便让机器执行。
本文由「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 等场景全覆盖。