我 100% 的代码都是由 Claude Code 写的。从去年 11 月起，我没有手动编辑过一行代码。每天我会提交 10 个、20 个、30 个 PR。所以目前我大概同时开着五个 agent 在跑。就在我们录音的时候？对对对。你怀念写代码吗？我从未像今天这样享受编程，因为我不必再去处理所有细枝末节。每位工程师的生产力提升了 200%。大家总在问，我应该学编程吗？一两年后，这 将不再重要。编程几乎已经被解决了。我想象这样一个世界：每个人都能编程。任何人都可以随时构建软件。软件编写方式的下一个重大转变 是什么？Claude 开始自己出主意了。它会浏览反馈、查看 bug 报告、查看遥测数据来寻找要修复的 bug 和要发布的功能。它更像是一个同事之类的角色。很多听众是产品经理，他们可能正在冒汗。我觉得到今年年底，人人都会是产品经理，人人都会写代码。软件工程师这个头衔将开始 消失。它只会被 builder 取代，而这会让很多人感到痛苦。今天的嘉宾是 Boris Cherny，Anthropic 的 Claude Code 负责人。很难描述 Claude Code 对世界产生的影响。 在这期节目发布前后，恰逢 Claude Code 发布一周年。在短短一年时间里，它彻底改变了软件工程师的工作。现在它也开始改变科技行业许多其他岗位的工作，我们稍后会谈到。Claude Code 本身也是 Anthropic 过去一年整体增长的重要推动力。他们刚刚完成了一轮估值超过 3500 亿美元 的融资。正如 Boris 提到的，Claude Code 本身的增长仍在加速。就在过去一个月，他们的日活用户翻了一番。Boris 本人也是一个非常有趣、有思想、有深度的人。在这次对话中，我们发现我们出生在乌克兰的同一座城市。这太有趣了，我之前完全不知道。非常感谢 Ben Mann、Jenny Wen 和 Mike Krieger 为这次对话推荐话题。别忘了访问 Lenny's Product Pass dot com，那里有为 Lenny 的 newsletter 订阅者提供的独家超值优惠。让我们先短暂休息一下，听听我们精彩赞助商的留言，然后进入正题。本期节目由 DX 赞助，DX 是一个由顶尖研究者设计的开发者智能平台。要在 AI 时代蓬勃发展，组织需要快速适应。但许多组织领导者难以回答一些紧迫的问题： 哪些工具在起作用？它们是如何被使用的？到底是什么在驱动价值？DX 提供领导者所需的数据和洞察，以驾驭这一转变。借助 DX，Dropbox、Booking.com、Adyen 和 Intercom 等公司能够深入理解 AI 如何为他们的开发者创造价值，以及 AI 对工程生产力产生了什么影响。想了解更多，请访问 DX 网站 getdx.com/lenny。也就是 getdx.com/lenny。应用会以各种方式崩溃：宕机、变慢、回归，以及那些只有在真实用户出现后才能发现的问题。Sentry 能捕获所有这些问题。看清发生了什么、在哪里发生、以及为什么发生。精确到引入错误的提交、提交它的开发者，以及具体的那一行 代码，所有信息都在一个统一的视图中。我绝对试过开五个标签页、在 Slack 里刷线程来调试。这种方式更好。Sentry 向你展示请求是如何流转的、什么在运行、什么变慢了、用户看到了什么。Sear，Sentry 的 AI 调试 agent，会接手后续工作。它利用所有 Sentry 的上下文信息来告诉你根本原因、建议修复方案，甚至为你打开一个 PR。它还会审查你的 PR， 标记出任何破坏性变更，并准备好修复方案。免费试用 Sentry 和 Sear，请访问 sentry.io/lenny，并使用优惠码 Lenny 获得 100 美元的 Sentry 额度。也就是 sentry.io/lenny。Boris，非常感谢你来到这个节目。感谢邀请。我想从一个尖锐的问题开始。大约六个月前，我不知道大家还记不记得，你其实离开了 Anthropic，加入了 Cursor，然后两周后又回到了 Anthropic。发生了什么？我想我还没听过真实的故事。这是我换工作最快的一次。我加入 Cursor 是因为我是这款产品的超级粉丝。说实话，我见了那支团队，印象非常深刻。他们是一个很棒的团队。我现在仍然觉得他们很赞，他们正在构建非常酷的东西。而且我觉得他们在 AI 编程的发展方向上，比很多人看得都更远。所以构建一个好产品的想法让我非常兴奋。但我一到那里，就开始意识到，我真正怀念 Anthropic 的是它的使命。这其实也是最初吸引我加入 Anthropic 的原因。因为在加入 Anthropic 之前，我在大型科技公司工作，后来有段时间我想加入一家实验室，以某种方式帮助塑造我们正在构建的这个疯狂东西的未来。吸引我加入 Anthropic 的是它的使命，也就是安全。当你在 Anthropic 随便找个走廊上的人聊聊，问他们为什么在这里，答案永远都会是安全。所以这种使命驱动感真的、非常打动我，而且我个人知道，这是我获得幸福感所需要的东西。我发现，无论工作内容是什么，不管多令人兴奋，哪怕是在构建一个非常酷的产品，它都无法真正替代那种使命感。所以对我来说，很明显，我很快就意识到自己怀念的是什么。好的，那让我顺着这个话题，回到 Anthropic 和你在那里做的工作。这期播客发布时，恰逢 Claude Code 推出一周年。所以我想花点时间回顾一下你们产生的影响。最近有一份 SemiAnalysis 的报告，我相信你肯定看到了，报告显示现在 GitHub 上 4% 的提交都是由 Claude Code 完成的。他们预测到今年年底，GitHub 上五分之一的代码提交都将来自它。他们的说法是："就在我们眨眼的工夫，AI 吞噬了整个软件开发。" 我们录音的这一天，Spotify 刚刚发布了一则消息，说他们最优秀的开发者从去年 12 月起就没写过一行代码，全靠 AI。越来越多最先进的高级工程师，包括你在内，都在分享自己不再写代码的事实，所有代码都是 AI 生成的，而且很多人甚至不再看代码了——这就是我们已经走到的程度。很大程度上，这要归功于你和你的团队在过去一年里发起并做大的这个小项目。我很想听听你对过去一年以及你的工作所产生影响的反思。这些数字真的太疯狂了，对吧？全世界 4% 的提交，这远超我的想象。而且就像你说的，这仍然感觉只是一个起点。这些还只是公开的提交。所以我们认为，如果去看私有仓库，实际比例要比这高得多。而对我来说最疯狂的不是我们目前的数字，而是我们的增长速度，因为如果你看 Claude Code 在各种指标上的增长率，它正在持续加速。所以，它不只是增长，而是增长得越来越快。最初开发 Claude Code 时，它只是个小实验，本来只是想随便 hack 一下。你知道，在 Anthropic，我们大致知道想推出某种编程产品。长期以来，我们在 Anthropic 一直按照某种心智模型来构建模型，即我们构建 safe AGI 的方式：模型先变得非常擅长编程，然后变得非常擅长工具使用，再变得非常擅长计算机使用。大致上，这就是发展轨迹。你知道，我们为此已经努力了很长时间。看看我当初加入的团队，它叫 Entropic Labs。实际上，Mike Krieger 和 Ben Mann 最近又重启了这个团队，算是第二轮。这个团队做了一些很酷的东西：我们做了 QuadCode，做了 MCP，做了桌面应用。所以你能看到这个想法的雏形——先是编程，然后是工具使用，再是计算机使用。这对 Entropic 之所以重要，是因为安全。这又回到那个问题：AI 越来越强大，能力越来越强。过去一年发生的事情是，至少对工程师而言，AI 不只是写代码，它不只是对话伙伴，而是真正使用工具，在世界上采取行动。我认为现在有了 Co-work，我们也开始看到非技术人员的转变。对于很多使用对话式 AI 的人来说，这可能是他们第一次使用真正能行动的东西。它真的能使用你的 Gmail，使用你的 Slack，能帮你做所有这些事，而且做得相当好。而且只会越来越好。所以，长期以来 Entropic 一直有种感觉，想做出点什么，但具体做什么并不明显。因此，当我加入 Anth 时，我花了一个月时间搞些 hack，做了一堆奇怪的原型。大多数都没上线，甚至离上线差得远，只是为了理解模型能力的边界。然后我花了一个月做 post-training，以便理解这方面的研究侧。说实话，作为工程师，我发现要做好工作，你必须理解你所工作的层级之下的那一层。在传统工程工作中，如果你在做产品，你要理解基础设施、runtime、虚拟机、语言，诸如此类，你所构建的系统底层。但如果你在 AI 领域工作，你必须在某种程度上理解模型，才能做好工作。所以我绕了点路去做那件事，然后回来开始原型设计，最终做出了 QuadCode。最早的那个版本有一段我夏天录的视频，因为我录了这个 demo 并发到了网上。当时它还叫 Quad CLI。我只是展示了它如何使用几个工具。让我震惊的是，我给了它一个 bash tool，当我问它“我在听什么音乐”时，它竟然能用它来写代码，然后告诉我答案。这是最疯狂的事，对吧？因为我并没有指示模型说“用这个工具来做这件事”或做任何事。模型被赋予这个工具后，自己想出了怎么用它来回答我的问题，而我甚至不确定我能否回答“我在听什么音乐”这个问题。于是我开始更多地做这个原型。我发了帖子，在内部宣布，只得到两个赞。那两个赞就是当时的全部反响。因为内部人员想到编程工具时，想到的是 IDE，是那些相当复杂精致的开发环境。没人想到这东西能基于终端。这种设计方式挺奇怪的，而且本来也不是有意为之。但从一开始我就在终端里构建它，因为头几个月只有我一个人，所以这是最简单的构建方式。这对我来说其实是很重要的产品教训：在开始时，你要刻意少投入一点资源。然后我们开始思考该做其他什么形态的产品，实际上决定暂时坚持终端形态。最大的原因是模型进步太快了，我们认为没有其他产品形态能跟得上它。说实话，这只是我在纠结我们该做什么——过去这一年我满脑子想的都是 QuadCode。所以深夜时我都在想，模型在持续进步，我们该怎么办？怎么才能跟上？说实话，终端是我唯一能想到的主意。然后它竟然流行起来了。发布之后，它很快在 Anthropic 内部走红，日活跃用户直线飙升。其实很早，在我正式发布之前，Ben Mann 就劝我做个 DAU 图表。我当时觉得还早，真的有必要现在做吗？他说有必要。然后图表几乎立刻就垂直上升了。接着在二月份，我们对外发布了。其实大家不太记得的是，Quad Code 最初并不算成功。发布时确实吸引了一批用户，有很多早期采用者立刻就理解了。但实际上花了很多个月，大家才真正理解这东西是什么。因为它太不一样了。我想，Quad Code 能成功的一部分原因在于 latent demand，我们把工具带到人们所在的地方，让现有工作流稍微轻松一点。但也因为它在终端里，有点令人意外，有点陌生。所以你必须心态开放，必须学习使用它。当然现在，Quad Code 已经可以在 iOS 和 Android 的 Quad 应用里使用，在桌面应用、网站上都能用，在 Slack 和 GitHub 里也有编辑扩展，在所有工程师出没的地方都有。它变得更熟悉了一些。但那不是起点。所以一开始，这东西竟然有用，本身就挺让人意外的。随着团队壮大，产品成长，它对人们越来越有用，全世界的人，从小型初创公司到最大的 FAANG 公司，都开始使用它并给出反馈。回顾起来，这是段非常谦卑的经历，因为我们一直在向用户学习。最激动人心的是，其实我们没人真正知道自己在做什么，我们只是和大家一起摸索，而最好的信号就是用户的反馈。这就是最棒的地方。我被惊喜了很多次。当今世界，事物变化之快令人难以置信。你一年前发布了这个，这并非人们首次用 AI 编程，但一年时间，整个软件工程职业已经发生了巨大变化。有各种预测说，代码将 100% 由 AI 编写。大家都说，不，那太疯狂了，你在说什么？我当时就想，哦，当然，事情正在按照他们所说的那样发展。只是现在一切都变得太快了。是的，真的很快。回想今年五月的 Code with Claude，那是我们 Anthropic 举办的第一次开发者大会。我做了一个简短的演讲，在演讲后的问答环节，有人问我对年底的预测是什么。我在2025年五月的预测是，到年底，你可能不再需要 IDE 来编写代码了。我们将开始看到工程师不再这样做。我记得当时全场都倒吸了一口凉气。这是一个非常疯狂的预测。但我认为在 Anthropic，我们思考事物的方式就是指数级的。这深深植根于我们的 DNA 中。如果你看看我们的联合创始人，其中三位是 scaling laws 论文的前三位作者。所以我们真的就是用指数思维来思考。如果你观察当时由 Claude 编写的代码百分比的指数增长，只要你画出那条线，很明显我们将在年底突破100%，即使这完全不符合直觉。所以我所做的只是画出那条线，是的，在十一月，就我个人而言，那件事发生了，从那以后一直如此，而且我们开始在很多不同的客户身上也看到这种情况。我觉得你刚才分享的这段历程非常有趣。就是这种“先随便试试，看看会发生什么”的想法吗？这在 Open Claude 的故事中经常出现，就像 Peter 当时也是在随意尝试，然后某件事就发生了。感觉这正是 AI 领域许多重大创新的核心要素——人们只是坐在那里尝试各种东西，把模型推得比大多数人都远。我的意思是，这就是创新，对吧？你无法强迫它。创新没有路线图。你只需要给人们空间。也许应该用的词是安全感。就是心理安全感，让人们知道失败是可以的。80% 的想法是糟糕的也没关系。你也要让他们负一些责任。所以如果想法不好，你要及时止损，转向下一个想法，而不是投入更多。在 Claude code 的早期，我完全不知道这东西是否有用。因为即使在二月我们开始的时候，它可能只写了我的20%的代码，不超过这个数。即使在五月，它可能也只写了30%。我大部分代码仍在用 Cursor。直到十一月才突破100%。所以花了一段时间，但从最开始，我就感觉我摸到了门道，我每个晚上、每个周末都在捣鼓这个。幸运的是，我妻子非常支持。但我就是感觉这事儿有戏。具体是什么并不明显。然后有时候，你找到了一条线索，你就得顺着它往下拉。那么，现在100%的代码都是由 Claude code 写的了吗？这就是你目前编程的状态吗？是的，我100%的代码都是由 Claude code 写的。我是一个相当高产的程序员。即使在 Instagram 工作时也是如此，我是那几位最高产的工程师之一。实际上在 Anthropic 这里仍然如此。哇，即使作为团队负责人。是的，是的。我仍然大量写代码。所以每天，我都会提交大概10、20、30个 pull request 左右。每天？每天。是的。天哪。100%由 Claude code 编写。自从十一月以来，我没有手动编辑过一行代码。是的，就是这样。我确实会查看代码。所以我认为我们现在还没到可以完全放手不管的阶段，特别是当有很多人在运行这个程序时。你必须确保它是正确的。你必须确保它是安全的等等。而且我们也让 Claude 对所有代码进行自动审查。所以在 Anthropic，Claude 审查100%的 pull request。之后仍然有一层人工审查，但你还是会想要这些检查点的。你仍然希望有人能查看代码，除非它是纯原型代码，你知道，它不会在任何地方运行。它只是个原型。下一个前沿是什么？现在，你100%的代码都由 AI 编写。这显然是软件工程领域每个人都将走向的方向。那曾感觉是一个疯狂的里程碑。现在则变成了，当然，这就是现在的世界。在软件编写方式上，下一个重大转变是什么？无论是你的团队已经在实践的，还是你认为将会走向的？我认为目前正在发生的一件事是，Claude 开始提出想法了。Claude 会浏览反馈，查看 bug 报告，查看遥测数据之类的东西，然后开始提出修复 bug 和要发布功能的思路。所以它开始变得更像是一个同事之类的角色了。我认为第二件事是，我们开始稍微跳出编程这个领域了。所以我认为此刻可以很有把握地说，编程实际上已经解决了。至少对我做的这类编程来说，这已是一个已解决的问题，因为 Claude 能做到。所以现在我们开始思考，好吧，下一步是什么？这之外还有什么？有很多与编程相邻的事情，我认为这也会到来，而且也包括日常事务。比如我现在每天都用 Claude 来处理各种与编程完全无关的事情，让它自动完成。比如前几天我有一张停车罚单要交，我就让 Claude 去处理了。我所有的团队项目管理，Claude 全部包办。比如在电子表格之间同步数据、在 Slack 上给人发消息、处理邮件等等。所以我认为前沿是这样的。而且我不认为前沿是编程，因为我觉得编程已经基本解决了，在未来几个月里，我认为我们将看到的是，在整个行业中，编程将越来越被解决，适用于每一种代码库、每一种人们使用的技术栈。这种帮助你想出该做什么的想法非常有趣。很多听众是产品经理，他们可能正在冒汗。你怎么用 Claude 来做这件事？你只是跟它对话吗？你有没有想出什么巧妙的方法，用它来帮你决定该构建什么？说实话，最简单的方法就是打开 Claude Code，把它指向一个 Slack 帖子。你知道，就像我们有一个频道，里面全是关于 Claude Code 的内部反馈。自从我们首次发布它以来，甚至在2024年内部使用时，反馈就如洪水般涌来。而这太棒了。在早期，每当有人发送反馈，我就会进去，尽我所能快地修复每一个问题。比如在一分钟内，五分钟内，或者类似的时间。这种非常快的反馈循环鼓励人们给出越来越多的反馈。这非常重要，因为这让他们感到被倾听。因为通常当你使用一个产品时，你给出反馈，它就掉进了某个黑洞，然后你就不再反馈了。所以如果你让人们感到被倾听，他们就会想要贡献，想要帮助把产品做得更好。所以现在我也做类似的事情，但老实说，Claude 承担了大部分工作。于是我把它指向那个频道，它就说：“好的，这儿有几件事我能做。我刚提了几个 PR，要看看吗？”我说：“好啊。”你有没有注意到它在这方面越来越强了？因为这某种程度上就是圣杯。现在就像是，构建问题已经解决了，酷。代码审查成了下一个瓶颈。这么多 PR，谁来审？下一个重大的开放性问题就是：好吧，现在需要人类来决定该构建什么、该优先处理什么。而你说 Claude Coder 正是在这个方面开始帮到你。它是不是进步很大，比如说 Opus 4.6，或者这方面的轨迹是怎样的？是的，进步很大。我觉得一部分原因是我们针对编程做的专门训练。显然，它是世界上最好的编程模型，而且越来越好了。比如 4.6 就简直不可思议。但实际上我们在编程之外做的很多训练也迁移得很好。所以存在一种迁移效应：你教模型做 X，然后它在 Y 上也变强了。是的，提升简直太疯狂了。比如在 Anthropic，过去一年里，自从我们推出 Quad Code 以来，我们可能——我不知道确切数字——把工程团队扩大了四倍左右。但每个工程师的产出按 PR 算提高了 200%。这个数字对任何真正在这个领域工作、关注开发效率的人来说都太疯狂了。因为我以前在 Meta 工作，当时我的一项职责是负责全公司的代码质量。就是我们所有的代码库，像 Facebook、Instagram、WhatsApp 这些，都在我的职责范围内。其中很多都关乎效率，因为如果你让代码质量更高，工程师就会更高效。我们看到的情况是，一年里有几百名工程师在上面工作，你可能只会看到几个百分点的效率提升，差不多这样。所以现在看到这种几百个百分点的提升，简直太疯狂了。同样疯狂的是这一切已经变得多么习以为常。就像我们听到这些数字，觉得“当然，AI 正在对我们做这些”。但对软件开发、产品构建乃至整个科技界来说，这种变化量是前所未有的。人们太容易习惯它了，但重要的是要认识到这很疯狂。这是我得时不时提醒自己的一件事。这也有点 downside，因为模型变化太……其实有很多我们可以聊的 downsides。但我认为其中一个很个人层面的问题是，模型变化太快了，我有时候会陷入一种旧的思维模式。我甚至发现团队里的新人，甚至刚毕业的应届生，做事方式比我更 AGI forward。比如几个月前我就遇到这种情况，当时 Quad Code 有个内存泄漏。内存使用量不断上升，最后就崩溃了。这是非常常见的工程问题，每个工程师都调试过无数次。传统做法是，你拍一个堆快照，放到专门的调试器里，搞清楚发生了什么，就是用这些专门的工具来看情况。我当时就在做这个，查看这些追踪记录，试图搞清楚发生了什么。而团队里一个资历更浅的工程师直接用 Claude 写代码。就像是：“嘿 Claude，好像有泄漏，你能搞定吗？”
然后 Claude code 做了和我完全一样的事。它拍了堆快照，给自己写了个小工具来分析，有点像是一个即时生成的程序。然后它找到了问题，并且比我更快地提了一个 PR。所以，对于我们这些用模型很久的人来说，你仍然得让自己跟上当下，不要被困在旧模型里，因为现在已经不是 Sonnet 3.5 的时代了。新模型已经完全完全不一样了。这种思维转变也很不一样。我听说你给团队制定了一些非常明确的原则，新人加入时你会带着他们过一遍。我记得其中一条是，有什么比自己做更好的？让 Claude 做。感觉你描述的这个内存泄漏的情况就是这样，你几乎忘了那条原则：好吧，我来看看 Claude 能不能帮我解决。还有一件有意思的事，当你给每个项目的资源都稍微少一点时，人们就会被迫去 Claudify。这是我们观察到的现象。有时候我们只放一名工程师在一个项目上，而他们之所以能快速交付，是因为他们自己想快，这是一种内在的驱动力。你就是想把事情做好。首先，如果你有个好想法，你就真的很想把它做出来。没人逼你，这是发自内心的。所以，如果你有 Claude，你就可以用它来自动化很多工作。这就是我们反复看到的情况。所以我觉得一个原则就是给资源时稍微紧一点。另一个原则就是鼓励大家再快一点。就是如果今天能做，就今天做。这是我们在团队里非常推崇的。早期这非常重要，因为当时就我一个人。所以我们唯一的优势就是速度。那是在竞争极其激烈的编程市场里，我们唯一能推出产品的方式。但时至今日，这仍然是我们团队非常重要的原则。而如果你想更快，一个很好的办法就是让 Claude 做更多事。所以这非常鼓励这种做法。这个“资源紧一点”的想法很有意思，因为通常大家觉得 AI 会让你不需要那么多员工、那么多工程师。所以，不只是你能更高效，你的意思是如果资源给得紧一点，你实际上会做得更好。不只是 AI 能让你更快，而是如果做某件事的人更少，你能从 AI 工具里榨出更多价值。是的，如果你招了优秀的工程师，他们会想办法做到的。特别是如果你授权他们去做。这其实是我经常跟 CTO 还有各类公司聊的事。我的建议通常是：不要一开始就试图优化，不要试图削减成本。先从给工程师尽可能多的 token 开始。现在你也开始看到一些公司这样做，比如在 Anthropic，每个人都能用很多 token。我们开始看到这在一些公司变成了福利。比如入职就送无限 token。这是我非常鼓励的，因为这让人们敢于去尝试那些原本太疯狂的想法。然后如果某个想法奏效了，你再想办法扩展它。到了那个阶段再去优化、去削减成本，比如想想看也许你可以用 Haiku 或 Sonnet 而不是 Opus 来做，诸如此类。但在一开始，你就是想往里面砸大量 token，看看这个想法能不能跑通。要给工程师自由去做这件事。所以这里的建议是，在使用这些模型时，对 token 的花费宽松一点。听到这话的人可能会想，当然啦，他在 Anthropic 工作，肯定希望我们尽可能多用 token。但你想说的其实是，最有趣、最具创新性的想法，往往来自某个人把它用到极致，看看能做出什么来。是的，而且我觉得实际情况是，在小规模下，你不会收到什么巨额账单之类的。如果是个别工程师做实验，token 成本相对于他们的薪水，或者相对于企业运营的其他成本来说，应该还是相对较低的。所以这其实不算很大的开销。等到规模上去之后——比如说他们做出了很厉害的东西，然后需要消耗大量 token，成本变得相当高——那时候你才需要去优化。但别太早做这件事。你有没有见过哪家公司的 token 成本比工资还高的？你觉得这会是我们即将看到的趋势吗？你知道，在 Anthropic，我们已经看到一些工程师每月在 token 上的花费达到几十万。所以我们已经开始看到一点这种迹象了。也有一些公司，我们开始看到类似的情况。是的。回到写代码这件事。你怀念写代码吗？不再以软件工程师的身份写代码了，你会不会有点伤感？对我来说挺有意思的，我学工程的时候是非常务实的。我学工程是为了能做出东西。而且我是自学的。我在学校学的是经济学，没学计算机科学，但我很早就开始自学工程了。初中的时候我就在编程。从一开始就非常务实。实际上，我学写代码是为了在数学考试中作弊。这是第一件事。我们有那种图形计算器，你知道，我就把答案输进去——TI-83？TI-83 Plus。对对，没错。Plus。所以我把答案输进去，然后下一次数学考试，大概第二年吧，题太难了，我没法把所有答案都输进去，因为我不知道题目是什么。所以我得写一个小型求解器，就是一个程序，能解这些代数题之类的。然后我发现，你可以买一根小线缆，把这个程序传给全班同学，然后全班都能拿 A。但后来我们被抓了，老师让我们别搞了。但从最开始，编程对我来说就一直是非常务实的，它是做出东西的一种方式，不是目的本身。在某个阶段，我个人也陷入了编程之美这个兔子洞。所以我写了一本关于 TypeScript 的书。我发起了当时全球最大的 TypeScript 聚会，就是因为爱上了这门语言本身。我还深入研究了函数式编程之类的东西。我觉得很多程序员会被这些分心。对我来说，编程确实有一种美感，尤其是函数式编程。类型系统也有它的美。当你解决了一道非常复杂的数学题时，会有一种很爽的感觉，当你把类型平衡好，或者程序写得非常优雅时，也是类似的感觉。但这真的不是最终目的。我觉得对我来说，代码很大程度上是一种工具，是做事的一种方式。不过话说回来，不是所有人都这么想。比如说，我们团队里有个工程师叫 Lena，她周末还在手写 C++，因为对她来说，她就是很享受手写 C++ 的过程。所以每个人都不一样。而且我觉得即使在这个领域发生变化，即使一切都在变，也总有空间去做这件事。总有空间去享受这门艺术，去亲手做事，如果你想的话。你担心作为工程师的技能会退化吗？你会担心这个吗，还是说你觉得，事情就是这样发展的？我觉得事情就是这样发展的。我个人对此并不过于担心。我觉得对我来说，编程是一个连续统。很久以前，软件其实还算是比较新的东西，对吧？你看今天写程序的方式，用运行在虚拟机上的软件之类的，我们从大概 1960 年代就开始这样写程序了。所以也就是大概 60 年左右。再之前是打孔卡，再之前是开关，再之前是硬件。再之前就是字面意义上的纸笔了。就是一屋子人在纸上做数学运算。所以编程一直以这种方式在演变。从某种程度上说，你仍然想了解底层之下的那一层，因为这能让你成为更好的工程师。而且我觉得接下来大概一年左右可能还是这样。但很快这就没什么关系了。它会有点像程序下面跑的 assembly code 之类的东西。在情感层面上，你知道，我觉得我一直都得学习新东西。作为程序员，这其实不觉得有多新鲜，因为总有新框架，总有新语言。这是我们这个行业里习以为常的事。但与此同时，你知道，不是所有人都这样。我觉得对一些人来说，他们可能会感受到更强烈的……我不知道，也许是失落、怀旧，或者退化之类的感觉。不知道你看到没有，Elon 说，为什么 AI 不直接写二进制？毕竟所有这些编程抽象最终意义何在呢？是啊，这是个好问题。我的意思是，如果你愿意，它完全可以那么做。天哪。那么，我从这里听到的是，关于“我该学编程吗？在校生该学编程吗？”这类问题，我听到你的观点是，大概一两年之后，你就不需要了。我的观点是，对于那些今天在用 quad code、用 agents 来编程的人来说，你仍然需要理解底层。但没错，一两年之后这就没关系了。我在想，这件事最合适的历史类比是什么？因为某种程度上，我们得把它放在历史中去定位，弄清楚我们以前什么时候经历过类似的转变？正确的思维模型是什么？我觉得对我来说最接近的是印刷机。你看，在 15 世纪中期的欧洲，识字率其实非常低。不到 1% 的人口是抄写员，他们负责所有的书写，负责所有的阅读。他们被领主和国王雇佣，而那些领主和国王自己往往也不识字。所以，这是这极少数人口的工作。然后在某个时刻，古腾堡和印刷机出现了。有一个惊人的数据：印刷机诞生后的50年里，印刷品数量超过了此前一千年的总和。因此，印刷品数量大幅激增，成本则急剧下降。在接下来的50年里，成本下降了约100倍。而看识字率的话，其实花了很长时间，因为学会读写相当困难，这需要教育体系，需要空闲时间，需要你不必整天在农场劳作，从而有时间接受教育等等。但在接下来的200年里，全球识字率上升到了约70%。所以我认为，我们可能会看到类似的转变。还有一份很有趣的历史文献，是15世纪对一位抄写员的采访，问他对印刷机怎么看。那位抄写员其实非常兴奋，说：我不喜欢做的是在书之间抄写，我喜欢的是在书里绘制插图，还有书籍装订。我很高兴现在我的时间被解放出来了。这很有趣，作为一名工程师，我感到一种共鸣。我也是这种感觉：再也不用做那些繁琐的编码工作了。因为这向来是其中的细枝末节，向来是枯燥的部分，就像对着代码瞎折腾，使用各种不同的工具。那并不是有趣的部分。有趣的部分是弄清楚要构建什么，是提出构想，是与用户交流，是思考这些大型系统，是思考未来，是与团队中的其他人协作。而现在我可以做更多这些事了。而令人惊叹的是，你正在构建的工具让任何人都能做到这一点。没有任何技术背景的人也能做到你描述的这一切。比如我一直在做各种随机的小项目，每当你卡住的时候，只要说“帮我解决这个问题”，你就豁然开朗了。我职业生涯早期曾做了10年工程师，只记得花了大量时间在库、依赖和各种小事上，只会想“天哪，我该怎么办？”然后去 Stack Overflow 上找答案。而现在就是“帮我解决这个问题”，然后得到一步一步的1、2、3、4。好了，搞定了。是的，完全正确。我今天早些时候还在和一位工程师聊天，他们在用 Go 写某个服务，已经弄了一个月，服务已经搭起来了，运行得相当不错。然后我问：“那你用 Go 写感觉怎么样？”他说：“其实我还是不太懂 Go，但是……”（笑声）我认为我们会越来越多地看到这种情况。就是说，如果你知道它能正确且高效地运行，那你其实不必了解所有细节。显然，软件工程师的工作已经发生了巨大变化。就在过去一两年里，这几乎变成了一份全新的工作。你认为下一个最受 AI 影响的会是什么角色？是在科技行业内部，比如产品经理、设计师，还是科技行业之外？你觉得 AI 接下来会走向哪里？我认为会轮到很多与工程相邻的岗位。是的，可能是产品经理，可能是设计，可能是数据科学。它会扩展到几乎所有能在电脑上完成的工作，因为模型在这方面会变得越来越好。这个 co-work 产品可以说是实现这一目标的第一步，但这只是第一步。我认为它把 agentic AI 带给了那些以前从未真正使用过 AI 的人，人们才刚刚开始第一次感受到它。回想一年前的技术工程领域，没人真正知道 agent 是什么，没人真正用过它，但如今这已经成了我们工作的方式。而当我看到今天的非技术工作，或者说半技术性的工作，比如产品工作、数据科学等，人们使用的 AI 总是这些对话式 AI，像是聊天机器人之类的，但没人真正用过 agent。而且 agent 这个词被到处乱用，滥用到了几乎失去所有意义的地步。但 agent 其实有一个非常特定的技术含义：它是一个 AI，是一个能够使用工具的 LLM。所以它不只是说话，它实际上可以行动，可以与你的系统交互。这意味着它可以使用你的 Google Docs，可以发邮件，可以在你的电脑上运行命令，做各种诸如此类的事情。所以我认为，任何以这种方式使用电脑工具的工作，都会是下一个。这是我们作为一个社会必须去解决的问题，也是作为一个行业必须去解决的问题。对我来说，这也是我觉得在 Anthropic 做这项工作非常重要且紧迫的原因之一，因为我们对此非常、非常认真。所以我们现在引入了经济学家、政策专家、社会影响方面的专家。我们就是想多讨论这件事，这样整个社会才能一起 figuring out 该怎么做，因为这不应该由我们说了算。所以你暗示的那个大问题，就是就业和失业之类的事。有一个概念叫 Jevons paradox，即随着效率提高、我们能做的更多，我们反而雇佣更多人，事情实际上并不像看起来那么可怕。随着 AI 成为工程工作中的重要组成部分，你到目前为止有什么体会？你们是否在招聘比没有 AI 时更多的人？以及对就业有什么看法？是的，我们团队在招人。Claude Code 团队在招人。如果你有兴趣，可以查看 Anthropic 的招聘页面。就我个人而言，所有这些只是让我更享受工作了。我从未像今天这样享受编码，因为我不必再处理所有细枝末节。所以对我个人来说，这相当令人兴奋。很多客户也跟我们反馈，他们热爱这个工具，热爱 Claude Code，因为它让编程重新变得令人愉悦。这对他们来说太有趣了。但很难知道这件事会走向何方，我再次觉得，我只能去借鉴这些历史类比。我认为印刷术就是一个很好的类比，因为这项技术原本只掌握在少数人手中——比如读写能力——后来变得人人可及。它本质上是民主化的。每个人都能开始做到这件事。如果不是这样，文艺复兴这样的事情根本不可能发生，因为文艺复兴很大程度上关乎知识的传播，关乎人们用来交流的书面记录。当时没有电话之类的东西，也没有互联网。所以问题在于，这接下来会催生出什么？我认为这就是对我而言非常乐观的版本，也是让我真正兴奋的部分。这简直无法想象。如果没有印刷术的发明，我们今天根本不可能这样交谈。我们的麦克风不会存在，我们周围的一切都不会存在。如果不是这样的话，就不可能协调这么大一群人。因此，我想象未来几年后的世界，人人都能编程。这会解锁什么？任何人都可以随时构建软件。我完全说不上来。就像15世纪时，没人能预见到今天一样。我认为情况是一样的。但我确实觉得，在此期间，这将非常具有颠覆性，对很多人来说会很痛苦。作为社会，这是我们必须要进行的对话，也是我们必须共同解决的问题。那么，对于听到这里、希望在我们进入的这场疯狂变局中取得成功的人，有什么建议吗？是多玩玩 AI 工具，熟练掌握最新的东西？还有别的建议能帮助人们保持领先吗？是的，我想基本上就是这样。去实验这些工具，熟悉它们，不要害怕。直接投入进去，尝试它们，走在 bleeding edge，站在 frontier。第二条建议可能是，尽量比过去更成为一个通才。比如，在学校学计算机科学的人，很多人只学了编程，别的没学什么。也许学了一点系统架构之类的东西。但我每天共事的一些最高效的工程师，以及一些最高效的产品经理等等，他们都是跨学科的。所以在 Cloud Code 团队里，每个人都会写代码。我们的产品经理写代码，工程经理写代码，设计师写代码，财务同事写代码，数据科学家写代码。团队里每个人都会写代码。如果看具体的工程师，人们经常跨越不同学科。一些最强的工程师是混合型的产品和基础设施工程师。或者是产品工程师，但有非常好的设计判断力，也能做设计。或者是商业嗅觉很好的工程师，能据此判断下一步该做什么。又或者是喜欢和用户交流的工程师，能真正传达用户的需求，从而决定下一步方向。所以，我认为未来几年最会获得回报的人，他们不仅会是 AI native，不仅知道如何很好地使用这些工具，而且他们好奇心强，是通才，横跨多个学科，能思考他们正在解决的更广泛的问题，而不仅仅是工程部分。你觉得工程、设计、产品管理这三个独立的学科，作为思考团队的方式还有用吗？你觉得即使他们现在都在写代码，都在参与构建的思考，这三个角色至少在现阶段还会长期存在吗？我认为短期内还会继续存在，但我们开始看到，这些角色之间可能有50%的重叠，很多人实际上在做同样的事，只是有些人有专长。比如，我写代码多一些，或者产品经理多做一些协调、规划、预测之类的事。利益相关方对齐。利益相关方对齐。没错。我确实认为未来——我想到今年年底我们就会开始看到——这些界限会变得越来越模糊，有些地方软件工程师这个头衔会开始消失，取而代之的是 builder，或者可能人人都会成为产品经理，而且人人都会写代码，类似这样的局面。谁说招聘必须公平？最近和我交谈过的每位创始人和招聘负责人都面临着同样的压力：尽快招到最优秀的人，但招聘耗时耗力，团队对齐困难，对优秀人才的竞争也越来越激烈。正因如此，11 Labs、Brex、Replit、Deel 以及另外5000多个组织都在使用 Metaview——这家 AI 公司让高性能团队在招聘中获得真正的不公平优势。他们提供一套行为像招聘同事一样的 AI agent。它们根据你的精确标准为你寻找候选人，自动记录面试笔记，在整个招聘流程中收集洞察，并帮助你识别 pipeline 中最合适的候选人。AI 处理招聘中的繁琐工作，为你提供真正的 single source of truth。这意味着每招一个人能节省数小时，团队可以专注于最重要的事：赢得合适的候选人。别让你的竞争对手在招聘上超过你。Metaview 的客户填补职位的速度提高了30%。今天就免费试用 Metaview，并在 metaview.ai/lenny 获得额外一个月的 sourcing 服务。拼写是 m e t a view.ai/lenny。你谈到你现在写代码写得更开心了。我其实在 Twitter 上做了一个非正式的小调查。不知道你有没有看到，我做了三个不同的投票。我问工程师们，自从使用 AI 工具以来，你是更喜欢还是更不喜欢自己的工作了？然后我又分别对产品经理和设计师做了调查。工程师和产品经理中都有70%的人说他们更喜欢自己的工作了，大约10%的人说更不喜欢了。有趣的是，设计师中只有55%的人说更喜欢，20%的人说更不喜欢了。我觉得这很有意思。这太有意思了。我很想跟这些人聊聊，不管是“更喜欢”那组的还是“更不喜欢”那组的，就是想了解一下。你有没有跟进过其中一些人？有几个人回复了，我们实际上还在做一个后续投票，会把链接放在 show notes 里，深入探讨这些问题。但关于让工作更有趣和更不有趣的因素，设计师们其实没分享太多，那些被问到为什么工作更不开心的人，我也没听到太多反馈。所以我很好奇那里发生了什么。是的，我在 Anthropic 也看到了一点这种情况。我认为每个人技术性都很强。这是我们在招聘时会筛选的，即使非技术岗位也要经历很多技术面试。而且我们的设计师基本上都写代码。所以我认为对他们来说，从我看到的情况来看，他们是享受这件事的，因为现在不用去烦工程师，可以直接自己去写代码，甚至有些以前不写代码的设计师也开始写了，对他们来说这很棒，因为他们可以解放自己。但我真的很想听听更多人的经验，因为我觉得情况不会这么一致。是的，所以如果你在听这期节目，如果你发现你的工作没那么有趣了，没那么喜欢了，请留个言，因为按照你说的和我从大多数人那里听到的，70%的产品经理和工程师都更喜欢自己的工作了。如果你不属于那一类，那一定是发生了什么。是啊是啊。我们确实看到人们也会使用不同的工具。比如我们的设计师更多地使用 cloud desktop app 来写代码。你只要下载桌面应用，里面有一个 code tab，就在 code work 旁边，其实和 Cloud Code 是一样的，agent 什么的都一样。这个功能我们已经推出好几个月了。所以你可以用它来写代码，不用打开一堆终端，但仍然能获得 Cloud Code 的能力。最重要的是，你可以按需并行运行任意多个 cloud session。我们称之为 multi-clouding。所以我认为，对于那些非工程师出身的人来说，这种方式反而更加自然。归根结底，这是要让产品贴近用户所在的地方。你不希望强迫用户改变工作流程，也不希望他们大费周章去学习新东西。无论人们原本在做什么，只要你能让这件事变得稍微容易一点，那就会是一款好得多的产品，人们也会更喜欢它。这正是“潜在需求”原则，我认为这是产品领域最重要的一条原则。实际上你能展开讲讲这个吗？因为我正想聊到这块——解释一下这个原则是什么，以及当你解锁了这种潜在需求后会发生什么。潜在需求指的是这样一种理念：如果你打造的产品能够被用户“破解”，或者说被他们以一种并非设计初衷的方式使用，用来做他们想做的事，那么这就能帮助身为产品构建者的你了解接下来该把产品带往何方。举个例子，Facebook Marketplace 就是这样诞生的。这个团队的负责人 Fiona，她是 Marketplace 团队的创始经理，她经常提到这段经历。Facebook Marketplace 的起源基于一个观察——那大概是在 2016 年左右——Facebook 群组里 40% 的帖子都在买卖东西。这很不可思议。人们其实一直在滥用 Facebook 群组这个产品来做交易，但这并非安全层面上的滥用，而是说产品本身并不是为此设计的，但人们自己摸索出了这个用法，因为它在这方面实在太有用了。所以很明显，如果你能做一个更好的产品来让人们买卖东西，他们一定会喜欢。从这一点就能非常清楚地看出，Marketplace 一定会大受欢迎。于是，第一步是先推出了买卖群组，也就是专门用于此目的的群组；第二个产品才是 Marketplace。我觉得 Facebook Dating 的起点也很相似。当时的观察是，如果你去看个人资料浏览量，也就是人们在 Facebook 上互相查看对方主页的行为，会发现 60% 的资料查看发生在非好友之间，而且双方性别相反。所以这就像是传统的约会场景，人们只是在互相暗中关注。那么，如果你能为这个需求做一个产品，它或许就能成。所以，潜在需求这个想法，我认为非常强大。再比如，这也是 Cower 的起源。我们看到，在过去大约 6 个月里，很多使用 Cloud Code 的人并没有用它来写代码。有人在 Twitter 上说用它种番茄，有人用它分析自己的基因组，有人用它从损坏的硬盘里恢复照片，像是婚礼照片，还有人用它分析核磁共振影像。所有这些使用场景都和技术毫无关系。很明显，人们是在费尽力气、大费周章地通过终端来做这些事。也许我们该为他们专门做一个产品。其实我们很早就注意到了这一点。大概在去年五月，我记得走进办公室时，看到我们的数据科学家 Brendan 的电脑上开着 Quad Code，屏幕上就是一个终端。我当时很震惊，问他：“Brendan，你在干什么？你居然搞懂了怎么打开终端，要知道这可是个非常工程师向的产品。很多工程师都不愿意用终端，它就像是在计算机最底层、最深处干活的方式。”但他搞懂了怎么用终端，下载了 Node.js，下载了 Quad Code，然后在终端里做 SQL 分析。太不可思议了。结果到了第二周，所有数据科学家都在这么干。所以，当你看到人们以这种方式“滥用”产品，以并非设计初衷的方式来完成对他们有用的事时，这就是一个强烈的信号，告诉你应该去做一款专门为此设计的产品，而人们一定会喜欢它。我觉得，现在潜在需求还有一个有趣的第二维度。传统框架是：观察人们在做什么，让这件事变得容易一点，为他们赋能。而我在过去 6 个月里看到的一种现代框架则略有不同，那就是：观察模型在试图做什么，然后让那件事变得容易一点。所以当我们最初开始构建 Quad Code 时，我觉得很多人用 LLM 做设计的方式，是把模型关在一个盒子里。他们会说：这是我想做的应用，我要它完成这个任务。模型，你负责其中这一个环节。这就是你与这些工具、API 等交互的方式。但 Quad Code 反过来了。我们说，产品就是模型本身。我们要把它暴露出来，在它周围搭建最少的脚手架，给它最少的工具集，这样它就能自主完成各种事情。它可以决定运行哪些工具，决定运行的顺序，等等。我觉得这在很大程度上也是基于模型自身想做之事的潜在需求。所以在研究中，我们称之为 being on distribution。你想看到模型在试图做什么。用产品的语言来说，潜在需求是完全相同的概念，只是把它应用在了模型身上。你提到了 Quad Code。我记得你之前在发布时说过，你们团队只用 10 天就把它做出来了。这太疯狂了。我想它上线后很快就有了数百万用户。这么重要的产品居然 10 天就搭好了。这里面有什么故事吗？除了说“我们用 Quad Code 来构建它”之外，还有什么别的原因吗？是啊，说来挺有意思的。Quad Code 呢，就像我说的，刚发布时并没有立刻火起来。它是随着时间推移才慢慢成为热门产品的，中间有几个拐点。一个是 Opus 4 发布的时候，增长曲线确实出现了非常明显的转折。然后在 11 月又迎来一个拐点。而且它一直在持续加速，增长曲线一天比一天陡峭。但你要知道，在最初几个月里，它并不算成功。虽然有人用，但很多人搞不清该怎么用，不知道它是干嘛的，模型本身也还不够好。而 Quad Code 在发布时，立刻就大受欢迎，比 Quad Code 早期要强得多。说实话，我觉得这很大程度上要归功于 Felix、Sam、Jenny 以及整个构建团队的功劳。那是一支极其强悍的团队。再说一遍，Quad Code 的诞生也是源于这种潜在需求。我们看到人们用 Quad Code 做这些非技术类的事情，于是就想弄清楚我们该怎么办。所以有几个月时间，团队一直在探索，尝试了各种各样的方案。最后有人就说：“好吧，那如果我们直接把 Quad Code 放到桌面应用里会怎样？”结果这就是那个管用的方案。于是，他们在 10 天内完全用 Quad Code 构建出了这款产品。而且你知道，Quad Code 其实内置了一套非常复杂的安全系统，本质上就是一些 guardrails，用来确保模型做正确的事，不会失控。比如，我们随产品附带了一整个虚拟机，而所有这些代码都是 Quad Code 自己写的。所以，我们只需要思考：如何让非工程师用户用起来更安全一点、更能够自主引导一点。它完全是用 Claude Code 实现的，花了大约 10 天时间。我们发布得很早。要知道，它当时还很粗糙，而且到现在也还有不少粗糙的地方。但这正是我们在产品和安全两方面学习的方式——我们必须比自认为的还要更早发布，这样才能获得反馈，才能与用户交流。我们才能理解人们想要什么，然后这会决定产品未来的走向。是的，我觉得这个观点非常有趣，也非常独特。一直以来都有“尽早发布、向用户学习、获取反馈、迭代改进”这样的想法。但事实上，你很难知道 AI 到底能做什么，以及人们会试图如何使用它——这正是尽早开始发布东西的一个独特原因。正如你准确描述的那样，这能帮助你发现这个东西中存在的 latent demand，那些我们原本并不真正了解的需求。先把它放出去，看看人们会怎么用它。是的，在 Anthropic，作为一家安全实验室，这件事的另一个维度就是安全。因为，你知道，当你思考模型安全时，有很多不同的研究方式。最底层大概是对齐（alignment）和 mechanistic interpretability。也就是说，在训练模型时，我们要确保它是安全的。目前我们已经有了相当复杂的技术，可以理解神经元里发生了什么，并进行追踪。比如，如果有一个与欺骗相关的神经元，我们开始……我们开始能够监控它，并理解它正在激活。这就是 alignment，这就是 mechanistic interpretability，它就像是最底层。第二层是 evals。这本质上是一个实验室环境。模型被放在培养皿里，你去研究它。你给它设置一个合成情境，然后问：“好吧，模型，你会怎么做？你做得对吗？它是对齐的吗？它安全吗？”第三层则是观察模型在真实环境（in the wild）中的表现。随着模型变得越来越复杂，这一点变得极其重要，因为它可能在前两层看起来很好，但在第三层却不怎么样。我们之所以很早发布 Claude Code，是因为我们想研究安全性。实际上，在发布之前，我们已经在 Anthropic 内部使用了大概四五个月，因为我们不太确定——这是第一个……你知道，我认为是当时大家发布的第一个大型 agent。它绝对是第一个被广泛使用的编程 agent。所以我们不确定它是否安全。因此我们不得不在内部研究了很长时间，直到我们对它感到放心。即便如此，从那以后，我们也学到了很多关于 alignment 的知识，学到了很多关于安全的知识，并能够把它们反馈到模型和产品中。而对于 Claude 在工作场景中的应用，情况也很类似。模型处于这个新环境中，做的是非工程类任务。它是一个代表你行事的 agent。它在 alignment 上看起来不错，在 evals 上看起来不错。我们在内部试了，看起来不错。我们也让一些客户试了，看起来不错。现在我们必须确保它在现实世界中是安全的。这就是为什么我们发布得稍早一些，为什么我们称之为 research preview。但它确实在持续改进。而且这确实是确保模型在长期内保持 aligned 并做正确事情的唯一方式。你们工作的这个领域太疯狂了，竞争如此激烈，节奏如此之快。与此同时，又有一种恐惧，就是如果你……你知道，就像上帝可能会出逃并造成破坏一样。要找到这种平衡一定非常具挑战性。我听到的意思是，你们有三个层面，我知道这完全可以单独做一整期播客来聊你们是如何思考安全问题的。但按照我听到的，你们有三个工作层面：有点像观察模型的思维和运作；有测试、evals 告诉你它在作恶；然后就是尽早发布。关于第一个层面我其实听得不多。这太酷了。所以你们有一个可观测性工具，可以让你窥探模型大脑内部，看看它是如何思考的，以及它正在朝什么方向发展。是的，你应该……你应该找个时间请 Chris Olah 来播客，因为他是这方面的行业专家。他开创了……我们称之为 mechanistic interpretability 的领域。这个想法是，你知道，就像我做过这样一个核心思考：大脑是什么？它到底是什么？它就像一堆相互连接的神经元。所以你可以在人类大脑或动物大脑中，在这种机制层面研究它，来理解神经元在做什么。令人惊讶的是，很多发现确实也能套用到模型上。模型神经元和动物神经元并不相同，但它们在很多时候表现相似。因此我们对这些神经元的工作方式了解了很多，比如这一层或这个神经元映射到某个概念。特定概念是如何被编码的，模型如何做规划，如何提前思考。很久以前我们不确定模型只是在预测下一个 token，还是在做更深的事情。现在我认为有相当强的证据表明它确实在做更深的事情。而且让它做到这一点的结构现在也相当复杂。随着模型变大，不再是一个神经元对应一个概念。单个神经元可能对应十几个概念。如果它和其他神经元一起激活，这被称为 superposition。它们共同代表了这个更复杂的概念。这是我们一直在学习的东西。对 Anthropic 来说，当我们思考这个领域如何发展时，以一种安全且对世界有益的方式去做，这正是我们存在的原因。这也是每个 Anthropic 人在这里的原因。每个在这里的人，这就是他们在这里的原因。所以很多这类工作我们其实是开源的。我们发表很多。我们非常自由地发表和谈论这些。就是为了激励其他做类似事情的实验室，也能以安全的方式去做。这也是我们在 Claude Code 上做的事情。我们在内部称之为 race to the top。比如对于 Claude Code，我们发布了一个开源 sandbox。这是一个可以运行 agent 的 sandbox。它只是确保有某些边界，它不能访问你系统上的所有东西。我们把它开源了，而且它实际上适用于任何 agent，不只是 Claude Code。因为我们希望让其他人也能很容易地做同样的事。这就是 race to the top 的同一个原则。我们想确保这件事进展顺利，而这就是我们所拥有的 lever。太不可思议了。好的，我肯定想在这个话题上多花些时间。我会跟进这个建议。另外我还注意到，在这个领域里，无论是工程师、产品经理，还是其他与 agent 打交道的人，都有一种焦虑感——当他们的 agent 不工作时，人们会感到焦虑。有一种感觉是：天啊，它需要问答，或者它被什么东西卡住了，或者……我只是觉得，我好像失去了所有这些生产力，我不能……我需要醒过来然后重新启动它。你会有这种感觉吗？你的团队有这种感觉吗？你觉得这是我们需要关注和思考的问题吗？我一直在运行一堆 agent。比如现在，我有五个 agent 在跑。随时都是，你知道吗，我一醒来就会启动一堆 agent。比如今天早上醒来第一件事就是，哎呀，我想检查一下这个东西。于是我打开手机上的 Claude iOS app，进入 code tab，然后对 agent 说“去做这个那个”。因为我昨天写了一些代码，然后就想，等等，我写得对吗？我有点自我怀疑，结果证明是对的。但现在做这种事太容易了。所以，我不知道，也许有一点焦虑吧。我个人倒没有真的感觉到，因为我一直都有 agent 在运行。而且我也不再局限于 terminal 了。现在大概三分之一的代码是在 terminal 里写的，三分之一是用 desktop app，还有三分之一是 iOS app——这太让人惊讶了，因为我没想到就算到了 2026 年我还会这样写代码。我喜欢你还把这称作“写代码”，本质上就是让 Claude Code 帮你写代码。有趣的是，现在这就算编程了。现在的编程就是描述你想要什么，而不是写实际的代码。我有点好奇，那些以前用打孔卡之类的东西编程的人，如果你给他们看现在的软件，他们会说什么？是不是很疯狂？我记得读到过一些东西。可能是 ACM 很早期的杂志之类的。里面有人说：“不，这不是一回事。这不是真正的 coding。”然后你知道，他们称之为 programming。我觉得 coding 算是个新词。但我会想起那些——你知道，我家来自苏联。我出生在乌克兰。我爷爷实际上是苏联最早的程序员之一。他用打孔卡编程。他会给我妈妈讲这些故事，或者说她小时候听他讲这些故事：他会把打孔卡带回家，家里有一大堆打孔卡。对她来说，她会在上面用蜡笔乱画，那是她的童年记忆。但对他来说，那是他编程的经历，而且他实际上从未见证过向软件的过渡。但某个时候确实过渡到了软件，我想可能有一代老程序员就没把软件当回事。他们会说：“嗯，你知道，这不是真正的 coding。”但我认为这个领域一直都是这样变化的。你可能不知道，我也出生在乌克兰。哦，我不知道。是啊，哪个城市？我来自 Odessa。哦，我也是。你说什么？ 是啊，太疯狂了。哇，不可思议。等等。也许我们在某种程度上还有点沾亲带故呢。你们是哪一年离开的？我们 '95 年来的。好的，我们 '88 年离开的。早一点。是啊。如果没离开，人生会完全不同吧？是啊，我每天都觉得很幸运，能在这里长大。是啊，我家每次举杯或吃饭时，都会说“敬美国”。是啊，就是——好吧，不说这个了，但你懂的，一旦你开始认真想本来可能过上的生活。是啊，是啊，没错。我们也敬一样的酒，但喝的还是伏特加。还是伏特加，绝对的。天啊。好了，我再问你几件事。你分享了一些很酷的技巧，关于如何充分利用 AI、如何基于 AI 开发、如何打造优秀的 AI 产品。你分享的一个建议是，给团队尽可能多的 token，让他们尽情实验。你还分享了一个总体建议：朝着模型未来的方向构建，而不是针对它现在的能力。对于那些想打造 AI 产品的人，你还有什么其他建议？我可能还会再分享几点。第一，不要试图把模型框死。我觉得很多人在基于模型构建产品时的本能反应，是想让它以非常特定的方式运作。他们会说，你知道，这是更大系统里的一个组件。举个例子，有些人会在模型上叠加非常严格的工作流。比如说，你必须先做第一步，然后第二步，然后第三步，还得有一个很花哨的 orchestrator 来管这个。但实际上，如果你只是给模型工具、给它目标，让它自己想办法，几乎总是会得到更好的结果。我觉得一年前你确实需要很多 scaffolding，但现在不太需要了。所以，我不知道该把这个原则叫什么，但有点像——你知道，别问模型能为你做什么。大概类似这种吧。就是要思考怎么给模型工具去做事？不要过度策划，不要把它装进盒子里，不要一上来就给它塞一堆上下文。给它工具，让它自己获取需要的上下文。这样效果会更好。第二点，嗯，也许其实是这个原则更通用的版本，就是 the bitter lesson。实际上，对 Quadko 团队来说——希望听众们已经读过了——Rich Sutton 大概十年前写过一篇博客叫 the bitter lesson。这其实是个很简单的观点。他的观点是，更通用的模型总是会比更专用的模型表现更好。我觉得他当时讲的是自动驾驶汽车之类的领域。但实际上 the bitter lesson 有很多推论。对我来说最大的一点就是：永远押注更通用的模型。而且从长远来看，不要试图用小模型做事，不要试图做 fine-tune，不要搞这些。有些应用确实需要，有些理由去做这些，但几乎 always 要尽量押注更通用的模型，如果你有这个灵活性的话。这些工作流本质上就是——你知道，这不是通用模型，而是在它周围搭 scaffolding。一般来说，我们看到 scaffolding 也许能提升 10% 到 20% 的性能，但这些收益往往会被下一个模型抹平。所以还不如直接等下一个模型。我想最后一点，也是 Quad Code 事后看来做对了的事。从一开始，我们就押注在为六个月后的模型做构建，而不是为今天的模型。在产品的早期版本里，我自己写的代码非常少，因为我不信任它。因为你知道，那时候还是 Sonnet 3.5，然后是 3.6，或者叫什么 3.5 new 之类的，随便我们给它取了什么名字。这些模型当时还不太擅长编程。它们在进步，但还很早期。所以那时候，模型对我来说确实——它自动化了一些东西，但真的没帮我写多少代码。所以 Quad Code 的赌注是，总有一天模型会变得足够好，能写大量代码。而我们第一次看到这个转折点是在 Opus 4 和 Sonnet 4 的时候。Opus 4 是我们五月份发布的第一个 ASL 3 级别的模型。我们看到了这个拐点，因为大家第一次真正开始用 Quad Code。那大概就是我们增长真正开始爆发的时候。而且就像我说的，它基本保持在那里了。所以，这其实是我会给很多人、尤其是创业公司的建议。头6个月会很不舒服，因为你的产品市场契合度不会太好。但如果你是针对6个月后的模型来构建产品，等那个模型一出来，你就能立刻上手，产品也会豁然开朗、开始运转。那你说要针对6个月后的模型来构建，你觉得人们可以预设会发生什么？是泛指它会各方面都变强吗？还是说，它现在差不多够用了，这就是一个信号，说明它在这方面很可能会继续变好？这方面有什么建议吗？我觉得这是个好思路。你知道，显然在 AI 实验室内部，我们能看到它具体在哪些方面变强。所以这有点不太公平。但我们也尝试对外分享这些。比如，它未来会变得更强的一个方面，就是使用工具和使用电脑的能力。这是我会押注的一个方向。另一个是，它会越来越擅长长时间运行。这个领域有各种各样的研究。但如果你只是追溯这条轨迹，或者甚至从我个人经验来看，一年前我用 Claude 3.5 的时候，它可能只能运行15到30秒，然后就开始跑偏，做任何复杂任务你都得手把手带着它。但现在用 Opus 4.6，平均下来，它可以无人值守地运行10、20、30分钟，我会再启动一个 Claude 让它去做别的事。就像我说的，我通常会同时运行很多个 Claude。它们也可以一次运行几个小时甚至几天。我想有些例子里它们运行了好几周。所以我认为，随着时间推移，模型运行非常长的时间会变成越来越常态的事，你不必再坐在那里盯着它们了。你刚聊了构建 AI 产品的建议。那对于第一次使用 Claude Code 的人，或者已经在用但想用得更好的人，有什么专业技巧可以分享吗？我先声明一点：使用 Claude Code 没有唯一正确的方法。所以我可以分享一些技巧，但说实话，这是一个开发工具。开发者各不相同，有不同的偏好，不同的环境。所以使用这些工具的方式有很多，没有唯一正确的方法。你得找到自己的路径。好在你可以问 Claude Code，它能给出建议，能修改你的设置。它对自己有一定了解，所以能帮上忙。我觉得比较有用的几个技巧：第一，用最强大的模型。目前来说，就是 Opus 4.6。我一直开着 maximum effort。有时候人们会尝试用更便宜的模型，比如 Sonnet 之类的。但因为它的智能程度较低，最终完成同样的任务反而要消耗更多 token。所以用便宜模型未必更省钱。通常情况下，用最强大的模型其实更便宜，消耗的 token 也更少，因为它能更快搞定，不需要那么多修正和手把手指导。所以第一个建议就是：用最好的模型。第二，用 plan 模式。我几乎所有任务都是用 plan 模式开始的，大概80%吧。plan 模式其实非常简单，我们只是在模型的 prompt 里加了一句话："请先不要写代码。" 就这样。实际上没什么花哨的，就是最简单的东西。对于用终端的人来说，按两次 Shift+Tab 就能进入 plan 模式。桌面应用上有个小按钮，网页版也有个小按钮。移动端很快也会上线。而且我们刚在 Slack 集成里也推出了这个功能。所以第二点是 plan 模式。本质上，模型会跟你来回沟通。一旦计划没问题了，你再让模型执行。之后我会开启自动接受编辑，因为如果计划做得好，它通常能一次搞定。用 Opus 4.6 的话，几乎每次都能第一次就做对。然后第三点建议是多试试不同的交互界面。很多人一想到 Claude Code 就想到终端。当然，我们支持所有终端，Mac、Windows，不管用什么终端都能完美运行。但实际上我们也支持很多其他形态。比如我们有 iOS 和 Android 应用，有桌面应用，还有 Slack 集成等等。所以我建议大家多试试这些。再说一次，每个工程师都不一样，每个做开发的人都不一样。找到让你觉得顺手的方式，用它就行。你不一定非要用终端。底层运行的是同一个 Claude agent。太棒了。好的，最后再问几个问题收尾。你怎么看 Codex？你对那个产品有什么看法？你觉得他们的方向如何，怎么看待在编程 agent 这个激烈竞争领域的竞争？我其实没怎么用过。不过我想它刚出来的时候我可能用过。在我看来它跟 Claude Code 很像，这还挺让人受宠若惊的。其实我觉得有更多竞争是好事，因为人们应该有选择权，而且希望这能迫使我们都做得更好。但对我们团队来说，我们只专注于解决用户的问题。所以我们不会花很多时间去看竞品，也不会真的去用其他产品。你要知道它们的存在，你要意识到有这么回事。但对我来说，我喜欢跟用户交流，喜欢把产品做得更好，喜欢根据反馈去行动。所以核心就是做出好产品。最后一个问题。我和 Anthropic 的联合创始人 Ben Mann 聊过，他给了我一些建议，告诉我可以跟你聊些什么，我也在这次对话中融入了这些建议。他有一个问题想问你：AGI 之后你有什么打算？你觉得你会去做什么？一旦我们实现了 AGI——不管那意味着什么——你的生活会是什么样？在加入 Anthropic 之前，我其实住在日本乡下，生活方式完全不同。我好像是镇上唯一的工程师，唯一的英语使用者。氛围完全不一样。一周我会骑车去几次农贸市场，骑车经过稻田之类的。这跟旧金山完全相反，完全不一样。我特别喜欢的一点是，我们通过交换腌菜来认识邻居、建立友谊。在我们住的那个镇上，其实每个人都会做味噌，每个人都会做腌菜。所以我做味噌做得还算可以。我做了好多批，现在也会做。味噌这东西很有意思，它教会你从很长的时间尺度去思考，这跟工程完全不同。因为比如一批白味噌至少要三个月才能做好。红味噌则要做两三年，甚至四年。你得非常有耐心。
Boris：你差不多把它拌好，然后就这样放着。你得非常非常耐心。所以我喜欢的就是这种以长时间尺度来思考的感觉。嗯，是的，我觉得在 post-AGI 时代，或者如果我不在 Anthropic，我可能会去做味噌。我喜欢这个回答。呃，Ben 让我问你，你和味噌是怎么回事。所以我很开心你回答了这个问题。好吧，那未来可能就是深入研究味噌。变得非常擅长做味噌。呃，太棒了。呃，Boris，这次访谈太精彩了。我感觉我们现在像是从乌克兰来的兄弟。呃，在我们进入非常激动人心的闪电问答环节之前，你还有什么想分享的吗？有什么想留给听众的吗？有什么你想特别强调的吗？
Boris：是的，我觉得我只想强调，从 Anthropic 创立之初，这种从编程起步，再到工具使用，再到计算机使用的理念，一直就是我们的思维方式。而且我们认为模型就是这样发展的，或者说，这就是我们想要构建模型的方式。这也是我们学习安全、研究安全并最大程度改进安全的方式。所以，你知道，现在发生的一切，就像 Claude Code 变成了一项巨大的、价值数十亿美元的业务。而且，现在我所有的朋友都用 Claude Code，他们一直给我发消息说这个。呃，所以，你知道，这个东西变得有点大了。在某些方面，这完全是个惊喜。因为这并不是我们预想的那样。我们不知道会是这个产品。我们不知道它会从一个终端开始之类的。但在某些方面，这又完全不足为奇，因为作为一家企业，这是我们长期以来的信念。同时，这仍然感觉非常早期。你知道，世界上大多数人还没有使用 Claude Code。世界上大多数人还没有使用 AI。所以，这感觉才完成了 1%，还有很长的路要走。主持人：是啊，伙计。想到现在公布的数字就觉得疯狂。你们刚融了一大笔钱。呃，我觉得单是 Claude Code 就能创造 20 亿美元的收入。Anthropic，我觉得你们公布的数字是 150 亿美元收入。想到现在还这么早期，而我们看到的数字就已经这么庞大了，真是不可思议。
Boris：是啊，是啊，是啊。这很疯狂。而且我的意思是，Claude Code 持续增长的方式，说实话就是靠用户。就是我们有很多人在使用它。他们非常热情。他们爱上了这个产品。然后他们会告诉我们哪些功能不行，他们想要什么。所以，它不断进步的唯一原因就是每个人都在使用它。每个人都在谈论它。每个人都在不断反馈。这才是最重要的事情。而且，你知道，对我来说，这就是我喜欢度过每一天的方式——和用户交流，为他们把产品做得更好。还有做味噌。好吧，你知道，味噌倒是不需要怎么操心。只需要等着就行。主持人：好吧，Boris，说到这儿，我们已经进入非常激动人心的闪电问答环节了。我有五个问题要问你。准备好了吗？开始吧。
Boris：开始吧。主持人：第一个问题，你会向其他人推荐的两三本书是什么？
Boris：我读书很多。呃，我先从一本技术书开始。一本是《Scala 函数式编程》。这是我读过的最好的技术书。这很奇怪，因为你不会真的去用 Scala，而且我也不知道这在未来还有多大意义，但函数式编程中有一种优雅，还有类型思维，这就是我写代码的方式，也是我无法停止思考代码的方式。所以，你知道，你可以把它当作一个历史文物。你也可以把它当作能让你提升水平的东西。主持人：我喜欢这本。从未被提及过的书，我的最爱。
Boris：哦，太棒了，太棒了。呃，好吧，第二本是 Stross 的《Accelerando》。这大概，你知道，我最喜欢的类型是科幻。呃，可能是科幻和小说。《Accelerando》是一本非常不可思议的书，节奏非常快。节奏变得越来越快，我觉得它比我看过的任何其他书都更捕捉到了我们当下时刻的本质。就是它的速度。故事开始时，腾飞刚刚开始发生，你知道，我们开始接近奇点。结尾则是某种集体龙虾意识环绕着木星。嗯，而且你知道，这发生在几十年左右的时间里。所以，节奏简直不可思议。我真的很喜欢它。也许我再推荐一本。呃，刘慈欣的《流浪地球》。对，他就是写《三体》的那个人。我想很多人因为《三体》知道他。其实我觉得《三体》很棒，但我更喜欢他的短篇小说。所以《流浪地球》是一本短篇小说集，里面有一些非常非常精彩的故事。而且看中国科幻也很有意思，因为它的视角与西方科幻非常不同，至少他作为作家的思维方式就是如此，读起来真的非常有趣，而且文笔优美。主持人：科幻让我们为思考未来做好了准备，这太有意思了。就像它给了我们大量的思维模型，让我们觉得："好的，我明白了。我在书里读到过这种世界。"
Boris：是啊，我觉得对我来说，这其实就是我加入 Anthropic 的原因。因为你知道，就像我说的，我当时住在一个乡村地方。我在以长时间尺度思考，因为那里的一切都很慢。至少跟旧金山相比是如此。嗯，而且你做的所有事情都是围绕季节，围绕这种需要很多很多个月的食物。社交活动就是这样组织的。你安排时间也是这样。你去农贸市场，现在是柿子季，你知道这一点是因为有大概 20 个柿子摊贩。然后下周这个季节结束了，就变成了葡萄季，你能看到这种变化。所以就是这类长时间尺度。而且我那时候也在读很多科幻小说。就在那个时刻，我在想，你知道，想着这些长时间尺度。我知道这件事会怎样发展，我只是觉得我必须为之做出贡献，让它往好的方向发展一点点。这就是我为什么最终去了 Anthropic。Ben Mann 也是其中的重要部分。主持人：我觉得我想做一整期播客，专门讲你在日本的时光，以及 Boris 从日本到 Anthropic 的旅程，但我们长话短说。呃，如果你没读过的话，我快速向你推荐一本科幻小说。你读过《A Fire Upon the Deep》吗？这是 Vinge 写的，对吧？
Boris：是的，很棒。是的。主持人：好的。那本书从 AI 和 AGI 的视角来看非常有趣。呃，读过的人太少了。所以我自己读过。是的。那是我非常喜欢的一本。
Boris：是啊，是啊，是啊。我也喜欢《A Deepness in the Sky》。我觉得续集是最棒的。续集更伟大。
Boris：是啊，是啊，是啊。我也这么想。是的。它很长，而且读起来很复杂，但非常棒。主持人：好的，我们继续闪电问答环节。呃，你最近有特别喜欢的一部电影或电视剧吗？
Boris：其实我最近不怎么看电视或电影。我只是没什么时间。嗯，我确实看了——我又要提到刘慈欣了——Netflix 上的《三体》剧集，我真的很喜欢。嗯，我觉得那是对原著系列的一次很好的改编。在 AI 领导者中，没时间看电视或电影是一种很普遍的现象，这我完全理解。那你最近有没有发现什么特别喜欢的、爱不释手的产品？我稍微要安利一下，那就是 Coda。因为这确实是一款对我来说堪称改变生活的产品，我一直开着它，尤其是它的 Chrome 集成做得非常出色。比如说，它帮我交了交通罚款，还帮我取消了几项订阅。它能帮我处理的繁琐工作量之大，太厉害了。我也不确定这算不算产品，但或许我还想推荐一个我非常喜欢的播客。显然除了《Money》之外……
当然。对，就是 Ben 和 David 做的《Acquired》播客。嗯。这个播客真的太棒了。我觉得他们讲述商业历史并让其变得生动的方式真的非常好。如果你还没听过，我推荐从任天堂那期开始。好建议。说到 Cowerk，为了让没试过的人明白：基本上就是你输入想完成的事，它就能打开 Chrome 帮你把事情做了。我看到有个 Anthropic 的员工去休陪产假，你让它帮忙填了那些医疗表格，就是那种特别烦人的 PDF，它会打开浏览器、登录、填表、提交。对，没错没错。而且它真的就是能用。大概一年前我们试过这个实验，但当时模型还没准备好，所以不太行，现在它真的就是能用了，太神奇了。我觉得很多人是因为之前没用过这种 agent。这给我的感觉和一年前的 Claude Code 非常像。但就像我说的，它的增长速度比 Claude Code 早期快得多。所以我觉得它开始有点破圈了。而且你提到的那个 Chrome 扩展也可以单独使用，它就在 Chrome 里，你可以直接对着 Claude 说话，让它看着你的屏幕、你的浏览器，然后帮你做事，让它告诉你正在看什么、总结页面内容之类的。没错没错。对于那些想马上尝试 Cowork 的人，我的建议是：下载 Claude 桌面应用，点进 Cowork 标签页，就在 Code 标签页旁边。我推荐的做法是先让它使用工具。比如清理桌面，或者总结邮件之类的，又或者回复最重要的三封邮件。实际上它现在也会直接帮我回邮件了。第二件事是连接工具。比如如果你说：“查看我最重要的邮件，然后发 Slack 消息。”或者把它们放进表格之类的。再比如，我用它来做所有的项目管理。我们整个团队共用一张表格，每个工程师一行，每周大家填写状态。每到周一，Cowork 就会逐个检查，给所有还没填状态的工程师发 Slack 消息提醒。这样我就不用再干这事了。而这只是其中一件事，它什么都能做。第三件事就是并行运行多个 Cowork。你可以同时运行任意数量的任务。比如我启动一个任务，让项目管理那边跑着，然后我还要做别的，再做别的，把这些都启动之后，我就去喝杯咖啡等它跑完。我会链接到一篇帖子，里面分享了人们使用之前叫 Cloud Code、现在可以通过 Cowork 做的各种方法。因为很多时候大家会觉得：“哇，我从没想过还能这么用。”我觉得一旦看到这些例子，人们就会意识到：“哇，原来还能这样。”
对，我觉得这里面有很多也是受你启发，Lenny。你之前发过一篇帖子，大概是讲 Cloud Code 的 50 个非技术用途之类的。所以我们的一位产品经理在发布 Cowork 之前，就是用这个来评估产品的。我记得当时 Cowork 能完成 50 个里面的 48 个，我们就觉得：“行，这产品不错了。”
哇，我之前不知道这个。这太棒了。呃，我成了评估基准了。是吧？感觉如何？太神奇了。我觉得自己好像对 AI 的未来有了价值。这就像是反向破圈。
［笑声］
哇，这太酷了。哇，好吧。我好奇最后那两个是什么。总之，好吧。还有两个问题。你有没有什么最喜欢的人生格言，在工作或生活中经常想起的？用常识。我觉得我见过很多失败，尤其是在工作环境中，都是因为人们没有运用常识。比如，他们不经思考就遵循某个流程；或者不经思考就去做一件事；又或者他们正在做的产品并不是个好产品、不是个好主意，但他们只是顺着惯性去做，不去思考。我觉得我见过最好的结果，都是那些从第一性原理出发思考、并且培养了自己常识的人做出的。如果某件事感觉不对劲，那它可能就不是个好主意。所以我觉得这就是我给同事们的唯一建议，比什么都重要。而且我觉得光这个话题就能单独做一期播客了。什么是常识？怎么建立常识？但我们长话短说。最后一个问题。你最近在 Twitter/X 上越来越活跃了。我好奇这是为什么，以及你在 Twitter 上的体验如何，因为你在 Twitter/X 上获得了很多互动。很长一段时间我只用 Threads，因为其实我早年帮忙做过一点 Threads。而且我也很喜欢它的设计，它是个很简洁的产品，我真的很喜欢。我开始用 Twitter 其实是因为我太无聊了。去年十二月我在欧洲。你说的是 Twitter 吧？哦对对对。我开始用 Twitter 是因为我太无聊了。去年十二月我和我太太在欧洲四处旅行，有点像数字游民那样。我们去了哥本哈根，还去了其他几个国家。对我来说那就像是一次编程度假。我每天都在写代码，这是我最喜欢的度假方式。就是整天写代码，太棒了。然后有那么一刻，我有点无聊了，有那么几个小时我想不出要做什么了。我就想：“好吧，接下来做点什么？”于是我打开 Twitter，看到有人在发关于 Quad Code 的推文，我就开始回复。然后我想：“好吧，也许我真正该做的事是去找找看大家有没有 bug，也许大家有一些 bug 或者反馈。”所以我就自我介绍了一下，问大家有没有一堆 bug 和反馈。我觉得大家对我们现在处理反馈的速度感到有点惊讶。对我来说这太正常了。如果有人报了个 bug，我大概几分钟就能修好。因为我只要写个 quad，只要描述清楚，它就会自己去修，然后我就开始干别的事、回答下一个问题。但我觉得对很多人来说这挺让人惊讶的。所以这事很酷。而且是的，我在 Twitter 上的体验非常好。能和大家交流，了解大家的需求，听取 bug 反馈和功能建议，这真的很棒。前几天我在 GitHub repo 上看到一条抱怨，而且你当时在 Twitter 上发了很多帖子，结果系统崩了，我当时就想：“天哪，这是怎么回事？”是的，确实有个 bug，希望现在已经修好了。太好了。天哪，Boris，我可以跟你聊上好几个小时。我就不耽误你时间了，非常感谢你来参加这次访谈，你太棒了。大家可以在网上哪里找到你？听众们怎样才能帮到你？可以在 Threads 或 Twitter 上找到我，这是最简单的方式。请大家在相关内容里 @ 我，提交 bug，发送功能请求。还缺什么功能？我们怎样才能把产品做得更好？你们想要什么？我很乐意倾听大家的声音。太好了。Boris，非常感谢你的到来。好的，谢谢 Lenny。各位再见。非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也欢迎给我们打分或留下评论，这真的能帮助其他听众找到这档播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多信息。下期再见。