昨天，Claude Code 之父 Boris Cherny 又来爆料了！
过去的一年，Claude Code 在不知不觉间已经彻底了改变了软件界。一年的时间里， Github 上就有 4% 的项目都是 Claude Code 提交的。
正当 Claude Code 一周年之际，知名播主 Lenny 跟 Boris 来了一场“周年总结与展望”，既回顾了自己加入 Anthropic 后打造 CC 的经历，总结了内部模型的发展脉络，也给出了未来几年打造AI产品的方向、方法和技巧。
Boris 直言不讳地表示：年底之前，“软件工程师”头衔在某些地方可能会消失！因为编程这件事“基本已经解决”了。
作为一名曾经非常高产的程序员，Boris 坦承：目前自己 100% 的代码是由 CC 生成的。他的工作流是这样的：
告诉 Claude Code 要做什么→AI 自动生成代码、调用工具、执行操作。他只做一件事：审查代码。
"写代码本身往往是繁琐的细节工作——处理git、调工具、修依赖……那不是最有趣的部分。"真正有价值的是：决定做什么、和用户对话、设计系统架构。
接下来，会被AI颠覆的工作岗位将是什么？Boris 表示：前沿已经不在编码上了，而是“编码邻近”的工作。所有使用计算机终端的岗位，比如：产品经理、设计师、数据科学家，等等，都将会被AI所改变。
Anthropic 内部是如何创新的？
Boris 重点强调了两点：给足空间和保持原则。
创新这件事是无法强迫的。没有一张明确的路线图可以指向创新。你只能给人空间。
而具体是什么原则？Boris 给出了两条：
一个原则是：在早期阶段刻意“少给资源”。另一个原则是鼓励速度，如果今天能做，就今天做。
当然，这里的少给资源并不是指优化成本。相反，Boris 经常给其他公司的CTO们建议：
“一开始不要优化成本，不要急着削减开支。先给工程师尽可能多的 token。
在 Anthropic，大家都可以使用大量 token。现在有些公司甚至把“无限 token”当作员工福利。我非常鼓励这种做法。”
另外，对于打造CC的过程，Boris 还总结道，打造AI产品与打造传统产品的思维是相反的。他自己一开始画了一个月的原型，发现没有一个原型是可用的。相反他又花了一个月的时间做后训练再返回去打磨原型反而成功了。
在传统工程中，如果你做产品，就要理解基础设施、运行时、虚拟机、编程语言、底层系统。
而在 AI 领域，如果你想做出好产品，你就必须真正理解模型本身。
另外，Boris反复提及了一个产品概念：“潜在需求”。这里有两点解释：
第一，观察用户：如果你设计的产品被用户以未预期的方式使用，并且他们因此完成了自己想做的事情，这会告诉你产品下一步该往哪里发展。
第二，观察模型：产品就是模型，观察模型想做什么，让它更容易。
产品就是模型，我们提供最小的框架和工具，让模型决定如何使用工具、以何种顺序执行操作。这也是潜在需求在模型上的应用。
此外，面向未来的模型构建AI产品，已经成为了业内共识。但很少人会进一步明确点出未来的模型会是什么样子。
Boris很直白的曝出了Claude模型的训练轨迹：“先让模型擅长写代码，然后擅长使用工具，接着擅长操作计算机。这是我们构建安全 AI 的发展轨迹。”
另一个方向则是，它会越来越擅长长时间运行任务。
言外之意，以后的产品构建，要考虑到“擅长操作计算机”和“长时程运行能力”的模型层面。下一个软件开发方式的重大转变是什么？
Boris 的回答可以说非常反直觉：让AI自己提想法，而人类只负责提供原始数据。
“Claude 正在开始提出自己的想法。它会分析用户反馈、查看 bug 报告、分析遥测数据，主动提出修复和发布建议。它更像是一个同事。”
总之，岗位之间的界限会更加模糊，“产品经理写代码”这件事将越来越普遍。
而“软件工程师”这个头衔会慢慢消失，被“构建者（builder）”取代。
此外，Boris 用 14 世纪的印刷术类比今天的 AI：
印刷机问世后的 50 年里，印刷材料的数量超过了此前 1000 年的总和。印刷品的数量暴增，成本却在 50 年内下降了大约 100 倍。
他认为，未来的世界将会因 AI 而迎来新一轮的“文艺复兴”。
Boris还详细分享了Anthropic的内部模型安全研究策略，以及自己曾短暂跳槽到Cursor的趣事。
篇幅关系，这里不再一一赘述。
以下是小编为大家梳理的精彩观点。今天是初五，大佬们“迎财神”了！
CC一年，改变了软件的工作形态
主持人：
今天的嘉宾是 Boris Cherny，Anthropic 旗下 Claude Code 的负责人。
很难用语言形容 Claude Code 对世界产生了多大的影响。等这期节目上线时，Claude Code 也将迎来发布一周年。在这短短一年里，它彻底改变了软件工程师的工作方式，并且现在开始改变科技行业中其他岗位的工作形态——
我们稍后会谈到这一点。
Claude Code 本身也是 Anthropic 在过去一年高速增长的重要驱动力。他们刚刚完成一轮融资，估值超过 3500 亿美元。正如 Boris 所说，Claude Code 的增长还在加速，仅过去一个月，日活跃用户就翻了一倍。
Boris 也是一个非常有深度、极具思考力的人。在这次对话中，我们还意外发现我们出生在乌克兰同一座城市，这太巧了。
最短的一次跳槽：
曝Boris短暂离开Anthropic，去Cursor
主持人：
Boris，非常感谢你来参加节目。
我想问一个有点“刺激”的问题。大约 6 个月前，你其实离开了 Anthropic，加入了 Cursor。但两周后你又回到了 Anthropic。这到底发生了什么？我从来没听过完整故事。
Boris Cherny：
那是我职业生涯里最短的一次跳槽。
我加入 Cursor，是因为我是这个产品的忠实粉丝。我见到了团队成员，也真的被他们打动。他们非常优秀，至今我仍然认为他们很棒。他们在很多人之前就看到了 AI 编程的发展方向。所以参与构建优秀产品这件事，对我来说非常有吸引力。
但当我真正加入之后，我很快意识到，我真正怀念的是 Anthropic 的使命感。
在加入 Anthropic 之前，我曾在大型科技公司工作。后来有一段时间，我希望去一家研究实验室，参与塑造这项疯狂技术的未来。吸引我加入 Anthropic 的核心原因，就是它的使命——安全。
当你在 Anthropic 随便在走廊里拦下一个人，问他为什么在这里，答案几乎都会是“为了安全
”。这种使命驱动感深深打动了我。我个人需要这种使命感才能真正感到快乐。
不管工作本身多么有趣，即便是在打造一款很酷的产品，也无法替代这种使命。
所以我很快就意识到，我缺失的正是这一点。
Github 4% 代码由CC生成
曝Claude模型训练路径
主持人：
这期节目上线时，正值 Claude Code 发布一周年。
最近一份报告显示，目前 GitHub 上 4% 的代码提交是由 Claude Code 生成的，而且预测到年底会达到 20%。报告中甚至说：“在我们眨眼之间，AI 已经吞噬了整个软件开发。”
就在今天，Spotify 也发布消息称，他们最优秀的开发者自去年 12 月以来就没有再手写一行代码。
包括你在内，越来越多资深工程师公开表示自己已经不再写代码，甚至不再看代码。这在很大程度上源自你们一年前启动的这个“小项目”。
你如何看待这一年的影响？
Boris Cherny：
这些数字真的非常疯狂。4% 的全球提交量，远远超出我的想象。而且这感觉还只是起点。
更重要的是，这些只是公开仓库的数据。我们认为在私有仓库中的比例会更高。
对我来说更疯狂的不是当前数字，而是增长速度。Claude Code 几乎在所有指标上的增长都在加速。不是简单地上涨，而是涨得越来越快。
最初我启动 Claude Code 时，它只是一个小 hack。在 Anthropic，我们一直知道要推出某种编程产品。我们的模型训练路径大致是：先让模型擅长写代码，然后擅长使用工具，接着擅长操作计算机。这是我们构建安全 AI 的发展轨迹。
我当时所在的团队叫 Anthropic Labs。我们打造了 Claude Code、MCP，以及桌面应用。你可以看到这条路线的种子——从写代码，到用工具，再到真正操作计算机。
这对 Anthropic 至关重要，因为随着 AI 能力越来越强，安全问题也越来越关键。
过去一年里真正发生的变化是：对工程师而言，AI 不再只是写代码的对话伙伴，它会真正调用工具，在现实世界中执行操作。
而现在，随着“协作型 AI”出现，我们开始看到这种能力向非技术岗位扩展。
Boris Cherny：
对于很多使用对话式 AI 的人来说，这可能是他们第一次接触到“会行动的 AI”。它真的可以操作你的 Gmail，可以用你的 Slack，可以替你完成各种任务，而且表现还相当不错。而且只会越来越强。
在 Anthropic，很长一段时间我们都觉得“要做点什么”，但到底做什么并不清晰。
Claude Code诞生：
花了一个月做后训练返回去做原型
做AI产品，需要理解模型本身
Boris Cherny：
我加入 Anthropic 之后，先花了一个月时间“瞎折腾”。做了很多奇怪的原型，大部分都没发布，甚至离发布很远。那只是为了摸清模型能力的边界。
接着我又花了一个月做后训练（post-training），去理解研究层面的东西。作为工程师，我始终认为，如果你想把工作做好，就必须理解你所工作的那一层之下的那一层。
在传统工程中，如果你做产品，就要理解基础设施、运行时、虚拟机、编程语言、底层系统。而在 AI 领域，如果你想做出好产品，你就必须真正理解模型本身。
所以我绕了一段路去理解模型，然后回来开始做原型，最终演变成 Claude Code。
最初版本我还录过一个演示视频，当时它叫 ClaudeCLI。我展示了它如何使用一些工具。真正让我震惊的是，我给了它一个 bash 工具，它竟然自己用这个工具写代码，回答了我一个问题——“我现在在听什么音乐？”
最疯狂的是，我根本没有明确告诉模型该如何使用这个工具。它只是被赋予了这个工具，然后自己学会如何使用它来回答我提出的问题。
后来我继续打磨这个原型，发了个内部帖子宣布这个项目，结果只收到了两个点赞。这就是当时的全部反应。
为什么只做CLI，而不做其他形态？
Boris Cherny：
因为大家一想到编程工具，脑子里就是 IDE，是那种复杂的可视化环境。没人会想到一个基于终端的工具会成为未来形态。
但一开始只有我一个人做这个项目，终端是最简单的方式。这其实是一个很重要的产品教训——在早期阶段，你应该刻意“资源不足”地去做。
后来我们讨论要不要做其他形态的产品，但最终还是决定先坚持终端。原因很简单：模型进步得太快了，我们认为没有其他形态能跟得上它的演进速度。
那段时间我几乎满脑子都是这个问题：模型越来越强，我们怎么才能跟上？终端是我唯一想到的答案。
发布后它很快在 Anthropic 内部流行起来，日活曲线几乎是垂直上升。
实际上，在我正式发布之前，Benjamin Mann还提醒我做一张 DAU 曲线图。我当时觉得“是不是太早了？”
他说：“做。”
结果曲线几乎立刻直线上升。
一开始并没有爆，
最好的信号是用户反馈
2 月我们对外发布。很多人现在可能不记得，Claude Code 一开始对外并不是爆款。它确实吸引了一批早期用户，但花了好几个月，大家才真正理解这到底是什么。
因为它太不一样了。它把工具带到用户已有的工作流里，让事情变得更轻松。但因为它是终端形态，它又有点“陌生”、有点“异类”。用户必须愿意尝试，愿意学习。
现在 Claude Code 已经无处不在——它在 iOS 和 Android 应用里，在桌面端，在网页上，在 IDE 插件里，在 Slack、GitHub 里。它存在于工程师工作的每个场景。
但那不是起点。回头看，这段经历非常谦逊。我们不断从用户那里学习。从小创业公司到最大的 FAANG 公司都在使用它，给我们反馈。
最让我兴奋的是：其实我们谁也不知道终局会是什么。我们只是和所有人一起摸索。而最好的信号来源，始终是用户反馈。
在今天这个世界，一切变化的速度快得惊人。
ScalingLaws 前三的作者都在Anthropic
主持人：
一年前你发布这个产品时，AI 写代码已经存在。但一年之后，整个软件工程职业都发生了巨变。
当初大家还说“100% 的代码由 AI 写？太疯狂了。”现在却成了“当然会这样”。变化太快了。
Boris Cherny：
确实非常快。
去年 5 月，在 Anthropic 的开发者大会上，我做了一个分享。Q&A 时有人问我对年底的预测。我当时的预测是：到年底，你可能不再需要 IDE 编程了，我们会看到工程师不再以传统方式写代码。
现场几乎能听到倒吸冷气的声音。
但在 Anthropic，我们习惯用指数思维。我们的联合创始人中，有三位是 Scaling Laws 论文的前三作者。指数增长是写在公司 DNA 里的。
当时如果你画出 Claude Code 生成代码占比的增长曲线，只要简单延长那条线，你会发现到年底突破 100% 是显而易见的，哪怕直觉完全无法接受。
我只是把那条线延长。到了 11 月，对我个人来说，这已经成为现实。现在越来越多客户也正在经历同样的变化。
AI 创新无法强迫，往往没有清晰的路线图
主持人：
你刚才说的那段经历很有意思——就是不断尝试、不断试验。很多 AI 创新似乎都源于某个人“随便试试”，然后突然发生了点什么。
这似乎是 AI 创新的核心成分之一。
Boris Cherny：
创新这件事是无法强迫的。没有一张明确的路线图可以指向创新。你只能给人空间。
也许更准确的词是“安全感”——
心理安全感。让人知道失败是可以的，80% 的想法是糟糕的也没关系。
但与此同时，也要保持原则。如果一个想法行不通，就及时止损，转向下一个，而不是继续投入。
在 Claude Code 的早期阶段，我根本不知道这东西到底有没有用。哪怕在 2 月对外发布时，它也只写了我大概 20% 的代码，不算多。到了 5 月，也不过 30%。那时候我大部分代码还是用 Cursor 写的。直到 11 月，它才真正跨过 100%。
所以这中间其实经历了一段时间。但从最早开始，我就隐约感觉自己抓住了什么。我几乎每天晚上、每个周末都在折腾它。幸运的是，我太太非常支持。它到底是什么并不清晰，但有时候你发现了一根线头，就必须一直往下拉。
Boris 目前的编程工作流
主持人：
所以现在你 100% 的代码都是 Claude Code 写的？
Boris Cherny：
对，100% 都是 Claude Code 写的。我算是个产出很高的工程师。早在 Instagram 工作时，我就是团队里产出最高的几个人之一。现在在 Anthropic 也是如此。
主持人：
哪怕你现在是团队负责人？
Boris：
是的，我仍然写很多代码。每天我会提交 10、20、30 个 PR。
主持人：
每天？
Boris：
每天。全部由 Claude Code 写。我自 11 月以来没有手动改过一行代码。
不过我会审阅代码。我们还没到完全“放手”的阶段。尤其当很多人在运行同一个系统时，你必须确保代码正确、安全。
在 Anthropic，Claude 会自动审查 100% 的 PR。之后仍然有人类复审。你还是需要这些检查点——除非只是纯原型代码。
真正的前沿并不在编码：
让Claude帮你决定做什么
主持人：
现在 100% 的代码由 AI 编写，这听起来曾经像疯狂的里程碑，如今却成了“当然如此”。那软件开发的下一个重大转变会是什么？
Boris Cherny：
正在发生的一件事是，Claude 开始主动提出想法。它会阅读反馈、查看 bug 报告、分析遥测数据，然后提出修复建议或新功能建议。它越来越像一个同事。
第二个变化是，我们开始走出“纯编码”。我认为，对我这种类型的编程来说，编码问题基本已经解决了。Claude 可以完成。
那接下来是什么？有很多与编码相邻的工作。而且我每天都用 Claude 处理与编码无关的事情，并让它自动完成。
比如前几天我要交一张停车罚单，我直接让 Claude 去做。我团队的项目管理几乎全部由 Claude 处理
——同步表格、发 Slack 消息、发邮件等等。
所以真正的前沿并不在编码本身。未来几个月，我们会看到整个行业在各种代码库、各种技术栈上逐渐实现“编码问题已解决”。
主持人：
让 AI 帮你决定“做什么”这件事非常有意思。很多产品经理听到这里可能会开始紧张。你是怎么用 Claude 来帮你决定做什么的？
Boris Cherny：
最简单的方法：打开 Claude，把一个 Slack 讨论串丢给它。
我们有一个内部频道，专门收集关于 Claude Code 的反馈。从 2024 年内部发布开始，这个频道就像消防水管一样源源不断。
早期我会亲自逐条处理反馈，尽可能在 1 分钟或 5 分钟内修复。这种超快的反馈循环会鼓励更多人反馈，因为他们感到被听见。
大多数产品的反馈都会掉进黑洞，所以用户不再反馈。如果你让他们感觉被重视，他们就会愿意参与改进。
现在 Claude 会帮我做大量工作。我把频道丢给它，它会说：“这里有几个可以修复的问题，我已经提交了几个 PR，要不要看一下？”我说：“好。”
Claude工程团队扩大了四倍
人均生产力提升了2倍
主持人：
它在这方面提升明显吗？这几乎是圣杯问题。构建问题解决了，代码审查成了瓶颈。接下来就是“决定做什么”。
比如 Opus 4.6 是否带来了飞跃？
Boris Cherny：
提升非常明显。一部分来自针对编码的专项训练。4.6 真的很强。
但有趣的是，很多非编码领域的训练也能迁移过来。模型在 X 上提升，会带动 Y 的能力。
过去一年，我们工程团队规模可能扩大了 4 倍左右。但人均生产力提升了 200%。以 PR 数量衡量，这个数字对真正做开发生产力研究的人来说是疯狂的。
我以前在 Meta 负责全公司的代码质量，包括 Facebook、Instagram、WhatsApp。
那时候，如果一年提升几个百分点的生产力，就已经是重大胜利。而现在我们谈的是数百个百分点。
更疯狂的是，这一切竟然被“正常化”了。我们听到这些数字，反应却是：“当然，AI 会这样。”
但这真的是史无前例的变化。软件开发、产品构建、整个科技行业，都在被重塑。我们很容易习惯它，但必须意识到——这很疯狂。
快速创新的副作用：
思维不能停留在旧模型
Boris Cherny：
当然也有副作用。模型变化太快，有时候我会被困在旧思维里。
甚至我发现新加入的工程师，尤其是刚毕业的，会以一种更“AGI 导向”
的方式工作。
举个例子：几个月前我们遇到内存泄漏问题。传统做法是抓取 heap snapshot，用专门的调试工具分析。
我当时就是这么做的。而一位新人直接对 Claude 说：“看起来有内存泄漏，帮我找原因。”
Claude 做了和我一样的事——抓取 heap snapshot，为自己写了一个小工具来分析，然后找出了问题。
Boris Cherny：
它当时就像一个“即时生成”的小程序。它找到了问题，并且比我更快地提交了一个 PR。所以，对我们这些已经使用模型很久的人来说，你必须不断把自己拉回到当下，而不是停留在旧模型的认知里。现在已经不是 Sonnet 3.5 时代了，新模型完全不一样。思维方式也必须随之改变。
Claude Code 团队的原则
主持人：
我听说你为团队总结了一些非常具体的原则。新人加入时你会带他们过一遍。其中一个原则是：“有什么比自己做更好？让 Claude 来做。” 你刚才那个内存泄漏的例子，听起来就像你差点忘了这个原则。
Boris Cherny：
还有一件有意思的事情：当你在早期阶段刻意“资源不足”时，人会被迫变得更有创造力。
比如我们在做 Co-work 项目时，有时只放一个工程师进去。但他们之所以能很快交付，是因为他们“想”交付。这是一种内在动机。你有一个好想法，就会想尽快把它推出去，不需要别人逼你。
而如果你有 Claude，你就可以用它自动化大量工作。我们反复看到这种情况。
所以一个原则是：在早期阶段刻意“少给资源”。
另一个原则是鼓励速度。如果今天能做，就今天做。这一点我们非常强调。
最初只有我一个人，我们唯一的优势就是速度。那是我们在竞争激烈的编程市场中生存的方式。
现在即便团队扩大了，这仍然是我们的核心原则。而如果你想更快，一个好办法就是让 Claude 多做事。
主持人：
“刻意资源不足”这个观点很有意思。很多人觉得 AI 会让你不需要那么多员工。你却说，不只是效率更高，而是团队人少反而能更好地利用 AI。
Boris Cherny：
如果你雇的是优秀工程师，他们会自己想办法完成任务。尤其是当你赋予他们足够的自主权。
我常和很多 CTO 聊这个话题。我的建议通常是：一开始不要优化成本，不要急着削减开支。先给工程师尽可能多的 token。
在 Anthropic，大家都可以使用大量 token。现在有些公司甚至把“无限 token”当作员工福利。我非常鼓励这种做法。
因为这让人有自由去尝试那些看似疯狂的想法。如果想法成功了，再去考虑如何优化、如何降成本——比如从 Opus 换成 Sonnet 或 Haiku。但不要过早优化。
公司应该给工程师无限 token
主持人：
所以你的建议是，在 token 成本上要“宽松一点
”？
有人可能会说，你在 Anthropic 工作，当然希望大家多用 token。但你的意思是，真正有创新性的想法，往往来自于把模型推到极限。
Boris Cherny：
是的。而且现实是，小规模实验的 token 成本并不高。对单个工程师来说，token 花费相对于工资或公司运营成本，其实不算大。
等到项目成功并规模化，token 成本真的变大时，再去优化也不迟。但不要过早削减。
主持人：
你见过 token 成本高于工资的情况吗？
Boris Cherny：
在 Anthropic，我们已经看到一些工程师每月花费几十万美元的 token。类似情况在其他公司也开始出现。
总会有人，喜欢手工创作
主持人：
回到编码。你会怀念亲自写代码吗？
Boris Cherny：
对我来说，学工程一直是很务实的。我学编程是为了“做东西”。
我并非科班出身。我大学学的是经济学，但很早就自学编程。中学时我就在写程序。
最早的动机非常现实——我学编程是为了在数学考试作弊。我们当时有图形计算器，我把答案写进 TI-83 Plus 里。
后来题目变难，我没法预先写答案，于是我写了一个小求解器，让程序自动解代数题。再后来，我发现可以买根线把程序传给全班，结果全班都拿了 A，最后被老师抓到，勒令停止。
从一开始，编程对我来说就是
“做事的工具”，不是终点本身。
后来我确实一度沉迷于编程的“美”。我写过一本 TypeScript 的书，还创办了当时全球最大的 TypeScript 线下社群。也深入研究函数式编程。
编程确实有美感，尤其是类型系统、函数式设计。有时候解决一个复杂类型问题，就像解开一道优雅的数学题，那种快感很强烈。但它终究只是工具。
当然不是每个人都这样想。比如团队里有位工程师 Lena，她周末还会手写 C++，因为她真的喜欢写。
即便时代变化，总会有人享受“手工创作”的乐趣。
不担心技能退化
主持人：
你会担心技能退化吗？
Boris Cherny：
我不太担心。编程本身就在不断演进。软件历史并不长。今天这种运行在虚拟机上的软件编写方式，大概从 1960 年代开始算，也就 60 年左右。
在那之前，人们还在用打孔卡。在那之前是拨动开关的时代；再往前是纯硬件；更早的时候，真的就是纸和笔——一个房间里坐满了人，在纸上做数学计算。
所以，编程一直在以这种方式变化。某种程度上，你仍然需要理解“下一层”的原理，因为这会让你成为更好的工程师。我认为在接下来一年左右，这依然成立。
但很快，它可能就不会那么重要了。它会变成类似“在程序员之下运行的汇编代码”那样的存在——你知道它在那儿，但你不需要直接操作它。
从情感层面讲，我一直在不断学习新东西。作为程序员，这其实不算新鲜——总有新框架、新语言出现，我们对这种变化是习以为常的。但这并不适用于所有人。对一些人来说，他们可能会感到失落、怀旧，甚至觉得技能在退化。
我不知道你有没有看到，Elon 曾说，为什么 AI 不直接写二进制代码？既然最终都是抽象层，为什么不直接到底层？这是个好问题。理论上当然可以。
一两年后，学编程这件事已经不重要了
做真正有趣的事
主持人：
所以，如果把话说得更直白一点：大家总在问，要不要学编程？学校还需要教编程吗？听你刚才的意思，好像一两年后，可能就不那么必要了？
Boris Cherny：
我的看法是，如果你现在在用像Claude Code 这样的工具、用 agent 来写代码，你仍然需要理解底层原理。但一两年后，可能真的就无所谓了。
我一直在想，历史上有没有类似的转折可以类比？我们必须把这件事放进历史坐标里，看看人类什么时候经历过类似的跃迁。
对我来说，最贴切的类比是印刷机。
在欧洲，大约 15 世纪中期，识字率极低。不到 1% 的人口是抄写员，他们负责所有书写和阅读。他们为领主和国王工作，而那些领主和国王往往自己都不识字。
后来，古腾堡发明了印刷机。一个非常惊人的统计是：印刷机问世后的 50 年里，印刷材料的数量超过了此前 1000 年的总和。
印刷品的数量暴增，成本却在 50 年内下降了大约 100 倍。
当然，识字率并没有立刻飙升。学习读写很难，需要教育体系、需要时间，也需要人们不用整天在农田里劳作。
但在接下来的 200 年里，全球识字率上升到了约 70%。
我认为，我们可能正在经历类似的转型。
有一份历史记录很有意思：14 世纪有人采访一位抄写员，问他怎么看印刷机。他其实很兴奋。他说，他不喜欢做的是重复抄写的工作，他真正喜欢的是在书中画插图和装订书籍。印刷机让他从重复劳动中解放出来。
作为工程师，我有种类似的感受。写代码本身往往是繁琐的细节工作——处理 git
、调工具、修依赖……那不是最有趣的部分。
真正有趣的是：决定要做什么、和用户对话、构建系统架构、思考未来、和团队协作。
而现在，我可以把更多时间花在这些事情上。
不需要掌握所有的技术细节
主持人：
更有意思的是，你们做的这个工具，让完全没有技术背景的人也能做到这些。我最近在做一些小项目，一卡住就说“帮我解决这个”，然后马上解锁。
我职业早期做了 10 年工程师，记得自己花了大量时间折腾库、依赖、查 Stack Overflow。现在只需要说一句：“帮我搞定。”然后一步步给出解决方案。
Boris Cherny：
没错。我今天还和一位工程师聊。他用 Go 写一个服务，已经写了一个月，运行得很好。我问他感觉怎么样，他说：“说实话，我还是不太懂 Go。”我认为这种情况会越来越多。
只要你知道系统是正确的、高效的，你未必需要掌握所有细节。
下一个被改变的岗位：
任何需要使用电脑工具的工作
主持人：
软件工程师的工作已经彻底变了。过去一两年，几乎成了一种新职业。
你觉得下一个会被 AI 强烈影响的岗位是什么？在科技行业内部，比如产品经理、设计师？还是科技之外？
Boris Cherny：
我认为会是那些“贴近工程”的岗位。比如产品经理、设计师、数据科学家。
其实，只要你的工作是在电脑上完成的，都会被影响。模型会越来越擅长这些任务。
Co-work 只是第一步，它让很多以前没真正用过 agent
的人第一次接触 agent。
一年前，工程师几乎没人知道什么是 agent。现在，这是我们日常工作的方式。但在非技术或半技术领域，比如产品或数据工作，人们还主要在用对话式 AI——聊天机器人。
“agent”这个词被滥用了，几乎失去了意义。但从技术上讲，它有明确含义：
agent 是能够使用工具的大语言模型。
它不仅能对话，还能行动。它可以调用你的 Google Docs，发送邮件，在你的电脑上运行命令，与系统交互。
所以，任何需要使用电脑工具的工作，都会是下一波。
这也是为什么我觉得在 Anthropic 做这件事非常重要。我们非常认真地对待这个问题。
我们有经济学家、政策专家、社会影响团队。因为这不应该由我们单方面决定。社会必须参与讨论。
AI就像印刷机，会带来新一轮文艺复兴
主持人：
你提到了一个核心问题——就业。有人提到“杰文斯悖论”：效率提升反而带来更多需求，未必是零和。在工程领域，AI 变成重要工具之后，你们是在增加招聘吗？
Boris Cherny：
是的，我们在招人。
Claude Code 团队正在招聘。
Boris Cherny：
如果你有兴趣，可以去看看 Anthropic 的招聘页面。
就我个人而言，这些变化让我对工作更享受了。我从来没有像现在这样享受写代码，因为不必再处理那些琐碎的细节。对我来说，这非常令人兴奋。
很多客户也是这样反馈的，他们喜欢 Claude Code
，因为它让编码再次变得愉快，这对他们来说非常有趣。
不过，未来会怎样发展很难预测。我不得不去寻找历史类比，我觉得印刷机是最贴切的。
印刷机的出现，让原本只属于少数人的知识——读写能力——变得人人可及。这本质上是民主化的，每个人都能参与其中。如果不是这样，文艺复兴也不可能发生，因为文艺复兴很大程度上是知识的传播，是通过书面记录进行沟通的——当时没有电话，也没有互联网。
我想象未来几年，人人都能编程。这会解锁什么潜力？任何人都可以随时开发软件。结果会怎样？谁也无法预测，就像 15 世纪没有人能预测印刷机会带来今天的世界一样。
当然，在此过程中，这会对很多人造成冲击，也会让人感到痛苦。作为社会，这是必须讨论和共同解决的问题。
最有回报的人：跨学科的通才
主持人：
对于那些想在这个 AI 时代脱颖而出的人，有什么建议吗？是多玩 AI 工具，熟练掌握最新技术，还是还有其他方法让人保持领先？
Boris Cherny：
基本上就是这两点：尝试各种工具，熟悉它们，不要害怕；勇于尝试前沿技术。
其次，我建议尽量成为通才，而不仅仅是专业狭窄的技术人。例如，很多学 CS 的人只学编程，可能了解一些系统架构，但其他方面几乎不涉猎。
我每天接触的最有效的工程师、产品经理，往往都是跨学科的。在 Claude Code 团队里，每个人都会写代码：产品经理写代码，工程经理写代码，设计师写代码，财务写代码，数据科学家也写代码。
一些最强的工程师是跨职能的，比如既懂产品又懂基础设施，或者既懂产品又有很强设计感，甚至懂商业逻辑，能用这些判断下一步做什么。还有些工程师喜欢和用户交流，能精准把握用户需求。
我认为，未来几年最有回报的人，不仅要 AI 原生、熟练使用工具，还要好奇、通才、跨学科思考问题，从更广的角度理解他们在解决的核心问题，而不仅仅是工程部分。
设计、产品、工程界限会更模糊
软件工程师头衔会消失，会被Builder取代
主持人：
你觉得把团队划分为工程、设计、产品管理三个领域仍然有用吗？即使现在大家都在写代码、参与产品决策，这三类角色会长期存在吗？
Boris：
短期来看会存在，但我们看到这些角色有大约 50% 的重叠，很多人实际上在做相同的事情。每个人都有特长：比如我写的代码多一些，Cat RPM 更擅长协调、规划、预测，或利益相关者对齐。
我认为，年底之前这些界限可能会更加模糊。在某些地方，“软件工程师”这个头衔可能会消失，被“Builder”取代，或者大家都是产品经理而且会写代码。
主持人：
你提到招聘压力很大，如何快速招到最优秀的人才。
Boris Cherny：
对，我们团队在招聘。Claude Code 团队也在招人。
主持人：
你刚才说自己现在更享受写代码。我在 Twitter 做了一个小调查，问工程师、产品经理和设计师，自从用 AI 工具后，他们是否更喜欢自己的工作。结果显示：
工程师和产品经理中约 70% 表示更喜欢工作，10% 表示更不喜欢；
设计师中只有 55% 表示更喜欢，20% 表示更不喜欢。
你有没有跟进过这些人？
Boris Cherny：
我们收到了一些回复，正在做后续调查，会在节目笔记中链接。设计师群体反馈不多，但我看到他们在 Anthropic 基本上都很技术化，即使非技术岗位，入职时也要通过很多技术面试。设计师大多会写代码，这让他们更喜欢现在的工作，因为不必总去麻烦工程师，可以自我解锁问题。
一些以前不写代码的设计师现在开始写，也很享受，因为他们可以自主解决问题。我很想听更多人的体验，可能情况并不完全一致。
产品设计最重要的原则：
潜在需求
Boris Cherny：
另外，人们也在用不同工具。设计师更多使用云桌面应用来编码。下载桌面应用后，有一个代码标签页，和 co-work 在同一界面，其实就是同样的 Claude Code agent。
最棒的是，可以同时运行多个 Claude Code 会话，我们称之为“multi-clauding”
。这对于非工程师来说更原生，真正做到了把产品带到用户身边，而不是强迫用户使用不同的工作流程。
你不想让用户刻意去学习新东西。无论他们在做什么，如果你能让这些操作更简单一些，这个产品自然会更好、更让人喜欢。这其实就是所谓的“潜在需求”原则，我认为这是产品设计中最重要的原则。
潜在需求的概念是：如果你设计的产品被用户以未预期的方式使用，并且他们因此完成了自己想做的事情，这会告诉你产品下一步该往哪里发展。
举个例子，Facebook Marketplace 的诞生。团队经理 Fiona 是 Marketplace 的创始经理，她经常提到这一点。早在 2016 年左右，他们观察到 Facebook 群组中 40% 的帖子都是买卖信息。用户在滥用群组功能，但不是安全意义上的滥用，而是因为原本没有设计用于买卖，但非常有用。显而易见，如果为买卖开发更好的产品，人们会喜欢，这也促成了 Marketplace 的成功。Facebook Dating 也是类似逻辑，通过观察发现 60% 的个人主页浏览来自非好友的异性用户，所以基于这个潜在需求构建产品是有意义的。
CLI里跑AI也属于潜在需求
同样，Co-work 的诞生也是潜在需求的体现。在过去半年里，我们看到很多用户使用 Claude Code 并不是为了写代码。有人用它种番茄，有人分析基因组，有人恢复损坏硬盘里的婚礼照片，还有人用它分析 MRI。
显而易见，用户为了实现这些目标不得不曲折地使用终端，也许我们应该为他们构建专门的产品。
大约在去年五月，我看到数据科学家 Brendan 在终端里用 SQL 分析数据，当时我很震惊：这是一种非常工程化的产品操作，很多工程师都不愿意用终端。他下载 Node.js 和 Claude Code，直接在终端里操作，接下来一周，其他数据科学家也都这样用了。这种“滥用”行为清楚地表明，你应该为这些用途构建专门产品，用户会喜欢。
潜在需求还有第二个维度：传统思路是观察用户做了什么，让它更容易；
现代思路是观察模型想做什么，让它更容易。最初设计 Claude Code 时，很多人把模型放进一个“盒子”，限定它只能做某个应用组件，指定如何调用工具和 API。
而我们做法是颠倒的：产品就是模型，我们提供最小的框架和工具，让模型决定如何使用工具、以何种顺序执行操作。这也是潜在需求在模型上的应用。
10天内打造出Cowork
主持人：
你提到 Co-work，你当时说团队在 10 天内就做出来了，这太疯狂了。除了用 Claude Code 构建之外，还有什么故事吗？
Boris Cherny：
有意思的是，当时 Claude Code 刚发布时并不是立刻爆火，而是经历了几个增长拐点。Co-work 一发布就比 Claude Code 更快获得成功，但归功于 Felix、Sam、Jenny 和整个团队，他们真的非常强大。Co-work 的诞生也是潜在需求驱动：我们看到用户用 Claude Code 做非技术任务，团队花几个月探索各种方案，最后有人提出直接把 Claude Code 放进桌面应用，这就是可行方案。10 天内，他们完全用 Claude Code 构建了产品。
Co-work 内置了复杂的安全系统和护栏，确保模型不偏离预期行为。比如我们随产品一起部署了整套虚拟机，Claude Code 自动生成所有代码。我们只需考虑如何让操作更安全、更自助化，特别是面向非工程师用户。整个过程用 Claude Code 完成，大约 10 天。发布时虽然还有粗糙之处，但这就是我们在产品和安全方面学习的方法：比预期更早发布，获取反馈，理解用户需求，从而决定产品未来方向。
主持人：
这一点真的很有意思，也很独特。传统理念是“早发布、向用户学习、迭代”，而 AI 的特殊性在于，很难预判模型能做什么，用户会如何使用它，因此提前发布尤其重要，这正体现了你说的潜在需求概念。
Anthropic模型安全的三层研究维度
对齐和可解释性、评测、真实环境反馈
主持人：
在 Anthropic 作为安全实验室的另一维度，就是安全性问题，因为模型安全有多种研究方式。
Boris Cherny：
最低层的是对齐和机制可解释性。这是指我们在训练模型时，确保它是安全的。到目前为止，我们已经有了比较成熟的技术来理解神经元的运作并进行追踪。例如，如果某个神经元与欺骗相关，我们可以开始监控它，了解它何时被激活。这就是对齐与机制可解释性——最基础的一层。
第二层是评测，本质上是在实验室环境下进行的。模型像放在培养皿中，你给它设置一个合成情境，然后问它：“模型，你会怎么做？你做得对吗？你是否对齐、安全？”
第三层是观察模型在真实环境中的表现。随着模型越来越复杂，这一点非常重要，因为它在前两层可能表现得很好，但在第三层未必同样出色。
我们很早就发布了 Claude Code，因为希望研究安全性。在内部，我们用了大约四到五个月来观察它，因为这是当时首次大规模发布的智能 Agent，也是第一批被广泛使用的编码 Agent，我们不确定它是否安全，所以必须先内部研究很久。
即便如此，我们也不断在对齐和安全方面学习，并把这些经验回馈到模型和产品中。
对于 Co-work 也是类似的，模型在新的场景中执行非工程任务，作为你的 Agent，它在对齐和评测上表现良好，也在少数客户使用中表现良好，但我们仍需确保它在真实世界中安全。这也是我们提前发布、称之为“研究预览”的原因，它会持续改进。长期来看，这是确保模型对齐并做正确事情的唯一方法。
在这个领域工作非常疯狂：竞争激烈，节奏快，同时又要面对模型可能失控造成损害的恐惧。找到平衡非常具有挑战性。你可以看到我们主要工作在三层：观察模型思考和操作、通过评测发现问题、提前发布以获取反馈。
机制可解释性研究：
模型不仅预测下一个token
还在做更深层次的处理
Boris Cherny：
我们甚至有观测工具，可以让你窥探模型“思维”的方向。我建议请 Chris Olah（备注：Anthropic 的联合创始人，解释性研究团队的核心人物）上节目，他是这一领域专家，开创了
“机制可解释性”研究。
核心理念是：大脑是什么？它由互相连接的神经元组成。类似的研究方法可以应用到模型中——虽然模型神经元不等同于动物神经元，但很多行为类似。
我们因此了解了神经元如何运作，某些层或神经元如何对应概念，概念如何被编码，模型如何进行规划和前瞻思考。过去我们不确定模型是否仅仅在预测下一个 token，现在已有强有力证据显示它在做更深层的处理。
随着模型增大，一个神经元可能对应多个概念，与其他神经元一起激活时形成更复杂的概念，这叫“叠加（superposition）”。这是我们不断学习的内容。
在 Anthropic，安全、可控地推动这一领域发展，是每个人工作的核心动力。我们也会开源这些研究成果，鼓励其他实验室安全地做类似工作。
例如 Claude Code，我们开源了沙箱环境，让任何 Agent 都能在安全边界内运行，不会访问系统的所有内容。我们希望其他人也能轻松遵循这一原则，这就是所谓“race to the top”。
不会担心Agent不work
主持人：
我也想更多了解这方面。还有一个我注意到的现象：工程师、产品经理等使用 Agent 时，会有一种焦虑感——当 Agent 不 work 时，会感觉生产力丢失，很想立即去解决。你和你的团队有这种感受吗？
Boris Cherny：
我一直有很多 Agent 在运行，目前大约有五个同时运行。早上醒来，我会检查它们的状态，比如在 Claude iOS App 中查看 Agent 执行情况。昨天写的代码，我会复核一遍，有时会有一点点焦虑，但现在操作非常方便。也许我个人没有强烈感受，因为 Agent 一直在运行。
我现在不再依赖终端，大约三分之一代码仍在终端里，三分之一用桌面应用，三分之一用 iOS 应用。非常意外，因为我没想到即便在 2026 年，我的编码方式会是这样。你描述的“仍在编码”非常准确，现在的编码就是告诉 Claude Code 你想做什么，而不必写实际代码。
我想，如果让过去用穿孔卡编程的人看到现代软件，他们会怎么想？很可能觉得“这不是真正的编码”
。我记得早期 ACM 杂志上有人也提过类似观点。我的祖父是苏联早期程序员，他用穿孔卡编程，我母亲小时候会在穿孔卡上涂画作画，那是她的童年记忆，而祖父的编程体验就是这些穿孔卡。
后来才过渡到软件，但我相信老一代程序员可能不会把软件当作“真正编码”。这个领域一直在变化。
不要试图把模型束缚起来
押注通用模型，不要过度微调
面向6个月以后的模型构建产品
主持人：
我再问几个问题吧。你分享了很多关于 AI 产品的建议，比如如何充分利用 AI、如何基于 AI 构建出色的产品。其中一个建议是：给团队尽可能多的 tokens，让他们自由实验。你还提到：构建产品时要顺应模型未来的发展，而不是局限于当前的模型。你还有其他建议吗？
Boris Cherny：
我会再分享几点。首先，不要试图把模型束缚起来。很多人在构建模型时本能地想让它按照特定方式运行，把它当作更大系统的一部分。比如有人会在模型上加严格的工作流程——先做步骤一，再做步骤二，然后步骤三，有一个复杂的调度器在控制。
但实际上，通常如果你给模型工具和目标，让它自己去解决问题，结果会更好。一年前可能还需要很多支撑框架，但现在不需要了。我不确定怎么称呼这个原则，但核心是：不要问模型能为你做什么，而是思考如何给它工具去完成任务。不要过度干预，不要一开始就提供大量上下文，而是给它工具，让它自己获取所需的上下文，这样效果最好。
第二个原则，更通用一点，就是“苦涩经验（Bitter Lesson）”。Claude Code 团队内部也参考了 Rich Sutton 十年前的博客，他的观点很简单：通用模型总会胜过特定模型。对他而言，可能是自动驾驶或其他领域，但这个道理很广。对我来说，最大的启示是：长期来看，总是押注通用模型，而不是微小模型或过度微调。工作流程可以稍微提高性能，但通常这些提升在下一个更强大的模型面前就会被抹去，所以不如等待下一代模型。
最后一点，也是 Claude Code 最早做对的：从一开始，我们就面向未来六个月的模型构建，而不是今天的模型。早期版本写的代码非常少，因为模型不够可靠——那时候是 Sonnet 3.5、3.6 等，这些模型还没成熟。我们的赌注是，随着模型变强，它最终能写大量代码。最早的迹象出现在 Opus 4 和 Sonnet 4 上，
Opus 4 是我们在五月发布的第一个 ASL3 级模型。当大家第一次使用 Claude Code 时，增长开始呈指数级。
对创业者来说，这个建议尤其重要：初期产品体验可能不佳，但如果为未来六个月的模型做准备，一旦模型成熟，产品就能顺利落地。
未来的模型：
越来越擅长使用工具和计算机、长时程运行
主持人：
你说的“为未来六个月的模型构建”，人们能假设什么会发生？只是一般性地变强吗？还是说模型几乎已经足够好，可以预期会更强？
Boris Cherny：
这是个好方法。在 AI 实验室里，我们能看到模型提升的具体方式，这有点不公平，但我们尝试公开讨论。模型会越来越擅长使用工具和计算机，这是一个我会押注的方向。另一个是，它会越来越擅长长时间运行任务。
以我个人经验，一年前用 Sonnet 3.5，它最多运行 15-30 秒就可能出错，需要不断指导。现在 Opus 4.6，平均可连续运行 20-30 分钟甚至更久，然后我可以启动另一个 Claude执行其他任务。我一直运行很多 Claude，有些甚至连续运行几周。随着时间推移，模型长时间自主运行会越来越普遍。
两个构建AI产品通用技巧
主持人：
我们刚讨论了构建 AI 产品的技巧，那如果只是第一次使用 Claude Code 或想提升使用效率，有哪些实用建议？
Boris Cherny：
先声明，没有单一正确方法。每个开发者都不同，环境和偏好也不同，所以必须找到自己的方式。幸运的是，你可以问 Claude Code，它能给出推荐、调整设置，也了解自身功能。
几个通用技巧：
1.使用最强大的模型——目前是 Opus 4.6，我总是开启最大努力模式。
有时有人用低成本模型（如 Sonnet），但因为智能较低，最终需要更多 tokens 完成任务，所以其实更强的模型更高效、少干预。
2.使用计划模式（Plan Mode）。我几乎 80% 的任务都用它。很简单：在模型提示里加一句话，“请先不要写代码”。
Boris Cherny：
计划模式其实没什么特别复杂的，就是最简单的方式。对于在终端使用的人，只要按两次 Shift + Tab 就能进入计划模式。桌面应用和网页都有一个按钮，移动端也很快会支持，我们也刚在 SWAC 集成里推出了这个功能。计划模式就是模型和你来回交流，一旦计划看起来可行，就让模型执行。我会自动接受之后的修改，因为如果计划没问题，Opus 4.6 几乎总能一次性完成。
第三个建议是尝试不同界面。很多人想到 Claude Code 就想到终端，我们支持所有终端：Mac、Windows 等等。但我们也支持 iOS、Android、桌面应用，还有 Slack 集成等等。每个开发者习惯不同，可以找到最适合自己的方式。你不用一定要用终端，同一个 Claude Agent 在所有平台都能运行。
主持人：
太棒了。再问几个问题。你对 Codex 有什么看法？你觉得它的发展方向如何？在这个竞争激烈的编码 Agent 领域，你怎么看待竞争？
Boris Cherny：
其实我没怎么用过 Codex，可能刚发布时试过一下，看起来很像 Claude Code，挺令人受宠若惊的。我觉得多一些竞争是好的，用户有选择，也促使我们做得更好。对于我们团队，我们更专注于解决用户的问题，不太关注竞品，也不会频繁去尝试其他产品。你当然要知道它们存在，但我更喜欢和用户沟通，改进产品，基于反馈行动。
Boris：AGI之后，大概会回去做“味噌”
主持人：
Benjamin Mann（
Anthropic 的联合创始人），想让我问你一个问题：AGI 之后你打算做什么？你的生活会是什么样？
Boris Cherny：
加入 Anthropic 前，我住在日本乡村，生活完全不同。我是镇上唯一的工程师，也是唯一讲英语的人。每周几次会骑车去农贸市场，经过稻田，生活节奏和旧金山完全相反。
我特别喜欢的一点是，通过交换泡菜结识邻居，建立友谊。镇上人人自制味噌（备注：日本传统发酵食品）、泡菜，我也做得不错，还会做很多批次。味噌制作很有意思，它教你长期思考技能，比如白味噌至少要三个月，红味噌可能两三四年，需要极大的耐心。我喜欢这种长期技能思维。如果我没在 Anthropic，我大概就是在做味噌。
主持人：
太棒了，未来可能就是深入味噌制作，变得非常精通。Boris，这太精彩了。
增长完全靠用户，根据用户反馈改进产品
主持人：
在进入闪电问答前，你还有什么想和听众分享的吗？
Boris Cherny：
我想强调一点，从一开始，Anthropic 就遵循这样的方法：先从编码开始，再到工具使用，再到计算机使用。这是我们观察模型发展的方式，也是研究安全、改进模型的方式。
Claude Code 变成数十亿美元的业务，很多朋友都在用，但大多数人仍未使用 AI，所以感觉这只是刚起步，还有很长的路要走。增长靠的完全是用户，他们热情使用，反馈问题，我们根据反馈改进产品。这是最重要的，也是我每天最喜欢做的事。
推荐《三体》，科幻小说帮助思考未来
自己要为未来尽一份力
主持人：
好的，我们进入闪电问答。第一个：你最常推荐给别人的两三本书？
Boris Cherny：
作为技术书，我推荐《Functional Programming in Scala》。这是我读过的最好的技术书，非常优雅，即使未来可能不会直接用 Scala，也能提升编程思维。
第二本是《Accelerando》by Charles Stross，我偏爱科幻小说。这本书节奏极快，
捕捉了当下科技发展和临近奇点的感觉，故事甚至延伸到集体意识在木星轨道上的场景。
第三本是《流浪地球》，作者是刘慈欣（《三体》作者）。我更喜欢他的短篇小说集，这部作品展现了中国科幻的独特视角，非常精彩。
科幻小说真的非常有趣，也写得很漂亮。它让我思考未来发展，帮我建立了模型去理解不同的世界。这也是我加入 Anthropic 的原因之一。当时我住在乡村，做长期技能相关的事情，一切都很慢，围绕季节和食物安排日常生活。我也读了很多科幻小说，在这样的时刻思考长时间尺度，觉得自己应该为未来尽一份力，这也是我最终来到 Anthropic 的原因，Benjamin Mann也在其中起了重要作用。
我顺便推荐一本科幻书《Fire Upon the Deep》（Vinge 著），非常棒，从 AI/AGI 角度非常有意思。还有《Deepness in the Sky》，续作也不错，非常长且复杂，但很值得读。
主持人：
你最近有喜欢的电影或电视剧吗？
Boris Cherny：
其实我很少看电视或电影，没时间。我看过 Netflix 上的《三体》系列，非常喜欢，书的改编做得很好。
曝 Co-work 灵活用法：
先处理单一任务，再连接工具，然后并行跑多个任务
主持人：
有没有最近发现的喜欢的产品？
Boris Cherny：
我喜欢 Co-Work，这是我觉得真正改变生活的产品。我一直在用它，特别是 Chrome 集成非常出色，帮我处理了很多繁琐事务，比如取消订阅、处理重复任务等。我也推荐另一档播客《Acquired》，Benjamin 和 David 做的，非常精彩，尤其是商业历史方面的讲解。我会从 Nintendo 那期开始听。
Co-Work 的用法也很灵活：先让它用一个工具，比如整理桌面、总结邮件、回复三封邮件；再连接工具，
比如 Slack 或电子表格进行团队项目管理，每周自动提醒未填写状态的同事；第三点是可以并行运行多个 Claude 任务，我可以启动多个任务，然后去喝咖啡，非常方便。很多人不了解这类 Agent，因为没用过，但它的功能类似于一年前的 Claude Code，只是发展更快。
主持人：
你觉得自己对 AI 的未来有价值吗？
Boris Cherny：
是的，我觉得自己对 AI 的未来有价值，这是一种“逆向突破”的体验。
从第一性原理出发，发展自己的常识
主持人：
你平时有没有喜欢的座右铭？
Boris Cherny：
用常识。我看到很多失败都是因为缺乏常识，人们机械地遵循流程、执行任务，或在不合适的产品上工作，没有独立思考。我觉得最好的结果来自于从第一性原理出发，发展自己的常识。如果感觉不对，很可能就是不好的决策。这也是我给同事们的核心建议。
在X上体验非常棒：新点子的来源
主持人：
你最近在 Twitter（X）上更活跃了，为什么？使用体验如何？
Boris Cherny：
我之前一直用 Threads，因为我当年参与过 Threads 的开发，也喜欢它的设计……
Boris Cherny：
Threads 是一个非常干净的产品，我非常喜欢。我最初用 Threads 是因为无聊。后来在十二月，我和我妻子在欧洲旅行，像流浪一样游走各地——
去了哥本哈根，也去了几个不同的国家。对我来说，这次旅行就是一次编码假期，每天都在写代码，这是我最喜欢的度假方式。
有一天我突然没了新点子，就打开了 Twitter，看到有人在讨论 Claude Code，我就开始回复他们，然后想到不如直接去找用户的 bug 或反馈。
于是我自我介绍，收集 bug 和反馈。大家可能有点惊讶，因为我们现在处理反馈的速度非常快。对我来说很正常，如果有人报 bug，只要描述清楚，我可以在几分钟内解决，然后继续处理下一个问题。但对很多人来说，这很令人惊讶。
总的来说，在 Twitter 上的体验非常棒，可以直接与用户互动，了解他们想要什么，听到 bug 和功能建议。前几天我还看到有人在 Twitter 上抱怨 Nikita Bier 发帖太多导致出问题，我希望现在已经修好了。
主持人：
Boris，非常感谢你今天来分享！
Boris Cherny：
谢谢你，Funny！大家再见！
参考链接：
https://www.youtube.com/watch?v=We7BZVKbCVw
——好文推荐——
OpenAI开发者平台负责人：我们活在硅谷泡泡里！很多AI部署确实负回报！曝OpenAI内部吃自己的狗粮，模型会把脚手架吃掉！SaaS黄金时代降至
大模型风向变了！CC之父：Opus4.6是我们最好的模型！为长时程Agent而生！实测玩疯了：一击必杀！超级可玩，连人物建模都更逼真了！
谷歌突发Gemini 3.1 Pro：刷爆全领域SOTA，堪称SVG王者，价格不变，清华姚顺宇参与：后续还会有更好模型！JeffDean：性能不止翻倍
