DHH:编程的未来、AI、agentic engineering、vibe coding 与 Linux
- 节目:Lex Fridman Podcast 第 501 期
- 主持人:Lex Fridman
- 嘉宾:David Heinemeier Hansson(DHH)
- 英文标题:DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux
- 原文发布日期:2026-08-26(官网记录)
- 翻译与整理日期:2026-11-04
- 校对日期:2026-11-05
- 原视频:YouTube
- 节目主页:Lex Fridman Podcast #501
- 官方文字稿:英文原文
翻译说明:以用户提供的官方文字稿 HTML 存档为底本,保留原稿 23 个章节、1,080 段发言及其顺序,移除时间戳、网页导航和重复目录。本次按更新后的翻译规范校对中文表达、语义、术语和人名;未核听音视频。文中的观点、数据、产品状态与时间表述均按原稿呈现,未经独立核实。
来源说明:官方注明文字稿由人工转写,可能有误。原稿中不一致的专名拼写及数字未据猜测改正;无法明确还原的口语残句保留停顿,不补写其含义。本文经中文翻译和排版,未经节目作者审核。
配图说明:2026-11-05 新增 8 张流程、观点与能力图解,由编者根据本访谈绘制,非节目原图;对应章节见各图图注,点击图片可查看高清图。图中个人经验、时间与预测均按访谈呈现,未经独立核实。
目录
- 访谈精彩片段
- 开场介绍
- 与 AI agent 一起编程
- 软件将如何改变
- AI 对 open source 的影响
- 构建 Omarchy Linux distribution
- vibe coding 与 agentic engineering
- 手工编程的终结
- 给程序员的建议
- 面对网络上的敌意
- 面向 AI agent 的编程环境
- 对速度的执着
- 语音 prompt 与键盘输入
- 哪些 AI 编程模型最好
- 哪些 AI 编程 harness 最好
- AI 视频生成与电影制作
- 为人父
- Linux 将赢得桌面市场
- PewDiePie
- 编程的未来
- 政治与移民
- 长寿、过度优化与对死亡的恐惧
- 永恒轮回与人类文明的未来
01 访谈精彩片段
DHH: 有时几十年都没什么动静,有时短短几周就抵得上几十年。过去九个月,我们就见证了相当于几十年的进步。如果你没有意识到这个时刻的分量,那才是妄想,那才是精神失常。如果突然有个精灵从瓶子里冒出来,对你说:“你想要什么都可以。你梦想过的 operating system 功能,我都能给你做出来,大多数只要五分钟,少数需要二十分钟;就算放开手脚大干一场,也不过两小时。”谁会不欣喜若狂?我想要能突破限速的最快的车,想要能潜入马里亚纳海沟的潜水表,也想要能在 60 秒内装好的 operating system。
DHH: 我一直热爱赛车,其中一个原因是:有时候我从车里踉跄着出来,累得几乎抬不起头,躺在维修车库的地上,心想:“我操,我还活着。”Overton 窗口(Overton window)不会自己打开。它是靠人们冒着一点风险,一次一次推开的:押上一点声誉,承受一点反对、一点批评;有时押上的声誉、承受的批评和阻力可能会很多。与自己所爱的人一起孕育生命,真的是活在这个星球上最巅峰的体验。
02 开场介绍
Lex Fridman: 接下来是我与 David Heinemeier Hansson,也就是 DHH 的对话。他是 Ruby on Rails 的创始人、37signals 的首席技术官、新的 Omarchy Linux operating system 的创始人,也是畅销书作家、赛车手,以及世界上最敢于直言、最多产的程序员之一。过去二十多年,对他而言,编程就是精心地亲手打磨优美的 Ruby 代码。但自 2025 年底以来,DHH 拥抱了 AI 革命,并公开转变为最敢于直言、最多产的 agentic engineer 之一——尽管他很讨厌这个称呼。那么,我们就把他称为这种正在形成的编程方式的实践者吧:AI 负责大部分实际编程,人类则通过整体设计、愿景和审美来掌舵。没错,确实如此。
Lex Fridman: DHH 有时颇具争议,但他始终无所畏惧、才思敏捷,而且聊起来很有趣。这次谈话依然激烈、令人大开眼界,也像一趟疯狂的过山车。这里是 Lex Fridman 播客。如果你想支持节目,请查看简介中的赞助商信息;那里还有联系我、提问、反馈等链接。现在,亲爱的朋友们,有请 DHH。
03 与 AI agent 一起编程
Lex Fridman: 13 个月前,我们就坐在这里聊编程,随后一切都变了。当时你对 AI 在编程中的作用还有些怀疑,之后我们经历了 agentic engineering 的快速演进。先问个简单的问题:你对 AI 在编程中的作用有了怎样的新看法?你是兴奋,还是害怕?
Lex Fridman: 你的情绪是不是 也像坐过山车一样?
DHH: 我非常兴奋。
Lex Fridman: 你一直在谈论乐趣。
DHH: 我完全没有感受到那种生存受到威胁的情绪。对我来说,那只是理性上会思考的问题,并不是情绪上的感受。我的情绪是百分之百纯粹的喜悦……还有乐观,以及对我们竟然能让计算机做到这些事情的惊叹。我们仅仅 13 个月前才聊过,这一点很有意思,因为感觉那次谈话发生在另一个宇宙、另一个时代。我很喜欢一句话,我记得是 Lenin 说的:有时几十年都没什么动静,有时短短几周就抵得上几十年。过去九个月,我们就见证了相当于几十年的进步。想象一下,你恰好身处 Wright 兄弟实现飞行的那个时代。
DHH: 昨天 The New York Times 还在写:“再过一万年,人类才飞得起来。”第二天,我们已经飞上天空;再过几年,跨大西洋的飞机就出现了。整个世界彻底改变了。能亲历那个时刻,是多么幸运。把视野拉远,看看整个人类历史,有多少人一辈子都生活在自己出生时的那个时代?他们从未看到世界和社会发生这种彻底转变。而我有幸经历两次,实在太难得了。我见证了互联网……从没有互联网到有互联网;如今又经历从没有 AI 到有 AI。这是多么精彩的一段人生,多么幸运。
Lex Fridman: 是的,不过这次给人的感觉是:它发生得比人类历史上的任何其他变化都快。
DHH: 没错。
Lex Fridman: 所以我想,转折点大约是在十二月,也可能是十一月下旬——
DHH: 11 月 24 日。
Lex Fridman: 这是……
DHH: 就是那个确切的时刻。
Lex Fridman: 人们谈论世界大战中一个国家 何时入侵另一个国家,会把日期记得清清楚楚。我们现在谈 AI 改变一切,也是这种方式。是的……对很多优秀开发者来说,情况确实变了:原先 AI 只做些基本的 autocomplete,可能写 5%、10%、15%、20% 的代码,后来变成写 80%。
DHH: 或者 100%。
Lex Fridman: 或者 100%,对,尤其是在产品并不面向公众的时候。
DHH: 所以,即使回顾一年前的谈话,我也不觉得自己的观点变了,观点还是那些。一年前,我不喜欢当时提供给我们的 AI 使用方式:要么是 autocomplete,要么是 chatbot。不过,正如我们当时聊到的,我其实喜欢 chatbot。它从一开始就是很好的老师,也是上网查资料的好办法,但它还替代不了我亲手雕琢代码。可是……后来 agent 出现了。
Lex Fridman: 是啊。
DHH: 最初,agent 只让人新鲜了大约五分钟,接着就变得令人惊叹,再接着就让人想问:“天哪,这是不是 AGI?”这些变化都是从去年到现在发生的,甚至就是最近九个月内。大体可以分成几个阶段。先是 agent 出现以前的 AI。我对此很兴奋,但它没有从根本上改变我的游戏规则,也没有彻底改变我的工作方式。我仍然在亲手雕琢代码,只是多了一个小帮手、一个小搭档——
DHH: ……我可以和它交流想法,也可以更高效地上网查资料。它只是让我更有效率地做原本就在做的事,并没有改变我与计算机之间的情感联系。然后到了 2025 年 11 月 24 日。对我来说,Opus 4.5 就是分水岭。突然之间……其实我没有在 24 日当天试用,我记得是 26 日。我交给它几个任务,发现输出的质量竟然与我自己会写出的东西惊人地接近。我记得自己往椅背上一靠,心想:“刚刚到底发生了什么?”
DHH: “怎么短短几个月,我们就从夏天聊到的那种乱七八糟的 autocomplete,走到了这一步?为什么智能水平和易用性都提高了这么多?”这就涉及 agent harness。我不知道 Opus 4.5 比夏天的 Opus 4 究竟聪明了多少,但它操作计算机、使用工具、检查自身工作,以及把智能用到实际工作中、真正做出有意义成果的能力,已经完全不同。我想,几乎所有在圣诞假期留意到这件事、开始尝试的人,都经历了这种巨变。我听到的情况是——
DHH: ……Shopify 等公司的许多员工突然有机会喘口气,有几周时间靠在椅背上,看看究竟发生了什么。他们试用之后,也经历了同样的震撼:这些 agent 和以前的东西根本不属于同一类。到这个阶段,我已经非常兴奋了。到了十二月,我开始重新审视自己以前的种种判断,心想:“哇,它能做这个,那能不能也做那个?”“哦,还真可以。”而现在回头看,Opus 4.5 又像个智障模型了。这就是进步的奇妙之处:你以为已经到了某种境界……我记得自己当时想:“如果以后再也没有新模型,就停在这里,我也够用了,也会很满足。”
Lex Fridman: 是的。是的。
DHH: 接下来的二十年,我都可以一直用 Opus 4.5,绝不会抱怨。看着一个 agent 按照我希望的方式完成所有这些工作,实在太不可思议了。关键不仅在于它能完成任务,还在于我能看着它解决问题的过程,说:“对,对。这里还不完全对,但很接近了。”它还会给你两条说明。它会沿着我想走的路径,到达我想去的地方,写出我愿意合并的代码。如果用 Ruby,它甚至能写出真正优美的代码。Rust 就另说了。agent 能真正成为我工作方式的延伸,这是前所未有的。可我们只等到初春,sub-agent 就突 然出现了。
DHH: harness 开始能够拆分任务。原本 Opus 要做很久的事情,忽然只要五分之一、十分之一的时间,因为任务被拆开,八个 sub-agent 同时替你工作。不过,对我来说,agent 时代最初这两个阶段仍然需要我自己掌舵。我得告诉它想要什么、去哪里找答案,在它偏离方向时稍微纠正一下。这样,我们就能到达目标,而且速度快得多。
DHH: 但我依然得坐在驾驶位上,告诉它我要什么,并审查、核验它产出的东西。直到今年夏天,随着 Opus 5、Fable、Sol,也就是 GPT Sol,以及某种程度上的一些 open-weight model 出现,我们进入了一个新时代。我不再告诉它具体往哪里走,只需说明我面临的问题,描述一个模糊、不成形的想法。它会告诉我该去哪里、走哪条路。我仍然会查看,因为我很好奇,喜欢计算机,也喜欢看到成果,但其实已经有点没必要了。在生成代码、选择实现路径的环节,我成了一个可有可无的参与者。你还记得早期的 GPS 吗?
DHH: 与看纸质地图相比,GPS 已经很神奇了,但你还是得留神:它会不会让你把车开进港口的水里?我记得报纸上有过这样的报道:“GPS 太糟糕了,人们不留神,就把车开进水里。”上一次有人被 GPS 带进港口水里是什么时候?这种事已经不怎么发生了。事实上,如今汽车都能自己开了,对吧?我们现在就到了类似的阶段,我可以信任它。至少在我目前工作的领域里,我可以完全放心,相信它能替我兜住问题。它不会乱来;就算做了蠢事,也有能力补救。
Lex Fridman: 嗯嗯。我们应该提到的是,有各种各样的领域——
DHH: 没错。
Lex Fridman: ……程序员工作的领域有很多种。我不确定,但我想最常见的开发领域,可能就是 Web 开发中的 CRUD。你有一个 database。
Lex Fridman: 再加一个面向用户的 UI,两边来回交互。它可能只供一个人内部使用,也可能服务几个人、许多人,或者全世界。我认为,在这种场景里,代码确实可以百分之百由 AI 编写。只要你是个优秀的程序员,能够凭直觉判断背后发生了什么,确实可以不看代码——至少我的经验是这样。我不知道需要多少编程经验,才能通过观察系统的连带影响和外在表现,直觉地判断内部是否工作正常。
Lex Fridman: 但我认为,在那个领域已经接近 100% 了。还有你正在做的另一个领域:编写 Linux distribution。你如此在意速度等问题,那里可能有更多需要留意的地方,也许需要多看一些代码。再往下还有安全关键系统,比如运行核电站或自动驾驶汽车的系统,那可能就需要更仔细地检查代码。
DHH: 是的,但话说回来,AI 在发现——
Lex Fridman: 是的。
DHH: ……以及修复 security vulnerability 这两方面,能力都强得惊人。Fable 引起轩然大波,就是因为这件事。它太擅长找到攻击者可以利用的漏洞,以至于直接发布都不安全。讽刺的是,在这个领域,我们似乎已经达到了几乎没有人类能够匹敌的智能水平,因为很多 exploit 需要把几招组合起来。你在这里找到一个小漏洞,单独看可能不算特别严重,但与另外四个漏洞一结合,突然就能实现 RCE,也就是 remote command execution。能做到这种事的人非常少。他们通常在国家支持的机构或其他秘密组织里工作,不会到处公开寻找漏洞。
DHH: 所以,它们在这方面已经非常厉害了。正是开发 Linux distribution 的经历,让我彻底成了 AI 的信奉者。过去三个月,我一直在开发 Omarchy,就是几天前刚发布、名为 Quattro 的这个版本。几乎从一开始,agent 辅助开发的占比就接近 100%;最近两个月,更是达到了 100%。我没有亲手写过——
Lex Fridman: 真的吗?
DHH: ……Quattro 发布版本中的任何代码。我审查了整体结构,也逐行检查了系统 model layer 中的所有关键代码,但不少 UI 代码我并没有看,很多辅助代码也没有看,更没有哪项新功能是完全由我手写的。不过,Web 这一边,也就是继续开发 Basecamp 和 HEY 这些用户众多、codebase 相对庞大的商业产品,要完全用 agent 加速,反倒出乎意料地棘手。我们不久前刚发布 Basecamp 5,它是 37signals 第一款真正大量借助 agent 加速开发的产品。大约从二月开始,我们进入了最后冲刺阶段。那时 agent 已经很好用了。
DHH: 起初我们兴冲冲地想:“问题解决了!让设计师直接编程就行。他们知道要什么功能,也知道应该做成什么样。让他们凭感觉做吧。”于是我们就让他们这么做。结果产生了大量 PR:每一个单独看,可能在当时都说得过去,但放在一起,却把系统架构破坏了。最后我们不得不亲自动手收拾残局,由人来清理,才能重新得到一个统一、连贯的架构。所以我们至今还留有一点这样的顾虑。顺便说一句,那是二月的事情,现在已经很不一样了。
Lex Fridman: 等一下,那这件事的教训是什么?其中一个教训是不是:现阶段,想做 vibe coding,你还是得先是个程序员?
DHH: 如果你要在已经存在、规模相当大的——
Lex Fridman: 我明白了。
DHH: ……codebase 上做 vibe coding,即使它们只是 CRUD 系统,而且你还想保留把这个系统支撑到今天的架构,那确实如此。不过,我也多次强调:有人指责 vibe coder 只会生成垃圾代码,我会反问:“你看过普通程序员写出来的东西吗?”那里面同样有不少垃圾。看看很多优秀公司内部的情况,看看那些经手过 3,000 名开发者的 codebase 是什么样,你会发现它们糟透了,简直惨不忍睹。
04 软件将如何改变
Lex Fridman: 能说说你的直觉吗?退一步看看我们平时离不开的那些应用,比如 Adobe Photoshop,我感觉它们的开发速度似乎并没有加快。为什么会这样?Basecamp 也是一款成熟、用户众多的产品,你从中得到了什么启示?为什么这些成熟应用的更新、新功能之类,并没有一下子多起来?
DHH: 原因有几个,我先说最关键的一点。一旦是一个团队在协作,瓶颈往往就不是实现功能,而是人的精力和沟通效率。一个产品经理、几个设计师,上面有副总裁,再上面有 CTO,人人都想参与产品构思,因为都得证明自己为什么在这儿。生产力就这么被耗光了。过去三个月开发 Omarchy,让我明白了一件事:要得到那种神奇的 10 倍、100 倍,极少数情况下甚至 1000 倍的效率提升,你必须直接和 agent 打交道,中间不能再隔着一个人传话,那实在太慢了。
DHH: 一方面,这有点扫兴。我喜欢和人打交道,一起做事也很愉快。但这也意味着,如果工作仍由人推动,还要经过三层审批,再加上大公司的其他种种流程,我们就得调整对 agent 的预期。实现功能只是整个过程的一小部分。另一方面,大多数 组织根本不知道自己想要什么,也不知道怎样才能把产品做得更好。卡住他们的不是实现能力,而是想法、愿景和审美。如果这些东西还没多到让实现能力跟不上,那再提高实现能力也没用。你能把一堆烂点子做出来,然后呢?真要把它们发布出去吗?
DHH: 听起来就像……我也不知道,像 Microsoft 会做出来的东西。我们可不是要复制这个。这个过程其实并不……因为我们早就有过这种情况了。退一步想想,那些庞大的公司手里有成千上万名程序员。我又拿 Microsoft 开刀了。我有时候也挺喜欢 Microsoft,但这里还是拿它举例,因为几十年来,它的资源和编程能力几乎用不完,对吧?这就说明,能写出大量代码,并不意味着能做出优秀、让人想用的软件。另外,我们拥有现在这种能力,也才大约六个月。人要理解、消化眼前的变化,这点时间真不算长。

图 1 · 产品交付的瓶颈。 根据第 04 节整理。DHH 认为,功能实现加快后,产品方向和团队沟通仍可能限制整体速度;图中箭头不表示各环节的耗时比例。
DHH: 所以有人批评 AI,说它怎么还不能再快点,我觉得挺好笑的。你在说什么?还有哪种进步能像 AI 这么快?就因为过去三个月里,我们没把整个世界重写一遍,没让好软件遍地开花、建成一个乌托邦,你就等不及了?
Lex Fridman: 你的意思基本就是,大家现在都该换到 Linux 上。其中一个理由是:Linux 上缺的那些软件,我们都可以重新做出来。我爱 Linux 很多年了,但一直舍不得离开 Windows,后来又用上 Mac,其中一个原因就是剪视频要用 Premiere。
DHH: 我们会解决这个问题。但是——
Lex Fridman: 那么,谁来给 Linux 做出 Premiere 和 Photoshop 呢?感觉现在一个人就能做到了。
DHH: 百分之百,一个人就能做到。
Lex Fridman: 所以,我着急一点也没问题吧。不管是我还是其他人,等不下去了,不正是决定自己动手的第一步吗?就像——
DHH: 没错。
Lex Fridman: ……有成千上万的人在用 Adobe Premiere、DaVinci 这些非线性剪辑软件,大家都知道用起来有哪些烦心事。看看 Reddit,看看论坛,谁都清楚。我不知道问题出在哪儿,可能是管理层,可能是开不完的会,也就是你一直说的那些公司内部的官僚作风,拖慢了所有功能的开发。但我总觉得,只要让几个开发者放开手脚,再配上一批 agent,这些问题都能解决。
Lex Fridman: 不过,照你刚才说的,也许得从头做起:做一个 open source 项目,或者有人另起炉灶开家公司。如今在大公司里,想让开发者放手去做,真正加速进入 agent 时代,好像很难。
DHH: 这是典型的创新者困境。这些公司已经把旧的做法磨练得非常成熟,地位也稳固了,因此它们的整个组织结构、管理层级和流程,都是为一个已经过去的时代设计的。可这些庞然大物就像超级油轮,没法说转向就转向。这也是科技行业终于迎来格局颠覆的原因。有一段时间,我对 Apple 和 Google 在移动领域的双头垄断很恼火,因为感觉移动是我们拥有的最重要的计算平台,而我看不出有什么办法可以撼动高居其上、掌控一切并收取过路费的 Google 或 Apple。但现在规则变了。这不再是最重要的平台。
DHH: 手机很重要,但还会出现许多其他设备形态,无论是眼镜还是耳机或其他任何东西。现在一切都重新有了竞争机会。就桌面而言,计算平台本身可能是四十年来第一次有机会重新洗牌。Linux 从 1991 年就有了。它一直没能在桌面端大规模普及或占据主导地位。其他地方倒是都被它占领了。你办公桌上的所有设备、冰箱、烤面包机,除了你的计算机之外,所有设备都运行 Linux。现在,有趣的是,你的 Android 实际上是 Linux,只是外面包了太多东西,已经认不出来了。但现在出现了一个突破口,正如你所说的那样。
DHH: 如果你离不开某款软件,只好一直用 Windows,那么现在,你完全有能力自己动手重写它。也许没法覆盖全部功能,不过这就像那个关于 Microsoft Office 的老笑话:“我只用其中 5% 的功能。”没错,可每个人用的都是不同的 5%。那我们各自做出自己需要的 5%,不就行了吗?我只实现自己要用的那些功能,又会怎样?这就成了完全不同的问题,而今天的 agent 已经非常擅长做这种事了,我自己就做过很多次。用上最新的 agent 后,一个让我惊喜的变化是:我成了能用多种语言编程的人,以前可完全不是这样。我主要就是个 Ruby 程序员,偶尔才碰一下 Bash——
DHH: ……而且是不得不用的时候才碰。但过去两个月,我写了 C++,做出了三个随 Omarchy Quattro 一起发布的应用。其中有一个写作应用。我原来用的是 Typora,非常好用——
Lex Fridman: 真的很好用。
DHH: ……它本身又是基于另一个应用 iA Writer 做的。那才是我在 Mac 上的最爱:一个干净、简单的 Markdown 写作环境。我所有文章都在那里写。
DHH: 后来我换到 Linux,用不了 iA Writer,就改用了 Typora。它是一款 shareware,里面很多功能我根本用不着。大概六七周前,我突然想:“你知道吗?Typora 本来已经很简单了,可我也只需要其中 5% 的功能。”于是我直接让 agent 开工,指定用 C++ 和 Qt 来写,好融入 Quattro 的整体视觉风格。我记得大约 20 分钟后,第一个版本就出来了。我试了一下,还有些不合心意。可两天之内,我就彻底换掉了 Typora。从那以后,我所有文章都是用 Omawrite 写的。
05 AI 对 open source 的影响
Lex Fridman: 有件事想听听你的建议和看法。我发现,有了 agent,你可以做出一个 Typora 的替代品,完全按自己的需要定制,只服务你一个人。也可以从满足一个人的需求开始,再逐渐让更多人使用。我已经给自己写了不少软件,发现只满足自己的需求,做起来更容易,用起来也更合适。比如我给自己写了一个视频编辑器。如果只是自己用,这其实很容易。
Lex Fridman: 但我和你不同,从没做过很多人都在用的产品,一想到这件事,就觉得有点发怵。在这个 agent 时代,怎样才能从解决自己的问题出发——我觉得这是很好的起点——再让做出来的东西也能帮到其他人?你有什么建议吗?给自己做工具现在这么容易,你觉得这会不会也带来问题?
DHH: 会,不过这件事比你想的简单。工具做完以后,直接告诉 agent:把它放到 GitHub 上。你甚至不用再做别的。它自己会把 repo 放上去,写好 README,还会用 GitHub Releases 来管理版本,方便你追踪。它甚至会比你更擅长维护软件,因为那些管理 open source 项目的苦差事,它比你更有耐心,也更肯认真去做。
DHH: 你只管享受自己做的软件,按自己的想法继续改进就好了。说到这里,就绕不开 open source 圈子里争了好一阵子的话题:AI 带来的贡献,对维护者到底是好是坏?现在很多维护者很烦,因为突然涌来了大量 pull request,而提交的人可能水平不高,甚至压根不是程序员。我看到这种说法就想:“你开玩笑吧?”这么多免费的贡献摆在这里,你想收就收,不想收就不收,怎么还抱怨起它们的存在了?这不就像在说:“我的牛排汁水太足,龙虾里的黄油太香浓了。”这有什么好抱怨的?
DHH: 这简直太棒了。我们说了那么多年,open source 的魅力就在于人人都能贡献。可实际上,过去从来没真正做到过。只有一小部分人为 open source 做出贡献,那就是技术极其高超的高手。所以这有点像宗教改革。我们与计算机之间,原本隔着一群被称为程序员的“神职人员”,如今这层中介突然被绕开了。就像十六世纪 Luther 把《九十五条论纲》钉在门上那样,是不是?其中很明确的一点就是:不必经过中间人,你应当能直接接触更高的智慧。
Lex Fridman: 但是你不需要高手来保持 codebase 的高标准吗?
DHH: 当然需要,而且 open source 一直都是如此。这就说到另一个让我恼火的论点了。我维护 open source 项目已经 25 年,看过的程序员作品,即使没有上万份,也有好几千份。我觉得这些样本足以支持一个判断:大多数程序员,水平都挺烂。不过,先别按字面理解这句话。
DHH: 所以我刚才才特意停了一下。我说“烂”,是 指他们写不出我想要的那种代码:bug report 里没写全相关信息,pull request 没说清楚为什么要改,该写的 code comment 懒得补,不复查自己的工作,也不写 unit test。这些做好软件需要的事,他们都没做好。但你知道谁会做吗?agent,只要你告诉它。它们大多数时候都会认真执行你的要求,有时甚至认真得过了头。也就是说,拿一个普通程序员给一般 open source 项目提的 pull request 来看,agent 已经做得比他更好了。
DHH: 给我的项目提 pull request,我现在宁愿收到 agent 写的。这不光是因为质量更好,也因为拒绝时没那么过意不去。反正又不是你亲手写的,我看看 agent 替你写的东西,说一句“嗯,不需要”,就完了。open source 一直允许你这么做。我觉得有些维护者的问题就在这儿:太紧张、太焦虑,把每一份贡献都当成自己的义务,觉得必须想尽办法让它合入 codebase。其实完全没这回事。
DHH: 你直接说“不”就行,更客气一点,就说“不用了,谢谢”。如果你意识到你的项目可以根据你的愿景、沿着你定下的 roadmap 发展,那么在 agent 时代,拒绝你不想要的贡献就会变得容易得多,也不用担心给谁添麻烦,或者伤了谁的感情。那只是个铁皮机器人,机器人不会介意。事实上,制造这些机器人的模型实验室,还巴不得你白白消耗 token。反正钱照收。所以,在我看来,这绝对是 open source 软件维护者最好的时代。
DHH: 我们不仅能收到一大批 agent 写的、各项要求都做到位的优秀 pull request,还能接触到那些过去没能力参与项目的人的创意。Omarchy 我已经做了一年多,过去三个月开发 Quattro,合并了超过 1,000 个 pull request。其中不少来自原本不做编程的人,或者来自其他领域的程序员,他们并 不从事 Linux operating system 或 distribution 的开发。借助 agent,他们终于能把好点子贡献出来,而我则能挑出其中最好的——
DHH: ……因为这些点子真的做出来了。否则,它们就只能一直留在那些人的脑子里。说到底,这不就是 open source 的意义吗?把整个地球上人们的智慧和创造力聚在一起,变成一份公共成果,让所有人都能受益。目前 Omarchy 大概有 400 个还没合并的 pull request,约是一周前的两倍。提交确实在加速,但处理它们的工具也在进步。我已经有一阵子不再亲自逐个 review 了,而是让 agent 替我看,再给我一份总结:这个改动是否已经准备好,可以交给人来做最后的决定——合,还是不合?
DHH: 那些有问题、重复或者质量差的 pull request,我都不用再看。agent 会替我筛掉,我只管挑珍珠:已经可以落地的好想法,以及 agent 已经替我在 VM 里验证过的 bug fix。复现问题、维护 open source 项目的那些苦差事,正在飞快消失。留给我们的,是软件开发最有滋味、最精华的部分:决定这个东西应该做什么,接下来往哪儿走。

图 2 · 从贡献到合并。 根据第 05 节整理。agent 承担筛选、复现和验证工作,人保留是否采纳改动、让项目往哪里发展的最终判断。
Lex Fridman: 你觉得这些好点子,最核心的部分,最终还是来自人的头脑,也就是每个贡献者吗?agent 能自己想出来,还是说每个 PR 最后都得有一个人的想法作为起点?比如这些改进 Omarchy 的提议……能 不能全靠一群 agent 来完成?
DHH: 在第一个 agent 阶段,也就是从 11 月 24 日到 2 月 28 日,我确实是这么想的:点子都来自人,人告诉 agent 要做什么,它们再去做。但我现在完全不这么看了。我见过一些你们根本想象不到的东西。模型提出的想法好到让我这个一向以点子多自豪的人,都自愧不如。agent 的创造力非常强。那些还停留在“agent 只会鹦鹉学舌,不过是在重复已有想法”这种判断上的人,根本没认清过去六到九个月里取得了多大的进展。
06 构建 Omarchy Linux distribution
Lex Fridman: 有些听众听到这里,会说 DHH 又犯了“AI 精神病”。你能不能先替他们构造一个尽可能有说服力的论点:你确实陷入了妄想,就像《飞越疯人院》那样;然后再反驳它?
DHH: 我确实欣喜若狂,这就是我现在的状态。我和计算机打交道四十年了,最近两个月见到的事情,以前从来没见过。
DHH: 整个职业生涯、几乎一辈子,我都把对计算机的热爱当作工作时间乃至业余时间的重心。如今这一切突然被彻底颠覆、彻底改写,我当然会欣喜若狂。面对这样的现实,谁会不是这样?如果你没有欣喜若狂,至少也应该非常兴奋……其实,我想这样说也不准确。真正的妄想,是没有意识到这一刻的分量。真正的“精神失常”,是相信世界没什么变化,只不过多了几只给我们背诵内容的电子鹦鹉。我觉得人们提出这种质疑,是因为还看不到进步的成果,也就是 你刚才说的:那些惊人的软件在哪里?
DHH: 为什么美国 GDP 没有同比增长 12%?首先,先等等吧,妈的,这还不到一年呢。其次,我自己已经拿出了实实在在的成果。Omarchy Quattro 周五刚发布,已经有几万人下载了。大家很喜欢,喜欢得不得了。
Lex Fridman: 我这里查一下 Perplexity 的介绍:Omarchy 是一个有鲜明设计取舍、基于 Arch Linux 的 desktop distribution,核心是 Hyprland 这个 Wayland tiling compositor。它由 David Heinemeier Hansson,也就是 DHH 创建,旨在提供一套精心打磨的开发者工作环境,具有统一的视觉风格,并预先配置好许多日常工具。
DHH: 让我说一下。Omarchy 是一款美观、现代、有鲜明设计取舍的 Linux 系统。它是 macOS 和 Windows 的替代 operating system,而且非常神奇。
Lex Fridman: 而 Quattro,就是你朝 agent 时代迈进的一步。
DHH: 没错。这是我们刚刚发布的最新版本,这也很有趣。Omarchy 项目只有一年的时间。我是去年夏天在勒芒 24 小时耐力赛间隙开始做这个项目的——
DHH: ……当时 Linux Ricing 的 YouTube 视频看多了,一下子就入了迷。我开始第二次尝试,想做出更好的 Linux operating system。第一次就是我们上次聊过的 Omakub,它基于 Ubuntu,做得还不错。但做新版本 Omarchy 时,我从 software stack 中更底层的位置入手,相当于往下深入了七层,能施展的抱负也完全不同。不过,那还是 agent 出现之前。一开始,那些 Bash script 都是我手写的,后来我亲眼看到了中途发生的转变。
DHH: 我先做了几个部分借助 agent 加速的 Omarchy 版本。到了三个月前,就彻底放开了:100% 的代码都由 agent 写,我来掌舵。这最终成为一种非常不同的 体验和一个非常不同的 operating system,因为我的雄心突然不再有上限。不管是 Windows、Mac 还是其他 Linux 系统,只要看到某个功能,我就可以说:“我想要那个”,agent 就会提供。于是我想要的一切突然变得触手可及,这让我有点欣喜若狂。如果精灵突然从瓶子里冒出来,说:“你想要什么都行。你梦想过的每一个 operating system 功能——”谁能不欣喜若狂?
DHH: “……我都能给你做出来,大部分五分钟,少数二十分钟,如果我们真的疯狂的话,我需要两个小时。”
Lex Fridman: 嗯。你看过《梦之安魂曲》吗?这东西有点像毒品。我个人的感觉是——这件事有很多层面,后面我们可以慢慢聊——这么大的力量突然交到手里,实在让人招架不住。就像《霍比特人》里的情况,你都不知道该怎么用。我发现自己同时忙着太多事,真的快撑不住了,几乎快累垮了。对什么都兴奋得不行,但回头一想,其实还是想专心做好一件事,把它真正做出来。
DHH: 我倒没有那种感觉,没有招架不住,也没有恐惧或失真感,因为我有一个明确的使命。我知道自己要去哪儿,所以这些新获得的力量,都可以用来实现——
Lex Fridman: 是的,太棒了。
DHH: 同一个目标:打造完美的计算机。所以,我对 AI 的所有探索都围绕着这个目标。当然,我还有本职工作,那边也在用 agent,同样是为了做出具体的成果。但凭借 Omarchy 的体验,就像直接在脑后接上了一根线,增加大脑中的想法与屏幕上出现的软件之间的带宽。这就像从拨号上网到光纤上网一样。我想在你的播客上,Elon 谈到了实际的人类带宽——
DHH: ……Neuralink 和其他项目正在努力加速。就像,我们现在通信的带宽非常低,因为我们受到认知的限制。我们受到语速的限制。当你与一群 agent 一起工作时,你就不会受到这些事情的限制。不过,我也得补一句:如果听到自己这样说话的是——
DHH: 九个月前的我,我大概也会说这是“AI psychosis”。当时这么说并不过分,因为那些这样谈论 AI 的人,还没有拿出实际产品。我觉得这就是最根本的区别。有些人很早就看到了这一切,我倒没那么早。我们刚才也说了,我当时相当怀疑,虽然会用 AI 做一些事,但并不是第一批下载 Claude Code 的人。我记得 Boris 是二月底发布它的,而我直到九月才安装。中间大约六个月,那些先行者已经看到了未来的一点曙光。当时还没真正实现,模型的能力和 harness 都还没到位,但他们看到了苗头,我没看到。
DHH: Tobi,也就是 Shopify 的首席执行官 Tobi Lutke,如今也是我在 Omarchy 项目上的一位搭档,他同样彻底迷上了 Omarchy。他很早就看到了这些变化,也试图告诉我,但当时我没有看出来,没有看到他所看到的东西。
Lex Fridman: 你当时就是个黑粉。
DHH: 是的。我当时还留在地球上。而他……他已经登上了火箭,朝着太空飞去。我记得看过他发给公司的那份 AI 备忘录,当时就想:“嗯,这是不是有点夸张了。”就像,你在大谈一些对我而言还不够具体、还摸不着的东西。
DHH: 因为成果在哪儿呢?我试着用了,写出的代码我不喜欢,还老是打断我。你到底从哪儿看到了这些能力?所以我理解,完全理解。如果没见过现在这些模型能做出什么,你当然会觉得这样说话的人有点疯。毕竟此前的所有经验都在告诉你:这些人不太正常。看看编程的发展史,过去四五十年来,总有人承诺,普通人只要开口说话就能写代码,说我们将会有 fourth-generation language。
DHH: 当年推出 Lisp、Smalltalk 时,都说普通人可以在这些环境里编写自己的应用。可除了 Microsoft Access database、Excel spreadsheet 之类的东西,承诺并没真正兑现。它们确实能让最终用户自己编程,但和今天能做到的完全不是一回事。而且,我现在甚至不是在说普通用户,我说的是自己:一个编程 25 年的人,看到了产出、速度和质量的变化,还真的把产品发布出去了。我觉得,这很快就会改变整场讨论。
DHH: 剩下那少数还在犹豫“这东西到底有没有用”的人,还困在 2025 年初“机械鹦鹉”那套说辞里。接下来扑面而来的证据,会让他们再也无法忽视。
07 vibe coding 与 agentic engineering
Lex Fridman: 所以我希望看到像 Omarchy 这样的项目,希望多一些这样的项目,真正展示以 agent 为核心的开发方式。
DHH: 来了。这一切都即将到来。
Lex Fridman: 在我刚才随口举的那些领域,比如视频剪辑、Typora 这一类应用,诸如此类。
DHH: 会有的,我已经看到苗头了。Omarchy 有一个很巧妙的功能:一套更强大的 plugin system。你可以 clone 我们自带的工具,做成自己的 plugin,用来扩展 operating system,甚至重写它的 UI、面板和功能。比如,你想要一个不一样的日历。Omarchy 自带的日历,点一下小时钟就会弹出来,但不支持 iCal,也不会读取你的日程。现在已经有大约 17 种日历实现了。短短三天,Omarchy 的 plugin 市场就上架了 330 个 plugin。在我参与过的任何项目中,我从未见过这样的增长。
DHH: 我从没见过参与面这么广的项目,也没见过这么多人能在这么短的时间里,做出既满足自己需要、又能给别人用的软件。背后的原因是:Omarchy 自带了一套 skills,无论你用哪种 agent,它都能据此学会给 operating system 写 extension,让那种真正可随意塑造的……我差点又要说 agentic 了。我真讨厌这个词。首先,它现在已经成了烂大街的营销话术,什么东西都要贴上去。真希望能有另一个词,就老老实实表示“AI 在干活”。
Lex Fridman: “vibe coding”这个说法,感觉也不太对。
DHH: 确实,因为 vibe coding 给我的感觉,和 2000 年代初的 script kiddie 一模一样:从网上下载一段 PHP script,完全不懂,就直接拿来用。当然,很多 vibe coding 确实就是这样,包括我自己的项目。刚才也说了,我已经做了好几个,用 C++ 写过,也用 Rust 写过。Rust——我真是恨透了 Rust。只要让我看 Rust 代码,就像往我眼睛里泼酸。
Lex Fridman: 等等,等等,等等,等等。为什么讨厌 Rust?
DHH: 在我看来,它是最丑的 programming language——
Lex Fridman: 哦
DHH: ……就所有被发明出来的语言而言——
Lex Fridman: 是啊
DHH: ……至少过去四十年里是这样。
Lex Fridman: 所以它与 Rails 和 Ruby 相反。
DHH: 恰恰相反。但是——
Lex Fridman: 可你也用它写过。
DHH: ……我是用 Rust 写过应用 ,因为它做出来的东西确实很棒。memory safety、作为 system language 的能力,还有很高的执行效率,这些都很出色。所以在我看来,Rust 既可以是最让人不想阅读和使用的 programming language,又可以是极好的 agentic engineering 平台。这两件事在我脑子里完全不矛盾。
Lex Fridman: 你认为是不是到了某个阶段,就可以把 agentic engineering 直接叫作编程?我们可以改变编程的含义吗?因为几个月后谁会真正采用老式方式进行编程呢?
DHH: 我认为我们不应该重复使用这个术语,因为对我来说,编程意味着理解 primitive、loop、condition、variable 这些东西。编程指的是运用 programming language 中的这些 construct,而不只是把一个程序做出来。否则,你也可以说,在 agent 出现以前,CEO 就已经在编程了。他正在雇用一群程序员,告诉他们该做什么,然后开发出可以出售的软件。
DHH: 我想大多数人不会把那位 CEO 叫作程序员,同样,我们也不应该把 vibe coder 叫作程序员。这里先给 vibe coding 下个定义:你告诉 agent 替你构建软件,但自己不看具体实现。对我来说,这就是它与编程,或者说与 agent 辅助开发的区别。
Lex Fridman: 那我稍微反驳一下。像你这样的老派程序员做 agentic engineering,和完全不懂编程的人做,难道不是两回事吗?我的意思是,如果你懂 for loop,懂 function programming,也懂一些好的 software engineering 基本原则,那么即使用自然语言来做 agentic engineering,方法也会更有条理。你能做出的东西,无论规模还是种类,都可能远远超过只做 vibe coding 的人。
DHH: 为了把这个问题辩清楚,我想再把支持这一观点的论据往前推一点。
Lex Fridman: 对。
DHH: 我反而觉得,有一阵子,懂得太多编程知识拖了我的后腿。因为我总是规定好做法,再让 agent 照着做,而它们也确实很擅长执行。在第一个 agent 阶段——还是别叫“时代”了,才持续三个月——这样做确实很有效。我把自己所有的编程经验都用上,告诉 agent 按我的方式去做,效率提高了很多。但到了下一个阶段,我反倒慢了一拍:现在,无论谁,只要告诉 agent 想要的结果、要解决的问题,就能得到比程序员先规定好路径更好的方案。
Lex Fridman: 好,我们这场辩论越来越有意思了。所以你的意思是,有些问题上,程序员做 agentic engineering,反而不如非程序员?
DHH: 完全是。先把意思说清楚:很多程序员并不是好的产品经理,而做软件也就是在做产品管理。它应该做什么?应该为谁做?应该怎么做呢?它应该是什么样子?我们的首要任务是什么?我们首先从什么开始?第一版包含哪些内容?所有这些能力并不是每个程序员都自然具备、或同样擅长的。在 agent 时代,你让 agent、AI 来执行,这些是你需要的技能。我碰巧同时属于这两个阵营,这就是我喜欢这一刻的原因。
DHH: 我仍然有一部分活在旧世界里,会把完整实现读一遍,因为在某些领域,我觉得这样做仍有价值。但另一部分的我已经活在未来了。刚才说过,做 AmaWrite 的时候,我一行 C++ 都没看过。我是刻意把它当成实验:100% 当作 black box,把自己当成一个普通用户,只对这台数字打字机该怎么工作有自己的想法。这样才算公平,就像任何一个作家,都可能对写作软件该怎么做、怎么用有自己的要求。
DHH: 就像你说的,剪辑师很清楚 Adobe Premiere 哪些地方不好用、怎样改会更好,只 是以前没能力动手改……怎么可能改得了呢。
Lex Fridman: 不过,我还是想反驳一下。优秀程序员擅长的是系统性的设计,是从整体考虑问题,而且做事严谨。我觉得即使通过自然语言控制 agent 系统,现在、乃至今后很长一段时间,仍然需要这种严谨。不是把结构规定得死死的,而是明确说清楚系统的目标、怎样验证、做哪些 security test,这些都得考虑。当然,反过来说,长远来看,系统本身也应该足够聪明……
DHH: 六个月前我也会说同样的话。
Lex Fridman: 是的,所以这已经改变了。
DHH: 我认为六个月前,这话也确实成立。但后来,尤其是最近几周借助 agent 加速开发 Mach-E 时,我越来越觉得,得谦虚一点,承认 agent 往往比我更懂。
Lex Fridman: 你可以合理地说,“确保它是安全的。”
DHH: 正确。它会更多地了解这意味着什么。现在,你在笑——
Lex Fridman: 多么疯狂的世界啊。
DHH: ……但这是真的。而事实上——
Lex Fridman: 天啊。
DHH: ……AGENTS.md / CLAUDE.md 文件就是个类似的例子。有一阵子,大家特别热衷于抠这些细枝末节:你要告诉 agent 这个——
DHH: ……还要告诉它那个,最后攒出一大份指令文件。做 Claude Code 的 Boris 最近谈 Opus 5 时提到,他们给 Opus 5 配的 system prompt 缩短了 80%,我想 Fable 大概也一样。不只是因为 agent 需要的人类指令更少了,还因为人规定得太细,反而会妨碍它发挥。任何一个碰过“尖头发老板”的程序员,都知道这是什么感觉:老板走进来,明明什么都不懂,却开始教你怎么编程、怎么写代码。你能怎么办?憋一肚子气。如果被迫违背自己的专业判断去做,写出来的代码就会更差。agent 为什么就不会这样呢?
Lex Fridman: 其实,反过来想想我自己,最近真正在学的,大概也是大家都在学的一种本事:别把要求写得太死,别挡着系统发挥。
DHH: 当然。
Lex Fridman: 只交代到足以提供大方向和指引的程度。
DHH: 还可以再进一步,因为就连这个也未必需要。现代软件开发的一个根本认识,来自 agile software development 运动。20 世纪 90 年代末、2000 年代初,一群聪明、诚实又勇敢的人聚在一起说:“过去四五十年我们试着采用的开发方法,一直行不通,以后也行不通。我们总想提前把软件该是什么样规定清楚,以为问问用户想要什么,全部记下来,再用系统思维严谨地整理成 spec,交给程序员照着实现,大家就都满意了。”结果呢?谁都不满意。因为在拿到成品之前,谁也不知道自己究竟想要什么。
DHH: 在使用程序之前,你不知道它应该做什么。所以,在 agent 时代,别急着一开始就把所有细节规定好。只给出足够让它先做点东西出来的大致想法,然后亲手试用。获得优秀软件的方法是编写一些软件,然后尝试使用它。在使用软件的过程中,你会发现自己真正想要什么。在这里你可以发现什么是重要的,什么是不重要的。agent 非常擅长让你在摸索中逐渐发现自己想要什么,因为你一开始并不知道。
Lex Fridman: 嗯嗯。我还真做过类似的事:让它做几种不同的设计,甚至用完全不同的方式实现,再给自己做个 HTML 或 PHP 页面,在上面投票选出更喜欢的方案。
DHH: 是的。
Lex Fridman: 这样不断 迭代,效果很好,也很有趣。给自己做一个好用的界面,和 agent 系统打交道可以非常好玩,而你的注意力会集中在设计上,尤其是设计中最好玩的部分。
DHH: 正确。而这正是人类真正擅长的。
Lex Fridman: 是的,审美。
DHH: 比较不同选项。你给我三个选项,我选一个。但如果给人二十二个选项,判断能力反而会陡然下降,这就是“选择悖论”。如果只有三个,人们几乎能在一瞬间告诉你喜欢哪一个。这些方法都利用了一个事实:人会作出先于理性思考的快速判断。先是直觉给出答案,再传到大脑,大脑才试着解释为什么直觉这样选。如果你愿意放下一部分预先进行的理性分析,让直觉来引导,agent 时代就会让你豁然开朗。

图 3 · 在使用中发现需求。 根据第 07 节整理。先做出可用版本,再通过试用和少量方案比较明确下一轮需求;体验、审美和取舍贯穿其中。
08 手工编程的终结
Lex Fridman: 这件事放在你身上尤其有意思。大家都知道,你讲了很多年怎么一行一行地雕琢优美的 Rails、Ruby 代码,可短短几个月,你就不再这么做了。你现在的工作方式是什么样的?我猜你仍然在追求美、追求打磨和手艺,只是换了一种创作媒介。
DHH: 也换了一个 abstraction level。我们的整个业务都建立在 Ruby 上,所以 Ruby 代码很多。让 agent 修改这些代码时,我仍然会细抠。但我逐渐意识到,这份精力带来的经济回报正在迅速减少。25 年来,我之所以如此谨慎地打磨每一行代码,是因为我知道保持架构的连贯性和可塑性的回报是软件可以改变和发展——
DHH: ……只需要一个小团队,就能快速、低成本地修改和演进,而不至于动了这里,又让那里冒出一堆 bug。这是为什么你应该编写漂亮的代码的主要经济论据,因为漂亮的代码更容易理解,更简单,更具可塑性。这是以人类进行修改为前提的。我认为这在多大程度上仍然重要是一个悬而未决的问题。现在,这确实很重要,我这么说的原因是,至少目前来说,token 仍然稀缺。此时此刻,我们的 token 都是有限的。好吧,不是全部,但任何没有无限预算的人都会受到 token 额度的限制。
DHH: 所以,如果一个系统能让 agent 轻松处理和修改,不必每次都重新理解整个 context,还是很划算的。和人一样,只要它能在不破坏架构的前提下持续修改 codebase,下一次修改的成本就能和上一次一样低。否则,就会碰上经典的 ball of mud 问题,最后整个系统都成了一团乱麻——
DHH: ……因为各部分只是随意拼凑在一起,毫无条理,乱成一团,对吧?我在 agent 中看到了这一点,并且在我们自己的 codebase 中看到了这一点,同样,第一个 PR 的质量很平庸,然后如果你在此基础上添加另一个 PR,然后再添加五个 PR,那就不是很好,对吧?所以这仍然是有回报的,但这种回报是以我们当前的时刻为前提的。我现在能够……顺便说一句,当你试图推断 9 个月后它会是什么样子时,这才是那种“AI psychosis”真正容易冒出来的地方。两年后它会是什么样子。不过,不妨做个思想实验。我记得自己用的第一台计算机是 Commodore 64。
Lex Fridman: 我也是。真酷。
DHH: 它的 CPU 只有 1 MHz,内存只有 64K。在那台机器上写软件的人,早就把各种限制刻进了脑子里。说“各种”都不够,那台机器简直处处都是限制。假如把这样的程序员放进时间机器,送到 2026 年,给他一台现代计算机,说“来,给我写个软件”,他一时肯定会不知所措,因为原来的技巧和经验法则都不适用了。也不能说错了,毕竟高效的软件依然很美,只是那些做法已经跟不上今天创造价值的方式。要在 1 MHz 的机器上做出游戏,得进行多少 optimization,和今天完全是两回事。
Lex Fridman: 想想当年那个坐在 Commodore 前写程序的人。回忆一下,当时编程是什么感觉、意味着什么:资源少得可怜,什么都慢得不得了。
DHH: 在很多方面都很美丽。美丽的。
Lex Fridman: 像是在精雕细琢。不过——
DHH: 它——
Lex Fridman: ……想象那个人现在来了。
DHH: 不过,这里面也有美化过去的成分。想想我们抱怨现代汽车文化的时候,是不是也会说:“哦,如果我们都有马车之类的东西不是更好吗?”不,不是。你知道当我们用马作为交通工具时纽约闻起来是什么味道吗?那是一条露天下水道。他们只是到处拉屎。
Lex Fridman: 是啊,但是你玩过 Red Dead Redemption 吗?你知道那些牛仔有多酷——
DHH: 就是这样——
Lex Fridman: ……在马上?
DHH: ……在游戏里怀念过去就挺好, 毕竟不用亲身承受那些毛茸茸的动物带来的各种刺激和感受。
Lex Fridman: 所以基本上编程,老式的手工编程有点像我们浪漫化和拍电影的牛仔文化。
DHH: 人们已经开始浪漫化亲手写代码了,我自己也有一点,因为那确实是个很浪漫的时代。我很庆幸自己赶上了手写代码仍有经济价值的那二十年。那是段美好的时光。
Lex Fridman: 手写的漂亮代码也很有价值。
DHH: 正确。因为手写的漂亮代码今天和昨天一样存在。有些人故意为 Commodore 64、Sega Mega Drive 或其他老式游戏机编写新视频游戏。事实上,我最近最喜欢的视频游戏之一是 ModRetro 的。你知道 Palmer Luckey 的那个副业吗?就是重新做那些老游戏机。他已经把 Game Boy 重新做出来了。
Lex Fridman: 不错。
DHH: 特别棒,搜一下,真的很酷。他不光重做了硬件,保留了原来那种厚实的手感,还换上现代屏幕之类的东西。现在连 Nintendo 64 也做出来了。很厉害,特别酷,细节、input lag 等等都抠得很细。不过,还有一个更酷的东西——我得指一下,就是那里那个,把鼠标移上去,你就明白我说的是什么了。那是 Chromatic 上的——
Lex Fridman: 啊
DHH: ……Tetris 重制版。
Lex Fridman: 哇。
DHH: 我在原来的 Game Boy 上玩了很多 Tetris。可能是我有史以来最喜欢的三款游戏之一。他们重做了游戏,只作了一处改动。如果按一下上方向键,方块就会直接落到底部。这使得游戏速度提高了约 400%。这是一款令人难以置信的游戏,而且是一款新的 Game Boy 游戏。
DHH: 我记得 Game Boy 是 1989 年还是 1988 年出的,真的是老机器了。现在还有人在给它写新游戏,这就很棒。这次做 Tetris,是因为他们想玩这个版本;但也有人纯粹是喜欢在限制中创作,喜欢那种写老游戏的浪漫。就像现在仍有人骑马,不是为了赶快到达目的地,而是喜欢这种出行方式:身下是一个活生生的生命,载着你往前走。
Lex Fridman: 而且,我们应该说,漂亮的代码是很好的训练数据。所以从某种意义上说,我们几十年来所建立的美丽——
DHH: 对。
Lex Fridman: ……以这种方式延续下去了。
DHH: 是我们促成了这一刻。能参与其中,多么幸运。对此我有很深的个人感受,因为我……我写过的几乎所有代码都是公共代码。我职业生涯的大部分时间都致力于编写 open source 代码,因此,其中一些代码,一些优美的代码行都在训练集中。事实上,我听说人们在编写 Ruby 代码时这样做。他们问 agent:“像 DHH 那样写。”
DHH: 他们对结果很满意。想到自己也曾以微不足道的一点贡献促成这一刻,我心里确实会暖一下。自编程作为一门学科存在以来,任何贡献过 open source 代码,或写过 agent 能够接触到的代码的人,如今都以某种方式成了这些新“agent 霸主”的一部分。
Lex Fridman: 所以你没有一点点悲伤,手写漂亮的代码现在越来越没有用了吗?
DHH: 如果明天要找工作,我大概已经很难靠亲手一行行写代码这项本领挣钱了,我会因此难过吗?不会。我已经写了 25 年,想看看新东西了。尤其是假如我们真的能永远活下去——我希望不会,待会儿也许可以聊聊——我已经做过这件事,足够了,挺好的。我对它的怀念,不会比对扛着锄头下地干活、站在流水线上劳 动的怀念更多。
Lex Fridman: 等一下,你可是世界上最擅长亲手打磨优美代码的程序员之一,对美有很高的鉴赏力。
DHH: 没错。
Lex Fridman: 而这种能力如今已经被替代了。
DHH: 这话我就谦虚地认下了。
Lex Fridman: 对,这种本领被替代了。而你现在……你适应得非常快。你有一个很了不起的特点,就是能改变想法,迅速往前走。可是,你也得和过去的那个自己告别。
DHH: 我感谢把我带到今天的每一个时刻,也一直试着这样生活。也许这确实需要练习,我承认;我可能并非一直如此。但斯多葛哲学中的 amor fati,也就是“热爱你的命运”,是一种非常让人自由的生活方式。你可以反驳:“这是站在有特权的位置上说的话。”没错,可在我还没有这些所谓“特权”时,我的大方向也一样。所以我认为,你可以选择一种与世界相处的方式:接受你能改变的事,也接受你不能改变的事,并爱上这一切。爱上这样一个事实:与去年相比,如今科技行业的世界仿佛已经向前跃进了二十年。
09 给程序员的建议
Lex Fridman: 那我们聊聊程序员面对这种转变时普遍感到的焦虑吧。他们可能上了大学,学的是 computer science,梦想着当程序员、做出自己的东西、拿一份高薪。可现在一切都变了,他们深深地担心:“我接下来的人生该怎么办?”你能理解这种感受吗?他们到底该怎么做?
DHH: 非常理解。虽然我自 己是这种性格,但我很清楚,并不是每个人都和我一样乐观。不过,我想把两件事分开说。如果你喜欢编程,只是喜欢把正确的逻辑结构拼起来,做出别人指定的东西,那么面对新现实,你恐怕会很难适应,因为受到冲击的正是这种机械性的工作。但如果你像刚才说的那样,喜欢的是把东西做出来,我倒不觉得你受到了威胁。实际上,有充分的理由认为,我们需要比现在多得多的创造者。再看就业数据,目前的情况还不明朗。
DHH: 根本不清楚会发生什么。一些统计数据实际上显示职位空缺有所增加,因为 AI 的出现极大地降低了软件的成本,以至于人们想要更多软件。这是经典的 Jevons 悖论(Jevons paradox),即当某种东西的价格下降时,对它的需求就会增加。这也是 ATM 机的例子。当 ATM 机最初出现时,很多银行出纳员都非常担心他们的工作,因为突然有了机器,能替人办理账户取款。嗯,自动柜员机的作用是降低了开设银行网点的成本,突然之间,银行有能力开设更多的分行,最终我们的银行出纳员比以前更多了。现在,这一切都没有得到保证。也有事情确实发生变化的时刻。
DHH: 直到 19 世纪末,绝大多数人还在田里干活。后来有了机械化收割工具,就不再需要那么多人拿着锄头、赶着牛下地了,机器能替他们做。那时有没有人的工作和生计受到威胁?有。他们害怕,有没有道理?有。英国那些砸毁织布机的 Luddites——
DHH: ……面对的也是同样的处境。而且,比起农民,他们可能更像今天的程序员:技术熟练,工作条件不错,做的也是自己喜欢的事,不用整天顶着太阳苦干。可站在今天,我们还愿意让衣服成为那么稀缺的东西吗?比如说,如果这件 T 恤售价 400 美元 怎么办?我的意思是,好吧,那我就买两件。嗯,看我的衣柜,你可能会以为我本来就只有两件。但我认为人类的总体进步取决于生产力的提高。什么是生产力改进?这非常重要,因为从抽象的角度来看,我认为每个人都会说:“是的,生产力。这很好。”你以为这只是喊句让人高兴的口号吗?不。
DHH: 生产力提高,就是用更少的人做同样多的工作。需要完成的工作可能随之增加,于是又需要更多人;但也可能不会。可能在某些地方,公司只需要完成一组特定的固定任务,突然间他们可以用十分之一的人员来完成这些任务。当然,对被裁掉的那个人来说,这在当下可能很惨,也很难熬。但对整个经济来说,它又可能是很好的变化。突然间,你释放了这些资源,他们现在可以去做更有成效的事情。这就是整个经济发展和改善的方式,也是我们实现增长的方式,而且增长是好的。我认为这是另一件需要强有力辩护的事情,总体而言,增长是一件好事。
DHH: 我们不想让时光倒回 1920 年或 1950 年。我们应该为我们发现的新技术感到兴奋,这些新技术可以让我们做更多的事情。虽然 AI 可能接管的一些任务是人类很乐意做的任务,而且它们在经济上不再可行,但很多任务只是苦差事。我的编程确实如此。我认为有些编程时刻是令人惊奇的。这些时刻产生了我们上次谈到的心流状态,让人欣喜若狂。它们在一年中发生的频率是多少?如果以普通程序员为例,他在 2,000 个小时的工作时间中,有多少时间处于心流状态?
DHH: 100?200?25?我认为所有这些答案对于某些人来说都是合理的。把那些苦差事交给机器,这就是文明的历史。
Lex Fridman: 是的,我的意思是,调试所花费的时间。所以编程有很多痛苦的时刻。如今这些痛苦消失了。对于……我的意思是,在大多数情况下,这很有趣。
DHH: 很多领域的痛苦已经消失了,剩下的也可能很快消失。我们会美化过去,部分原因就在这里:痛苦发生的时候,真是难熬,又烦又累;可回头看,它就变成了成就、骄傲、成长和进步。这些都是人的经历。我们讨厌眼前的痛苦,可等事情过去,哪怕才过去五分钟,就开始珍惜它了,因为已经忘了难受,只记得自己往前走了一步。
Lex Fridman: 因此,在社会层面、宏观经济层面,增长无疑是令人兴奋的。但在个人层面上,将会有很多焦虑,可能会有很多痛苦。因此,作为建议,如果你现在是年轻时的 DHH,或者刚入行的程序员,你会怎么做,你会建议他们做什么?
DHH: 别费劲预测了,真会把自己逼疯。业内最聪明的人,也猜不出再往后两代模型会是什么样。想推演两年后的世界,完全是在浪费时间,还容易把自己想出“AI psychosis”。专注眼前吧,现在正是玩计算机最不可思议的时代。只要认真投入,你就能让它们做出惊人的东西。抽出一点时间,逼自己了解一下最前沿的能力到了哪一步,我敢打赌,你不可能不为这些可能性感到兴奋。
Lex Fridman: 你会建议公开分享自己的开发过程吗?
DHH: 公开分享开发过程,我觉得其实是可选的。不过,这样做挺好,因为你能加入一个社区,找到一起做事的伙伴。open source 圈子里不只是有一点友情,而是有很多。它能带来很强的归属感和同伴情谊,也能缓解那种“我以后怎么办”的恐惧。和其他人在一起,你会感染一些好的“思想病毒”,那些让人兴奋的想法:一切会好起来, 未来很有希望;只要一起做点东西,就能做成谁都没想过的事。
DHH: 我刚和 Ryan Hughes 聊过。他几乎从第一天起就是我做 Omarchy 的主要搭档。昨天我们还在说,刚开始时,愿望真的很小。我们就像是,“我们能否让这个 distribution 在凌晨三点不会因为我们控制不了的 Arch package 更新而崩溃?那就太棒了。那就太好了。”现在我们靠在椅背上思考,“我们怎样才能统治世界?我们怎样才能让 Omarchy 去火星?我们怎样才能实现我们梦想的一切?”敢把目标定得这么大,一部分是因为 agent 越来越强,但很大程度上也是因为我们周围都是对同一旅程感到兴奋的人。
DHH: 如果你只是坐在你孤立的小洞穴里担心未来,是的,你会有点疯狂。疫情至少让我们明白了一件事:一个人窝在小洞穴里,不停担心未来,真的会把自己逼疯。这与抑郁症没有什么区别,无休止地思考你无法控制的事情。我很抱歉在这里引用 Jensen Huang 的观点,但这只是失败者心态。你不必成为失败者。你可以选择向前一步并——……获胜。胜利的定义非常广泛,包括学习更多、创造更多、贡献更多、参与更多。归根结底,你的选择是什么?你别无选择,伙计。
DHH: 不管你喜欢与否,未来都会到来,所以你不妨选择为此感到兴奋。
Lex Fridman: 但还是得强调,AI 让规划未来几乎成了不可能的事。我们大多数人多少都会规划人生。年轻时有希望、有梦想,之所以去上大学,背后也有自己的打算。
DHH: 我同意这一点。
Lex Fridman: 但是那里——
DHH: 我承认这一点。
Lex Fridman: ……有点——
DHH: 这是不同的。
Lex Fridman: ……离谱,根本没法认真做计划。因为,你真的不知道六个月后是否还会有 Claude Code、Codex 和 Cursor。也许你会与 WhatsApp 交谈。也许全会变成 open call 那种形式。也许一切都只是声音。也许 Omarchy 会接管世界,也完全靠语音操作。也许不再有 operating system 了。你会……会有一个发光的球体,你只需与之交谈,因为如果自然语言足以完成生活中的所有任务,那么,生活究竟意味着什么?例如,你生活中需要完成的主要任务是什么?如果你用语音就可以做到这一点,它给你写所有的程序,一切都由系统安排好了,那还需要人做什么工作呢?也许更多的是服务业。
Lex Fridman: 也许连 agentic engineer 这种程序员都不会有了。所以,专注当下确实是明智的建议,可这段经历依然像坐疯狂的过山车,因为我们不知道到了十二月、一月,世界会变成什么样。
DHH: 确实不知道,所以不妨选择相信,事情最终会有好的结果。这就是我应对焦虑最想给出的建议:在很大程度上,你可以选择用什么态度面对。你要一直往 P(doom) 那边想吗?你担不担心,都不影响它是否会发生,这不是你能控制的。
Lex Fridman: 但还有很实际的问题,比如每天怎么安排:花多少时间学习,多少时间动手做,又花多少时间接触不同的东西。前阵子我去了中国乡村,就是刻意这么安排的。在中国,或者任何地方的乡村,和当地人聊天,会发现时间慢得多,也没人讨论 agentic engineering。我先去了长城,那是一种跨越了几个世纪的、恒久的存在。当然,心里还是有一点 FOMO,总觉得自己是不是错过了什么。

图 4 · 能力重心与尚存的分歧。 综合第 07、09 节整理。DHH 强调产品判断与开放尝试;Lex 强调系统思维、验证和严谨。两人对技术经验应参与多深的判断并不一致。
10 面对网络上的敌意
Lex Fridman: 但我就是想刻意去找一找,人类生活中那些不会随时间改变的东西。整个历史里,人们总觉得一切都在变化,可生活中真正重要的那些事,依然相通。我想让自己始终和它们保持联系。
DHH: 你不会错过任何东西。这是在这个转变的早期阶段真正让我恼火的地方。大家都急得不行,好像你不赶紧跟上就……现在是 loop!不不,loop 过时了,现在得用 graph!不不,那个也过去了,现在又是 harness,对吧?他们不断地探索前沿,这在某种程度上实际上是非常令人兴奋的。这就是当新领域打开时会发生的情况。它就像一个新的门户,一切都溢出来了。这太令人兴奋了。但这也意味着,如果我去年刚刚背包旅行,没有接触过电脑,没有见证过这个 agent 的时刻,而我昨天才出现,你知道吗?两周后我就能赶上进度。
DHH: 你并不需要把错过的每一步都补上,某种程度上,这反而让人松了口气。如果去年错过了,两周后就能赶上最前沿。如果你是一名程序员,在喜马拉雅山徒步旅行了一年,然后回来,你可以在两周内赶上。这恰恰是这些进步了不起的地方。我们现在同时进行如此多的实验,不断淘汰无效的做法,留下真正有用的东西。你不必记住甚至不必参与整个旅程。你直接过来用最后的成果就行了。
Lex Fridman: 但当你从背包旅行回来时,关键的一步是愿意成为一个全新的、不同的人,因为事情变化得太快了。
DHH: 没错。
Lex Fridman: 我是说,假如你真的出去背包旅行——……去年十月,四月或五月回来——
DHH: 你可能已经在低温休眠舱里待了 100 年了。
Lex Fridman: ……就像,“什么,你是什么意思?我们不再编程了?”这,这是一个非常……这是一个巨大的转变。
DHH: 确实让人震惊。其实……我有些话也稍微夸张了一点,是为了表达得更鲜明。我也认识到,短暂地感到悲伤是可以的。那不是我的性格。这不是我的做法,但我承认这是一种经过时间考验的应对失落感的机制。当你所熟悉的、也许你非常喜欢的世界不再是原来的样子时,有一种失落感是可以接受的。
Lex Fridman: 那我也该明确说出来:我确实会难过,就像那个眼角滑下一滴泪的美国原住民形象,我也会……就是有种伤感。这是一次再见。这是对旧编程世界的告别。
DHH: 那是……这让我觉得很有意思。
Lex Fridman: 我花了这么多年——
DHH: 可之前的一切,最终都汇聚到了这一刻。这也是为什么我觉得这一路如此有意义。AI 不是从天上掉下来的,不是什么外星技术穿过宇宙,突然落到我们面前。computer science 有多久,AI 就存在了多久。20 世纪 50 年代,那些最聪明的人以为,再过十年左右就能攻克它。结果花的时间长了一些,部分原因是我们在通往 AI 和 neural network 的路上走了弯路,以为其他 symbolic representation 能胜出,结果没有。这可能耽误了大约十五年。还有一个原因是,我们得先经历游戏革命,经历 3D 游戏的发展。
DHH: 如果我们没有 Quake,如果我们没有 Duke Nukem,如果我们没有 Unreal Tournament,我们永远不会得到 AI,因为我们永远不会得到 GPU,因此我们永远不可能得到现在这样的 AI。因此,我们到目前为止所做的一切都是为了实现这一目标。你是其中的一部分。天哪……多幸运啊。不管是提供训练的东西,还是玩电子游戏,能尽自己的一份力,都是多么幸运的事。你完全可以这么想。就我而言,在 90 年代,你花在玩电子游戏上的所有时间,都是——
Lex Fridman: 你正在贡献。
DHH: 是的,我当时就为 AI 革命做出了贡献。
Lex Fridman: 为了人类文明的进步。不,当然。文明随着旧事物的死亡和新事物的诞生而进步,并以这种方式继续下去,但我认为悲伤的过程仍然是其中的一部分。
DHH: 花点时间。没关系。考虑一下……而且,你甚至不必接受一切都已死的事实。就像,如果你仍然非常执着于手工凿刻,如果你在一年前问我,我会预测我会更执着。我很惊讶——
Lex Fridman: 我有点惊讶……
DHH: ……自己竟然没有更舍不得。但我想,我之所以没有更加依恋,是因为我发现了一些更有趣的东西。如果不是这样,如果 AI 取代了我所爱的东西,给了我一些我讨厌的东西,我可能会有点痛苦。
Lex Fridman: 看着你的变化,真的又好笑,又精彩,也很鼓舞人。就像 Picasso 突然用上 image generation,兴奋得 不得了,几个月内就换了创作方式。你身上发生的,差不多就是这件事:一个欣赏优美代码的艺术家,忽然开始大谈做这些事有多好玩——
DHH: 我认为 Picasso 实际上是一个很好的类比,因为如果你看他早期的作品,他学习了他的手艺,那就是画写实画,对吧?就像,他原本是在练习传统技法,想成为尽可能逼真地描绘现实的大师,后来,立体主义和其他表达方式出现了。
DHH: 所有这些抽象表达形式,他并没有因为不再画文艺复兴式的画、不再把苹果画得惟妙惟肖而难过。他把苹果重新想象成一个方块,反而兴奋得很。我感觉到这种转变,我们已经摆脱了这种单一的表达模式,突然像推开一扇门,眼前的色彩一下丰富起来,能看见的东西也更多了。也许是因为我当初成为程序员的方式。我并不是因为深爱 if statement 而成为一名程序员。我成为一名程序员是因为我想要程序。我想要那些不存在的东西存在。首先,我必须学习如何编程来实现这一点。
DHH: 然后我碰巧爱上了编程作为一门手艺,然后我花了二十年的时间真正深入研究它。但现在我回来了。我又回到了有了一个想法,并且非常不耐烦地想看到它存在于世界上,而 AI 把从想法到实现的时间压缩到了几乎为零。所以,这种加速也让我重新找回了最初的热情。现在,我明白这并不适合每个人。有很多程序员从一开始就喜欢编程,他们被逻辑结构等所吸引。我的意思是,我已经在那里呆了二十年了,所以我明白了。但我也认为你能够发现自己新的一面——
DHH: ……只要你愿意接纳。借用 Jeff Bezos 的说法,我总会想到那个“后悔最小化框架”(regret minimization framework)。两年后回头看,你会不会说:“ 我把时间都花在生当下的气、怨行业变了,真是值啊。”还是会为当初愿意投入而骄傲?中间难过一阵也没关系,这些情绪都可以有。然后再告诉自己:“我要弄明白这个世界现在怎么运转,不光顺应它,还要借此做出更多东西。”
Lex Fridman: 我的意思是,这是真的,很多程序员,我的很多朋友,我,当然还有你,都玩得很开心。
DHH: 在过去的三个月里,我从电脑中获得的乐趣比以往任何时候都多。
Lex Fridman: 快速上厕所,然后我要问你现在如何与系统实际交互。
DHH: 是的。
11 面向 AI agent 的编程环境
Lex Fridman: 我得问问,你的编程环境现在变成什么样了?用键盘,还是语音?IDE 又是什么?
DHH: 现在想起来都觉得很疯狂,但是,是的,我使用 TextMate 已经快 20 年了。我想我是从 2005 年开始使用 TextMate 的。我帮助发布了第一个版本,之后我就无意再寻找别的编辑器。我并没有在市场上寻找替代方案。直到切换到 Linux,我才不得不离开熟悉的环境。现在切换到,我们称之为什么?agentic engineering?哦,我他妈的讨厌这个词。我们必须想出一些听起来像编程一样简单的东西,但又能说明是和 agent 一起做的。但是——
Lex Fridman: 此时我仍然觉得应该叫编程。
DHH: ……好吧,就叫它编程吧。使用 agent 进行编程需要不同的工具集。确实如此。这里的主要变化是, 你将从脑子里的 single-threaded 工作方式,转向 parallel processing。不久前我写代码的时候,在 TextMate 甚至 Neovim 上手工凿代码的时候,我当时就只关注一个问题,然后有条不紊地解决它,这实际上是进入心流的入口。心流的入口是深度沉浸在单一问题中,并坚持到底。
DHH: 和 agent 合作就不一样了,部分原因是它们既太快,又太慢。交代一件事后,它们不会像敲键盘那样立刻给你反馈,你得让它们自己忙一会儿。如果只是坐着等,就会觉得自己没干什么事。哪怕单个 agent 的产出已经很高,你还是没有那种高效工作的感觉,心里不舒服,甚至觉得自己有点没用。
DHH: 最早用 agent 的时候,我主要一次只开一个,当时确实有过一瞬间的犹豫:“这真的好吗?”但很多难题,只要投入更多资源,就能解决。这不就是 AI 的 scaling law 吗?把任务并行起来,同时开几个 agent,你又会有那种进入心流的感觉,因为你一直在做决定:这个 agent 不知道往哪个方向走,你帮它解个围;那个做完了,你准备好下一项任务。要这么工作,就需要另一套环境。

图 5 · 并行工作与注意力限制。 综合第 11、15 节整理。并行让人把等待时间用于其他任务,也增加了切换和决策的密度;三个任务仅作示意,不是固定的并发建议。
DHH: 我一开始用 tmux,开不同的 pane、分不同的区域。可以把它想成带 tab 的 terminal,一次打开好几个 tab。这个大家都熟悉,平时也不会只在一个 tab 里做事 。
Lex Fridman: 所以仍然坚持使用 terminal,CLI。
DHH: 绝对的。
Lex Fridman: 所以你没有使用 Claude Code 应用程序或——
DHH: 不。
Lex Fridman: ……Codex 应用程序或——
DHH: 我喜欢这场 agent 革命在 terminal 中拉开序幕,因为我已经是 TUI,也就是 terminal user interface,以及整个 terminal 环境的忠实粉丝。在里面工作很舒服,也很漂亮。现代 terminal 本身就是个赏心悦目的工作环境,所以我很喜欢。然后,拥有多个 agent 这一事实,尤其是当它不仅仅是在你自己的机器上运行多个 agent,而是你开始运行多台机器时。现在仅靠 tmux 还不足以跟踪它,这就是为什么最近我改用了这个叫做 Herdr 的东西。
DHH: 而 Herdr 本质上是 tmux 加上 agent 通知。因此,每当你的 agent 完成工作并需要为你提供某些东西时,它就会叮一声,提醒人类该来看看了……人到底是主人还是仆人,我也时常搞不清。总之,该你做决定了。它还会标明 agent 是否仍在工作。所以我配好了 Herdr,而且在不同机器上各跑一套。大约一个月前,我进入了这个疯狂的阶段,意识到在一台机器上完成这项工作还不够快。这就像我发现了 multicore programming,但我只有两个核心。我想,“如果我有 16 个核心怎么办?如果我有 32 个核心怎么办?如果我有 64 个核心怎么办?”所以我立即出去买了这些令人惊叹的 KVM,称为 GL.iNet Comets。
DHH: 它就是这么一个小盒子,用 HDMI 和 USB 接到计算机上,也就是 KVM。因此,KVM 是一种远程控制计算机的方式,但它的特别之处在于它非常简单。你连接这个东西,你进入一个网页,登录一次,设置一个密码。然后它就能加 入你的 tailnet 了。对我来说,这是去年的另一场革命,就是发现这些 WireGuard 网络。Tailscale 本质上是将你拥有的所有计算机转变为本地网络,无论你身在何处。就像现在在我的手机上一样,我可以直接访问马里布办公室的所有计算机。我还可以访问哥本哈根办公室的所有计算机。
DHH: 我可以像坐在旁边一样使用它们,而无需在 firewall 上打孔或设置复杂的 VPN。这样做的作用只是减少了接入更多计算资源的麻烦。所以当我发现这一点时,我看了看我的衣柜,我意识到我有一堆之前实验中的迷你电脑,我只是说,“如果我把它们全部连接起来怎么办?”
Lex Fridman: 哦,哇。
DHH: 我刚刚连接了四台电脑——
Lex Fridman: 不错。
DHH: ……在壁橱里。每台都接着自己的 Comet 小盒子,突然间我可以在更多计算机上同时运行 agent,并且我可以用 Herdr 控制它们。这下真的把我自己的处理能力用满了。
Lex Fridman: 对。
DHH: 差不多是……怎么算呢?四五台机器,每台跑大概三个 agent,总共有 16 个 thread。这就是我能同时应付的数量。当然,agent 跑得越快,我能照看的 thread 就越少。按现在的速度,我可以同时让大约 16 个 thread 全速工作。这也是为什么我从兴奋变成了欣喜若狂。就像你说的,这种变化确实有点让人招架不住。以前我们和计算机之间的沟通,简直还停留在拨号上网的带宽。想想都好笑:一年前,我还坐在这里雕琢代码,一行一行地写。
DHH: 忙一个小时,可能写出一个漂亮的 controller、一个漂亮的 model,也就是一个文件。已经很用心地写了,最后可能留下 60 行。折算下来,我的带宽也 许就是每小时 30 行,可能还说高了,也许只有 20 行。现在我同时跑 16 个 thread,有时每小时能产出几百行代码。不过,先打住,我其实很讨厌这个指标,对吧?
DHH: 通常拿代码行数衡量这种事,就挺蠢的。大家一个劲炫耀自己写了多少行代码,真问一句“那你到底做出了什么”,却又支支吾吾,答不上来。编程圈里有人拿这种“AI psychosis”开涮,我觉得也没错。
Lex Fridman: 但它是个挺方便的简略说法——
DHH: 对,方便用来概括产出有多少。至于产出的东西是好是坏——
DHH: ……单凭这个指标判断不了。但我现在能做出多得多的东西,也能一直把这些任务并行推进。这就是我的工作环境。它仍然是 Neovim,但此时,我没有编写大量代码,因此我使用 Neovim 作为项目浏览器,然后用它启动 lazygit,查看 change log。即便如此,我想说,如果 GitHub 能更快地向你展示 pull request,那也许直接在 Web 上看会更舒服。我不知道。我一直在使用另一个名为 Hunk 的工具,它展示 diff 的方式很好。所以你也可以看看。
DHH: 但我发现当我看 Hunk 时,我只能看到 changeset,而当我查看 agent 的输出时,我经常想看到周围的上下文。哦,是的,所以它改变了这个文件,但实际上,我们另一个没改的文件里,是不是也有该一起改的东西?这就是为什么我仍然喜欢 Neovim 作为一种实现方式。但这一切当然都发生在 Omarchy 中。所以这一切都发生在 Linux 上。这是 agent 的另一个重大突破。agent 热爱 Unix 哲学。它喜欢可以通过 command line 调用的单独工具,在 Mac、Windows、Linux 这三大主流 operating system 里,没有谁比 Linux 更适合这种工作方式。
DHH: Linux 中的所有内容要么是 config file,要么是 CLI 工具。五分钟前,这就是它的主要缺点。这就是人们不喜欢 Linux 的原因。就像所有 config file 和 CLI 工具一样。
DHH: 这世界开的玩笑真妙:五分钟前还是 Linux 的缺点,转眼就成了它最大的卖点。这是其中一件事……四个月前,有个周末,我发现自己只能用 Mac 了。我以为我去的地方有一台 Linux 的电脑,所以我没有带笔记本电脑,到了才发现我只有一台 Mac Mini。因此,我只好将就着用,试着按 Linux 上习惯的方式配置这台 Mac。现在你实际上可以做很多事情。Homebrew 已经变得非常好。Homebrew 是 Mac 缺少的 package manager,并且没有人在简化设置方面为 Mac 的进步做出更多努力。
DHH: 但即使像 Raycast 这么简单的东西,不知道你用过没有。就是这样——没有你可以访问的 config file。你必须进入 GUI,导出一个文件,然后将该文件(我不知道)放在你背包里的什么破 U 盘上。然后你可以将其导入到其他地方。你无法自动化机器的整个设置。你无法自动化 Mac 默认 key binding 的所有配置。这必须是一个手动过程,你需要像穴居人一样点击鼠标来设置你的机器。
Lex Fridman: 我的意思是,有解决办法。
DHH: 不好用。我查过,也费劲试过。
Lex Fridman: 这就是我的旅程。显然我是一个 Linux 人,但由于 Adobe Premiere、Adobe 产品,我也是一个 Windows 人,所以我经常会使用 WSL,也就是 Windows Subsystem for Linux。
DHH: 是的。
Lex Fridman: 所以 Windows 里面的 Linux,这……在 agent 时代并不是一个好的 Linux,因为它只是——
DHH: 它是个 sandbox。
Lex Fridman: ……对,是个 sandbox ,而你希望 Linux 能放开手脚,什么都能做。
DHH: 没错。
Lex Fridman: 所以,我现在开始留意 GrayCat 这类东西了。你知道,我习惯用键盘操作,就会问:config file 在哪儿?能不能让 agent 替我把一切设置好,保存 configuration,再复制到其他系统上,让整个过程都自动完成?我不得不一个个问,可很多地方根本没有这种支持。
DHH: 他们没有好的答案。
Lex Fridman: 但很多时候你实际上可以自己构建应用程序。
DHH: 但有些变通办法。
Lex Fridman: 对,那是变通办法。
DHH: 有些临时凑合的办法。
Lex Fridman: 都是变通办法。
DHH: 你不必这样生活,Lex。还有更好的……实际上,这是一个伟大的时刻。
Lex Fridman: 等你先做出个视频编辑器再说吧。
12 对速度的执着
DHH: 所以这是一个美好的时刻。
Lex Fridman: 是的。
DHH: 听说今天是你的生日。
Lex Fridman: 是的。
DHH: 所以我带了一个小礼物。
Lex Fridman: 不。
DHH: 不管你愿不愿意,今天都得让你用上面向 agent 的 operating system。
Lex Fridman: 这太棒了。
DHH: 我问……我在 Dell 的朋友是否有一台机器可以送给你作为生日礼物。
Lex Fridman: 哦,不。
DHH: 这就是我用的那款机器……准确地说,和我的同款,不过这一台归你了。这是一台——
Lex Fridman: 不。
DHH: ……Dell XPS 14,已经装好了 Omarchy 4——
Lex Fridman: 哇哦
DHH: ……就等你完成个人设置了。等你发现这些……对了,我们真该计个时。回答大约五个问题,一分钟左右就能开始用。你愿意的话,现在就能当场试试。
Lex Fridman: 哦,Omarchy,DHH 的美观、现代、有鲜明设计取舍的 Linux。是的,让我们开始吧。
DHH: 是的,边说边填。所以——
Lex Fridman: 真酷。
DHH: ……你刚才说的那些 Mac 上的痛点,我那个周末也亲身体验过。我费了不少劲,找到了一些还不错的变通办法,主要是 Homebrew 现在有了安装 GUI 应用的 tabs。想想前不久大家还怎么装软件,真的很好笑:“我要用 Zoom。”他们会进入 Zoom.com,找到下载链接,下载 DMG-……双击它,看到一个奇怪的手动交互,告诉他们将图标从屏幕的一个位置拖到另一个位置,这就是安装应用程序的方式。你会一遍又一遍地这样做,直到拥有你想要的所有应用程序,如果你要设置一台新机器,并且你有 12 个应用程序,你会像穴居人一样去 12 个不同的网站下载它们。
DHH: Homebrew 解决了其中很多问题,但并没有全部解决,至于那些……它就完全没帮上忙——
Lex Fridman: 抱歉打扰了,但是看看这进展有多快。
DHH: 哦,40 秒左右就搞定了。这就进到 Omarchy 里了。
Lex Fridman: Super 是 Windows 或键盘上的 Command 键。那么 Super 键是哪一个呢?
DHH: 是的,这就是 Windows 键。哦,实际上,不,不,你有一个特别版。
Lex Fridman: 是啊。
DHH: 世界上大约只有六台这样的计算机。
Lex Fridman: 哦,有一个 Super 键。
DHH: 上面写着 Super,看看 Copilot 键在键盘另一端的位置。那是 Omarchy 标志。
Lex Fridman: 不错。好吧,酷。
DHH: 这是 Dell 的 Spencer Bull 帮忙做的。这些事情里有不少是我和他一起合作的,他们真的很棒。
Lex Fridman: 他们暂时放弃了 XPS 品牌。
DHH: 是,去年确实取消过。
Lex Fridman: 我当时想,“这太蠢了。这是……XPS 太棒了。”
DHH: 他们干的蠢事还不只是取消 XPS 这个名字。他们还取消了 Escape 键,并在顶部放置了电容式触摸按钮。这正是 Apple 大约三年前才意识到很糟糕、并且人人都讨厌的那个错误。但现在他们拥有一支令人难以置信的团队,这实际上是我自己的第一台 Dell 笔记本电脑。
DHH: 因为我的服务器一直使用 Dell。我们退出 cloud,用的就是 Dell 的 server。我记得从 2000 年代中期就在用了。但我从未运行过他们的笔记本电脑,因为与 MacBook 相比,它们达不到我的要求。2016 年,或者说 2026 年的 XPS 配备 Intel Panther Lake 芯片,才是第一款我自己真正愿意用的 Dell 笔记本。这很有趣,因为当我最初对 Apple 生气时,我想,“你知道吗?我应该买一台 Dell,”因为我们已经使用过它们等等,然后我买了一台 Dell,我想,“伙计,我做不到。我做不到。它不够好。”然后你瞧,今年他们刚刚解决了所有问题。续航好了,性能也好了。
DHH: 兼容性好了,重量降下来了,屏幕也升级了。这是一块 tandem OLED 屏幕——
Lex Fridman: 是的,这太不可思议了。
DHH: ……这意味着它实际上比你在 MacBook 中得到的技术更好。它比 MacBook 更轻,而且该芯片终于具有竞争力,因为 Intel 花了五年时间开发 18A 工艺节点。花了很长时间,但现在它来了,这真是令人难以置信。我们终于可以与 Apple M 芯片竞争了……续航能与之打平,性能也有得一拼。
Lex Fridman: 这东西有一个漂亮的默认主题,那它是什么?按 Super + Space 就能打开。
DHH: 其实只要按 Omarchy 键就可以了。它打开菜单。所以现在你可以从那里控制一切。
Lex Fridman: 哦,跟 Super 键一样。好,真酷。
DHH: 与 Super + Space 相同。所以这对我来说是个很大的变化:终于有一台 Linux 机器,不需要替它的短板找借口了。其实我不介意解释这些短板,说到底,只是有所取舍。我喜欢我上次谈到的 Framework 13。我还是喜欢他们。他们仍然制造出很好的计算机。但我认为对于很多人来说,他们并不想要 DIY 体验。他们想要一些开箱即用的东西,感觉它在构建质量等方面与 Mac 不相上下,现在我们终于拥有了它。生日快乐。
Lex Fridman: 非常感谢。DHH 的 Omarchy Dell 笔记本电脑是最好的生日礼物。这太棒了。
DHH: 顺便检查一下 screensaver。
Lex Fridman: 是的,这有点神奇。我看到了。
DHH: 在那 tandem OLED 屏幕上——
Lex Fridman: 太漂亮了。
DHH: ……这绝对是令人难以置信的棒。
Lex Fridman: 看看那个。整个界面都很复古,就像 Fiverr pop— —
DHH: 就像 20 世纪 90 年代开着一个 BBS,那正是我十四岁时做的事。所以对我来说,这一下就回到了过去。它把 Unix 里正在兴起的现代文化,和 90 年代的复古感融合在一起,这种风格太棒了。
Lex Fridman: 对,一个以 agent 为先的 OS,外表却这么复古,真有意思。
DHH: 这两者又很搭……所以,当这些 agent harness 以 TUI、CLI、terminal 的形式出现时,我才那么兴奋:因为突然间,全新一代的程序员和普通用户都发现了 terminal 的魅力。该 terminal 实际上是我们拥有的最令人印象深刻和最高效的 UI 之一。现在,我们从那时起就构建了更容易学习的 UI。鼠标是一项很棒的发明,可以让那些对计算机不太了解的人只需点击鼠标就能找到答案,但 terminal 是为那些想要学习他们的系统、想要学习键盘命令的人准备的。
Lex Fridman: 所以你认为 TUI 会继续存在吗?
DHH: 100%。现在,这不会是唯一的事情。当然不是,因为这些实验室现在估值高达数万亿美元,因此它们需要能够接触到数十亿人。我认为我们不会向数十亿人传授 TUI 的复杂性。所以还会有其他工具,实际上已经有了。对了,Linux 有个很棒的东西,就是 ChatGPT Codex 工具。
Lex Fridman: 是的,我看到了。
DHH: 消息发布后不到两个小时,我就已经把它打包好,放进 Omachi 里了。现在,如果你转到……你实际上可以按 Omachi 键——……然后只需写 ChatGPT。应该会弹出安装选项。
Lex Fridman: 不错。
DHH: 然后按回车即可。
Lex Fridman: Lex 的 sudo 密码。
DHH: 是的,无论你输入什么。然后它就会安装它, 它会弹出它,你就有了 ChatGPT。
Lex Fridman: 不错。
DHH: 很多应用程序就是这样,所有的 agent harness 都是这样构建的。刚才说的 Tailscale,想用也可以这样装。Dropbox 也是。所有这些东西都在那里的原因是因为我使用它们。这是因为我为自己构建了这个系统,并且我想,首先也是最重要的是,如何为我构建我梦想的计算机?如果我得到了我梦想的电脑,我确信其他人也会有和我一样的梦想。
Lex Fridman: 现在,你痴迷于让安装时间在一分钟以内,并且很多人在网上问你为什么。那么为什么呢?为什么你如此着迷于让安装时间少于 60 秒?
DHH: 首先,让我引用 Michel Hashimoto 的一句话,他创建了非常棒的 Ghostty terminal,并且在 Omachi 上也可以使用,他也是 HashiCorp 的创始人,他不久前在 X 上发表了一篇很棒的帖子,里面有句话特别有力:“追求卓越无需解释。”想要把东西做得尽可能好、尽可能快、尽可能漂亮,不需要任何理由。
DHH: 我们应该想要漂亮、快速、使用起来令人愉悦的系统。现在,安装时间的有趣之处在于我一开始的目标并不是一分钟。一开始我的目标很保守。我想如果我能在 15 分钟内设置好整个系统,那么与之前相比已经是一个巨大的进步,我会非常高兴。事实上,大家用来比较的基准,早已偏离合理水平。你谈到 Commodore 64 是你的第一台计算机,对吧?
Lex Fridman: 嗯嗯。
DHH: Commodore 64 拆箱后,按下电源键,我记得不到一秒,BASIC interpreter 就已经在等你输入命令了,几乎是瞬间启动。再说说我新买的 Mac。我买它是为了 Adobe Lightroom,那是我还没在 Linux 上用 vibe coding 做出替代品的一个应用。 你知道,把那台新 Mac 设置好,我用了多久吗?
DHH: 全新的电脑,刚拆箱。我开始设置,然后就要更新软件。等系统全部更新完,终于可以安装 Adobe Lightroom 时,已经过去 42 分钟了。这太奇怪了。这太荒谬了。这对每个喜欢电脑的人来说都是一种侮辱,你买了一台新电脑,在使用它之前,你必须花 42 分钟进行更新……对出厂时就已经安装在电脑上的东西进行更新。这太荒谬了,而且疯狂的是,这还不是最糟糕的事情。我还买了一台 PC,因为所有这些 Linux 机器都是 PC,对吧?
Lex Fridman: 对。
DHH: 它们预装了 Windows。所以我得到了一个。这只是三周前的事。全新机器,Intel Panther Lake,全套最新配置。从打开包装到可以使用需要 1 小时 35 分钟。而你刚才用了多久,就进到 Omarchy 里了?
Lex Fridman: 我的意思是,这肯定不到一分钟。
DHH: 一分钟。
Lex Fridman: 是的。
DHH: 我们可以像这样建造计算机。我们有技术。自 1981 年 Commodore 64 首次问世以来,我们就拥有了这项技术。事实上,我们现在拥有一台速度快一万亿倍的计算机,而你必须花 42 分钟或一个半小时来设置它才能准备使用,这让我非常恼火,以至于它变成了一种激情。有趣的是,就在我们在这里休息的时候,我正在和我的搭档 Ryan Hughes 交谈。我们觉得,已经找到了一条路:为特定机器预先制作 Turbo image。因为需要利用对硬件的了解,比如 Dell XPS,所以要按机型来做。我们打算做一个 Dell XPS Turbo image,大约 12 秒就能装好。完整的 Linux 系统——
Lex Fridman: 是啊
DHH: ……大约 12 秒内安装完毕。
Lex Fridman: 太不可思议了。
DHH: 这种不肯将就的执着,才是用计算机让我如此满足的原因。这就是为什么我现在所处的 agent 加速现实如此令人振奋。因为我可以看到这些限制然后想,你知道吗?当我们进行到五分钟时我本可以停下来。那已经足够快了。这就是关于 X 的争论,对吗?你为什么还要继续走下去?五分钟已经够快了。好吧,也许对你来说,但对我来说,12 秒更有趣。我总是想,尝试思考这些第一性原理。好吧,在那台机器上,实际上再次按下 Omarchy 键,然后输入 speed。你会看到出现一个列表,其中之一是磁盘速度。
Lex Fridman: 速度测试,网络速度,磁盘速度。
DHH: 磁盘速度。执行该操作,然后运行它。这是测试内置 NVMe 驱动器的性能,你得到了什么?
Lex Fridman: 每秒 7 GB。
DHH: 所以每秒 7 GB。这就是驱动器的速度。为什么我们不能在一秒钟内安装 Linux distribution?Omarchy distribution 大小为 5.8 GB。既然它能达到每秒 7 GB……当然,现在你实际上无法做到这一点,因为 U 盘比这慢得多,但目标就应该是把底层硬件和 protocol 允许的性能尽量用满。我们得一路追问到这些最基本的限制。
Lex Fridman: 是啊,我很喜欢你选择做 Linux distribution。你本来什么都能做,但做这个,意味着你在重新思考计算机到底是什么,因为 operating system 决定了最根本的——
DHH: 对。
Lex Fridman: ……你与计算机交互。
DHH: 是的。而且它已经如此陈旧了。
Lex Fridman: 是,确实。
DHH: 我们今天的 macOS 与 10 年前的 macOS 几乎没有什么不同。事实上,在 很多方面情况都更糟,因为 Apple 不断限制用户对自己设备的控制。它们不希望用户安装未经 Apple 允许的软件。他们不希望用户在不手动操作的情况下重新配置 hotkey。连切换 workspace 时那 500 毫秒的动画,他们都不愿意改。这是一台令人恼火的锁定计算机。现在,值得 Apple 称赞的是,对于一台限制这么多的计算机而言,它已经做得不错,但我不想要一台锁定的计算机。我想拥有我的电脑。更好的是,我想改变我的计算机,这就是 agent 时代需要新 operating system 的地方。
DHH: 当你可以对你想到的任何应用程序进行 vibe coding 时,你应该能够对你的 operating system 进行 vibe coding。你应该能够更改任何内容,例如它的外观、工作原理、有哪些面板、没有哪些面板,而这需要 Linux。就这么简单。没有……其他两个 operating system 都无法提供这一点。
Lex Fridman: 我记得 X 上有人问过你:“你算老几,怎么就觉得自己能比 Ubuntu 做得好?”或者,“Ubuntu 已经挺好了,你干吗还做这个?”你回答:“因为我觉得自己能做得更好。”这股劲儿从哪儿来?怎么敢相信,凭你一个人,或是再加上 Ryan,就能做出比 Ubuntu、Arch 这些系统更好的东西?
DHH: 嗯,我会说它一开始并没有那么宏伟。当我开始我的 Linux 之旅时,我实际上刚刚开始使用 Ubuntu,并且我只是在它的基础上进行构建。这个系统已经做了很多我想做的事情,至少是 Linux。那么我可以在它的基础上进行构建并使其更加现代,使其实际上看起来不错,并拥有我想要使用的程序吗?我先做出了一个大致符合想法的版本,然后我发现你可以深入七层,而且,你越接近底层硬件,越接近 kernel,越接近每一个 package 等等,你发现的自由就越大。
DHH: 因此,当我发现越来越多的自由时,我变得越来越雄心勃勃,我意识到,哦,果然不出所料,我对计算机应该如何工作、它们应该如何外观、应该安装什么程序以及安装它们是否应该花费 42 分钟或 45 秒有强烈的意见。顺便说一句,这是当前的世界纪录。所以如果有人在这之后安装了 Omarchy Quattro 并且安装时间能少于 45 秒,截图并发给我,你就会成为新的世界纪录保持者。
Lex Fridman: 你何时——多久前跨过 60 秒大关的?
DHH: 很有趣,因为就像旧的限制一样,那是什么?这是四分钟一英里之类的——就像 1952 年那样——人们认为人类不可能超越。后来一个人突破了纪录,接着几个月里,又有三个人做到了,对吗?所以我们有这个目标。我原本的目标是两分钟。
DHH: 后来我们做到了两分钟以内,我就想:“既然能少于两分钟,为什么不能少于一分钟?”我记得当时的想法是,“这太疯狂了。现代 operating system 都需要 42 分钟,你不可能在一分钟内安装好它们……”如果其他 operating system 需要 42 分钟,对吧?就像 Apple 公司一样,充满了很多聪明人,比如,花了 42 分钟,所以这该是基准了吧。不,这不是基准,因为没有速度限制。就像,几乎在任何情况下,你认为理所当然的事情都不是不可改变的现实法则。在驱动器能够传输的数据达到每秒 7 GB 之前,你还没有达到极限,因此你应该继续努力。当然,然后它本身就变成了一个游戏和一种满足感。
DHH: 每省下一秒,都让我兴奋。当我们打破一分钟的障碍时,我想,这实际上只是在大约三周前,甚至两周前被打破,我简直疯了。然后我得到了一群 agent 来运行 auto research loop,逐一试验各种 设想,就像,哦,如果你改变这个东西,如果你改变那个东西,如果你把它删掉怎么办?如果你并行做事情怎么办?如果当你输入用户名时,我们开始把 package 预先加载到内存里,是不是就能更快地装上去?这变成了一个有趣的游戏。我认为这就是你应该如何思考产品开发。这应该很有趣。你应该带着一点玩心,不必事事都那么严肃。

图 6 · 速度目标推动反复试验。 根据第 12 节整理。时间均为 DHH 在访谈中的自述;“约 12 秒”是为特定机型制作 Turbo image 的设想,尚非已实现的结果,也不能作为统一条件下的性能对比。
DHH: 就该试着超过目标,做得比所谓的“够用”好得多。
Lex Fridman: 特别是现在,因为你可以移动得如此之快,并且由于 agent 你可以尝试很多不同的方法。
DHH: 是的,这只会让它更令人满意。但我认为这始终是正确的。如果你看看有史以来最伟大的 Mercedes-Benz,我认为它被称为 W126。我看过这部精彩的纪录片。主导这个项目的是一位在 Mercedes-Benz 安全部门工作了多年的人。突然间,他被任命负责整个 S-Class 项目,他把能用的好东西全加进去了,包括自动回收安全带、前灯清洗装置等等。这辆车的设计和用料远远超过了市场通常要求的程度。
DHH: 太难以置信了。但你看着它,然后说:“好吧,我想要那个。”就像你看着机械表时会问:“它能下潜到 100 米吗?”或者,或者我认为 Rolex 有一个可以下潜到 4,000 米,深海,深海潜水员海洋——……或者无论它叫什么。买这块表的人,全世界可能也就三个真会把它带到那个深度。但你难道不想成为那种想要推动人类进步的人们的赞助人吗?我想要最快的汽车突破速度限制。我想要一块可以潜入马里亚纳海沟的潜水表。我想要一个可以在 60 秒内安装的 operating system。
Lex Fridman: 从个人角度,我很佩服这样的人,也觉得大家都该有这种追求。还得说说它带来的影响:哪怕追求的指标看起来有点不务正业,这种精益求精也可能意外带来别的突破、发现和创新,很多甚至与速度无关。
DHH: 100%。
Lex Fridman: 对,重点是探索。把一个具体指标当作催化剂,让它推动创新,这很好,因为过程中总会有新的发现。这和你去月球、去火星的原因是一样的。就像,为什么?谁在乎?嗯,事实上,真正的事情是你会发现很多关于化学推进的知识。你会发现很多关于人类如何在太空中长期生存的知识。也许你会发现在太空中使用太阳能或在太空中使用数据中心或其他什么的全新方法。
DHH: 没错。
Lex Fridman: 各种各样的……也许你会遇到——
DHH: 没错。
Lex Fridman: ……外星人,但你永远不知道。但设定一个目标并追逐它,尤其是当它是数字的时候,真的很好。
DHH: 设定一个宏伟的目标就更好了。当你拒绝只做实用的事情,而努力追求稍微超出合理范围的事情时,魔法就会发生。我们应该全力以赴。这是原因之一……事实上,在某种程度上,这个特定目标是因为看到其他人这样做而激发的。我的意思是,Elon 就是我们这次谈话中最突出的例子。这家伙的目标是如此远大。乍一看,它们似乎很荒谬。我自己就不止一次觉得那些目标荒唐。然后你意识到它们有时会实现。也许并不总是按计划进行,那又怎样?所以呢?所以我们没有如期得到自动驾驶汽车。早在 2017 年,我就因为这件事对 Elon 骂了很多遍。
DHH: 但现在它就在这里,除了那个在 17 年认为这是可能的人之外,谁会把我们带到这里,他对现实如此不耐烦,以至于光凭那股劲,就要把现实推到自己想要的位置。我认为这非常鼓舞人心,我们需要有人把目标再往前推。我们需要有人跑完四分钟一英里,所以我们其他人意识到,“好吧,但我想我可以跑得更快。”这就是我努力争取的目标,我真的为 Omarchy 努力奋斗,因为这样生活更有趣,心里装着更大的追求和抱负。我会说我实际上已经改变了一点想法。过去我说过很多次,许多人其实不需要这么大的雄心。
DHH: 这话也没错。我们不希望 80 亿 Elon 在世界各地奔跑。我想这会相当疯狂。但我逐渐意识到,对于企业家来说,拥有合适的宏大目标是健康的。就算只是开一家意大利餐厅,也不该止步于把店开着。也许我只是经营一家意大利餐厅,但我做的披萨可能是最好的。我做的帕尔马干酪最美味。我们必须追求卓越,才能激发继续前进的动力。
Lex Fridman: 是的,敢于大胆思考,就像你可以建造一个 Linux——
13 语音 prompt 与键盘输入
DHH: 是的。
Lex Fridman: ……distribution。要把它做到这么快,你还记得哪些具体办法?刚才你提过,有些是 agent 发现的。
DHH: 其中一件事是利用等人输入的时间做 preload。因此,在设置 Omarchy 机器时,你需要回答五个问题。所以它在后台做一些事情。我们正在后台做一些事情。这是我甚至没有考虑到的事情之一,我的意思是,这其实是个老得不能再老的办法。很长一段时间以来,各种视频游戏都这样做,让玩家与某些东西进行交互,然后在后台进行 preload 等等。所以这是一种古老的技术,但我只是没有想到把它用在安装程序上。
DHH: 我原来的想法是,先问用户密码、用户名、时区这些问题,问完再开始安装。其实这些东西完全可以提前加载。还有一些优化,是调整 installer 执行各项操作的顺序,以及直接缩小安装包。上一版 Omarchy 是 7.5 GB,现在安装过程的大部分时间,其实都花在解压 package 上。这些 package 占了 ISO 的大头,也占了安装时间的大头。我们把体积缩到现在大概 5.85 GB,减掉了不少,而省下的体积,几乎一比一地换成了省下的时间。这方面我做了些很有意思的事。
DHH: 所以 Omarchy 使用了 JetBrains 字体,这是一个很棒的字体,漂亮的字体,实际上我第一眼其实不太喜欢,但后来发现,在 Mitchell Hashimoto 的 Ghostty 里,它是唯一能呈现出完美效果的字体。Ghostty,无论出于何种原因,不想以我习惯的方式呈现我心爱的 Bitstream Vera Sans。嗯嗯。但它完美地渲染了这个 JetBrains 字体,所以我就切换了。但是它……Arch 上的 JetBrains 字体的标准包是 200 兆字节,因为它包括所有这些变体和所有这些子类型等等。我意识到,我们没有使用其中任何一个。我们在这个 Nerd Font patched 版本中使用 monospace 版本。你知道那有多大吗?我认为是 16 兆字节。唔。
DHH: 所以,我干脆做了一个精简版的 JetBrains font package,一下就省了 180 MB。然后逐个检查,类似的事又做了不少。NVIDIA driver 也是这样。Arch repo 里的 driver 没用最高强度的压缩,我记得那种格式叫 ZSTD。压缩起来很慢,但慢的是生成 archive 的过程。如果多花点打包时间就能缩小 ISO,那我有的是时间等。光是两个 NVIDIA package,我记得就省了 200 MB。我特别喜欢这个过程,感觉自己像个 McLaren 的汽车设计师。
DHH: McLaren 目前正在制造一些世界上最轻的超级跑车,他们绝对痴迷于连最后一克重量都要抠。这就是为什么即使是新的 750S McLaren 也比竞争对手轻得多。他们使用碳纤维硬壳式车身,这让它们比使用铝制车身的 Ferrari 等对手更有优势。但他们也对重量有这种痴迷,我会看到 McLaren 人员的采访,他们对一些记者说,“是的,我们减轻了 370 克。”我就想:“等等,一辆车重 1,040 公斤,还是 1,380 公斤来着,他们还在计较这 370 克?”是的。多么痴迷的疯子。是的。我爱他们。是的。我就想让生活里多点这样的人和事。
DHH: 我想要一个 McLaren 就是因为这个原因。因此,当我从 package 中削减单个兆字节时,我想,伙计,我有点像这里的 McLaren 汽车开发人员,尽管我的意思是,我们甚至还没有完成这项工作。package 还可以进一步精简。但这实际上是 Omarchy 与传统 Linux 社区之间的另一个争论:所谓的 bloat。有些圈子觉得,预装软件就是不合规矩:你凭什么替用户决定该用什么程序?我就想,“伙计,这就是他妈的名字。它叫 Omarchy,因为 Oma 部分是 omakase 的缩写,字面意思是厨师的选择。我就是那个厨师。”
DHH: 我正在做出选择,这是我认为很棒的应用程序集合,”顺便说一下,它有一个视频编辑器。它与 OBS 一起提供来录制视频。它就在那里。是的。预装 OBS。好的。Kdenlive 是一个视频编辑器,时间线编辑器,非常棒。我用它编辑我所有的视频。然后我制作了自己的剪辑编辑器。你谈到了同步的事情。是的。我也有剪片段的需求。比如做完一期播客,想截一小段发到 X 上。而且使用 Kdenlive 或其他时间线编辑器有点麻烦,所以我制作了 Omacut。Omacut 也包括在内。Omacut,酷。它只是用于制作剪辑,你可以用键盘驱动整个东西。这样你就可以到达正确的时间标记。
DHH: 然后你可以按 Control + Space。就会把片段起点设在那里。然后转到剪辑的末尾,按 Alt + Space,就会设好终点。好的。然后你按 Control + S,它就保存了。好的。我现在可以使用 Omacut 快速制作剪辑。太棒了。但它上面有所有的软件。上面有 Neovim。上面有 Herdr。它有 tmux。它有一个 terminal。它有很多主题。它有一堆背景图片,是我能选出的最好的。这会占用一些空间。应该是这样,因为我不想交给你一片荒地,让你什么都得从头搭。当你打开包装时,这应该是一个高效的系统。它内置了什么?
DHH: Linux configuration 这部分主要是用 Bash 写的。它很适合干这个,本来就是为 system administration 这类工作设计的。当然,它也有局限,不能什么都拿 Bash 来写。
Lex Fridman: 生成 Bash 的 agent 怎么样?不错?
DHH: 哦,太棒了。
Lex Fridman: 好的。
DHH: 只有一件事例外,每次逮到,我都得敲敲 agent 的脑袋,提醒它去看那份 Markdown 指令文件:里面明明写了,不要用 early exit。agent 很喜 欢 precondition,不爱写完整的 conditional。我喜欢“如果这样,就那么做”;它们喜欢“这个前提不满足就退出,下一个前提不满足再退出”。
DHH: 然后一路往下,才到真正要做的那件事。我讨厌这种风格。除此之外,它写 Bash 已经好得惊人了。上次我们聊天时,我还是先问 agent 某段 Bash 怎么写,再自己敲进去,但其实记不太住。后来我刻意下功夫学,免得动手的本事全丢了。结果刚学会自己写 Bash,现在又一行都不写了。大概已经好几个月没亲手写过,因为 agent 太厉害了。你只要给一点风格上的指引,偶尔提醒它别搞得太复杂……这事我前几天还在 X 上说过。
DHH: 有件事我总觉得不可思议:agent 做完一件事,说完成了,再让另一个 agent review,也说没问题。可我只要说一句“看起来是不是太复杂了”,它就会说:“对,你说得对,我把它搞复杂了。”接着把实现砍掉一半。我就想,一开始不能这么做吗?后来有人提醒我,人也一样。你做完一件事,同事看过后说“好像有点复杂”,你往往也会反应过来:“还真是。”
Lex Fridman: 你看,这些小细节就让我觉得,程序员的直觉还是有用的。你刚才怎么说的来着?你对代码的整体样貌有感觉。
DHH: 当我构建像 Omarchy 这样的东西时,我会查看代码。我看形状。
Lex Fridman: 是的。
DHH: 我看比例。
Lex Fridman: 是的。
DHH: 我不必再亲手雕琢每一处细节了。当然,这又是在给自己脸上贴金:前一刻还把自己当成 McLaren 工程师,下一刻又成了 da Vinci,带着一整个工作室的学生。大理石上的细活都由学生来做,我只要说:“不,这个比例还不对 。”现在和 agent 合作就是这种感觉,我可以像编辑一样给反馈。
DHH: 那个,你知道吗?我不会自己写下所有内容,但哪里说不通,我看得出来;方案的规模和要解决的问题是否相称,我也看得出来,或者什么时候感觉太复杂。令人震惊的是,它常常奏效。就像早期的笑话一样,“不要犯错误”。我认为你不必再告诉 agent 了,因为现在 harness 非常好,它们会运行 automated test,拿到反馈。但你实际上必须告诉他们,“让它变得更简单。”
Lex Fridman: 你是否使用语音进行交互?或者你……你打了多少字?你有多少是——
DHH: 我全都用打字。Omarchy 内置了 Voxtype 语音转写,其实效果挺好。只是我的思考习惯好像不适合这种方式。连我自己都意外,原来我不喜欢对着电脑说话。我喜欢在车里的时候,但是当我在键盘前时,我只想打字。我也只是喜欢打字。你用的是语音吗?
Lex Fridman: 我是一个内向的人,不喜欢社交……或说话。还有——
DHH: 我想这也是我的一部分。
Lex Fridman: 但不知为什么,语音对我特别管用。给你看看这个……我跑步时会带着它,叫 Plaud,就夹在 T 恤这里。
Lex Fridman: 按一下按钮,它就开始录音。这种方式在思路的流畅程度上,甚至比坐在电脑前更好。通常我想好好梳理的,是 agent 提出来的问题。我会说一大段 prompt,很多就是边想边说,有点像意识流。说到一半,可能还会改变某个设计,但整个思考过程都录下来了,再让 LLM 处理。Plaud 有 API,可以把录音取出来,transcribe,再整理 transcript。因为我会提到文件、function 等技术概念,所以必须让——
Lex Fridman: ……speech-to-text 把这些词识别对。你需要一份 dictionary,处理这些文件时,还得让它了解 codebase。最后拿到的,往往就是我花十分钟、十五分钟、二十分钟讲整个设计的一大段内容。我发现这特别有用。系统知道了我围绕想法展开的那么多思考,反而不会有把要求规定得太死的问题。设计的早期阶段尤其适合这么做。假如我要从头做 Omarchy,最开始会先把思路说一遍,也许得说一个小时。我确实录过一小时的 prompt,一边跑步——
DHH: 太棒了。
Lex Fridman: ……然后说话。我强烈建议人们尝试基于语音的——
DHH: 所以——
Lex Fridman: ……一口气多说一会儿。
DHH: 其实我还没有——
Lex Fridman: 别只说几句很具体的指令……
DHH: ……我没有,是的,我没有那样用过它,也许这就是我用错的方式。我尝试只输入或说出两个句子,然后我有点沮丧,因为我可能可以同样快地输入这句话。但我还没有尝试过连续说话 20 分钟的整个过程。
Lex Fridman: 尤其是你,因为你说得很快。
DHH: 对,这么说我就明白了。我想是因为我一直把它用来做,比如回复电子邮件之类的事情,而且我认为它可以有所帮助。它确实做到了,但是它会犯一个小错误,我必须纠正这个错误。但如果你对 LLM 做意识流,反正它也不在意那些零碎的小错误——……这可能会效果更好。
Lex Fridman: 有两件事要做。首先,把原始录音 transcribe 成文字。我使用 ElevenLabs 进行转录。它们可能是最好的 speech-to-text model。那里仍然存在错误,所以你需要有一个可以访问字典和大量信息的 prompt——
DHH: 你如何建立字典?
Lex Fridman: 首先,有一本与你相关的术语词典。再让它了解……所以你有一个 agent,当你谈论代码时,它会浏览整个 codebase 以查找你经常使用的关键术语。此外,当我们谈论消息传递、Gmail 和 WhatsApp 等时,它会意识到容易转写错误的人名和常用术语。
DHH: 你真的已经深入其中了。
Lex Fridman: 这对我来说是一个需要解决的问题——
DHH: 是的。
Lex Fridman: ……因为 speech-to-text 可能会遇到的问题之一是它有时会出错。
DHH: 正确。然后我就不能用它来听写电子邮件了。
Lex Fridman: 对。如果它从不犯错误,那么你——
DHH: 那就更有吸引力了。
Lex Fridman: 是的,实际上,不完全实时也没关系。你等五秒钟就可以了——
DHH: 对。
Lex Fridman: ……有可能。我不知道你的用例是什么。我可以等五秒钟——……十秒钟,让它处理所有的事情。
DHH: 你该用 vibe coding 把它做成一个应用,把这些步骤全包起来,这样——
Lex Fridman: 对。
DHH: ……它就可以了。
Lex Fridman: 我想我在线下向你提到过,翻译做得并不完美令我感到非常惊讶。
DHH: 对。
Lex Fridman: speech-to-speech translation。
DHH: 通过将所有这些东西放在一起,你似乎已经更接近现有技术所能达到的最佳效果了。