整理 & 编译：深潮TechFlow

嘉宾：Boris Cherny，Claude Code 负责人

主持人：Lenny Rachitsky

播客源：Lenny's Podcast

原标题：Head of Claude Code: What happens after coding is solved | Boris Cherny

播出日期：2026年2月19日

要点总结

Boris Cherny 是 Anthropic 的 Claude Code 项目的创始人和负责人。仅仅一年时间，他将一个基于终端的简单原型发展成了一个正在改变软件工程角色，并逐步影响所有专业领域的工具。

在这次讨论中涉及了以下话题：

1. Claude Code 如何从一个快速开发的原型，成长为占公共 GitHub 提交量 4% 的工具，并且上个月的每日活跃用户数量翻了一番。
2. Claude Code 成功背后的反直觉产品原则。
3. 为什么 Boris 认为编程问题已经"被解决"。
4. 塑造 Claude Code 和 Cowork 的潜在需求。
5. 如何最大限度地利用 Claude Code 和 Cowork 的实用建议。
6. 为什么缩减团队规模并给他们提供无限的 Token 使用权限，能带来更好的 AI 产品。
7. Boris 为什么曾短暂离开 Anthropic 加入 Cursor，但仅仅两周后又回归。
8. Boris 与每位新团队成员分享的三大核心原则。

精彩观点摘要

关于离开又回到 Anthropic 的真相

• "吸引我来 Anthropic 的是它的使命，是安全。你在 Anthropic 随便找一个人拦下来问他们为什么在这里，答案永远是安全，这种使命驱动的感觉对我来说共鸣极深。我知道这是我个人需要的东西，没有它我无法感到快乐。"

为什么 Claude Code 增长如此之快？

• "在 Anthropic，用指数思维看问题是刻在 DNA 里的——看看我们的联合创始人，他们是'scaling laws'论文的前三位作者，我们真的在用指数去思考问题。如果你当时把 Claude Code 写代码占比的指数曲线画出来，然后顺着它描一条线，很明显我们在年底就会越过 100%。"
• "创新是没有路线图的，你无法强制它发生。你必须给人空间，也可以说是'安全感'——让人们有心理安全感，知道失败没关系，80% 的想法是坏想法也没关系。"

下一个前沿是什么？编程已被解决

• "编程已经基本上被解决了——至少对我所做的这类编程来说，它就是一个已经解决的问题，因为 Claude 能做到。自从十一月以来，我没有手动改过一行代码。我每天要提交十个、二十个、三十个 PR，而且全部由 Claude Code 编写。"

迁移学习带来的意外红利

• "这种迁移学习 (transfer learning) 的现象非常有趣——当你教模型完成某个任务 X 时，它在另一个任务 Y 上的表现也会有所提升。举个例子，自从我们推出 Quad Code (四元码) 技术以来，我们的工程团队规模大约增加了 4 倍，但更令人震撼的是，每位工程师的生产力提升了 200%。"

团队原则一：故意"欠配资源"（Underfund）

• "当一个项目故意‘欠配资源’时，人们就会被迫使用 Claude。如果你把一个工程师单独放在一个项目上，他们之所以能够快速交付，这种内在动力来自于他们想做好工作。如果你有 Claude，就可以用它来自动化大量工作。"

团队原则二：给工程师无限制的 Token

• "不要在一开始就优化，不要在一开始就削减成本，先把尽可能多的 token 给到工程师手里。加入后可以用无限 token，这是我非常支持的做法，因为这让人们可以自由地去尝试那些疯狂的想法。最有趣的创新想法，会从这种尽情实验的过程中涌现出来。"

印刷机类比：好玩的部分变了

• "最贴切的类比，是印刷机。我不需要再做那些繁琐的工作——折腾 Git、用各种工具，那从来都不是好玩的部分。好玩的部分是想清楚要构建什么，和用户交谈，思考这些大系统，思考未来，和团队协作。现在我可以把更多时间放在这些事情上。"

接下来会改变哪些职业？Agent 进入电脑

• "我觉得会是很多与工程相邻的职位——产品经理、设计、数据科学，最终会扩展到几乎任何一种可以在电脑上完成的工作。Agent 真正的含义：一个能够使用工具的 LLM——它不只是在说话，它能真正行动，能和你的系统交互。"

职业阶梯的重组：Builder 取代工程师

• "到年底，这些界限会变得更加模糊，在一些地方，'软件工程师'这个职位名称会开始消失，被'Builder'取代，或者所有人都变成产品经理，同时大家也都写代码。回报最丰厚的人，是那些好奇、博学、跨越多个学科的人。"

现代版"潜在需求"框架

• "传统的潜在需求框架是看用户在做什么。而我看到的现代框架有点不同：看模型在试图做什么，把那件事变得更容易。产品就是模型本身，我们希望把它充分暴露出来，用最少的脚手架包裹它，让它自己决定运行哪些工具、按什么顺序。"

用 AI 在 10 天内构建出 Cowork

• "Cowork 的诞生来自于‘潜在需求’——我们看到人们用 Claude Code 做那些非技术的事情。最终方案是用 10 天，全程用 Claude Code 来构建它。Cowork 里有一套非常精密的安全系统，而这些代码全部由 Claude Code 编写。"

Anthropic 的三层安全体系

• "第一层是对齐和机械可解释性；第二层是 Eval（实验室场景）；第三层是看模型在真实世界中的行为。我们需要比我们认为准备好了更早地发布，这样才能得到反馈，即便发布之后我们还是学到了很多关于对齐和安全的东西。"

关于"Agent 停摆焦虑"

• "我早上醒来，第一件事就是打开 iPhone 上的 Claude iOS 应用，看昨晚 Agent 的进展。在某种程度上确实有一点焦虑——这是一种‘某个 Agent 卡住了，我失去了很多生产力’的感觉。我真没想到我会用 iOS 来‘写代码’。"

构建 AI 产品的核心原则

• "不要问模型能为你做什么，而是想想怎么给它工具让它自己去做。不要过度管控，不要把它关进盒子。永远为六个月后的模型而构建，不是为今天的模型。当那个模型出来时，你的产品就会一举腾飞。"

给专业用户的技巧：Plan Mode

• "我开始大约 80% 的任务时会先用计划模式。这其实非常简单，就是在提示里注入一句话'请先不要写任何代码'。等计划看起来没问题了，再让模型执行。用最强的模型（Opus 4.6），往往反而更便宜。"

为什么 Boris 短暂离开 Anthropic 去了 Cursor（以及他为何回来

主持人 Lenny：大约六个月前，你离开了 Anthropic，加入了 Cursor，但两周后就回来了，发生了什么？

Boris Cherny：

这是我经历过最快的一次工作变动。我加入 Cursor 是因为我是这个产品的铁杆粉丝，见到团队后也很佩服他们——他们是很棒的团队，在做很酷的东西，而且我觉得他们比很多人更早看到 AI 编程的走向，所以去那里构建好产品这件事本身对我非常有吸引力。但一到那里，我就开始意识到，我真正怀念的是 Anthropic 的使命。这也是当初驱动我来 Anthropic 的原因——在我加入之前，我在大型科技公司工作，但我想在一个实验室里，以某种方式参与塑造这个疯狂事物的未来。

吸引我来 Anthropic 的是它的使命，是安全。你在 Anthropic 随便找一个人拦下来问他们为什么在这里，答案永远是安全，这种使命驱动的感觉对我来说共鸣极深。我知道这是我个人需要的东西，没有它我无法感到快乐。不管工作本身有多令人兴奋，哪怕是在做一个非常酷的产品，它也无法替代使命感。这个认识来得相当快相当清晰。

Claude Code 一周年

主持人 Lenny：让我们回到 Anthropic 和你在那里完成的工作，这期播客上线时差不多是 Claude Code 发布一周年。有一份 SemiAnalysis 的报告你应该看到了——它显示 GitHub 上 4% 的公开提交是由 Claude Code 创作的，并预测到年底这个数字将达到五分之一。就在录这期播客的当天，Spotify 发了一条新闻，说他们最优秀的工程师从十二月以来就没有写过一行代码，全靠 AI 了。你对这一年的影响有什么反思？

Boris Cherny：

这些数字实在太疯狂了，比我想象的要多得多，而且这些还只是公开提交记录，如果把私有仓库算进来估计数字会高很多。但对我来说，最疯狂的不是我们当前所处的数字，而是我们增长的速度——因为从任何维度来看，Claude Code 的增速都在持续加快，它不只是在上升，而是越来越快地上升。当初启动 Claude Code 时，它只是一个小 hack。Anthropic 大致清楚我们想做一个编程产品，而且公司长期以来构建模型的方式有一条轨迹：先让模型在编程上非常强，然后在工具使用上非常强，再然后是计算机使用——这也是出于安全的考虑，因为 AI 的能力越来越强，要以负责任的方式去发展。

Claude Code 的起源故事

Boris Cherny：

我加入 Anthropic 后，先花了一个月做各种奇怪的原型，大多数都没上线；然后又花了一个月做后训练，去理解研究这一侧。我觉得要做好工作，你真的需要理解你工作层之下的那一层。在 AI 领域，你必须在一定程度上理解模型才能做好产品。

Claude Code 的第一个版本叫 ClaudeCLI，当时展示的是它如何使用几个工具——最让我震撼的一刻是，我给它一个 bash 工具，结果它自己想出来用这个工具来回答我"我现在在听什么音乐"这个问题。这件事很神奇，因为我根本没有告诉模型"用这个工具来做这件事"，它自己推断出来了。我把这个发到内部后，得到的反应就是两个赞，仅此而已。因为大家一想到编程工具，就想到 IDE，没人觉得这东西可以在终端里跑。终端这种设计有点怪，确实很另类。但我当时选终端，只是因为最初那几个月就我一个人，终端是最容易构建的方式。

这其实是一个重要的产品教训——在初期你需要稍微减少一些资源投入。后来我们开始考虑是否要换一个形式，但最终决定继续坚守终端，最大的原因是模型改进得太快了，我们觉得没有别的形式能跟上它的速度。这是我深夜反复思考的问题：模型还在持续进化，我们该怎么办？终端是我当时唯一想到的答案，结果发布之后确实很快就流行起来了，在 Anthropic 内部变成了爆款，日活数据几乎垂直上升。

在二月我们对外发布时，它其实并没有立刻成功，很多个月之后，大多数人才真正明白这个东西是什么。它实在太不一样了，Claude Code 能成功，部分原因在于"潜在需求"这个概念——我们把工具带到了人们已经在的地方，让现有的工作流变得稍微容易一些。当然因为是在终端里，它有点陌生，你需要保持开放的心态去学习使用它。现在 Claude Code 已经上了 iOS 和 Android 应用、桌面应用、网页版，还有 IDE 插件、Slack 集成、GitHub 集成——工程师在哪，它就在哪，而且已经更加熟悉亲切了。在最初这个东西能有用，本身就是个惊喜。随着团队成长，随着产品演进，从小创业公司到最大的科技巨头，全球各地的用户开始使用并给我们反馈。回顾这一年，我们一直在向用户学习，没有人真正知道自己在做什么，我们只是在和所有人一起摸索。

AI 正在以多快速度改变软件开发

主持人 Lenny：你一年前发布了这个产品，不是第一个让人用 AI 写代码的工具，但在一年时间里，整个软件工程行业发生了剧烈变化。一开始大家都说"AI 写 100% 的代码？不可能吧！"，现在大家又说"当然，这不就是在发生吗。"事情变化得太快了。

Boris Cherny：

在 2025 年 5 月的 Code with Claude 大会上，我做了一个简短演讲，Q&A 环节有人问我对年底的预测是什么。我说：到年底，你可能根本不需要 IDE 来写代码了，我们开始看到有工程师已经不用 IDE 了。话音刚落，会场里传来一声倒吸冷气。这个预测在当时听起来太疯狂了，但在 Anthropic，用指数思维看问题是刻在 DNA 里的——看看我们的联合创始人，他们是"scaling laws"论文的前三位作者，我们真的在用指数去思考问题。如果你当时把 Claude Code 写代码占比的指数曲线画出来，然后顺着它描一条线，很明显我们在年底就会越过 100%。我就是做了这件事，然后对我个人来说，这在十一月发生了，而且是从那以后一直如此，我们现在也在很多客户那里看到同样的情况。

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

主持人 Lenny：你分享的这段旅程很有意思——这种随意玩耍、看看会发生什么的感觉。这似乎是 AI 领域很多最大的创新的核心要素，就是有人在一直推动模型走向比其他大多数人更远的地方。

Boris Cherny：

关于创新，有一件事是确定的：它是没有路线图的，你无法强制它发生。你必须给人空间，也可以说是"安全感"——让人们有心理安全感，知道失败没关系，80% 的想法是坏想法也没关系。同时你也要有一定的问责机制：如果一个想法不好，你就承认损失，继续下一个，而不是越陷越深。在 Claude Code 的早期，我完全不知道这个东西能不能有用。即使是在二月对外发布时，它大概也只写了我 20% 的代码。到了五月，可能是 30%，我还是在用 Cursor 写大部分代码，直到十一月才跨越了 100%。但即便从最早的那天起，就感觉像是找到了什么。我每个晚上、每个周末都在研究这个东西，有时候你找到一条线索，就只能一直顺着拉下去。

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

主持人 Lenny：所以现在你 100% 的代码都由 Claude Code 完成，这是你当前编程的状态吗？

Boris Cherny：

100% 的代码由 Claude Code 完成。我是一个相当高产的工程师，即便回到 Instagram 的时候，我也是公司最高产的几个工程师之一，这在 Anthropic 依然如此。每天我要提交十个、二十个、三十个 PR，而且全部由 Claude Code 编写。自从十一月以来，我没有手动改过一行代码。

我还是会看代码——我不认为我们到了可以完全不用过问的阶段，尤其是当很多人在用你的程序时，你得确保它是正确和安全的。我们在 Anthropic 也有 Claude 做全自动代码审查，100% 的 PR 都由 Claude 审查，但之后还有一层人工审查。这些检查点是有意义的，除非是完全是原型代码，不会实际运行的那种。

下一个前沿是什么

主持人 Lenny：100% 的代码都由 AI 编写，这感觉是个疯狂的里程碑，现在已经变成"当然，这就是世界"。那下一个软件编写方式的重大转变是什么？

Boris Cherny：

我觉得现在正在发生的一件事，是 Claude 开始自己提出想法了。它在看反馈、看 bug 报告、看遥测数据，开始提出修复和要发布的功能建议，变得有点像一个同事。第二件事是，我们开始从编程延伸出去。此时此刻，可以说编程已经基本上被解决了——至少对我所做的这类编程来说，它就是一个已经解决的问题，因为 Claude 能做到。

所以现在我们开始想：接下来是什么？编程之外有什么？有很多相邻的事情，我觉得接下来会到来。还有更通用的任务——我现在每天都在用 Cowork 处理各种和编程完全无关的事情，比如前几天我用 Cowork 缴了一张停车罚单，我整个团队的项目管理也全部由 Cowork 负责——在 Spreadsheet 和 Slack 之间同步信息、发邮件等等，所以我觉得前沿在这里。编程已经基本解决了，接下来的几个月里，我们会看到整个行业的各种代码库和技术栈都相继被解决。

主持人 Lenny：Claude 帮你想"接下来做什么"这件事很有意思。很多听众是产品经理，他们大概正在冒冷汗。你怎么用 Claude 来做这件事？

Boris Cherny：

最简单的方式是：打开 Claude Code 或 Cowork，指向一个 Slack 频道。我们有一个专门收集 Claude Code 内部反馈的频道，从最早内部发布就有了，一直是源源不断的反馈流。早期的时候，每当有人发来反馈，我就会立刻进去，尽可能快地修复所有问题——也许一分钟、也许五分钟，非常快的反馈循环。这让人感到被倾听，因为通常你用一个产品、给出反馈，反馈就消失在黑洞里，你就不想再给反馈了，但如果让人们感到被倾听，他们就会继续贡献，继续帮助改进。现在我做的是同样的事，但 Claude 承担了大部分工作。

主持人 Lenny：Opus 46 的表现是不是提升了很多？从整体来看，这个模型的进展如何？

Boris Cherny：

确实有了显著的提升，我觉得部分原因是我们针对编程进行了专门的训练。Codex 是目前全球最强的编程模型之一，而且它的表现还在不断提升。比如说，4.6 版本的表现就非常出色，但不仅仅是编程领域的训练带来了进步。实际上，我们在其他领域进行的训练也能很好地迁移到编程任务上。这种迁移学习 (transfer learning) 的现象非常有趣——当你教模型完成某个任务 X 时，它在另一个任务 Y 上的表现也会有所提升。举个例子，自从我们推出 Quad Code (四元码) 技术以来，我们的工程团队规模大约增加了 4 倍，但更令人震撼的是，每位工程师的生产力提升了 200%，比如提交 pull request 的数量大幅增加，对于任何从事开发生产力研究的人来说，这个增长幅度简直不可思议。

我曾经在 Meta 工作时，负责公司代码质量的管理工作，包括 Facebook、Instagram 和 WhatsApp 等所有代码库。当时，我们非常注重提升工程师的生产力，因为代码质量的提升会直接提高开发效率。然而，即便有上百名工程师共同努力了一年，生产力的提升通常也只有几个百分点。

快速创新的代价

主持人 Lenny：更令人震惊的是，这些变化已经变得非常日常化了。当我们听到这些数字时，可能会觉得这是理所当然的，因为 AI 正在改变我们的工作方式，但这种对软件开发、产品构建乃至整个科技行业的巨大变革是史无前例的。

Boris Cherny：

当然，这种快速变化也带来了一些挑战。以我个人为例，因为模型的更新速度太快，我有时候会陷入过去的思维定式中，难以适应新的变化。我甚至发现团队里新加入的成员，尤其是刚毕业的新人，他们在工作中往往能以一种更符合通用人工智能 (AGI) 的前瞻性思维方式来完成任务，而我有时候反而显得落后了。

比如几个月前，有一个内存泄漏的问题——Claude Code 的内存使用量在上升，最终会崩溃，这是很常见的工程问题，传统方式是获取堆快照，放进调试器，用专用工具分析。我就是这样做的。但团队里一个较新的工程师直接让 Claude Code 来做，就说"嘿 Claude，好像有泄漏，你能找出来吗？"Claude Code 做了和我完全一样的事——获取堆快照，自己写了一个小工具来分析，就是一种即时生成的程序，然后找到了问题，提了一个 PR，而且比我更快。所以对于我们这些长期使用模型的人来说，必须不断把自己带回当下，不能还停留在旧模型的思维框架里——它不再是 Sonnet 3.5 了，新模型完全不同了，这种思维方式的转变是非常不同的。

Claude Code 团队的工作原则

主持人 Lenny：我听说你在团队里有一些具体的工作原则，有一条大概是"有什么比自己做某件事更好的？让 Claude 来做"，你刚刚描述的内存泄漏故事正好体现了这一点——你几乎忘了自己的原则，忘了先让 Claude 试试。

Boris Cherny：

还有一件有趣的事，就是"故意欠配资源"（underfund）。当你欠配资源时，人们就会被迫使用 Claude，这是我们持续看到的现象。我们有时候就把一个工程师单独放在一个项目上，他们之所以能够快速交付，这种内在动力来自于他们想做好工作、想把好的想法尽快落地。如果你有 Claude，就可以用它来自动化大量工作，所以欠配资源是一个原则。

另一个原则是鼓励人们更快行动——如果今天能完成的事就今天完成，这在团队里是我们非常强调的。在早期这非常重要，因为就我一个人，我们唯一的优势就是速度，这是我们在这个竞争激烈的编程市场中能够生存的唯一方式。但直到今天，这依然是我们的原则之一。如果你想更快，一个好方法就是让 Claude 做更多事情，这两个原则是相互促进的。

为什么要给工程师无限制的 token

主持人 Lenny："欠配资源"这个概念很有意思，因为通常的想法是 AI 可以让你用更少的员工做更多事情。但你说的是：不只是 AI 能让你更快，而是如果你用更少的人，你实际上会从 AI 工具里得到更多。

Boris Cherny：

对。如果你雇了优秀的工程师，他们会想办法做到的。这也是我经常和 CTO 们以及各种公司谈到的话题。我的建议通常是：不要在一开始就优化，不要在一开始就削减成本，先把尽可能多的 token 给到工程师手里。现在你开始看到一些公司把这作为福利——加入后可以用无限 token，这是我非常支持的做法，因为这让人们可以自由地去尝试那些疯狂的想法。一旦有想法行得通，那时再想怎么扩展、怎么优化，那时候才去想用 Haiku 还是 Sonnet 代替 Opus，是否要缩减规模之类的，但一开始就是大量使用 token，看看想法是否 work，给工程师自由去这么做。

主持人 Lenny：听到这里的人可能会想"当然，他在 Anthropic 工作，他当然希望我们多用 token"。但你说的是，最有趣的创新想法，会从这种尽情实验的过程中涌现出来。

Boris Cherny：

对。而且现实是在小规模的情况下，如果是一个工程师在个人实验，token 的成本相对于他们的薪资或者其他运营成本，其实还是相对低的。让成本真正增长的，是当某个东西真的跑得通了，然后规模扩大，那时候才是优化的时机，但别过早这么做。

主持人 Lenny：有没有见过 token 成本超过薪资的公司？

Boris Cherny：

在 Anthropic，我们开始看到一些工程师每个月花掉数十万美元的 token，我们开始在一些公司看到类似的情况。

编程技能在未来还重要吗

主持人 Lenny：你会怀念写代码吗？作为软件工程师，这件事不再属于你了，这让你有点难过吗？

Boris Cherny：

对我来说挺有意思的，因为当初学编程就是为了实用，我是自学的工程师，在学校读的是经济学，没有学计算机科学，但从中学就开始写程序了，而且从一开始就很实用。我学编程是因为想用它来作弊——我们有图形计算器，我把答案编程进去了。然后下一年题目太难，我不知道题是什么，就写了一个小小的代数求解器，程序来解题。后来我发现可以用小线缆把程序传给全班同学，全班都得 A 了，但最后被发现了，老师叫我们别再这么干。从一开始，编程对我来说就是构建东西的手段，而不是目的本身。

后来我也陷入对编程本身的迷恋——我写了一本 TypeScript 的书，创立了当时全球最大的 TypeScript 线下聚会，因为我爱上了这门语言本身，爱上了函数式编程和类型系统。但编程对我来说本质上是个工具，是用来做事情的方式。当然并不是所有人都这样，有人就是享受编程的这个过程。每个人都不同，即使这个领域在变化，永远都有空间去享受这门艺术，去用手写代码。

主持人 Lenny：你担心自己的工程技能会退化吗？

Boris Cherny：

对我个人来说，我没有太担心。编程一直在这样演变——从打孔卡，到开关，到硬件，到纸笔，再到现在运行在虚拟机上的软件，这已经是我们写程序的方式大概六十年了。在每次转变里，都有人说"这不算真正的编程"。但我认为，未来你依然想理解下面那一层，因为这让你成为更好的工程师。但这种情况大概只会再持续一年左右，之后可能真的就无所谓了，就像汇编语言之于程序员一样。

在情感层面，我一直需要学新东西，作为程序员，这并不是什么新鲜感，因为总有新框架、新语言。这是我们在这个领域很熟悉的事情。但同时，这对所有人未必都一样，对某些人可能会有一种失落感、怀旧感，或者技能退化的感觉。

印刷机的类比：AI 的影响

主持人 Lenny：现在总有一个疑问：我们还需要学习编程吗？学校里的学生是否还有必要学习编程？从你的观点来看，似乎在一两年内，这可能就不再是必需的技能了。

Boris Cherny：

我的看法是，对于那些如今正在使用四元码 (Quad Code) 或者智能代理 (agents) 来编程的人来说，目前还是需要理解底层的编程逻辑的。但在一两年内，这种理解可能就变得不那么重要了。

我最近一直在思考，什么样的历史事件可以用作类比？因为我们需要将这种现象放到一个更大的历史背景中，试着弄清楚我们是否曾经历过类似的技术转型。我想到的最贴切的类比，是印刷机。在 1400 年代中期的欧洲，识字率其实非常低——不到 1% 的人口，也就是那些文士才能读写，受雇于贵族和国王，很多统治者自己都是文盲，然后古腾堡和印刷机出现了。有一个疯狂的统计：印刷机发明后的五十年里，印刷出来的材料比此前一千年的总量还多。印刷物的数量急剧上升，成本在之后五十年里下降了大约一百倍。而识字率花了大约两百年才从不到 1% 上升到全球 70%，因为学会读写很难，需要教育体系、需要闲暇时间，不能整天在农田劳作。

我觉得我们可能会看到类似的转变。而且有一个有趣的历史记录——有人访问了一位 1400 年代的文士，问他对印刷机的感受，他们其实很兴奋，因为他们说：我不喜欢做的事，是在书与书之间抄写，我喜欢做的是书里的绘画和装帧。我很高兴我的时间现在解放出来了，作为工程师我和这种感觉很有共鸣。我不需要再做那些繁琐的工作——折腾 Git、用各种工具，那从来都不是好玩的部分。好玩的部分是想清楚要构建什么，和用户交谈，思考这些大系统，思考未来，和团队协作。现在我可以把更多时间放在这些事情上。

主持人 Lenny：而且令人惊叹的是，你构建的这个工具，让任何人都能做这件事，即便没有技术背景。我自己做了一堆小项目，遇到卡壳时，Claude 就帮我解决——之前花很多时间在库和依赖上面的痛苦，现在都消失了。

Boris Cherny：

就是这样，我今天早些时候和一个工程师聊，他用 Go 写了一个服务，弄了一个月，已经运行得相当不错，然后我问他感觉怎么样，他说："我其实还是不太会 Go……"我觉得我们会越来越多地看到这种情况——只要你知道它运行正确、运行高效，你其实不需要了解所有的细节。

AI 接下来将改变哪些职业

主持人 Lenny：你觉得 AI 接下来最快会冲击到哪些职位？无论是科技领域内的产品经理、设计师，还是科技领域以外的？

Boris Cherny：

我觉得会是很多与工程相邻的职位——产品经理、设计、数据科学，最终会扩展到几乎任何一种可以在电脑上完成的工作，因为模型在这方面会越来越强。Cowork 是触达这类工作的第一种方式，但只是第一个，我觉得它把 Agentic AI 带给了以前从未使用过它的人，让人们第一次开始有一种感觉。回顾工程领域一年前的样子，没有人真正知道什么是 Agent，没人真正用过它，但现在它已经是我们工作的方式了。

而当我看向非技术性工作，或者说半技术性工作，比如产品和数据科学，大家用的 AI 还都是对话式的，就是一个聊天机器人。Agent 这个词被随意滥用，已经失去了很多意义，但它其实有非常明确的技术含义：一个能够使用工具的 LLM——它不只是在说话，它能真正行动，能和你的系统交互，能用你的 Google Docs，能发邮件，能在电脑上运行命令。所以我认为，任何使用电脑工具的工作都是下一个。这也是我觉得在 Anthropic 做这件事感觉很重要、很紧迫的原因——我们非常认真地对待这件事，有经济学家、政策研究者、社会影响领域的人，我们希望能大量讨论这件事，这样作为社会，我们能一起弄清楚该怎么应对，因为这不应该只由我们来决定。

主持人 Lenny：有一个"杰文斯悖论"的概念——当我们能做更多时，我们就会雇更多人，实际上没有那么可怕。在 AI 成为工程工作重要部分的过程中，你经历了什么？你雇了更多人吗？

Boris Cherny：

Claude Code 团队正在招人，就我个人而言，这一切让我更享受工作了。我从来没有像今天这样享受编程，因为我不需要再处理那些琐碎的细节。我们也从很多客户那里听到这种反馈——他们爱用 Claude Code，因为它让编程再次变得快乐，但这件事会走向哪里很难说。我还是需要寻找历史上的类比，而印刷机真的是很贴切的类比——这种原本只掌握在少数人手中的能力，知道如何读写，变得每个人都可以使用了，这本质上是民主化的。每个人都开始能做这件事，而如果不是这样，文艺复兴根本不可能发生，因为文艺复兴很大程度上依赖于知识传播、文字记录——那时候没有电话，没有互联网，文字是人们大规模协调的方式。我想象这样一个世界，几年后每个人都能编程，任何人随时都能构建软件，这会解锁什么？我完全想象不到，就像 1400 年代的人无法预测接下来会发生什么一样。但我确实认为在过渡期，这会是非常有破坏性的，对很多人来说会很痛苦，这是我们作为社会必须一起讨论和应对的事情。

在 AI 时代取得成功的建议

主持人 Lenny：对于想在这个动荡时代站稳脚跟的人，你有什么建议？是多玩 AI 工具、熟练掌握最新的东西吗？还有别的什么？

Boris Cherny：

这大概是建议的第一条——去用这些工具，去了解它们，不要害怕，大胆地去探索，跟上最前沿。第二条建议是：比过去更努力地成为一个通才。比如在学校，很多学 CS 的人学会了写代码，但不太学其他东西，顶多学一点系统架构之类的。但我每天共事的最有效的工程师里，很多人都跨学科——在 Claude Code 团队里，所有人都写代码，我们的产品经理写代码，工程经理写代码，设计师写代码，财务写代码，数据科学家写代码，大家都写代码。而且很多工程师都跨越不同领域，最厉害的是那些既是产品工程师又是基础设施工程师的人，或者是有很好设计感的产品工程师，或者是有很强商业直觉的工程师，或者是喜欢和用户交谈、能很好地理解用户需求的工程师。所以我觉得，接下来几年里回报最丰厚的人，不只是 AI 原生的、会用这些工具的，还是好奇、博学、跨越多个学科、能从更宏观的角度思考他们在解决的问题的人——而不只是盯着工程这一块。

主持人 Lenny：你觉得工程、设计、产品管理这三个独立的学科还有长期存在的价值吗，虽然现在它们在互相重叠、互相做对方的事？

Boris Cherny：

短期来看会继续存在，但我们开始看到这些角色有大约 50% 的重叠，很多人其实在做同样的事，只是有各自的专长。比如我写的代码可能多一点，我们的产品经理可能更多做协调、规划、预测、利益相关方管理。我确实认为，到年底，这些界限会变得更加模糊，在一些地方，"软件工程师"这个职位名称会开始消失，被"Builder"取代，或者所有人都变成产品经理，同时大家也都写代码。

调查：哪些职业因 AI 而更享受工作

主持人 Lenny：我在 Twitter 上做了一个非正式调查，问工程师、产品经理和设计师：自从采用 AI 工具以来，你更享受还是更不享受你的工作？工程师和产品经理中，70% 的人说更享受，约 10% 说更不享受。设计师有趣的是，只有 55% 说更享受，20% 说更不享受。

Boris Cherny：

我很想和两边的人都谈谈去了解更多。在 Anthropic，我们的设计师大多数会写代码——这是我们招人时会考察的，对非技术岗位我们也有很多技术面试。我们的设计师大多数在编程方面很享受 AI 带来的变化，因为他们不需要去麻烦工程师了，可以自己进去改。甚至有些以前不写代码的设计师现在开始写了，对他们来说很好，因为可以自己解除阻碍。但我很想听到更多不同的体验，因为我相信情况并不是统一的。

主持人 Lenny：所以如果你在听这个播客，如果你发现你不太享受工作了，欢迎留言说说是什么让你不那么开心——因为大多数人，70% 的产品经理和工程师都说他们更享受工作了。

Boris Cherny：

我们也看到人们使用不同的工具——我们的设计师更多地使用 Claude 桌面应用来写代码，就是下载桌面应用，里面有一个代码 Tab，就在 Cowork Tab 旁边，用的其实是完全相同的 Claude Code Agent，而且可以同时运行尽可能多的 Claude 会话，我们叫这个"多并行 Claude"。这对于不是工程师的人来说，我觉得更原生一些。这也回到了把产品带到人们已经在的地方这个原则——不想让人们改变工作流，不想让他们特意去学一个新东西，而是无论人们在做什么，如果能让那件事变得稍微容易一些，产品就会更好，人们也更喜欢。

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

主持人 Lenny：你能讲讲"潜在需求"这个原则吗？你在 Cowork 发布时提到了它，能解释一下这个概念是什么，以及当你解锁潜在需求时会发生什么吗？

Boris Cherny：

潜在需求是这样一个想法：如果你构建的产品，被人们以一种它根本没有被设计来使用的方式"滥用"，来完成他们想做的某件事，这就能帮助你作为产品构建者，了解产品下一步应该去哪里。一个例子是 Facebook Marketplace。当时的团队负责人 Fiona 经常讲这个故事——Facebook Marketplace 的起源是观察到 Facebook 群组里大约 40% 的帖子是买卖东西的，人们在"滥用" Facebook 群组来买卖，没有人专门为此设计产品，但他们想出了这种用法，因为它真的很有用。所以很明显如果你构建一个专门让人们买卖的产品，他们会喜欢的。Facebook Marketplace 就是这样诞生的，Facebook Dating 也是类似的思路——如果你看个人主页的浏览数据，60% 的查看来自于互不相识的异性，这是一种"潜在的约会行为"，于是就有了 Dating 产品。

这个"潜在需求"概念在 Cowork 的诞生上也发挥了作用。我们注意到，过去六个月里，有很多人使用 Claude Code 根本不是为了写代码。有人用它来种番茄，有人用来分析自己的基因组，有人用来从损坏的硬盘里恢复婚礼照片——这些用途完全不是技术性的，很明显大家在费尽周折地在终端里做这件事，也许我们应该专门为他们构建一个产品。

我记得有一天走进办公室，看到我们的数据科学家 Brendan，在终端里跑着 Claude Code，我震惊了——他是怎么打开终端的？这是一个很有工程范的产品，连很多工程师都不想用终端。他下载了 Node.js，下载了 Claude Code，在终端里做 SQL 分析，然后第二周所有数据科学家都在这么做。当你看到人们以非设计初衷的方式使用产品来完成某件对他们有用的事情时，这就是一个强烈的信号，你应该专门为此构建产品。

我觉得现在还有一个有趣的第二维度。传统的潜在需求框架是：看用户在做什么，把那件事变得更容易，赋予他们能力。而我在过去六个月看到的现代框架有点不同：看模型在试图做什么，把那件事变得更容易。当我们最初构建 Claude Code 时，很多人在用 LLM 构建东西时，把模型关在一个盒子里，说"这是我要构建的应用，你来做这一个组件，按这个方式与 API 交互。"但 Claude Code 把这个倒过来了——产品就是模型本身，我们希望把它充分暴露出来，用最少的脚手架包裹它，给它配备基本的工具集，让它自己决定运行哪些工具、按什么顺序。这在很大程度上是基于模型自身的"潜在需求"——它想做什么？在研究中，我们叫这个为"分布"，就是看模型试图做什么。在产品视角，潜在需求正是这个概念对应用于模型的版本。

Cowork 是如何在10天内构建出来的

主持人 Lenny：说到 Cowork，你在发布它时提到，你的团队在 10 天里构建出来了，这怎么做到的？

Boris Cherny：

Claude Code 在发布时并不是马上成功的，它是随着时间推移慢慢变成大爆款的，有几个关键的拐点——Opus 4 发布时有一次，十一月有一次，增长越来越快。但头几个月，很多人不知道怎么用，也不明白这是什么，而 Cowork 发布时立刻就爆了，比 Claude Code 早期成功得多。

Cowork 的诞生来自于刚才讲的"潜在需求"——我们看到人们用 Claude Code 做那些非技术的事情，我们需要想清楚怎么应对。团队探索了几个月，尝试了各种不同的方向，最终有人说：如果我们就把 Claude Code 放进桌面应用会怎样？这就是最终 work 的方案。然后用了 10 天，全程用 Claude Code 来构建它。Cowork 里有一套非常精密的安全系统，有护栏确保模型不会失控——我们随产品一起发布了一个完整的虚拟机，而这些代码全部由 Claude Code 编写。我们只需要想清楚：怎么让它对非工程师用户来说稍微更安全、更自主一些。全部由 Claude Code 实现，花了大约 10 天。

我们早早发布了，那时候还很粗糙，但这就是我们学习的方式——无论是产品层面还是安全层面，我们需要比我们认为准备好了更早地发布，这样才能得到反馈，和用户交谈，理解他们想要什么，让这些来塑造产品的走向。

Anthropic 的三层 AI 安全体系

主持人 Lenny："尽早发布，从用户那里学习，迭代"这个理念一直都存在，但你说的是一个独特的理由：你甚至不知道 AI 能做什么、人们会怎么用它，这本身就是尽早发布的独特理由——帮你发现"潜在需求"到底在哪。

Boris Cherny：

对，而且作为一个安全为先的实验室，发布的另一个维度就是安全。因为关于模型安全，有几种不同的研究方式。最底层的研究是对齐和机械可解释性——在训练模型时，我们想确保它是安全的，现在已经有相当成熟的技术来理解神经元里发生了什么，比如如果有一个与欺骗相关的神经元被激活，我们开始能够监控和理解它。这是对齐，这是机械可解释性，是最底层的东西。

第二层是 Eval——这是一个实验室环境，模型在"培养皿"里，你在合成场景里研究它：模型，你会怎么做？它是对齐的吗？它安全吗？

第三层是看模型在真实世界中的行为。随着模型越来越复杂，这一层变得越来越重要，因为模型在前两层可能表现很好，但在第三层未必。我们很早就发布了 Claude Code，是因为我们想研究安全——在对外发布前，我们在 Anthropic 内部使用了大概四五个月，因为这是当时发布的第一个大规模使用的 Agent，我们并不确定它是否安全，需要在内部仔细研究。即便如此，发布之后我们还是学到了很多关于对齐和安全的东西，持续把它反哺给模型和产品。Cowork 也类似——模型在一个全新的场景里，在做非工程任务，对齐看起来很好，内部测试看起来很好，找了几个客户测试也不错，但现在需要确保它在真实世界中是安全的。

主持人 Lenny：所以一共是三个层次，还有你提到的第一层——有一个可观测性工具，可以让你窥视模型的"大脑"，看它在想什么、往哪里走。你们真的有一个工具，可以看到模型的内部，看它的思维方式和走向。

Boris Cherny：

有机会你应该请 Chris Olah 来上这个播客，他是这个领域的专家，他发明了机械可解释性这个领域。核心思路是：模型本质上是一堆连接的神经元，就像人脑或动物大脑一样，可以从机制层面研究这些神经元在做什么。令人惊讶的是，这在模型上也在很大程度上适用。模型神经元和动物神经元不一样，但在很多方面行为相似。我们已经学到了很多关于这些神经元如何工作的东西——哪一层或哪个神经元对应什么概念，特定概念是如何编码的，模型如何做规划，如何向前"预想"。

很久以前，我们还不确定模型究竟是在预测下一个 token，还是在做更深层的事情。现在有相当强的证据表明，它确实在做更深层的事情。而且随着模型变大，结构也更加复杂——一个神经元可能对应十几个概念，与其他神经元一起激活时才代表更复杂的概念，这叫"叠加"。我们一直在学习，而 Anthropic 作为一个思考这个领域如何发展的实验室，做到这件事要既安全又对世界有益——这是我们存在的原因，是每个人在这里的原因。所以很多这类工作我们开源，我们大量发表，我们坦诚地谈论这些，希望能激励其他实验室也以安全的方式做事。我们也在 Claude Code 上做这件事，我们叫它"向上竞赛"——比如我们开源了一个沙盒，可以在其中运行 Agent，确保它在系统访问方面有边界，而且这个沙盒适用于任何 Agent，不只是 Claude Code，因为我们想让其他人也很容易做到同样的事。

AI Agent 不工作时的焦虑感

主持人 Lenny：在工程师、产品经理等使用 Agent 的人中——当 Agent 没有在运行时，会有一种焦虑感一种"某个 Agent 卡住了，我失去了很多生产力"的感觉。你有这种感觉吗？你的团队有吗？你觉得这是一个需要关注的问题吗？

Boris Cherny：

我一直都有一堆 Agent 在跑，就在现在我有五个 Agent 在运行。我早上醒来，第一件事就是打开 iPhone 上的 Claude iOS 应用，看昨晚 Agent 的进展——因为前一天写了些代码，半夜在想某件事有没有做对，然后发现是对的。所以在某种程度上确实有一点焦虑，但就我个人来说，因为 Agent 一直在跑，所以感觉没那么明显。我现在大概三分之一的代码在终端里写，三分之一用桌面应用，还有三分之一用 iOS 应用——这在 2026 年对我来说还是很惊讶，我真没想到我会用 iOS 来"写代码"，但这就是现实了。

主持人 Lenny：你描述它为"写代码"，但其实是在和 Claude Code 对话，让它帮你写代码。现在写代码的含义是：描述你想要什么，而不是真正写代码。

Boris Cherny：

我有时候会想，当年用打孔卡写程序的人，如果看到今天的"写代码"会怎么说。我记得我看过一篇很早期的杂志文章，有人说"这不一样，这不是真正的编程"。我的家庭来自苏联，我在乌克兰出生，我的外祖父其实是苏联最早的一批程序员之一，他用打孔卡写程序。他带着那些打孔卡回家，对我妈妈来说，这些打孔卡的童年记忆是用蜡笔在上面乱画——那是她的游戏，但那是他的"写程序"的体验。他从未见到软件的时代，但在某个时候确实过渡到了软件，而我相信当时可能有一代"老一辈程序员"不太认真对待软件，会觉得"那不算真正的编程"。但这个领域一直在这样演变。

构建 AI 产品的建议

主持人 Lenny：你分享了一些很棒的建议——给团队尽可能多的 token，为模型六个月后要到达的地方构建，而不是为今天的模型构建。对于想构建 AI 产品的人，你还有什么其他建议？

Boris Cherny：

一是不要把模型关在盒子里。很多人的直觉是构建很严格的工作流，"你必须先做第一步，再做第二步，再做第三步"，然后有一个复杂的编排器。但几乎总是，如果你直接给模型工具、给它目标，让它自己想办法，你会得到更好的结果。一年前你可能确实需要很多脚手架，但现在不需要了。我还不知道用什么名字来称呼这个原则，但大概是：不要问模型能为你做什么，而是想想怎么给它工具让它自己去做。不要过度管控，不要把它关进盒子，不要预先给它一大堆上下文，给它一个工具让它自己去获取需要的上下文，你会得到更好的结果。

第二条是惨痛的教训（Bitter Lesson）。在 Claude Code 团队，我们把这个挂在墙上。Rich Sutton 大约十年前有一篇博文叫《惨痛的教训》，核心思路很简单：更通用的模型永远会比更专门的模型表现更好。对我来说，最大的推论是：永远押注更通用的模型。不要尝试微调，不要试图用小模型，不要搭建这些固定的工作流——这些工作流本质上是在抛弃通用性。通常脚手架能带来 10-20% 的性能提升，但这些提升往往在下一个模型发布时就被抹掉了。所以有时候还不如直接等下一个模型。

第三条原则，也是我觉得 Claude Code 从一开始就做对了的——从第一天起，我们就是为六个月后的模型而构建，不是为今天的模型。在早期，Claude Code 只写了我很少一部分代码，因为当时是 Sonnet 3.5、3.5 new 之类的模型，并不擅长写代码。但押注是：在某个时刻，模型会好到能写大量代码。我们第一次真正看到这种拐点，是 Opus 4 和 Sonnet 4 发布时——那是我们第一个 ASL3 级别的模型，我们看到增长真的指数化了，然后就一直保持在那里。我会把这个建议给到很多人，尤其是在构建创业公司的人。早期的产品市场契合度不会很好，这会让人不舒服，但如果你为六个月后的模型构建，当那个模型出来时，你的产品就会一举腾飞。

主持人 Lenny："为六个月后的模型构建"这一点，具体来说人们可以假设会发生什么？是不是就是"它在某件事上几乎够好了，这是它会变得更好的信号"？

Boris Cherny：

我觉得这是一个好的判断方式。在 AI 实验室内部，我们当然能看到它具体在哪些方面变得更好。它会越来越擅长使用工具和计算机——这是我会押注的一点；另一点是它会越来越能长时间持续运行。看看进步的轨迹：用 Sonnet 3.5 的时候，大约一年前，它大概能运行 15 到 30 秒，之后就开始出问题，你必须全程紧盯着。而现在用 Opus 4.6，它平均可以无人看管运行 10 到 30 分钟，我可以启动一个任务然后去做别的事。有些任务可以跑几小时甚至几天，也有例子是跑了好几周。所以我认为，随着时间推移，模型能长时间自主运行会越来越普遍，你不再需要一直守着它。

使用 Claude Code 的专业技巧

主持人 Lenny：对于第一次使用 Claude Code 的人，或者已经在用、想要提升的人，有什么专业技巧可以分享？

Boris Cherny：

先说一个前提：没有一种"正确的方式"使用 Claude Code。这是一个开发者工具，开发者各有不同，有不同的偏好和环境，所以有很多方式可以用，没有唯一正解。你需要找到适合自己的方式。好在你可以直接问 Claude Code，它能给出建议，能编辑你的设置，它对自己有所了解，可以帮你找到适合的方式。

具体来说有几条我觉得普遍有用的技巧。第一，用最强的模型。目前是 Opus 4.6，有人会尝试用便宜一点的模型，比如 Sonnet，但因为它不那么智能，完成同样的任务其实会用更多 token。所以用便宜的模型未必真的更便宜——用最强的模型，往往反而更便宜，因为它能用更少的来回、更少的纠错完成任务。

第二，用计划模式（Plan Mode）。我开始大约 80% 的任务时会先用计划模式。这其实非常简单，就是在提示里注入一句话"请先不要写任何代码"，就这一句，没有别的花哨的东西。在终端里，按两次 Shift+Tab 就进入计划模式；在桌面应用和网页版，有一个按钮；移动端很快也会有；Slack 集成也刚刚上线了。本质上是模型和你来回确认计划，等计划看起来没问题了，再让模型执行。我在计划确定后会开启"自动接受编辑"，因为如果计划是好的，模型通常会一步到位搞定，用 Opus 4.6 几乎每次都是第一次就对。

第三，尝试不同的界面。很多人一想到 Claude Code，就想到终端。我们当然支持所有终端，Mac、Windows、任何你用的终端，运行完美。但我们也支持很多其他形式——iOS 和 Android 应用、桌面应用、Slack 集成等等。试试这些，每个工程师、每个构建者都不一样，找到适合你的方式。不管用哪个界面，底层是同一个 Claude Agent。

对 Codex 的看法

主持人 Lenny：对 Codex 你怎么看？你对他们的走向有什么感觉？在编程 Agent 这个竞争激烈的领域，他们的定位是什么？

Boris Cherny：

我其实没怎么用过，但发布时我试用了一下，看起来很像 Claude Code，这让我有点受宠若惊。我觉得竞争是好事，人们应该有得选，而竞争会迫使我们所有人做得更好。但说实话我们的团队主要专注于解决用户的问题，不会花很多时间研究竞争对手，也不会特别去试其他产品。对它们保持知晓是有必要的，但对我来说，我热爱和用户交谈，热爱改进产品，热爱响应反馈，所以一切都是关于构建好产品。

Boris 的 AGI 后计划

主持人 Lenny：Anthropic 联合创始人 Ben Man 建议我问你的：你的 AGI 后计划是什么？一旦我们到达 AGI，不管那意味着什么，你会做什么？

Boris Cherny：

在加入 Anthropic 之前，我住在日本农村过着完全不同的生活。我是那个小镇上唯一的工程师，唯一讲英语的人，是完全不同的节奏，和旧金山完全不同。有一件我非常享受的事，是和邻居建立友谊的方式——交换腌菜。那个小镇里，大家都做味噌，大家都做腌菜，所以我学会了做味噌。味噌有趣的地方在于，它教会你用完全不同的时间尺度去思考——白味噌至少需要三个月，红味噌要两三四年，你必须非常非常有耐心等待，这和工程完全不同。我喜欢它的原因就是这种超长时间尺度的思维方式。所以我想 AGI 之后，或者如果没有在 Anthropic，我大概会去做味噌。

我想再说一件事——对于 Anthropic 来说，"从编程开始，然后到工具使用，然后到计算机使用"这一路线图，一直是我们思考事物的方式，也是我们知道模型会如何发展、或者说我们想要如何构建模型的方式，同时也是我们最能学习安全、研究安全、改进安全的方式。现在 Claude Code 正在变成一个庞大的、多十亿美元的业务，我的朋友们都在用 Claude Code，不停地发消息给我说这件事有多好。这一方面是惊喜，因为我们不知道是这个产品、不知道是从终端开始；另一方面又完全不意外，因为这一直是我们公司长期以来的信念。同时，感觉仍然很早期——世界上大多数人还没有用过 Claude Code，还没有用过 AI，所以感觉才完成了 1%，还有太多事情要做。

主持人 Lenny：听到这些数字、你们刚刚融了那么多钱、Claude Code 单独可能就有 20 亿美元的收入，Anthropic 整体据说有 150 亿，再想这才是多早期，真的很难想象。

Boris Cherny：

是很疯狂，而且 Claude Code 能持续成长，真的全靠用户——这么多人在用，他们那么热情，他们爱上了这个产品，然后告诉我们哪里不好、哪里需要改进。持续改进的唯一原因，就是所有人都在用，都在谈论，都在给反馈。这是我最爱的方式——和用户交谈，让它变得更好。

闪电问答与结束语

主持人 Lenny：Boris，我们来到激动人心的闪电问答环节！五个问题，第一个问题——你最常推荐给别人的两三本书是什么？

Boris Cherny：

我先推荐一本技术书：《Scala 函数式编程》。这是我读过的最好的技术书，很奇特，因为你可能不会用到 Scala，也不知道将来这还有多大意义，但函数式编程和类型思维的优雅之美，是我写代码和思考编程的方式，很难改变。可以把它当作一件历史文物，也可以当作一本让你大幅提升的书。

第二本是 Charles Stross 的《加速奏鸣曲》（Accelerando）。这可能是我读过的最能捕捉我们当下这个时代本质的书——它的节奏越来越快、越来越快，故事从起飞开始，接近奇点，最终以一种集体的龙虾意识绕木星轨道飞行告终，而这一切发生在短短几十年里。节奏本身就是一种体验，我非常爱它。

第三本是刘慈欣的《流浪地球》短篇小说集。很多人知道他是因为《三体》，我也觉得三体很棒，但我更喜欢他的短篇小说。而且读中国科幻很有趣，因为视角和西方科幻非常不同，刘慈欣的文字也非常优美。

主持人 Lenny：你最近有没有特别喜欢的电影或电视剧？

Boris Cherny：

我其实不太看电视或电影，最近实在没时间。我看了 Netflix 的《三体》剧集，我觉得改编得非常好。

主持人 Lenny：你最近发现了什么特别喜欢的产品？

Boris Cherny：

Cowork——这是真心话，是对我最有改变的一个产品。我一直在用它，Chrome 集成尤其出色。它帮我缴了停车罚单，帮我取消了几个订阅，处理了太多繁琐的事情，太好了。除了产品，还想推荐一个播客——《Acquired》，Ben Gilbert 和 David Rosenthal 主持的，除了 Lenny 的播客当然。他们深入挖掘商业历史、让它重焕生机的方式非常出色，推荐从任天堂那期开始听。

对于刚开始用 Cowork 的人，我的建议是：先下载 Claude 桌面应用，进入 Cowork Tab，然后第一步，让它比如整理一下桌面，或者总结一下你的邮件，或者帮你回复最重要的三封邮件（它现在也帮我回邮件了）。第二步，连接工具——比如"看一下我的重要邮件，然后把它们同步到 Slack 或 Spreadsheet"。第三步，并行运行多个任务——你可以同时运行任意多个 Cowork 任务，我会启动项目管理任务，再启动别的，然后去倒杯咖啡让它们跑。

主持人 Lenny：你有没有一个经常回想起来的人生座右铭或格言？

Boris Cherny：

运用常识。我在工作环境中看到的很多失败，是人们简单地没有运用常识——他们遵循流程却不去思考，或者做一件事却不去想，或者在做一个不好的产品却只是顺着惯性走。我看到最好的结果来自于从第一原则出发思考，发展自己的常识。如果一件事闻起来不对，那大概就不是个好主意。这是我最常给同事的建议。

主持人 Lenny：最后一个问题——你最近在 Twitter/X 上活跃了很多，为什么？体验怎么样？

Boris Cherny：

我之前一直用 Threads，因为我参与过 Threads 的早期构建，也真的很喜欢它的设计，很干净。我开始用 Twitter，是因为去年十二月我无聊了——我太太和我在欧洲旅行了一个月，去了哥本哈根和好几个国家。对我来说那是"编程假期"，每天就是编程，这是我最喜欢的假期。某一天，我编程编到没想法了，就打开了 Twitter，看到有人在发关于 Claude Code 的推，我就开始回复，然后开始主动找有 bug 的帖子，自我介绍，问大家有没有 bug 和反馈。大家对我们响应反馈的速度感到很惊讶，因为现在如果有人说了一个 bug，我大概几分钟就能修好——让 Claude Code 去处理，描述清楚就行，它处理，我去回复下一条。Twitter 上的体验非常好，和大家互动、听反馈、了解需求，都很棒。