本文档是 Lenny 的播客（Lenny’s Podcast）的一期完整中文翻译文稿。本期嘉宾是 Anthropic 旗下现象级 AI 编程工具 Claude Code 的负责人 Boris Cherny。在对话中，Boris 深入探讨了 AI 如何以惊人的速度重塑软件工程行业，并分享了 Claude Code 是如何从一个简易的终端原型，爆发式增长为贡献了 GitHub 全球公开提交量 4% 的颠覆性工具。

两位对谈者围绕诸多深刻的行业话题展开了讨论。Boris 坦言自己目前的编程工作已 100% 由智能体（Agent）完成，并预测“传统编程”问题已被基本解决。他分享了 Anthropic 团队内部打造 AI 产品的独特哲学，如发掘用户的“潜在需求”、保持团队的“资源欠配置”以激发 AI 效能、提供无限量 Token 鼓励试错，以及 Anthropic 严谨的三层 AI 安全架构。

除了前沿的技术洞察，Boris 还展现了丰富且有趣的生活经历。他与主持人 Lenny 惊喜地发现彼此都出生于乌克兰的敖德萨；他还分享了自己在日本乡村制作味噌的时光，以及这种“长远的时间尺度”如何影响了他对通用人工智能（AGI）未来的思考。文章最后，Boris 提供了多项关于如何高效使用 Claude Code 的进阶技巧与科幻好书推荐。

Head of Claude Code: What happens after coding is solved | Boris Cherny

Boris Cherny 是 Anthropic 旗下 Claude Code 的创始人与负责人。这款仅仅一年前还只是一个简单终端原型的工具，如今已深刻改变了软件工程师的工作方式，并正在加速重塑各类专业工作的面貌。

本期话题：

1. Claude Code 如何从一个快速验证的原型成长为贡献 GitHub 公开提交量 4% 的产品——日活用户上月实现翻倍
2. 推动 Claude Code 成功的反直觉产品原则
3. 为何 Boris 认为编程问题已被"解决"
4. 塑造 Claude Code 与 Cowork 的潜在需求（latent demand）
5. 充分发挥 Claude Code 与 Cowork 的实用技巧
6. 为何给团队削减预算、同时提供无限 token，反而能打造出更好的 AI 产品
7. Boris 为何短暂离开 Anthropic 加入 Cursor，又在两周后回归
8. Boris 与每位新团队成员分享的三条原则

本期文字稿： https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens

文字记录

Boris 与 Claude Code 简介

Boris Cherny: 我 100% 的代码都由 Claude Code 编写。

Lenny Rachitsky: 哦，真的吗？你会想念亲手写代码的感觉吗？

Boris Cherny: 我从未像今天这样享受编程，因为我不再需要处理那些繁琐的细节。工程师人均生产力提升了 200%。有个问题一直被反复讨论：我应该学编程吗？再过一两年，这个问题将不再重要。编程这件事在很大程度上已经被解决了。我设想一个人人都能编程的世界——任何人随时都可以构建软件。那么，软件开发方式的下一次重大变革会是什么？Claude Code 开始自主提出想法了。它会浏览用户反馈，查看 bug 报告，分析遥测数据来修复漏洞、推进功能发布——越来越像一个同事（co-worker）的角色。收听这期节目的很多人是产品经理，他们现在可能正在冒冷汗。我认为到今年年底，每个人都会成为产品经理，同时每个人都会编程。「软件工程师」这个头衔将逐渐淡出，被「构建者（builder）」所取代，这对很多人来说将是一个痛苦的转变。

Lenny Rachitsky: 今天我的嘉宾是 Boris Churnney，Anthropic 旗下 Claude Code 的负责人。Claude Code 对世界所产生的影响难以言表。本期节目发布之际，正值 Claude Code 上线一周年。就在这短短一年内，它彻底改变了软件工程师的工作方式，如今也开始影响科技行业中许多其他岗位——这也是我们今天要探讨的话题。Claude Code 本身在过去一年里也是 Anthropic 整体增长的重要驱动力。Anthropic 刚刚完成了一轮估值超过 3500 亿美元的融资。正如 Boris 所提到的，Claude Code 自身的增长势头依然强劲——仅在过去一个月内，其日活用户数就翻了一番。Boris 本人也是一个非常有趣、善于思考、思维深邃的人。在这次对话中，我们意外发现彼此出生在乌克兰的同一座城市——太有趣了，我之前完全不知道。

Boris 短暂离职加入 Cursor 的前因后果

Lenny Rachitsky: Boris，非常感谢你来到这里，欢迎参加这期播客。

Boris Cherny: 谢谢邀请。

Lenny Rachitsky: 我想先问一个劲爆的问题。大约 6 个月前——我不知道大家是否还记得——你其实离开了 Anthropic，加入了 Cursor，然后两周后又回到了 Anthropic。这究竟是怎么回事？我想我从来没有听过这件事的完整经过。

Boris Cherny: 【笑】这是我经历过的最快的一次工作变动。我加入 Cursor 是因为我是这款产品的忠实粉丝，坦率说，见到那个团队时我真的印象深刻。我至今仍觉得他们很厉害，他们正在构建非常酷的东西，而且我认为他们比很多人更早看清了 AI 编程的发展方向。所以，打造出色产品的想法对我来说非常令人兴奋。但我想，一到那里，我就开始意识到，自己真正怀念的是在 Anthropic 的使命感。这其实也是当初驱使我加入 Anthropic 的原因——在那之前，我在大型科技公司工作，到了某个时刻，我想去一家实验室，以某种方式帮助塑造我们正在共同构建的这个疯狂事物的未来。吸引我来到 Anthropic 的，正是它的使命——一切都关乎安全。当你和 Anthropic 的人交谈时，就算在走廊里随便找一个人，问他们为什么在这里，答案永远是：安全。这种使命驱动的文化深深触动了我。我也深知，这是我获得幸福感所必需的东西。这就是我真正怀念的。我发现，无论工作内容是什么，无论多么令人兴奋，即使是打造一款非常酷的产品，都无法真正替代那种感觉。所以对我来说，很快就清晰地意识到——我缺少的是什么。

Claude Code 上线一周年

Lenny Rachitsky: 好的。那么，让我顺着你回归 Anthropic 以及在那里所做工作的这条线索聊下去。这期播客发布之际，正值 Claude Code 发布一周年。我想花一点时间回顾一下你们所产生的影响。最近有一份由 SemiAnalysis 发布的报告——我相信你已经看过——显示目前 GitHub 上所有代码提交（commit）中，有 4% 是由 Claude Code 完成的，他们预测到今年年底，这一比例将达到 GitHub 所有代码提交的五分之一。他们的说法是：就在我们眨眼之间，AI 已经吞噬了整个软件开发领域。就在我们录制这期节目的今天，Spotify 发布了一条头条新闻——他们最优秀的开发者自去年十二月起就再未手写过一行代码，全靠 AI。越来越多顶尖的高级工程师，包括你在内，都在坦言自己已经不再写代码了，全部由 AI 生成；很多人甚至连代码都不看了。我们能走到今天这一步，在很大程度上要归功于你发起的这个小项目，以及你的团队在过去一年里对它的规模化推进。我很想听你回顾一下这过去的一年，以及你的工作所产生的影响。

Boris Cherny: 这些数字真的太疯狂了，对吧？全球 4% 的代码提交——这远远超出了我的预想。就像你说的，感觉这还只是起点。而且这还只是公开的代码提交，如果算上私有仓库，我们认为这个比例会高出相当多。对我来说，最疯狂的甚至不是我们现在所处的这个数字，而是增长的速度——从任何维度来看 Claude Code 的增长率，它都在持续加速，不只是在上升，而是越来越快地上升。我最初启动 Claude Code 的时候，它不过是一个小小的实验性尝试（hack）。我们在 Anthropic 大致清楚想要推出某种编程产品。在很长一段时间里，我们构建模型的方式契合我们对"如何打造安全高能力 AI"的心智模型：模型先是在编程方面变得非常出色，然后是工具调用，再然后是计算机操作——大致就是这样的发展轨迹，我们为此已经努力了很长时间。

我最初加入的团队叫 Anthropic Labs 团队。Mike Krieger 和 Ben Mann 刚刚重新启动了这个团队，开启"第二轮"。这个团队打造了一些很酷的成果：我们构建了 Claude Code、MCP（Model Context Protocol，模型上下文协议），以及桌面应用。你可以从中看到这个构想的脉络——从编程，到工具调用，再到计算机操作。这对 Anthropic 之所以重要，是因为安全性——说到底还是回到那个话题：AI 正变得越来越强大，能力越来越强。过去一年发生的事情是：至少对工程师而言，AI 不再只是写代码，不再只是对话伙伴，而是真正地使用工具，在世界中采取行动。我认为，现在随着 Cowork 的推出，我们也开始看到这一转变延伸到非技术人群。对于许多使用对话式 AI 的人来说，这可能是他们第一次接触到真正能够"行动"的东西——它可以真正操作你的 Gmail、你的 Slack，替你完成各种各样的事情，而且做得相当好。未来只会越来越好。

所以我觉得，在 Anthropic，很长一段时间里都有一种感觉：我们想要构建些什么，但具体是什么并不明朗。加入 Anthropic 后，我花了一个月时间做各种实验性开发，搭了一堆奇奇怪怪的原型，大部分都没有发布，甚至连接近发布的状态都谈不上，只是在探索模型能力的边界。然后我又花了一个月时间做后训练（post-training），了解研究层面的情况。说实话，对我这个工程师而言，这非常重要——我发现，要做好工作，你真的需要理解你所工作的那一层之下的那一层。在传统工程工作中，如果你在做产品，你就需要了解基础设施、运行时（runtime）、虚拟机、编程语言；总之是你所构建的那个系统。但如果你在做 AI，你真的需要在某种程度上理解模型，才能做好工作。我走了这段弯路，然后回来开始原型设计，最终就成了 Claude Code。

第一个版本，那是夏天的事——我录制了一段演示视频并发布了出去，那时候它叫 Claude CLI。我只是展示了它如何使用几个工具，而让我震惊的是：我给了它一个批处理工具（batch tool），它竟然能用这个工具自己写代码，当我问"我正在听什么音乐？“时，它给出了答案。这是最让我觉得不可思议的地方——因为我并没有指示模型说"用这个工具做这个"之类的话。模型被给予了这个工具，然后它自己想出了如何使用它来回答我的问题——而我甚至不确定它能否回答。

Claude Code 的诞生故事

Boris Cherny: 我正在听什么音乐？于是我开始进一步做原型。我在内部发了一篇帖子宣布这件事，结果只收到了两个点赞——那就是当时反响的全部了。我想原因在于，人们想到编程工具时，脑子里浮现的是 IDE，是各种复杂精密的环境；没有人觉得这东西可以基于终端（terminal）。这是一种有些奇特的设计方式，其实也并非出于刻意为之——从一开始我就在终端里构建它，只是因为最初几个月只有我一个人，这是最简单的开发方式。对我来说，这实际上是一个很重要的产品经验：在早期阶段，你要刻意让资源稍微匮乏一点。

然后我们开始思考应该采用哪种产品形态（form factor），最终决定暂时坚守终端形态，最主要的原因是模型进化得太快了——我们感觉没有其他形态能跟得上它。说实话，这也是我苦苦思索的过程——过去这一年，Claude Code 就是我脑子里全部的念头。就是深夜里反复想的事情：模型在持续进化，我们该怎么办？怎么才能跟得上它？说实话，终端是我唯一想到的答案。然后发布之后很快就火了。在 Anthropic 内部大受欢迎，日活用户数直线拉升。其实早在发布之前，Ben Mann 就催我做一张日活用户（DAU）图表。我还想说，现在是不是太早了，真的有必要现在就做吗？他说：“就现在。“然后那张图表几乎立刻就垂直拉升了。二月份，我们对外正式发布了。

有一件事大家可能不太记得了：Claude Code 对外发布的时候并没有立刻大获成功。它获得了一批用户，有很多早期采用者（early adopter）立刻就理解了它，但实际上花了好几个月，大家才真正弄明白这个东西是什么。还是那句话——它实在太不一样了。回想起来，Claude Code 之所以能成功，部分原因在于潜在需求这个概念——我们把工具带到用户所在的地方，让现有工作流程更顺畅一点；但也正因为它在终端里，这让它有点出人意料，有点像个外来物种，所以你需要保持开放的心态，也需要学着去使用它。当然，现在 Claude Code 已经可以在 iOS 和 Android 的 Claude 应用中使用了。可以在桌面应用中使用，可以在网页端使用，也可以作为 IDE 扩展在 Slack 和 GitHub 中使用。

说到底，这些都是工程师们如今更加熟悉的地方——但这并不是我们的起点。所以，一开始的时候，这东西能用，其实连我们自己都有点意外。随着团队壮大、产品成熟，越来越多人开始使用它——从全球各地的小型初创公司，到最大的 FAANG 大厂——他们开始用，也开始提反馈。回想这段经历，真的让我深感谦逊，因为我们一直在从用户身上学习。最令人兴奋的一点是：其实我们谁都不知道自己在做什么。我们只是在和大家一起摸索。而最好的参照，就是来自用户的反馈——这一直是最好的信号。我已经数不清被惊到了多少次。现如今，事情变化的速度真的令人叹为观止。

AI 改变软件开发的速度

Lenny Rachitsky: 你们一年前发布了这个产品，那也不是人们第一次能用 AI 来写代码。但短短一年之内，整个软件工程行业就发生了翻天覆地的变化。曾经有那么多预测——“AI 会写掉 100% 的代码”——大家当时都说：太疯狂了，你在说什么？如今呢，大家又说：这当然在发生，完全如他们所料。事情变化得就是这么快。

Boris Cherny: 去年五月，在"Code with Claude"大会上——那是 Anthropic 举办的第一届开发者大会——我做了一个简短的分享，在提问环节，有人问我对年底有什么预测。我在 2025 年五月给出的预测是：到年底，你可能不再需要集成开发环境（IDE）来写代码了，我们会开始看到工程师不再亲自动手写代码。我记得当时整个会场都倒吸了一口冷气，那个预测听起来太疯狂了。但在 Anthropic，这正是我们思考问题的方式——指数级增长——这已经深深烙入我们的 DNA。看看我们的联合创始人，其中三位是规模化定律（scaling laws）论文的前三作者。所以我们真的就是以指数思维来看世界的。如果你把当时 Claude Code 所写代码的占比画成指数曲线，顺着那条线往前推，很明显到年底就会突破 100%——哪怕这在直觉上完全说不通。我只是沿着那条线延伸下去而已。结果，十一月份，这件事在我个人身上就发生了，从那以后一直如此。我们也开始在越来越多的客户身上看到同样的情况。

Lenny Rachitsky: 你刚才分享的这段历程，我觉得有一点很有意思——那种"随便玩玩，看看会发生什么"的心态。在 Open Claude 这个项目上也经常是这样，Peter 当时就是随便捣鼓，然后一个东西就冒出来了。这种心态，感觉是 AI 领域很多重大创新的核心要素：一群人坐在那里，不断尝试，把模型推向其他人很少触及的边界。

实验精神在 AI 创新中的重要性

Boris Cherny: 这就是创新的本质——你没办法强求它。创新没有路线图，你只能给人们留出空间。你需要给他们——也许用"安全感"这个词更合适——心理安全感（psychological safety），让他们知道失败没关系，80% 的想法是烂的也没关系。但同时也要适度问责：如果一个想法行不通，就要止损，转向下一个，而不是继续往里砸资源。Claude Code 刚起步的时候，我完全不知道这东西会不会有任何用处。因为即使是二月份发布的时候，它大概也只写了我 20% 的代码，仅此而已。到了五月份，可能也就到 30%。我大部分代码还是用 Cursor 写的。直到十一月份才突破了 100%。所以这花了不短的时间。但从最早的那一天起，我就有一种感觉——感觉自己摸到了什么。我每天晚上、每个周末都在埋头捣鼓这个东西。幸运的是，我太太非常支持。但那种感觉一直都在——感觉抓住了什么，只是还说不清楚是什么。有时候，你找到了一根线头，就只能顺着它一路拉下去。

Boris 当前的编程工作流（100% 由 AI 编写）

Lenny Rachitsky: 所以现在，你 100% 的代码都是由 Claude Code 来写的——这就是你目前的编程状态？

Boris Cherny: 是的。没错，我 100% 的代码都由 Claude Code 来写。我是个相当高产的程序员。哪怕是在 Instagram 工作的时候，我也是产出最高的几位工程师之一。而这一点，在 Anthropic 至今依然如此。

Lenny Rachitsky: 哇。即使已经是团队负责人了。

Boris Cherny: 对，还是写很多代码。每天我大概会提交十几、二十、三十个拉取请求（PR），差不多这个量级，每天都是。

Lenny Rachitsky: 每天都是。对。天哪。

Boris Cherny: 100% 由 Claude Code 编写。自从十一月份以来，我就再没有手动改过一行代码。就是这样。不过我还是会看代码。我不认为我们已经到了可以完全撒手不管的阶段，尤其是当有很多人在运行这个系统的时候。你还是得确保代码是正确的、是安全的，等等。我们也让 Claude Code 对所有内容进行自动代码审查。在 Anthropic，Claude Code 会审查 100% 的拉取请求（PR）。之后还有一层人工审查，但你还是希望保留这些检查节点——还是希望有人亲眼看一遍代码——除非是那种纯原型代码，根本不会实际运行在任何地方，就只是个原型。

下一个前沿

Lenny Rachitsky: 那下一个前沿是什么？现在你 100% 的代码都由 AI 来写，这显然是整个软件工程行业的走向。这曾经感觉像个疯狂的里程碑，如今却成了理所当然的现实。那么，在软件编写方式上，下一个重大转变是什么？是你的团队已经在探索的，还是你认为即将到来的？

Boris Cherny: 我觉得现在正在发生的一件事是：Claude Code 开始自己提出想法了。它在浏览用户反馈、查看 bug 报告、查看遥测数据（telemetry）等，然后开始提出 bug 修复建议和需要开发的功能。它正慢慢变得有点像一位同事了。第二件事是，我们开始在编程之外有所拓展。我认为，就目前而言，编程这件事基本上已经是个解决了的问题——至少对于我所做的这类编程来说，它就是一个已解决的问题，因为 Claude Code 能做到。

所以现在我们开始思考：下一步是什么？超越编程之后还有什么？有很多与编程相邻的领域，我认为这些都将相继到来。但也包括各种通用任务——我现在每天都在用 Cowork 来处理各种与编程完全无关的事情，全程自动完成。举个例子，前几天我需要缴一张停车罚单，直接让 Cowork 去处理了。团队的所有项目管理工作，也全部由 Cowork 包办——在电子表格之间同步数据、在 Slack 上联系相关人员、收发邮件，诸如此类。所以我认为，前沿方向是这样的，而不再是编程——因为编程基本上已经解决了。在未来几个月里，整个行业都会看到这一点：无论是哪种代码库、哪种技术栈，编程问题都将越来越趋近于完全解决。

Lenny Rachitsky: “帮你想清楚该做什么”——这个想法真的很有意思。听众中有很多产品经理，他们现在可能已经开始冒冷汗了。你是怎么用 Claude 做这件事的？直接对话吗？你有没有摸索出什么聪明的方式，帮助你用它来决定构建什么？

Boris Cherny: 说实话，最简单的方法就是打开 Claude Code 或 Cowork，然后把它指向一个 Slack 频道。比如我们有一个专门收集 Claude Code 内部反馈的频道，自从 2024 年内部首次发布以来，那里就一直是滚滚而来的反馈洪流，棒极了。早期，每当有人发来反馈，我就会立刻进去，尽可能快地修复每一个问题——可能一分钟、五分钟之内就搞定。这种极快的反馈循环会鼓励人们给出越来越多的反馈，这一点至关重要——因为它让他们感到被倾听。通常，当你使用一个产品并给出反馈时，那些反馈就好像石沉大海，你也就不再反馈了。所以，如果你让人们感到被倾听，他们就愿意参与进来，帮助把产品做得更好。现在我也在做同样的事，只不过 Claude Code 承担了大部分工作。我把它指向那个频道，它就说：“好，这里有几件我能做的事，我刚提了几个拉取请求（PR），要看看吗？“我说：“好啊。”

Lenny Rachitsky: 你有没有注意到它在这方面正在快速进步？因为这才是真正的"圣杯”，对吧——现在的局面是：好，编程已经解决了。代码审查成了下一个瓶颈——这么多 PR，谁来一一审查？接下来最大的问题是：人类的价值究竟在于决定构建什么、确定优先级。而你说的正是 Claude Code 开始在这方面帮助你的地方。不管是 Opus 4.6 还是其他版本，它在这方面进步了很多吗？演进轨迹是怎样的？

Boris Cherny: 是的。是的，进步了很多。部分原因在于我们专门针对编程所做的训练。显然，它是世界上最好的编程模型，而且越来越好——4.6 就已经令人叹为观止。但实际上，我们在编程之外所做的许多训练，迁移效果也相当不错。存在一种迁移效应：你教模型做 X，它在 Y 方面也随之提升。过去这一年在 Anthropic 内部，收获简直令人咋舌——自从我们推出 Claude Code 以来，工程团队规模大概扩大了约 4 倍（具体数字我不太确定），但与此同时，每位工程师的生产力提升了 200%。就拉取请求（PR）的数量而言，这个数字对于真正在这一领域、在开发者效率方向工作过的人来说简直匪夷所思。我之前在 Meta，负责之一就是整个公司的代码质量——Facebook、Instagram、WhatsApp，所有这些代码库都是我的责任。而代码质量工作在很大程度上也关乎生产力，因为代码质量越高，工程师就越高效。我们当时看到的情况是：数百名工程师花上整整一年，生产力也不过提升几个百分点。所以，如今看到生产力提升以百分之几百来计算，真的是完全超越认知的。同样令人难以置信的是，这一切已经变得如此"正常”——我们听到这些数字，都觉得"当然了，AI 不就应该这样嘛”。但软件开发、产品构建、整个科技世界正在经历的变化，其剧烈程度是前所未有的，实在太容易让人习以为常了。所以我们必须清醒地认识到：这真的非常疯狂。

快速创新的代价

Boris Cherny: 这是我需要时不时提醒自己的事情。这件事也有一些"代价”——可以聊的方面有很多，但我认为在个人层面，有一点很突出：模型迭代太快，我有时会陷入固有的旧思维。我甚至发现，团队里的新人，乃至刚加入的应届毕业生，做事的方式有时比我更加"AGI 原生”。比如，几个月前我遇到了一个内存泄漏（memory leak）问题——Claude Code 的内存占用持续上升，到某个点就会崩溃。这是工程师调过无数次的经典问题，传统的做法是：抓一个堆快照（heap snapshot），放到专用调试器里，用这些专门的工具搞清楚发生了什么。我就是这样做的，坐在那里翻看调用链，试图找出根源。而团队里那位新来的工程师，直接让 Claude Code 去搞定，说：“嘿 Claude，看起来有内存泄漏，你能查出来吗？“于是 Claude Code 做了和我一模一样的事：抓了堆快照，还给自己写了一个小工具，方便自己分析——有点像一个"即时编写的程序”（just-in-time program）。它找到了问题所在，提交了拉取请求（PR），速度比我还快。所以，对于我们这些长期使用模型的人，还是要时刻把自己拉回到当下，不要停留在旧版模型的思维定式里——它已经不是 Sonnet 3.5 了，新模型完全是另一回事。这种思维方式的转变是非常深刻的。

Lenny Rachitsky: 我听说你为团队总结了一套非常具体的原则，每当有人加入，你都会带他们过一遍。其中一条好像是：“比自己做更好的是什么？让 Claude 来做。“感觉你刚才描述的内存泄漏，正好就是忘记了这条原则——忘记了先问一句：好，让 Claude 来试试能不能解决。还有一件有意思的事：当你在各方面资源都略显不足的时候，大家反而会被迫去"Claude 化”（Claudify）——这是我们观察到的现象。比如在工作中，有时我们只给一个项目配一名工程师，他们之所以能快速交付，是因为内心有一种驱动力——一种想把事情做好的内在动力。

Claude Code 团队的工作原则

Boris Cherny: 如果你有一个好主意，自然就会想把它付诸实践，不需要任何人来推动你——那股劲儿来自你自己内心。有了 Claude，你就可以用它自动化大量工作。这也是我们反复观察到的现象。所以我觉得，其中一条原则是：在资源上刻意保持略微欠配置。另一条原则是鼓励大家更快行动——如果今天能做到，就今天去做。这是我们团队非常非常强调的一点。早期这一点尤为重要，因为当时只有我一个人，我们唯一的优势就是速度。那是我们能在这个竞争极为激烈的编程市场中立足的唯一方式。但时至今日，这依然是我们团队坚守的重要原则。如果你想跑得更快，一个很好的方法就是让 Claude 来承担更多工作——这条原则本身也在持续鼓励这种做法。

Lenny Rachitsky: 这个"欠配置"的想法真的很有意思，因为通常大家的感觉是：AI 会让你不再需要那么多员工、那么多工程师。但你说的不只是"你可以变得更高效”——你的意思是，如果主动减少配置，你实际上反而能取得更好的成果。不仅仅是 AI 能让你跑得更快，而是在一个项目上配置的人更少，你反而能从 AI 工具中发挥出更大的价值。

Boris Cherny: 对，如果你招到了优秀的工程师，他们自然会想办法把事情搞定，尤其是当你给他们充分授权的时候。这一点我其实经常和各种公司的 CTO 以及各行各业的从业者聊。我通常给出的建议是：不要一开始就去优化，不要一开始就想着降本。先从一件事做起——给工程师提供尽可能多的 token。现在你开始看到，有些公司——比如 Anthropic——每个人都可以大量使用 token。“无限 token"也开始成为一些公司的福利待遇，加入就能享有。这一点我非常提倡，因为它让大家敢于去尝试那些"想想都觉得太疯狂"的想法。一旦有个想法跑通了，你再来考虑如何规模化，那才是优化和降本的时机——比如研究能不能换成 haiku 或 sonnet，而不是 opus，等等。但在最开始，你只想把大量 token 砸进去，看看这个想法是否可行，给工程师以自由去尝试。所以这里的建议就是：在使用这些模型的成本上，放开手，别太吝啬。

为何应给工程师提供无限量的 token

Lenny Rachitsky: 听到这话，可能会有人说：当然了，他在 Anthropic 工作，自然希望我们用越多 token 越好。但你真正想说的是：最有趣、最具创新性的想法，往往来自那些把工具用到极致、去探索边界在哪里的人。

Boris Cherny: 对。而且我觉得，从实际情况来看，在小规模阶段根本不会产生什么巨额账单之类的问题。一名工程师在做实验时，token 的成本相对于他的薪资，或者公司运营的其他开销来说，其实仍然相当低。所以在项目成长阶段，这实际上并不是一笔很大的开支。比方说，他们做出了很棒的东西，token 消耗量急剧增加，成本开始变得可观——那才是你要去优化的时机。但不要做得太早。

Lenny Rachitsky: 你有没有见过那种 token 成本超过薪资总额的公司？你认为这会成为一种趋势吗？

Boris Cherny: 在 Anthropic，我们已经开始看到一些工程师每月在 token 上的花费达到数十万美元。这种情况确实已经初现端倪。一些其他公司也开始出现类似的情况。

编程技能在未来还重要吗？

Lenny Rachitsky: 说回编程——你会怀念自己亲手写代码吗？作为一名软件工程师，你会对"这件事可能已不再是你分内之事"感到有些失落吗？

Boris Cherny: 说来有意思，对我来说，当初学工程是非常务实的——我学工程是为了能够做出东西。我是自学成才，大学学的是经济学，没学过计算机，但我很早就自己摸索着学了编程，大概从初中就开始写代码了，而且从一开始就极其务实。老实说，我学编程最初的原因——是为了在数学考试上作弊。那时候我们有图形计算器，我就把答案直接编程写进了 TI-83 里。

Lenny Rachitsky: TI-83 Plus 嘛。对，就是那款。

Boris Cherny: （笑）Plus 版，没错。就是这样，我把答案全编进去了。后来下一年的数学考试太难，没办法提前把所有答案都编进去，因为根本不知道题目考什么。于是我就写了一个小解题器——一个能自动求解代数题之类的小程序。后来我发现可以弄一根小数据线，把程序传给全班同学，结果全班都拿了 A。但后来被老师发现了，叫我们别再这么干。从最一开始，编程对我来说就始终是非常务实的——它是一种构建东西的手段，而不是目的本身。不过话说回来，我个人后来也曾深陷进编程本身的美感之中。比如我写了一本关于 TypeScript 的书，还创办了当时全球规模最大的 TypeScript 线下聚会，就是因为我爱上了这门语言本身。我也深入钻研过函数式编程（functional programming）等领域。我觉得很多程序员都会为之着迷。对我来说，编程确实有一种美——尤其是函数式编程；类型系统（type system）也有一种美；当你解开一道真正复杂的数学难题时的那种感觉，和你把类型对齐、写出一段格外优雅的程序时的感觉，是相通的。但它终究不是终点。对我而言，编程始终是一种工具，是一种做事的方式。

话虽如此，不是每个人都这么想。比如我们团队里有一名工程师 Lena，她周末还是会用手写 C++，就是因为她享受这个过程。每个人都不一样。我觉得，即使这个领域发生了翻天覆地的变化，即使一切都在改变，始终会有空间去享受编程这门艺术，去用手工方式完成一些事情——只要你愿意。

Lenny Rachitsky: 你会担心自己的工程师技能日渐退化吗？还是说，你觉得这就是大势所趋，顺其自然就好？

Boris Cherny: 我觉得这就是事情发展的规律，我个人并不太担心这个。对我来说，编程是一个不断演进的连续体。回溯历史，软件其实算是相当新鲜的事物——如果你看看今天程序的编写方式，比如运行在虚拟机（virtual machine）上的软件，这种模式大概从 1960 年代就存在了，算来大约六十年了。在这之前是打孔卡（punch cards），在打孔卡之前是拨动开关，在那之前是硬件本身。在那之前，就是字面意义上的纸和笔——一屋子的人，在纸上进行数学运算。所以说，编程一直都在以这种方式演变。从某种程度上看，你仍然需要了解底层之下的底层，因为这能帮你成为更好的工程师。我认为，大概再过一年左右，情况仍然如此。但我觉得，很快这就不再重要了——就好像汇编代码（assembly code）只是在程序员所写的程序底下默默运行，诸如此类。从情感层面来说，我觉得自己一直都在不断学习新事物。而作为程序员，这其实感觉并不新鲜，因为总会有新的框架、新的语言不断涌现——这是这个领域早已习以为常的事。但话说回来，并非所有人都有这种感受。我想对某些人来说，他们会产生更强烈的失落感、怀旧感，或者技能退化的焦虑，诸如此类。

Lenny Rachitsky: 不知道你有没有看到，Elon 说过：AI 为什么不直接写二进制（binary），直接输出二进制代码？因为，那些编程抽象（programming abstraction）层，最终到底有什么意义？

Boris Cherny: 这是个好问题。我的意思是，如果你想的话，它完全可以做到。

印刷机：AI 冲击的历史类比

Lenny Rachitsky: 哇。那我理解的是——“我该不该学编程？学校里的孩子该不该学编程？“这个问题总是被反复提起。从你的说法来看，你的观点是：大概一两年之内，其实不需要了。我的看法是：对于今天正在使用 Claude Code、使用智能体来编程的人，你仍然需要理解底层逻辑；但一两年之后，这也不会重要了。

Boris Cherny: 我一直在想，历史上有什么合适的类比——因为我们需要把这件事放到历史的坐标系中，搞清楚我们曾经历过哪些类似的转变，什么样的心智模型最贴切。我觉得最接近的类比就是印刷机（printing press）。你看，如果观察 15 世纪中叶的欧洲，当时的识字率（literacy）其实非常低，不到人口的 1% 识字，能读能写的只有抄写员（scribes）——他们包揽了所有的写作和阅读工作。他们受雇于那些往往自己也不识字的领主和国王。所以说，这项工作只属于极少数人。后来，Gutenberg 和印刷机横空出世——有一个惊人的数据：印刷机发明后的五十年间，印刷品的产量超过了此前一千年的总和。印刷品的数量急剧攀升，成本则急剧下降，在随后的五十年里降低了约一百倍。再看识字率，它的提升其实花了相当长的时间，因为学习读写本来就不容易：需要完整的教育体系，需要闲暇时间，需要人们不必整日在农田里劳作，才能有时间接受教育。但在随后的两百年间，全球识字率上升到了约 70%。我认为，我们现在正在经历的，可能就是一场类似的转变。

有一份很有意思的历史文献，记录了一位 15 世纪抄写员对印刷机的看法——他其实非常兴奋。他说：我真正不喜欢做的，是在书籍之间抄写誊录；我真正喜欢的，是在书中绘制插图和装订书籍。现在我的时间被解放出来了，我真的很高兴。有趣的是，作为工程师，我对此深有同感——我现在不再需要做那些繁琐的编码工作了，而那些繁琐的细节，一直都是编程让人头疼的地方。那些琐碎的部分——折腾 git、捣鼓各种工具——从来都不是编程有趣的地方。有趣的地方在于：想清楚要构建什么、提出创意、与用户交流、思考大型系统、展望未来、与团队成员协作。而这些，正是我现在可以花更多时间去做的事情了。

Lenny Rachitsky: 而令人惊叹的是，你们正在构建的这个工具，让任何人都能做到这一切。哪怕完全没有技术背景的人，也能做到你所描述的。我最近一直在做各种零散的小项目，每次卡住了，就说"帮我解决这个”，然后问题就迎刃而解。我以前职业生涯早期做了十年工程师，记得当时在库（libraries）、依赖项（dependencies）这些问题上耗费了大量时间，一边抓狂一边去 Stack Overflow 找答案。而现在，只需要说"帮我解决这个”，然后一二三四，一步步就搞定了。

Boris Cherny: 是啊——完全是这样。今天早些时候我跟一个工程师聊天，他正在用 Go 写一个服务，已经写了大概一个月了，服务运行得相当不错。我问他：写起来感觉怎么样？他说，你知道吗，我其实还是不太懂 Go……（笑）我觉得这样的情况会越来越多。就是说，只要你知道它运行正确、运行高效，你其实不需要了解所有细节。显然，软件工程师的工作已经发生了翻天覆地的变化——过去这一两年，这简直是一份全新的职业了。

AI 将颠覆哪些岗位？

Lenny Rachitsky: 你认为，接下来哪个岗位会受 AI 冲击最大？是科技行业内部——比如产品经理、设计师——还是科技行业之外？你觉得 AI 下一步会渗透到哪里？

Boris Cherny: 我觉得会是很多与工程相邻的岗位。比如产品经理、设计师、数据科学家。这种趋势将扩展到几乎所有可以在电脑上完成的工作，因为模型只会越来越擅长处理这类任务。Cowork 这款产品算是打开这扇门的第一步，但也只是第一步。我认为它的意义在于，将智能体 AI 带到了那些此前从未接触过的人面前，让他们第一次开始对此有所感知。回想一年前的工程圈，没有人真正知道智能体（agent）是什么，也没有人真正用过它。但如今，这已经是我们日常工作的方式了。再看今天非技术类的工作，比如产品工作，或者数据科学这类半技术性的工作——你会发现，人们使用的 AI 始终都是对话式 AI（conversational AI），就是聊天机器人之类的东西，从来没有人真正用过智能体。“智能体"这个词被反复滥用，已经快失去意义了——但"智能体"其实有非常明确的技术含义：它是一种能够使用工具的 AI，是一种能够调用工具的语言模型（LM）。它不只是会说话，它实际上能够行动，能够与你的系统交互——这意味着它可以使用你的 Google Docs，可以发邮件，可以在你的电脑上运行命令，做各种各样的事情。所以我认为，凡是需要以这种方式使用计算机工具的工作，都将是下一波被波及的领域。这是我们作为社会整体、作为一个行业，需要共同思考和解决的问题。对我来说，这也是为什么在 Anthropic 做这项工作感觉如此重要、如此紧迫的原因之一——因为我们对此非常非常认真。所以现在，我们有了经济学家，有了政策方面的人员，有了社会影响方面的人员，这是我们希望大量讨论的议题，这样作为社会，我们才能共同想出应对之道——因为这不该只由我们来决定。

Lenny Rachitsky: 所以你所暗示的核心问题，是就业和工作流失之类的问题。这里有个概念叫杰文斯悖论（Jevons Paradox）——当我们能做的事情越来越多，我们就会雇用越来越多的人，所以实际上没有看起来那么可怕。你目前在工程领域亲身经历了什么？AI 已经成为工程工作的重要组成部分，你们是否比没有 AI 时雇用了更多的人？对就业问题有什么看法？

Boris Cherny: 嗯，就我们团队而言，我们确实在招人。Claude Code 团队正在招聘，如果你感兴趣，去 Anthropic 的招聘页面看看吧。就我个人而言，这一切只是让我更享受自己的工作了。我从来没有像今天这样享受写代码这件事，因为我不必再应付那些繁琐的细节。所以对我个人来说，这一切都令人非常兴奋。我们也从很多用户那里听到了同样的感受——他们喜欢这个工具，他们喜爱 Claude Code，因为它让写代码重新变得令人愉快。这对他们来说真的太有趣了。但这件事将走向何方，实在难以预料。我还是忍不住要借助历史类比来思考。我觉得印刷机（printing press）是一个非常贴切的例子——它所带来的，是一项原本只掌握在少数人手中的技术——比如读写能力（literacy）——向所有人敞开。它本质上是一股民主化的力量，每个人都开始能够做到这件事。如果不是这样，文艺复兴根本就不可能发生，因为文艺复兴在很大程度上，正是关于知识的传播，关于人们用来沟通交流的书面记录——毕竟那个年代没有电话之类的东西。那个时代也没有互联网。所以关键在于：这会开启什么样的可能？对我来说，这就是非常乐观的那一面，也是我真正感到兴奋的部分。那是难以想象的——就像我们今天能够坐在这里对话，如果没有印刷机的发明就不可能实现；我们的麦克风也不会存在。我们周围的一切都不会存在。如果没有那项技术，就根本不可能协调如此庞大的人群。所以我设想一个几年后的世界，人人都能编程——那会解锁什么？任何人都可以随时构建软件。我完全不知道会发生什么。就像 1400 年代没有人能预测此后的一切一样，我想现在也是如此。但我确实认为，在此期间会有很大的冲击，对很多人来说将是一段痛苦的过渡。同样，作为一个社会，这是我们必须进行的对话，是我们必须共同解决的问题。

AI 时代的成功之道

Lenny Rachitsky: 那么，对于听到这里、想在我们即将进入的这个动荡时代中立于不败之地的人，有什么建议？是应该多玩 AI 工具、真正精通最新的东西吗？还是有什么其他建议，能帮助人们保持领先？

Boris Cherny: 嗯，我觉得基本上就是这样——多尝试工具，去了解它们，不要害怕它们，直接投入进去，走在最前沿，走在边界之上。也许第二条建议是：比以往更努力地成为一个通才（generalist）。比如在学校里，很多学计算机的人学会了编程，但除此之外几乎什么都没学，也许学了一点系统架构之类的东西。但我每天共事的最有效率的工程师，以及最有效率的产品经理等等，都是跨学科的人。就在 Claude Code 团队，每个人都写代码——产品经理写代码，工程经理写代码，设计师写代码，财务人员写代码，数据科学家写代码。团队里每个人都写代码。而如果我看具体的工程师，很多人都横跨不同领域。最优秀的工程师往往是产品与基础设施兼修的复合型工程师，或者是具有出色设计感、同样能胜任设计工作的产品工程师；或者是对业务有深刻理解、能够以此判断下一步方向的工程师；又或者是热爱与用户交流、能够真正感知用户需求、从而找到前进方向的工程师。所以我认为，在未来几年里获得最多回报的人，不仅仅是 AI 原生用户、不仅仅是非常擅长使用这些工具的人——他们同时也是充满好奇心的通才，能够横跨多个领域，能够从更宏观的视角思考他们正在解决的问题，而不只是局限于工程层面。

Lenny Rachitsky: 你是否认为这三个独立的职能——工程、设计、产品管理——作为思考团队的框架，依然有其价值？尽管这些人现在都在写代码、都在参与思考应该构建什么，但你认为这三种角色从长远来看还会持续存在吗，至少在目前阶段？

Boris Cherny: 我认为短期内会继续存在，但我们已经开始看到一个现象：这些角色之间大概有 50% 的重叠——很多人实际上在做着相同的事情，只是各有各的专长。比如我写的代码多一点，而我们的 RPM Cat 也许更多地负责协调、规划或预测之类的事情。

Lenny Rachitsky: 利益相关方的协调对齐（Stakeholder alignment）。

Boris Cherny: 利益相关方的协调对齐，正是如此。我确实认为存在这样一个未来——我想到今年年底，我们就会开始看到这些边界越来越模糊：在某些地方，“软件工程师"这个头衔将开始消失，取而代之的也许是"构建者”（builder），或者也许所有人都将是产品经理，同时所有人都写代码——诸如此类。

Lenny Rachitsky: 谁说招聘必须公平？如今我接触的每一位创始人和招聘经理都感受着同样的压力：要尽快招到最优秀的人才。但招聘耗时耗力，协调对齐（alignment）难度极大，顶尖人才的竞争也愈演愈烈。正因如此，11 Labs、Brex、Replit、Deal 等 5,000 多家企业选择了 MetaView——这家 AI 公司正在为高绩效团队提供招聘领域真正的"不公平优势”。MetaView 为你提供一套像招聘同事一样运转的 AI 智能体：根据你的精确标准寻找候选人、自动记录面试笔记、从整个招聘流程中提炼洞察，并帮你锁定候选人池中的最佳人选。AI 接管繁琐的招聘事务，给你提供一个真实可信的信息来源。这意味着每次招聘节省数小时，让团队聚焦于最重要的事——赢得合适的候选人。别让竞争对手在招聘上超越你。MetaView 的客户关闭职位的速度快 30%。立即免费试用 MetaView，前往 metaview.ai/lenny 还可获得额外一个月的人才挖掘服务。那说的就是我了。

调查：哪些岗位因 AI 而更享受工作

Boris Cherny: Lenny，你说过你现在更享受写代码了。我其实在 Twitter 上做了一个小型非正式调查，不知道你有没有看到——我发起了三个不同的投票。我问工程师们：自从使用 AI 工具以来，你是更享受工作了，还是不如以前？然后分别对产品经理和设计师做了同样的调查。结果是，工程师和产品经理中都有 70% 的人说更享受工作了，约 10% 的人说没以前享受了。而设计师的情况颇为有趣：只有 55% 的人说更享受工作了，20% 的人说没以前享受了。我觉得这真的很耐人寻味。

Lenny Rachitsky: 这非常有意思。我很想和这些人聊聊——无论是那些"更享受"的，还是那些"没以前享受"的——去真正了解一下原因。你有没有机会跟进他们？

Boris Cherny: 有几个人回复了，我们其实正在做一个深度跟进的调查，会放在节目注释里，进一步探讨让工作变得更有趣或更无趣的因素。但对于说工作变得没以前有趣的设计师，他们留下的回复其实不多——那些被具体问到"为什么你不再享受工作"的人，几乎没有多少给出回应。

Lenny Rachitsky: 所以我也很好奇背后究竟发生了什么。

Boris Cherny: 是的，这也是我在 Anthropic 观察到的一点。我认为 Anthropic 的每个人技术背景都相当扎实——这是我们招聘时的筛选标准之一。即便是非技术岗位，员工在入职时也要经历大量技术面试。我们的设计师大多数都会写代码。所以从我的观察来看，他们对 AI 工具是相当享受的——因为现在他们不用再去麻烦工程师，直接自己就能下场写代码了。甚至一些之前不会写代码的设计师，现在也开始动手了，对他们来说太棒了，因为可以自行解除阻碍、推进工作。不过我真的很想听到更多人的亲身经历，因为我相信这绝对不是整齐划一的。

Lenny Rachitsky: 是啊。所以如果你正在收听这期节目，不妨在评论区留言——如果你觉得工作变得没以前有趣了，说说原因吧。因为从你说的、以及我听到的大多数反馈来看，70% 的产品经理和工程师都更享受工作了。如果你不在这个阵营里，那肯定是有什么原因在里面。

产品开发中的潜在需求原则

Boris Cherny: 对。是的。我们也确实看到大家在使用不同的工具。比如，我们的设计师更多地通过 Claude 桌面应用来写代码——你只需下载桌面 App，里面有一个代码标签页，就在 Cowork 旁边，本质上运行的是完全相同的 Claude Code、同一个智能体，功能一模一样。这个功能已经上线很多个月了。你可以用它来写代码，而不必打开一堆终端（terminal），同时又保留了 Claude Code 的全部能力。最大的亮点是，你可以同时并行运行任意数量的 Claude 会话——我们把这叫做"多开 Claude”（multi-Clauding）。对于非工程师背景的用户来说，这种方式更加自然顺手。而这背后的逻辑，归根结底还是：把产品带到用户所在的地方。你不该强迫用户改变工作流程，也不该让他们费力去学一套全新的东西。只要能让用户正在做的事情变得稍微轻松一点，产品体验就会大幅提升。这正是潜在需求（latent demand）原则的精髓——我认为这是产品领域最重要的单一原则。

Lenny Rachitsky: 你能展开讲讲吗？因为我也正想聊到这个话题。能解释一下这个原则是什么，以及真正释放潜在需求之后会发生什么吗？

Boris Cherny: 潜在需求的概念是这样的：如果你构建的产品，可以被人们以一种并非设计初衷的方式来"破解"或"滥用”，用来完成某种他们真正想做的事，那么这恰恰能帮助你作为产品构建者判断下一步该把产品带向何处。一个典型的例子是 Facebook Marketplace。那个团队的负责人 Fiona，她是 Marketplace 团队的创始负责人，她经常谈到这件事。Facebook Marketplace 的诞生，源于大约 2016 年前后的一个观察：Facebook 群组中有 40% 的帖子都是买卖商品的内容。这简直太疯狂了——人们在"滥用"Facebook 群组功能来进行买卖交易。这里的"滥用"并不是安全层面的滥用——而是指没有任何人把这个产品设计成用来买卖的，但用户自己摸索出了这种用法，因为它实在太好用了。所以很显然，如果你专门做一个更好用的买卖产品，用户一定会喜欢。Marketplace 的成功几乎是板上钉钉的事。于是第一步是推出"买卖群组"——专为买卖行为定制的特殊群组；第二个产品才是 Marketplace 本身。Facebook 交友（Facebook Dating）我认为起点也大同小异。当时的观察是：如果查看用户的主页浏览记录，会发现 60% 的主页浏览发生在互相不是好友、但性别相反的用户之间。这就是一种传统意义上"相亲配对"的雏形，只不过用户是在悄悄查看彼此的主页。所以想着，如果能专门为这种行为做一个产品，或许会奏效。这种潜在需求的思路，我认为是极为强大的。

Cowork 的诞生也是同样的逻辑。过去六个月左右，我们观察到大量使用 Claude Code 的人，用它做的根本不是写代码的事情：有人在 Twitter 上用它种西红柿，有人用它分析自己的基因组，有人用它从损坏的硬盘里恢复照片——是婚礼照片——还有人用它分析核磁共振（MRI）图像。各种完全不涉及技术的使用场景，层出不穷。信号太明显了：人们正在费尽周折地使用一个终端（terminal）来做这些事情——或许我们该直接为他们做一款专门的产品。其实我们很早就注意到了这个信号，大概是去年五月的事。我记得走进办公室，看到我们的数据科学家 Brendan 正在电脑上用 Claude Code——他打开了一个终端（terminal）。我当时惊呆了，就问他：“Brendan，你在干什么？你居然知道怎么打开终端——这可是面向工程师的产品啊。”

Lenny Rachitsky: 就连很多工程师都不愿意用终端。终端就是最底层的操作方式，真的是要钻进计算机最深处。

Boris Cherny: 结果他不仅学会了用终端，还下载了 Node.js、下载了 Claude Code，然后在终端里跑 SQL 分析——太疯了。下一周，所有数据科学家都开始照做。所以，当你看到有人这样"滥用"一款产品——用一种它根本没有预设的方式，来完成对自己有用的事——这就是一个极强的信号：你应该直接为此构建一款产品，人们一定会喜欢这个专门为此而生的东西。

我认为，潜在需求还有另一个有趣的维度。传统视角是：观察人们在做什么，把它变得更简单，赋予他们更大的能力。而我过去六个月看到的现代视角稍有不同：观察模型在尝试做什么，然后把它变得更简单。我们最初构建 Claude Code 的时候，很多人设计语言模型产品的思路是把模型装进一个"盒子"里——“这是我想构建的应用，这是我想做的事，模型，你只负责其中这一个组件，按照这种方式与这些工具和 API 交互。“而对于 Claude Code，我们把这个逻辑翻转了。我们说：产品就是模型本身。我们要把它充分暴露出来，在它周围搭建最少的脚手架，给它最精简的工具集。这样它就能自己做决定：运行哪些工具、以什么顺序运行，等等。我认为，这在很大程度上源于对模型"潜在需求"的洞察。在研究领域，我们把这叫做"在分布内”（on distribution）——观察模型本身想做什么。在产品领域，“潜在需求"不过是同一个概念，只是把它应用到了模型身上。

Cowork 诞生记：10 天极速构建

Lenny Rachitsky: 你提到了 Cowork——我记得你在发布时谈到，你们团队仅用 10 天就把它做出来了。太疯狂了。而且上线之后很快就有数百万用户——这样一款产品居然是 10 天做出来的。能多聊聊吗？还是说一切就归结于"我们用 Claude Code 来构建它"这么简单？

Boris Cherny: 对，说来有趣。Claude Code 就像我之前说的，发布之初并没有立刻火起来，而是随着时间推移才逐渐成为爆款。其间经历了几个关键拐点：Opus 4 发布时有一次明显跃升，11 月又有一次，之后就一直在拐——增长曲线每天都在变得更陡。但在最初的几个月，它并不算爆款：人们在用，但很多人搞不清楚怎么用、用来做什么，模型本身也还没那么出色。Cowork 发布的时候完全不同——立刻就火了，比 Claude Code 早期的势头猛得多。说实话，功劳主要得归于 Felix、Sam、Jenny 和整个团队，这真的是一支极其出色的队伍。而 Cowork 的诞生，同样源于潜在需求。我们看到人们用 Claude Code 做各种非技术性的事情，就开始思考：我们该怎么办？团队花了几个月探索，尝试了各种各样的方向。最终有人提出：“要不这样——直接把 Claude Code 放进桌面应用里？“结果，这个方案奏效了。于是团队在 10 天内全程用 Claude Code 来构建它。值得一提的是，Cowork 内置了一套相当复杂的安全系统和防护机制，确保模型不会"脱轨”。比如，我们随产品内置了一整个虚拟机（virtual machine），而这些代码全部由 Claude Code 编写完成。我们只需要思考：怎么让它对非工程师用户来说更安全、更自主？整个实现完全依靠 Claude Code，历时 10 天。我们选择提前发布——产品当时还比较粗糙，现在也还有不少毛边。但这正是我们学习的方式——无论是产品层面还是安全层面——我们必须比自己预想的更早发布，这样才能收到反馈，才能和用户对话，才能理解人们真正想要什么，进而塑造产品未来的走向。

Anthropic 的 AI 安全三层架构

Lenny Rachitsky: 这个观点非常有意思，也非常独特。“提早发布、向用户学习、获取反馈、持续迭代”——这个理念一直都有。但对于 AI 来说，还有一个独特的理由促使你更早发布：你很难预判 AI 究竟能做什么、人们会如何使用它。这正如你所描述的——提早发布能帮你探索"这个东西里到底藏着什么潜在需求”，把它放出去，看看人们会做什么。

Boris Cherny: 对。而对于 Anthropic 这样一个以安全为核心的实验室来说，提早发布还有另一个维度——安全。在模型安全领域，有几种不同的研究方式。最底层是对齐（alignment）与机制可解释性（mechanistic interpretability）：这发生在训练模型的阶段，我们要确保模型是安全的。目前我们已经拥有相当成熟的技术，能够理解神经元内部发生了什么，并对其进行追踪。比如，如果某个神经元与"欺骗"相关，我们就能对它进行监控，并在它被激活时感知到。这就是对齐，这就是机制可解释性——这是最底层。第二层是实验室环境：把模型放进"培养皿"里，用合成场景来研究它——“模型，这种情况下你会怎么做？你做的是正确的事吗？是否对齐？是否安全？“第三层则是观察模型在真实世界中的行为表现。随着模型越来越复杂，这一层变得愈发重要——因为模型在前两层表现良好，并不代表在第三层也没问题。我们之所以很早就发布 Claude Code，正是为了研究安全——在对外发布之前，我们在 Anthropic 内部使用了大约四五个月，因为我们当时并不确定……毕竟这是当时业界发布的第一个重量级 AI 智能体（agent）。它绝对是第一个被广泛使用的编程智能体（coding agent）。我们当时确实不确定它是否安全，所以在内部实际研究了相当长一段时间，直到觉得可以放心发布为止。即便在此之后，我们在对齐和安全方面也学到了很多，并不断将这些成果反哺回模型和产品中。Cowork 的情况非常相似——模型处于全新的使用场景中，承担的是非工程类任务，是一个代表你行动的智能体（agent）。从对齐角度看，表现良好；从评估（eval）角度看，也没问题；内部试用，良好；与几个客户试用，同样良好。现在，我们需要确保它在真实世界中是安全的。这也是我们略微提前发布的原因，也是我们将其称为"研究预览版"的原因。但这确实在持续改进。这也是唯一能确保模型长期对齐、长期做正确事情的方式。

Lenny Rachitsky: 你们所处的领域真的太疯狂了——既有激烈的竞争和飞快的节奏，与此同时又存在一种恐惧：AI 一旦失控，就可能造成破坏——在这之间寻找平衡，一定极具挑战性。我所听到的是，你们似乎构建了三个层次——我知道这个话题可以单独撑起一整期播客——就是你们如何看待安全问题。大致来说：一是观察模型的思维与运作过程；二是通过测试和评估来判断模型是否在做有害的事情；三是提前发布。关于第一层，我其实听到的不多，但那太酷了——你们有一个可观测性工具，能让你们"窥视"模型的大脑，看看它在思考什么、将要走向哪里？

Boris Cherny: 对，你应该找机会请 Chris Ola 来上播客，因为他是这个领域公认的行业专家。他发明了我们所说的机制可解释性（mechanistic interpretability）这个领域。其核心思想是：你的大脑到底是什么？它是由一堆相互连接的神经元组成的。就像研究人类大脑或动物大脑一样，你可以从机制层面去研究它，理解神经元在做什么。令人惊讶的是，这套方法在很大程度上也适用于模型。模型的神经元与动物的神经元并不相同，但在很多方面行为相似。因此，我们学到了大量关于这些神经元工作方式的知识——比如某一层或某个神经元对应某个概念，特定概念是如何被编码的，模型是如何进行规划的，如何"向前思考"的。很久以前，我们还不确定模型究竟只是在预测下一个 token，还是在做更深层次的事情。现在，我认为有相当有力的证据表明，它确实在做更深层次的事情。而随着模型越来越大，实现这一点的结构也越来越精密——并非单一神经元对应单一概念，一个神经元可能对应十几个概念，而当它与其他神经元共同被激活时，这种现象就叫做叠加（superposition）。多个神经元叠加在一起，共同表征更为复杂的概念。这是我们始终在持续探索的领域。对于 Anthropic 来说，以安全、对世界有益的方式推动这一领域发展，正是我们存在的根本原因，也是每一位 Anthropic 人选择来到这里的原因。在这里工作的每一个人，都是因为这个原因而来的。因此，我们实际上将大量这类研究成果开源，频繁发表论文，非常公开地进行分享——希望借此激励其他从事类似工作的实验室，以安全的方式推进研究。这正是我们在 Claude Code 上一直践行的理念，我们在内部将其称为"争先竞优”（race to the top）。比如，针对 Claude Code，我们发布了一个开源沙箱（sandbox），可以在其中运行智能体，确保其在特定边界内操作，防止它随意访问你系统上的所有内容。我们将这个沙箱开源，而且它可以与任何智能体配合使用，不仅限于 Claude Code——因为我们希望让其他人也能轻松做到同样的事情。这正是"争先竞优"原则的体现。我们希望确保这件事朝着好的方向发展，而这就是我们手中的杠杆。

智能体"卡壳"时的焦虑感

Lenny Rachitsky: 太棒了。好，我确实想在这个话题上多花些时间，我会跟进这个建议的。另外，我在这个领域——以及在工程师、产品经理和其他与智能体协作的人群中——注意到一个现象：当智能体无法正常工作时，人们会产生一种焦虑感。那种感觉就像：“哦天哪，Nza 提了个问题，我得去回答，否则它就卡住了。“或者是：“它卡在某个地方了，我在损失大量生产力，我得赶紧起来让它重新运转。“你有这种感觉吗？你的团队有这种感觉吗？你认为这是一个需要关注和思考的问题吗？

Boris Cherny: 我现在一直有一堆智能体在跑。比如此刻，我大概有五个智能体在同时运行。每次醒来，第一件事就是去查看之前挂起的那些智能体。今天早上一醒来，我第一个念头就是：“我真的很想看看那个东西。“于是我打开手机上的 Claude iOS 应用 Code 标签页，查看智能体的执行情况——因为昨天写了一些代码，心里一直在琢磨：这样做对吗？我有点自我怀疑，结果发现是对的。现在做这些真的太方便了。所以说，这种焦虑感确实有一点，只是我个人可能感受不那么强烈，因为我的智能体一直都在跑。而且我现在也不再局限于终端（terminal）了。大概三分之一的代码工作在终端里完成，三分之一在桌面端应用，还有三分之一在 iOS 应用上——这让我非常惊讶，因为我完全没想到在 2026 年竟然会以这种方式编程。

Lenny Rachitsky: 我喜欢你仍然把这称为"编程”（coding），它本质上就是跟 Claude Code 描述你想要什么，然后让它替你写代码。有趣的是，这现在就是编程的定义——编程，是描述你想要什么，而不是亲手写代码。

Boris Cherny: 我有时候会想，那些曾经用打孔卡编程的人，如果让他们看看今天的软件，会说些什么。这不是很疯狂吗？我记得读到过一些东西——大概是早期 ACM 杂志之类的出版物——有人在上面说：“这不一样，这根本算不上编程。“你知道，他们那时候叫它 programming，coding 其实是个相对较新的说法。不过我常常会想到一件事——我家人来自苏联，我出生在乌克兰，我的祖父实际上是苏联最早的一批程序员之一，他用打孔卡编程。他告诉我妈妈——或者说，我妈妈在我成长过程中讲起这些故事——说他会把那些打孔卡带回家，一大摞一大摞的。对我妈妈来说，她小时候会拿蜡笔在上面乱涂乱画，那是她童年的记忆；但对他来说，那就是编程本身的体验。他其实从未亲眼见证软件时代的到来，但在某个时间节点，这场转变确实发生了。我想，那一代的老程序员里，大概有人就是没把软件当回事，会说：“这不算真正的编程。“但我觉得，这个领域一直就是这样不断变化的。

Boris 的乌克兰情缘

Lenny Rachitsky: 你可能不知道，我也出生在乌克兰。

Boris Cherny: 哦，真的吗？哪里？

Lenny Rachitsky: 我来自敖德萨（Odessa）。

Boris Cherny: 哦，我也是。

Lenny Rachitsky: 〔笑声〕什么？

Boris Cherny: 是真的，太巧了。

Lenny Rachitsky: 哇，太不可思议了。真是难忘的时刻。说不定我们还有那么一点渊源呢。你们是哪年离开的？

Boris Cherny: 我们是 95 年来的。

Lenny Rachitsky: 好的，我们是 88 年走的，早了一些。

Boris Cherny: 哦，是啊。

Lenny Rachitsky: 如果当初没有离开，生活会截然不同，对吧？

Boris Cherny: 是的。我每天都感到无比幸运，能够在这里长大。

Lenny Rachitsky: 是啊。

Boris Cherny: 我家人每次喝酒或者吃顿饭，都会举杯说"敬美国”——我就说，好了好了，够了。但你懂的，一旦你真的开始想象，另一种人生可能会是什么样子……

Lenny Rachitsky: 是的，完全理解。我们也举同样的祝酒词，不过还是用伏特加。

Boris Cherny: 还是伏特加，当然。〔笑声〕

Lenny Rachitsky: 好，我还想再问你几件事。你分享了很多关于如何充分利用 AI、如何基于 AI 打造优秀产品的实用建议。其中一点是：给团队充足的 token，放手让他们去实验。你还分享了一个整体原则：朝着模型将要去的方向构建，而不是针对今天的模型。还有哪些建议，想分享给正在尝试打造 AI 产品的人？

构建 AI 产品的建议

Boris Cherny: 我大概还有几点想补充。第一点是：不要试图把模型框死。我发现很多人在基于模型构建系统时，本能反应是让它严格遵循某种固定方式——“这只是更大系统中的一个模块。“典型的例子，是在模型上叠加非常严格的工作流程：规定它必须先执行步骤一，再执行步骤二，再执行步骤三，然后用一个复杂的编排器来控制整个流程。但实际上，几乎在所有情况下，只要给模型提供工具、赋予它一个目标，让它自己想办法，效果往往会更好。一年前，你可能确实需要大量脚手架（scaffolding）来辅助；但现在基本上不需要了。我不知道该怎么给这个原则起名，也许可以套用一句话——别问模型能为你做什么，想想你能给模型提供什么工具。核心就是：不要过度干预，不要把它塞进条条框框，不要一开始就塞给它一堆上下文；给它一个工具，让它自己去获取所需的上下文——你只会得到更好的结果。

第二点，也许是一个更具普遍性的原则——就是《苦涩的教训》（The Bitter Lesson）。对 Claude Code 团队来说，我们把这篇文章视为重要参考——希望各位听众都读过——Rich Sutton 大约十年前写了一篇博客，叫做《苦涩的教训》，核心思想其实非常简单。他的观点是：越通用的模型，永远会胜过越专用的模型。他当时谈的是自动驾驶和其他一些领域，但实际上，《苦涩的教训》有着极多的推论。对我来说，其中最重要的一条就是：始终押注于更通用的模型。从长远来看，不要尝试用小模型来处理问题，不要尝试做微调（fine-tune）。不要去做这些。当然，某些特定的应用场景可能有其理由，但几乎在所有情况下，如果你有这个灵活性，都应该尽量押注更通用的模型。那些复杂的工作流程，本质上是在把模型"专用化”——是在给它套脚手架。我们通常观察到的是，脚手架也许能带来 10%、20% 的性能提升，但这些收益往往会被下一个模型直接抹平。所以，有时候还不如直接等下一个模型发布。

最后一个原则——也是我认为 Claude Code 事后回头看做对了的事——从一开始，我们就押注于为六个月后的模型构建产品，而不是为今天的模型。产品非常早期的时候，它帮我写的代码其实很少，因为我不信任它——那时候用的是 Sonnet 3.5，后来是所谓的 3.6 或者 3.5 new，不管叫什么名字。那些模型在写代码方面还不够好，正在进步，但仍处于相当早期的阶段。所以那时候，它只是帮我管理 git、自动化了一些事情，并没有真正承担大量的编码工作。Claude Code 的赌注在于：终有一天，模型会好到足以独立完成大部分代码编写。这件事我们第一次真正看到，是在 Opus 4 和 Sonnet 4 的时候——Opus 4 是我们去年五月发布的第一个 ASL-3 级别的模型，那时候我们看到了明显的拐点：大家第一次真正开始大规模使用 Claude Code，增长正式进入指数级阶段，而且正如我之前说的，这种势头一直延续至今。所以，这是我常常给很多人的建议，尤其是在创业的人：头六个月会很难熬，因为产品市场契合度不会很好，但如果你是为六个月后的模型构建产品，等那个模型发布的时候，你就能立刻冲出起跑线，产品会一下子顺畅起来，真正跑起来。

Lenny Rachitsky: 那么，所谓"为六个月后的模型构建产品”，你认为人们可以对未来做出哪些假设？是说模型总体上会越来越强？还是说，如果某件事已经"差不多够用了”，就意味着它大概率还会继续改进？在这方面有什么建议吗？

Boris Cherny: 我觉得这是个不错的判断方式。当然，在 AI 实验室内部，我们能看到模型具体的改进方向。[笑声] 这确实有点不公平，但我们也尽量公开谈论这些内容。比如，模型会越来越擅长使用工具和操作计算机。这是我愿意押注的方向。另一个方向是：模型能够持续运行的时间会越来越长。这方面有很多研究可以印证，但如果你只看发展轨迹——或者就拿我自己的亲身经历来说，一年前用 Sonnet 3.5 的时候，它大概只能运行 15 到 30 秒就开始跑偏，处理任何复杂任务都得全程手把手。但现在用 Opus 4.6，平均能无人值守地运行大约 10 到 30 分钟，我可以直接开一个新的 Claude Code 会话去做别的事。就像我说的，我通常同时跑很多个会话，它们甚至能持续运行几个小时乃至几天，有些案例据说连续运行了好几周。我认为随着时间推移，“模型长时间自主运行、无需人工值守"这种状态会越来越普遍。

高效使用 Claude Code 的进阶技巧

Lenny Rachitsky: 我们刚才聊了构建 AI 产品的技巧。那使用 Claude Code 本身有没有什么建议？无论是第一次上手的新用户，还是已经在用、想进一步提升的人，能分享几个进阶技巧吗？

Boris Cherny: 先说一个前提：使用 Claude Code 没有所谓唯一正确的方式。我可以分享一些技巧，但说实话，这是一款开发者工具，而开发者各有不同——偏好不同、环境不同，使用方式因人而异，没有标准答案。你需要摸索出适合自己的路径。好在你可以直接问 Claude Code，它能给出建议，能修改你的设置，对自身也相当了解。所以 Claude Code 本身也能帮你入门。以下是我觉得普遍适用的几个技巧。第一条：使用能力最强的模型。目前是 Opus 4.6，我始终开启最高算力模式。有时候人们会想用 Sonnet 这类成本更低的模型，但正因为智能程度相对较低，完成同一任务反而消耗更多 token。所以用更便宜的模型是否真的更省钱，其实并不显而易见。很多时候，使用能力最强的模型反而更省钱、消耗的 token 也更少——因为它能更快、更直接地完成任务，不需要反复纠错和手把手引导。所以第一条建议就是：用最好的模型。

第二条是使用计划模式（plan mode）。我几乎所有任务都从计划模式开始，大约占 80%。计划模式其实非常简单，本质上只是在模型的提示词（prompt）中注入一句话：“请先不要写任何代码。“就这一句——没有什么花哨的机制，就是最简单的处理方式。在终端里，只需按两次 Shift+Tab 就能进入计划模式；桌面应用里有一个按钮，网页端也有；移动端即将上线，SWAC 集成也刚刚支持了这个功能。计划模式就是第二条建议。模型会和你来回沟通，等计划确定之后，再让它执行。我在那之后会开启自动接受编辑，因为计划一旦确定，模型往往能一次性完成——用 Opus 4.6 几乎每次都能一次搞定。

第三条建议是多尝试不同的使用界面。很多人一提到 Claude Code，脑子里就是终端。当然，我们支持各种终端——Mac、Windows，不管你用什么终端都能完美运行。但我们其实也支持很多其他产品形态，比如 iOS 和 Android 应用。还有桌面应用、Slack 集成，以及各种其他支持的形式。我建议都去尝试一下。每位工程师都不一样，每位构建者都有自己的风格，找到最适合你的方式去用就好。你不一定非要用终端，因为底层运行的是同一个 Claude 智能体。

对 Codex 的看法

Lenny Rachitsky: 太棒了。好，再聊最后几个问题。你怎么看 Codex？对这款产品有什么感受？它的发展方向如何？毕竟这是个竞争极为激烈的编程智能体赛道——说实话，我其实没怎么用过它，不过大概在它刚发布的时候试用过一次。在我看来它和 Claude Code 挺像的，说实话挺让我受宠若惊的。我认为有更多竞争其实是好事，因为用户应该有选择权，竞争也能督促大家都做得更好。

Boris Cherny: 但说到底，我们团队专注的还是解决用户遇到的问题。我们不会花太多时间研究竞品，也不怎么去试用其他产品。你当然需要知道它们的存在，但对我来说，我更享受与用户交流，享受不断改进产品，享受把用户反馈真正落地的过程。归根结底就是把产品做好。

Boris 的后通用人工智能时代规划

Lenny Rachitsky: 最后一个问题。我和 Anthropic 联合创始人 Ben Mann 聊过，请他推荐了一些问题，已经穿插在我们整个对话中了。他特别想问你：通用人工智能（AGI）实现之后，你有什么打算？不管"AGI"具体意味着什么，到那个时候，你觉得自己会过着怎样的生活？

Boris Cherny: 加入 Anthropic 之前，我其实住在日本农村，那是一种截然不同的生活方式。我是那个小镇上唯一的工程师，也是唯一的英语母语者，整个氛围与现在完全不同。每周我会骑几次自行车去农贸市场，沿途经过稻田，那个节奏与旧金山截然相反，是两个完全不同的世界。让我特别喜欢的一点是我们与邻居建立感情的方式——通过互赠腌菜。在我们住的那个小镇，几乎家家户户都自己做味噌、腌菜。我也因此练得有模有样，做了好几批，到现在还在坚持。味噌是一件很有意思的东西，它教会你用一种非常长远的时间尺度去思考。这和工程思维很不一样。一批白味噌至少要发酵三个月，红味噌则需要两三四年。你必须非常有耐心——把原料混好，然后静静等待，要有极大的耐心。我热爱它的原因，正是这种用漫长时间尺度思考的方式。嗯，是的。我想，如果到了 AGI 之后的时代，或者假如我不在 Anthropic，我大概会去做味噌吧。〔笑声〕

Lenny Rachitsky: 我太喜欢这个答案了。Ben 让我问你"你和味噌到底是什么关系”，所以很高兴你解答了这个问题。好，那么未来的方向也许就是一头扎进味噌世界，把味噌做到极致，对吗？太棒了。Boris，这次对话真的精彩绝伦。我感觉我们现在就像来自乌克兰的兄弟了。在进入令人期待的闪电问答之前，还有什么你想补充分享的吗？有没有什么想留给听众的话？有什么想再次强调的观点？

Boris Cherny: 有的。我只想再强调一点：对 Anthropic 来说，从创立之初，“先从编程入手，再扩展到工具调用，进而到计算机操控”——这一直是我们思考问题的框架。这是我们认为模型将要演进的轨迹，也是我们构建模型的方式。同时，这也是我们学习安全、研究安全、持续改进安全的最有效路径。所以你看，现在发生的一切——Claude Code 成长为一个数十亿美元量级的庞大业务，我所有的朋友都在用 Claude Code，每天都发消息来聊它——某种程度上完全出乎意料，因为我们起初根本不知道它会演变成这个产品形态，不知道它会在终端起步，诸如此类。但从另一个角度看，这又完全在情理之中，因为这一直是我们作为一家公司长期坚守的信念。与此同时，我仍然感觉这一切还处于非常非常早期的阶段——世界上大多数人仍然没有使用 Claude Code，大多数人仍然没有使用 AI。所以感觉这件事才完成了 1%，前方还有太多路要走。

Lenny Rachitsky: 确实。老兄，联想到最近披露出来的那些数字，真的难以置信。你们刚刚完成了一笔巨额融资。我记得 Claude Code 单独就在创造 20 亿美元的营收，而 Anthropic 整体——你们公布的数字，好像是 150 亿美元营收。仔细想想，这一切还处于如此早期的阶段，但我们看到的数字已经是这个规模，真的令人咋舌。

Boris Cherny: 是啊。是的，确实疯狂。而且，Claude Code 能持续保持这样的增长势头，说实话，完全归功于用户。有太多太多人在使用它，他们对产品充满热情，深深爱上了它，然后告诉我们哪里不好用、他们想要什么功能。产品能持续改进，唯一的原因就是所有人都在使用它、谈论它、持续给我们反馈——这是最最重要的事。对我而言，每天与用户交流、让产品越来越好——这就是我热爱的工作方式。这让我……哦对，味噌嘛，倒不太需要操心，只需要等待，静静等待就好。

闪电问答与结语

Lenny Rachitsky: 好了，Boris，说到这里，我们正式进入令人期待的闪电问答环节！我有五个问题，准备好了吗？

Boris Cherny: 来吧！

Lenny Rachitsky: 第一个问题：你最常向别人推荐的两三本书是什么？

Boris Cherny: 我这人，书单很长。先说技术类：第一本是《Scala 函数式编程》（Functional Programming in Scala）。这是我读过的最好的技术书，没有之一。它有点奇特，因为你可能根本不会真正去用 Scala，而且我也不确定这在未来还有多大现实意义——但函数式编程（functional programming）有一种纯粹的优雅，那种用类型体系（type system）思考的方式，就是我编程的方式，是我无法摆脱的思维模式。你可以把它当成一件历史文物来读，也可以当成一本能让你脱胎换骨的书。

Lenny Rachitsky: 我很喜欢这本从来没人提起过的书。

Boris Cherny: 我最爱的一本。

Lenny Rachitsky: 太棒了，太棒了。第二本呢？

Boris Cherny: 第二本是 Charles Stross 的《Accelerando》。我最喜爱的类型大概就是科幻，或者说科幻与文学类。《Accelerando》是一本令人叹为观止的书，节奏飞快，而且越来越快、越来越快。我觉得它比任何一本书都更能捕捉到我们此刻所处时代的本质——就是那种速度感。故事从技术起飞刚刚开始时讲起，逐渐逼近奇点（singularity），最终以一群拥有集体意识的龙虾绕木星飞行作结。这一切就发生在几十年的时间跨度里，所以节奏真的令人窒息。我非常喜欢它。再推荐最后一本——刘慈欣的《流浪地球》（The Wandering Earth）。他就是写《三体》的那位作者。很多人因为《三体》认识他。我觉得《三体》非常精彩，但说实话我更喜欢他的短篇小说。《流浪地球》是他的短篇小说集之一，里面有几个真的非常非常精彩的故事。读中国科幻也很有意思，它提供了与西方科幻截然不同的视角，至少从刘慈欣作为一个作家的思维方式来看是如此。真的非常值得一读，而且文字也写得极为优美。

Lenny Rachitsky: 科幻小说确实帮我们提前建立起对未来走向的思维框架，这一点真的很神奇——读完之后脑子里会形成一个模型：好，我见过这种世界，我知道它可能的走向。

Boris Cherny: 对，我觉得这正是我加入 Anthropic 的真正原因。就像我说的，我当时住在那个偏远地方，生活节奏非常非常慢，至少比旧金山慢太多了。你做的一切都围绕着季节，围绕着那些需要很多很多个月才能完成的食物。那里的社交活动也是这样组织的，时间的安排也是如此。你去农贸市场，发现现在是青椒（piman）季——你怎么知道？因为有二十几个摊位都在卖青椒。下一周季节就过了，变成葡萄季了，你能清清楚楚感受到这种流转。这就是那种漫长的时间尺度。当时我也在大量阅读科幻，身处那样的环境、处于那样的时刻，带着对漫长时间尺度的思考，我想：我知道这件事可以走向何方，我只是觉得我必须出一份力，让它走得好一点点——这就是我最终来到 Anthropic 的原因。Ben 也是一个很重要的推动因素。

Lenny Rachitsky: 我觉得可以专门做一期播客，只聊你在日本的时光、Boris 从日本走到 Anthropic 的历程，但今天就先点到为止吧。我快速给你推荐一本科幻小说，如果你还没读过——《深渊上的火》（A Fire Upon the Deep），读过吗？

Boris Cherny: 那是 Vernor Vinge 写的，对吧？

Lenny Rachitsky: 对，就是他。太棒了。对。从 AI 和通用人工智能（AGI）的视角来看，那本书真的非常有意思。读过它的人太少了，我自己……是的，里面有太多值得琢磨的东西。

Boris Cherny: 确实确实。我还很喜欢《天渊》（A Deepness in the Sky）。那应该是续集之类的，对吧？

Lenny Rachitsky: 嗯。对对对，是的。

Boris Cherny: 嗯。

Lenny Rachitsky: 读进去很费力，也很复杂，但真的太好看了。好，我们继续闪电问答。你最近有没有特别喜欢的电影或电视剧？

Boris Cherny: 说实话，我平时基本不看电视或电影，最近实在没时间。不过我想再提一个推荐——Netflix 上的《三体》剧集，我真的非常喜欢，觉得这个改编对原著系列的呈现相当出色。

Lenny Rachitsky: 所以 AI 领域领导者的共同规律就是：没时间看电视或电影，这我完全理解。好，有没有你最近发现、特别喜欢的产品？

Boris Cherny: 我直接说吧——Cowork，因为这真的是对我生活改变最大的产品。我一直开着它用，其中 Chrome 集成尤其出色。它帮我交过交通罚款，帮我取消过几个订阅，能替我处理掉的那些琐碎杂事真的太棒了。另外我也不确定算不算产品，但我还想推荐一个播客——除了 Lenny 的节目之外——就是 Ben 和 David 主持的《Acquired》播客。太棒了，内容非常精彩。他们深入挖掘商业历史、把历史讲得鲜活生动的方式，真的非常非常好。如果你还没听过，我建议从任天堂那期开始。

Lenny Rachitsky: 很好的建议。关于 Cowork，让大家了解一下——如果你还没用过：基本上就是你输入想完成的任务，它就能启动 Chrome 帮你去执行。我见过有人在 Anthropic 休陪产假期间，让它帮自己填那些医疗表格——就是那种特别烦人的 PDF——它会打开浏览器、登录账号、填好内容，然后提交。

Boris Cherny: 对，就是这样，而且它真的能跑起来。大概一年前我们也试过，但当时没成功，因为模型还没准备好。但现在，它真的就直接能用了，太神奇了。我觉得很多人根本不了解这是什么，因为他们之前从没用过智能体。在我看来，这和一年前的 Claude Code 给人的感觉非常相似——但就像我说的，它的增长速度远比 Claude Code 早期要快得多，所以我觉得它正在开始真正破圈。

Lenny Rachitsky: 还有你提到的那个 Chrome 扩展插件，可以单独使用，它就嵌在 Chrome 里，你可以直接跟 Claude 对话，它能看着你的屏幕和浏览器帮你做各种事情——告诉你你在看什么、总结页面内容，诸如此类。

Boris Cherny: 对，没错。对，就是这样。对于刚开始用 Cowork 的人，我的建议是：先下载 Claude 桌面版应用，打开 Cowork 标签页，就在 Code 标签页旁边。我推荐从让它使用某个工具入手。比如整理一下桌面，或者总结你的邮件，或者"回复最重要的三封邮件”——它现在真的会帮我回邮件。第二步是连接工具。比如你可以说"查看我最重要的几封邮件，然后发 Slack 消息”，或者"整理进电子表格”。再比如，我用它来管理所有项目：我们团队有一张统一的电子表格，每行对应一位工程师，每周大家填写状态更新，每周一 Cowork 就自动检查一遍，给所有没填状态的工程师发 Slack 提醒——我就再也不用手动去做这件事了。这就是一条提示词，全部搞定。第三点，就是同时跑一堆任务。Cowork 支持同时运行任意数量的任务。所以就是这样：启动一个任务——比如我这个项目管理任务在跑——再让它做别的，再做别的，把这些都启动了，然后我就去喝杯咖啡等着。

Lenny Rachitsky: 我会附上一篇文章链接，里面分享了很多人使用——以前叫 Claude Code、现在也可以通过 Cowork 来做——的各种用法。因为很多时候就是那种"哇，我没想到还能用它来做这个"的惊喜，而看到这些具体例子，我觉得正是人们需要听到的。顺便说，其中很多内容也受到了你的启发——你曾经发过一篇文章，好像是"Claude 的 50 个非技术用途"之类的。我们有一位 PM 就用那篇文章来评测 Cowork 上线前的效果。据我了解，当 Cowork 能完成 50 条里的 48 条时，他们说：“好，差不多了。”

Boris Cherny: 哇，我完全不知道这件事。这也太酷了吧。我……我成了一个测评基准。

Lenny Rachitsky: 感觉怎么样？

Boris Cherny: 棒极了。我感觉自己对 AI 的未来很有价值。

Lenny Rachitsky: 这算是反向破圈了。哈哈哈，太酷了。好，还有两个问题。你有没有什么特别喜欢、在工作或生活中常常回想起的人生格言？

Boris Cherny: 用常识。我觉得我见过的很多失败，尤其在工作环境中，都源于人们没有运用常识。比如不假思索地执行流程，不假思索地做事，或者在做一个并不好的产品、追着一个并不好的想法，却只是随着惯性走，从不停下来思考。我见过的最好结果，都来自那些从第一性原理出发、建立自己判断力的人。如果某件事感觉不对劲，那大概就是个坏主意。这是我给同事最多的一条建议，没有之一。

Lenny Rachitsky: 光是这一点就能单独开一期播客了——什么是常识？怎么培养？但我们今天就点到为止。最后一个问题：你最近在 Twitter/X 上活跃了很多，我很好奇这是为什么，以及你在 Twitter 这个世界里的体验是怎样的？因为你在 Twitter/X 上的互动非常多。

Boris Cherny: 有很长一段时间我只用 Threads，因为我当年也参与了一些 Threads 的开发工作，而且我也很喜欢它的设计——产品界面很简洁，我真的很喜欢。我开始用 Threads，其实是因为无聊。十二月我在欧洲——

Lenny Rachitsky: 你是说开始用 Twitter 吧？

Boris Cherny: 对对，没错。我开始用 Twitter，也是因为无聊嘛。十二月我和妻子在欧洲旅行，就是到处晃悠——去了哥本哈根，去了好几个国家。对我来说，那简直是一次"编程假期”，每天都在写代码，这是我最喜欢的度假方式，整天就是写代码，太爽了。有那么几个小时突然没灵感了，不知道接下来想做什么，就打开了 Twitter，看到有人在发关于 Claude Code 的推文，就开始回复。后来我想，也许我应该主动去找找，看有没有人遇到了 bug，或者有什么反馈想说——于是就介绍了一下自己，问大家有没有 bug 和意见要分享。我觉得大家都对我们现在处理反馈的速度感到有些惊讶。对我来说这已经太正常了——只要有人报个 bug，我大概几分钟内就能搞定，用 Claude Code 一跑，只要描述够清晰，它就自己去处理了，然后我再去回应下一条。但我想对很多人来说，这种速度还是挺出乎意料的，体验真的很棒。总体来说在 Twitter 上的经历非常好，能跟大家互动、了解需求、听 bug 反馈和功能建议，都让我很享受。前两天我还在 Twitter 上看到有人向 Nikita Beer 抱怨，说他们在 Threads 上连续发帖发着发着就崩了——我当时就想，天哪，这是怎么了。

Lenny Rachitsky: 对啊。对，对，确实有个 bug。希望现在已经修好了。太厉害了。Boris，我真的可以跟你聊上好几个小时。好了，不多占用你的时间了。非常感谢你来参加节目！你真的太棒了。听众们可以在哪里找到你？他们能为你做些什么？

Boris Cherny: 大家可以在 Threads 或者 Twitter 上找到我，那是最方便的方式。有什么就直接 @ 我——bug 也好，功能建议也好，觉得缺什么也好，想让产品变得更好的任何想法都欢迎。喜欢什么、想要什么，我都非常乐意听。

Lenny Rachitsky: 太好了。Boris，非常感谢你今天的到来。

Boris Cherny: 好的，谢谢你，Lenny。

Lenny Rachitsky: 各位再见！非常感谢大家的收听。如果您觉得本期节目有所收获，欢迎在 Apple Podcasts、Spotify 或您常用的播客应用上订阅本节目。也希望您能为我们打分或留下评价，这将大大帮助更多听众发现这档播客。所有往期节目及更多节目信息，请访问 lennispodcast.com。我们下期见。

术语表

本期内容时间轴：

• Boris 与 Claude Code 简介
• Boris 为何短暂离开 Anthropic 加入 Cursor（以及他回归的原因）
• Claude Code 的一周年回顾
• Claude Code 的起源故事
• AI 正以多快的速度改变软件开发
• 实验精神在 AI 创新中的重要性
• Boris 当前的编程工作流（100% 由 AI 完成代码）
• 下一个前沿
• 快速创新的代价
• Claude Code 团队的行动原则
• 为何应该给工程师提供无限 token
• 编程技能在未来还重要吗？
• 用印刷机类比 AI 的影响
• AI 接下来将改变哪些职业？
• 在 AI 时代脱颖而出的建议
• 投票：哪些职业因 AI 而更享受工作
• 产品开发中的潜在需求原则
• Cowork 如何在短短 10 天内构建完成
• Anthropic AI 安全的三个层次
• AI 智能体不工作时的焦虑感
• Boris 的乌克兰根源
• 构建 AI 产品的建议
• 高效使用 Claude Code 的进阶技巧
• 对 Codex 的看法
• Boris 的后 AGI 时代规划
• 闪电问答与结语

参考资料： • Cursor：https://cursor.com • Cursor 的崛起：年收入 3 亿美元、工程师欲罢不能的 AI 工具 | Michael Truell（联合创始人兼 CEO）：https://www.lennysnewsletter.com/p/the-rise-of-cursor-michael-truell • Anthropic：https://www.anthropic.com • Anthropic CPO 谈未来展望 | Mike Krieger（Instagram 联合创始人）：https://www.lennysnewsletter.com/p/anthropics-cpo-heres-what-comes-next • 《Claude Code 是拐点》：https://newsletter.semianalysis.com/p/claude-code-is-the-inflection-point • Spotify 称其顶尖开发者自去年 12 月起已不再手写一行代码，AI 功不可没：https://techcrunch.com/2026/02/12/spotify-says-its-best-developers-havent-written-a-line-of-code-since-december-thanks-to-ai/ • Anthropic 联合创始人谈离开 OpenAI、AGI 预测、亿元人才争夺战、20% 失业率及令他夜不能寐的噩梦情景 | Ben Mann：https://www.lennysnewsletter.com/p/anthropic-co-founder-benjamin-mann • Haiku：https://www.anthropic.com/claude/haiku • Sonnet：https://www.anthropic.com/claude/sonnet • Opus：https://www.anthropic.com/claude/opus • Jenny Wen 的 X 主页：https://x.com/jenny_wen • Johannes Gutenberg：https://en.wikipedia.org/wiki/Johannes_Gutenberg • Anthropic 招聘：https://www.anthropic.com/careers/jobs • Lenny 在 X 上的 AI 投票帖：https://x.com/lennysan/status/2020266745722991051 • Fiona Fung 的 LinkedIn：https://www.linkedin.com/in/fionafung • Brandon Kurkela 的 LinkedIn：https://www.linkedin.com/in/bkurkela • Cowork：https://www.anthropic.com/webinars/future-of-ai-at-work-introducing-cowork • Chris Olah 的 X 主页：https://x.com/ch402 • 《苦涩的教训》：http://www.incompleteideas.net/IncIdeas/BitterLesson.html ……更多参考资料见：https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens

节目制作与推广：https://penname.co/ 播客赞助合作请联系：podcast@lennyrachitsky.com

Lenny 可能持有节目中提及公司的投资份额。

此文章由 AI 翻译