更多大师谈 AI 编程：播客与访谈实录
在整理《五位软件大师谈 AI 编程》之后，一个自然的问题是：除了 Linus Torvalds、Bjarne Stroustrup、Anders Hejlsberg、antirez 和 DHH，还有哪些编程界的重要人物公开谈过 AI？
本文按立场光谱排列，尽量使用原始文字。有主持人提问的，保留“提问 · 回答”的对话结构；只有博客文章或社交媒体短帖的，直接引用原文段落并注明没有采访者。
年龄均截至 2026 年 9 月 9 日。标为区间（如“69–70 岁”）的，是公开资料只记载了出生年份、没有具体日期。Rich Hickey 与 Andrew Kelley 的出生年份没有可靠的公开记载，因此不做推测。
各人生日出处：Rob Pike 生于 1956 年、Jonathan Blow 生于 1971 年 11 月 3 日、Casey Muratori 生于 1976 年、John Carmack 生于 1970 年 8 月 21 日、Guido van Rossum 生于 1956 年 1 月 31 日、Andrej Karpathy 生于 1986 年 10 月 23 日、Martin Fowler 生于 1963 年 12 月 18 日、Kent Beck 生于 1961 年、Robert C. Martin 生于 1952 年 12 月 5 日、Grady Booch 生于 1955 年 2 月 27 日、Mitchell Hashimoto 生于 1989 年、Simon Willison 生于 1981 年 1 月、Chris Lattner 生于 1978 年，均据各自的维基百科条目。
一、强烈批判派
Rich Hickey（Clojure 之父 · 生年未公开）
来源： 《Thanks AI!》，2025 年圣诞期间发表的 GitHub gist
该文为 Rich Hickey 自己撰写的公开信，不是采访，因此没有采访者提问。起因是他收到了一封由 Claude Haiku 4.5 生成的“感谢信”。
啊，圣诞时节。一年当中我们的心被一个白痴机器人的美好祝愿温暖的那个时节。经历过这一切之后浑身发麻，本着节日精神，我想我也该写一封我自己的感谢信，献给那些为我们带来这新一代“AI”的人们。
亲爱的“AI”贩子们：
我该如何感谢你们呢？让我一一数来：
我该感谢你们盗用了人类创造力的全部历史产出，然后宣称对这批赃物拥有所有权吗？
感谢你们浪费了海量的开发者时间？
感谢你们运营着本世纪第二大、也是破坏性第二强的骗局？
我想不必了。
这封邮件提醒了我：代理式的“AI”必将把废话灌满人类剩余的所有沟通渠道，淹没大量服务，让每一次与不在同一个房间里的人的互动都变得可疑，让过滤这些东西成为一种永久的、消耗时间的浪费。
我们是从什么时候开始，不再把“制造的问题比解决的问题更多”视为失败的？
他一贯主张的“Hammock Driven Development”——先离开键盘，把系统的状态、转换和失败模式想清楚，再写第一行代码——与 AI 提供的即时满足正面冲突。
Rob Pike（Go、UTF-8、Plan 9 共同作者 · 69–70 岁）
来源： Bluesky 发帖，2025 年 12 月 25 日。事件经过见 Simon Willison 的记录，邮件原文见 Hacker News 讨论串
同样不是采访。触发事件是 AI Village 项目的自主代理群发邮件，其中一封“感谢”他对计算机领域的贡献。
去你们的。一边强奸这个星球，把数万亿花在有毒的、不可回收的设备上，一边把社会炸个稀烂，却还有闲工夫让你们那些卑劣的机器来感谢我为更简单的软件所做的努力。就，去你们的。你们全都去死吧。我不记得上一次这么生气是什么时候了。
顺便说一句，你们训练那个怪物用的数据，有一部分出自我自己的手，既没有署名也没有补偿。
至于其他人：我为自己在无意中、天真地、哪怕是微小地促成了这场侵袭，向整个世界道歉。
Jonathan Blow（Braid、The Witness 作者 · 54 岁）
来源： YouTube 访谈片段
提问 · 主持人
但是把你的代码作为上下文喂给它，也许正是能带来全部差别的那件事。
回答 · Jonathan Blow
增加上下文并不会改变这里起作用的核心技术。增加上下文只是帮它把你的代码模仿得更像。它仍然不理解自己在做什么。当你真的用批判的眼光去看输出时，这一点完全显而易见。它一直在胡说八道。信息更多的时候它能把话编得更漂亮，但它一直在胡说八道。
如果人们声称 AI 为他们做的就是这些，那没问题，很多讲道理的人确实是这么说的。很多讲道理的人会说：哦，它帮我代替了查文档，或者帮我规划项目之类的。这没问题。但那些声称自己用这个产出了可用的、健壮的软件的人，全是彻头彻尾的骗子。这不是这个系统在做的事。它不是这么工作的。
我觉得这么多人被它骗到的原因是，他们本来就不太会编程。你看着它，心想“哦，天哪，它把代码写出来了，太神奇了”。但它实际上没有做到那件事。这不是它的工作方式。它在任何时候都只是在胡说八道。
Andrew Kelley（Zig 之父 · 生年未公开）
来源： Zig 项目的贡献政策变更。背景分析见这期视频
政策公告与社区讨论，没有采访者提问。
他直接禁止了 Zig 项目接受 AI 生成的贡献。公开的理由不是 PR 质量差，而是他称为 “contributor poker”（贡献者扑克） 的东西：审查一份外部贡献，从来就不只是为了那一个补丁。如果他要的只是那段代码，自己写会更快。审查真正的价值在于知识传递和培养下一代维护者。
这期视频把他和 Bjarne Stroustrup 并列讨论，指出两人在完全不同的领域得出了同一个结论：
抛开我们如今已经习以为常的 AI 垃圾不谈，Bjarne 和 Kelley 都认为，这个行业最大的问题是那些十年后本该存在、而现在没有在被造出来的人。
二、不用但不否定派
Casey Muratori（Handmade Hero、性能优化专家 · 49–50 岁）
来源： Doom Debates 播客，主持人 Liron Shapira；以及 The Pragmatic Engineer 播客
提问 · Liron Shapira
[00:11:47] 我们来聊点 AI 的背景。显然，你有很丰富的软件工程生涯，而且你是真心热爱这门手艺的人。这几乎算是你身份的一部分，你就是喜欢为它本身而做，尽管你做出来的结果也很出色。但你同时是真的热爱这门手艺。这个描述准确吗？
回答 · Casey Muratori
[00:11:58] 是的。我想我在之前的采访里说过这个话题——显然这是今天的热门话题，所以每个人都在问 AI。我说过很多次的是：我能靠这个拿到报酬，其实是个意外。我完全可以想象另一个世界，在那个世界里这更像是我不得不当作爱好去做的事情，因为它不是什么大生意。
所以这只是一个我出生的时间恰好落在人们愿意为计算机编程付很多钱的年代的问题。而这也是我试图向人们解释、为什么我并不怎么在意 LLM 代码生成的原因。因为我并不把自己看作那种只想尽快拿到工资的人。所以我并不怎么在意去加速一件我本来就想做的事情。
提问 · Liron Shapira
[00:16:11] 你这种表述方式，等于是在说所有复杂度都必然是偶然复杂度。但你不觉得也存在大量的本质复杂度，只是处理起来很烦人吗？
回答 · Casey Muratori
[00:16:22] 那我会说：如果你不喜欢处理内在的复杂度，那你就是不喜欢编程。
提问 · Liron Shapira
[00:16:30] 我举个例子。我今天临时做了一个仪表盘，就是个随手做的东西——“嘿，我想这样看数据，你能不能给我做个界面，把这个聚合的周环比数据拉出来？”如果没有 AI，也许我就手动跑几个 SQL 查询，然后想：行吧，暂时够用了。我不会去做一整个仪表盘，还带进度条，我还让它做了颜色编码。
回答 · Casey Muratori
[00:17:01] 那我还是要问，为什么它需要不止是敲几行本质上就是 API 的代码，而那些 API 看起来正好就是你刚才描述的样子？大多数人在给 AI 输入他们想要什么的提示词时，那段文字本来就是一个写得好的库应该长的样子。如果你想要的是“显示这个按钮，显示那个按钮，按下这个按钮时做这件事”，那代码本来就该长这样。
在 The Pragmatic Engineer 的那期节目里，他把话说得更直接：
我们完全不用 AI 工具。……我之所以想在游戏里编程，是因为我想编程。如果我只是想要 AI 来写，那我们大概直接去用授权引擎就好了，我根本不会费劲去问 AI，我会直接去拿 Unreal Engine。
John Carmack（id Software 创始人，现 Keen Technologies · 56 岁）
来源： D CEO 杂志专访，2025 年 11 月于 Venture Dallas
提问 · D CEO
你怎么看 AI 在未来十年会带来的改变？
回答 · John Carmack
AI 会以相当显著的方式改变世界，尽管没有人们相信的那么多、那么快——那些认为一切都处在悬崖边上的人。世界这套系统的惯性是巨大的，它不会像人们以为的那样改变那么多。十年之后，人们还是会在 Facebook 上聊天。我们今天做的事情，十年后也不会有那么大的不同。
值得注意的是，他现在的本职工作就是在 Keen Technologies 研究 AGI。从这个位置说出这番话，分量与旁观者的怀疑不同。
三、务实中间派
Guido van Rossum（Python 之父 · 70 岁）
来源： Python on Azure 播客，主持人 Gwen 与 Marlene；补充引文出自 ODBMS 访谈与 GitHub Blog 访谈
提问 · 主持人
你用得最多的模型是哪个？
回答 · Guido van Rossum
我得用一个我比较熟悉的 AI 功能来完成这项工作，就是 VS Code 里的 agent mode，过去半年我用过它几百次了。……对 ChatGPT 和微软来说很遗憾，最好的编程助手仍然是 Claude Sonnet 4.5。就跟其他所有生成代码的人一样。
提问 · 主持人
你觉得 agent mode 配上那个模型，能按你预期的那样把活干完吗？
回答 · Guido van Rossum
非常棒。好的地方在于，它不像 GitHub 网站上的 Copilot——网站上那个会思考一阵子，你完全不知道它在想什么，然后它写出一堆代码，谁知道它尝试了多少次才写成这样，接着它写一段总结说自己做了什么，我认为那总结大体上是准确的，但我不见得信它，所以我会读它生成的每一行代码。
但如果你用 agent mode，它非常“话痨”，侧边那一栏里它在自言自语，也可能是在跟我说话，但我读不完所有内容。不过你能完整地看到它是怎么推理的，怎么发现自己写了坏代码的。比如它某个时候会去跑类型检查器——至少在我的工作流里，我教过它必须去跑类型检查器——然后你会看到它开始回溯，自己嘟囔着：哦，我看到我犯的错误了。或者它似乎忘了把相关的地方一起改掉，比如它改了一个函数，却忘了改另一个文件里的调用。
这让我对它在做正确的事情有了多得多的信心。即便如此，我仍然会审查它生成的大部分代码，因为它在设计、API 设计和架构这些事情上仍然有盲区。
如果我给它一个可以通过“加一个新函数”或者“改一个已有函数”解决的问题，那一切都很顺利。但如果我给它一个没有完全界定清楚的问题，而解决方案的其中一步是改某个 API 或者改架构——也许我们需要把原来的函数变成一个类，也许我们需要把一个函数拆成两个，或者我们需要往函数里传入别的东西好让它拿到所需的全部上下文——有一次我甚至抓到它试图用代码内省，那在 Python 里确实能做得相当深入，但对它要解决的问题来说完全是错误的工具。我想它当时是在读某个函数的源代码，来判断这个函数是这种还是那种。而正确的解法只是：改一下 API，我们直接告诉它那个函数是什么。
提问 · 主持人
你现在的工作基本上是全面拥抱 AI 了，还是有些特定任务你会把它关掉？
回答 · Guido van Rossum
我觉得是一半一半。我仍然喜欢自己写代码。我绝对不属于 vibe coding 那一派。我也许是让 AI 在我的代码库里做了不少实质性的工作，但它仍然是我的代码库，我要对使用它的人负责，我得站在这份代码后面。
而且这个代码库现在是开源的。我希望人类维护者能够理解它、写出自己的改进并贡献回来，而不是被迫面对一大堆恰好能跑对、但你根本不想知道它是怎么跑对的 AI 垃圾。
在 ODBMS 的访谈里，他把这个立场浓缩成了两句：
AI 被过度炒作了。它仍然只是软件。……我们有些代码是所谓的“智能体”写的。但我们不做“vibe coding”——在架构和 API 设计上，我们保持控制。
代码仍然需要由人来阅读和审查，否则我们就有彻底失去对自身存在的控制的风险。
被问到 AI 时代 Python 是否需要更强的类型系统时，他在 GitHub Blog 的访谈中回答：
我不认为我们需要恐慌，然后开始做一堆可能让 AI 更好过的事情。
最大的问题不是 Python 的类型系统，而是训练数据。大多数教程不教静态类型，AI 模型见到的带注解的 Python 不够多。
Andrej Karpathy（OpenAI 创始成员、前特斯拉 AI 负责人 · 39 岁）
来源： Dwarkesh Patel 播客，2 小时 26 分，YouTube 版本，有完整文字稿
提问 · Dwarkesh Patel
[00:29:45] 你发推说，编程模型在你组装这个仓库（nanochat）时帮助很小。我很好奇这是为什么。
回答 · Andrej Karpathy
[00:29:53] 这个仓库我写了一个多月。我觉得现在人们与代码互动的方式大致分为三类。有些人完全拒绝所有 LLM，纯手写。这大概已经不再是正确的做法了。
中间那一类，也就是我所处的位置，是你仍然大量地从零开始写，但你会用这些模型现在提供的自动补全。当你开始写出一小段时，它会替你补全，你按 Tab 通过就行。大多数时候它是对的，有时候不对，你就改掉。但你仍然非常明确地是你所写内容的架构师。然后是“凭感觉写代码”（vibe coding）：“嗨，请实现这个或那个”，回车，然后让模型去做。那就是智能体。
我确实觉得智能体在非常特定的场景下有效，我也会在特定的场景里用它们。但这些都是你可以用的工具，你必须学会它们擅长什么、不擅长什么、什么时候该用。举例来说，如果你在做样板代码，智能体相当不错。那种纯粹是复制粘贴的样板代码，它们非常在行。它们非常擅长互联网上经常出现的东西，因为这些模型的训练集里有大量例子。
我要说的是，nanochat 不属于那一类，因为它是一个相当独特的仓库。按我组织它的方式，代码量并不大。它不是样板代码，它几乎算是智力密集型的代码，每一处都必须极为精确地安排。而这些模型有太多认知缺陷。举个例子，它们不断地误解我的代码，因为它们对互联网上那些典型做法有太多记忆，而我恰恰没有采用那些做法。
提问 · Dwarkesh Patel
[00:31:49] 能举个例子吗？
回答 · Andrej Karpathy
[00:31:51] 你有八块 GPU 同时在做前向和反向传播。在它们之间同步梯度的做法是使用 PyTorch 的 Distributed Data Parallel 容器，它会在你做反向传播时自动开始通信和同步梯度。我没用 DDP，因为我不想用，因为没这个必要。我把它扔掉了，自己在优化器的 step 里写了一套同步例程。而这些模型一直想让我用 DDP 容器，它们非常担心。
提问 · Dwarkesh Patel
[00:32:26] 它们就是没办法接受你有自己的实现？
回答 · Andrej Karpathy
[00:32:28] 它们过不去这个坎。它们不断想把风格搞乱。它们防御过度得离谱，到处写 try-catch。它们一直想弄出一个生产级的代码库，而我的代码里有一堆前提假设，这没问题，我不需要那些额外的东西。所以我觉得它们在让代码库变臃肿、让复杂度变臃肿，它们不断误解，还好几次用上了已废弃的 API。整个就是一团糟。它就是净收益为负。我可以进去把它清理干净，但那不划算。
我也觉得，用英文把我想要的东西打出来很烦，因为要打太多字。如果我直接导航到我想改的那部分代码，走到我知道代码该出现的地方，敲出前几个字母，自动补全就懂了，直接把代码给我。这是一种信息带宽非常高的、说明你想要什么的方式。
提问 · Dwarkesh Patel
[00:34:23] 这个问题之所以有意思，是因为人们关于 AI 迅速爆发到超级智能的主要叙事，就是 AI 把 AI 工程和 AI 研究自动化。他们会看到你能用 Claude Code 从零做出整个应用、CRUD 应用，然后想：如果 OpenAI、DeepMind 内部也有同样的能力，想象一千个你、一百万个你并行地去找那些细小的架构改进。听你说这恰恰是它们不对称地更差的地方，就很有意思。
回答 · Andrej Karpathy
[00:35:05] 你这个说法很好，而且你正说中了为什么我的时间线要长一些。你说得对。它们不太擅长写从来没有被写过的代码——也许可以这么说——而那恰恰是我们在构建这些模型时想要达成的事情。
总的来说，模型还没到那个程度。我觉得整个行业跳得太快了，一直假装这很惊艳，但它不是，它是 slop（垃圾）。他们没有正视这一点，也许他们是想融资，我不确定在发生什么。但我们正处在一个中间阶段。模型很惊人，但仍然需要大量工作。就目前而言，自动补全是我的甜点区。不过有时候，对某些类型的代码，我会去找 LLM 智能体。
提问 · Dwarkesh Patel
[00:36:53] 纵观编程的历史，出现过许多提升生产率的东西——编译器、代码检查、更好的编程语言——它们提高了程序员的生产率，但并没有导致爆炸。这听起来非常像自动补全那一档，而另一档则是把程序员整个自动化掉。
回答 · Andrej Karpathy
[00:37:26] 我很难区分 AI 从哪里开始、到哪里结束，因为我从根本上把 AI 看作计算的延伸。从最开始的代码编辑器、语法高亮，到类型检查，我看到的是一条连续的谱系——这些都是我们为彼此造出来的工具。甚至搜索引擎也是。为什么搜索引擎不算 AI？排序就是 AI。
我们正在非常非常缓慢地把自己抽象上去。这里有一个我称之为“自主性滑杆”（autonomy slider）的东西：在任何时间点上，能被自动化的部分越来越多地被自动化，而我们做得越来越少，把自己抬升到自动化之上的抽象层。
Martin Fowler（62 岁）与 Kent Beck（64–65 岁）
来源： The Pragmatic Engineer 播客（2026 年 4 月，纪念敏捷宣言 25 周年）；GOTO 2025 双人对谈；以及 Fowler 博客的 Fragments
GOTO 的自动字幕没有说话人标记，无法可靠区分两人，因此下面只引用可明确归属的文字。
Kent Beck 把 AI 编程工具称为“精灵”（genie），并提出了 “Genie Tarpit”（精灵焦油坑） 这个概念。Fowler 在自己的博客里引用了他的原话：
这是我观察到的——精灵天然地待在“摸索”（muddling）的左下方。精灵那种“可推诿”的任务导向，让它在代码根本跑不通的时候也照样宣称成功。于是复杂度堆在复杂度之上，直到连精灵自己都没法再假装还在推进为止。
Fowler 自己接着提出了他认为的核心问题：
在代理式编程的时代，内部质量是否还重要、在多大程度上重要，这仍然是个悬而未决的问题。一种看法是，正如 Laura Tacho 所说：“开发者体验与智能体体验的文氏图是一个圆。”组织良好、命名恰当的代码元素能帮助精灵理解代码，因此如果我们想走得比小型一次性系统更远，这些就很重要。另一种看法是，这类内部质量并不重要，LLM 那颗巨脑能看懂最大的一碗意大利面。也许现在还不行，但再过几个拐点就行了。
这才是根本问题。精灵能躲开焦油坑吗，还是会在焦油的黏着里徒劳挣扎？
在 The Pragmatic Engineer 那期节目里还有一个值得记录的转变：Kent Beck 承认自己最初因为 GitHub Copilot 的糟糕体验而看轻 AI，后来是被 Simon Willison 以及 Thoughtworks 的同事 Mike Mason、Birgitta Böckeler 说服的。同一期节目里，他还提到有从业者告诉他，二十五年的 TDD 文化在今天变得至关重要，因为开发者现在必须严格验证 AI 生成的代码。
Simon Willison（Django 共同创始人 · 45 岁）
来源： Heavybit High Leverage 播客第 9 期，主持人 Joe Ruscio
提问 · Joe Ruscio
我很欣赏你一直在做的一件事，就是区分 vibe coding 和你说的“agentic engineering”（代理式工程）。
回答 · Simon Willison
是的，这是我一直在用的两个词。但奇怪的是，这两件事对我来说已经开始模糊了，这让我挺不安的，因为我原以为我们有一条非常清晰的分界线。vibe coding 是这样一件事：你根本不看代码。你甚至可能不会编程。你可能是个非程序员，你要一个东西，然后你得到一个东西。如果它能跑，太好了。如果不能，你就告诉它不能跑，然后祈祷。
但在任何时候，你都并不真的关心代码质量或者那些额外的约束。我对 vibe coding 的看法是：只要你明白它什么时候能用、什么时候不能用，它就非常棒。比如给你自己用的个人工具，出了 bug 伤害的是你自己，那就放手去做。但如果你是在给别人做软件，vibe coding 就是极不负责任的，因为那是别人的信息，被你的愚蠢 bug 伤害到的是别人。你需要有比那更高的标准。
与之对照的是代理式工程：你是一名专业的软件工程师，你懂安全、可维护性、运维、性能这些东西。你在用这些工具把自己的能力发挥到极致。我发现我能承担的挑战范围显著变大了，因为我有这些工具的支撑。
提问 · Joe Ruscio
那些通过 vibe coding 入门的人，你怎么看他们的走向？
回答 · Simon Willison
大多数人以前会受挫然后放弃。而现在这些人都在学编程。我跟一大批人聊过，他们把 vibe coding 当作起点，热情高涨，但正是通过 vibe coding，他们得到了“我在做的事情有效”的正反馈，他们开始更多地了解代码，踏上了那条路。
悬而未决的问题是：三年之后，这些新的 vibe coder 会变成你愿意托付生产系统的软件工程师，还是仍然只是在 vibe 一些没有长期价值的东西？我不知道答案，但我想三年之内我们就会知道。
四、拥抱派
Robert C. Martin（Uncle Bob · 73 岁）对 Grady Booch（71 岁）
来源： 2026 年 4 月的社交媒体往来，完整对话记录。Uncle Bob 一侧的完整论述见本站中译：《与 Robert C. Martin 谈架构、AI 智能体与产品同理心》，出自 Kent C. Dodds 的播客（节目页）
这是社交媒体上的公开往来，不是同一场访谈，因此没有共同的采访者。下面按发言顺序排列。
这是本文收录的所有材料中唯一一组直接互相回应的公开辩论，而且双方都是软件工程教科书的作者。导火索是一个很具体的问题：面对 Claude 生成的、动辄五百行的 PR，在评审者对代码库并不熟悉的情况下，逐行审查还可行吗？
发言 · Robert C. Martin
我不审查智能体写的代码。我测量的是测试覆盖率、依赖结构、圈复杂度、模块大小、变异测试等等。
从这些指标里可以推断出很多关于代码质量的信息。代码本身我留给 AI。
人类读代码太慢了。要拿到生产率，我们人类必须从代码里脱身，从更高的层次去管理。
他后来补充说明了这套做法的前提——不是放任，而是用“极端约束”把智能体围起来：
单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及其他一大堆东西。
他也坦承自己两年前并不相信 AI 会变得这么强，这是一次立场反转。
回应 · Grady Booch
和 Bob 不同，我审查智能体生成的全部代码。
测试覆盖率之类的指标能给我功能上的信心，但它们完全不能让我相信这些智能体没有引入漏洞、没有留下会削弱未来可理解性的死代码、没有错过对性能有重大影响的重构。
信任，但要验证。
作为一个有经验的开发者，我知道什么是好的味道，什么不是。
而没有任何智能体具备那样的经验或上下文。
如果你想要又糙又快，那我建议你按 Bob 的建议来。
值得注意的是，两人的分歧并不是“信任 AI”与“不信任 AI”那么简单。真正的争点是责任应该落在哪一层：Bob 主张把尽可能多的质量判断转化为可执行的工程约束，Booch 则指出当前的指标体系仍留有重大盲区——覆盖率能证明“功能对不对”，但证明不了“有没有埋雷”。
Mitchell Hashimoto（HashiCorp 创始人、Ghostty 作者 · 约 37 岁）
来源： The Pragmatic Engineer 播客（2026 年 2 月 25 日）；个人长文《My AI Adoption Journey》
他的方法论相当硬：为了公平评估，他强迫自己把所有手写的 commit 用智能体重做一遍，同一份工作做两遍来对比质量。
我没有放弃，而是强迫自己用代理式的方式复现我全部的手动提交。我确确实实把工作做了两遍。
由此提出了两条规则。第一条是“工装工程”（harness engineering）：
智能体在第一次就产出正确结果时效率要高得多，最差也应该是只需要极少的后续修补。要做到这一点，最可靠的办法是给智能体提供快速、高质量的工具，让它在犯错时能自动得到提示。
第二条是“永远保持一个智能体在跑”：
如果我在写代码，我希望有个智能体在做规划。如果它们在写代码，我希望我在做审查。
对怀疑 AI 的工程师，他的建议是从调研而不是从代码开始：
有很多人会说“我不想让它替我写代码”。但你至少可以把调研的部分委托出去。
Chris Lattner（LLVM、Clang、Swift、Mojo 之父 · 47–48 岁）
来源： Hanselminutes 第 1037 期，2026 年 2 月 19 日，主持人 Scott Hanselman
他的切入角度与上述所有人都不同：讨论的不是“程序员该怎么用 AI”，而是“如何为 AI 时代重新设计一门系统编程语言”。节目围绕从 LLVM、Clang 到 Swift 再到 Mojo 的这条线索展开，主题包括内存所有权、异构计算、编译期元编程，以及如何让开发者精确控制 AI 负载落到硅片上的方式。
补充一个时间点：Mojo 在 2026 年 8 月 11 日发布 1.0，一周后于 8 月 18 日以 Apache 2.0 许可完全开源。
相关文章
Enjoy Reading This Article?
Here are some more articles you might like to read next: