导读：本文内容整理自 Anthropic 创作者兼 Claude Code 负责人 Boris Cherny 在 Lenny's Podcast 频道之专访。

内容提要：鲍里斯·切尔尼在 Lenny's Podcast 探讨 Claude Code：当编码难题被解决后会发生什么

• AI 驱动的软件开发革命： Boris Cherny 认为，AI（如 Claude Code）已经并将继续彻底改变软件开发。他本人 100% 的代码由 AI 生成，且已不再手动编辑代码。这种转变将使每位工程师的生产力提高 200%，甚至可能导致“软件工程师”这一头衔消失，取而代之的是“构建者（Builder）”。
• AI 正在“攻克”编程难题： 编程本身正在被 AI 大规模解决。AI 不仅能编写代码，还能审阅反馈、查看 Bug 报告，甚至开始主动提出修复 Bug 和发布新功能的想法，正逐渐演变成开发团队的“同事”。
• “潜在需求”驱动产品进化： AI 产品（如 Claude Code 和 Cowork）的成功很大程度上源于“潜在需求”原则。即观察用户如何以非预期的方式使用工具，然后构建更易于实现这些需求的产品。例如，人们将 Claude Code 用于非技术性任务，从而催生了 Cowork。
• AI 正在重塑非技术性工作： AI 的影响力将从工程领域扩展到产品经理、设计师、数据科学家等与计算机相关的工作。具备工具使用能力的 AI 智能体（Agents）将成为下一个变革前沿，使非技术人员也能实现自动化操作。
• 未来的关键是通用性而非专业性： Boris 强调“苦涩的教训”（The Bitter Lesson）原则，即通用模型将始终优于专用模型。构建 AI 产品应着眼于未来，押注更通用的模型，而不是过度优化当前模型或添加僵化的工作流程。
• AI 推动创新的“民主化”： 正如印刷术降低了知识获取的门槛，AI 也在做类似的事情。未来人人都能编程，这将释放巨大的创造力，但也会带来巨大的颠覆和阵痛，需要社会共同应对。
• AI 安全性的多层机制： Anthropic 采用三层 AI 安全机制：底层的“对齐”和“机械可解释性”（理解神经元工作原理），中间层的“评估”（实验室环境测试），以及顶层的“早期发布”以观察其在实际应用中的行为。
• 拥抱 AI，成为“通才”： 在 AI 时代取得成功的秘诀在于拥抱 AI 工具，成为好奇心强、跨学科的通才，能够思考宏观问题，而不仅仅局限于工程细节。
• 无限 Token 的实验价值： 鼓励给工程师提供“无限 Token”，让他们自由尝试疯狂的想法。因为在小规模实验中，AI 的使用成本相对较低，而其潜力可能带来革命性的突破。

内容简介

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 与每一位新团队成员分享的三个原则。

访谈全文

Boris 与 Claude Code 简介

Boris Cherny： 我的代码 100% 是由 Claude Code 编写的。自去年 11 月以来，我就没有亲手改过一行代码。每天我都会提交 20 到 30 个 Pull Request。所以，目前我有大约五个智能体（Agent）在同时运行。

主持人： 我们在录音了吗？好的。你怀念亲手写代码的感觉吗？

Boris Cherny： 我从未像现在这样享受编程，因为我不再需要处理那些琐碎的细枝末节。每一位工程师的生产力都因此提高了 200%。

总会有人问：“我应该学习编程吗？” 再过一两年，这就不重要了。因为编程问题在很大程度上已经被解决了。

我设想未来是一个人人都能编程的世界。任何人都可以随时构建软件。编写软件的下一个巨变是什么？Claude 正开始主动提出想法。它会审阅反馈、查看 Bug 报告、分析用于修复 Bug 和发布新功能的遥测数据。它越来越像是一个同事，甚至是一群同事。

主持人： 产品经理们听到这话恐怕要冒冷汗了。

Boris Cherny： 他们确实该紧张了。我认为到今年年底，每个人都会成为产品经理，同时也都能编程。“软件工程师”这个头衔将开始消失，取而代之的是“构建者（Builder）”。对很多人来说，这个转型过程会很痛苦。

主持人： 今天我的嘉宾是 Anthropic 的 Claude Code 负责人 Boris Cherny。很难用言语形容 Claude Code 对世界产生了多大的影响。本期节目播出时，正值 Claude Code 发布一周年。在如此短的时间里，它已经彻底改变了软件工程师的工作方式。正如我们稍后会谈到的，它现在也开始重塑科技领域许多其他职能的工作。

Claude Code 本身也是 Anthropic 去年整体增长的巨大推动力。公司刚刚为此融资了超过 35 亿美元。正如 Boris 所言，Claude Code 的增长仍在加速，仅上个月，其日活跃用户数就翻了一番。

Boris 本人也是一位非常有趣、有思想且极具深度的思考者。在这次交谈中，我们惊喜地发现，我们竟然出生在乌克兰的同一个城市，这太巧了，我之前对此一无所知。

Boris 为什么短暂离开 Anthropic 加入 Cursor（以及是什么让他回归）

主持人： Boris，非常感谢你来到节目，欢迎！我想从一个比较犀利的问题开始。大约六个月前，不知道大家是否记得，你实际上离开了 Anthropic 加入了 Cursor，但两周后又回到了 Anthropic。当时到底发生了什么？我好像从未听过真实版本的故事。

Boris Cherny： 这确实是我职业生涯中最快的一次变动。我加入 Cursor 是因为我是该产品的忠实用户。老实说，我见了他们的团队，印象非常深刻。他们非常出色，正在构建很酷的东西，而且似乎比许多人更早地看到了 AI 编码的未来。因此，打造一款好产品的想法当时让我非常兴奋。

但当我真正到了那里，我开始意识到，我真正怀念的是 Anthropic 的使命。这也是我最初被吸引到 Anthropic 的原因。在加入 Anthropic 之前，我曾在大公司工作。后来我想去一家实验室性质的机构，希望能亲自参与塑造我们正在构建的这个疯狂事物的未来。

Anthropic 最吸引我的是它的使命——一切为了安全（All about safety）。当你在 Anthropic 的走廊里随便找个人，问他们为什么在这里，答案永远是“安全”。这种使命驱动的文化与我个人的价值观高度契合。我意识到，这不仅是工作的动力，更是我快乐的源泉。

Claude Code 的一周年

我真的很怀念那种感觉。我发现，无论工作内容多么令人兴奋，无论产品多么酷炫，都无法替代使命感带来的满足。 对我来说，这是一个非常明显的信号，我很快就意识到我缺失了这一块。

主持人： 好的，让我们顺着这个话题回到 Anthropic 以及你在那里所做的工作。这期播客将在 Claude Code 发布一周年之际播出，我想花点时间反思一下你所带来的影响。最近 SemiAnalysis 发布了一份报告，我相信你肯定看过。报告显示，现在 GitHub 上有 4% 的代码提交是由 Claude Code 编写的，并预测到今年年底，这一比例将达到 GitHub 所有代码提交的五分之一。他们评论道：“就在我们眨眼之间，AI 吞噬了所有的软件开发。”

就在我们录音的今天，Spotify 发布了一个头条新闻，称他们最优秀的开发者自 12 月以来就没有写过一行代码，这都要归功于 AI。越来越多的顶尖资深工程师，包括你，都在分享不再亲自写代码的事实——代码全是 AI 生成的，甚至很多人连看都不看了。这在很大程度上要归功于你启动的这个小项目，以及你的团队在过去一年里的扩展。我很想听听你对过去一年以及这些影响的反思。

Boris Cherny： 这些数字简直令人难以置信。全球提交的代码中有 4% 来自 Claude Code，这完全超出了我的预期。正如你所说，这感觉仅仅是个开始。这些还只是公开的代码提交，如果算上私有仓库，我们认为比例会高得多。对我来说，最疯狂的不是当前的绝对数字，而是增长的速度。Claude Code 的各项指标不仅在增长，而且是在加速增长。

当我刚开始做 Claude Code 时，它只是一个小项目。在 Anthropic 内部，我们普遍认为应该发布某种编码产品。长期以来，Anthropic 构建安全通用人工智能（AGI）的心智模型一直是：模型首先要精通编程，然后要擅长使用工具，最后要能够驾驭计算机。 这大概就是我们长期以来的发展轨迹。

我最初加入的团队叫 Anthropic Labs。Mike Krieger 和 Ben Mann 实际上是第二次重启了这个团队。团队开发了一些非常棒的东西，包括 Claude Code、MCP（模型上下文协议）和桌面应用。你可以清晰地看到这个理念的萌芽：先是编程，然后是工具使用，最后是计算机操作（Computer Use）。

这对 Anthropic 至关重要，核心原因在于安全性。人工智能正变得越来越强大。在过去一年里，至少对工程师而言，AI 不仅仅是编写代码或充当对话伙伴，它实际上已经开始使用工具并在现实世界中采取行动。

Claude Code 的起源故事

通过 Computer Use（计算机操作功能），我们也开始看到这种转变发生在非技术人员身上。对于许多使用对话式 AI 的人来说，这可能是他们第一次体验到能够实际执行操作的工具。它可以访问你的 Gmail、你的 Slack，并为你处理各种事务。它在这方面表现出色，且只会越来越好。

很长一段时间以来，Anthropic 内部一直有一种想要创造某种东西的感觉，但具体形态并不明确。因此，当我加入 Anthropic 时，我花了一个月的时间进行探索性开发，构建了许多奇特的原型。大多数都没有发布，甚至离发布还很远，但这只是为了探索模型能力的边界。随后，我又花了一个月时间研究后训练（Post-training），以便从研究角度深入理解它。老实说，作为工程师，想要把工作做好，你就必须深入理解你所构建层级之下的底层逻辑。

在传统的工程工作中，如果你开发产品，你需要了解基础设施、运行时、虚拟机、编程语言等依赖项。但在从事人工智能工作时，你必须在一定程度上理解模型本身，才能胜任工作。

所以，我绕了一点路来做这件事，回来后便开始构建最终演变成 Claude Code 的原型。

关于它的第一个版本，我还保留着那个夏天录制的演示视频，当时它被称为 Claude CLI。我只是展示了它如何使用一些工具。令我感到最不可思议的是，我只是给了它一个 Bash 工具，它就能利用这个工具编写代码。当我问它“我正在听什么音乐”时，它竟然真的给出了答案。这简直太神奇了，对吧？因为我并未指示模型去使用特定工具完成任务，也没告诉它“去做任何事”。模型在获得工具后，自行想出了如何利用它来回答我的问题——实际上，我当时甚至不确定它能否回答“我正在听什么音乐”这个问题。

于是我开始了更多的原型开发。我写了一篇文章并在内部发布，结果只收到了两个赞。这基本上代表了当时大家的普遍反应。

因为在当时，人们一想到编码工具，脑海中浮现的都是 IDE（集成开发环境），以及那些相当复杂的环境配置。没人想过这东西能基于终端运行。这在当时看来是一种奇怪的设计，而且最初也并非有意为之。

但我从一开始就把它构建在终端里，原因很简单：最初几个月只有我一个人在开发，这是最省力的构建方式。对我来说，这是一个相当重要的产品教训：资源受限在初期反而是一种优势，它能帮你聚焦。

后来当我们考虑开发其他形式时，决定在一段时间内坚持使用终端。最大的原因是模型进化得太快了，我们觉得任何图形界面（GUI）都跟不上它的步伐。说实话，这也是我一直在思考的问题：“我们到底该构建什么？”在过去的一年里，Claude Code 占据了我全部的思考。深夜里我常想：模型还在不断进步，我们该怎么办？如何才能跟上？老实说，终端成了我唯一的解法。

结果证明这条路走通了。发布后，它很快在 Anthropic 内部流行起来，日活跃用户（DAU）直线上升。其实在发布前，Ben Mann 就建议我制作一张日活图表。我当时还问：“现在做是不是太早了？”他说：“不，就现在。”结果那张图表的曲线几乎立刻就拉出了一条直线。

二月份，我们将其对外发布。其实大家可能不太记得了，Claude Code 最初发布时并非一炮而红。确实有一批早期采用者立刻理解了它的价值，但实际上市场花了几个月的时间才真正理解这到底是什么。还是那句话，它太与众不同了。

回过头看，Claude Code 之所以成功，部分原因在于“潜在需求”——我们将工具带到了人们所在的地方，让现有的工作流程变得更顺畅。但因为它运行在终端里，这有点出人意料，甚至让人感到有些陌生。你必须保持开放的心态去学习使用它。

当然，现在 Claude Code 已经可以在 iOS 和 Android 的 Claude 应用、桌面应用、网站、IDE 扩展以及 Slack 和 GitHub 中使用了——它渗透到了工程师所在的每一个角落，变得更加熟悉。但这并不是它的起点。

起初，这个东西“能用”就已经是个惊喜了。随着团队壮大、产品成熟，它对用户越来越有价值。从世界各地的小型初创公司到知名大厂都在使用并反馈，这真是一次非常谦卑的经历。我们不断从用户那里学习。最令人兴奋的是，其实没人确切知道该怎么做，我们都在与用户一同摸索。 用户的反馈最能说明这一点，我已经被惊喜过无数次了。

AI 正以何种速度重塑软件开发

主持人： 当今世界的变化速度简直不可思议。你们一年前发布了这个产品，虽然那不是人们第一次用 AI 写代码，但短短一年间，整个软件工程行业已经发生了翻天覆地的变化。比如，之前到处都是关于“AI 将 100% 接管代码编写”的预测，当时大家都觉得是天方夜谭，说“你在开玩笑吗？”而现在，正如所言，这一切正在发生。这种发展和变化的速度太快了。

Boris Cherny： 是的，速度极快。回想 2025 年 5 月，在 Anthropic 举办的首届开发者大会“Code with Claude”上，我做了一个简短演讲。在问答环节，有人问我年底的预测是什么。我当时的回答是：到今年年底，你可能就不再需要 IDE 来写代码了，我们会开始看到工程师放弃这种工作方式。 我记得当时全场观众都倒吸了一口凉气。

实验精神：AI 创新的核心

这听起来是个疯狂的预测。但在 Anthropic，我们的思维方式是指数级的，这深植于我们的基因之中。我们的联合创始人中有三位是《Scaling Laws》（缩放定律）论文的前三作者。所以我们确实习惯于指数级思考。如果你观察当时 Claude 编写代码比例的指数增长曲线，只要顺着趋势线画下去，就很明显我们将在年底突破 100%——即使这在当时完全反直觉。我所做的只是顺着那条线推演。果然，到了 11 月，对我个人而言，那个时刻真的到来了，并一直持续至今。我们也看到很多客户出现了类似的情况。

主持人： 你刚才分享的探索过程——那种“只是随便玩玩，看看会发生什么”的心态，我觉得非常有趣。这在 OpenAI 的故事里也经常出现，比如 Peter 只是在尝试，然后就促成了某些突破。感觉这似乎是 AI 领域许多重大创新的核心要素：人们只是坐下来尝试各种方法，将模型推向比其他人更远的地方。

Boris Cherny： 这就是创新的本质，你无法强求。创新没有既定的路线图，你只需要给人们空间。 你需要给他们“心理安全感”，让他们知道失败是可以接受的。80% 的想法可能都不靠谱，这没关系。

当然，你也需要有一定的问责机制。如果想法行不通，就及时止损，转向下一个，而不是无底洞般地投入。

在 Claude Code 早期，我完全不知道这东西会有用。即使在 2 月份发布时，它可能只帮我写了 20% 的代码。哪怕到了 5 月份，可能也只有 30%，我当时主要还是用 Cursor 写代码。直到 11 月份才突破 100%。所以这确实花了一段时间。

Boris 的现状：100% 代码由 AI 撰写

但从最早的时候开始，我就觉得我抓住了某种诀窍。几乎每个晚上和周末我都在捣鼓它——幸运的是，我的妻子非常支持我。我隐约感觉抓住了某种东西，尽管当时并不清晰。有时候，你发现了一根线头，就必须顺着它拽下去。

主持人： 也就是说，你现在 100% 的代码都是由 Claude Code 编写的，对吗？这就是你目前的编码状态？

Boris Cherny： 是的，我 100% 的代码都由 Claude Code 编写。我是一个相当多产的程序员，无论是在 Instagram 工作时，还是现在在 Anthropic，我都是产出最高的工程师之一。

主持人： 哇，即使作为负责人也如此？

Boris Cherny： 是的，我仍然写大量代码。我每天大概会提交 10、20 甚至 30 个 Pull Request（PR）。每天如此。是的，这很疯狂。所有代码 100% 由 Claude Code 编写，从 11 月份之后，我就没有手动编辑过一行代码。

下一个前沿

当然，我确实会看代码。我不认为我们已经到了可以完全放手不管的阶段，尤其是在很多人运行程序的情况下，你必须确保它的正确性和安全性。在 Anthropic，Claude 会对所有代码进行自动审查（Code Review），这覆盖了 100% 的 Pull Requests。之后仍然有一层人工审查。我们需要这些检查点，除非是那种纯粹的原型代码，不会在生产环境中运行。

主持人： 那么下一个前沿是什么？现在你 100% 的代码都由 AI 编写，这显然是软件工程的未来。这曾经是一个疯狂的里程碑，现在感觉就像“当然了，世界本来就该这样”。那么，软件编写的下一个重大转变是什么？是你的团队已经在进行的，还是你认为我们将朝着哪个方向发展？

Boris Cherny： 我认为现在正在发生的一件事是，Claude 已经开始主动提出想法了。Claude 会查看反馈、Bug 报告、遥测数据等，然后开始提出修复 Bug 和发布新功能的建议。它开始变得有点像一个同事了。

第二件事是，我们开始拓展到纯编码之外的领域。我认为目前可以肯定地说，编码在很大程度上已经是一个被解决的问题——至少对我所做的那类编程来说，Claude 完全可以胜任。所以现在我们开始思考：“接下来是什么？还有什么？”有很多工作是与编码相关的。

我认为这种趋势即将到来，但也包括一些通用的任务。比如，我现在每天都使用 Claude 处理各种与编码无关的事务，并让它自动完成。例如，前几天我得支付一张停车罚单，我直接让 Claude 去付了。我团队的所有项目管理工作也都由 Claude 完成，它可以在电子表格之间同步数据，以及在 Slack、电子邮件等地方与人沟通。我认为下一个前沿不再是编码本身。因为在我看来，编码问题基本上已经解决了。未来几个月，整个行业将见证：无论针对何种代码库或技术栈，编码工作都将变得越来越容易被解决。

主持人： 利用 AI 辅助构思工作内容的想法非常有趣。许多听众是产品经理，可能正为此焦虑。你是怎么使用 Claude 的？仅仅是对话吗？还是有什么巧妙的方法利用它来构思构建内容？

Boris Cherny： 说实话，最简单的办法就是打开 Claude Code，让它读取某个 Slack 讨论串（Thread）。比如我们有一个专门收集 Claude Code 内部反馈的频道。从最初发布甚至早在 2024 年内部测试时起，那里就积累了海量的反馈。这可是无价之宝。

早期每当有人反馈，我会立刻修复，哪怕是一分钟、五分钟内解决。这种极致的快速反馈循环能极大地鼓励人们提供更多意见。

这至关重要，因为它让用户感到被重视。通常如果你反馈后石沉大海，就不会再有下文了。但如果人们觉得自己的声音被听到了，他们就会愿意贡献力量，帮助改进产品。

现在我依然遵循这个原则，但大部分工作都由 Claude 代劳了。我只需让它指向那个频道，它就会说：“这里有几件事我能处理，已经提交了几个 PR（拉取请求），要看看吗？”我就说：“好。”

主持人： 你有没有注意到 AI 在编码能力上的显著进步？这简直是“圣杯”。目前软件构建的基础设施问题已经解决，代码审查（Code Review）成了新的瓶颈——到处都是待处理的 PR，谁来审查呢？现在的核心问题变成了人类需要思考构建什么以及如何定优先级。正如你所说，Claude Code 正是在这方面开始发挥作用。它的性能提升轨迹如何？比如像新版本在这些方面的表现？

Boris Cherny： 是的，进步非常大。部分原因是我们进行了针对编码的特定训练。显然，它是世界上最好的编码模型，而且还在不断进化，目前的版本表现就非常出色。

有趣的是，许多非编码方面的训练也能很好地迁移。这种“迁移效应”意味着你教会模型做 X，它在 Y 方面也会做得更好。进步幅度简直不可思议。

比如在 Anthropic，引入 Claude Code 的这一年里，我们的工程团队规模大概扩大了四倍。但以 PR 数量衡量的**每位工程师的生产力却提高了 200%**。对于任何专注于开发者生产力领域的人来说，这个数字都堪称惊人。

我之前在 Meta 工作时负责全公司的代码质量，涉及 Facebook、Instagram、WhatsApp 等庞大的代码库。我们曾投入数百名工程师，耗时一年，往往只能将生产力提升几个百分点。而现在看到这种成倍的增长，简直令人难以置信。

快速创新的双刃剑

主持人： 同样令人难以置信的是，这一切已经变得多么常态化。AI 对软件开发、产品构建乃至整个科技界带来的前所未有的变化，我们很容易就习以为常。但意识到这一切是多么“疯狂”，这一点至关重要。

Boris Cherny： 我也需要偶尔提醒自己。模型更新太快也有弊端，导致我也时常固守旧的思维方式。我发现团队里的新人或应届毕业生，他们看待事物的方式甚至比我更具“AGI（通用人工智能）导向”。

比如几个月前，我遇到了一个棘手的内存泄漏问题——Claude Code 的内存占用不断飙升直至崩溃。这是一个经典的工程问题，大多数工程师都调试过无数次。传统做法是获取内存快照（Heap Snapshot），放入调试器，配合特定工具分析。

正当我埋头研究堆栈跟踪（Traces）时，团队里一位新工程师直接问 Claude：“嘿，好像有内存泄漏，你能找出原因吗？”Claude Code 随后执行了与我完全相同的任务：获取快照，编写即时程序进行分析。它找到问题并提交修复 PR 的速度，比我还在手动排查时快得多。

Claude Code 团队的核心原则

这件事提醒我们要跟上时代，不要停留在过去。模型在不断进化，不再是以前的版本了，新模型需要我们彻底转变思维方式。

主持人： 我听说你们有一些具体的团队指导原则。其中一条似乎是：“有什么比自己动手更棒的吗？那就是让 Claude 来做。”这听起来和你刚才说的内存泄漏案例如出一辙——你几乎忘了这个原则，即“先看看 Claude 能不能搞定”。

Boris Cherny： 还有一点很有趣：当你让团队处于稍微“资源紧缺”的状态时，人们就被迫去创新。我们经常看到，哪怕项目只派一名工程师，他们也能快速交付，因为这是发自内心的驱动力——如果你有个好主意，你会想方设法把它实现，这不需要强迫。

所以，如果你拥有 Claude，就可以用它自动化大量工作。因此我们的原则之一就是：保持适度的“资源紧缺”。

另一个原则是鼓励快速行动。如果今天能做完，就绝不拖到明天。这一点在早期只有我一个人时至关重要，因为速度是我们唯一的优势。如今，要想快，最好的办法就是让 Claude 做更多事。

主持人： “资源紧缺”这个观点很有意思。通常人们认为 AI 会让你不再需要那么多工程师。但你的意思似乎是：与其说 AI 让你更快，不如说投入更少的人力，反而能迫使你从 AI 工具中挖掘更多价值。

Boris Cherny： 对，优秀的工程师只要获得授权，总能找到解决办法。我常给 CTO 们的建议是：起步阶段不要试图优化成本，尽可能给工程师提供无限的 Token。

在 Anthropic，我们每个人都有海量的 Token 额度。我们开始看到这在一些公司已成为一种福利——入职即享“无限 Token”。

为什么要给工程师“无限 Token”

我强烈建议这样做，因为这能解放人们去尝试那些看似疯狂的想法。如果想法可行，再考虑如何规模化和优化成本（比如改用 Haiku 或 Sonnet 模型）。但在初期，必须投入大量 Token，给工程师验证想法的自由。

主持人： 也就是说，对 Token 成本要宽容。最具创新性的想法往往来自于有人将其推向极致，探索边界。

Boris Cherny： 没错。实际上，小规模实验的 Token 成本相对于工程师薪资或运营成本来说微不足道。只有当项目规模化后，成本才会变得可观，那时才是优化的时机。不要过早优化。

主持人： 你提到过 Token 成本可能比薪水还高的情况？你认为这会成为一种趋势吗？

当 Token 成本超过工程师薪水

Boris Cherny： 在 Anthropic，我们已经看到有个别工程师每月的 Token 花费高达数十万美元。这种趋势确实开始出现了。

主持人： 你怀念写代码吗？作为一名软件工程师却不再亲自编码，你会感到失落吗？

Boris Cherny： 有趣的是，我学习工程学的过程非常注重实践。我学它的初衷就是为了能亲手构建事物。我是一名自学成才的工程师——我在学校主修经济学，并非计算机科学。但我很早就开始自学工程，中学时就开始编程了。

从一开始，编程对我就非常实用。我学会写代码甚至是为了在数学考试中作弊。那是我做的第一件事：在我们的图形计算器（TI-83 Plus）上编写程序。没错，我把答案编进了程序里。

等到第二年的数学考试，题目太难了，我也无法预知题目把答案存进去。于是我不得不写一个小型的通用解算器来处理代数题。后来我发现可以用数据线把程序分享给班上其他人，结果全班都拿了 A。当然，后来我们被抓了，老师严令禁止。但从那时起，我就意识到：编程是构建事物的手段，而非目的本身。

后来，我曾一度沉迷于“编程之美”。我写了一本关于 TypeScript 的书，还组织了当时世界上最大的 TypeScript 聚会，纯粹是因为我爱上了这门语言。我也深入研究了函数式编程。

我认为很多程序员容易因此分心。我也曾觉得编程、特别是函数式编程和类型系统，具有一种内在美。就像解决复杂数学难题时那种特殊的兴奋感，当你平衡好类型定义，或者写出优雅的代码时，也会有同样的感受。

但那并不是最终目的。对我而言，代码终究是工具，是实现目标的手段。

当然，并非每个人都这么想。例如我们团队的工程师 Lena，她周末还会手写 C# 代码，纯粹因为享受其中的乐趣。每个人都不同。我认为，即使领域在变，总有一方天地留给人们去享受编程艺术，去打磨手工艺。

主持人： 你是否担心作为工程师的技能会退化？还是认为这只是顺应了发展的必然？

Boris Cherny： 我认为这是发展的必然，我个人并不担心。对我来说，编程是一个连续演进的过程。

回看历史，现代软件编写方式（运行在虚拟机上）大约始于 20 世纪 60 年代，已有 60 年历史。在此之前是打孔卡，再之前是拨动开关，更早是纯硬件。而在那之前，所谓的“计算”就是一屋子人拿着纸笔进行数学运算。

编程一直在变。虽然理解底层的原理能让你成为更好的工程师，这在未来一两年内可能依然成立，但我认为很快它就会变得不再重要。它将像今天的汇编代码一样，隐匿在程序员的视野之外。

情感上，我习惯了不断学习新事物。作为程序员，面对新框架、新语言是家常便饭。但也并非所有人都能适应。有些人可能会感到强烈的失落、怀旧，甚至是对技能退化的焦虑。

主持人： 不知道你是否看到埃隆·马斯克（Elon Musk）的观点：为什么 AI 不能直接生成二进制代码？归根结底，如果 AI 能做到，中间这些编程抽象层还有什么存在的意义？

Boris Cherny： 是的，这是个好问题。理论上，它完全可以做到。

AI 影响如同印刷术革命

主持人： 我常听到人们问：“我应该学编程吗？学校里还应该教编程吗？”听你的意思，似乎一两年后，这就变得不那么必要了？

Boris Cherny： 我的看法是：今天使用代码或 AI 智能体（Agent）的人，仍需理解底层原理。但一两年后，这确实不再重要。

我们需要将此事置于历史背景下考量。最贴切的类比，莫过于印刷术。

15 世纪中叶的欧洲，识字率极低，仅约 1%。抄写员垄断了读写工作，受雇于往往不识字的权贵。古腾堡印刷术问世后的 50 年里，印刷品数量超过了此前一千年的总和，而成本下降了约 100 倍。

识字率的提升需要时间，因为学习读写很难，需要教育体系和闲暇时间，不能整天被农活捆绑。但在随后的 200 年里，全球识字率最终攀升至约 70%。

我们可能正在经历类似的转变。有一个关于 15 世纪抄写员的历史轶事很有趣：他对印刷术感到兴奋，因为他其实讨厌枯燥的抄写工作。他真正热爱的是绘制插图和书籍装帧。印刷术让他得以从繁琐中解脱，专注于更具艺术感的工艺环节。

作为工程师，我感同身受。我不再需要处理繁琐的编码任务——比如管理 Git 和各种工具配置，那些细节耗时且并不令人愉悦。真正的乐趣在于构想我们要构建什么。 与用户互动、设计大型系统、思考未来架构、与团队协作——这才是现在我可以投入更多精力的地方。

主持人： 令人惊叹的是，您构建的工具让非技术人员也能做到这一点。我之前做些小项目，遇到困难只要说“帮我解决这个问题”，AI 就能搞定。回想我早年做工程师的那 10 年，大量时间花在处理库和依赖项上，遇到问题只能去 Stack Overflow 翻找。而现在，AI 直接给出步骤“1、2、3、4”，问题就解决了。

AI 将首先颠覆哪些角色？

Boris Cherny： 没错。今天我还和一位工程师聊天，他花一个月用 Go 语言写了个运行良好的服务。但他告诉我：“其实我还是不太懂 Go。” 这种情况会越来越多见。只要你能确认它运行正确且高效，就不再需要深究每一处实现细节。

主持人： 软件工程师的工作已经发生了翻天覆地的变化。您认为在技术领域（如产品经理、设计师）甚至非技术领域，下一个最受 AI 冲击的角色会是什么？

Boris Cherny： 我认为工程领域的相邻岗位（如产品经理、设计、数据科学）将首当其冲。实际上，这种影响将扩展到几乎任何依赖电脑完成的工作，因为模型能力正日益增强。

协作型产品只是第一步。它将 AI 带给了从未接触过它的人群。回想一年前，工程界还没人真正理解“智能体”（Agent），但现在，这已成为我们的工作常态。

观察现在的非技术或半技术工作，人们主要还在使用对话式 AI（聊天机器人），尚未真正触及“智能体”。虽然“智能体”这个词现在被滥用，但它有具体的技术含义：一种能够使用工具的大语言模型（LLM）。 它不只是陪聊，而是能实际行动并与系统交互——操作 Google Docs、发送邮件、在电脑上运行命令。凡是以此类方式使用电脑工具的工作，都将是下一个被改变的领域。

这既是社会问题，也是行业问题。这也是我在 Anthropic 从事这项工作感到紧迫的原因。我们非常严肃地对待此事，聘请了经济学家、政策专家和社会影响专家进行深入探讨。社会需要弄清楚如何应对，因为这不该仅由我们一家公司来决定。

主持人： 您提到了就业问题。有个概念叫“杰文斯悖论”（Jevons paradox），意指效率提高反而可能增加对资源（或人力）的需求。在 AI 深度介入工程领域的当下，您的团队招聘情况如何？

Boris Cherny： 实际上，我们的 Claude Code 团队正在积极招聘。若感兴趣，欢迎查看 Anthropic 的招聘页面。

就个人而言，我从未像今天这样享受编程，因为我从琐事中解脱了。很多客户也有同感，他们喜欢 Claude Code，因为它让编码重新变得快乐。但很难预测事情最终会如何演变，所以我倾向于借鉴历史。印刷机的出现是一个绝佳的类比：这项技术曾经只掌握在少数人手中（比如读写能力），后来变得人人触手可及。这本质上是一种民主化。若非如此，文艺复兴绝无可能发生——毕竟，文艺复兴的核心在于知识的传播和思想的交流。当时没有电话，也没有互联网，全靠书面记录。

所以，关键在于“这会通向何方”。我对此持乐观态度，甚至感到无比兴奋。如果当年没有发明印刷机，我们今天就不可能坐在这里交谈，麦克风不会存在，周围的一切都不会存在。没有这种技术，根本无法协调如此大规模的人类协作。

我设想几年后的世界，人人皆可编程。这将释放怎样的潜能？任何人都能随时构建软件。正如 15 世纪的人无法想象我们现在的生活，我们现在也难以预见那时的图景。

在 AI 时代取得成功的秘诀

但我也认为，过渡期将充满颠覆，甚至让许多人感到痛苦。再次强调，作为一个社会，我们必须展开对话，共同寻找出路。

主持人： 既然我们即将步入这个疯狂的动荡期，对于那些希望取得成功的人，你有什么建议？是多玩玩 AI 工具，精通最新技术吗？还有什么能帮助人们保持领先地位？

Boris Cherny： 对，最基本的就是去尝试、去了解这些工具，不要害怕，直接上手探索它们最前沿的应用。

其次，尽量让自己成为一名通才。 在学校里，很多计算机专业的学生只学编程，忽略了其他领域，比如系统架构。但我身边最高效的工程师、产品经理，都具备跨学科能力。以 Claude Code 团队为例，我们全员都会写代码——产品经理、工程经理、设计师、财务人员，甚至数据科学家，每个人都会写代码。

再看具体的工程师，最出色的人往往也是多面手：既懂产品又懂基础设施的混合型工程师；拥有出色设计感的工程产品经理；或者是对业务有深刻理解，并能以此决定技术方向的工程师；又或者是热爱与用户交流，能真正理解用户需求以确定下一步方向的工程师。

所以我认为，未来几年获益最大的不仅仅是那些精通 AI 工具的原生代，更是那些充满好奇心、能够跨越学科边界的通才。他们不仅思考工程问题，更能着眼于全局，解决更宏观的难题。

主持人： 你认为工程、设计、产品管理这三个独立学科的划分仍然有效吗？尽管大家现在都在写代码、贡献想法，你觉得这些角色会一直存在吗？

Boris Cherny： 长期来看很难说，但短期内它们会持续存在。不过我们开始看到角色间出现了 50% 的重叠，很多人实际上在做同样的事情。虽然有些人仍有专长——比如我写代码多一些，而其他的 PM 则更多负责协调、规划或预测——但界限正在模糊。

我认为未来，也许到年底，我们会看到这些界限变得更加模糊。“软件工程师”这个头衔可能会逐渐消失，取而代之的是“构建者”（Builder）。也许每个人都会成为既写代码又懂产品的产品经理。

投票：AI 让哪个角色的工作更有趣了？

主持人： 你提到现在更喜欢写代码了。实际上我在 Twitter 上针对不同角色做了一个关于“使用 AI 工具后是否更享受工作”的调查。

结果很有趣：70% 的工程师和产品经理（PM）表示更享受工作，只有约 10% 表示不享受。然而，设计师中只有 55% 表示更享受，却有 20% 表示更不享受。我觉得这个差异非常有意思。

Boris Cherny： 这太有趣了。我很想和这些人聊聊，深入了解背后的原因。你有后续跟进吗？

主持人： 有几个人回复了，我们正在进行后续采访，链接会放在节目笔记里。但这确实受很多因素影响。那些表示不享受的设计师并没有分享太多具体原因，所以我很好奇发生了什么。

Boris Cherny： 在 Anthropic，我有不同的体会。我们的团队技术背景很强，招聘时就很看重这一点。即使是非技术岗位，也要经历很多技术面试。

我们的设计师也会写代码。据我观察，他们很喜欢这一点，因为现在不必事事去麻烦工程师，自己就能动手写代码解决问题。甚至一些以前不写代码的设计师也开始尝试了。这对他们来说很棒，因为赋予了他们独立解决问题的能力。

但我很想听听更多人的经历，因为我相信不同公司的情况肯定不尽相同。

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

主持人： 没错。如果你正在听这个节目，并且发现工作变得更无趣了，请留言告诉我们。因为大多数反馈都表明工作变得更有趣了（70% 的 PM 和工程师），如果你不在此列，也许哪里出了问题。

Boris Cherny： 是的。我们也观察到人们使用的工具不同。例如，我们的设计师更多使用 Claude 桌面应用程序来写代码。

你只需下载桌面应用，里面有一个就在“协作”旁边的“代码”标签页。它本质上拥有 Claude Code 的全部功能，是一个强大的代理。这样你就不需要打开一堆终端窗口，操作更符合非工程师的习惯。

最重要的是，你可以同时运行任意数量的 Claude 会话，我们称之为“多 Claude”（Multi-Claude）。

这其实是关于如何把产品带到用户面前。你不想强迫用户改变工作流或付出额外的学习成本。如果能让他们现有的操作变得更容易，那就是一个更好的产品。这触及了产品开发中最核心的原则——潜在需求原则（Latent Demand）。

主持人： 能详细讲讲吗？因为我正想让你解释这个原则是什么，以及当你解锁这种潜在需求时会发生什么。

Boris Cherny：潜在需求是指：如果用户以一种非预期的方式“破解”或使用你的产品来达成某种目的，这实际上为你指明了产品下一步的演进方向。 Facebook Marketplace 的创始经理 Fiona 经常提到这个例子。

Facebook Marketplace 的诞生源于 2016 年左右的一个观察：Facebook 群组里竟然有 40% 的帖子都是买卖信息。这太惊人了。用户正在“滥用”群组功能来进行交易。这不是安全意义上的滥用，而是说并没有人为此设计这项功能，但用户自己找到了办法，因为它太有用了。

显然，如果你构建一个更好的产品来专门服务买卖需求，用户会喜欢的。Marketplace 的成功是显而易见的。第一步是买卖群组，第二步就是 Marketplace。

Facebook Dating 的诞生也基于类似的洞察。如果你查看 Facebook 上的个人资料浏览量，会发现 60% 的浏览来自非好友关系的异性。这就像一种传统的约会模式，人们只是在互相“窥探”。所以，构建一个专门的产品可能会奏效。

我认为潜在需求的概念非常强大。例如，Cowork 的诞生也源于此。我们注意到，过去半年里，很多使用 Claude Code 的人并不是用它来写代码。有人用它在 Twitter 上种番茄，有人用来分析基因组，有人用来从损坏的硬盘中恢复婚礼照片，还有人用来分析 MRI 图像。存在各种各样完全不相关的用例。这表明，人们即使费劲使用终端也要做这些事。也许我们应该为他们专门构建一个产品。我们其实很早就留意到了这一点。大概在去年五月，我走进办公室，看到我们的数据科学家 Brendan 的电脑上开着 Claude Code。他当时只是打开了一个终端。我很惊讶，问他：“Brendan，你在干嘛？你竟然学会了用终端？要知道，这是非常工程化的工具，因为太底层、太繁琐，甚至很多工程师都不爱用。”

但他不仅学会了，还下载了 Node.js 和 Claude Code，直接在终端里进行 SQL 分析。这太疯狂了。结果第二周，所有的数据科学家都在做同样的事情。

当你看到人们以这种“破解”产品的方式，用非预期的方法来完成对他们有益的工作时，这强烈暗示你应该去构建这样的产品——人们会喜欢它，因为它有明确的用途。我认为“潜在需求”（latent demand）现在有了第二个有趣的维度。

传统的理解是：观察人在做什么，让他们的工作变简单，为他们赋能。而我近六个月体会到的现代理解略有不同：它是关于观察“模型”试图做什么，并让这件事变得更容易。

当我们开始构建 Claude Code 时，人们设计 LLM（大语言模型）应用的主流方式是把模型“关在盒子里”。他们会说：“我想构建这个应用，让它完成这个任务。模型，你只负责其中一个组件，通过这些 API 和工具进行交互。”

对于 Claude Code，我们反其道而行之。我们主张：产品即模型。我们要把它展现出来，只在周围搭建最少的脚手架，给它最精简的工具集，让它能够做它需要做的事。它可以自主决定运行哪些工具以及执行顺序。

Cowork 如何在短短 10 天内建成

这很大程度上是基于“模型想要做什么”这一潜在需求。在研究中，我们称之为“分布内”（on distribution）。你要观察模型的行为。用产品术语来说，这和“潜在需求”是同一个概念，只是应用对象变成了模型。

主持人： 你提到了 Cowork。记得最初发布时，你说团队仅用了 10 天就完成了，这太不可思议了。发布后很快就有数百万人使用。像这样的产品能在 10 天内建成，除了它是用 Claude Code 构建的之外，背后还有什么故事吗？

Boris Cherny： 是的，这很有趣。Claude Code 发布初期并没有立刻爆火。它的热度是随时间积累的，经历了几个转折点。比如 Claude 3 Opus 的发布让它真正起飞了。到了十一月，增长曲线变得非常陡峭。但在最初几个月，很多人并不知道怎么用它，也不知道它的用途，当时模型也不够完美。

相比之下，Cowork 一发布就火了，热度远超早期的 Claude Code。这很大程度上要归功于 Felix、Sam、Jenny 以及整个强大的团队。Cowork 的诞生同样源于那种潜在需求——我们看到人们用 Claude Code 做非技术性的事情，于是试图搞清楚该怎么应对。

团队探索了几个月，尝试了各种方案。最后有人提议：“如果我们把 Claude Code 放进桌面应用里会怎样？” 这招奏效了。于是他们在 10 天内，完全使用 Claude Code 构建出了 Cowork。

Cowork 其实拥有一套非常复杂的安全系统，本质上是为了确保模型行为正确、不偏离轨道的保护措施。例如，我们内置了一个完整的虚拟机，所有这些代码都是 Claude Code 编写的。我们要考虑的是：“如何让它对非工程师用户来说既安全又自主？” 这个完全用 Claude Code 实现的过程，大约只花了 10 天。

Anthropic 的三层 AI 安全机制

我们发布得很早，它在细节上还很粗糙。但这正是我们的学习方式——无论是产品还是安全层面，我们必须比预期更早发布，这样才能获得反馈，与用户交流，真正了解人们想要什么。这将决定产品未来的演进方向。

主持人： 这非常有趣且独特。大家常说“尽早发布，从用户反馈中迭代”，但鉴于很难预知 AI 的能力以及人们会如何使用它，这反而成了尽早发布的独特理由。正如你所说，这有助于发现那些我们尚不了解的“潜在需求”，所以尽管推出去吧。

Boris Cherny： 对，人们到底会用它做什么？对于 Anthropic 这样的安全实验室来说，另一个维度就是安全。研究模型安全有很多不同方式，大致分为三层：

最底层是“对齐”（alignment）和“机械可解释性”（mechanistic interpretability）。 我们在训练模型时要确保其安全。现在我们有相当先进的技术来追踪和理解神经元内部的活动。例如，如果有一个与“欺骗”相关的神经元，我们能监控它的激活情况。这就是最底层的对齐和机械可解释性。

第二层是“评估”（evals）。 这本质上是实验室环境，模型就像在培养皿中一样。我们将它置于合成场景中，测试它是否合规、安全。

第三层则是观察模型在现实世界中的行为。 随着模型日益复杂，这一点至关重要，因为模型可能在前两层表现良好，但在第三层翻车。我们很早就发布了 Claude Code，正是为了研究安全性。我们在内部使用了大概四五个月才对外发布，因为当时它是第一批大型智能体（Agent），甚至是第一个被广泛使用的编码智能体，我们不确定它是否安全。我们在内部做了大量研究，直到觉得可以了才发布。即使那样，我们在对齐和安全方面学到的经验，也都反哺回了模型和产品中。

Cowork 的情况也类似。模型处于新环境中，作为代理执行非工程任务。它在内部测试和评估中表现良好，但在现实世界是否安全？这就是我们尽早发布并称之为“研究预览”（research preview）的原因。这是确保持续改进、让模型长期符合要求并做正确之事的唯一途径。

主持人： 这是一个竞争激烈、节奏极快的疯狂领域。同时，人们又担心某种“超级智能”会失控造成破坏。找到平衡点一定极难。

据我理解，你们通过这三个层面来处理安全问题：观察模型的思考方式、通过评估测试模型是否作恶、以及尽早发布。关于第一个层面（机械可解释性），我想听听更多细节。你们似乎拥有能窥探模型内部、观察其思考过程和走向的可观测性工具，这太不可思议了。

Boris Cherny： 是的，你应该邀请 Chris Olah 上你的播客，他是该领域的行业专家，开创了“机械可解释性”领域。核心思想很简单：就像人类大脑是一堆相互连接的神经元一样，我们可以从机械层面研究大脑，了解神经元的功能。

令人惊讶的是，这在很大程度上也适用于模型。虽然模型神经元与生物神经元不同，但表现有很多相似之处。我们因此学到了很多：概念是如何编码的、模型如何规划、如何进行超前思考。以前我们不确定模型是否只是在预测下一个词，现在有强有力的证据表明，它在做更深层的事情。

随着模型变大，结构变得相当复杂。不再是一个神经元对应一个概念，而是一个神经元可能对应十几个概念，如果它与其他神经元一起被激活，这被称为“叠加”（superposition）。这也是我们一直在探索的领域。

Anthropic 存在的理由，就是以一种对世界安全且有益的方式推动这一领域的发展。这也是大家聚集在这里的原因。因此，我们将许多工作开源并公开发布，希望能激励其他实验室同样采取安全的方式。

AI 代理不工作时的焦虑感

以 Claude Code 为例，我们在发布时开源了一个沙盒。这是一种安全边界，确保代理无法访问你系统上的所有内容。这个沙盒适用于任何代理，不仅仅是 Claude Code。这和之前提到的“竞赛”原理一样：我们希望让其他人也能更容易地实现安全。这就是我们推动行业正向发展的杠杆。

主持人： 太棒了。我绝对想花更多时间探讨这点，也会跟进这个建议。我在这个领域观察到，工程师、产品经理以及其他与 Agent（智能体）协作的人，当 Agent 停止工作时会产生焦虑感。感觉就像是：“天哪，这里有个问题需要我解决”或者“它卡住了”，又或者觉得“我正在丧失生产力”。感觉像是必须立刻醒来让它重新运行。你有这种感觉吗？你的团队有吗？你认为这是一个值得关注和思考的问题吗？

Boris Cherny： 我总是有一堆 Agent 在运行。目前我有五个在跑。任何时候，我醒来都会启动一批。

我醒来第一件事就是想：“我得检查一下这东西。”所以我打开手机上的 Claude iOS 应用，查看代码标签页和 Agent 状态等。因为昨天我写了一些代码，当时心想：“等一下，我这样做对吗？”有点犹豫，但结果确实是对的。现在做这些太容易了。所以我也说不好，也许确实有一点点焦虑。

我个人并没有强烈感受到，因为我的 Agent 始终在运行。而且我不再局限于终端了。现在大约三分之一的代码在终端里完成，三分之一使用桌面应用，还有三分之一通过 iOS 应用完成。这太令人惊讶了，因为我完全没想到这会成为我的编码方式，即使是展望 2026 年时也没想到。

主持人： 有意思的是你仍然称之为“编码”，尽管你只是在与 Claude Code 对话，让它为你写代码。有趣的是，这就是现在所谓的“编码”——编码现在的定义是描述你想要什么，而不是亲手编写代码。

Boris Cherny： 我很好奇，那些过去使用打孔卡或其他方式编码的人，如果看到现在的软件开发方式，会怎么说。我记得读过一些资料，也许是很早期的 ACM 杂志，有人说：“不，这不一样，这不算真正的编码。”那时候他们称之为“编程”（Programming）。我认为“编码”（Coding）是一个相对较新的词。

这让我想起一件事。我出生在乌克兰，来自苏联。我的祖父实际上是苏联最早的程序员之一，他就是用打孔卡编程的。我妈妈抚养我时讲过这些故事：她小时候，祖父会把厚厚一叠打孔卡带回家。对她来说，那是用来画蜡笔画的玩具，是童年的回忆；但对祖父来说，那就是他的编程生涯。

鲍里斯的乌克兰根源

他实际上从未见过软件行业的这种转变。但不知何时，转变确实发生了。我想，当时可能有一代老程序员不太看得起新软件，他们会说：“这不算真正的编码。”但我认为，这个领域一直都在经历这样的演变。

主持人： 你可能不知道，其实我也出生在乌克兰。

Boris Cherny： 真的吗？什么时候？我来自敖德萨。

主持人： 哦，我也是。

Boris Cherny： 是的，太疯狂了。哇，难以置信。多么巧合。也许在某种程度上有关联。你的家人是什么时候离开的？

Boris Cherny： 我们是 95 年来的。

主持人： 好的。我们是 88 年离开的，早一点。如果不离开，生活会有多大不同啊。

Boris Cherny： 是的，我每天都觉得非常幸运能在这里长大。

主持人： 是的，我的家人只要遇到点小事，就会说：“幸好去了美国。”我就想说：“好了，别再说了。”但一旦你开始真正思考另一种生活的可能性……

Boris Cherny： 是的，确实如此。我们也做同样的事，不过那是伏特加。

构建 AI 产品的建议

主持人： 绝对还是伏特加。天哪。好的，让我再问你几个问题。你分享了一些关于如何最大化利用 AI、如何构建 AI 以及基于 AI 构建优秀产品的精彩技巧。你提到的一点是，让团队拥有无限量的 Token，让他们去实验。还有一个普遍建议是：朝着模型发展的方向构建，而不是基于今天的模型构建。 对于那些试图构建 AI 产品的人，你还有什么其他建议吗？

Boris Cherny： 我可以分享一些其他观点。首先，不要试图将模型“框”死。很多人在使用模型时，本能地试图让它表现得非常具体，把它视为“更大系统中的一个组件”。比如，人们会添加非常严格的工作流，要求模型必须按顺序完成第一步、第二步、第三步，并用一个精密的编排器来执行。

但实际上，如果你只给模型提供工具，设定一个目标，然后让它自己去解决，几乎总是能获得更好的结果。一年前，你确实需要很多这种“脚手架”（Scaffolding），但现在不太需要了。

这个原则有点像“不要问模型能为你做什么，而要思考如何为模型提供完成任务的工具”。不要过度策划，不要试图把它框住，也不要一开始就塞给它大量上下文。给它工具，让它自己获取所需的上下文，你会得到更好的结果。

第二点，也许是这个原则的更普遍版本，就是“苦涩的教训”（The Bitter Lesson）。Claude Code 团队非常推崇理查德·萨顿（Richard Sutton）大约十年前写的那篇博文。

他的核心观点是：更通用的模型终将胜过更具体的模型。 这有很多推论，对我来说最重要的一点是：永远押注于更通用的模型。从长远来看，不要试图用小型模型完成任务，不要试图进行微调（Fine-tuning）。

虽然有些特定应用有理由这样做，但如果你有灵活性，一定要押注通用模型。那些在模型周围添加“脚手架”的工作流，通常只能带来 10% 到 20% 的性能提升，而这些提升往往会被下一代模型的原生能力瞬间抹平。所以，最好的策略往往是等待下一代模型。

这或许是最终的原则，也是 Claude Code 回过头看做对的一件事：从一开始，我们就致力于为六个月后的模型而构建，而不是为今天的模型而构建。

在产品早期，它写的代码很少，因为我当时不信任它。那是 Sonnet 3.5 或类似版本的时期，模型写代码的能力还处于早期阶段。那时它确实能帮忙做些 Git 操作或自动化任务，但并没有真正承担大量编码工作。

Claude Code 的赌注是：总有一天模型会足够强大，可以直接编写大量代码。 当我们第一次看到 Opus 4 和 Sonnet 4 时，转折点出现了。Opus 4 是我们去年五月发布的第一款 ASL3 级别模型。从那时起，大家开始真正使用 Claude Code，我们的增长也呈指数级爆发，并保持至今。

这也是我给很多创业公司的建议，尽管这会让人感到不舒服，因为你的产品市场契合度（PMF）在最初六个月可能很差。但是，如果你为六个月后的模型构建产品，当那个模型问世时，你将立刻占据先机，产品会迅速起飞。

主持人： 当你说“为六个月后的模型构建”时，人们应该假设会发生什么？是它会普遍变得更强？还是说针对目前的短板，假设它未来会解决？关于这一点有什么具体建议吗？

Boris Cherny： 这是一个好问题。显然，在 AI 实验室内部，我们能看到它具体在哪些方面变强，这有点像“作弊”。但也有些通用的预测。

第一个预测是：模型将越来越擅长使用工具和操作计算机。

另一个预测是：它将越来越擅长长时间运行。 这方面有很多研究，但我基于自己的经验也能看出来。

一年前使用 Sonnet 3.5 时，它可能只能运行 15 到 30 秒就开始失控，你必须时刻指导它完成复杂任务。

但如今，使用 Opus 4.6，它平均可以无人值守（Unattended）运行 10 到 30 分钟。我可以开启一个任务，然后去做别的事。正如我所说，我总是有很多个任务在并行运行。

使用 Claude Code 的专业技巧

它们甚至可以运行数小时、数天，有些案例中甚至运行了数周。我认为随着时间推移，模型长时间独立运行将成为常态，你不再需要盯着它们了。

主持人： 我们刚才讨论了构建 AI 产品的技巧。那么，对于 Claude Code 的初学者，或者想要进阶的用户，你有什么建议吗？能分享几个专业技巧吗？

Boris Cherny： 首先我要明确一点，使用 Claude Code 并没有所谓的“唯一正确方式”。我虽然可以分享一些技巧，但这毕竟是一个开发工具。开发者千差万别，每个人都有不同的偏好和环境，所以使用方式也是多种多样的。你必须找到适合自己的路。幸运的是，你可以直接向 Claude Code 提问。它可以提供建议，甚至帮你修改设置。某种程度上它具备自我认知的，能为你提供帮助。

不过，我发现有几个技巧通常非常管用。

第一个技巧：只用最强的模型。 目前是 Opus 4.6。我始终开启“最大努力模式”（maximum effort）。有时人们为了省钱会尝试使用 Sonnet 等成本较低的模型，但因为它们不够聪明，最终往往需要消耗更多 Token 才能完成同样的任务。所以，低成本模型并不一定真省钱。相反，使用能力最强的模型通常成本更低、Token 消耗更少，因为它能更敏捷地完成任务，需要的纠正和指导也更少。

第二个技巧：使用计划模式（Plan Mode）。 我大约 80% 的任务都以计划模式开始。这其实很简单，只需要在提示词中加一句：“请暂时不要写任何代码。” 就行了。

对于终端用户，按两次 Shift-Tab 键就能进入计划模式；桌面应用和网页版也有专门的按钮；移动端也即将支持。我们刚刚还为 Slack 集成推出了这一功能。

本质上，模型会先与你沟通思路。一旦计划确认无误，你再让模型执行。有了完善的计划，加上 Opus 4.6 的能力，它几乎每次都能一气呵成，一次性正确完成任务，我只需要接受编辑即可。

第三个技巧：尝试不同的界面。 很多人提到 Claude Code 就会想到终端。确实，我们完美支持 Mac、Windows 等所有终端环境。但我们也支持其他形式，比如 iOS 和 Android 应用、桌面应用以及 Slack 集成等。无论你在哪里运行，背后都是同一个 Claude Agent。所以我建议大家多尝试，找到最适合自己的工作流。

关于 Codex 与行业竞争

主持人： 太棒了。我想再问几个收尾的问题。您怎么看 Codex？在这个竞争激烈的编码代理（Coding Agent）领域，您如何看待他们的发展方向和竞争力？

Boris Cherny： 实话实说，我还没怎么深度使用过它，记得刚发布时稍微试了一下。在我看来，它和 Claude Code 很像，这其实挺让人欣慰的。我认为竞争是好事，它给用户提供了选择，也倒逼我们所有人做得更好。

但我必须坦白，我们团队只专注于解决用户的问题，很少花时间关注竞争对手，也鲜少试用其他产品。知道它们的存在固然重要，但我更喜欢直接与用户交流，根据反馈来打磨产品。归根结底，关键在于打造一款真正优秀的产品。

AGI 之后的生活规划

主持人： 最后一个问题。我采访 Anthropic 联合创始人 Ben Mann 时，他托我问你一个问题：AGI 实现之后你有什么计划？当你达成 AGI 时，你的生活会变成什么样？

Boris Cherny： 在加入 Anthropic 之前，我住在日本的乡下，过着截然不同的生活。我是镇上唯一的工程师，也是唯一的英语使用者。

我每周骑两三次自行车穿过稻田去农贸市场。那里的节奏和旧金山完全相反，是一种截然不同的生活速率。

我们融入当地社区的方式之一就是交换腌菜。镇上几乎家家户户都做味噌和腌菜。我也因此练就了一手做味噌的好手艺，至今仍乐此不疲。

味噌是一种很有趣的食物，它能教会你用长远的眼光去思考。 这与工程截然不同。一锅白味噌至少需要三个月，而红味噌则需要耗费两三年甚至四五年。你把原料拌好，剩下的就是漫长的等待，必须非常有耐心。我喜欢味噌，正是因为它让我习惯了这种长周期的思考方式。所以，如果 AGI 实现了，或者我不在 Anthropic 了，我大概会去专心做味噌。

闪电问答与结语

主持人： 我太喜欢这个答案了。Ben 特意让我问问味噌的事，很高兴你也提到了。未来或许就是潜心钻研味噌制作之道。Boris，这次访谈非常精彩。感觉我们像来自乌克兰的兄弟一样投缘。在进入激动的闪电问答之前，你还有什么想对听众分享或再次强调的吗？

Boris Cherny： 我想强调的是，对于 Anthropic 而言，从编码到工具使用，再到计算机操作，这是一脉相承的。这是我们思考问题的路径，是我们认为模型发展的必然方向，也是我们要构建的未来。同时，这也是我们研究和最大程度提升安全性的途径。

如今，围绕“代码”已经形成了一个庞大的、数十亿美元级的产业。我的朋友们都在使用它，网络上关于它的讨论也层出不穷。这件事正变得越来越举足轻重。

从某些方面看，这完全出乎意料，因为我们最初并不知道产品会演变成这样，也没想到会从终端形态开始。但从另一方面看，这又在情理之中，因为这始终是我们公司的信念。

不过，一切感觉才刚刚开始。世界上大多数人还没开始使用代码工具，大多数人还没使用人工智能。感觉我们只完成了 1%，路还很长。

主持人： 是的，想想这些数据简直疯狂。你们刚融了巨资。据我所知，Claude Code 的收入就达到了 20 亿美元，Anthropic 的总收入更是达到了 150 亿美元（注：此处原文数字可能存在口误或指代估值）。想到这一切才刚刚起步，真是令人难以置信。

Boris Cherny： 对，这太疯狂了。老实说，Claude Code 之所以能持续增长，全是因为用户。大家充满热情，爱上了这个产品，并积极告诉我们需要改进的地方。它不断进步的唯一原因，就是大家都在用、都在谈论、都在反馈。这是最重要的。对我来说，与用户交流、为他们改进产品，就是我最喜欢的生活方式。

主持人： 还有，做味噌。

Boris Cherny： 对，还有做味噌。其实做味噌并不复杂，你只需要学会等待。

主持人： 真奇妙。好了 Boris，现在进入激动的闪电问答环节。我有五个问题。准备好了吗？第一个问题：你最常推荐给别人的两三本书是什么？

Boris Cherny： 我是个书虫。 第一本是技术书，《Scala 函数式编程》（Functional Programming in Scala）。这是我读过最棒的技术书籍。你可能不会用到 Scala，我也不确定它未来的地位，但函数式编程和类型思维有一种优雅之美。这也是我编写和思考代码的方式。你可以把它当作一本历史文献，也可以作为提升技能的读物。

主持人： 我喜欢这个推荐，一本从未被提及过的书，太棒了。

Boris Cherny： 哈哈，太好了。 第二本是查尔斯·斯特罗斯（Charles Stross）的科幻小说 《加速》（Accelerando）。这是我最喜欢的科幻作品。这本书节奏极快，速度感层层递进。我觉得比任何书都更能捕捉我们当下的时代精髓——那就是“速度”。故事从即将发生的起飞开始，逼近奇点，结局是木星轨道上的集体龙虾意识。而这一切都发生在几十年内，这种节奏感不可思议。

第三本我推荐刘慈欣的 《流浪地球》。大家可能都知道他的《三体》，虽然《三体》很棒，但我更喜欢他的短篇小说。《流浪地球》这本短篇集里有一些非常精彩的故事。阅读中国科幻很有趣，因为这展现了与西方科幻截然不同的视角，至少从他作为作家的思维方式来看是这样。文笔也非常优美。

主持人： 科幻小说确实能引导我们思考未来的方向。它就像构建了一幅宏伟蓝图，让我们感觉“我明白了，我曾在书中读过这样的世界”。

Boris Cherny： 确实如此。实际上，这正是我加入 Anthropic 的原因。就像我说的，我曾住在乡村，那里的一切都很慢，尤其是与科幻小说相比。你在那里做的一切都围绕着季节，围绕着那些需要数月甚至经年累月才能成熟的食物。社会活动通常就是以这种方式组织的，人们的时间安排也是如此。举个例子，当你去农贸市场时，你会发现现在是“柿子季”。你知道这一点，是因为那里大概有 20 个摊位都在卖柿子。而到了下周，这个季节就结束了，变成了“葡萄季”，你能直观地看到这种更替。这就像是一种长远的时间尺度。

与此同时，我读了很多科幻小说。正是在那个时期，我开始思考这些宏大的时间尺度。我看到了事物发展的可能性，并觉得我必须为让未来变得更好而贡献一份力量。这其实就是我最终加入 Anthropic 的原因。Ben Mann 对此也功不可没。

主持人： 我真想专门做一期播客，聊聊你在日本的时光，以及 Boris 穿越日本加入 Anthropic 的旅程，但今天我们会简短一些。如果你还没读过，我快速推荐一本科幻小说——你读过《深渊上的火》（A Fire Upon the Deep）吗？

Boris Cherny： 哦，那是 Vinge（弗诺·文奇）的作品，对吧？是的，我读过。

主持人： 没错，那本书太棒了。从人工智能和通用人工智能（AGI）的角度来看，它非常有趣。可惜读过的人不多，所以我特别推崇它。我经常会想起书里的内容。

Boris Cherny： 是的，没错。我也很喜欢《苍穹浩瀚》（The Expanse）。

主持人： 我觉得那些项目确实是...

Boris Cherny： 对，是的，我认为确实如此。

主持人： 是的，虽然篇幅很长，设定复杂，入门有点难，但非常精彩。好的，我们继续“闪电轮”提问。你最近有没有特别喜欢的电影或电视节目？

Boris Cherny： 其实我不太看电视或电影，现在的确没什么时间。不过我看了 Netflix 的《三体》剧集，非常喜欢。我认为那是对原著小说系列的一次很棒的改编。

主持人： AI 领域的领导者们普遍都有个共同点，就是没时间看电视或电影，我完全理解。那你最近有没有发现什么特别喜欢的产品？

Boris Cherny： 我想稍微“凡尔赛”一下，推荐一下 Claude。这确实是一个改变了我生活的产品，因为它一直在运行。特别是它的 Chrome 集成功能，真的非常出色。它帮我处理了一张交通罚单，还帮我取消了几项订阅。它能帮你解决那么多繁琐的工作，真是太棒了。

虽然不知道这算不算产品，但我还想推荐一个我非常喜欢的播客。除了 Lenny（Lenny's Podcast）之外，就是 Ben 和 David 的 Acquired 播客。真的非常非常棒。他们深入剖析商业历史并使其栩栩如生的方式令人叹为观止。如果你还没听过，建议从任天堂的那一期开始。

主持人： 极好的建议。关于 Claude，为了让大家明白——如果还没试过的话——基本上你输入你想做的事情，它就可以启动 Chrome 浏览器并为你完成任务。我看到有人在 Anthropic 休产假时，让它帮忙填写繁琐的医疗表格。面对那些非常恼人的 PDF 文件，它会自动加载浏览器、登录，然后完成填写。

Boris Cherny： 没错，完全正确。而且它现在真的能用了。一年前我们在做实验时，它还不能很好地工作，因为模型还没准备好。但现在它非常成熟了。我觉得很多人并没有真正理解它是什么，因为他们以前没有使用过智能体（Agent）。它给我的感觉非常像一年前的 Claude Code，但正如我所说，它的进化速度比早期的 Claude Code 要快得多。所以，我认为它已经开始崭露头角了。

主持人： 还有你提到的那个 Chrome 扩展程序，你可以单独使用，它会驻留在 Chrome 中。你可以直接对着它说话，让 Claude 查看你的屏幕、你的浏览器，让它做一些事情，比如告诉你正在浏览什么，或者总结当前的内容等等。

Boris Cherny： 是的，没错。对于刚开始使用 Claude 的人，我推荐这样做：下载 Claude 桌面应用程序。然后转到 Claude 选项卡；它就在代码（Code）选项卡旁边。我推荐的入门方法是让它使用一个工具，比如“清理桌面”或“总结邮件”。或者你可以让它“回复我收到的前三封邮件”，它现在甚至可以帮我撰写回复。

第二件事是连接工具。如果你连接了相关工具，比如你说“看看我收到的重要邮件”，它可以发送 Slack 消息，或者将内容填入电子表格等。例如，我用它来管理我所有的项目。我们有一个全团队的统一电子表格，每位工程师占一行。每周，每个人都要填写一份状态报告。每周一，Claude 就会检查表格，并给那些没有在 Slack 上填写状态的工程师发送提醒消息。这样我就不必亲自做这件事了，只需要一个提示词，它就能搞定一切。

第三件事就是并行运行一系列 Claude 任务。你可以让它同时处理任意数量的任务。比如，启动一个项目管理任务，然后让它做点别的，再做点别的。启动这些任务后，我去喝杯咖啡，让它自己运行。

主持人： 我会附上一篇帖子的链接，里面分享了很多人使用以前被称为 Claude Code（现在可以直接通过代码实现）的各种方式。因为很多时候人们的反应是“哇，我没想到可以这样用”。一旦你看到了这些例子，你就会惊叹：“哇，我不知道我还能用它做这个。”

Boris Cherny： 是的，我认为很多灵感其实是受到了你的启发，Ani。你曾经发过一篇关于“Claude 的 50 个非技术用例”之类的帖子。实际上，我们的一位产品经理在发布产品之前，就是用那篇帖子来评估 Claude 的。当他们发现 Claude 能够完成那 50 个用例中的 48 个时，他们就说，“好吧，这已经足够好了”。

主持人： 哇，我真不知道那篇帖子还有这个作用。我竟然成了评估员？这感觉太棒了。我觉得我对 AI 的未来产生了价值，这简直是一种反向的突破。

哇，那真是太酷了。好吧，我很想知道最后没完成的那两个用例是什么。总之，还有最后两个问题。你有没有一句最喜欢的座右铭，常用来指导你的工作和生活？

Boris Cherny：运用常识（Use Common Sense）。

我认为在工作环境中看到的很多失败，往往是因为人们未能运用常识。比如机械地遵循某个流程而不去思考，或者做事不过脑子。又或者他们正在为一个糟糕的产品或不好的想法而努力，只是随波逐流。

我认为最好的结果，往往来自于那些能够从第一性原理出发思考，并构建起属于自己的“常识体系”的人。比如，如果某件事听起来不对劲，那它大概率就不是个好主意。这是我给同事们最多的建议。

主持人： 我觉得这本身就可以成为一期播客的主题——什么是常识？如何培养常识？但我们今天先聊到这。最后一个问题：你最近在 Twitter/X 上活跃多了。我很好奇原因是什么？你在 Twitter 这个世界里的体验如何？因为你在上面有很多互动。

Boris Cherny： 很长一段时间我只用 Threads，因为我之前也参与过 Threads 的开发。而且我很喜欢它的设计，那是一个非常简洁的产品。

我开始使用 Twitter 是因为感到无聊。去年十二月，我和妻子在欧洲各地旅行。我们去了哥本哈根，去了几个不同的国家。对我来说，这就像一次“编码假期”。每天我都在写代码，这是我最喜欢的度假方式——整天写代码，感觉太棒了。

然后，我突然感到有些无聊，几个小时内就用光了想法。我想，好吧，接下来该做什么？于是我打开了 Twitter。我看到有人在讨论 Claude Code，就开始回复。我想，也许我应该做的是寻找人们遇到的 Bug，或者收集大家的反馈。

于是我介绍了自己，询问人们的情况，收集了很多 Bug 和反馈。我认为他们对我们如今能够如此快速地处理反馈感到惊讶。但对我来说，这太正常了。如果有人遇到 Bug，我可能几分钟内就能解决，因为我熟悉 Claude Code，只要描述清楚，它就能运行。解决完一个，我就可以去做别的事情，处理下一个问题。但我认为很多人对此感到非常惊喜。所以这体验真的很棒。

是的，在 Twitter 上的体验非常好。与人互动，了解大家的需求，倾听关于 Bug 和功能的反馈，这一切都很棒。

主持人： 我前几天在 Twitter 上看到 Nikita Bier 抱怨说，你发了很多很长的帖子，结果导致页面崩了，然后大家都在想“天呐，这是怎么了？”。

Boris Cherny： 是的，没错，那确实是一个 Bug。希望现在已经修好了。

主持人： 太棒了。天呐，Boris，我可以和你聊上几个小时。我就不打扰你了。非常感谢你来参加这次节目。你太棒了。人们在哪里可以找到你？听众如何才能帮助你？

Boris Cherny： 去 Threads 或 Twitter 找我就行，那是联系我最方便的地方。欢迎随时 @ 我，无论是反馈 Bug 还是提交功能需求。告诉我们产品缺了什么？还能做些什么来改进？你们真正想要的是什么？我很期待听到大家的声音。

主持人： Boris，非常感谢你做客我们的节目。

Boris Cherny： 谢谢邀请。

主持人： 再见，各位。感谢大家的收听。

作者：瓜哥新知

参考资料: 

https://www.youtube.com/watch?v=We7BZVKbCVw