Lex Fridman 对话 DHH：Omarchy，才是真正属于 Agent 时代的操作系统

AI新浪潮观察

20min read

Lex Fridman 对话 DHH：Omarchy，才是真正属于 Agent 时代的操作系统

Founder Park2026/09/28

摘要

AIOS的界面，应该可以被用户随时改写。

本文首发于 Founder Park 公众号 · 2026 年 9 月 3 日

Omarchy 最近很火，隐约已经要成为今年最火的 Linux 桌面系统，以及可能是第一个 Agent 时代的操作系统。

开发者 David Heinemeier Hansson（DHH）功不可没，作为 Ruby on Rails 的创造者、37signals 联合创始人兼 CTO。过去 25 年，他以手写代码闻名。甚至一年前，他对于 Agent 编程还持怀疑态度。但 Quattro 发布的新功能代码，已经没有一行出自他本人之手，全部由 Agent 编写。

DHH 把 Omarchy 定位为第一个「Agent 原生操作系统」。在他看来，如果 Agent 已经能够理解自然语言、调用系统工具并编写软件，操作系统本身也应该随之改变。界面、功能乃至整套系统，都可以按个人需求随时改写。以前，人需要学习如何使用一台计算机。在他的设想里，计算机将可以按照人的意愿被重塑。

近期，DHH 做客 Lex Fridman 的播客节目。在超过五小时的对谈里，两人从 Omarchy 出发，聊到了 AI 时代操作系统形态、软件生产和编程方式正在发生的变化。

播客较长，Founder Park 编辑节选了部分内容。

Founder Park 正在持续寻找值得被看见的 AI 团队与项目。

我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。

如果你正在做 AI 相关的事，欢迎和我们聊聊。01没有手写一行新代码，DHH 做出了 Agent 原生的操作系统

Lex Fridman：先介绍一下，Omarchy 是什么？

DHH：Omarchy 是一套漂亮、现代、有明确取舍的 Linux 系统，是 macOS 和 Windows 的替代方案。它基于 Arch Linux 和 Hyprland 平铺式窗口管理器。名字里的「Oma」来自日语 omakase，意思是「交给厨师」，我就是那个厨师，我来替你做技术选型。

这个项目才一年多。去年夏天，我在勒芒 24 小时耐力赛的间隙看了很多 Linux 美化视频，又一次掉进了这个坑。我的第一次尝试叫 Omakub，建立在 Ubuntu 之上。它还不错，但我希望能够进入更底层的位置，控制系统里的更多东西，于是有了基于 Arch Linux 的 Omarchy。

最早的 Omarchy 诞生在 Agent 之前，那些 Bash 脚本都是我手写的。随后几个版本开始部分采用 Agent。到了 Quattro，过去三个月几乎已经是全速使用 Agent，最近两个月则是 100%。

Quattro 最终发布的新功能代码，没有一行是我亲手写的。关键的模型层代码，我会查看整体结构和具体实现。很多 UI 和辅助代码，我没有逐行看过。三个月内，我合并了超过 1000 个 Pull Request。代码由 Agent 完成，我负责掌舵。

这带来了完全不同的开发体验。过去，开发能力会限制我的野心。现在，我可以看着 Windows、macOS 或其他 Linux 系统里的任何功能说：「我也想要这个。」Agent 通常五分钟就能交付，复杂一些的需要 20 分钟，真的很夸张的需求也不过两小时。

这就像有一个精灵突然从瓶子里跳出来，告诉你操作系统里梦想过的功能都能实现，谁不会感到兴奋？

但我没有被这种能力压垮，因为我有一个明确的目标，创造一台完美的计算机。所有 AI 实验都指向这个结果。Agent 带来的真正变化，是增加了大脑中的想法与屏幕上的软件之间的带宽，像从拨号上网直接切换到了光纤。

Lex Fridman：为什么偏偏选择重做操作系统？Ubuntu 已经相当成熟，你为什么会觉得自己可以做得更好？

DHH：一开始，我的野心并没有这么大。我只是想让 Ubuntu 更现代、更好看，预装我真正使用的软件。

但随着进入更底层的位置，我发现距离内核和具体软件包越近，拥有的自由越多。我的野心也随之变大。我对计算机应该怎样工作、怎样呈现、预装什么程序，以及安装究竟应该花 42 分钟还是 45 秒，都有非常明确的想法。

操作系统是人和计算机交互的基础，但这个领域已经停滞太久。今天的 macOS 和十年前没有太大不同，有些方面甚至更封闭。用户不能自由安装软件，很多快捷键只能手动修改，连切换工作区的动画时间都不容易调整。

我不想要一台被锁住的计算机。我想真正拥有它，更进一步，我想随时改变它。当用户已经可以 Vibe Coding 出任何应用时，也应该能够 Vibe Coding 自己的操作系统。

02AI OS 的界面，应该可以被用户随时改写

Lex Fridman：你把 Omarchy 称为「可塑计算机」。它和今天在操作系统里增加一个 AI 助手有什么不同？

DHH：Omarchy 有一套更完整的插件系统。用户可以创建插件，改写操作系统的界面、面板和功能。比如，Omarchy 默认带有一个日历，点击时钟就会弹出来，但它不支持 iCal。几天内，社区已经做出了大约 17 种不同的日历实现。

插件市场上线三天，就出现了 330 个插件。这是我参与过的项目里从未见过的增长速度。我从来没见过这么广泛的参与，也从没见过这么多人能这么快地为自己创造有意义的软件，而且这些软件也能被别人使用。

关键在于，Omarchy 内置了一组 Skill，告诉用户带来的任何 Agent，应该怎样为这套系统开发扩展。用户不需要先理解插件架构，只要说清楚自己想要什么，Agent 就能把它做出来。

过去，只有程序员能够体验这种感觉，输入一组严格的命令，计算机按照要求发生变化。现在，一个人可以用自然语言说上 20 分钟：「这里最好有个面板。不对，应该放到另一边，再加上这个信息。」最后，操作系统就会变成他想要的样子。

这就是我所说的可塑计算机。Commodore 64 开机后直接进入 BASIC，计算机从一开始就是可塑的。你打开它，它等着你告诉它做什么，只不过当时必须先学会一套近似象形文字的语言。

现在，Agent 给了我们一块「罗塞塔石碑」*。用户可以直接说出自己的需求，让计算机按照自己的样子发生变化。一旦体验过这种力量，就很难再回到一套只能接受厂商预设的系统。

注：一块制作于公元前 196 年的花岗闪长岩石碑，它是破解失传千余年古埃及象形文字的关键钥匙。

Lex Fridman：Agent 会怎么改变系统的软件分发、更新和维护？

DHH：Agent 天生就喜欢 Unix 哲学，这也是 Linux 适合 Agent 的原因。普通用户不喜欢 Linux，正因为它里面的一切，要么是配置文件，要么是命令行工具。以前这让普通人望而却步，现在这恰好是 Agent 最擅长操作的界面。地球上没有哪个主流操作系统能像 Linux 一样，完美地支持这种机制。

真是讽刺，宇宙竟然跟我们开了个玩笑。五分钟前 Linux 的缺点，现在成了它的主要卖点。

四个月前，我以为自己这周末只能用 Mac 了。像 Raycast 这种工具？没有配置文件，你得进 GUI 导出、用 U 盘导入。你无法自动化整台 Mac 的配置，甚至不能自动化默认键绑定，你得像原始人一样用鼠标点。

而 Agent 已经消除了 Linux 所有的困难。自从今年年初，我的 Linux 机器上没有一个问题是 Agent 无法诊断的。以前还要泡论坛找答案，现在 Agent 知道 Linux 的 4000 万行源码，知道我机器上每个软件的源码。当 Linux 报一个对人类来说毫无意义的晦涩错误信息时，Agent 能立刻把它和训练数据中的源码关联起来，精确定位问题。错误信息越具体、越晦涩，对 Agent 反而越有用。

新工具发布后，也可以很快进入系统。ChatGPT Codex 客户端发布大约两小时后，我已经把它封装好，放进 Omarchy 的安装菜单。用户搜索 ChatGPT、按下回车，就能完成安装。

Agent Harness 的更新频率更夸张，有时一天更新七次。传统软件包管理器并不是为这种速度设计的，所以我们使用 mise 管理这些快速变化的开发工具。

故障处理也在变化。Omarchy Quattro 内置了一个崩溃监视器。任何应用崩溃后，系统都会询问用户是否让 AI 诊断。Agent 可以查看系统日志、找到应用的源代码，定位到某个 Rust 文件中的具体一行，再替用户整理 Bug Report。

Lex Fridman：那么，未来的主要交互界面会是什么？

DHH：终端一定会保留下来。但模型公司需要服务数十亿用户，不可能要求所有人都学会终端，因此它不会是唯一的入口。

Agent 编程最初从 TUI（终端用户界面）和 CLI 开始，我非常喜欢这一点。鼠标和图形界面降低了学习门槛，让普通人可以通过点击探索系统。终端则适合希望理解和控制计算机的人。

Lex Fridman：你用语音吗？

DHH：我自己不用，我就是喜欢打字。但 Omarchy 内置了 VoxType 语音转写。

很多人会觉得，直接对计算机说「给我做一个股票面板，我想追踪 Apple 和 Dell」非常自然。Agent 可以通过语音接收需求、完成开发，随后操作系统里就真的多出一个面板。

我能想象到，如果有一天，对着你的操作系统说上 20 分钟，它的界面和功能就能不断生成、变化。那就是 Iron Man 里 Jarvis 的感觉，定制化应用凭空出现。我觉得这也是 Linux 会全面胜出的原因之一。

03很多组织的限制不是实现能力，是愿景和品味

Lex Fridman：你真觉得普通人会从 Mac 切到 Linux？

DHH：如果没有令人信服的理由，人们很难切换系统。这正是 Omarchy 的主要设计目标之一。Ubuntu 试过做一个「便宜版 Mac」，结果不行，人们不要更差的仿制品。Omarchy 走的是完全不同的路，不是模仿，是提出一种全新的可能性。平铺式窗口管理器、键盘驱动、Agent 原生，这些东西一旦你体验过，就回不去了。

Lex Fridman：很多人无法离开 Windows 或 macOS，是因为依赖 Premiere、Photoshop 等少数几个软件。Agent 会改变这种局面吗？

DHH：完全可能。过去关于 Microsoft Office 有个玩笑，每个人都只使用其中 5% 的功能，只不过大家用的是不同的 5%。那么，为什么不各自做出自己需要的 5%？

完整重写 Office 是一个巨大的项目，只实现某类用户真正需要的 5%，却是完全不同的任务，今天的 Agent 已经很擅长完成它。

我以前主要写 Ruby，必要时碰一点 Bash。最近两个月，我却做了 C++ 和 Rust 应用。

我在 Mac 上很喜欢 iA Writer，换到 Linux 后使用 Typora。Typora 很好，但里面大量功能我并不需要。大约六七周前，我突然想到，我只需要 Typora 的 5%。

我告诉 Agent，用 C++ 和 Qt 做一个符合 Omarchy Quattro 风格的写作工具。大约 20 分钟后，第一版就出来了。我一边使用，一边告诉它哪里不对。两天后，我彻底放弃 Typora，之后的文章都写在 Omawrite 里。

我刻意不查看任何一行 C++ 代码，把它当成一个黑盒实验。假设我只是一个对数字打字机有明确意见的作家，我是否也能做出自己想要的软件？答案是可以。

熟悉视频剪辑的人，知道 Adobe Premiere 哪里难用，却过去没有能力改进它。现在，他们可以先为自己做出一个版本。它未必覆盖原产品的全部功能，但可能更准确地解决一类用户的问题。

Lex Fridman：AI 已经可以大幅提高开发效率，为什么 Photoshop、Premiere 等成熟软件的更新速度还没有明显加快？

DHH：原因有很多。最关键的一点是，一旦涉及到人类的团队协作，瓶颈通常不是实现，是人的带宽和沟通。

一个产品经理、几个设计师，上面还有 VP 和 CTO。每个人都要参与塑造产品的过程，也要证明自己为什么存在，生产力就消耗在这里。

我开发 Omarchy 得到的最大启示是，如果真想获得 10 倍、100 倍，极少数情况下甚至 1000 倍的提升，人必须直接与 Agent 互动，中间不能再隔着另一个人，否则带宽太低。

当一家公司仍然有三层审批、复杂的管理机制和多人协作流程时，代码实现只是其中很小的一部分。我们不应该把 Agent 的理论能力，直接等同于整个组织可以获得的效率提升。

还有一个更根本的问题，大多数组织并不知道自己想要什么，也不知道怎样把产品变得更好。它们受到限制的不是实现能力，是想法、愿景和品味。如果好想法的数量没有超过实现能力，让更多糟糕的想法更快变成现实，并不会产生更好的软件。

大型科技公司过去几十年已经拥有数以万计的程序员，这足以证明，单纯增加代码产能不会自动产生优秀产品。

Lex Fridman：所以正确的做法是从头开始？通过开源或创建新公司，而不是在大公司内部加速进入 Agent 时代？

DHH：这就是经典的创新者困境。这些公司已经发展得如此成熟，如此根深蒂固，以至于它们的整个结构、管理层级和流程都适应于一个已经过时的时代。但你无法改变它们。它们就像超级油轮，根本无法转型。这就是为什么科技行业最终会如此动荡不安。

有段时间我对 Apple 和 Google 在移动端的双寡头垄断很不满，因为我看不到打破它的路径。但游戏变了，移动端不再是最重要的计算平台了。各种新的形态都在出现，包括眼镜、耳机等等。

计算平台本身也在经历 40 年来的首次洗牌。Linux 从 1991 年就有了，在桌面端从没起飞过，但在其他所有地方都占据了统治地位。你桌上的设备、冰箱、烤箱，全都跑 Linux，除了你的电脑。现在有了突破口，如果有一款软件把你绑在 Windows 上，你完全有能力自己重写它。

Omarchy 能获得关注，也因为它没有试图成为廉价版 Windows 或 macOS。Omakub 更熟悉、更接近传统桌面，影响始终有限。Omarchy 使用平铺式窗口管理，提出了另一种计算机应该怎样工作的愿景，反而从一开始就获得了更强的吸引力。

04同时开 16 个 Agent 线程，人类负责判断

Lex Fridman：13 个月前，我们坐在这里讨论编程。当时你对 AI 在编程中的作用还有些怀疑，之后我们经历了 Agentic Engineering 的快速演变。你对 AI 在编程中角色的看法发生了什么变化？是兴奋还是害怕？

DHH：我无比兴奋，没有任何存在性威胁的感觉。那种威胁对我来说只停留在理智层面，而在情感层面，是百分之百纯粹的、不掺水的喜悦和乐观，以及对我们让计算机做到这些事情的惊叹。

13 个月前的那次对话，像发生在另一个宇宙、另一个时代。有人说，「有些几十年里什么都没有发生，有时几周内就发生了几十年的变化。」过去九个月，我们就看到了几十年的进步。

我的基本判断其实没有变。去年，我不喜欢的是当时提供给我们的 AI 形态，自动补全和聊天机器人。聊天机器人可以是很好的老师，也能帮助查找资料，但它不会取代我亲手雕琢代码。它只是提高了原有工作方式的效率，并没有改变我和计算机之间的关系。

在第一个阶段，我仍然需要坐在驾驶位上。我告诉 Agent 想做什么、去哪里找答案，在它偏离时把它拉回来，并审查最终结果。它让我快了很多，但我仍然是驾驶员。

真正的分界线是 2025 年 11 月 24 日，Opus 4.5 发布。我过了两天才试，给了它几个任务，然后发现，它输出的代码和我自己会写的已经非常接近。我向后一靠，心里只有一个问题：刚刚发生了什么？

几个月前还是糟糕的自动补全，几个月后，它已经能操作计算机、调用工具、检查自己的工作，并真正完成有意义的任务。它不只能够解决问题，采取的路径也基本符合我的判断，写出的 Ruby 代码甚至是我愿意合并的。

今年春天，Harness 开始支持子 Agent。一个任务可以被拆开，交给八个 Agent 并行完成，耗时降到原来的五分之一甚至十分之一。

而到了夏天，随着 Opus 5、Fable、GPT Sol，以及一些开放权重模型发布，我们终于进入了第三个阶段。在这个新时代，我不再需要告诉 Agent 应该去哪里，也不再规定它走哪条路。我只需要描述一个问题，或者一个模糊的想法，它会告诉我目标是什么、应该怎样到达那里。

我当然还会看，因为我喜欢计算机，也对过程好奇。但严格来说，在选择路径并产出代码这部分，人已经变成了可选项。

Lex Fridman：你现在具体怎样和 Agent 一起工作？

DHH：最大的变化，是从人脑里的单线程开发转向并行处理。

过去，我在 TextMate 或 Neovim 里亲手写代码，一次专注于一个问题。Agent 却同时显得太快和太慢，每个任务都要运行一段时间。如果只启动一个 Agent，人只能坐在那里等。

因此，我开始并行运行多个 Agent。最初用 tmux 打开不同窗格，后来换成带 Agent 通知的 Herdr。再后来，一台机器也不够了。我把几台闲置的迷你电脑接起来，通过 Tailscale 访问不同办公室里的设备。目前，我大约可以同时维持 16 条开发线程。

这时，人的工作变成了持续作出判断。解除某个 Agent 的阻塞，决定下一步方向，检查另一个 Agent 的结果，再启动新的任务。

我通常还会让一个模型执行，再用另一个不同来源的模型审查。比如由 Opus 或 Fable 完成工作，最后固定让 Codex 审查。与其寻找一个绝对正确的模型，不如把相互独立的检查写进工作流。

我们也在 Basecamp 中尝试把 Agent 当作同事，直接给它分配 To-do 和卡片。为异步协作设计的工具，可能比聊天框更适合 Agent。聊天会诱使人坐在那里等待，把任务交给一位「同事」，你天然不会期待立刻收到回复。

05手写代码没必要了，程序员更需要产品经理的能力

Lex Fridman：你曾经花很多时间讨论如何雕琢漂亮的 Ruby 代码，现在却不再亲手写了。你不难过吗？

DHH：我仍然在意漂亮的代码，尤其在修改 37signals 的 Ruby 系统时，我会仔细看实现细节。但我也越来越清楚，这件事的经济回报正在迅速下降。

过去 25 年，我之所以审慎对待每一行代码，是因为清晰、简单、一致的架构更容易被人理解和修改。小团队因此能够低成本地持续迭代，也不容易因为一处变化引入大量 Bug。这个经济逻辑建立在人类负责后续修改的前提上。

今天，漂亮的架构仍然有价值。因为 Token 依然有限，Agent 处理结构清晰的系统，不必每次重新理解全部 Context，后续改动的成本也更低。如果连续把多个质量平庸的改动叠在一起，代码库同样会变成一团泥。

但这只是当前阶段。未来 Token 更充足、模型更强之后，过去建立的很多经验可能不再拥有相同价值。

手写代码不会消失，就像今天仍然有人给 Game Boy 或 Commodore 64 写新游戏，也有人喜欢骑马。但人们这样做，是因为享受限制和过程，而不是因为它仍然是最高效的交通方式。

我很庆幸，自己经历了 20 多年手写代码具有经济价值的时代。现在，我也想看看新的东西。

Lex Fridman：如果代码主要由 Agent 产出，程序员还剩下什么价值？

DHH：软件正在变成产品管理。很多程序员并不是好的产品经理，现在软件开发需要的恰恰是这些能力。它应该做什么、为谁而做、以什么方式实现、优先级是什么、第一版包括什么，这些才是需要回答的问题。

如果你热爱编程的唯一原因，仅仅是机械地将正确的逻辑结构组合起来，完成别人让你完成的工作，那么我认为你很难适应新的现实。因为这种机械化的过程正受到威胁。但如果你真正喜欢的是创造东西，我不认为你面临同样的威胁。

软件变得更便宜之后，人们也可能需要更多软件。最终是岗位增加还是减少，现在还没有确定答案。在一些任务固定的公司里，原本十个人的工作也确实可能只需要一个人完成。

我的建议是，不要试图预测两次模型迭代之后会怎样，那只会把人逼疯。行业里最聪明的人也不知道两年后会发生什么。关注现在，看看最先进的工具已经能做到什么，然后真正去做一个东西。

如果你过去一年都在徒步，现在才回来，两周也足够追上前沿。很多短暂流行的循环、图和 Harness 已经被快速实验筛掉，你不需要重走所有弯路。

未来无论你是否喜欢都会到来。与其花两年抱怨行业变了，不如重新理解今天的世界怎样运转，再去创造更多东西。

06与 Agent 协作，人给的指令可能越少越好

Lex Fridman：程序员和非程序员使用 Agent，得到的结果应该还是不同的吧？程序员懂循环、函数和软件工程原则，能够更系统地描述目标和验证方式。

DHH：在一段时间里，懂得太多编程知识对我反而是一种负担。

最初，我会按照自己的经验规定 Agent 应该怎么做，而它也很擅长照办。那时看起来非常高效。但很快，Agent 已经能够根据结果和问题，找到比程序员预先指定的路线更好的解法。

Lex Fridman：但好的程序员仍然擅长系统设计和严谨思考。即使通过自然语言控制 Agent，也要清楚说明目标、验证方式和安全测试。

DHH：六个月前，我会和你说完全相同的话。但最近的经验让我意识到，很多时候需要有足够的谦逊，承认 Agent 更清楚该怎么做。

AGENTS.md 和 CLAUDE.md 就是一个很好的例子。曾经大家热衷于微调这些文件，给 Agent 写很长的指令。但 Opus 5 的系统提示词据说缩短了 80%，因为模型不仅不再需要那么多人类指令，过度规定还会损害它的表现。

任何遇到过外行老板指挥自己怎么写代码的程序员，都应该理解这种感觉。如果老板不了解具体情况，却强制你采用违背判断的方案，你通常只会写出更差的代码。Agent 也一样。

Lex Fridman：那么，人应该提供多少信息？

DHH：尽可能模糊地开始，先让某个东西出现，然后与它互动。

敏捷开发最重要的洞见，就是人们无法在开始前准确知道自己想要什么。过去几十年，我们试图先把软件完整定义出来，写成详尽的规格，再交给程序员实现。结果很少有人满意，因为只有真正拿到软件、开始使用时，你才会知道自己要什么。

Agent 让这种方式变得非常便宜。先做出一点软件，亲自试用，再决定哪里重要、哪里不重要。你不需要第一次就说清楚所有事情。

Lex Fridman：我会让 Agent 给出几种完全不同的设计和实现，再做一个页面，自己投票选择喜欢的版本。

DHH：对，这正是人类擅长的事情，差异化评估。

给人三个方案，他通常一眼就能选出喜欢的那个。给他 22 个，反而会被选择压垮。很多判断先来自直觉，随后大脑才替它寻找理由。如果你愿意放开一些理性的前期加工，让直觉来驱动，Agent 时代将会让你大开眼界。

07Agent 的想法，可能比人提出的更好

Lex Fridman：当每个人都能用 Agent 为自己开发工具，怎样从只服务一个人的产品，走向更多用户？

DHH：比你想象得简单。为自己做完工具之后，直接让 Agent 把它放到 GitHub。它会创建代码仓库、写 README、管理 Release，甚至比大多数人更耐心地处理开源维护中的琐事。

今天，一些开源维护者抱怨 Agent 带来了大量 Pull Request。我完全不理解这种抱怨。你可以接受，也可以拒绝。开源一直承诺所有人都能够贡献，但过去真正能参与的只是少数技术高手。

现在，程序员这个曾经横在人和计算机之间的「神职人员」阶层正在被绕过，有点像一次宗教改革。更多人可以直接把自己的想法变成代码，再贡献给公共项目。

Lex Fridman：难道不需要这些技术大牛来维持代码质量吗？

DHH：当然需要。我维护开源项目已经 25 年了，看过成千上万名程序员的工作。很多人不会在 Bug 报告里提供足够的信息，不解释 Pull Request 背后的原因，不写必要的注释，不检查工作，也不补单元测试。

但是你知道谁会做所有这些事吗？那就是 Agent。只要提出要求，Agent 大多数时候都会非常认真地执行你的指令，有时甚至到了吹毛求疵的地步。

这实际上意味着，如果你把一个普通程序员和他们提交的 pull request 放到一个普通的开源项目中，他们已经被 Agent 远远甩在后面了。

过去三个月，Omarchy 合并了超过 1000 个 Pull Request。其中很多来自非传统程序员，或者来自不熟悉 Linux 发行版开发的程序员。Agent 让他们能够贡献好想法，我再从中挑选最有价值的部分。

目前项目里还有大约 400 个尚未合并的 Pull Request，我已经不再逐一审查。Agent 会先过滤错误、重复和低质量的内容，在虚拟机里验证 Bug 修复，再把真正需要人作决定的部分交给我。

开源项目管理的所有苦差事都在以闪电般的速度消失，留给我们的是软件开发中最精华的部分：这个项目应该做什么，下一步应该往哪走。

Lex Fridman：你觉得最终好的想法、想法的核心，还是起源于人脑吗？还是说可以全部由 Agent 完成？

DHH：在 Agent 的第一阶段，我确实认为所有想法都来自人类，人类告诉 Agent 去做什么。但我现在完全不这么认为了，我见过从模型中涌出的好想法，好到让我这个以好想法自居的人都感到谦卑。

那些仍然停留在「Agent 只是鹦鹉、只是复述已有想法」这种分析的人，对过去六到九个月的进步是完全脱节的。

转载原创文章请添加微信：founderparker

FounderParkAIAGI