五位软件大师谈 AI 编程

Created on 2026.9.9

2026   ·   ai   programming   software-engineering   interview   analysis   ·   ai

年龄与编程时间均截至 2026 年 9 月 9 日；“编程时间”按公开资料中可确认的起始时间估算。

Bjarne Stroustrup

来源： 《C++之父：贝尔实验室、负开销抽象与错误》

提问 · 瑞安

[1:28:51] 当我观察当今的行业时，越来越多的代码是由机器而不是人类编写的。我觉得很多编程语言的设计都在考虑如何让它适合人类解决问题和编写代码。我很好奇您是否认为如果越来越多的代码由模型和机器编写，编程语言设计是否会改变。

回答 · 比亚内

我认为在我最感兴趣的领域，代码仍然会由人类编写，并且他们会使用抽象。我见过的人工智能在这个领域生成代码的尝试的例子并没有成功。它们会产生更多的错误、更多的安全漏洞。他们的代码臃肿，这再次让人悲观，因为你使用了更多的内存，而且很难验证。验证它所需的高级开发人员已经开始退休，因为他们不想处理每次更改代码或提示时都会更改的内容的验证。此外，我考虑的很多事情都涉及监管机构的验证。您必须能够验证您所做的更改。当你做出改变时，AI、工具都会改变，即使你在提示中做了微小的改变，很多代码也会改变，你必须再次检查。

我看到他们中的一些人开始退休，因为他们不想处理每次在代码和提示中进行更改时都会更改的内容的验证。此外，我考虑的很多事情都涉及监管机构的验证。您必须能够验证您所做的更改。当你做出改变时，AI、工具都会改变，即使你在提示中做了微小的改变，很多代码也会改变，你必须再次检查。

所有生成的代码都比人类编写的代码了解更多。当人类做出改变时，它会做出局部的改变。您可以寻找局部更改的影响。如果人工智能写了它，你实际上不知道它在哪里被改变。你必须尝试弄清楚这一点。因此，如果您正在做以前已经做过很多次的事情，例如编写标准网络应用程序，那么您所说的是正确的。

此外，人工智能也并非毫无用处。我不是这个意思。它可以用来编写文档。同样，它必须经过人工验证，但它有助于编写内容。擅长文字。至少现在，它不擅长安全关键、性能关键的代码。现在，假设世界上 70% 或 80% 的代码不符合这种模式。但我感兴趣的是那 10% 或 20% 的代码。而且，它不在那里。

我不认为 LLM 模型会带来这种情况。此外，当接受训练数据时，它必须使用旧代码进行训练。在我看来，我的工作是确保人们编写新东西并使用对旧代码进行改进的新技术。我发现基于 LLM 的代码正在模仿旧代码，并再次获得旧的性能和旧的错误。也许你可以改进这一点。我听说 Bjarne 应用程序正在编写适合我的作品的传言，但即使这样也是有问题的，因为我所说的与 20 年前不完全相同。

但无论如何，我们拭目以待。此外，甚至 Dijkstra 也在研究这种可能性，他声称将自然语言作为编程语言的想法是愚蠢的。他比我没礼貌。我认为像英语这样的语言是非常灵活的，我们说的话往往是非常模糊的。我们需要一种精确的编程语言，即工程、数学；这不是英语。

提问 · 瑞安

[1:33:48] 对于那些对性能或安全至关重要的代码，我想会有一些人使用法学硕士。根据您所说的，直觉是您会预见到更多的损坏和错误，因为它是无效的。

回答 · 比亚内

真正擅长这类事情的人往往不想花所有时间进行验证。另一个问题是他们想淘汰初级程序员，因为初级程序员数量很多。但如果这样做的话，高级程序员从哪里来呢？我们会看到的。我的意思是，十年后你可以再问我同样的问题，会有更多的知识。毫无疑问，我说的有些话是不正确的。我的猜测是我所说的一些内容在十年内将是正确的。人工智能支持者总是告诉我，问题要么已经解决，要么在下一个版本中得到解决。但我听说 Anthropic 4.7 比 4.6 存在更多问题，原因我不明白。认为下一个版本将解决问题的想法始终是一个危险的假设。而且，它变得越来越贵。

如果你必须建造一个耗资 1 亿美元的中心并为其使用和运行电力，那么需要多少初级开发人员才能更便宜？他们开始需要钱。这并非没有问题。我所处的子领域可能比大多数领域都存在更多问题。

Anders Hejlsberg

来源： 《TypeScript 之父：TypeScript 提速 10 倍，为什么 AI 不会取代软件工程师》

提问 · Ryan

[14:49] 在从 JavaScript 移植到 Go 的过程中，我很好奇你们用了多少 LLM。我知道有几个著名的大项目在做整个代码库的重写，比如有个叫 Bun 的 JavaScript 项目把所有东西从 Zig 重写成了 Rust……看起来这是个挺有用的手段。我很好奇你们在这个过程中是否利用了它。

回答 · Anders

用得不多，但这和时间点有关。我们是两年前开始这个项目的，而两年前的 LLM 远不如现在这么好。你看这一切发展得多快。不过我们当时确实有一堆辅助移植的工具。扫描器（scanner）和解析器（parser）的原型是我们手工写的。到那个时候，我们已经能让自己确信：哇，我们真的能从中获得 10 倍的提升。

那么剩下的代码库怎么办？我们的做法是写了一个在语法层面把 TypeScript 翻译为 Go 的工具。翻译出来的代码没有语法错误，但也编译不过——它把类型当作 TypeScript 的类型来用，但 Go 里并不是那样的。所以所有这些都必须重构，我们必须重做所有数据结构之类的。但我们由此得到了一个对应的代码库，然后就可以在这个基础上逐步打磨，偶尔以更局部的方式用 AI 来帮我们做一些转换。

所以整个过程是手工、自动化加一点点 AI 的结合。如果今天重新开始这个项目，我们会换种做法吗？可能会。不过我要说，如果我们直接把 AI 放开，让它翻译我们旧编译器那大约 50 万行——或者说 50 万到 100 万行之间的代码——我不认为这样就能免除我们逐行仔细检查产出物的责任。我们必须确认其中没有幻觉（hallucination）。除非你有 100% 完美的测试覆盖率，否则你可能还是得去检查所有东西。坦率地说，我认为更好的方法是让 AI 帮你写一个程序，一个帮你把 TypeScript 翻译成 Go 的程序。因为这样你就可以把随机性”封存”在那个程序里，之后每次运行都能得到确定性的行为——每次运行都会得到相同的转换结果。

人们总是忘记 AI 的这个特点：它不是确定性的。你无法相信它两次会做出同样的事情。我们本来可能会那样做，但当时 AI 还没准备好。这并不意味着我们现在不在后续工作中使用 AI。我们在编译器的内部流程中大量使用 AI，就像所有人一样。比如帮忙写测试、处理 pull request 之类的。

每当有人提交 issue，我们做的第一件事就是让 Copilot 上，看看它能不能帮我们修复。就是这种方式。

提问 · Ryan

[18:13] 也就是你用 LLM 来生成工具，然后工具本身是确定性的，但你还是得验证那个东西本身。

回答 · Anders

是的，但那需要验证的表面积要小得多，对吧？说实话，我在朋友身上也见过同样的情况。我们一起旅行，回来后要算账——他付了酒店房费，我们付了这个那个的，需要把账目理清楚。于是我们说：好吧，这是所有的费用明细，让 AI 帮我们算清楚——谁该给谁多少钱。

结果它非常自信地给出了错误答案。因为它忘掉了其中几笔结算。但如果我们让它写一个电子表格——那其实就是一个程序——我们就能得到正确答案，因为它非常擅长写程序。这挺有意思的：有时候你不该直接问 AI 要答案，而应该让它写一个能算出答案的程序。

提问 · Ryan

[23:28] 在这个 AI 很可能有能力重写代码库的新时代，我想人们会开始转向他们”想要”的语言，而不是那些”既有”的语言。我很好奇你是否认为 JavaScript 未来可能会被用得越来越少。

回答 · Anders

我不这么认为。我观察到的是：AI 最擅长的是它在训练集中见得最多的语言。AI 是用世界上存在的所有代码训练的，这意味着有海量的 JavaScript、海量的 TypeScript、海量的 Python，因此 AI 擅长 JavaScript、TypeScript 和 Python。而我刚发明的那门小众语言，它就不太擅长了。事实上训练集里一行都没有，这意味着你必须在提示词里牺牲掉不知道多少个 token 来教 AI 这门语言，然后才能开始问它关于这门语言的问题。所以从这种意义上说，我认为既有语言反而会因为 AI 而更加繁荣。我们现在在 TypeScript 身上也看到了这一点，对吧？TypeScript 的采用率曲线上有一个明显的拐点，恰好与 AI 的出现同步。我确实认为既有语言实际上正在变得更强，而不是更弱。

提问 · Ryan

[25:31] 如果把这个趋势延伸下去，你认为最终 TypeScript 会成为默认选择、几乎所有 JavaScript 都会带类型吗？

回答 · Anders

当然会。我的意思是，如果你让 AI 来写代码，我敢说你几乎找不到一个还在写 JavaScript 的工具——它们全都在写 TypeScript。因为类型注解能引导 LLM 写出更好的代码、犯更少的错误；而且我们能在代码运行之前对它做静态验证。这就是关键区别，对吧？验证 JavaScript 的唯一方法是运行它，这意味着你必须搭一个运行时环境——而 AI 未必做得到，因为 AI 生活在沙箱里。但 AI 可以通过工具运行编译器，检查它刚生成的代码，然后被告知：”哦，你犯了个错误。”

提问 · Ryan

[49:14] 我觉得很有意思的一点是：在你的一次演讲中你说过，因为 AI 的存在，工具链的速度如今更加重要了。我想听听你为什么这么认为。

回答 · Anders

是这样的：我们的工作流越来越多地被在后台狂奔的智能体（agent）主导——它们在替你写代码。它们和我们一样会犯错，但你可以想要多少个就有多少个。所以生态系统里多了许许多多”小工人”，在写多得多的代码。而整个工作流对 LLM 来说本来就已经有性能挑战了。

如果你在一个大项目里写代码，每次 LLM 写点东西你都得做类型检查、一检查就是两分钟。那太可怕了。所以让这件事变快是极大的收益。

提问 · Ryan

[51:16] 你谈 AI 的时候非常现实、非常扎根于软件工程实践。所以我想把我在网上听到的一些常见 AI 论断拿出来，听听你觉得它们有多准确、你认为它们何时或者是否会成为现实。第一个论断——这在去年年底特别流行——是：AI 将在一年内写出 90% 以上的代码。

[51:49] 我很好奇你怎么看。

回答 · Anders

嗯，对于某些类别的应用，可能确实如此——比如所有”凭感觉写代码”（vibe coding）的应用，100% 的代码都是 AI 写的。而且确实有大量这样的东西在被写出来。但它们会写出互联网上 90% 的高质量代码吗？我对此表示怀疑。事情是这样的：如今代码总量的暴涨，九成都是这么来的。因为 AI 写了太多代码。所以从某种意义上说，这是一个自我实现的预言，对吧？但说到那种从来没有人写过的超高质量代码——我看不出 AI 能写出其中的 90%。

提问 · Ryan

[52:35] 那么想到 AI 无法包办所有代码的场景时，你能举些”超高质量代码”的例子吗？那是什么样的？

回答 · Anders

比如说，从来没人见过的算法，或者某些特定的解决方案。我是说，我知道 AI 写不出我们的编译器——TypeScript 编译器，它就是写不出来。我们试过，它做不到。我也不是非要它做到——我并不指望它做到。但我们的编译器也不是一段典型的代码。这正是 AI 写不好的原因：训练集里没有这样的代码。它见过一些编译器，但没见过这样的——没有这些概念，没有用我们这种方式做的。所以它在那个方向上就是不合适。我们不能忘记：AI 本质上是一台巨大的随机性机器，它记住了整个互联网。并且能在记忆的基础上做一定程度的外推。但如果它以前没见过，它就未必能做得多好。它在变好——我不是说它不令人印象深刻，它能做的事简直惊人——但我只是觉得，离”包办一切”还有很长的路要走。而且我不知道我们是否真会到那一步，我倒希望不要。因为到了那一步人类还有什么意义呢？

提问 · Ryan

[54:09] 还有一个我常看到的论断：一年之内你就不再需要用 IDE 了，或者说你再也不需要读代码了。

回答 · Anders

那就祝你好运吧。我是说，如果你要把钥匙都交给 AI，那一切就不好说了，对吧？等到 AI 修不好这个 issue、或者实现不了你想要的新功能的那一刻，你打算怎么办？如果你根本不理解底层是什么，你怎么办？

这是问题之一。另一个问题是：假设一个用户跑来找你说”你的应用偷走了我银行账户里的钱”——好吧，他们要起诉的是你。他们会起诉你，而不是 AI。我的意思是，归根结底，总得有人为 AI 的所作所为负责。如果你把钥匙交给了它，那责任就在你身上。但我不觉得……就我个人而言，如果我对自己担保的东西一无所知，我会睡不着觉的。

提问 · Ryan

[55:13] 为什么你的这种看法和我从 Anthropic 之类公司的人那里听到的观点差别这么大？

回答 · Anders

区别在于：我在这里说的并不是 AI 不能做惊人的事情——它能，它每天都在做。但人们就喜欢把事情一路推到 100%，对吧？而我恰恰在这一点上要打住了。我觉得：哦，是的，好吧，比例当然可以越提越高，但总得有个人理解正在发生什么、理解它与我们的业务问题有何关联。还得理解它与我们组织正在做的事情有何关系。还有那么多别的事情需要被连接起来……所以我认为，把事情看成”AI 包办了所有工作，而我们完全没有必要存在”，这种观点是错的。

提问 · Ryan

[56:04] 是的。我接下来想问的是：三年后，AI 会取代初级软件工程师、或者取代今天初级软件工程师所做的工作吗？

回答 · Anders

嗯，如果真会，那我们从哪儿得到高级软件工程师呢，对吧？我的意思是……我不这么认为。除非你也相信，再过三年你也可以在没有任何高级软件工程师的情况下运营你的业务。

因为他们从哪里来呢？总得有人培养他们，对吧。但对我来说，我认为某种程度上已经发生的一个变化是：对于某些类别的程序员，金字塔的底部变窄了。新进来的人变少了，而我们希望他们更快地向上走，好让他们能尽早进入那种更具监督性质的角色。我认为软件工程师这门手艺确实正在改变：从你自己敲一行行代码，变成你让智能体敲一行行代码，而你来审查智能体的工作。

所以你会做更多审查、更少敲键盘。有些人热爱这种方式，并且非常擅长这样的工作流。但作为程序员，这份工作的性质确实在改变，而你工具箱里新添的这件工具正在产生这种影响。但它终究只是一件工具，过程中仍然有程序员参与——这一点我深信不疑。

Linus Torvalds

  • 年龄： 56 岁（1969 年 12 月 28 日出生）
  • 编程时间： 约 45 年；1981 年前后开始在 Commodore VIC-20 上编程，1991 年开始开发 Linux
  • 资料： Britannica、 Linus Torvalds 简介

来源： 《Linux之父：Linus Torvalds 谈 AI 与 Linux 内核开发》

提问 · Dirk Hohndel

还是我通常会问的问题：“发生了什么？进展如何？”

回答 · Linus Torvalds

我过去总说一切运转良好、进展顺利，一直在稳步前进。但大约半年前，情况发生了变化。

后来事实证明我错了。

我喜欢这些工具。我觉得它非常有用，也很有意思。但它确实正在制造一些痛点。

2000 年前后，我不得不改变自己的工作方式，因为随着 Linux 项目不断发展，我原来的方式已经无法继续扩展。我至今仍记得，那是内核开发过程中最痛苦的阶段之一。而那确实已经是 25 年前的事情了。我认为，如今 AI 正在带来一些相同的影响，迫使人们走出自己的舒适区。

这个邮件列表上的人数很少，因为一切都被认为需要高度保密，而我们却把全部时间花在将报告转发给更熟悉相关领域的开发者上。我们修改了政策：如果你通过 AI 发现了安全漏洞或任何其他错误，基本上都应该把它视为公开信息。因为既然你能用 AI 找到它，其他一百个人也同样能用 AI 找到。

只需要让人们知道问题是什么，不必准确告诉他们怎样在周五下午让某个人的生活变得极其悲惨。

提问 · Dirk Hohndel

如果所有 AI 发现的错误都被视为公开信息，这是否会让维护者始终处于被动状态？

回答 · Linus Torvalds

遗憾的是，我认为我们无法绕开这个问题。

公平地说，有时发现错误确实比修复错误容易。

冲突并不在于 AI 很糟糕，而在于这种新工具带来了一些社会协作上的关卡和痛点。

实际上，我对整件事非常乐观。

但想想其他成千上万个由人们维护的普通项目，它们并不是 Linux 内核。

提问 · Dirk Hohndel

是否使用了一些优秀工具来帮助代码审查、理解补丁或改进其他工作流程？

回答 · Linus Torvalds

哦，对。我们的确会使用 AI 工具。

你不会希望完全受制于那些大公司，因为它们终有一天会决定：哦，我们也需要赚钱。

提问 · Dirk Hohndel

会给刚刚开始职业生涯的人哪些建议，以及他们应该把注意力放在哪里？

回答 · Linus Torvalds

AI 是一款优秀的工具，但终究只是一款工具。

我几乎可以保证，他们 100% 的代码都是由编译器编写的，但他们从来不会这样说。

这就像你们都会使用编译器来生成代码一样。你们所有人——好吧，也许不是所有人，但很多人——都会使用 AI 生成源代码，再由编译器处理这些源代码，然后由汇编器生成机器码。这是一场革命，但其意义与我们以前见过的那些革命相同。AI 会把你的生产率提高十倍。

而我认为编译器让你的生产率提高了一千倍。所以 AI 很棒，但 AI 并没有改变编程。它或许正在改变其他领域，别误会，但我是个程序员，所以我不关心那些。

如果项目需要长期维护，你不仅需要理解自己的提示词，还需要理解最终结果，因为这是你能够长期维护它的唯一方式。

antirez

  • 年龄： 49 岁（1977 年 3 月 7 日出生）
  • 编程时间： 职业编程经历约 28 年；1998 年已有全职安全研究工作并开发 hping，2009 年开始开发 Redis
  • 资料： antirez 个人网站、 antirez 的相关回忆

来源： 《Redis之父：不要陷入“反 AI”的炒作》

该文为 antirez 撰写的文章，不是采访，因此没有采访者提问。

我热爱编写软件，一行一行地写。可以说，我的职业生涯就是一场持续不断的努力：写出精良、极简、以”人的温度”为根本特质的软件。我也希望社会不会遗忘那些落在最后的人。此外，我并不希望 AI 在经济上取得成功，我也不在乎当前的经济体系是否会被颠覆（说实话，如果它朝着大规模财富再分配的方向发展，我会非常高兴）。但是，如果我对软件和社会的理念妨碍了我的判断，我就无法尊重自己和自己的才智：事实就是事实，AI 将永远改变编程。

2020 年，我辞去工作，写了一部关于 AI、全民基本收入，以及一个在重重挑战中适应工作自动化的社会的小说。2024 年底，我开设了一个 YouTube 频道，专注于 AI、它在编程任务中的应用，以及它潜在的社会和经济影响。虽然我很早就意识到将要发生什么，但我以为在编程被彻底重塑之前，我们还有更多时间，至少还有几年。现在我不再这么认为了。最近，最先进的大语言模型（LLM）已经能够独立完成大型子任务或中型项目，几乎不需要人工协助，只要给它们一组关于最终结果应该是什么样的良好提示。你所能取得的成功程度，与你所做的编程类型有关（越独立、越能用文本表示的就越好：系统编程尤其合适），也与你向 LLM 传达问题的能力有关——即在头脑中构建问题的表征。但总的来说，现在已经很清楚：对于大多数项目，亲自写代码已经不再明智，除非是为了乐趣。

在过去的一周里，仅仅通过写提示词，并时不时检查代码、提供指导，我在几个小时内完成了以下四项任务——是几个小时，而不是几周：

  1. 我修改了我的 linenoise 库以支持 UTF-8，并创建了一个行编辑测试框架，它使用一个模拟终端，能够报告每个字符单元格中显示的内容。这是我一直想做、但难以证明其工作量合理的事情——毕竟只是为了测试我的一个业余项目。但如果你只需描述你的想法，它就能变成实实在在的代码，情况就大不相同了。
  2. 我修复了 Redis 测试中的偶发性失败。这是非常烦人的工作：与时间相关的问题、TCP 死锁情况等等。Claude Code 不知疲倦地迭代，直到复现问题，然后检查进程状态以弄清发生了什么，最终修复了这些 bug。
  3. 昨天，我想要一个纯 C 库，能够对 BERT 类的嵌入模型进行推理。Claude Code 在 5 分钟内就创建了它。与 PyTorch 输出相同，速度相当（慢 15%）。700 行代码，外加一个用于转换 GTE-small 模型的 Python 工具。
  4. 在过去的几周里，我对 Redis Streams 的内部实现进行了修改。我为这项工作写了一份设计文档。我试着把它交给 Claude Code，结果它在大约 20 分钟甚至更短的时间内就重现了我的工作（大部分时间还是因为我检查和授权运行所需命令的速度太慢）。

想要对正在发生的现实视而不见，根本是不可能的。在很大程度上，编写代码已经不再必要。如今更有趣的是理解要做什么，以及如何去做（而关于第二部分，LLM 也是很好的伙伴）。AI 公司能不能收回成本、股市会不会崩盘，都不重要。从长远来看，这些都无关紧要。某个独角兽公司的这个或那个 CEO 对你说了些令人反感或荒谬的话，也不重要。无论如何，编程已经永远改变了。

对于我写的那些被 LLM 吞噬进去的代码，我作何感想？能成为其中的一部分，我感觉很棒，因为我把这看作是我一生努力的延续：让代码、系统和知识民主化。LLM 将帮助我们更快地写出更好的软件，并将让小团队有机会与大公司竞争——就像 90 年代开源软件所做的那样。

然而，这项技术太重要了，不能掌握在少数几家公司手中。就目前而言，你的预训练做得好不好、你的强化学习是否比别人有效得多，都不是决定性的——开源模型，尤其是中国开发的那些模型，仍在与封闭实验室的前沿模型竞争（即使处于落后位置）。到目前为止，AI 的民主化程度还算足够，尽管并不完美。但是：情况会永远如此吗？这绝非显而易见。我对集中化感到恐惧。与此同时，我相信神经网络在足够大的规模下简直能够做出不可思议的事情，而目前的前沿 AI 内部并没有那么多”魔法”，不足以阻止其他实验室和团队追赶上来（否则就很难解释，为什么 OpenAI、Anthropic 和 Google 的成果多年来一直如此接近）。

作为一名程序员，我现在比以往任何时候都更想写开源软件。我想改进我那些因时间原因而被搁置的仓库。我想把 AI 应用到我的 Redis 工作流程中，改进 Vector Sets 的实现，然后是其他数据结构，就像我现在对 Streams 所做的那样。

但我为那些将被解雇的人感到担忧。目前尚不清楚其中的走向会是怎样：公司会尝试雇用更多人、构建更多东西吗？还是会尝试削减薪资成本，只留下更少但更擅长写提示词的程序员？而且，恐怕还有其他领域，人类将变得完全可以被替代。

那么，社会层面的解决方案是什么？毕竟创新无法被收回。我认为，我们应该投票给那些认识到正在发生什么、并愿意支持失业者的政府。而且，被解雇的人越多，要求选出能保证一定程度保护的政府的政治压力就越大。但我也期待 AI 可能带来的好处：科学的新进步，可以帮助减轻人类处境中的苦难——人类的处境并不总是幸福的。

无论如何，回到编程上来。我的朋友，我只有一个建议给你。无论你相信”正确的事”应该是什么，你都无法通过拒绝当下正在发生的事情来控制它。避开 AI 不会对你或你的职业生涯有任何帮助。好好想想吧。去测试这些新工具，认真地、花上几周时间去用，而不是用五分钟的测试来强化自己既有的观念。找到一种放大自己能力的方法；如果对你暂时不起作用，每隔几个月再试一次。

是的，也许你觉得自己曾经那么努力地学习编程，而现在机器在替你做了。但当你写代码写到深夜、只为看到项目跑起来的那一刻，你内心的那团火焰是什么？是”构建”。而现在，如果你找到了有效使用 AI 的方法，你可以构建得更多、更好。乐趣依然在那里，未曾改变。

DHH

来源： 《DHH：编程的未来、AI、智能体工程、氛围编程与 Linux》

提问 · Lex Fridman

13 个月前，我们坐下来谈论编程，然后一切都改变了。当时，你对AI 在编程过程中的作用有点怀疑，然后我们经历了智能体工程的快速演变。首先问一个简单的问题：您对AI 在编程中的作用的看法发生了怎样的变化？你兴奋吗？你害怕吗？

你的情绪是否像坐过山车一样？

回答 · DHH

不存在任何生存威胁。这对我来说并不作为情感成分存在。它只是作为一种智力成分存在，而对我来说，情感成分是 100% 纯粹的、不掺杂任何杂质的快乐——……以及我们让计算机做到这一点的乐观和惊讶。我觉得我们 13 个月前的谈话非常有趣，因为这就像我们在不同的宇宙、不同的时代进行谈话。我喜欢这句话。我认为是列宁。有几十年什么都没有发生，也有几周发生了几十年。我们在过去九个月里看到了数十年的进步。我的意思是，想象一下当莱特兄弟起飞时你就在那里。

昨天，《纽约时报》还会写道：“我们还要一万年才能飞起来。”第二天，人类就已经升上天空；仅仅几年后，跨大西洋航班也出现了。整个世界彻底改变。能亲历那一刻是何等幸运。把视角拉远，纵观人类历史，有多少人一生始终活在出生时的同一个时代，从未见证世界与社会彻底改变？而我有幸经历了两次：从互联网之前到互联网之后，如今又从 AI 之前走向 AI 之后。这是多么不可思议的经历，多么幸运。

所以即便回头看一年前的对话，我的观点其实并没有改变。一年前，我不喜欢当时那种 AI 使用方式：要么是自动补全，要么是 AI 聊天机器人。聊天机器人我其实很喜欢，正如我们当时谈到的，它从一开始就是出色的导师，也是在线查资料的好方法；但它并不能取代我亲手雕琢代码。后来，智能体出现了。

智能体们开始感到好奇大约五分钟，然后他们变得惊讶，然后他们得到，“天哪，这是 AGI 吗？”所有这一切都发生在去年以来，甚至就在过去九个月内。我们这里基本上有这几个阶段。我们在前智能体时代拥有人工智能。我对此感到兴奋，但这并没有从根本上重写我的游戏规则。这并没有完全改变我的工作方式。我还在敲代码，我只是有一个小帮手，一个小助手——

…谁可以提出想法，我可以以更有效的方式在线查找这些信息等等。这只是一种更有效的方式来完成我已经在做的事情，并且它并没有改变我与计算机的情感联系。然后我们到了 2025 年 11 月 24 日。Opus 4.5 对我来说是分界线，突然间……我什至没有在 24 日尝试过。我想我26号就试过了。我给它分配了几个任务，我意识到输出的质量与我编写的内容惊人地接近。我记得我只是向后靠去想，“刚刚发生了什么？”

“我们怎么会从夏天还在讨论的那团自动补全乱象，在短短几个月后走到这里？智能水平和可用性怎么会同时提升这么多？”这里的关键是智能体运行框架。我不知道 Opus 4.5 是否真的比夏天的 Opus 4 聪明很多，但它操控计算机、调用工具、检查自身工作，并把智能用于完成真正有意义任务的能力，已经完全不同。我认为，几乎每个在圣诞假期里认真关注并亲手尝试过它的人，都经历了这种巨变。

但我必须坐在驾驶座上。我必须告诉它我想要什么，并且我必须成为即将发布的内容的审阅者和审计者。最后，今年夏天，随着 Opus 5、Fable、Sol、GPT Sol，以及在较小程度上的一些开放权重模型，我们已经到达了一个新时代，我不会告诉它我们要去哪里。我告诉它我遇到的问题。我告诉它我的模糊想法。它告诉我我们要去哪里。它告诉我该走哪条路，我仍然会关注它，因为我是一个好奇的人，我喜欢计算机，我喜欢它的结果，但我真的有点不需要。我在生成选择路线的代码的部分中变得可选。

与查看地图相比，它们很神奇，但你仍然想注意。它会开车送你到港口吗？我记得这些报纸文章。 “啊，GPS，它们很糟糕，因为人们不注意，它们在港口里行驶。” GPS 上次在港口开车是什么时候？就像，这样的事情不会再发生了。事实上，汽车现在只是自动驾驶，对吧？这就是我们现在所达到的目标，我可以相信。对于我现在工作的领域，我可以信任它，并且完全有信心它会支持我。它不会做一些愚蠢的事情，如果它做了一些愚蠢的事情，它也能够恢复。

提问 · Lex Fridman

但我认为对于该领域来说，它接近 100%，然后还有像您一样正在操作的领域，即编写 Linux 发行版。在那里，也许还有更多，因为你痴迷于速度和所有类似的东西。在那里，也许您需要多看一下代码。然后可能还有安全关键系统，一直到运行核电站或自动驾驶汽车。也许您需要更仔细地查看代码。

回答 · DHH

是的，但话虽如此，AI 在发现-

…并修复安全漏洞。这就是Fable 的整个爆发过程。该模型非常能够发现攻击者可以利用的漏洞，因此发布它根本不安全。因此，讽刺的是，当你观察这个领域时，我们似乎已经达到了几乎没有人类可以匹敌的智能水平，因为许多安全漏洞都是关于将组合动作串在一起的。你在这里发现了一个小漏洞，它本身可能并不是世界上最糟糕的事情，但是当你将它与其他四个漏洞结合起来时，突然间你就拥有了 RCE，即远程命令执行。能够做到这一点的人类非常罕见。他们通常在国家资助的组织或其他秘密组织内工作。他们不只是出去寻找东西。

所以他们在这方面做得非常好。 Linux 发行版是我 100% AI 被抛弃的原因。因为过去三个月我一直在开发 Omarchy，所以几天前刚刚发布的这个版本称为 Quattro。几乎从一开始我就在开发这个版本，智能体加速接近 100%，在过去两个月里一直是 100%。

… Quattro 中手动发送的任何代码。我已经回顾了所有这些的形状。我已经审查了系统模型层中所有关键内容的各个行，但没有查看一堆 UI 代码。我没有看过一堆辅助代码，也没有完全手工编写任何新功能。但 Web 部分，实际上是不断发展的 Basecamp 和 Hey，我们拥有大量用户且代码库相对较大的专业产品，事实证明，要通过智能体完全加速是非常困难的。

我们早期就出现了这样的想法：“问题已经解决了。我们可以让设计师进行编程。他们知道自己想要什么功能。他们知道自己想要什么形状。让他们感受到。”我们让他们产生共鸣。我们最终得到了很多 PR，这些 PR 单独来看可能在热门时刻是合理的，但总的来说，破坏了系统的架构。事实上，我们必须手动清理，用手拖地，用人的手，才能回到一个感觉有凝聚力和连贯性的建筑。所以我们仍然有一些这样的事情——顺便说一下，那是二月。现在情况已经大不相同了。

一旦你让人类团队一起工作某件事，瓶颈很少会出现在实施上。这是人类的带宽和沟通。当你有一名产品经理、几名设计师、一名副总裁和一名首席技术官时，每个人都想成为塑造过程的一部分，因为我们都在证明我们在这里的理由，那就是所有生产力都会消亡的地方。过去三个月我在 Omarchy 工作中得到的启示是，要获得神奇的 10 倍、100 倍（在极少数情况下）甚至 1000 倍的生产力提升，你必须直接与智能体交互，并且你无法与另一个人协调该带宽，因为它太慢了。

提问 · Lex Fridman

所以，在这个智能体时代，你如何采取步骤来实际构建一些解决你的问题的东西，我认为这是一种美丽的构建方式，但也将其扩展为对其他人真正有用？比如，您可以提供什么建议吗？您是否也看到了为自己构建一个工具是多么容易的问题？

回答 · DHH

是的，但比你想象的要简单。当您自己构建完该工具后，您只需告诉您的智能体将其放在 GitHub 上即可。你甚至不需要做任何其他事情。它将弄清楚如何将该存储库放在 GitHub 上。它会写一个很好的自述文件。它将开始使用 GitHub 版本，以便您可以跟踪事情。它实际上会成为比你更好的软件维护者——……因为它比你更有耐心，在管理开源软件的苦差事上也比你更勤奋。

您可以继续享受使用您构建的软件的乐趣，并按照您认为合适的方式对其进行改进。现在，这成为我们在开源领域一段时间以来一直存在的争论。AI 的贡献对于维护者来说是好事还是坏事？现在有很多维护者对他们突然收到大量拉取请求感到非常不安，这些拉取请求来自那些可能不是最好的程序员或根本不是程序员的人……对他们的软件的贡献。我看着这个论点，然后说道：“你在开玩笑吗？”这里有一系列免费贡献，你可以接受也可以不接受，但你却抱怨它们的存在？听起来很直接——我的牛排太多汁，我的龙虾太黄油。你在抱怨什么？

我不需要查看所有错误、重复或错误的拉取请求。智能体可以帮我把这些废话清除掉。我只是看看珍珠 - ……准备好的好主意，智能体代表我在虚拟机中验证的错误修复。所有复制和管理开源项目的苦差事都以闪电般的速度消失，我们留下了金黄多汁的部分，软件开发的骨髓——……决定这个东西应该做什么以及应该去哪里？

我认为这已经不再是真的了。我看到了你们这些人无法相信的事情，从模型中产生的想法是如此伟大，这让我感到谦卑——……作为一个以拥有好想法而自豪的人。智能体具有令人难以置信的创造性思维能力，而那些仍然停留在智能体是鹦鹉学舌的分析中的人们……只是重复已经存在的想法，对过去六到九个月所取得的进展产生了妄想。

提问 · Lex Fridman

所以问你这个问题是一件很有趣的事情，因为你很长一段时间以来一直在谈论，比如，详细凿凿美丽的 Rails Ruby 代码，但现在你在几个月内就不再这样做了。那么，您当前的设置是什么样的？因为，我认为，你仍在寻找美感、凿凿、工艺，但你只是在不同的媒介中进行工艺。

回答 · DHH

以及不同的抽象层次。当我使用 Ruby 代码工作时，我们有很多 Ruby 代码，因为它涉及我们的整个业务，并且我要求智能体对这些代码进行更改，但我仍然担心细节。我逐渐意识到，这些汗水所带来的经济回报正在迅速减少。25 年来，我之所以如此明智地编写每一行代码，是因为我知道保持架构的连贯性和可塑性的回报是软件可以改变和发展——

…用一个小团队快速完成，并且成本不高，并且当你改变一件事而不是另一件事时不会引入一堆错误。这是为什么你应该编写漂亮的代码的主要经济论据，因为漂亮的代码更容易理解，更简单，更具可塑性。这是以人类进行修改为前提的。我认为这在多大程度上仍然重要是一个悬而未决的问题。现在，这确实很重要，我之所以这么说，至少目前是因为token仍然稀缺。此时此刻，我们的token都是有限的。好吧，不是全部，但任何没有无限预算的人都会受到象征性的限制。

手写代码的浪漫化已经发生了。我有一些因为那是一个非常浪漫的时代。我很庆幸自己已经活了 20 年，手写代码具有经济价值。那是，那是一段美好的时光。

如果我明天必须找到一份工作，我不太可能以这样的方式应用我的技能，从而获得报酬来编写这些手动代码行，我是否感到难过？不，我已经这样做了 25 年。就像，我想在这里看到一些新的东西，特别是如果我们都能永远活着，但我希望我们不会。也许我们会做到这一点。但是，就像，我已经做到了。这就够了。没关系。我对此的怀念并不比我不必把时间花在拿着锄头在地里或在装配线上的事实更令人怀念。

如果你对编程唯一喜欢的就是将正确的逻辑结构放在一起以产生其他人告诉你要产生的东西的机械部分，那么你将很难应对新的现实。因为机械过程正受到威胁。正如您刚才提到的，如果您对构建事物感到兴奋，我认为您根本不会受到威胁。

提问 · Lex Fridman

因此，在社会层面、宏观经济层面，增长无疑是令人兴奋的。但在个人层面上，将会有很多焦虑，可能会有很多痛苦。因此，作为建议，如果你现在就像一个年轻的 DHH 或年轻的开发程序员，你会怎么做，你会建议他们做什么？

回答 · DHH

不要试图预测任何事情。你真的会发疯的。因为即使是业内最聪明的大脑也无法预测从这里开始的两个模型跳跃会是什么样子。这绝对是浪费时间，你会患上AI 精神病，试图推断两年后会是什么样子。专注于现在，现在是进入计算机领域最不可思议的时刻。如果你愿意努力，你就能让他们做出最令人惊奇的事情。

编者点评：哪些观点成立，哪些有误或尚无证据

本章是编者点评，不属于以上五位受访者或作者的原始表述。点评只针对本文摘录的原话，不涉及各人在其他场合的发言。判断依据为截至 2026 年 9 月可以查到的公开研究和项目实践。个人体验、价值判断和未来预测无法简单判为“正确”或“错误”，因此下文分成三类：成立的观点指有公开证据或工程共识支持；事实有误的表述指对技术机制或事实的描述不准确；尚无证据或被夸大的表述指方向可能正确，但目前缺少可核验的依据。

Bjarne Stroustrup

成立的观点

  1. 安全关键、性能关键的软件必须经过严格验证。 航空、医疗、汽车、内核和基础设施软件不能只看功能测试是否通过，还可能需要静态分析、形式化验证、可追踪需求和监管认证。NIST 关于生成式 AI 的安全软件开发实践与 OpenSSF 的 AI 编程助手安全指南都要求 AI 生成的代码进入与人写代码同等、甚至更严格的审查流程。

  2. 自然语言不能完全替代精确的工程规约。 自然语言适合描述目标，但容易遗漏权限、并发、时序、精度、兼容性和故障恢复等约束。它可以成为编程入口，却不能自动成为完整、无歧义的规格说明。

  3. LLM 会受到旧训练数据的影响。 模型更擅长常见语言、框架和既有解决方案，也可能重现过时 API、不安全用法和低效模式。因此，AI 生成代码仍需编译器、测试、静态分析和专家审查。

  4. 淘汰初级岗位可能破坏人才培养链条。 这是合理的组织风险。高级工程师需要通过实现小任务、调试、代码审查和处理真实故障来成长。如果这些机会全部被 AI 接管，企业必须设计新的训练方式。

事实有误的表述

  1. “人类只做局部修改，AI 会改变很多地方”不是 AI 的固有属性。 智能体可以被限制为提交小型差异；人类重构同样可能产生大范围变更。决定可审查性的是变更规模、版本控制、测试和架构，而不是作者是否为 AI。

  2. “LLM 只是在模仿旧代码”不符合模型的工作方式。 模型并非数据库式复制器，它能组合训练中学到的模式并生成未曾逐字出现的实现。不过，任务越新颖、跨度越长，可靠性通常越低，因此 Bjarne 的风险判断仍然有价值。

尚无证据或被夸大的表述

  1. “AI 会产生更多错误、漏洞和臃肿代码”缺少比较基线。 斯坦福的对照实验确实发现使用 AI 助手的参与者写出了更不安全的代码，但“更多”取决于模型、任务、开发者水平以及是否引入测试反馈。把它当作 AI 的普遍属性，现有证据还不够。

  2. “70%～80% 是普通代码，10%～20% 是关键代码”没有统计来源。 这些比例只能视为说明问题的估算，不应作为行业数据引用。

Anders Hejlsberg

成立的观点

  1. 大型迁移中，确定性转换工具通常比逐文件随机生成更可靠。 让 AI 帮助编写一个 TypeScript 到 Go 的转换程序，再重复执行、比较和修正，比让模型分别改写数十万行代码更容易审计。

  2. 不能因为 AI 能生成代码就跳过验证。 采样、上下文和工具环境都可能使结果变化。把随机生成限制在较小范围，再交给确定性程序处理，可以缩小需要验证的表面积。

  3. 类型系统、编译器和 LSP 对智能体很重要。 类型信息能增加约束，编译器则能提供快速、可执行的错误反馈。“生成—编译—修正”的循环比仅凭自然语言判断结果可靠。

  4. AI 更擅长训练数据丰富的语言。 JavaScript、TypeScript 和 Python 拥有大量公开代码、库和示例，模型通常比处理全新或小众语言更稳定。AI 因此可能进一步强化成熟语言的网络效应。

  5. 软件责任最终属于开发者和组织。 “用户起诉的是你，而不是 AI”准确指出了法律和产品现实。AI 可以辅助实现，但目前不能成为责任主体。

事实有误的表述

  1. “AI 记住了整个互联网”不是准确的技术描述。 LLM 是对训练数据统计模式的有损压缩与泛化，不是可以精确查询整个互联网的数据库。模型可能记忆部分内容，但不会逐字保存全部训练语料。

尚无证据或被夸大的表述

  1. “AI 写不出 TypeScript 编译器”是当前观察，不是长期结论。 Anders 给出的依据是团队实际尝试后的结果，这个观察本身可信；但它反映的是当前模型能力和工作流的限制，不能推断为永久边界。

  2. TypeScript 使用率上升与 AI 同期，不证明 AI 是原因。 类型安全、编辑器支持、生态成熟和大型项目采用同样可能推动 TypeScript 增长。这里存在相关性，但没有建立因果关系。

  3. 初级工程师不会被取代仍是预测。 人才培养的论证很有说服力，却不能保证企业保留现有岗位结构。更可能的结果是初级工作的内容和准入要求发生变化——这一点 Anders 自己也提到了“金字塔底部变窄”。

Linus Torvalds

成立的观点

  1. AI 是工具，不会自动消除程序员的责任。 无论代码由人、代码生成器还是 LLM 产生，提交者都必须验证行为、处理缺陷并承担发布责任。Linux 内核的 AI 编程助手指南同样要求由人审查代码并签署开发者来源证书（DCO）。

  2. 长期维护要求开发者理解最终结果。 测试只能覆盖已知场景，无法证明系统满足所有隐含约束。如果团队只会编写提示词，却不能解释代码和架构，就很难处理未知故障和后续演进。

  3. 未验证的 AI 报告会消耗维护者资源。 curl 项目因 AI 生成的漏洞报告泛滥，先写下《Death by a thousand slops》，又在 2026 年 1 月终止了 bug bounty。Linus 本人在 2026 年印度开源峰会上也表示，直到当年年初，内核收到的 LLM 垃圾产出仍多于有用代码，而分辨一份看似合理的报告是否为幻觉会严重消耗资源。

事实有误的表述

  1. “AI 发现的漏洞应视为公开”不是普遍安全原则。 这是 Linux 为处理重复报告而在 7.1-rc4 公告中采用的项目策略，其前提是“你能用 AI 找到，别人也能”。对于新颖、难以自动发现的漏洞，这个前提不成立，协调披露仍然必要。

尚无证据或被夸大的表述

  1. “AI 会把生产率提高十倍”没有证据。 现有受控实验结果差异极大：METR 对资深开源开发者的随机对照实验测得速度反而下降约 19%，GitHub Copilot 的对照实验在单一任务上测得提速约 56%，Google 的企业内随机对照实验测得约 21%。没有研究支持普遍的十倍提升。Linus 后来在 2026 年印度开源峰会上也承认这个数字“不科学”、是随口说出来的。

  2. “编译器把生产率提高一千倍”同样不是统计结论。 这里没有定义生产率指标、比较基线和测量方法，只能把它理解为强调编译器价值的修辞。

antirez

成立的观点

  1. 能够调用工具和读取反馈的智能体，已经超越单纯自动补全。 Claude Code 反复运行测试、检查进程状态并修复偶发故障，展示了智能体循环的实际价值。对于有编译、测试或参考输出的任务，AI 可以持续尝试。

  2. 任务越独立、越容易用文本描述和自动验证，AI 越容易成功。 明确上下文和验收标准能减少模型猜测隐含需求的概率，快速反馈则让错误可以在循环中被纠正。

  3. 程序员的工作正在转向问题定义、规格和验证。 随着代码生成变得廉价，决定做什么、如何验收以及结果是否值得维护，会占据更高比例。

  4. 应该认真试用工具，而不是用五分钟体验下结论。 智能体工作流需要学习如何提供上下文、拆分任务和设置反馈。短暂试用确实不足以公平评估工具。

  5. 模型集中化与就业风险值得重视。 模型、算力和平台掌握在少数公司手中会形成依赖；生产率提高也可能带来扩张或裁员两种不同结果。

尚无证据或被夸大的表述

  1. “对大多数项目，亲自写代码已经不再明智”是过度外推。 这个结论来自少数由顶级程序员设计、具有明确反馈的成功任务，不能代表需求模糊、历史复杂、缺少测试或高风险的项目。

  2. 几分钟生成代码不等于几分钟完成工程。 生成约 700 行代码只是开始，还需检查许可、边界条件、数值精度、性能、可移植性和长期维护成本。

  3. “LLM 会让我们写出更好的软件”没有保证。 “更快”在部分任务中成立，“更好”则取决于架构、测试、审查和维护。DORA 2024 报告发现，AI 采用率上升的同时，交付吞吐量和变更稳定性反而下降，说明速度与质量不会自动同向。

  4. AI 公司的经济可持续性并非无关紧要。 如果工具依赖长期补贴、服务关闭或价格大幅上涨，开发工作流和开放竞争都会受到影响。这与 antirez 自己对平台集中化的担忧指向同一个问题。

  5. 前沿实验室能力相近，不足以证明其他团队一定能追上。 训练数据、芯片、资本、人才和分发渠道都可能形成长期壁垒。模型榜单接近只是当前观察，不是未来竞争结果的证明。

DHH

成立的观点

  1. 智能体把 AI 从补全代码推进到了执行任务。 读取仓库、调用工具、运行测试、拆分任务并继续修改，确实覆盖了更完整的开发循环。

  2. AI 在边界清楚、反馈快速的任务上可以显著提速。 原型、脚手架、测试、个人工具和局部迁移通常容易定义完成条件。DHH 的 Omarchy 经历证明这种工作流对他有效。

  3. 写代码不是软件交付的唯一瓶颈。 目标、产品判断、沟通、架构、测试、发布和运营不会因为代码生成更快而消失。在大型团队中，组织协调可能比实现更限制速度。

  4. 成熟代码库比新项目更难完全智能体化。 Basecamp 的 AI PR 单独合理、叠加后却破坏架构，说明局部正确不等于系统正确，也证明历史约束和整体设计仍然重要。

  5. AI 可以辅助维护者筛选 AI 贡献。 使用模型进行去重、摘要、测试和初步分类是合理方向。它能缓解一部分信息过载，但最终合并决定仍需由维护者承担。

尚无证据或被夸大的表述

  1. “关键代码逐行审查、UI 和辅助代码不看”的分界难以推广。 DHH 说他审查了 Omarchy 系统模型层的每一行，但没有看 UI 和辅助代码。对个人项目这是合理取舍；一旦涉及鉴权、注入、隐私、资金和不可逆数据变更，“UI 代码”与“关键代码”的边界往往并不清晰，界面正常、测试通过也不能证明系统安全。

  2. “AI 发现漏洞已达到几乎无人类可匹敌的水平”缺少证据。 DHH 自己用的是“似乎”。AI 擅长大规模初筛和部分漏洞模式，但仍会误报、漏报，也可能引入新的漏洞，目前没有公开评测支持“几乎无人类可匹敌”。

  3. “生产率提高 10 倍、100 倍甚至 1000 倍”混淆了局部速度与端到端生产率。 几分钟生成样板代码可能比手写快很多，但从需求到上线还包括设计、验证、返工和运营。上文三项对照实验测得的区间是 −19% 到 +56%，与这些倍数相差数个量级。它们是个人体验，不是行业基准。

  4. “AI PR 是免费贡献”忽略了维护者成本。 维护者仍需阅读、复现、拒绝、沟通并承担合并风险。curl 终止 bug bounty，正是因为这类“免费贡献”的净成本为负。只有经过验证、符合项目目标并附带充分上下文的 PR，才可能真正创造净价值。

  5. “手工编程已经终结”目前没有证据。 DHH 谈的主要是自己的经济处境——“手写代码具有经济价值”的时代对他结束了。手工输入代码的比例可能下降，但嵌入式、实时系统、安全关键软件、内核、数据库和新算法仍需要精确理解。

综合评价

五位大师最经得起检验的共同观点是：

  1. AI 编程能力已经出现实质进步；
  2. 效果高度依赖任务、代码库和反馈机制；
  3. 生成速度不等于端到端生产率；
  4. 编译、测试、静态分析和人工审查仍然必要；
  5. 人必须理解关键结果并承担责任。

最缺乏证据的说法则集中在：

  1. 用“10 倍、100 倍、1000 倍”描述普遍生产率；
  2. 用单个成功项目推断整个软件行业；
  3. 认为代码由 AI 生成，就不再需要阅读、验证或培养程序员；
  4. 把 AI 对开源、安全和就业的影响描述成只有收益或只有损害。

综合来看，Linus 和 Anders 的观点最接近当前工程实践；Bjarne 对高风险领域的警告大体可靠，但部分表述把工具的当前局限说成了固有属性；antirez 准确捕捉到了智能体带来的工作流变化，却从少量成功案例推广得太快；DHH 提供了最有冲击力的实践样本，同时也最容易把个人项目的经验直接放大成行业级结论。

参考资料



Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • 更多大师谈 AI 编程：播客与访谈实录
  • Linux之父:Linus Torvalds 谈 AI 与 Linux 内核开发
  • C++之父：贝尔实验室、负开销抽象与错误
  • Redis之父:不要陷入"反 AI"的炒作
  • TypeScript 之父：TypeScript 提速 10 倍，为什么 AI 不会取代软件工程师