DHH's new way of writing code¶
📝 摘要¶
DHH从反对AI编码工具到全面拥抱AI，认为当前AI代理能显著提升资深开发者的效率（5-10倍），但初级程序员因缺乏验证能力而角色脆弱。他强调品味、判断力和手艺在AI时代更为重要。他正在构建Omachi Linux发行版，注入个人风格，在拥挤市场中找到空间。Ruby on Rails因代币效率和代码可读性，非常适合AI代理工作流，正经历复兴。DHH认为对电脑的热爱不会消退，反而因AI工具而更旺盛。
关键要点¶
- DHH对AI编码工具的180度态度转变：从抨击到全面AI优先。
- AI代理使资深开发者效率暴增，但初级开发者面临被淘汰风险。
- Ruby on Rails的复兴：代币高效且人类可读，适合与AI协作。
- Omachi Linux：在7000种发行版中通过降低门槛和美学设计成功。
- 品味与手艺成AI时代核心竞争力：高级工程师需能验证和引导AI输出。
🎙 中文翻译¶
[00:00:00 → 00:00:44] A Ruby on Rails 的创造者是如何借助 AI 代理改变软件构建方式的？David Heinemeier Hansson，通常被称为 DHH，是 Ruby on Rails 和 Omachi 的创造者，也是 37 Signals 的联合创始人。六个月前，他在 Lex Fridman 的播客上抨击了 AI 编码工具的能力。然后在寒假期间的几周内，他来了个 180 度大转弯，全面转向 AI 优先。在今天的对话中，我们将探讨 David 和他的团队在 37 Signals 如今如何构建软件，AI 工具如何让他们比以往任何时候都更有野心，为什么 Ruby on Rails 可能会比现在更受欢迎——因为它非常适合与 AI 代理协作，为什么品味和精美的软件变得更重要，为什么关心工艺的杰出设计师和工程师可能会更受欢迎，以及更多内容。
[00:00:44 → 00:01:08] A 如果你想知道科技行业最有经验的构建者之一如何看待 AI 工具的实际效用，以及这些工具可能如何影响关心工艺的软件工程师，那么这一集就是为你准备的。本集由 Statsig 赞助，这是一个集成了标志、分析、实验等功能的统一平台。查看节目笔记，了解更多关于他们以及其他赞助商 Sonar 和 WorkOS 的信息。David，很高兴你来到这里。谢谢邀请。
[00:01:08 → 00:01:16] B 我应该说，谢谢你来。你在哥本哈根。这是我目前最喜欢的城市。这是个美丽的城市，有很多优点。
[00:01:16 → 00:01:35] B 那么你最近在忙什么？我总是在捣鼓东西。我在互联网上已经捣鼓了整整三十年，大概从 1994 年开始，第一次接触它，然后就再没停过。过去六个月，我一直在构建各种东西。
[00:01:35 → 00:01:59] B 其中之一是一个名为 Omachi 的新 Linux 发行版。我大概在两年前换到了 Linux。先在 Ubuntu 上玩了一段时间，挺有趣，然后意识到我想从零开始构建自己的系统，以 Arch 和 Hyperland 为基础。所以在 Omachi 上花了很多时间。它最初是作为暑假项目开始的，我在 24 小时勒芒赛间歇期间启动的。
[00:01:59 → 00:02:33] B 那一周有很多空档时间。我就开始鼓捣它，之后项目迅速起飞。看到即使在 Linux 发行版这样拥挤的市场里——大约有 7000 种不同的发行版，有些历史悠久，很多在某种程度上还是有点相似——仍然有新东西的空间，这真是一次鼓舞人心的经历。这也提醒我们，世界上所有的想法可能都被用过了，但没关系，因为你的独特版本还没出现。
[00:02:33 → 00:03:00] B 我把自己的风格注入 Linux，构建了 Omachi，为自己打造了完美的计算机系统，然后看到了和我之前每一次构建真正击中我内心的东西时一样的情景。还有成千上万像我一样的人，或者和我的喜好足够接近，他们从中找到了同样的乐趣和喜悦。无论是 Ruby on Rails、Kamal 走出云端，还是其他任何东西，都是同样的模式。
[00:03:01 → 00:03:08] A 是的。对于 Rails，你真的是在挠自己的痒处。你只是构建自己的组件，然后开源它们。就是这样开始的吗？
[00:03:08 → 00:03:37] B 基本上，我在 2000 年代初开始接触 Ruby，并在 2003 年真正用它测试——那时我们开始构建 Basecamp，而且我没有被命令用什么来构建它。在那之前，我做过很多客户项目，他们会说，我们用 PHP 构建这个，因为我们有人懂这个。所以你必须用这个。然后我们在构建自己的系统，构建 Basecamp，我可以自由选择。
[00:03:37 → 00:04:00] B 所以我选了 Ruby。当时 Ruby 在 Web 应用程序方面几乎没有工具，或者很少。所以我得自己构建所有的东西，这就变成了 Ruby on Rails，它到现在依然强劲。我仍然深度参与其中。我觉得在某些方面，Ruby on Rails 正在经历一场复兴，因为它是构建 Web 应用最高效、最节省代币的方式之一。
[00:04:00 → 00:04:21] B 它非常适合我们目前面对的代理工作流。不知道这种情况能持续多久。也许五分钟内，所有代理都会开始写机器码或汇编语言。所以可能那种情况会结束。但就目前而言，代币效率仍然重要，代理生成的代码是否人类能读懂并验证，这也很重要。
[00:04:21 → 00:05:05] B 那也可能在某天结束。但就现在而言，看到这些我挠自己痒处的项目能引起更大社区人群的共鸣，然后他们出现并愿意帮忙，这真是一段有趣的旅程。拿 Omachi 来说，它才存在了大概六个月多一点，现在我们已经有大约 400 位贡献者对发行版做了代码修改。除此之外，还有数万人安装并把它作为日常系统使用。所以我总是喜欢发现像 Ruby 这样新颖、令人振奋的新东西——或者说，谈论一个从 1991 年就存在的操作系统的发现，听起来有点奇怪。
[00:05:05 → 00:05:35] B 但对很多人来说，Linux 现在就是那个发现，因为他们之前没有在自己的个人电脑上用过它。所以他们第一次看见它。我帮助一批新的 Linux 用户，希望甚至是爱好者出现，因为我稍微降低了门槛。我让开始变得更容易，让默认安装看起来就很棒，这样他们就不必花一百个小时调整系统才能上手。
[00:05:36 → 00:06:02] B 这真的很有趣。当然，同样有趣的是，这两件事——Ruby on Rails 和 Omachi——都不只是爱好项目。我喜欢爱好产品，也总会做这类东西，但我也喜欢把它们应用到商业上。所以在 37 Signals，我们基于 Ruby on Rails 构建了整个业务，持续了二十多年。现在大多数开发者的机器上都在跑 Linux，因为我们有自己的发行版了。
[00:06:02 → 00:06:04] A 所以 Omachi 跑在所有的 Omachi 上？
[00:06:04 → 00:06:04] B 我是说，
[00:06:04 → 00:06:06] A 人们可以选择，对吧？
[00:06:06 → 00:06:18] B 他们能吗？嗯，有点吧。我们一开始是开放选择的。但到某个时候，就不再合理了。就像，如果有人在 37 Signals 说，我想用 Django 写这个，我们要用 Python 和另一个框架，即使你有 Ruby on Rails 并且正在用它，那也不合理。所以我们从早期的邀请尝试转变过来。那是在我第一次换到 Linux 时，我就说，嘿，如果你想试试，就来试试。当 Omachi 变得更严肃时，我就说，我们全力投入吧。
[00:06:18 → 00:06:36] B 对于技术方面的人，当然不是 iOS 开发者，而是任何做网页、用 Ruby、做 DevOps 的人，他们应该用 Linux，因为首先，这更接近我们部署的环境。我们一直部署在 Linux 上。从第一天起，对于开发者和系统运维人员，我们在服务器端就是 Linux 商店。我实际上认为，更接近生产环境、更熟悉工具是一个实实在在的优势。然后在此基础上，我们当然在构建这个发行版，我们应该有尽可能多的人来帮忙。
[00:06:36 → 00:07:11] B
[00:07:11 → 00:07:17] B 作为这家公司的CTO，我来定技术方向，而且这就是我们要走的路。你能不能简短回顾一下你是怎么成长的？现在整体业务处在什么位置？你一直在开发、发布新的、令人兴奋又酷的东西，我记得Fizzy是最新的一个。
[00:07:17 → 00:07:31] A 好的。30秒信号公司1999年成立，最初是一家网页设计公司。我2001年加入，比它晚两年，之后和杰森合作做咨询项目做了几年。2003年我们开始做Basecamp，2004年发布。
[00:07:31 → 00:07:52] B 有意思的是，发布日期正好跟Facebook上线差一天左右，算是个巧合吧，我们属于同一时期、同一批创业者。大概一年后，我们发现这东西火了，就全职投入，从咨询公司转型成软件公司。
[00:07:52 → 00:08:19] B 到现在已经二十二年多了。这期间我们发布了好多产品。Basecamp是第一个，现在也还是最大、最重要的产品。这其实挺有意思的——人们有时候会幻想，自己学得越多、经验越丰富，想法就越聪明、越好。但事实并非如此。很多人的第一个想法就是最好的想法。我不觉得羞耻，Basecamp客观来说是我们有史以来最棒的商业创意。能让它持续发展、成长二十年以上，我非常自豪。很少有软件公司，更别说一个软件产品，能有这么长的寿命和传承。
[00:08:19 → 00:09:01] B 但这几年我们也尝试了很多东西，也取得了其他一些成功。2020年我们推出了邮件服务Hey.com，现在想想，那真是一个疯狂的任务。
[00:09:01 → 00:09:19] B 没错。
[00:09:19 → 00:09:19] A 这个领域完全被谷歌的Gmail垄断了，那是个不错的产品。
[00:09:19 → 00:09:57] B 它十七年没什么大变化，但很稳定，很多人也完全满意。他们脑子里存在一种矛盾：一边讨厌电子邮件，一边却不觉得这和用Gmail有关——我觉得这很奇怪。但不管怎样，我们推出了一款产品，它不仅挑战这个根深蒂固的对手，而且Gmail的市场份额恐怕比我能想到的任何主流品类里的任何产品都要高。在美国，Gmail大概占了85%的邮件流量——听起来有点离谱。
[00:09:57 → 00:10:17] B 也许80%吧。总之极高。基本就是Gmail，其他所有邮箱都挤在图表里一小块地方。所以我们在推出Hey之前……我用了Gmail很多年，我不知道什么时候注册的。刚用几周就拿到了一个邀请码——当时那个发布策略挺聪明的——然后就一直用到现在。
[00:10:17 → 00:10:49] B 所以差不多用了十七年Gmail吧。这段时间里我对很多不满意的地方积累了很多想法。我们把这些想法全部融进新软件产品里，花了几乎两年开发，投入了数百万美元的研发资金，然后在2020年夏天发布。顺便提一句，选发布时间的话，2020年由于各种原因可不太妙。我们当时就想找一周全世界别那么疯。
[00:10:49 → 00:10:56] B 疯？没错。我们最终选了那一周上线，然后就跟苹果打了一场硬仗。
[00:10:56 → 00:10:57] A 跟苹果打，我记得这事。
[00:10:58 → 00:10:58] B 最终……
[00:10:59 → 00:11:00] A 他们就是不想批准你的应用，对吧？
[00:11:00 → 00:11:18] B 他们不想批准，除非我们交30%的“过路费”。他们基本等于说：你不能上App Store。对于Hey这样的邮件产品，这等于判死刑。没错，你不仅需要支持手机，而且必须支持iPhone。今天依然如此。我们的付费用户里大部分是iPhone用户，因为那是美国最大、最富裕的市场，而美国又是全球最富裕的软件市场。所以这个业务要想成功，必须上iPhone。经过两周来回激烈的斗争，幸好时间点刚好赶上WWDC，苹果不想在大会上摆出碾压小开发者的形象。
[00:11:18 → 00:11:48] B 小开发者。
[00:11:48 → 00:11:48] A 最后我们被允许上架了，苹果事后还改了规则来适应我们。这只是一个小胜利，不是最终的……
[00:11:48 → 00:12:00] B 胜利，但至少……
[00:12:00 → 00:12:00] A 至少让我们能进去了。Hey最后大获成功。讽刺的是，苹果反而给了我们两周铺天盖地的报道。现在回想起来，我觉得当时不会赌那么大，因为可能结果为零。对吧？比如苹果拒绝我们的应用，我们只注册200人，应用就死了。
[00:12:00 → 00:12:23] B
[00:12:23 → 00:12:48] B
[00:12:48 → 00:13:17] B 而我的第二常用的应用就是HEY，很多时候甚至是最常用的，因为我几乎所有事情都在邮件里搞定。我得不停地跟人沟通、写东西、处理各种事情——很多人都这样。而这个邮件体验如果变得愉悦、环境舒适，收件箱能比Gmail更受尊重（在Gmail里，全世界的陌生人都能让你口袋嗡嗡响，只要你开着通知——而默认就是开着的），对我来说这简直太疯狂了。
[00:13:17 → 00:13:29] B 对吧？任何人都能直接接触到我们每日最重要的优先事项清单——随便谁都能往上面加东西，太疯狂了。总之，HEY不会这样。我们有筛信器。
[00:13:29 → 00:13:39] B 除非你明确说“我想收到这个人的来信”，否则没人能直接进入收件箱。大多数情况下我对大多数人都是拒绝的，对吧？所以东西都进了筛信器。我们有点赞——我会听这个人的消息。
[00:13:39 → 00:13:42] B 点踩——我再也不想听到这个人的消息。
[00:13:42 → 00:13:51] A 我就是这样联系你的。我不确定我们在X上有没有互相关注，但我用了邮件，因为你的邮箱是公开的。而且你的筛信器似乎起作用了——它给了我一个赞。
[00:13:51 → 00:14:21] B 确实起作用了，因为筛信器就是我本人。甚至没有AI来判断我是否想听你的消息。事实是，每天花一次时间过筛信器，点个赞或踩，其实并不麻烦，因为世界上没那么多人。如果你对那些烦人的销售说“不”——他们在Gmail里能七次轰炸你的收件箱——那么工作量就小多了。而且我觉得这还挺令人满足的。
[00:14:21 → 00:14:31] B 因为我以前用Gmail的时候，经常被那些销售手段套路——他们当然依赖这个——就是你回信说“不，谢谢，我不感兴趣”，然后他们就不再回复了。对。
[00:14:31 → 00:14:41] B 然后你会想：等等，我是不是有义务回复这个人？我觉得好像是，偶尔就写了。就算我不写，他们还是能进我的收件箱，所以我又会收到他们的消息。
[00:14:41 → 00:14:47] B 下周他们就开始一整套邮件滴灌营销。他们都这么干。对吧？任何一次联系都是七封邮件，不是一封。
[00:14:47 → 00:15:02] B 七封邮件。你要是表现出一点活的迹象，可能就变成52封。这根本不是正常交往方式。而HEY，我说，点一次踩，就再也听不到那个人了。你简直神奇地能快速清除杂草，管理好自己的花园，然后突然就只剩下美丽的花朵了。
[00:15:02 → 00:15:14] B 突然之间，邮件不再是苦差事。你开始想去闻玫瑰花香。你收件箱里大部分东西都是你愿意读的，来自你愿意联系的人。这就是我们做HEY的基本使命。
[00:15:15 → 00:15:40] B 我们能让邮件再次可爱吗？那么多人都讨厌邮件，因为系统太糟糕了，因为它们建立在最初的前提上：邮件只是大学里科学家用来互相交流的工具。科学家非常有礼貌，不会因为要推销某个愚蠢的应用就烦你52次。不会，他们很尊重人，很美好。对吧？
[00:15:40 → 00:16:06] B 多么美好的理想、理念和协议设计，针对那种规范、那种人。然后你把它放到广大的世界中，才发现并非所有人都具备那样的规范与礼貌，尤其是在销售人员参与进来之后。所以你需要更好的防御。对于我、对于我们、对于我们众多客户来说，HEY就是那种防御。它是一种重新爱上邮件的方式。我觉得实际上有一个宏大的“为什么”非常重要。
[00:16:07 → 00:16:33] B 这要追溯到维克多·弗兰克尔，《活出生命的意义》。找到“为什么”能让你在寒冷、不适、烦人的雪中前行——用电脑构建东西时，很多事情都是如此，它们可以被称作不舒服和烦人。大多数时候不应该是这样，
[00:16:33 → 00:16:48] B
[00:16:48 → 00:17:10] A
[00:17:10 → 00:17:31] A
[00:17:31 → 00:17:51] A
[00:17:51 → 00:18:07] A
[00:18:07 → 00:18:24] B
[00:18:24 → 00:18:31] B 比Nomad Lane还慢。所以我能理解，因为我也有同样的直觉。我觉得这就是我们作为开发者的傲慢——我们认为……
[00:18:31 → 00:18:31] A 确实，对吧？
[00:18:31 → 00:18:43] B 我们就是神，可以瞬间搞定一切，而且你确实能做到。如今你可以在比周末更短的时间内做出原型。对吧？比如，只需几个小时，我们就能弄出一个……
[00:18:43 → 00:18:44] A 启动一个AI代理。没错。
[00:18:44 → 00:19:19] B 但弄清楚你真正想构建的东西需要更长时间。而做出值得发布的东西还需要更长时间。至少对我们来说是这样，我认为对任何做出好东西的人来说也是如此。最初的HEY项目，技术上只有我一个人。实际上，我们大多数主要产品的起步方式都是：要么只有我，有时再加一个开发者，但一直保持极小团队，直到我们有了形态、架构和产品方向。
[00:19:19 → 00:19:40] B 我发现，如果方向不确定，投入大量人力反而会更慢。如果你不知道自己想要什么，一百万个人也帮不了你。你必须自己想明白。我们可以稍后讨论这一点，但正是AI最近取得的进展在彻底改变局面——现在弄清自己想要什么变得更快了。
[00:19:40 → 00:19:59] B 但对于HEY，一开始只有我。然后是Jason，一两个设计师，非常非常小的团队，试图摸索出形态。如果你要挑战Gmail，你不能只做一个蓝色版的Gmail——没人会买账，没人会感兴趣。
[00:19:59 → 00:20:39] B 它必须新颖，而且不仅仅是新颖——还必须优秀。它必须解决人们甚至没有明确说出来的对Gmail的不满，因为人们表达对Gmail的抱怨时只会说“我讨厌邮件”，正如我们讨论过的，这有点误导。我认为你讨厌的是Gmail，不仅仅是Gmail，而是大多数基于旧模式的邮件系统——任何人都能访问你的收件箱等等。但要弄清楚这些、摸索出形态需要时间，而且当你慢慢琢磨、没有无限资源的时候，这个过程也很有趣。最初的Basecamp也是以同样的方式构建的。
[00:20:39 → 00:20:41] B 技术上也只有我一个人。
[00:20:41 → 00:20:44] A 这是ShapeUp本体论吗？有ShapeUp……
[00:20:44 → 00:21:07] B ……思想，试图赋予设计师意图：它应该怎么工作，而不仅仅是它应该怎么看起来。当然也要弄清楚它看起来应该是什么样——产品应该美观、独特、有吸引力等等。这也需要时间。但首要的是弄清楚它应该如何工作，找到核心在哪里，最重要的部分是什么，然后把这些拆解开。
[00:21:07 → 00:21:32] B 但对于HEY，以及我们所有的主要产品，我们都是从极小的团队开始的——通常编程方面只有一个人，设计方面一两个人。然后我们不断推进，突然某个瞬间灵光一现，我们会觉得“这个不错，有戏”。然后略微加速，增加几个人手，当项目进展到最后20%左右时……
[00:21:32 → 00:22:06] A ……我们会说，“好了，现在我们知道地形了。如果所有人都投入进来，我们可以快得多。”所以有一件事非常有趣，你可能会觉得理所当然，但这与大多数融资的初创公司（我非常熟悉）以及大公司（如Uber、Facebook等）的做法截然不同。那些项目的启动方式是：一个产品经理，可能配合半个设计师，做出一个规格文档，然后开发人员后来才介入。而我听到的、对我来说非常新颖的做法是，你只用到一两个设计师和一个开发者。
[00:22:06 → 00:22:20] A 那么你是如何看待设计师的呢？你最近雇佣了一位名叫佐尔坦的设计师，其实我私下和他聊过，是个很棒的人。但我感觉你对设计师的看法可能和行业里其他人不太一样？
[00:22:20 → 00:22:37] B 确实如此。37signals的设计师不只是让规格文档看起来漂亮——他们负责确定规格应该是怎样的。在很多方面，他们就是产品经理。在很多情况下，他们是“怎么做”和“为什么做”的发现者。
[00:22:37 → 00:22:59] B 他们通过客户反馈（有些情况下）或纯粹直觉（其他情况下）进行推导，并提炼出应该构建什么以及它应该如何工作。除此之外，他们还负责
[00:22:59 → 00:23:47] B
[00:23:47 → 00:24:14] B
[00:24:15 → 00:24:56] B
[00:24:56 → 00:25:24] B 有些实现确实很糟糕，但它本质上就是个“打包好的网页”。但失望的是那种感觉的缺失——我觉得这和Mac的情况类似：Mac的原生感已经有点牵强了。比如按钮布局，所有你称之为“原生应用”的东西，要么显得做作，要么显得真实。而今天，一切都是做作的，再也没有真实感了。
[00:25:24 → 00:25:47] B 我认为网页也是如此。如今网页是一个庞大得多的平台，因此它获得了更多关注。所以有更多人在提升它的质量，但在大公司里，那种动态交互几乎绝迹了。我觉得这种情况会有所改变。AI代理加速将赋予设计师在这些方面更强的能力。
[00:25:47 → 00:26:25] B 所以行业正在向我们的基本立场靠拢，这有点讽刺，因为编程领域也是如此。当我谈到Basecamp在发布时编程方面只有我一个人时，很长一段时间这听起来像是不求上进，甚至被认为是错误的，网上有些人甚至指责我在撒谎。他们觉得：是啊，但你不可能做出真正、有意义、大型的东西，除非你有一个更大的团队，否则那只是个玩具产品。对吗？而我从一开始就明白，这当然是胡扯，因为你只是没用过Ruby on Rails。
[00:26:25 → 00:26:40] B 你没用过借助更好工具所能实现的加速。现在我们所有人都意识到了这一点。我们正在明白：哦，如果你使用AI代理加速，单个人确实能构建出东西——那相当于一个庞大的团队。是的。
[00:26:41 → 00:27:01] B 看到行业逐渐意识到“小团队更好”真是有趣，因为现在你从沟通成本的对数曲线中节省的成本开始变得重要。这就是其中一点，也许我们可以聊聊：AI代理加速正在真正改变初级开发者和高级开发者之间的权衡。
[00:27:01 → 00:27:27] A 我们来谈谈这个。但在那之前，我感觉到你非常看重软件工程这门手艺，这很明显。但我还感觉到你同样看重设计、用户体验设计、软件设计——也就是制造让人感觉良好的东西，无论是软件还是硬件。你也把它当作一门手艺来珍视，并一直追求它。我感觉对吗？
[00:27:27 → 00:27:55] B 我认为美学即真理。当某样东西很美时，它很可能是正确的。这在数学上成立，在物理学上成立，在很多不同领域都成立——当你得到具有正确美学特质的东西时，就像我们有直觉引导我们走向那种美，因为它同时也是正确、高尚且值得追求的。
[00:27:55 → 00:28:26] B 我也相信这就是让人幸福的原因。被优美、好用的物品包围是幸福的关键部分。事实上，我也可以从反面来说：焦虑和沮丧的一大来源就是当一切都很烂的时候——界面卡顿、触摸不灵敏、需要重启、打电话给旅行社时他们因为老旧的破系统而什么都做不了。对吧？
[00:28:26 → 00:29:38] B 这个世界充满了各种“烂化”——不仅仅是东西从好变坏，而是直接变烂、变得糟糕透顶。我认为这是文明的一大隐患：如果我们周围有更多美丽的物品、更美的系统——无论是外在的美学品质，还是内在的美学品质——我们实际上可以提升人类的幸福感水平，因为这两者通常是完美和谐的。史蒂夫·乔布斯之所以关心盒子内部，是因为他直觉地知道：那些在意电路板布局的人，也会在意用户界面的细节，会在意开箱的工学设计。所以我基本上认为别无选择。如果你是被这种美学吸引的人——我相信每个人都是，只是意识程度不同——那么你就会想把一切都做得美。
[00:29:38 → 00:30:16] B 对我来说，Ruby特别是一门具有开创意义的语言，因为它能写出最漂亮的代码。在我看来，几乎没有竞争对手。比如，有些东西可以通过某种方式变美——我觉得看Smalltalk的极简风格就很美，但那不是我想住的房子。Ruby才是我愿意住的房子，因为它既有美学品质，又不会在意识形态上僵化，这是非常罕见的特质。更常见的是——现在我们可以再提艾维——当有人如此痴迷时，他们往往有点狭隘。
[00:30:16 → 00:30:32] B 那是代价，是交易。而我觉得Ruby奇迹般地既视野开阔，又在这方面极度专注。但总而言之，我们必须拥有美的东西，必须使用漂亮的工具。
[00:30:32 → 00:30:45] B 我们必须制造优美、流畅的交互。我们应该把自己看作手工艺人，细心打磨，直到没有任何毛刺。
[00:30:45 → 00:31:09] A AI是如何改变你的工作方式的？你认为它如何改变你的手艺？或者我们就谈谈手艺本身——你在37signals招聘那些同样关心设计和软件质量的人。AI如何改变你从手艺中获得的成果？或者在某些方面如何让它变得更好或更糟？我只想先问问你的看法是如何变化的。
[00:31:09 → 00:31:25] A 因为上次你长篇谈论这个话题是在Lex Friedman的播客上，那时你仍然非常合理地对AI持怀疑态度。那是另一套工具，效果没那么好。我觉得你在那里狠狠地抨击了它，但后来情况变了。
[00:31:25 → 00:31:53] B 这是一个微妙的点，也许有点自我辩护，但我实际上不认为我的观点变了。变化的是环境和事实——我当时在那期节目以及其他文章中已经指出：从最开始我就看到我们拥有某种全新且新颖的东西，它将改变一切。ChatGPT三年前发布时，即使在当时，显然也足以在时间线上标记为一个里程碑事件。
[00:31:53 → 00:31:53] A 是啊，你——
[00:31:53 → 00:32:12] B 就像：这是计算机科学或世界历史上所有重要事件。哇，这里有ChatGPT的发布。以这种方式与计算机互动，看到它们推理——即使这个术语仍有争议。但对我来说，这些家伙显然聪明得惊人。
[00:32:12 → 00:32:33] B 很多方面比我聪明。无论这种聪明是来自训练权重和数据关联延迟，还是别的什么。我们不太清楚人类意识如何运作，也不太清楚人类的智慧或智力如何运作，所以别那么绝对地定义意识或智力是什么。
[00:32:33 → 00:32:51] B 至少我觉得这种区分没什么用，尽管想一想是有趣的。但我发现早期的模型和人机交互方式——那种自动补全、Copilot和Cursor在你编辑器里试图猜下一个字符——
[00:32:51 → 00:32:53] A 那会弄得到处都是。对吧？
[00:32:53 → 00:33:01] B 没错，我真的觉得特别恼火。就像我们正试着好好聊个天，你老是不让我把话说完，还一个劲儿地问“你是不是这个意思？”
[00:33:01 → 00:33:22] B “你是不是这个意思？”搞得我很想说：“闭嘴行吗？让我把想法说完行不行？”我觉得就算它偶尔能加速工作，但出错的频率也太高了。这种“加速”反而让人觉得烦人，即便算起来净效果是正面的——反正对我来说不是。也可能是我放弃得太早了，但我就是不喜欢那种体验。
[00:33:22 → 00:33:44] B 我当时觉得模型还不够好。那种用AI自动补全的方式，跟后来智能体工具（agent harnesses）比起来，简直糟糕又烦人。实际上，我一度对行业方向有点悲观——我以为以后大家都要这么干活了：坐在那里不停地按“Tab”。谢谢，不用了。
[00:33:44 → 00:33:49] A 嘿，Cursor他们甚至把那个“Tab键”做成了纪念品，我拿到过一个。
[00:33:49 → 00:33:49] B 没错。
[00:33:49 → 00:33:56] A 那个东西吧……确实很酷，设计很棒，整体都很好看。但是——
[00:33:56 → 00:33:57] B 但有点反乌托邦。
[00:33:57 → 00:33:58] A 反乌托邦。
[00:33:58 → 00:34:28] B 看到它，我就想起以前有个段子：键盘上只需要三个键。对吧？这还让我想起《辛普森一家》那集：Homer放了个机械鸟在键盘上，只能按回车键——因为他一直在按回车。结果核反应堆要爆了，那鸟还是一按回车，整个就烧没了。我当时就想，哇，这对比真有意思。《辛普森一家》果然能预言一切。
[00:34:28 → 00:34:53] B 但我真的不喜欢那种用法。虽然我对整个AI方向一直保持热情——因为确实很神奇。对我来说，我试着把它当成一个教练模型，或者一个不开车的结对编程伙伴。问ChatGPT或者其他模型“这个我不太懂，这里有段代码、有个问题，你能告诉我为什么这样工作吗？哪里有问题？”就非常好用。
[00:34:53 → 00:35:01] B 因为我从第一天开始就是这么用网络的。对吧？对我来说，Google就是这样。
[00:35:01 → 00:35:17] B “这里有报错信息，有个概念。或许我在Stack Overflow上能找到某个被动的书呆子嘲笑别人，然后最下面才是我要的答案。或者干脆找不到，让人抓狂。而用ChatGPT的时候，我经常能得到很好的解释。
[00:35:17 → 00:35:34] A 对。我其实跟一个游戏开发者Jonas Tyroller聊过，他做了一个超棒的热卖游戏，我很喜欢玩。那段时间他也在用Tab自动补全。他说他的做法是：彻底关掉IDE里的所有自动补全，因为他也被烦到了。
[00:35:34 → 00:35:50] A 然后他偶尔会去ChatGPT问问题，或者让它生成一整段东西。他的模式是：自己先思考、自己动手做，遇到问题了就说“这里我需要帮助”，然后给出具体细节，再把结果拿过来。不知道为啥，这样感觉他整天都能保持心流状态，因为是他自己在控制。
[00:35:50 → 00:35:55] A 对。而且这种习惯跟你说的好像一样——那种工具反而剥夺了你的控制权。
[00:35:55 → 00:36:05] B 是的，我当时真有点担心：以后大家都会变成那只鸟吗？我可不想当鸟。然后我就想：那我能做什么呢？也许去种土豆？在丹麦这可是个老传统。说不定我可以搞这个。
[00:36:05 → 00:36:25] B 但谢天谢地，后来发生了两件事。第一，就是那个“plot code”项目——春天启动，夏天慢慢开展，到了秋天，我们找到了一种使用智能体（agents）帮助编程的新方式，就是智能体工具包（agent harnesses）。
[00:36:25 → 00:36:33] B 对吧？这就是从AI向智能体（agents）的真正转变。突然之间，AI拥有了工具——它能用bash、能用终端上的所有东西、能调用网络获取信息。它不仅仅能推理你给它的东西，或者从源文件中输入上下文。
[00:36:33 → 00:37:03] B 然后就是模型本身。对我来说，Opus 4.5是另一个里程碑：它是第一个持续稳定地让它输出质量和分析能力惊艳到我的模型。
[00:37:04 → 00:37:32] B 基于模糊的输入，它的分析质量很高，更重要的是输出质量也很高。它生成的代码我几乎不用修改就能合并。就算我想改，告诉它一次它就能记住，下次不会再犯同样的错误。对我来说，这两件事的结合就是真正的解锁。
[00:37:32 → 00:37:33] A
[00:37:33 → 00:37:51] B 你的标准非常高，真的非常高。我的标准也很高。就像我们刚才聊了很久的那样，输出的美感对我来说至关重要——如果我要看这些代码、要审查它们，那代码必须好看。稍后我还会讲另一个例子，那里面这些都不重要。但当我用代理工具写 Ruby 代码时，我希望它们写的代码和我写得一样漂亮。
[00:37:51 → 00:38:10] B 如果代码写得乱七八糟，我是不会合并的。就像我不会合并没有完全内化我们团队风格的初级开发者的工作一样。所以我希望它们能达到同等水平。早期的模型就是做不到。这并不意味着它们写不出能运行的软件——至少有时候可以。
[00:38:10 → 00:38:24] B 非常震撼。我记得我第一次用AI做蛇形游戏的时候，我简直惊呆了。我从六岁起就想做这件事。一直有这个想法，想把它做成游戏，结果我大概——说不好——三十秒就完成了。
[00:38:24 → 00:38:27] B 游戏就做好了。我把HTML复制粘贴过来。
[00:38:27 → 00:38:28] A 当你第一次做出来的时候... （这是一句不完整的句子，保留其未完成感）
[00:38:28 → 00:38:59] B 太神奇了，对吧？所以我认为这个爬坡过程非常有意思，因为其实我们花了不少时间才找到这种代理工具和终端界面的结合形态。对我来说，真正的突破在于：我觉得这东西有意思，我想跟它对话——我想用它来写代码。现在，我启动任何新项目都会从代理优先开始。这是一个巨大的转变。
[00:38:59 → 00:39:23] B 这个转变就发生在11月27号左右，我记得是Opus 4.5发布的日期。当然，其他人可能有不同的感觉，比如有人觉得是Opus 4o，或者有人提到Sonnet 3.7。还有一些更早的关键节点。但我也确实感受到有一种普遍的共识可以依靠——那种能力和别人所表达出来的——对，大概就是11月底、12月初那个时间点。
[00:39:23 → 00:39:35] A 所有在大厂工作的人，那段时间正好是冬歇期，因为大家都——是的，整个行业都会停摆两周，除了少数需要on-call的地方。但说实话，整个行业几乎没什么生产工作。
[00:39:35 → 00:39:36] B （大家就）玩这个。
[00:39:36 → 00:39:42] A 我的感觉是，大家都在玩这个东西，因为你把自己永远完不成的副业项目丢给它，本来也没指望它能做完，结果大家都被震惊了。
[00:39:42 → 00:39:52] B 对，它做完了。那完全是一个——怎么说呢，就好像电影里的那种声音——比如你听到唱片刮伤的声音，然后你说“等等”。
[00:39:52 → 00:39:53] B 什么？倒回去？什么？
[00:39:53 → 00:40:17] A 我觉得那是一次最大的集体震惊——每个人都独自经历了那种震惊。然后大家一月份回来上班，尤其是很多决策层——CTO、工程总监之类的——他们本来不怎么动手，但这次亲自上手了。奇怪的是，他们回来之后就开始强制要求或者直接说：“你们必须用这个，因为我看到了未来。我真的亲自试过。你们也得试试。”
[00:40:17 → 00:40:27] A 所以我们又回到了类似硬件推广的时代。有人想把新硬件塞到别人手里说：“你必须体验一下，因为——是的，你不会相信的。”这东西确实有这种特点，你真的不敢相信。
[00:40:27 → 00:40:33] A 我们可以聊这个，但没试过、没经历过那个时刻的人，我不认为我们能说服他们。
[00:40:33 → 00:40:48] B 这是另一个“言语无效”的例子。你必须自己坐在OpenCode或者其他工具前面，用上前沿模型——就从Opus开始。我建议从Opus开始。
[00:40:48 → 00:40:48] A 对。
[00:40:48 → 00:41:11] B 它是最好的前沿模型。其他模型在别的地方更好，等等等等。但如果你只是想写一段代码，看看当前的前沿是什么——如果——我是说，如果你的听众里还有人没试过，我会很惊讶。但如果还有这样的漏网之鱼，现在就是时候了。我不想再听到有人说——我觉得X平台上那种“如果你没有内化AI的一切，你就会被淘汰”的论调很令人反感。
[00:41:11 → 00:41:21] B 闭嘴。首先，这完全不是真的。你完全可以在接下来的三周内把一切都补上。这就是这类项目的另一个神奇之处，对吧？或者说这种进步。
[00:41:22 → 00:41:49] B
[00:41:50 → 00:42:26] B 对我来说，Shopify的Toby Lutke是第一个看到这一切的人，他比我早得多地预见到了这些变化。他一直不断地向我推销，说“嘿，你看看这个，看看这个”，真的把我拉进了这个领域。我觉得这其实非常有帮助。身边有一群信念更坚定、或者眼光更长远的人，确实很有好处。我的目光通常比较贴近地面，只盯着眼前的东西。而有些人看得更远，有时候他们看到的东西未必会实现。
[00:42:27 → 00:42:56] B 这次，Toby两年前就准确预见到了我们现在的位置。而我直到去年12月才看到，因为路已经铺到我面前了。有趣的是，一路上我一直在说：“是啊，等模型足够好，等它们能搞定所有事情，那该多棒啊。”但又觉得：“嗯，大概还要18个月、两年，或者五年吧。”这类转折点真的很难预测，我觉得整个行业自己都没预测到，对吧？
[00:42:56 → 00:43:13] B 整个硅谷和旧金山周边地区都在全力推动这件事，但要精确预测曲线什么时候开始指数级增长，非常困难。但转折确实发生了，现在我每天的工作方式完全变了。
[00:43:13 → 00:43:15] A 那你现在每天具体做什么？
[00:43:15 → 00:43:21] B 我现在一切都以AI代理为先。
[00:43:21 → 00:43:49] A 说到以代理为先，正好该提一下我们本季的赞助商Sonar。转向以代理驱动的工作时，代码质量自然就成了关键问题。Sonar，也就是SonarQube的开发商，始终坚信代码质量和代码安全性是内在关联的。高质量的代码天然更具弹性。而随着AI代理开始大规模编写代码，这个验证层就成了你最重要的安全参数。这正是SonarQube Advanced Security这类解决方案的价值所在。
[00:43:49 → 00:44:22] A 有了这种新的恶意包检测功能，Advanced Security提供了一个实时断路器，能自动阻止代理拉取未经验证或有风险的第三方库，避免它们进入你的流水线。影响也是可量化的：根据Sonar的《2026年代码开发者调查报告》，用Sonar验证代码的开发者，因AI导致服务中断的概率降低了44%。这本质上是在缩小AI速度与生产环境安全性之间的差距。Sonar还在做哪些事情来帮助减少宕机、提升安全性、降低与AI和代理编码相关的风险？
[00:44:22 → 00:44:30] A 请访问sonarsource.com/pragmatic了解更多。回到David的代理优先工作流——具体来说，他用的是Claude Code吗？
[00:44:31 → 00:44:31] B 我用OpenCode。
[00:44:31 → 00:44:33] A OpenCode？你用OpenCode？
[00:44:33 → 00:44:49] B 那是我主要用的工具。我也用一点Claude Code。不幸的是，他们率先取得了领先。Opus是目前最好的模型，所以他们开始有点思路固化，觉得游戏是一场单局比赛，而不是多轮博弈，然后我就把订阅从OpenCode撤了。
[00:44:49 → 00:45:05] B 所以如果你想用他们的最佳订阅服务，就得用他们的工具，我不太喜欢这样。我觉得这是个错误，不过先放一边，我们还是要庆祝他们拥有最好的模型。Opus 4.5和4.6也不错，但对我来说，4.5才是转折点。这也带来了很多竞争，因为所有人都想赶上他们。
[00:45:05 → 00:45:08] A 当然，特别是看到Anthropic的收入增长。我记得年初是90亿美元，几周后变成大概140亿，现在又到190亿了。
[00:45:08 → 00:45:17] B 这简直是你能想象到的最疯狂的火箭飞船，激励着大量资本投入到竞争对手身上，这很棒。很高兴看到这一点。所以即使我不喜欢他们做的所有事情，Claude Code也不是我偏好的工具，但还是可以同时容纳两种想法。我对苹果也这样——我严重不满他们的运营方式、守门人角色以及所有我们讨论过的乱七八糟的事。但同时，我仍然戴上“我就是爱计算机”的帽子，说：我喜欢新出的Neo。
[00:45:17 → 00:45:48] B 我甚至可能买一台新的Neo，看看500美元能做出什么来。对于Opus，我毫无芥蒂地使用它。实际上，每当我遇到真正困难的问题，我现在就会用Opus。但我也用其他模型，我融入工作流的一件事是同时运行两个模型，用不同的速度。我用TMUX，在Omachi里内置了一个布局功能：左边启动新的Vim编辑器，右边启动两个面板。
[00:45:49 → 00:46:21] B 上面是运行Kimi K2.5的OpenCode，下面是运行Opus的Claude Code，最底部还有一个终端条。几乎所有事情，我先在一个代理里开始，告诉它我想要什么。然后跳到Neovim，先按空格+g+g查看lazy git的差异。如果改动看起来正确，我就直接提交。好了，搞定。
[00:46:21 → 00:46:50] B 很棒。有时候看起来不对，我就自己进去改代码。但这种比例的变化速度仍然惊人。从去年11月初开始，我变成了“代码优先一切”。嗯。
[00:46:50 → 00:47:04] B 我以前是打开编辑器，花很长时间写代码，遇到卡壳或者想听第二意见时，才去问我的友好Claude。现在不是这样了。现在我以代理开始，它给我草稿，我审查草稿，必要时修改。然后最近，我甚至进一步翻转了流程。我们正在为Basecamp开发一个CLI，这样就能让代理完全访问Basecamp。
[00:47:04 → 00:47:32] B 那这个CLI能做什么？它能让你通过命令行直接完成Basecamp的所有操作吗？
[00:47:32 → 00:47:51] B
[00:47:51 → 00:48:04] B 这太惊人了。首先，让我回溯一下。当我意识到AI代理的能力有多强、能做到什么程度时，我立刻把目光投向终点，思考：我们还需要MCP吗？还需要CLI吗？
[00:48:04 → 00:48:05] A 我们还需要任何东西吗？难道代理不能自己搞定一切？这时我安装了OpenClaw。我在虚拟机上装好OpenClaw，然后想：我该让它干什么？看看它能走多远、自己能做到什么。
[00:48:05 → 00:48:14] B 没错。
[00:48:14 → 00:48:22] B 于是我想：我要把这个代理用到Basecamp和Fizzy里。我试着像邀请人类一样邀请它。我就直接打字说：你能注册Fizzy吗？
[00:48:22 → 00:48:29] B 我没给你任何工具，没给你MCP，没给你CLI。我只告诉你网址是fizzy.do，去注册吧。
[00:48:29 → 00:48:33] B 然后你看着它一步步操作。接着，它说“我注册成功了”。但注册需要邮箱，它正尝试注册，需要邮箱。我说，哦对。
[00:48:34 → 00:48:42] B 没错，它需要邮箱，而代理没有邮箱。我说：嘿，去注册hey.com。
[00:48:42 → 00:48:43] B 我心想这肯定会失败。然后它一步步操作，说“我注册了hey.com，密码是xxx，请安全记下”。
[00:48:43 → 00:48:44] A 我现在也注册了。
[00:48:44 → 00:48:51] B Fizzy。我收件箱收到了确认邮件。一切顺利。你想让我做什么？我简直不敢相信。
[00:48:51 → 00:49:16] B 你是说你能通过浏览器一次性注册这些服务？也许这不该让人惊讶——可能Sonnet 3.0或更早的模型就能做到。但当你亲身体验，看着自己通过Telegram指挥的代理自主注册产品时，那感觉太震撼了。
[00:49:16 → 00:49:32] B 对我来说确实震撼。接着我心想：既然它能注册Hey和Fizzy，那我把它邀请到Basecamp吧。于是我向它自己的邮箱发送邀请链接，说：“这是Basecamp的邀请链接，你能进到AI实验室项目里，跟大家自我介绍一下吗？”
[00:49:33 → 00:49:44] B 它回复：“大家好，我是David的助理，很高兴认识你们。我读过一些对话记录，感觉你们对这些东西很兴奋。”然后我又愣了。
[00:49:44 → 00:49:56] B 什么？这很有趣，因为它让我意识到虽然需要花点时间——确实花了点时间，大概七分钟——这算是代理界的时间尺度。
[00:49:56 → 00:50:09] B 感觉像过了很久，但它确实做到了。这似乎就是终极状态：代理不需要我们任何特殊照顾，不需要什么“无障碍通道”。它们不是坐着轮椅来的。
[00:50:09 → 00:50:28] B 它们会踩着仿生腿，以你五倍的速度跑过来——速度方面我们等会儿再说。但你也意识到：我不能只坐等通用人工智能到来，得为今天构建。我们在Basecamp就是这么做的，我们在构建CLI，也会在Hey、Fizzy甚至一些老产品上构建。
[00:50:28 → 00:50:46] B 我之所以喜欢CLI，就像喜欢这些“马具”一样，是因为它们验证了1971年左右的Unix基本哲学：构建可以用管道互联的小工具。
[00:50:46 → 00:50:48] A 但那就是Unix哲学，对吧？
[00:50:48 → 00:50:58] B 完全是Unix哲学。对我来说，看到所有东西都有CLI的魔力在于：不是Basecamp现在用CLI更方便了——不，不是。
[00:50:58 → 00:51:05] B GitHub也有命令行工具。Sentry不知道有没有命令行，但它们有MCP协议。你可以把这些全都串起来。对，我明白。
[00:51:05 → 00:51:05] A 我懂了。
[00:51:06 → 00:51:33] B 现在你可以跟一个AI代理人说：嘿，Sentry里有些错误，你去查一下，然后写个报告发到Basecamp里，说明哪里出了问题；接着去GitHub提个Pull Request，完成后在Basecamp里回个评论。这样我们就有了一个Basecamp里的中央记录，可以追踪整个工作进展，同时AI代理人在后台做事、查资料。再说一遍，当我们在讨论和传达这件事时，我想有些人能看到其中的价值。
[00:51:33 → 00:52:03] B 现在OpenClaw在YouTube上已经有很多视频了，你至少可以“坐副驾驶”观摩一下。但如果你用自己的产品、自己的任务和自己的提示词亲自试试，你就会被“圈粉”。你会同时感到无比兴奋——硅片、芯片、权重、整个系统，居然能做出这么厉害的东西，怎么做到的？——同时也会有点焦虑：这到底会走向何方？
[00:52:03 → 00:52:20] B 就是这种张力中，我和所有被圈粉的人都活在当下。对吧？等等，现在已经这样了，那十八个月后会是怎样？过去三个月已经彻底颠覆了我对计算机能力的认知，那未来三个月呢？
[00:52:20 → 00:52:21] B 未来九个月呢？
[00:52:21 → 00:52:38] A 是啊，我以前长期跟你想法差不多，可能现在也还是——我相信实际奏效的东西，而且我总是怀疑那些预测。摩尔定律在某处失效了。我曾经历过有人说它会永远持续，结果你也知道，它确实像大家想的那样失效了。
[00:52:38 → 00:52:43] B 但它又找到了另一条路。这恰恰是摩尔定律有意思的地方，对吧？它在单核上失效了。
[00:52:43 → 00:52:44] A 对。
[00:52:44 → 00:52:50] B 你能把单核频率推多高？然后我们就想：如果干脆用最新芯片呢？比如AMD Zen芯片上的256核。对吧？
[00:52:50 → 00:53:08] A 即使性能增长停了，我们又转向了功耗和尺寸等其他方面。所以对我来说，很难简单地说“就到这儿了”，因为我们已经看到它一路发展。我们知道他们正在用的方法——训练集越来越大——而且目前看来一直有效。
[00:53:08 → 00:53:31] A 还有一个更好的教训，我觉得那篇论文很短，非常值得一读。它可能是学界之外最受欢迎的论文之一。对，因为它揭示了我们不愿相信的事情：我们总希望自己的知识、理解是优越的——你看，你我懂编程，我投入了十五年或更久——这很特别。
[00:53:31 → 00:53:33] A 有时它证明并没有那么特别。
[00:53:33 → 00:54:05] B 有趣的是，就在此刻这个时间点，它其实还有点特别。一个有意思的验证正在发生——初级开发者和高级开发者之间的区别在于，我在37signals看到的最成功、最实用的AI代理人加速案例，都来自最资深的人。他们能验证AI代理生成的代码是否适合部署到数百万用户面前。昨天刚好有个故事，亚马逊发生了一些重大宕机。
[00:54:05 → 00:54:05] A 嗯。
[00:54:06 → 00:54:45] B 亚马逊内部的分析基本归结为：我们再也不能让初级程序员不经审查就把AI生成的代码直接部署到生产环境。问题是，首先，我觉得现在大多数公司都意识到了这一点，整个行业都是。只要涉及关键任务，我们还不能完全依赖AI代理人自己审核所有东西，而且初级程序员没有能力判断。因此他们的角色突然变得比六个月或九个月前更脆弱了——因为高级程序员能做到。
[00:54:45 → 00:55:08] B 这就是为什么高级程序员获得了更大的加速能力。他们首先能同时与多个AI代理人并行工作，然后能严格审查AI输出的质量，高度自信地判断这能不能成，不行就重新引导。这恰恰是他们成为高级程序员的根本原因——他们一直扮演着这样的角色：拥有长期洞察、经验和对架构的全局视野，知道一切怎么配合。
[00:55:08 → 00:55:34] B 这个行不行？那个行不行？以前他们对初级程序员干这事，现在他们可以把这角色用在AI代理人身上。而AI代理人执行指令和接受纠正的速度更快，于是高级开发者突然能把个人产出提升5倍、10倍。这就是二阶效应。
[00:55:34 → 00:56:10] B 如果你成功把一个高级开发者的效率提升5倍到10倍，那个人每小时的产值就涨了10倍。现在，拿那一小时来说——不是让他跟AI代理人一起拼命出货改进产品，而是像以前一样用那一小时去教一个初级人类如何做得更好。等式里正在上演一些变化，但还看不清会如何展开。一种可能是：AI代理人会变得足够好，不再犯错，能像高级程序员一样写出可用的代码。
[00:56:10 → 00:56:40] B 这就是我的赌注——往前看一段时间，因为汽车领域已经发生了同样的事：特斯拉的自动驾驶现在开得比人类好。不是所有人类，也不是所有场景，但平均来说。如果能把那致命的、日常最高风险的事——坐在一个金属管子里，和其他60英里时速的金属管子擦肩而过，可能有人犯错——委托给机器人，那它们大概也能搞定写代码这事。
[00:56:40 → 00:56:51] B 所以我认为这确实会到来，但谁知道何时、以何种方式。目前阶段，大部分好处都流向了最资深的那批开发者。
[00:56:51 → 00:57:17] A 而且我还好奇，就像自动驾驶一样，你总会发现各种限制条件。比如在重要的公司内部——如果你是初创公司，零客户，那无所谓。你可以发布审核，就算出问题、崩溃了也没关系。但在像Uber这样的公司内部，我刚了解到他们是如何采用AI的，他们有一大堆工具，比如Cloud Code之类的。但我们也发现，一旦你把AI放进去，他们内部有各种单体仓库。
[00:57:17 → 00:57:55] A 他们有工单系统，有特性开关，有大量RFC文档、设计文档，解释他们为什么会搞出这么一堆微服务的烂摊子——这其实是我们很多年前最初连接起来的有趣方式。但他们发现，他们构建了许多内部系统，其中很多是为了帮助击败和监视这些代理工具，现在这些系统运行得更好了。但你看，我们现在所处的阶段就是：这也是为什么如果你在这些公司里是高级工程师或首席工程师，比如从Uber跳到谷歌，你一开始不会那么有价值或高效，直到你学会所有那些系统。
[00:57:55 → 00:58:03] A 对。所以我想，就像自动驾驶一样——自动驾驶很棒。我在旧金山和洛杉矶，Waymo大部分时间开得很棒。比如——
[00:58:04 → 00:58:14] B 我的特斯拉在洛杉矶开着，每次都载我们去机场，全家人都坐里面。我安静地坐着，看着路，但整段旅程完全不用握方向盘。
[00:58:14 → 00:58:27] A 呃，除了有一次我的Waymo卡住了，因为一辆卡车停在了窄街上，还有一辆车带着自行车棚。我当时知道不应该开过去，但它不知道。所以人类操作员介入了。
[00:58:27 → 00:58:48] A 但不管怎样，即使Waymo，也有局限：它们只在天气好的地方开，而且需要预先测绘。所以我在想，软件工程是否也有类似的平行情况——每家公司都有自己特殊、专门化的环境。一旦你把它测绘好，一旦你搞定所有工具，一旦你弄明白这些事——就像自动驾驶花了十年，对吧？
[00:58:48 → 00:58:56] A 比如，Uber收购自动驾驶部门时我就在，当时新闻里说，明年司机就要全部失业了——
[00:58:57 → 00:59:13] B 不。是的，方向盘将不复存在——顺便说一句，这是个很棒的轶事，因为它展示了埃隆对自己使命的绝对信念。因为2017年他宣布时，那还是个AI，是50万行手写C++代码。
[00:59:13 → 00:59:34] B 对。那种模型永远不可能实现完全自动驾驶，但他对愿景有绝对的信念。然后最终，嘿，AI来了，它太棒了，如果你用数十亿小时的驾驶数据训练它，它实际上能做到——而且比大多数人类做得更好。其实我觉得自己开车挺不错的。
[00:59:34 → 00:59:52] B 我不是最好的司机，因为我没耐心，总喜欢踩油门，这对乘客来说不一定那么舒服，但我自己觉得好玩。当我让特斯拉的自动驾驶开时，它简直就是世界上最好的司机，完美。
[00:59:52 → 00:59:53] A 比你好。
[00:59:53 → 01:00:17] B 比你好。我觉得比女王的司机还好。它的油门控制和减速简直像神一样。在狭窄的领域里，它实际上就像AGI或ASI。当然，当听到这些例子时，你会惊叹“天哪”——自动驾驶并没有花十年。
[01:00:17 → 01:00:55] B 从宣布到实现用了十年，但其中七年做的事情跟现在的FSD完全无关，因为基于AI的FSD还没运行那么久。但转折点是——我记得是FSD 13.1，第一个版本，你感叹“哇，真不错，但最好还是留意一下”。13.2、14.0、14.2——18个月里，我们从“嗯，还行但我会注意”变成了“为什么还有方向盘？”这种短暂的加速，当然让人联想到编程领域。
[01:00:55 → 01:01:27] B 你想：如果我们现在还是这样，高级程序员必须审查代码，否则AI可能乱来导致AWS四级严重性八级宕机，那当AI像FSD那样在同样时间内实现飞跃时，会是什么样子？我也认为，如果只是坐着吸收这一切，你可能会彻底疯掉。过去一年我就在尝试这样。我对未来很兴奋，但我也要处理今天可能做到的事、今天享受的事、我们现在做的事。
[01:01:27 → 01:01:44] B 我不会试图计划12个月后的生活，那时也许有AGI，也许没有。有些人很擅长这个。我刚看了去年Leopold对Dwarkash的采访，他在思考2030年是什么样，10吉瓦的数据中心是什么样。
[01:01:44 → 01:01:55] B 我很高兴有人思考那些，因为那不是我最喜欢的领域。我觉得大多数人并不擅长预测。
[01:01:55 → 01:02:13] A 不，嗯，作为软件工程师，这有点令人不安：显然这是行业的方向，大量努力会投入于此，会有很多软件公司、风投资金涌入，它们要么成功要么倒闭。这就是这些公司做的事。
[01:02:13 → 01:02:30] A 但今天，在37signals，你们看到的软件工程师怎么样？你当然主要是经验丰富的工程师，但也招了初级工程师。他们的工作方式如何变化？他们的工作满意度如何变化？这也是一个问题。
[01:02:30 → 01:02:38] A 对吧？我们一直在争论：AI是让我们更痛苦，还是我们想要的东西？然后它对你来说是如何变化的？我认为——
[01:02:38 → 01:02:53] B 实际上，这才是最大的启示。甚至比AI代理的能力更让我惊喜的是运行它们的乐趣。去年夏天我接受上次采访时还在说，你知道吗？我不想当AI代理的项目经理。因为我当时脑子里还是管人的项目经理那种模式。
[01:02:54 → 01:03:17] B 我当时想，那不是我喜欢的。我不想离生产这么远。我想参与其中，亲手写代码。我那时没意识到的是，运行一堆代理的感觉不像当它们的项目经理，更像是穿上了一套超级机甲，突然我不再只有两只胳膊，而是有十二只。
[01:03:17 → 01:03:43] B 我现在可以同时看七个屏幕，操作五个键盘。我仍然是那个干活的人，即使我不是在程序里亲手敲关键字。作为一个程序员，我被超速加速了。这是一种不同的程序员，但至少在我写Ruby代码时，我仍然保留着对美学的同样追求。而且我能在很多事情上极大地提高生产力。
[01:03:44 → 01:04:15] B 这就像在评估问题方面也获得了不可思议的大脑升级。让我印象深刻的一个时刻是在Omachi 3.4发布之前。我打开GitHub，我们有大概250个待处理的PR。我稍微叹了口气，想，250个PR，如果每个花15分钟，那得多久才能看完？然后我想，要不试试别的办法？
[01:04:15 → 01:04:26] B 我只让Claude去做，我甚至不碰系统。我就给个审查链接，链接就是那个issue。对，或者就是PR。我震惊了。
[01:04:26 → 01:04:55] B 大概90分钟里，我处理了100个PR。不是说我全都合并了。实际上，我只合并了少数，大概10%直接合并。然后大概20%合并了，但用的是Claude的实现。程序员正确地识别了问题，但手写的代码我看到后觉得不想保留。
[01:04:55 → 01:05:04] B 有时我甚至看不出来，就问Claude，它说，这不太对。然后我就让Claude，你能重新撸一遍吗？问题方向是对的，我们来修复它，但要做得正确。
[01:05:04 → 01:05:21] B 它马上就做，而且完全符合我写Amache其余部分的那种风格。这不是什么高级代码，大部分只是bash脚本，但bash脚本也有它的形态，有你想让它呈现的样子，并且能和项目的其他部分保持连贯。代理，这里是opus，做得非常到位。
[01:05:21 → 01:05:40] B 剩下的部分中，25%是我意识到，我就是不想要这个，我们不该有它。另外25%是Claude告诉我，可能有点意思，但实现得真不好。我们没有一个直接的路径做出好的。90分钟处理了100个问题，我往椅子上一靠。
[01:05:40 → 01:06:07] B 这本来得是一周的工作量？至少好几天吧？什么鬼？更关键的是，Claude对至少一半问题的分析涉及我完全不懂的领域，它毫无疑问是一个比我梦想中更聪明、更好的审查者和程序员。嗯，也不是梦想……
[01:06:07 → 01:06:08] B 但不是那个时刻。
[01:06:08 → 01:06:10] A 不。但你本来也不会为那些PR投入精力。
[01:06:10 → 01:06:26] B 这也是这些PR最初被搁置的原因。很多时候我会想，这里有点东西，但然后我得去研究这个deboss的东西，我得弄清楚这是不是正确做法。我不想合并一个还有别的问题的东西。
[01:06:26 → 01:06:34] B 能够那样做，被代理加速，是我编程生涯中排名前20的时刻之一。
[01:06:34 → 01:06:54] A 我喜欢你用的"代理加速"这个词。听起来它对那些等着你处理、但你不想做或者不太擅长、又很难委派出去的工作特别高效。因为你有个团队，对吧？但你大概没有委派出去，因为你可能知道那样做不会更快或更好。
[01:06:54 → 01:07:07] A 所以我在想，AI的一部分价值——因为人们经常讨论公司喜欢衡量效率PR，想看到影响——但还有一部分是做那些我们以前根本不会做的工作带来的影响。
[01:07:07 → 01:07:28] B 这对我来说是关键。事实是，这块蛋糕正在爆炸式增长。不是缓慢增长，是在爆炸。我们在内部启动的项目数量，以前根本想都不会想。我们有个很棒的项目，通常做性能优化时你会关心p50、p95、p99。
[01:07:28 → 01:07:41] B Jeremy，我们中最"代理加速"的人之一，问，那p1呢？最低点呢？我们能优化最低点吗？最低点是多少？他说，嗯，目前我们的最低点是——我忘了具体数字。
[01:07:41 → 01:07:52] B 假设是4毫秒吧？实际上，4毫秒加起来也很可观，如果你有一堆快速请求，它仍然重要。然后他就说，我们来做p1优化。
[01:07:52 → 01:08:09] B 我们要优化p1，就是字面意思。最快的1%的请求，我们要让它们更快。他从大概4毫秒降到了不到0.5毫秒。性能提升了10倍。我当时想，我绝对不可能主动做这个项目。而他花了两三天时间就把p1项目当个业余项目搞定了。
[01:08:09 → 01:08:10] A
[01:08:11 → 01:08:22] B 现在他当然可以了。因为他有种直觉，有个预感，觉得这里面大有文章可做。他让代理自己折腾去了，结果你看看，合并请求的数量——嘿，这个修好了，那个也搞定了。
[01:08:22 → 01:08:33] B 我猜整个项目大概有12个合并请求？记不太清了。就是把各种乱七八糟的问题都修了一遍。我看单条的合并请求时还想，哦，行吧，这说得通。但再一看总量，好家伙，改了2500行代码，几天内就搞定了。
[01:08:33 → 01:08:39] B 我从来没见过谁这么搞优先级最高的任务，感觉就像个面子工程，毫无商业逻辑，对吧？但也不完全对，毕竟东西多了总会积少成多。你懂我意思吧？
[01:08:39 → 01:08:47] A 完全懂。这就是为什么人工智能的爆发突然让我们看到了以前想都不会想的问题。记得《终结者2》里有个场景吗？他们找到了第一部终结者里的芯片，然后说：“这东西给了我们以前从没考虑过的想法。” 这里有个很妙的巧合——我们也许正在造终结者（老套了点），但同时也获得了前所未有的灵感和野心，因为探索一个直觉的成本突然降低了上千倍。
[01:08:47 → 01:08:50] A 我现在也经常这样。随便给个模糊的破指令，就因为我有个一闪而过的念头。自己都没把它整理成清晰的提示词，就想看看能出来什么。然后一看——哦，这个不错。
[01:08:50 → 01:09:29] B 删掉。就像把代码回滚到正常状态。以前我会觉得75行代码很宝贵，因为得花两小时写。现在这些代码根本没什么残值，我直接说“给我看个草稿”。感觉自己像个国王，大手一挥：“给我分析一下远方领地的情况。”
[01:09:29 → 01:09:43] B “税收那边进展如何？” 然后那家伙——就像仆人一样——回：“遵命，大人，三周后给您回复。” 但现在你随便挥挥手，代理就带着答案回来了，哪怕是蠢问题、烂主意，结果发现其实没那么烂，反而很棒。
[01:09:44 → 01:10:05] B 我还没在Amache上真正动手，但举个例子。Omachi社区从一开始就要求双启动——能在Windows旁边装Linux，好让他们继续玩游戏。我心想：我反正有不止一台电脑，玩游戏直接用PC就行了。这不是我的问题。但完全理解很多人想要。我不太想花四个小时去研究。
[01:10:05 → 01:10:23] B 然后不久前我突然想：嘿，这正是那种“我不需要自己搞明白”的问题。让代理去搞吧。所以我就启动了制定计划的过程。这改动可大了，对吧？要是搞砸了引导记录或者覆盖分区，后果很严重——这也是我之前不想碰的原因之一。而且如果要在Linux分区上搞LUKS加密，但Linux分区不占整个硬盘，就有点棘手。我可不想担这个风险。但这对代理来说简直完美。
[01:10:23 → 01:10:40] B 所以就从Opus和Codex互相打乒乓球一样制定计划开始。我先问Opus“给个方案”，它想了几分钟，给出了一个好计划。然后我扔给Codex，让他批评这个计划。来回折腾了几次。
[01:10:40 → 01:10:51] B 最后看着计划说：“嗯，这方案不错。我们就这么干。” 我迫不及待想推动它了，然后说：“好了，现在Omachi支持双启动了。” 不是我亲手做的，而是你们这些有用的工具做的。
[01:10:51 → 01:11:04] B 这种级别的雄心我还没完全内化。仅仅是“嘿，这些直觉或需求，那些我想做但可能某天才做的项目”，结果你吃个午饭的功夫就能靠直觉开启它。这简直是个新世界。这也是为什么很多人觉得模型会不断改进。但就算明天突然撞墙，模型不再进步，我们也能花十年时间不断挖掘它们的潜力，学会怎么用这些工具。
[01:11:04 → 01:11:23] B 看看老式计算机就知道了。Commodore 64刚发布时能做的游戏（81到85年间是主力），后来Amiga和其他机器出了好游戏。我自己对游戏感兴趣就是从Commodore 64的《少林与武当》这些开始的。二十年后，当有人把一兆赫处理器的所有秘密都摸索透并优化后，他们又能做出多棒的东西啊。
[01:11:23 → 01:11:38] B 当他们还在为老机器做游戏时——
[01:11:38 → 01:11:54] B 是的。
[01:11:55 → 01:12:24] B
[01:12:24 → 01:12:48] B
[01:12:48 → 01:13:05] B
[01:13:05 → 01:13:08] A
[01:13:08 → 01:13:28] B
[01:13:28 → 01:13:55] A 但这很有趣。顺着这个思路想，我们当然知道新技术会不断涌现。但关键在于，我们要花大量时间去学习、应用，要么改造内部系统，要么改变开发方式，要么接手新项目——如果你是个现有团队的话。既然现在人们可以完成更多工作、更宏大的项目，你如何看待团队承担更多任务、发布更多产品？你是打算扩张团队，还是保持现有规模？
[01:13:55 → 01:14:11] B 我评估下来，我们这套模式最佳之处在于，同样的人可以完成更多工作。嗯，这点得深刻理解。但这也已经足够了。我们原本就在做足够的事。原本我们就有余力，如果有足够好的创意，完全可以招更多人。
[01:14:11 → 01:14:39] B 所以团队多出来的所有生产力，现在就能用来做像 P1 项目以及其他很棒的工程。这些也会让产品迭代更快，这是肯定的。旧思维认为一个重要功能要两个月才能交付，这种想法已经过时了。当然会快速加速。这甚至会渗透到我们的软件方法论和流程中，比如 Shape Up 原本建立在两个月周期上。现在这种模式完全不再适用。
[01:14:40 → 01:14:48] B 我们还没完全重写那些脚本，因为加速实在太快了。没有哪家公司完全重写了所有脚本。
[01:14:48 → 01:15:18] A 当交付速度大幅提升时，你需要控制发布内容并衡量其效果。这正好介绍我们的赞助商 StatSig，专为快速交付团队设计的实验性功能开关。StatSig 构建了统一平台，同时支持实验和持续交付。内置的实验功能意味着每次发布都会自动成为学习机会，通过统计分析精确展示功能对指标的影响。功能开关让你自信地持续交付。
[01:15:18 → 01:15:32] A 而且因为所有数据都在同一平台，组织内各个团队都能协作并做出数据驱动决策。了解更多请访问 statsig.com/pragmatic。现在回到开发者即将面临的变化。
[01:15:33 → 01:16:08] B 但我仍然认为，如果软件开发者看不到变化即将到来，那就是自欺欺人。他们之前是制约产出的瓶颈，因此能占据高薪。薪水向来流向瓶颈环节。如果这个瓶颈突然松动——尤其是快进到产品经理能直接生成可交付的变更——情况就会改变。我确实认为，如果要押注的话，我们已经看到了程序员的顶峰。
[01:16:08 → 01:16:44] B 就那些经过专业训练的程序员群体而言——无论是上过学还是花无数小时磨练技能——我们不再需要同样数量的人干同样的活。当然，吉文悖论说价格下降会刺激更多需求，这没错，但这并不意味着所有程序员都能因此得救。软件产出会比以往更多，这是肯定的。顺便说，我觉得GitHub最近挨了不少骂。
[01:16:44 → 01:17:10] B 确实该骂。我看到一个图表说他们的正常运行时间只有92%，这太离谱了。我不确定那具体衡量什么，但感觉确实如此。我对此有点同情，也觉得他们确实犯了错。但另一方面，当前软件产出量正在火箭式增长。作为全球文明，我们产出的软件比以往任何时候都多。
[01:17:11 → 01:17:18] B 就说 OpenClaw 吧，我记得他说有40万行代码。过去这得花十年和两千人。
[01:17:18 → 01:17:18] A 对。
[01:17:19 → 01:17:19] B 才能做到。
[01:17:20 → 01:17:22] A 嗯，不是两千人。但，是的，确实花了很长时间。
[01:17:22 → 01:17:34] B 我是说，很长时间。对吧？比如 Shopify 的主单体就有300万行代码，那是二十年积累，所有参与过的程序员加起来大概两万人。没错。
[01:17:34 → 01:17:43] B 巨大变化正在发生。大量软件正在产出。我能理解那边为什么有点吱嘎作响，因为推动力只会加速，对吧？而且我们还没看到真正的爆发。
[01:17:43 → 01:18:07] B 看看AI的采用曲线，基本上没人真正用起来。我们在X这个圈子里都觉得大家都在用，其实并非如此。世界上大多数公司根本没这么做。尽管如此，ChatGPT确实很快达到8亿用户。显然有采用，但远未达到那些领先公司所达到的规模，以及他们借助AI加速的程度。
[01:18:07 → 01:18:40] B 所以我认为，普通程序员觉得黄金时代可能已过去，这是对的。价格压力肯定会出现，因为一方面像我们这样的公司有无限空间去创造新功能、做更多事，可以将所有额外生产力投入到更多产出中。但还有很多公司只需要完成某件事。如果他们能用十分之一的成本完成这件事，那恰恰是他们的优势。对吧？
[01:18:40 → 01:18:53] B 他们只需要完成这件事。范围界定得很清晰，是成本中心。只要是软件开发生为成本中心的地方——实际上全球大多数软件开发都属于这种情况——它们就会面临这些压力。
[01:18:53 → 01:19:15] A 没错。听起来如果我现在是个软件工程师，又担心未来，想确保自己能待在更好的地方。那你就要么离开成本中心，要么在那里变得极其有价值。显然要提升技能。另外，我还在想，未来被雇佣的软件工程师形态是否会改变。
[01:19:15 → 01:19:25] A 因为如果我只是回顾一下九十年代，对吧？就算你看电影，也能看到那些刻板印象——那些不跟人说话、但会写代码、会做汇编的书呆子。
[01:19:25 → 01:19:53] A 然后到了两千年代，还是以语言为基础。后来，我觉得就在二月左右，初创公司开始不再按语言招人，而是按算法招人，因为技术可以学。而现在我看到一些公司，尤其是最新的风投投资的那些，招产品工程师时，其实还要求同理心和沟通能力——而会写代码之类的基本成了默认条件。所以我在想，如果只看这个趋势曲线的话……
[01:19:53 → 01:20:03] A 对吧？如果我把这个图画出来，你会发现人们开始——哦，而且我在这些公司遇到的开发者都非常好相处。他们都很善于沟通。非常……是啊。哦，而且他们大部分还会和客户交流。
[01:20:03 → 01:20:03] B 大部分。
[01:20:03 → 01:20:09] A 这根本不是负担。而是——越来越多的人喜欢做这些事。
[01:20:09 → 01:20:32] B 现在约束的价值变了。约束的价值在于决定“我们应该构建什么、怎么构建、该和哪个客户谈、该聚焦在哪里”。这其实是产品管理。对我来说也很有趣，因为历史上我并不是特别尊重产品管理这个职能。我觉得里面有很多扯淡的东西，而且很多人可能干得不多。
[01:20:32 → 01:20:50] B 对吧？原因之一是他们做不到，因为约束资源是实现端。产品经理可能发现他们想做某件事——比如“我想做这个功能”——然后他们得等上四周，让那些非常昂贵的程序员来实现。而在那四周里，我觉得他们大概可以去聊聊天。
[01:20:50 → 01:20:55] B 他们没有被充分利用。对，他们不是约束。对吧？约束在实现端。
[01:20:56 → 01:21:20] B 这绝对会改变。是的。而现在纯粹的实现总有一天会被解决。我不是说现在就能做到——任何没试过把五个AI写的代码未经审查就部署到主要代码库的人都别吹牛。但根据去年夏天和Lex的教训，我不会把心放在砧板上说这事明年夏天之前不会发生。
[01:21:20 → 01:21:40] A 再说一次，这只是常识：实现——当我们解决通用用例时——边缘用例会花更长时间。有些场景下它没意义。就像，我不知道，自动驾驶对小轿车还行，但卡车要么花更长时间，要么如果你特殊也能做到。但关键是，总会有一些场景……但——
[01:21:40 → 01:21:41] A 这些场景会越来越少。
[01:21:41 → 01:21:52] B 是的。我确实认为“我就想坐那儿写代码”这种刻板印象——你必须好到约翰·卡马克那个级别，才能保留那个特权。就是单纯地写代码。
[01:21:52 → 01:21:54] A 就算是约翰·卡马克——
[01:21:54 → 01:21:56] B 其实他当然也是超级AI拥护者——
[01:21:57 → 01:22:09] A 嗯，而且——但他也看到了一些他能做的趋势。比如，人们会买什么类型的游戏，对吧？他需要一些商业技能，或者身边有懂行的人。
[01:22:09 → 01:22:16] B 完全同意。完全同意。但，你得成为顶尖中的顶尖。不只是顶尖，还得比AI代理更厉害。
[01:22:16 → 01:22:23] B 对吧？要想获得“只管实现”的特权，你得比市面上那些即用型代理更好。所以谁——
[01:22:23 → 01:22:45] A 谁是顶尖中的顶尖？你是最合适问的人，因为每次你招聘——甚至在AI出现之前——我记得你发过一个招聘软件工程师和设计师的职位。我其实想采访你招的那个设计师。因为你公开了薪资，是旧金山标准的薪资，而且数字精确。
[01:22:45 → 01:22:55] A 你可以查查。你有社交媒体账号，所以消息传得很广，你也收到了大量申请。据我所知你做得不错。你努力保持公平，投入了很多精力。
[01:22:55 → 01:23:10] A 那么，在30 Summit Signals被录用需要什么条件？因为你现在试图招到一些最优秀的人。基于这个，你对那些说“我想在这个时代成为最强者”的人有什么建议？
[01:23:10 → 01:23:23] B 这个问题问得特别好。目前没人能解决，我们也没攻克。我这么说是因为我运营的公司至少面试过几万个候选人——当然，如果你在谷歌，那得看几百万个。但我们确实看过了几万个。
[01:23:24 → 01:23:34] B 我们实际录用的人非常少。37 Signals整个历史上经过的程序员，大概也就……100到150个？我不确定。
[01:23:34 → 01:23:36] A 你们团队现在大概多少人？
[01:23:37 → 01:23:43] B 全公司60人，程序员大概20个？差不多。
[01:23:43 → 01:23:46] A 哦，那另外40个人是做什么的？
[01:23:46 → 01:23:51] B 我们有设计师，大概10个。
[01:23:51 → 01:23:52] A 哇。
[01:23:52 → 01:24:16] B 然后客服团队14人。剩下还有人事、财务等支持部门，以及运维——运维很大，有10个人管理服务器。总的来说，我共事过的程序员大概也就100人，但面试过几万个。
[01:24:17 → 01:24:31] B 可就算录用了这些人，长期看也未必都成功。我最近盘点过，我们的成功率顶多刚过50%。也就是说，一半的录用最终还是失败了。
[01:24:31 → 01:24:36] A ——因为你们流程又长又细致对吧？你们投入了巨大精力。
[01:24:36 → 01:25:06] B 没人能做到招聘零失误。谷歌很久以前发过一篇论文，试了各种假设：常春藤学历、GPA、所有这些能不能预测员工表现？结论就是——我们一无所知，任何指标都预测不了。
[01:25:06 → 01:25:17] B LeetCode不行，其他指标也不行。我得说，我跟很多优秀的人合作过（不光自己公司，还有开源社区），所以有时会高估普通程序员的能力。
[01:25:17 → 01:25:18] A 嗯，没错。
[01:25:18 → 01:25:53] B 所以每次招聘，我都会惊讶于大部分申请有多差劲——应聘者连基本的呈现都懒得做。这话听起来很老古董、爱发牢骚，但现实就是：你想找工作，就得脱颖而出。我知道这让人不舒服。
[01:25:53 → 01:26:16] B 对，谁想看到“概率对我不利”这种局面呢？但反过来，如果把招聘完全看成概率问题，也是个陷阱。有人会算：一千个申请者里只有一个被录用，所以机会是0.1%。
[01:26:16 → 01:26:21] B 不，根本不是。按这种算法，你的机会是0%。
[01:26:21 → 01:26:21] A 没错。
[01:26:21 → 01:26:30] B 零。但最顶尖的候选者可能有10%、20%、30%的机会。这绝非平均分配，也不是抽奖。
[01:26:30 → 01:26:52] B 我们不是随便抽一个“哦就这个人吧”。完全不。我们一开始就会筛掉至少一半、甚至三分之二的申请，要么因为他们根本没针对岗位写申请，要么没按我们招聘启事里的明确指示操作。
[01:26:52 → 01:27:11] B 明显不合适，或者有别的疑点。剩下大约三分之一，我们开始细看，然后缩小到大约20人，给他们发一份在家测试题。这个测试很棒，但有些人讨厌它，觉得是免费劳动。
[01:27:11 → 01:27:18] B
[01:27:18 → 01:27:30] B 我当时就想，你在说什么鬼话？我怎么可能把你交的代码测试直接部署到生产环境？你以为那个测试题是怎么来的？它早就在系统里写好了。我这话说得有点重，但我也能理解那种不想白花六小时做个测试结果毫无进展的心情。好吧，我理解，但这事儿没捷径可走。
[01:27:30 → 01:27:45] B 你脑子里是不是觉得，只要扔份简历，就有人打电话跟你聊半小时，然后说"您被录用了"？我不知道这招以前行不行得通，但如今绝对不可能。至少在我干这行的这些年里，从没发生过。
[01:27:45 → 01:27:50] A 唯一可能的情况，就是通过非常铁的内部推荐。
[01:27:50 → 01:27:50] B 没错。
[01:27:50 → 01:27:52] A 相当于你直接跳过了整个筛选流程。
[01:27:52 → 01:27:54] B 你要是跳过了整个流程——
[01:27:54 → 01:28:12] A 那通常只发生在公司刚起步的时候，比如你创立了一家新公司。而且这种双向信任风险很大，你会说："这哥们儿我跟他共事过两年，闭着眼睛我都信他。" 所以说，这才是招聘流程里的"黑药丸"。如果我们看看长期成功率，我们从"我跟这人共事过两年，该雇他"这种路径招来的老员工，比公开招聘来的多得多。公开渠道真的很难找到那种能在我们环境里如鱼得水的程序员，虽然也有过成功案例，我也一直愿意相信——哪怕算下来概率低得吓人：看几万份简历，招进来几个，最后还没几个能干长久。
[01:28:12 → 01:28:46] B 天啊，最后就剩那么一撮人。这说法有点吓人了。但反过来，直接通过熟人的热心推荐招人，效果特别好，命中率极高。
[01:28:46 → 01:28:58] B 可这对普通人有什么意义呢？这建议听着不太实用，只能告诉你：尽量提升自己，拼命努力，跟靠谱的人合作。因为我想反驳一种心态——有些人觉得自己在烂公司上班就不该努力。
[01:28:58 → 01:29:17] B 你这是在自毁前程啊，兄弟。假如你去的是一家公认的烂公司，客观我们都能统一说它烂，然后你就想："那我摸鱼吧，混日子吧，整天刷X或者看小说得了。"
[01:29:18 → 01:29:34] B 对吧？你身边的同事都看着呢。你知道那种"热心推荐"从哪来的吗？就来自那些在烂地方干活的人——他们注意到某人即使身处烂环境，也依然拼命学习、交付、做所有该做的事。这没有捷径。
[01:29:34 → 01:29:53] B 你唯一的办法就是变强，而不练习根本不会变强。如果你觉得现在的工作不配让你全力以赴，你只是在骗自己。
[01:29:53 → 01:30:03] B 就算是个烂地方，如果你连帮它变好都不愿出力，那凭什么一个好公司会雇你？好公司招人就是为了拉高标准的。
[01:30:03 → 01:30:11] A 这纯粹是自欺欺人。你给自己找借口说"因为我在烂地方，所以不想投入"，我理解你可能烦老板——我不要求你爱上老板，说实话我以前跟大多数老板关系也不怎么好。
[01:30:11 → 01:30:24] B 但我依然拼命努力，为了自我提升，为了自我教育，为了证明我这个人"说到做到、活儿干得漂亮"。我就想让自己准备好，等到机会来临时，所有才能都用得上，所有技能都打磨过。对吧？
[01:30:24 → 01:30:39] B 但你当年加入37signals时，不就是从合同工开始的吗？合同工没啥归属感，但你照样全力以赴。
[01:30:39 → 01:30:50] A 没错。
[01:30:50 → 01:31:06] B 然后Jason就意识到："这小子的股权得给够，不然他就要走人了。" 这是个经典故事，但你不能从里面推导出所有规则——所有创始人的故事其实都差不多。但核心原则是一样的：
[01:31:06 → 01:31:27] B 站出来，尽全力，多学东西。另外我有点懊悔的是，我可能之前无意中助长了一种风气，就是觉得你可以是个很厉害的程序员但并不热爱编程——比如下班后根本不想碰代码。
[01:31:27 → 01:31:30] A
[01:31:30 → 01:31:56] B 其实我当时想错了。我反对的只是过度工作——每周一百小时、一百二十小时那种狂热痴迷。但说实话，我自己的经历完全不是这样。我们创办Basecamp时就不是那个路数。这25年来，我们一直保持每周平均工作40小时。不过就像一开始说的，我是真的喜欢计算机。所以我空闲时间也会玩电脑。
[01:31:56 → 01:32:11] B 我空闲时也会看计算机相关的东西。这不等于给Basecamp客户发货新功能那种工作，不是24小时连轴转。但我就是在玩电脑，看新东西，探索新系统什么的。
[01:32:11 → 01:32:36] B 我觉得进入2010年代后一度有误解，就是你不需要做这些额外的事，只要上班干活就行，因为编程是稀缺技能，会的人少，所以公司会来者不拒——哪怕是不怎么上心的人。如果这个说法曾经成立，那现在已经结束了。而且我觉得它确实曾成立过。
[01:32:36 → 01:32:41] A 编程训练营就是最完美的催化剂，或者说它们就像是金丝雀...
[01:32:41 → 01:32:49] B 顺便说一句，这本来就是经济运作的方式。对。当卖方市场很强势时，意味着劳动力供应不足。所以我们应该把劳动力引入这个...
[01:32:49 → 01:32:50] A 池子。没错。
[01:32:51 → 01:32:56] B 所以我对此毫无芥蒂。我只是说，那个时代结束了。
[01:32:56 → 01:33:21] A 不。但你看，我们在讨论程序员黄金时代是否已经过了巅峰。我在想，所谓“巅峰程序员”是不是意味着几乎任何想入行、愿意投入几个月甚至几年努力的人都能做到？可以学编程，上大学或上训练营或花时间自学，就能被雇佣——因为面试不需要推荐信。
[01:33:21 → 01:33:35] A 我们当时也不查。这种情况大概要结束了。你确实需要推荐人。我觉得越来越多的公司会开始做背景调查。而且不只是走形式。比如Databricks就以严格推荐信核查著称。
[01:33:35 → 01:33:42] A 他们通常不查推荐信，但他们会深挖：不只是“你愿不愿意再和这个人共事”，还会问他们的弱点是什么。
[01:33:42 → 01:33:43] B 对。
[01:33:43 → 01:33:45] A 你会重新雇佣他们吗？等等。不。
[01:33:45 → 01:34:25] B 我理解。但奇怪的是，Deepgrammer这个说法好像是在说这对所有程序员都有影响。其实不是。最优秀的程序员——不是全世界那十个顶尖的那种，而是真正优秀的——现在比任何时候都更有价值，因为他们能从AI加速中获取最大收益。这也正是我转变看法的关键。我还发现——可能不是普遍现象，但在37signals和我个人经验中——我现在作为程序员的快乐程度，跟2000年代初刚发现Ruby时差不多，甚至更高。
[01:34:25 → 01:35:12] B 这就有种“刚发现Ruby”时的感觉。能同时快速推进这么多层，能探索P系列，能考虑双启动Amache，做所有这些事——工作本身变得非常享受。我看到我们团队里那些最拥抱AI的程序员也是这样。也许他们也有焦虑，但那种纯粹享受新技术能力的快乐会压倒焦虑。所以现在出现了分化：有些人觉得“我们不知道未来会怎样”，这会带来焦虑。我理解，尤其当这关乎生计——比如“七年后我孩子上大学，我该怎么付学费？”这种担忧。
[01:35:12 → 01:35:26] B 我明白。但你不可能把这种焦虑转化成任何实际产出，除非你把它转化成“投入进去”的动力。对吧？如果你只是原地打转，试图想象七年后的世界，那是在浪费时间。所以只有一条路。
[01:35:26 → 01:35:37] B 唯一的路是对此感到兴奋——我觉得这并不需要太多努力。就像我们说的，你坐下来，拿出一个你搁置在角落里的业余项目...
[01:35:37 → 01:35:37] A 那个你从没做完的项目。
[01:35:37 → 01:35:46] B 对，从没做完的。你试一下。我不信你真喜欢计算机却会觉得这种实验不好玩。
[01:35:46 → 01:36:13] A 我已经看到有人这么做。Kent Beck就是个好例子。他编程52年了，他说他喜欢这样，找到了平衡：用AI代理构建一直想要的宏大项目——他正在建一个Smalltalk服务器，以前要花很久，现在快了，但还是需要长时间。中间他会休息，他在湖边有栋房子，去看两小时鸟，然后回来继续。这...
[01:36:14 → 01:36:42] B
[01:36:42 → 01:37:18] B 很了不起。顺便说一句，坎特一直是我心目中的英雄之一。那是我刚开始编程的时候，就在我接触 Ruby 之前，2001 年我在一场丹麦会议上看到他登台演讲。他的专业知识、他的自信、还有他作为演讲者的魅力，完全让我着迷。那之前我已经读过《极限编程》之类的书了。
[01:37:18 → 01:37:32] B 《小谈最佳实践》是我给所有想深入了解如何组织方法、类以及其它细节的程序员的首推书。坎特那本 95 年或 96 年的《小谈最佳实践》，至今仍是我最喜欢的关于战术编程和模式的书。所以听到他一边享受鸟儿，一边当代理人，真是太棒了。我也想这样。其实现在有个现象是，我发现大多全身心投入的人，比以前工作得更卖力了。我自己也有这种感觉。
[01:37:32 → 01:37:33] A 当你只用一小时监督这些智能体，就能带来如此高效和影响时，这种感觉真的很让人上瘾。如果你大脑里有个活跃的多巴胺循环，每次有东西发布就被激活，那现在这个循环就是过度活跃的。
[01:37:33 → 01:37:56] B 是啊。
[01:37:56 → 01:38:02] B 我得提醒自己：这不是限时抢购。AI 下个月还在，以后几个月也都在。我不能把它当成限时促销，想着必须在两周内收割完所有多巴胺。我觉得这其实是目前走在前列、最上头的人面临的主要挑战——要记住，正如那句老话，现在的 AI 已经是最差的了。
[01:38:02 → 01:38:16] A 对吧？你得想办法不被完全吞没，哪怕它再激动人心。
[01:38:17 → 01:38:27] A 嗯，这种吞噬感确实很严重。就像 Steve Yaghi，他看起来比之前更疲惫了——你在视频里也能看出来。但他很诚实，他确实被拉进去了。他有些朋友也是。当你处于前沿时，你就在那儿。
[01:38:27 → 01:38:48] B 你显然也吃了 AI 的药，那你如何保持平衡？比如，什么时候该抽身离开？我记得你以前谈过睡眠的重要性。你好像不用闹钟？
[01:38:48 → 01:39:07] B 对，我不设闹钟。不过现在我妻子用，因为孩子要按时上学。对我来说，每晚睡够八小时是给自己认知能力做的最好的投资。每次我没睡够八小时，都会提醒自己，那是很糟糕的交换。
[01:39:08 → 01:39:22] B 如果从八小时减到六小时，那我就得在剩下的十八小时里保持清醒。为了多挤出一两个小时而砍掉睡眠，我要为那十八小时背负多大的疲劳？这账怎么算都不划算，完全没道理。当然，偶尔也有身不由己的时候。
[01:39:22 → 01:39:40] B 实际上，尤其是在搞 AI 的时候，我有过几次——很少，十个手指头数得过来——失眠的经历。就是大脑转得太快了。这对我来说不常见，现在依然不常见。
[01:39:40 → 01:39:58] B 但确实有过几次，对吧？所以我理解那种兴奋从何而来，但我也想强调，你最不应该牺牲的就是睡眠，还有健康。你不该为了多做点智能体工作，省下每周三小时的锻炼时间。那太不划算了。
[01:39:58 → 01:39:59] A 保持好状态。如果你想保持头脑敏锐，那就得让整个系统——即便达不到峰值效率，至少也要维持一个良好可持续的水平。我认为现在有些人正面临精疲力竭的风险。
[01:39:59 → 01:40:09] B 没错。
[01:40:09 → 01:40:28] B 那就慢点来，伙计。这不是限时抢购。未来十年，我们会看到越来越多，越来越疯狂。所以别糟蹋自己的健康。
[01:40:29 → 01:40:41] A 别牺牲睡眠，别牺牲饮食，去为任何事服务。因为即使在短期内，也起不到作用。比方说，连续三周每晚少睡两三个小时，你觉得三周后还能保持连贯的思考吗？你会变成一锅粥的。
[01:40:41 → 01:40:53] A 那我们来收尾吧。我们谈了很多未知的东西。但最后聊聊你已知的。你本可以很早就退休，放松下来，听听鸟鸣。
[01:40:53 → 01:40:57] A 是什么让你继续做下去，继续构建，每天起床？在 AI 之前，你会打开终端——我记得你分享过，你会直接开始写代码。现在你用智能体了。是什么驱动着你？
[01:40:57 → 01:41:10] B 展望未来，有哪些事情让你兴奋？
[01:41:10 → 01:41:34] B 我开赛车、花很多时间陪孩子、享受生活，但如果每天要花八小时做一件事，那最好的选择就是电脑。我从五岁起就这样了——无论是打游戏，还是现在感觉有点像玩星际争霸那样，操控这些AI代理，指挥它们行动，做探索。
[01:41:35 → 01:41:35] A 探索。
[01:41:36 → 01:41:54] B 对，就是这样。所以我就是真的很喜欢电脑。不管我是否需要为了经济原因去搞它，我都会继续玩电脑，看看它们怎么运转，然后做出东西来。我觉得这也是很多人对财富的一个误解——他们以为财富是个终点站。
[01:41:54 → 01:42:20] B 好像一旦你成功了，就可以躺平、休闲，那就是幸福。可上百年的心理学研究告诉我们，不，那是痛苦。如果你有的是时间，却没有目标、没有使命，休闲根本没用。那不会让你感到充实。这道理其实显而易见——看看那些卖掉公司的创业者就知道了。
[01:42:20 → 01:42:32] B 他们在沙滩上躺三周，然后就又回来干事了，对吧？因为这不仅仅是为了某个目标去做的事，它本身就是目标，就是使命。
[01:42:32 → 01:43:03] B 这是满足感，是作为人类的自我确认——我不是一摊烂泥躺在那。我是一个有用的人，把自己的技能用到极致。所以我还会继续这样做，不管我是坐在键盘前打字，是操控这些代理，还是它们教我什么——无论哪种方式，我都想玩电脑，我就是要这么做。而具体来说，过去三个月之后，我现在特别倾向于代理的可用性。
[01:43:03 → 01:43:16] B 比如，这就是我过去几周在做的。我们在搞一个新的CLI（命令行界面），这也让我意识到，我们离通用人工智能还差得远，对吧？你会想：让代理直接给你做个CLI就好了。它会做，但还不到位。
[01:43:16 → 01:43:29] B 对吧？我希望它做得完美，代理们还是需要一点帮助。我很乐意帮它们，然后我们会很快发布一个很棒的Basecamp CLI。可能等你们听到这段时，它已经发布了。其他项目也一样，我要全力投入这一切。
[01:43:29 → 01:43:53] B 我们怎么能尽可能多地利用这些工具？另外，我现在也是个特别好奇的人。每天早上一醒来，我有一个新习惯——不再第一时间拿起手机刷X。我觉得那样其实不好，但要忍住需要巨大的意志力，因为我实在太想知道发生了什么。现在发生的事情太多了。
[01:43:53 → 01:44:03] B 我想知道，我想参与其中、享受其中。所以我觉得这股劲不会停。对电脑的热爱不会消失。
[01:44:04 → 01:44:12] B 事实上，如果要说有什么变化，我觉得现在这种热爱反而更旺了。我比五年前更喜欢电脑了，这真的很棒。
[01:44:13 → 01:44:17] A 太棒了。David，这次聊得真好。非常感谢。好了，谢谢邀请。
[01:44:17 → 01:44:34] A 这次真的非常棒。这是一场引人入胜的对话，我很喜欢David的这股劲。我希望这种在场时显而易见的能量也能感染到你们。我很欣赏David的坦诚——他对AI的立场之所以转变，不是因为他的哲学变了，而是因为工具变得足够好用，能做有用的事了。
[01:44:34 → 01:44:50] A 对于有经验的开发者来说，AI做自动补全很烦人。但AI代理能自己写出相当好用的代码，这就很有用了。然而David一直在强调品味、判断和手艺。他绝不是让模型随便写什么。恰恰相反。
[01:44:50 → 01:45:20] A 他的质量标准很高，他希望输出的是他真正愿意合并的代码。这感觉就像AI可能让好的判断力变得比以往更有价值。我也很喜欢David对设计重要性的看法。在37signals，设计师帮助确定要构建什么、如何工作，甚至越来越多地决定如何实现。我在想，37signals在思考设计师有点像开发者、开发者有点像设计师这一点上，是不是比行业领先了一步。
[01:45:20 → 01:45:29] A 最后，我觉得David关于“我们可能已经达到软件工程师峰值”的论点很有意思。他认为我们会比以往产出更多软件，但
[01:45:29 → 01:45:29] B 他的观察是，
[01:45:29 → 01:45:29] A 我们可能正在接近
[01:45:29 → 01:45:29] B 一个
[01:45:29 → 01:46:04] A 开发者不再能要求高薪的时代。但这将意味着，软件工程师不仅需要擅长编码或使用AI生成代码，还要能监督构建复杂系统，具备品味和商业嗅觉。如果你想听更多David的内容，请查看与他的加长版节目（链接在节目笔记中）。另外，节目笔记中还关联了关于Pridemantic引擎的深度内容，涉及软件工艺和构建软件的实用方法。
[01:46:04 → 01:46:04] B
[01:46:04 → 01:46:13] A 如果你喜欢这期播客，请在你常用的播客平台和YouTube上订阅。也特别感谢你为节目打分。谢谢，下期再见。
由 PodMate 自动翻译 (DeepSeek)