独立深读 · 课堂教学参考资料 · 事实核查版
计算机先驱如何看待 AI 生成代码
八位代表性先驱——从 C++ 之父到 Redis 之父——对 AI（Artificial Intelligence，人工智能；本页特指用大语言模型生成代码）生成代码的立场，按"人物身份 → 核心观点 → 教学启示"组织。 他们并非简单"排斥"AI 代码，而是围绕验证成本、系统理解、长期责任与开拓性创新各自划定边界，恰好构成一条从"严守核心系统"到"拥抱效率"的完整光谱。 本页所有言论均对照原始访谈、论文与本人博客逐条核查——"核查转发语录"这件事本身，就是第一课。
TL;DR（一句话总结）与核查方法
一句话版本：AI 改变的是"代码由谁写出来"的速度，没有改变"代码为何值得被信任"的标准。
工具在变，抽象层在升，但"理解系统、验证正确性、承担工程责任"这三件事，从 Knuth 到 Torvalds 到 Bob 大叔，没有一位先驱认为可以被跳过。
8
位计算机先驱
6
核实属实（2026-09-03 复核上调）
3
部分属实（Knuth / Carmack / Osmani）
0
未获证实（原 antirez 红标经复核撤销）
核查方法与三级状态图例
对每位先驱的每条言论，检索三类原始来源——本人论文 / 博客、直接访谈记录、权威媒体报道——比对原话后给出三级结论：
| 核查状态 | 含义 |
|---|---|
| 核实属实 | 找到原始出处，逐条有原话对应，可直接引用 |
| 部分属实 | 立场真实可溯源，但个别细节 / 数字与原始出处有出入 |
| 未获证实 | 未找到任何可靠来源，引用前需另行查证 |
2026-09-03 二次核查：这一页自己也被核查了一遍。
对 9 位人物的每条引语回溯一手来源（播客转录、论文本体、本人博客）后，本页的初版核查结论出现系统性漏判：
标记的 7 处"未找到"里有 6 处其实原话都在，命中率 14%。
最严重的是 antirez 的红色"未获证实"——三个被判"查无出处"的案例，一字不差地写在他的博客原文 antirez.com/news/158 里。
比任何一条语录都更值得记住的一课：核查者把"我没检索到"写成了"来源不存在"。 "我没查到"是对自己检索能力的陈述，"不存在"是对世界的陈述——别把前者当后者。 红标必须留给"打开一手原文逐字核对后仍无对应"的情形。
比任何一条语录都更值得记住的一课：核查者把"我没检索到"写成了"来源不存在"。 "我没查到"是对自己检索能力的陈述，"不存在"是对世界的陈述——别把前者当后者。 红标必须留给"打开一手原文逐字核对后仍无对应"的情形。
为什么先讲核查（已订正）：中文互联网流传的"大佬语录"确实大量经过概括性转述，但反向的错误同样常见——把真话误判成谣言。
本页初版曾把 Bob 大叔那句"我完全不看 Agent 代码"当成误传，理由是"原话更接近分工"；二次核查发现，
"My current strategy is to not read any of the code written by my agents" 就是他本人的原话，
"不看实现代码"与"把纪律压到外围约束"是同一立场的两个半句，并不对立（见 §3.5）。
真正该警惕的走样另有其人：Torvalds 那句流传甚广的"AI 提效 10 倍"，三个月后被他本人定性为"pulled out of my ass number"（拍脑袋数字）。 故事越动人、越具体、越有数字，越值得核查——包括核查者自己的结论。
真正该警惕的走样另有其人：Torvalds 那句流传甚广的"AI 提效 10 倍"，三个月后被他本人定性为"pulled out of my ass number"（拍脑袋数字）。 故事越动人、越具体、越有数字，越值得核查——包括核查者自己的结论。
八人立场总览（按信任度从保守到开放）
| 人物 | 身份 | 核心立场 | 关键词 | 核查 |
|---|---|---|---|---|
| Bjarne Stroustrup | C++ 之父 | 警惕派：安全 / 性能关键领域不应依赖 AI 代码（但他明确说 AI "不是没用"） | 更多 bug · 更难验证 | 核实属实 |
| Linus Torvalds | Linux 与 Git 创造者 | 工具派：AI 是生产力工具，不能替代系统理解（已把 AI 制度化进 Linux 7.0 政策） | "99% AI 代码"令我生气 | 核实属实 |
| James Gosling | Java 之父 | 批判派：AI 热潮本质是营销骗局，难处理开拓性创新 | 只能复刻见过的内容 | 核实属实 |
| Grady Booch | UML 联合创建者 | 历史规律派：抽象层上升的又一次重复，不会终结软件工程 | "完全是 BS" · 三黄金时代 | 核实属实 |
| Robert C. Martin | 《代码整洁之道》作者 | 纪律派：不看 Agent 的实现代码，用确定性规则自动判达标（但验收测试与 QA 他仍审） | "AI 代码我完全不看"（原话） | 核实属实 |
| Donald Knuth | TAOCP 作者 · 图灵奖 | 谨慎修正派：AI 可参与数学探索，证明与判断仍属人类 | "Shock! Shock!" | 部分属实 |
| John Carmack | DOOM/Quake 之父 | 工具派：语法打字从来不是重点，产品 / 问题求解才是 | 产品技能 · 价值导向 | 部分属实 |
| Salvatore Sanfilippo | Redis 之父 (antirez) | 双面派：手写代码在逻辑上已不成立，但 AI 仍"远远落后人类智能" | 5 分钟 700 行 · 20 分钟复刻 | 核实属实 |
注："核查"列依据原始访谈、论文与本人博客比对，详见 §3 各人核查结论与 §7 来源清单。
团队照：八位先驱 + Addy Osmani（按表格顺序；核查状态以小色块标记）
逐一拆解：人物 → 观点 → 金句 → 核查
3.1 · 警惕派 · 验证底线
Bjarne Stroustrup：AI 代码"更多 bug、更难验证"
C++ 之父 · Morgan Stanley 技术院士。2026 年 5 月播客访谈中用约七分钟集中回应"AI 能写好代码吗"，判断明确：
- 质量担忧：AI 代码 bug 更多、安全漏洞更多、代码臃肿、占用更多内存，性能敏感场景反而成为负担
- 验证黑洞（最深的担忧）：prompt 稍有变化代码即被重写——"你不知道它到底改了哪里"，每次都要重新审查
- 边界划分：常规应用代码机器写是大势所趋；但他关注的系统级领域（安全关键、性能关键、需监管审查），AI 的尝试"并不成功"
- 人才隐忧：资深开发者因不愿反复验证 AI 代码而提前退休，行业人才链面临系统性风险
"在我关注的领域，代码仍将由人类编写，并借助抽象来管理复杂性。"
—— India Today 采访 · 2026-05
—— India Today 采访 · 2026-05
事实核查 · 核实属实（2026-09-03 复核上调）：采访真实存在（India Today，2026-05-20，Ryan Peterman 主持），四条观点与金句在播客转录中逐字对应。
初版误判已撤销：本页曾称「LLM 复刻旧 bug」「10–20% 系统级代码」未找到——两者均为原话。转录 1:31:22："…70 or 80% of the world's code doesn't fit that pattern. But it's that 10 or 20% of the code that I'm interested in. And there, it's not there."；1:32:09："I find that LLM-based code is imitating old code and getting old performance and old bugs again."
一处重要补正：他并非全盘否定 AI。原话："AI is not useless. That's not what I'm saying. It can be used to write documentation."——他否定的是"用 AI 写安全关键 / 性能关键代码"，不是"用 AI"。
初版误判已撤销：本页曾称「LLM 复刻旧 bug」「10–20% 系统级代码」未找到——两者均为原话。转录 1:31:22："…70 or 80% of the world's code doesn't fit that pattern. But it's that 10 or 20% of the code that I'm interested in. And there, it's not there."；1:32:09："I find that LLM-based code is imitating old code and getting old performance and old bugs again."
一处重要补正：他并非全盘否定 AI。原话："AI is not useless. That's not what I'm saying. It can be used to write documentation."——他否定的是"用 AI 写安全关键 / 性能关键代码"，不是"用 AI"。
3.2 · 工具派 · 系统理解
Linus Torvalds：AI 是工具，但"99% 代码由 AI 写"让我生气
Linux 与 Git 创造者。他的态度在 2024–2026 年间经历明显演变，是讲解"条件化接受"的最佳案例：
- 三阶段演变：2024-10 "90% 的 AI 营销是炒作" → 2026-01 在业余项目 AudioNoise 中用 AI 生成 Python 音频可视化工具 → 2026-05 承认 AI 是生产力工具，如同编译器取代汇编
- 生产力标尺：编译器给编程带来约 1000 倍提升，AI 约 10 倍——"AI 辅助生产力仅为编译器的 1/100"
- 愤怒点在于责任缺席：说"99% 代码由 AI 编写"的人，100% 的代码同样由编译器编写，却从不这么说
- 底线：以代码质量而非来源作为唯一评判标准，严肃项目的开发者必须深入理解代码与系统架构
不理解系统复杂性的人，即便用提示词系统也会写出失败的程序。
事实核查 · 核实属实（2026-09-03 复核上调）："90% marketing"（Open Source Summit 维也纳，2024-10）、编译器 1000x / AI 10x、"99% vs 100% 编译器"引语、AudioNoise 项目均可溯源。
初版误判已撤销：本页曾称「核心 DSP 滤波器手动用 C 编写」未找到——多家报道确认他 "wrote the core logic in C"，Python 可视化部分才交给 AI IDE。
三条必须补充的关键事实：
① 那个"10 倍"被他本人撤回了。2026-07 在 OSS India（孟买）他承认，这个 10x 是 "not scientific… that was pulled out of my ass number"（拍脑袋数字）。引用这句时必须同时引用这句撤回。
② 他已把 AI 制度化：Linux 7.0（2026-04）发布首个官方《AI Coding Assistants》政策——AI 代码须守 GPL-2.0；禁止 AI 工具使用 Signed-off-by 标签；新增 Assisted-by 元数据标签，人类对提交负最终责任。
③ 他对反 AI 的批评者同样翻脸：明确表示 Linux 不是"反 AI 项目"，不爽可以 fork 走人。
初版误判已撤销：本页曾称「核心 DSP 滤波器手动用 C 编写」未找到——多家报道确认他 "wrote the core logic in C"，Python 可视化部分才交给 AI IDE。
三条必须补充的关键事实：
① 那个"10 倍"被他本人撤回了。2026-07 在 OSS India（孟买）他承认，这个 10x 是 "not scientific… that was pulled out of my ass number"（拍脑袋数字）。引用这句时必须同时引用这句撤回。
② 他已把 AI 制度化：Linux 7.0（2026-04）发布首个官方《AI Coding Assistants》政策——AI 代码须守 GPL-2.0；禁止 AI 工具使用 Signed-off-by 标签；新增 Assisted-by 元数据标签，人类对提交负最终责任。
③ 他对反 AI 的批评者同样翻脸：明确表示 Linux 不是"反 AI 项目"，不爽可以 fork 走人。
3.3 · 批判派 · 开拓创新
James Gosling：AI 热潮"基本上是一场骗局"
Java 之父。八人中火力最猛的一位，但别把他记成"反 AI 的人"——他也给 AI 留了明确的位置：
- 术语批判：AI 是"自带一桶有毒废料的营销术语"，本质是"高级统计方法"
- 资本批判：行业里"骗子和炒作者多到令人心智腐烂"，风险投资人只关心成功退出，绝大多数 AI 投资将被吸入黑洞
- 技术天花板（最有分量的论点）：生成式 AI 靠抓取现有代码、只能复刻见过的内容；而专业开发中真正有趣的东西从不重复，无法用已被打包成库的方式实现
- 实用定位：AI 最有价值的用途是"写没人愿意写的文档"——本质是理解代码的智能搜索引擎
"项目一旦稍显复杂，氛围编程（vibe coding）几乎总会把开发者的脑子烧穿。"
—— The New Stack《Java at 30》访谈 · 2025-05
—— The New Stack《Java at 30》访谈 · 2025-05
事实核查 · 核实属实：全部言论出自 The New Stack 的 Java 30 周年访谈（2025-05），"mostly a scam""blow their brains out" 等原话逐条对应。注意：访谈时间为 2025 年 5 月，而非部分转载所称的 2026 年。
3.4 · 历史规律派 · 抽象上升
Grady Booch：AI 不会杀死软件工程
UML 联合创建者 · IBM Fellow。对 Anthropic CEO"软件工程将在 12 个月内实现自动化"的预测作出强硬回应：
- 正面回击："客气地说，用个科学术语——这完全是胡说八道（utter BS）。我认为他大错特错。"
- 三黄金时代：① 算法抽象与业务自动化；② 面向对象思维与分布式系统；③ 平台、API 与系统级复杂性（2000 年起，并非始于 AI）
- 历史押韵：编译器出现时汇编程序员恐慌，高级语言出现时恐惧重演——每次看懂"新一层抽象"的人都赢了
- 核心判断：AI 编码助手正在减少摩擦、释放想象力，而不是取代工程师
"AI 是软件工程第三黄金时代的延续，而非革命——它不会杀死软件工程。"
—— The Pragmatic Engineer 访谈 · 2026-02
—— The Pragmatic Engineer 访谈 · 2026-02
事实核查 · 核实属实："utter BS" 回应、三个黄金时代划分、编译器 / 高级语言恐惧类比、"减少摩擦释放想象力"均出自 The Pragmatic Engineer 访谈（Gergely Orosz 主持，2026-02），逐条有原文对应。
小订正：访谈发布在 2026-02-05 前后，页面初版标注的 02-04 略有出入。
页面漏掉的地基：他敢说 "utter BS" 是因为他对软件工程下过一个定义——软件工程是"平衡力量"：物理定律（光速、算力、存储）、经济约束（成本、时间、预算）、人的因素（团队、沟通）、伦理问题（能做 vs 该做）。编码只是软件工程的一小部分，这才是他的论据核心。
页面内部对撞：Booch 公开反对同页的 Uncle Bob——"Trust, but verify. 作为经验丰富的开发者，我可以凭直觉分辨代码好坏。但没有任何智能体，能够拥有同等的实战积累与业务上下文。" Booch 完整审核智能体生成的全部代码（详见 §3.5）。
小订正：访谈发布在 2026-02-05 前后，页面初版标注的 02-04 略有出入。
页面漏掉的地基：他敢说 "utter BS" 是因为他对软件工程下过一个定义——软件工程是"平衡力量"：物理定律（光速、算力、存储）、经济约束（成本、时间、预算）、人的因素（团队、沟通）、伦理问题（能做 vs 该做）。编码只是软件工程的一小部分，这才是他的论据核心。
页面内部对撞：Booch 公开反对同页的 Uncle Bob——"Trust, but verify. 作为经验丰富的开发者，我可以凭直觉分辨代码好坏。但没有任何智能体，能够拥有同等的实战积累与业务上下文。" Booch 完整审核智能体生成的全部代码（详见 §3.5）。
3.5 · 纪律派 · 工程纪律
Robert C. Martin（Bob 大叔）：不看 Agent 代码，但纪律不能丢
《代码整洁之道》作者 · 50 年编程经历。全场被误传最严重的一位——流传句与原话是两个意思：
- 流传句 vs 原话：流传的"我完全不看 Agent 写的任何代码"，原文更接近"我让 Agent 处理代码，我负责周围的约束与验证"——前者是傲慢，后者是分工
- 纪律升级：与其逐行人肉 Review，不如建立确定性规则与工具（gauntlet：测试 + 静态检查）自动判定代码是否达标——可类比 CI（Continuous Integration，持续集成）门禁
- 识挣扎：他能看出 Agent 何时开始"挣扎"（改一处、坏一处的模式），因为作为一名程序员，他自己经历过同样的挣扎
- 新人警告："现在有人认为软件基础不重要了。他们会吃到苦头，而且不会等太久。"
"他们写代码快，我写代码慢——所以代码交给他们，我负责确保周边一切正确。"
—— X 原帖 2026-07-23 + Matt Pocock 直播访谈 2026-08-19
—— X 原帖 2026-07-23 + Matt Pocock 直播访谈 2026-08-19
事实核查 · 核实属实（2026-09-03 复核：判定依据被推翻）：确定性规则（gauntlet）、识挣扎、基础警告三条均有原文支撑。
本页初版称"我完全不看 Agent 代码"是误传——这个判断是错的。它是他 2026-07 在 X 上的原话："My current strategy is to not read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints."（2026-08-19 Matt Pocock 直播上重申："我的终极目标是彻底不用手动查看代码"）
但"不看"有明确边界——他本人给的分工表：实现代码 / 单元测试 = Agent 写、无人审（by design）；Gherkin 验收测试 / QA 流程 = Agent 写、Martin 本人审（严格度按关键性浮动）；最终手工测试 = 他定期做。
同页对撞：Grady Booch 公开反对他——"Trust, but verify"，Booch 完整审核全部 AI 代码，理由是指标无法发现安全漏洞、无效死代码、性能关键的逻辑拆分缺失。
他自己的两处松动：① 承认"测试过载"问题——"lots of times I just use unit tests and crap"；② 2026-08 承认架构自动化没走通，AI 做架构设计常产出漏洞方案，架构与模块依赖管控仍需人类主导。
本页初版称"我完全不看 Agent 代码"是误传——这个判断是错的。它是他 2026-07 在 X 上的原话："My current strategy is to not read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints."（2026-08-19 Matt Pocock 直播上重申："我的终极目标是彻底不用手动查看代码"）
但"不看"有明确边界——他本人给的分工表：实现代码 / 单元测试 = Agent 写、无人审（by design）；Gherkin 验收测试 / QA 流程 = Agent 写、Martin 本人审（严格度按关键性浮动）；最终手工测试 = 他定期做。
同页对撞：Grady Booch 公开反对他——"Trust, but verify"，Booch 完整审核全部 AI 代码，理由是指标无法发现安全漏洞、无效死代码、性能关键的逻辑拆分缺失。
他自己的两处松动：① 承认"测试过载"问题——"lots of times I just use unit tests and crap"；② 2026-08 承认架构自动化没走通，AI 做架构设计常产出漏洞方案，架构与模块依赖管控仍需人类主导。
3.6 · 谨慎修正派 · 人类判断
Donald Knuth：从"不感兴趣"到"Shock! Shock!"
《计算机程序设计艺术》作者 · 1974 图灵奖。2026 年出现标志性转折，讲这个故事本身就有教学价值：
- 标志性转折：论文《Claude's Cycles》以"Shock! Shock!"开篇——一位长期不用 AI 的大师公开震惊（三年前他还告诉 Stephen Wolfram 这个话题"绝对不适合我"）
- 事件经过：同事 Filip Stappers 将 Knuth 研究数周的有向图分解猜想交给 Claude Opus 4.6，模型找到了对所有奇数都成立的构造
- 人类收尾（关键）：Knuth 亲自写出严格证明并验证——论文由他署名发表。探索给 AI，证明与判断留给人
- 留有余地："看来有一天，我得修订我对'生成式 AI'的看法了"——修订的是能力评价，未修订的是判断标准
"看来有一天，我得修订我对'生成式 AI'的看法了。"
—— 《Claude's Cycles》论文结尾 · 2026-02
—— 《Claude's Cycles》论文结尾 · 2026-02
事实核查 · 部分属实（2026-09-03 复核：半对半错）：论文确凿存在（斯坦福官网，28 February 2026; revised 14 April 2026），已下载 6 页 PDF 全文核验。
初版误判已撤销：「一小时 31 次系统性探索」论文明文（第 4 页）："Delicious success for odd m, at exploration number 31, came about one hour after the session began."
仍未获证实（这条判对了）：「验证不超过 101 的每个奇数」——PDF 全文 0 命中，确实不存在。
引语位置订正：那句"看来有一天我得修订我对生成式 AI 的看法了"在论文开篇第二段，不是结尾。论文真正的结尾是 "Over And Out. Dear reader… We are living in very interesting times indeed."
页面漏掉的续集：4 月 14 日修订版新增参考文献 [4]–[12]，偶数情形后来被解决了——GPT-5.4 Pro 产出了一份 14 页的证明论文，Knuth 称"完全是机器独立完成的，他没有做任何编辑"；另有研究者给出了更简洁的偶数情形分解。相关代码与证明均挂在 Knuth 斯坦福主页。
存疑项：「三年前他告诉 Stephen Wolfram 这个话题绝对不适合我」——论文全文 0 次出现 Wolfram，需另行查证。
初版误判已撤销：「一小时 31 次系统性探索」论文明文（第 4 页）："Delicious success for odd m, at exploration number 31, came about one hour after the session began."
仍未获证实（这条判对了）：「验证不超过 101 的每个奇数」——PDF 全文 0 命中，确实不存在。
引语位置订正：那句"看来有一天我得修订我对生成式 AI 的看法了"在论文开篇第二段，不是结尾。论文真正的结尾是 "Over And Out. Dear reader… We are living in very interesting times indeed."
页面漏掉的续集：4 月 14 日修订版新增参考文献 [4]–[12]，偶数情形后来被解决了——GPT-5.4 Pro 产出了一份 14 页的证明论文，Knuth 称"完全是机器独立完成的，他没有做任何编辑"；另有研究者给出了更简洁的偶数情形分解。相关代码与证明均挂在 Knuth 斯坦福主页。
存疑项：「三年前他告诉 Stephen Wolfram 这个话题绝对不适合我」——论文全文 0 次出现 Wolfram，需另行查证。
3.7 · 工具派 · 价值导向
John Carmack：语法打字从来不是重点
DOOM/Quake 之父 · 前 Oculus CTO。对焦虑的年轻程序员给出非常务实的建议：
- 价值坐标："软件只是帮人们完成某件事的工具——很多程序员从未理解这一点"
- 产品技能：未来重要的是"产品技能"——盯住应用程序或服务的价值收益，而不是过度聚焦工具的具体细节
- 回应黄仁勋：针对"不必人人都学编程"——编码从来不是价值来源，解决问题的能力才是核心技能（逻辑不是否认 AI 能写，而是打字从来不是职业核心）
- 领域常新：编程职业仍有"大量机会"，但"整个领域的构成"会持续变化
"编码从来不是价值的来源——解决问题的能力才是核心技能。"
—— 回应 NVIDIA CEO 黄仁勋 · 2024-02
—— 回应 NVIDIA CEO 黄仁勋 · 2024-02
事实核查 · 部分属实（2026-09-03 复核维持）：回应黄仁勋（2024-02，World Government Summit 视频）原话逐字核实——"Coding was never the source of value, and people shouldn't get overly attached to it. Problem solving is the core skill." 后半句亦为原话："The discipline and precision demanded by traditional programming will remain valuable transferable attributes, but they won't be a barrier to entry."
补充原话（教学上很值得接上）："I suspect that I will enjoy managing AIs more, even if they wind up being better programmers than I am."
仍未获证实：「今天你仍可作为纯 C 程序员找到工作，但这已不同于 1990 年」——二次核查同样未检索到，维持不建议引用。
补充原话（教学上很值得接上）："I suspect that I will enjoy managing AIs more, even if they wind up being better programmers than I am."
仍未获证实：「今天你仍可作为纯 C 程序员找到工作，但这已不同于 1990 年」——二次核查同样未检索到，维持不建议引用。
3.8 · 拥抱派 · 创造自由
Salvatore Sanfilippo (antirez)：手写代码在逻辑上已不成立
Redis 之父。立场双面、经复核全部可溯源——他同时认为「AI 远远落后人类智能」与「自己写代码已不合逻辑」：
- 激进表态："除非为了乐趣，手写代码在逻辑上已不成立"——八人中最接近全面拥抱的立场
- 三个案例（经复核全部属实，出自 news/158 原文）：5 分钟生成 700 行纯 C 的 BERT 推理库（比 PyTorch 慢 15%）· Claude Code 自主定位并修复 Redis 测试的 TCP 死锁 · 20 分钟复刻 Redis Streams 的数周设计工作
- 真实拥抱立场：其博客确实长期拥抱 AI——《Don't fall into the anti-AI hype》直言"AI 将永远改变编程"
- 人类角色：即便拥抱，他仍强调"用直觉、设计与持续引导来驾驭过程"——人类决定方向
- 另一面（页面初版完全漏掉）：同一时期他还有 news/153《Human coders are still better than LLMs》——结论是 AI"仍然远远落后于人类智能"，因为人类能"打破常规、设想出奇特且不精确但更有成效的解法"。两句话不矛盾：前者讲智能上限，后者讲工程性价比
"it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun."
—— antirez.com/news/158《Don't fall into the anti-AI hype》· 原文可查，已替换初版那句查无出处的转述
—— antirez.com/news/158《Don't fall into the anti-AI hype》· 原文可查，已替换初版那句查无出处的转述
事实核查 · 核实属实（2026-09-03 复核：红标已撤销）：本页初版把三个案例判为"在其全部博文及第三方来源中均无对应"——这是全页最严重的误判。三个案例一字不差地写在他的博客 antirez.com/news/158《Don't fall into the anti-AI hype》正文中。
① Redis 测试瞬时失败修复：原文 "timing related issues, TCP deadlock conditions, and so forth. Claude Code iterated for all the time needed to reproduce it…" ✅
② 纯 C 的 BERT 推理库：原文 "Claude Code created it in 5 minutes. Same output and same speed (15% slower) than PyTorch." ✅
③ Redis Streams 复刻：原文 "it reproduced my work in, like, 20 minutes or less" ✅
唯一需要订正的数字：页面原写「917 行」——原文是 700 行，且他诚实补了一句"比 PyTorch 慢 15%"。已按原文修正。
页面漏掉的另一面（同样重要）：他还有一篇 news/153《Human coders are still better than LLMs》（2025-05），结论是"虽然目前的 AI 水平不错、颇具实用性，但仍然远远落后于人类智能"，理由是"人类的创造力仍有优势——我们能够真正打破常规、设想出一些奇特且并不精确、但就是更有成效的解法，而这对大模型来说则极其困难"。
所以他的立场是双面的，不是"八人中最激进的拥抱派"：他同时认为「AI 远远落后人类智能」（智能上限）与「自己写代码已不合逻辑」（工程性价比）。两句话不矛盾，这个张力正是本页最好的讨论题。
金句订正：页面原引"你永远跑不赢一支 24 小时不睡觉的编程大军"确未找到出处——本页已替换为有原文支撑的表述。
① Redis 测试瞬时失败修复：原文 "timing related issues, TCP deadlock conditions, and so forth. Claude Code iterated for all the time needed to reproduce it…" ✅
② 纯 C 的 BERT 推理库：原文 "Claude Code created it in 5 minutes. Same output and same speed (15% slower) than PyTorch." ✅
③ Redis Streams 复刻：原文 "it reproduced my work in, like, 20 minutes or less" ✅
唯一需要订正的数字：页面原写「917 行」——原文是 700 行，且他诚实补了一句"比 PyTorch 慢 15%"。已按原文修正。
页面漏掉的另一面（同样重要）：他还有一篇 news/153《Human coders are still better than LLMs》（2025-05），结论是"虽然目前的 AI 水平不错、颇具实用性，但仍然远远落后于人类智能"，理由是"人类的创造力仍有优势——我们能够真正打破常规、设想出一些奇特且并不精确、但就是更有成效的解法，而这对大模型来说则极其困难"。
所以他的立场是双面的，不是"八人中最激进的拥抱派"：他同时认为「AI 远远落后人类智能」（智能上限）与「自己写代码已不合逻辑」（工程性价比）。两句话不矛盾，这个张力正是本页最好的讨论题。
金句订正：页面原引"你永远跑不赢一支 24 小时不睡觉的编程大军"确未找到出处——本页已替换为有原文支撑的表述。
延伸：Addy Osmani 的"理解债务"（Comprehension Debt）
延伸 · 2026 年最被引用的理论框架之一
理解债务：系统存在的代码量与人类真正理解的代码量之间的鸿沟
Addy Osmani（Google Chrome / Gemini 团队，前端工程领域知名作者）提出。核心定义：
系统存在的代码量 与 人类真正理解的代码量 之间不断扩大的鸿沟。
与传统技术债务不同，它是不可见的——技术债务是代码混乱、构建缓慢；理解债务是代码干净、测试全绿，但没有人能解释为什么这样设计。
两个关键实证
- Anthropic 随机对照实验：52 名工程师学习新库，AI 辅助组后续理解测验 50% vs 对照组 67%（低 17 个百分点），调试能力下降尤为明显——卖铲子的人自己承认了代价，可信度反而更高
- 使用方式决定认知结果（博客原文数据）："帮我写出来"式委托得分低于 40%；提问式概念探究高于 65%——同一工具，怎么用决定变强还是变虚
"让代码生成变得廉价，并不能让理解变得可以跳过。理解工作本身就是工作。"
—— addyosmani.com/blog/comprehension-debt · 2026-03-14 · 实验论文 arXiv:2601.20245
—— addyosmani.com/blog/comprehension-debt · 2026-03-14 · 实验论文 arXiv:2601.20245
事实核查 · 部分属实（2026-09-03 复核维持）：概念与 Anthropic 实验全部核实——52 名工程师随机对照、学习新库（Trio）、AI 组 50% vs 对照组 67%（低 17 个百分点，p=0.010）、调试能力下降最明显，arXiv:2601.20245。
引文出处订正：「低于 40% / 高于 65%」这组数字出自另一篇《Don't Outsource the Learning》，不在 comprehension-debt 那篇里。原文："Engineers who used AI to ask conceptual questions scored above 65%. Engineers who copy-pasted the generated code scored under 40%. The tool didn't determine the outcome. The posture did."
关于"35% vs 86%（3.6 倍）"：这组数字确实出自 Anthropic 那项研究（7 种使用模式分型），只是不在该博客中——本页的谨慎处理是对的。完整分型：AI 委托 35% / 迭代式 AI 调试 24%（最慢也最差）/ 概念追问 65% / 混合式代码+解释 68% / 先生成再理解 86%（最高）。
引文出处订正：「低于 40% / 高于 65%」这组数字出自另一篇《Don't Outsource the Learning》，不在 comprehension-debt 那篇里。原文："Engineers who used AI to ask conceptual questions scored above 65%. Engineers who copy-pasted the generated code scored under 40%. The tool didn't determine the outcome. The posture did."
关于"35% vs 86%（3.6 倍）"：这组数字确实出自 Anthropic 那项研究（7 种使用模式分型），只是不在该博客中——本页的谨慎处理是对的。完整分型：AI 委托 35% / 迭代式 AI 调试 24%（最慢也最差）/ 概念追问 65% / 混合式代码+解释 68% / 先生成再理解 86%（最高）。
立场光谱与三个教学洞察
光谱方向：← 严守核心系统 ｜ 全面拥抱效率 →（位置 1 = 最保守，位置 8 = 最开放）
真实头像版（与上方光谱图同序：左 1 → 右 8）
1. Stroustrup
警惕派
2. Torvalds
工具派
3. Gosling
批判派
4. Booch
历史规律派
5. Bob 大叔
纪律派
6. Knuth
谨慎修正派
7. Carmack
工具派
8. antirez
拥抱派
| 位置 | 人物 | 派别 | 光谱理由 |
|---|---|---|---|
| 1 | Stroustrup | 警惕派 · 验证底线 | 守的是安全关键、性能关键的系统级代码，验证成本是硬约束 |
| 2 | Torvalds | 工具派 · 系统理解 | 接受 AI 提效，但要求对系统复杂性的理解不能让渡 |
| 3 | Gosling | 批判派 · 开拓创新 | 承认工具价值，但认定开拓性创新超出其能力上限 |
| 4 | Booch | 历史规律派 · 抽象规律 | 不焦虑工具，焦虑的是历史坐标系——抽象层上升的又一次重复 |
| 5 | Bob 大叔 | 纪律派 · 工程纪律 | 代码可以外包给 Agent，验证纪律必须留在人类手里 |
| 6 | Knuth | 谨慎修正派 · 人类判断 | 面对可机器判定的数学构造公开修正看法，判断标准不变 |
| 7 | Carmack | 工具派 · 价值导向 | 打字从来不是职业核心，价值在问题求解 |
| 8 | antirez | 拥抱派 · 创造自由 | 面对可快速验证的独立项目，全面拥抱效率 |
三个可教学的结构性洞察
洞察 1 · 因果链
立场随所负责系统的关键程度而保守
负责的系统越核心、生命周期越长、错误代价越高，对 AI 代码的验证要求就越严格：Stroustrup 守安全关键系统所以最谨慎，antirez 面对可快速验证的独立项目所以开放。这是教学中最值得强调的因果链——分歧本质是责任半径的分歧。
洞察 2 · 共识
"人类判断不可替代"是八人共同底线
从 Knuth 的"证明由人写"到 antirez 的"人决定方向"，八人在这一点上没有分歧——即便最拥抱的 antirez 与 Carmack，强调的也是"人类决定做什么、为什么做"。真正的争论是：判断力如何培养？这正是课堂教学的切入口。
洞察 3 · 底线
"基础还重要吗"——所有人都答：是
没有任何一位先驱认为"有了 AI 就可以不学计算机基础"。Martin 的警告最具代表性：认为基础不重要的人"会吃到苦头，而且不会等太久"。三个洞察共同指向同一个教学目标：让学生建立"责任边界"意识，而非站队"支持或反对 AI"。
四道课堂讨论题
建议节奏：每题 2 分钟思考 / 同桌讨论 + 3 分钟发言。
Q1 · 能力评价 vs 判断标准
Knuth 修订了什么，没修订什么？
他说"看来有一天我得修订我对'生成式 AI'的看法了"，但仍然亲自写出证明并署名发表论文。讨论：修订的是对 AI 哪方面能力的评价？没有修订的又是哪方面？（提示：能力评价 vs 判断标准）
Q2 · 转述走样
Bob 大叔的两句话矛盾吗？
"不看 Agent 代码"与"软件基础不过时"是否矛盾？若不矛盾，他设想的"新工程纪律"（确定性规则 + 自动判定）应长什么样？（提示：放弃的是逐行人肉 review 的形式，未放弃代码必须被验证的原则；新纪律 = CI + 测试 + 静态检查的门禁）
Q3 · 角色辩论
Amodei vs Booch 辩论
Booch 称"12 个月自动化软件工程"是 BS。请分别站在两位的立场辩论："自动化编码"与"软件工程"的区别究竟是什么？（提示：核心在责任归属——自动化可取代"写"，无法取代"为正确性负责"的主体）
Q4 · 综合排序
综合排序并解释分化
把八位先驱按"对 AI 代码的信任度"排序，并解释：为何 Knuth 选择"修订看法"，而 Gosling 选择"批判骗局"——个性差异？所处领域？还是别的？（提示：首选领域可验证性——Knuth 面对可机器判定的数学构造，一次成功足以说服他；Gosling 面对难以判定的开拓性创新；其次才是个性）
给教师的一页纸总结 + 来源清单
如果只能给学生留下一句话（Booch 历史隐喻 + Bob 大叔警示的组合版）：
"工具在变，抽象层在升，但'理解系统、验证正确性、承担工程责任'这三件事，从 Knuth 到 Torvalds 到 Bob 大叔，没有一位先驱认为可以被跳过。AI 改变的是'代码由谁写出来'的速度，没有改变'代码为何值得被信任'的标准。"
"工具在变，抽象层在升，但'理解系统、验证正确性、承担工程责任'这三件事，从 Knuth 到 Torvalds 到 Bob 大叔，没有一位先驱认为可以被跳过。AI 改变的是'代码由谁写出来'的速度，没有改变'代码为何值得被信任'的标准。"
三词记忆卡（可让学生回忆"这是谁说的"做记忆检索）
理解系统
Torvalds：不懂系统复杂性，提示词也救不了你
验证正确性
Stroustrup：最大的问题是"不知道它改了哪里"
承担工程责任
Booch：抽象层上升历史中，责任从未转移给工具
事实核查结论与原始来源（2026-09-03 二次核查复核确认）
| 人物 | 结论 | 原始出处 | 时间 |
|---|---|---|---|
| Stroustrup | 核实属实 | India Today 对其播客访谈的报道（Ryan Peterman 主持） | 2026-05-20 |
| Torvalds | 核实属实 | Tom's Hardware / The Register（维也纳峰会）；LWN.net、ClawdBytes（OSS NA 峰会）；GitHub AudioNoise | 2024-10 ~ 2026-05 |
| Gosling | 核实属实 | The New Stack《Java at 30: The Genius Behind the Code That Changed Tech》 | 2025-05 |
| Booch | 核实属实 | The Pragmatic Engineer 访谈（Gergely Orosz 主持）/ TeamDay 转录 | 2026-02-05 |
| R. C. Martin | 核实属实 | Matt Pocock 直播访谈转录（Sozai）/ ExplainX 报道 | 2026-07 ~ 08 |
| Knuth | 部分属实 | 斯坦福官网论文《Claude's Cycles》cs-faculty.stanford.edu/~knuth/papers/claude-cycles.pdf | 2026-02-28 |
| Carmack | 部分属实 | X 帖子 @ID_AA_Carmack（回应 Jensen Huang 2024-02-26 World Government Summit 演讲）；TechSpot / Brix Consulting / 腾讯新闻 / AI Something 转载 | 2024-02-26 |
| antirez | 核实属实 | 立场：antirez.com 博客（news/153、news/158 等）；三个具体案例均出自 news/158《Don't fall into the anti-AI hype》原文（REDIS TCP 死锁修复 / 5 分钟 700 行 BERT / 20 分钟复刻 Streams） | 2025 ~ 2026 |
| Osmani | 部分属实 | addyosmani.com/blog/comprehension-debt；Anthropic 论文 arXiv:2601.20245 | 2026-03-14 |
核查说明："部分属实"指立场与核心引语可溯源、个别细节或数字与原文有出入，差异已在对应人物卡说明。2026-09-03 二次核查将 Stroustrup / Torvalds / R. C. Martin 由"部分属实"上调为"核实属实"、antirez 由"未获证实"撤销红标改为"核实属实"（原判断均因未回溯一手来源而漏判），详见 §1 与对应人物卡。课堂作业建议：挑一个最感兴趣的人物，点开原始出处读原文，对比本页版本——核查没有想象中难。