# 代码是写给人的：Knuth文学编程启示 ## 导语：一个42年前的问题，在2026年变得更尖锐了 你有没有过这种体验：打开一段三个月前自己写的代码，逐行读完，却完全想不起“我当时为什么这么写”？或者更常见的：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（文学编程）的原始思想与当代实践 | ## 核心内容拆解 ### 1. 问题的起点：代码的第一读者到底是谁？ 视频的切入方式很聪明：不从理论出发，而是从一个日常场景出发——**开发者和客户要在同一段代码上达成共识**（视频简介原话：“code that a developer and a client can agree on”）。这个场景每个做过交付、驻场、外包的开发者都不陌生：客户不关心你的设计模式，他关心的是“这段逻辑是不是我想要的那个意思”。 这里我先给出一个（延伸）判断：这段话背后其实藏着一个更根本的立场——**代码首先是写给人的文档，其次是写给机器的指令**。编译器不在乎你的变量叫 `data2` 还是 `pendingInvoiceCount`，但三个月后的你和你的同事在乎。Knuth 在1984年的论文里把这个立场推到了极致：程序应该像文学作品一样，是“对人的一次阐述”，而编译器需要的顺序只是副产品。 ### 2. 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**。这些名字和日期都有据可查，细节见文末参考来源。 ### 3. TANGLE 与 WEAVE：一份源文件，两种输出 文学编程的工作流只有两步，但命名堪称软件史上最优雅的彩蛋： - **Weave（编织）**：从源文件生成给人看的排版文档； - **Tangle（缠结）**：从同一份源文件生成给编译器看的代码。 两个名字出自沃尔特·司各特的诗句"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 专栏里）。文字游戏背后是一个严肃洞察：**编译器要求的代码顺序和人脑理解的逻辑顺序，是两种完全不同的排序**。传统语言强迫你按编译器的口味组织代码；文学编程让你按自己思考的顺序写作，把“翻译给机器”这件事彻底外包给工具。 ### 4. 宏即思想：用自然语言短语造“算子” 视频里 Chatley 演示的核心机制（结合 Wikipedia 上经典的 `wc` 字数统计例子来说明）：文学编程中的宏不是 C 语言那种文本替换宏，而是一个**用自然语言写成的抽象名**，比如 `<<扫描文件>>`、`<<头部文件>>`。你可以在讲思路的段落里随手引用它，它的实体定义可以出现在文件的任何位置，甚至可以分散在多处逐步补充。 Knuth 说自己正是在意识到这一点后开始把程序看作“**一张网（web），而不是一棵树**”——这是他在《Literate Programming》中的原话。传统的设计方法论强迫你在自顶向下和自底向上之间二选一，而网状结构允许你“以心理上正确的顺序”探索一个大程序（Knuth 原话是 "psychologically correct order"，意识流式地展开）。对维护过大型遗留代码的人来说，这个描述简直是对阅读体验的精准诊断：我们理解系统靠的从来不是目录树的层级，而是局部与局部之间的关系。 ### 5. 被误解40年：文学编程不是“给代码写注释” 这是我认为整期视频最有正名价值的一点（延伸展开）：很多人一听“文学编程”，第一反应是“哦，注释写多一点、再配个 Javadoc”——**方向完全反了**。Wikipedia 上专门有一节澄清这个误解：Javadoc、POD 这类工具做的是“文档生成”——文档嵌在代码里、结构跟着代码走；而文学编程是**代码嵌在文档里、结构跟着文档走**。 区别为什么重要？因为 Javadoc 的结构仍然被编译器强制的顺序绑架，你依然无法在“思路最自然展开的地方”放置对应的实现。Knuth 甚至在2008年的一次访谈中说：文学编程是“TeX 项目中最重要的产出”，没有它，“像 MMIX 元模拟器这种复杂度的程序，我的脑子根本处理不过来”。一个工具能让 Knuth 级别的大脑说出“ indispensable（不可或缺）”，值得每个开发者认真对待。 ### 6. 血统高贵的实践者：从 TeX 到拿了奥斯卡的 pbrt 文学编程最硬核的反驳点是“理想主义、不实用”——但战绩摆在那里。据 Wikipedia 记载： - **TeX 和 METAFONT** 都是 WEB 写成的，是文学编程的概念验证，TeX 全部带注释源码出版为《TeX: The Program》（五卷本《Computers and Typesetting》的 B 卷）； - 图形学名著《Physically Based Rendering》（pbrt）整本书就是一个文学程序，“数学理论与工程实现互为正文”，**这本书还拿到了奥斯卡技术成就奖**； - 交互小说语言 Inform 是迄今最大的文学程序之一；Knuth 本人还把700行 FORTRAN 写成的游戏《巨洞冒险》（Colossal Cave Adventure）改写成了一本解释代码的“小说”。 一个人用奇怪的方法写出一两个好程序可能是天才的偶然，但一条延续40年、横跨排版、图形学、符号计算的实践路线，就只能归因于方法本身的有效性了。 ### 7. 现代复兴：你的 Jupyter Notebook 就是“半文学编程” 文学编程真正的大规模落地，发生在 Knuth 没预料到的地方——**数据科学**。据 Wikipedia 引述的研究（Schulte 2012 发表于《Journal of Statistical Software》、Kery 2018 发表于 CHI），2010年代计算笔记本的流行让文学编程工具今天被数百万程序员日常使用： - **Jupyter Notebook**：文字、代码、图表、公式混排，可执行——“探索式编程”路线； - **Emacs org-mode + Babel**：一份纯文本文档里嵌入多种语言的代码块，可共享数据、可导出； - R 生态的 **knitr/Sweave**：动态统计报告的事实标准； - **nbdev**（fast.ai 出品）：直接在 notebook 里开发 Python 库，代码、测试、文档三位一体。 （延伸）注意一个细微差别：这些现代后裔大多保留了“文字与代码混排”，但**丢掉了 Knuth 的宏系统和自由排序**——Wikipedia 把它们称为“半文学（semi-literate）”工具。你拿到了可复现研究的能力，但“按人的逻辑重排代码顺序”这个最激进的创新，至今仍是小众手艺。 ### 8. 2026年的新回响：AI 写代码的时代，人读代码反而更贵 最后是我认为这期视频在这个时间点发布最大的现实意义（延伸分析，非视频原话）：2026年，AI 辅助编码已经普及，“让代码跑起来”的边际成本趋近于零，瓶颈全面转移到**理解和审查**上。一个耐人寻味的细节是：连 Wikipedia 的文学编程条目都把 "Vibe coding" 列入了相关主题——这两件事的纠缠才刚刚开始。 三个具体判断：**其一**，AI 生成的代码默认只有机器的“正确性”，没有人的“可读性”，review 人类写的代码尚且读不懂思路，review 千行 AI 代码更是灾难；**其二**，文学编程“先写意图文档、代码作为附件”的结构，恰好是给 AI 时代协作准备的接口——一份讲清楚“为什么”的文档，既能让人类 reviewer 快速对齐，也是 LLM 最优质的上下文；**其三**，nbdev 这类工具已经验证了“文档即源码”能让库对 AI 更友好。Knuth 在1984年问的问题——“程序应该按照谁的理解顺序来组织”——在 AI 时代有了一个他没料到的第三答案：还要兼顾 AI 的理解顺序。 ## 知识结构图 ```mermaid 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生成代码时代
可读性成为稀缺能力"] L --> O M --> O N --> O ``` ## 实战启示 看完视频，你不需要立刻去学 CWEB，但可以马上做五件事： 1. **下次写 PR 描述时，先写“思路展开”，再贴代码。** 把设计动机、被否决的方案、关键取舍用三五句话说清楚——这就是最小可行的 weave，review 效率的提升立竿见影。 2. **探索性工作用 notebook，沉淀时补“文学化”。** 用 Jupyter 探索，定稿时把“为什么这么做”的段落补全再转成模块——nbdev 证明了这条路能一路走到发布 PyPI 库。 3. **给变量和函数命名时借用“宏思维”。** 名字应该是一个“自然语言的抽象短语”，让调用处的代码读起来像人话——这正是 Knuth 宏系统留给普通编程语言的遗产。 4. **与客户对齐需求时，试试可执行文档。** 与其甩 PPT，不如给一份“文字讲解 + 可运行片段”的文档，让客户亲眼确认逻辑——这正是视频标题“Human Readable Code”的原始场景。 5. **为 AI 写好文档，就是为未来写好 prompt。** 一份思路清晰的 README 和模块文档，既是给人的，也是给 LLM 的最高质量上下文。投入回报率可能是你今年技术债偿还清单里最高的一项。 ## 延伸学习路径 1. **Knuth 1984年原始论文**《Literate Programming》（DOI: 10.1093/comjnl/27.2.97）——一切的原点，30页读透“程序是网”； 2. **pbr-book.org**——《Physically Based Rendering》全文免费在线，体验“一本书即一个程序”的最佳样本； 3. **nbdev 官方文档与 fast.ai 课程**——把文学编程思想落地到现代 Python 工作流的最短路径； 4. **Emacs org-mode Babel 手册**——如果你是 Vim/Emacs 用户，这是最接近 Knuth 原意的现成工具； 5. **Computerphile 同频道关联视频**——如《Fuzzing Programs to Find Bugs》《The "Trick" that Compilers Use for Long Division》，延续“工程细节背后原理”的观看脉络。 ## 一句话总结 当 AI 把“写代码”变成白菜价，Knuth 42年前的这句潜台词成了2026年开发者最值钱的护城河——**代码是写给人看的，顺便让机器执行**。 ## 参考来源 1. [Human Readable Code - Computerphile](https://www.youtube.com/watch?v=SJocPm2E8eQ) — 本文分析的核心视频（2026-05-29发布，时长22:51） 3. [Knuth, D. E. (1984). "Literate Programming". The Computer Journal 27(2): 97–111](https://doi.org/10.1093/comjnl/27.2.97) — 文学编程原始论文 4. [Physically Based Rendering 在线阅读版](https://pbr-book.org) — 文学编程的奥斯卡获奖样本 5. [Computerphile 频道页](https://www.youtube.com/channel/UC9-y-6csu5WGm29I7JiwpnA) — 主讲人与频道信息（频道由 Jane Street 赞助） --- > 本文由「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 等场景全覆盖。