• Boris Cherny，Claude Code 的创造者，Anthropic 工程师
• Garry Tan，YC 总裁兼播客主理人
• Jared Friedman，YC 合伙人兼播客联合主持人
• Diana Hu，YC 合伙人兼播客联合主持人

---

Boris 00:00
在 Anthropic，我们的思维方式是：不为今天的模型做开发，而是为 6 个月后的模型做开发。这也是我现在对所有基于大语言模型（LLM）进行开发的创始人们的建议。试着去想一想，现在的模型在哪些前沿领域还不够擅长？因为只要耐心等待，它迟早会变得强大。所有的 Claude Code 都被反复重写、重写、再重写。现在的 Claude Code 里，没有哪怕一行代码是 6 个月前留下的。

Boris 00:21
你去尝试，把它交给用户，与用户交流，你去学习，最终你可能会得到一个好点子。当然有时也不会。

Jared 00:27
但在你的潜意识里，你是不是也会觉得，也许 6 个月后，你甚至都不需要给出那么明确的提示词（Prompt）了，模型自己就已经足够聪明去解决了？

Boris 00:34
也许一个月后就行了，哈哈。

Diana 00:36
一个月后就不需要 Plan（计划）模式了。

Garry 00:38
我的天啊。

Garry 00:46
欢迎收听新一期的《光锥》（The Light Cone）播客。今天我们请到了一位极其特别的嘉宾——Boris Cherny，他是 Claude Code 的创造者和工程师。Boris，感谢你的加入。

Boris 00:58
感谢邀请。

Garry 00:59
感谢你创造了这个让我连续三周熬夜到失眠的神器。我已经对 Claude Code 彻底上瘾了，用起来感觉就像装了火箭推进器一样。对于其他人来说，这种感觉是不是已经持续好几个月了？我觉得大概在去年 11 月底的时候，我的很多朋友就跟我说“一切都变了”。

Boris 01:19
我还记得，我第一次开发出 Claude Code 时也有这种感觉，那时我还不知道自己是不是弄出了什么了不得的东西。我隐约觉得抓住了某个重点，然后我也开始失眠了。而且那不是 1 个月或 3 个月，而是 2024 年 9 月的事情。那是整整三个月，我一天假都没休，周末也在加班，每天晚上都在疯狂写代码。我当时就觉得：“我的天，我觉得这东西能成。”但我当时还不知道它到底好不好用，因为那时候它还不能真正写业务代码。

Garry 01:45
如果你从那一刻回望现在，最让你感到惊讶的是什么？

Boris 01:52
令人难以置信的是，我们现在居然还在用终端（Terminal）。终端本该只是一个起点，我从没想过它会成为最终的形态。其次，它在早期阶段居然就已经能派上用场了。其实在 2 月份我们刚做出来的时候，它还不怎么会写代码，大概只能帮我写 10% 的代码。我基本不会用它来写，因为当时它写得并不好，我的大部分代码还是手写的。

所以，我们的赌注竟然真的有了回报，它变得越来越强大，并且恰好在我们预想的领域变得强大——这绝非显而易见。在 Anthropic，我们的理念是：不为今天的模型做开发，而是为 6 个月后的模型做开发。这也是我现在给那些基于 LLM 开发应用的创始人的建议——试着去想一想，现在的模型在哪些前沿领域还不够好？因为只要你耐心等待，它迟早会变得强大。

Jared 02:38
你还记得你第一次萌生这个想法是什么时候吗？能跟我们聊聊整个过程吗？是有什么灵光一闪的瞬间，或者你脑海中它的初版是什么样的？

Boris 02:46
挺有意思的，这其实是个极其偶然的产物，它是自然演化成现在这样的。作为 Anthropic 员工，我们长期以来都押注在“编程”上，我们坚信通向 AGI（通用人工智能）的必经之路就是编程。

Boris 03:02
这一直是我们的一个核心构想。实现它的路径是：首先教模型写代码，然后教它使用工具，最后教它使用计算机。你可以看到一条清晰的脉络，因为我在 Anthropic 加入的第一个团队叫 Anthropic Labs，我们推出了三款产品：Claude Code、MCP（模型上下文协议）和桌面端应用。你可以看出这些产品是如何交织在一起的。

至于我们具体开发的这个产品——并没有人要求我去做一个命令行界面（CLI）。我们只是隐约觉得，也许是时候做一款编程产品了，因为模型似乎已经准备好了，但市面上还没有人真正做出能驾驭这种能力的产品。尽管现在依然有一种强烈的“产品落后于模型能力”的感觉，但在当时那种感觉更疯狂，因为真的还没人做出来。于是我开始自己瞎折腾，心想：“好吧，如果要开发一款编程产品，我首先需要做什么？”

Boris 03:51
首先，我得搞懂怎么使用 API，因为那时候我还没用过 Anthropic 的 API。所以我就写了一个非常简单的终端应用来调用 API，仅此而已。它就是一个小巧的聊天应用，毕竟你想想当时的 AI 应用形态，对非技术普通用户来说，绝大多数人用的也就是聊天界面。所以我做出了这个在终端里运行的工具，我可以提问，它能回答。接着，Tool Use（工具使用）功能发布了。我想试用一下它，因为我不太懂这玩意儿是啥。我想：“使用工具，听起来很酷，但真的有用吗？可能没用吧，但我还是试试看。”

Jared 04:23
你选择在终端里做，仅仅是因为这是能让它最快跑起来的方法？

Boris 04:27
是的，因为我不需要去画 UI 界面，而且那时候整个项目就只有我一个人。

Jared 04:31
当时像 Cursor、Windsurf 这些 AI IDE 已经开始大火了，你有没有承受什么压力，或者收到很多建议说：“嘿，我们应该把它做成一个插件，或者直接做成一个功能齐全的 IDE ！”？

Boris 04:43
完全没有压力，因为我们甚至不知道自己想做什么。当时团队正处于探索模式，我们只知道大致想在编程领域做点什么，但具体做什么并不明朗。没有谁有足够的把握能指明方向，弄清楚这个问题就是我的工作。于是，我给了模型一个 Bash 工具，这也是我给它的第一个工具，因为那其实就是我们官方文档里的示例代码。我直接把 Python 的示例用 TypeScript 重写了一遍，因为我习惯用 TS 写代码。

Boris 05:07
我当时并不知道模型拿到 Bash 之后能干什么。所以我让它读取一个文件，它居然成功用 cat 命令输出了文件内容，我觉得这太酷了。然后我想：“好吧，那你还能做什么？”我就问它：“我正在听什么音乐？”它竟然写了一段 AppleScript 脚本来控制我的 Mac，并从我的音乐播放器里查到了正在播放的音乐。

Boris 05:23
我的天啊！这可是 Claude 3.5 Sonnet 模型，我本以为它做不到这些。这应该是我人生中第一次切身感受到“AGI 降临的时刻”，我当时震撼极了：“天哪，模型太渴望使用工具了。它想要的仅仅是工具而已。”

Diana 05:38
这太迷人了。我的意思是，这其实很反直觉——Claude Code 在如此优雅、极简的形态下居然能运转得这么好。终端（Terminal）已经存在很长时间了，它似乎提供了一个绝佳的设计约束，催生了许多有趣的开发者体验。在里面工作甚至感觉不到是在工作，就是觉得极具极客乐趣。考虑到所有的文件系统都在那里，这几乎是个“美丽的意外”。

Boris 06:07
是的，确实是个意外。我还记得，在终端版本开始受到欢迎之后……老实说，在做出最初原型的两天后，我就开始把它给我的团队去“吃狗粮”（内部试用）了。因为你知道的，如果你想出了一个看起来有用的点子，你要做的第一件事就是把它给别人用，看看别人是怎么用的。第二天我来到办公室，坐在我对面的工程师 Robert，他已经在电脑上装了 Claude Code，并且正在用它写代码。我当时就惊呆了：“你在干嘛？这东西还没准备好呢，只是个原型啊！”但事实证明，这种终端形态已经足够实用了。

我记得当我们在准备正式对外发布 Claude Code 时（大概是 2024 年 11 月或 12 月的发布评审会），Dario（Anthropic 联合创始人）问我——他看到了内部使用的数据图表，那个 DAU（日活用户）曲线几乎是垂直飙升的——他问：“你们是不是在强制工程师用这个？为什么要强制他们用？”我当时连忙解释：“没有没有，我们绝对没有。我只是在内部发了个帖子，然后大家就开始口口相传了。”说实话，这完全是个意外。我们从 CLI 起步仅仅是因为它开发成本最低，然后就顺理成章地保留了下来。

Jared 07:10
在 2024 年那个时期，工程师们是怎么使用它的？他们已经开始用它交付代码了吗？还是用在别的地方？

Boris 07:18
当时模型在写代码方面其实还不太行。我自己主要用它来自动化执行 Git 命令。到现在我可能已经忘了大部分 Git 语法了，因为 Claude Code 替我代劳太久了。早期的典型用例就是自动化 Bash 命令，或者操作 Kubernetes 集群之类的。

也有人尝试用它写代码，所以出现了一些早期的迹象。我觉得第一个真正的代码用例是写单元测试，因为风险相对较低，而且当时模型写业务代码还挺糟糕的。但人们在逐渐摸索它的用法。我们观察到一个现象：人们开始为自己编写 Markdown 格式的说明文档，然后让模型去读取这些文档。这就是 Claude.md 的由来。对我个人而言，产品开发中最重要的核心原则就是“隐性需求”（Latent Demand），而在最初的 CLI 之后，这个产品的每一个功能几乎都是由隐性需求驱动开发出来的。Claude.md 就是一个典型的例子。

Boris 08:09
这里还有一个可能很有趣的通用原则：你可以为模型进行开发，可以在模型外围搭建脚手架（Scaffolding）代码来稍微提升它的性能。根据不同领域的差异，也许能提升 10% 到 20% 的表现。但问题是，只要下一代模型一发布，你辛苦做出来的这些性能增益瞬间就变得毫无意义了。所以，你要么费尽心思搭建脚手架换取一点微弱的提升，然后在新模型发布后再推倒重来；要么，你干脆什么都不做，耐心等待下一代模型，然后免费获得这些能力。

Claude.md 和周围的脚手架代码就是个绝佳的例子。我觉得我们之所以坚持留在 CLI 形态，是因为我们当时觉得，无论我们今天花多少精力去打磨一个炫酷的 UI 界面，6 个月后它都会变得无关紧要，因为模型进化的速度实在是太快了。

Garry 08:48
刚才我们还在聊，我们应该互相交流一下各自的 Claude.md 怎么写的。但你说了一句非常深刻的话，你说你的配置文件其实非常短，这几乎和大家的普遍认知相反。你的 Claude.md 里到底写了什么？

Boris 09:01
好的，我来之前特意看了一下。我的 Claude.md 里只有两件事，也就两行内容。第一行是：每当我发起一个 PR（Pull Request），开启自动合并（Auto merge）。这样只要有人通过了审批，它就会自动合并。这主要是为了方便我专心敲代码，不用在代码审查环节来回折腾。第二行是：每当我发起一个 PR，把它发到我们内部团队的 Slack 频道里。这样就有人能马上帮我审查，我就不会被阻塞。

我们的理念是：其他所有的项目规范和指令都写在代码库根目录的 Claude.md 里，这是我们整个团队每周都会共同维护和更新的东西。很多时候，如果我看到某人的 PR 里犯了一个完全可以避免的低级错误，我就会直接在 PR 里艾特 Claude——类似“@Claude，把这条规则加到 Claude.md 里”。我一周大概会这么干好几次。

Garry 09:51
你需要去精简你的 Claude.md 吗？我之前就遇到过这种情况，终端顶部弹出一个提示，说我的 Claude.md 已经占了好几千个 Token 了。你们碰到这种情况会怎么做？

Boris 10:01
我们的 Claude.md 其实挺短的，大概也就几千个 Token。如果你遇到这种情况，我的建议是：直接删掉你的 Claude.md，重新开始。

Garry 10:10
有意思。

Boris 10:11
我觉得很多人喜欢过度设计这个东西。实际上，模型的能力是随着每次迭代而变化的。所以你真正想要的是：用最极简的指令让模型回到正轨。如果你删除了 Claude.md，发现模型开始跑偏、做错事，那时候你再一点点加回来就行了。你大概率会发现，随着新模型的发布，你需要写进去的规则会越来越少。

就我个人而言，老实说，我觉得自己就是个挺普通的工程师，我不怎么用那些花哨的工具，比如我不怎么用 Vim，我用 VS Code，就是很常规的那种。
大家可能会觉得，既然我做了一个终端工具，那我一定是个极度硬核的“终端死忠粉”，或者是个“非 Vim 不用”、鄙视 VS Code 用户的原教旨主义者。当然，我们团队里确实有这样的人，比如 Adam Wolf（团队工程师），他就是那种“想要我放弃 Vim？除非从我冰冷的尸体上踩过去”的人。

我们团队里有很多这样的极客。这也是我早期学到的一件事：每个工程师都有自己偏好的开发习惯和工具栈，根本不存在一个能让所有人满意的万能工具。但我也认为，正是这一点让 Claude Code 能够变得如此出色，因为我的出发点是：“我需要一个能顺应我的直觉、让我自己愿意去用的产品”。所以，要使用 Claude Code，你不需要懂 Vim，不需要懂 tmux，不需要知道怎么配置 SSH。你不需要掌握这些繁琐的东西，你只需要打开终端工具，它就会指引你，帮你搞定一切。

Garry 11:28
你是怎么决定终端的输出应该有多详尽（Verbose）的？有时候你得按 Ctrl+O 去查看详细日志。内部是不是也因为“输出日志该长点还是短点”发生过那种关于细枝末节的激烈争论？毕竟每个用户的口味都不一样，你们是如何做决定的？

Boris 11:45
你的看法呢？你觉得现在的输出太啰嗦了吗？

Garry 11:47
哦，我简直爱死这种详尽的输出了！因为有时候它就是会突然开始“发癫”，我在旁边盯着看，快速扫一眼就知道：“哦，不对不对，不该是这样。”然后我立刻按 Esc 键打断它。这样就能在灾难发生的同时，直接掐灭一个潜在的 bug 温床。通常这种情况都是因为我没有正确使用 Plan（计划）模式。

Boris 12:05
这确实是我们经常调整的一个地方。我记得早期，大概是 6 个月前吧，我试图在内部版本中屏蔽掉 Bash 的原始输出，只显示摘要。因为我觉得那些又长又臭的 Bash 命令根本没人关心。结果，我给 Anthropic 内部员工试用了一天，所有人全都造反了！他们喊着：“我要看我的 Bash 输出！”因为这对他们来说其实非常有用。比如对于 Git 输出，可能没那么重要；但如果你正在运行 Kubernetes 任务或者类似的操作，你绝对会想看到具体的执行日志。

Boris 12:32
最近，我们隐藏了文件读取和文件搜索的详细输出。你会注意到，现在它不会再说“读取了 foo.md”，而是会显示“读取了 1 个文件，搜索了 1 个模式”。如果是 6 个月前，我们绝对不敢上线这个改动，因为当时的模型还不够强大，它经常会读错文件，作为用户你必须在旁边盯着抓错和调试。但现在我发现，它在绝大多数情况下都能找对方向。既然它已经如此高频地使用工具，直接总结输出结果其实体验要好得多。

不过，我们上线并内部试用了一个月后，GitHub 上的开源用户又不喜欢了。有人专门提了个高热度的 Issue，说：“不，我想要看细节！”这是非常棒的反馈。于是我们新增了一个“啰嗦模式”（Verbose Mode）。你只要输入 /configure，就可以开启它，继续查看所有的文件输出细节。然后我又在那个 Issue 里回复，结果还是有人不满意，但这同样太棒了！因为我这辈子最喜欢的事情，就是倾听用户的反馈，了解他们到底想怎么用这个产品。我们就这样一遍又一遍地迭代，力求把它做到极致，把它变成大家真正想要的模样。

Garry 13:32
让我惊讶的是，我现在居然非常享受修 Bug。现在你只需要有详尽的日志，甚至只要告诉它：“嘿，看下这个特定对象，它在某个地方出了错。”它就能自动去翻日志，把前因后果理得清清楚楚。它甚至能帮你建立一个连通生产环境的隧道，替你去查生产数据库。这太疯狂了！修 Bug 马上就会变成只是去 Sentry 复制一段 Markdown 日志，很快就会演变成纯粹的 MCP（模型上下文协议）调用——一种自动修 Bug 和自动写测试的系统。现在流行的新词叫什么来着？“全自动初创公司工厂”？

Garry 14:09
现在涌现出了一大批全新的理念，它认为不再需要人类去人工审查代码。我比较“老派”，所以我喜欢看详细的输出。我喜欢对它说：“哦，你现在在做这个，但我希望你做那个。”但现在出现了一个完全不同的流派，他们认为：“任何需要真人员工去肉眼检查代码的情况，都是糟糕的设计。”这真的很有意思。

Boris 14:31
我觉得 Dan Shipper（知名科技作家）经常谈到这一点：只要你看到模型犯了错，就尽量把纠错规则放进 Claude.md 里，或者封装成可复用的技能。但我发现这里面其实有一个很大的悖论，我自己也经常纠结。大家都说“Agent（智能体）能做这个，Agent 能做那个”，但实际上，Agent 究竟能做什么，是随着每一个新模型的发布而不断改变的。

所以有时候团队里新来了一个人，他们反而比我更会用 Claude Code。我经常被这种事惊艳到。举个例子，我们之前遇到了一个内存泄漏问题。顺便提一句，Jared Sumner（Bun 创始人）最近一直在带头疯狂消灭各种内存泄漏，简直神了。但在 Jared 加入团队之前，这活儿是我干的。当时有个内存泄漏，我正试图调试。我抓取了堆转储（Heap Dump），在开发者工具里打开，仔细翻看性能分析报告，对照着代码，绞尽脑汁想找出原因。

就在这时，团队里的另一位工程师 Chris，他直接把问题扔给了 Claude Code。他说：“嘿，我觉得这里有个内存泄漏，你试着找找原因。”然后 Claude Code 直接拿到了堆转储文件，自己给自己写了一个小工具来分析这个文件，最后它找内存泄漏的速度居然比我还快！

这就是我必须不断重新学习的东西，因为很多时候，我的思维依然被禁锢在 6 个月前的经验里。

Diana 15:43
那么，对于那些希望在最新模型发布时，彻底将其能力榨干（成为“模型最大化主义者”）的技术创始人，你有什么建议吗？听起来，那些刚出校门、大脑没有条条框框的新人，似乎比在这个行业摸爬滚打多年的老兵更有优势？专家们又该如何提升自己呢？

Boris 16:05
我觉得对于个人来说，关键是要保持“初学者心态”，或者说，保持谦逊。我觉得在软件工程这个学科里，我们早就习惯了去持有非常强烈的观点，而资深工程师往往因为这种特质而受到奖赏。在我以前大公司的工作中，当我们去招聘架构师这种级别的工程师时，我们寻找的正是那些经验丰富且观点极其笃定的人。
但现在事实证明，以前的很多经验都不再适用了。随着模型越来越强，很多固有的观点都应该被打破。所以我认为现在最重要的能力，是能够用科学的方法思考，并能回归第一性原理去解决问题的人。

Diana 16:38
那你们现在在为团队招聘时，是如何筛选这种特质的？

Boris 16:42
我有时会问：“能不能举一个你曾经犯错的例子？”这是个非常棒的问题。很多这种传统的行为面试题，甚至不是写代码的问题，反而非常有效。因为你可以借此看出他们能否在事后认识到自己的错误，能否勇于承担责任，以及是否从中吸取了教训。

很多非常资深的人——当然也有一些创始人是例外，我觉得优秀的创始人在这方面通常做得很好——但其他人有时候就是不肯为错误承担责任。就我个人而言，我大概有一半的时间都是错的，我的一半想法都是馊主意。你必须去不断尝试，去把东西交给用户，去跟用户聊天，去学习反馈，最终你才可能撞上一个好点子。当然，有时候你还是会失败。在过去，这被认为是创始人必须具备的核心技能；但在今天，我认为这是每一个工程师都必须具备的技能。

Garry 17:32
你觉得未来会不会有这样一天：你单凭一个人在使用 Claude Code 等 Agent 时的交互记录（Transcript）来决定是否录用他？因为我们现在正在积极尝试这种做法。我们最近刚刚加入了一个测试环节——你可以上传你使用 Claude Code 或 Aider 开发某个功能的对话记录。

Garry 17:51
我个人觉得这绝对行得通。通过这些记录，你能看出一个人的思维方式：他们会不会去看日志？如果 Agent 跑偏了，他们能不能及时纠正？他们会不会使用 Plan 模式？在使用 Plan 模式时，他们是否考虑了编写测试？他们有没有系统性思维？甚至他们是否理解系统的概念？

这里面蕴含了太多的信息。我甚至想搞个像《NBA 2K》游戏里那样的雷达图（Spider web graph）了——“哦，这个人在投篮和防守上很强”，你能想象一张展示某人“Claude Code 技能等级”的雷达图吗？

Boris 18:30
哈哈，那这个雷达图上会有哪些技能维度呢？具体会有什么？

Garry 18:33
我觉得肯定有系统测试能力、用户行为洞察，我的意思是，肯定得包含设计感和产品感。

Boris 18:39
还有自动化能力。

Garry 18:42
我自己的 Claude.md 里最让我得意的一条是：对于生成的每一个计划，都要评估它是过度设计了、设计不足、还是恰到好处，并说明理由。

Boris 18:53
我觉得这也是我们团队正在努力摸索的事情。当我观察团队里最高效的那些工程师时，我发现他们呈现出明显的两极分化。
一端是极端的专家型人才。就像我前面提到的 Jared（Bun 的作者），他就是这方面的典型，Bun 团队也是非常典型的例子。他们是超级专家，比任何人都懂开发工具，比任何人都要精通 JavaScript 运行时系统。
而另一端则是超级通才（Generalists）。这大概代表了团队里的大多数人。很多人跨界组合能力很强，比如跨界产品与基建、产品与设计、产品与用户研究，或者是产品与商业化。

Boris 19:27
我个人非常喜欢看到员工去捣鼓一些“稀奇古怪”的东西。在过去，这常常会被视为一个危险信号，因为老板会怀疑：“这些人到底能不能做出点有用的东西？”

Garry 19:38
这是真正的极限测试。

Boris 19:39
是的，这正是马斯克的风格。但在今天，情况完全变了。举个例子，我们团队的一位工程师 Daisy，她之前在别的团队，后来转到了我们组。我之所以想让她过来，是因为她刚加入没几周，就给 Claude Code 提了一个 PR，想加个新功能。但她并没有直接去写那个功能，而是先提了一个 PR：给 Claude Code 赋予一个“测试任意工具并验证其是否有效”的能力。等这个 PR 合并后，她直接让 Claude 自己去把那个新功能写了出来，而不是自己手敲代码。

我觉得这种跳出框架的思维方式太有趣了，因为现在还没多少人能转过这个弯来。我们使用了 Claude Agents SDK 来自动化开发流程的几乎每一个环节：它能自动化代码审查、安全审查，能给 Issue 打标签，能把代码自动部署到生产环境。它基本上包揽了我们的一切工作。但我发现外界也有很多人开始慢慢领悟到这一点。不过，学会如何这样驾驭 LLM、如何运用这种新型自动化，确实需要时间。这绝对是一门新技能。

Garry 20:40
现阶段我跟各种创始人做 Office Hours（一对一辅导）时，最有趣的一个现象是：假设有一位富有远见的创始人，他有一个绝妙的创意，在他的脑海中已经构建了一座极其完美的“产品水晶宫”，他脑子里已经完全装下了目标用户是谁、用户的痛点是什么、用户的动机是什么。然后他坐在 Claude Code 面前，他一个人能干 50 倍的工作量。

但是，他手下雇佣的工程师们，并没有创始人脑海中那种对完美产品的“水晶宫般”的深刻记忆。所以那些工程师借助 AI 可能只能发挥出 5 倍的工作量。

你有没有听到过类似的故事？通常都有一个核心的产品架构师，他现在就像是把大脑里的想法疯狂倾泻出来。这些团队未来的协作形态会是怎样的？似乎这已经变成了一种稳定的结构——拥有愿景的人彻底被解放了。回到我们开头的话题，我自己现在就有这种感觉：“哎呀，我只是个单打独斗的人，我还要吃饭睡觉，我还有别的工作。我到底要怎么搞定这一切呢？”

Boris 21:51
你知道的，我们即将推出 Claude Teams。这提供了一种解决方案，但你完全也可以用你自己的方式去搭建类似的工作流，这其实非常简单。

Garry 21:57
Claude Teams 协作的愿景是什么？

Boris 21:59
这是一个人们正在探索的全新领域：智能体拓扑结构（Agent Topologies）——即你如何去编排和配置各种 Agent。

其中有一个分支理念叫做“不相关的上下文窗口”（Uncorrelated Context Windows）。它的核心思想是：启动多个 Agent，它们都拥有全新的、未被污染的上下文窗口，它们不会受到彼此上下文或自身历史记录的干扰。如果针对一个问题，你能投入更多的上下文窗口去并行处理，这本质上就是一种测试时计算（Test-time Compute），你能通过这种方式获得更强的能力。如果在这个基础上叠加正确的拓扑结构，让这些 Agent 能够以恰当的方式进行通信和权重分配，它们就能构建出非常庞大的系统。

所以，Teams 就是其中的一个理念，我们很快还会推出更多相关的功能。核心愿景就是：也许它能构建出更宏伟的项目。我认为第一个成功的巨大案例就是我们的 Plugins（插件）功能。这整个功能是在一个周末，完全由一群“蜂群 Agent”（Swarm）自动构建出来的。它连轴转了几天，中间几乎没有任何人工干预。而 Plugins 最终发布时的形态，基本上就是它周末自动写出来的那个版本。

Garry 22:52
你们是怎么部署这个过程的？是你们先写好期望实现的功能规格（Spec），然后让它自己去搞定细节，直接让它跑起来吗？

Boris 23:02
是的，团队里的一位工程师只给了 Claude 一份规格说明书，并告诉它使用 Asana 的看板。然后 Claude 自己就在 Asana 上建了一堆任务卡片，接着孵化出了一群 Agent，这些 Agent 开始主动认领任务。主控的 Claude 给它们分配指令，然后它们就自己把所有事情搞定了。

Diana 23:19
那些独立执行任务的子 Agent，它们其实并不知道那份宏大规格书的全部上下文，对吧？

Boris 23:24
如果你了解我们现在的 Agent 是怎么启动的——虽然我没有拉取具体的数据，但我敢打赌，如今绝大多数的 Agent 其实都是由 Claude 亲自提示（Prompt）出来的，具体形式就是子智能体（Sub-agents）。因为子智能体在代码逻辑上，就是一个递归运行的 Claude Code。它是由我们戏称为“Claude 妈妈”（Mama Claude）的主节点触发的。我认为，如果你去观察绝大多数以此方式启动的 Agent，情况都是如此。

Jared 23:46
它们都是这样启动的。就像 Claude 之前刚给我提了个建议，让我在调试时多用这种方法。因为我花了大量时间在修 Bug 上，如果能让多个子 Agent 同时启动，并行去排查问题，效果会好得多。所以我把这个加到了我的 Claude.md 里：“嘿，下次你尝试修 Bug 的时候，派一个 Agent 去看日志，另一个 Agent 去追踪代码执行路径。”面对那些诡异、可怕的 Bug，这似乎是不可避免的趋势。

Garry 24:09
我通常会用 Plan 模式来修 Bug。在这种模式下，它似乎会调用多个 Agent 去对所有东西进行广度搜索；而当你只是想在当前行（In-line）直接修复时，它就只会想着：“好吧，我只专注眼前这一个小任务”，而不是进行广泛的搜索。

Boris 24:22
这也是我经常用的一招。如果这是一个非常棘手的系统性或研究性任务，我会根据任务的难度，动态调整我要求它调用的子 Agent 数量。如果特别难，我会告诉它：“启动 3 个、5 个甚至 10 个子 Agent 进行并行研究，然后把结果汇总看看。”

Jared 24:38
我很好奇，那你为什么不把这一条写进你的 Claude.md 文件里呢？

Boris 24:42
因为这需要视情况而定。你要知道，Claude.md 到底是什么？它就是一个快捷方式。如果你发现自己在一遍又一遍地重复同样的话，你才应该把它放进 Claude.md 里。否则，你不需要把所有东西都塞进去，你随时可以直接向 Claude 发出指令。

Jared 24:54
但在你的潜意识里，你是不是也会觉得，也许 6 个月后，你甚至都不需要给出那么明确的提示词了，模型自己就已经足够聪明，能够自行搞定？

Boris 25:02
也许一个月后就行了。

Diana 25:05
一个月后就不需要 Plan（计划）模式了。

Garry 25:07
我的天啊。

Boris 25:07
我觉得 Plan 模式的寿命大概也快到头了。

Garry 25:10
有意思。

Diana 25:11
这可是今天给大家爆的一个内部猛料（Alpha）。如果没有了 Plan 模式，未来的开发世界会是什么样？你只要在提示词层面描述一下需求，它就能一把过（One-shot）直接搞定？

Boris 25:19
是的，我们已经开始在这方面进行实验了。如果你注意到了的话，现在的 Claude Code 已经可以自行进入 Plan 模式了。我们正致力于把这种体验打磨到极致，让它能够精准地在人类原本想要开启 Plan 模式的那个节点，自动帮你开启。所以，我猜未来的形态大概就是这样。不过说实话，Plan 模式其实没有什么惊天大秘密。它唯一做的，就是在你的提示词末尾加上一句话：“请先不要写代码。”就这么简单，你完全可以直接手动输入这句话。

Diana 25:45
听起来，Claude Code 的很多功能开发，非常符合我们在 YC 经常强调的那套逻辑：去跟用户聊天，听取反馈，然后再去实现它。而不是你一开始就憋了一个宏大的“总体规划”，然后按部就班地实现所有的功能。

Boris 25:58
没错，事实就是这样。以 Plan 模式为例，我们当时观察到很多用户会这样说：“嘿，Claude，我想到了一个点子，你先给我规划一下，但先别写代码。”用户有各种各样类似的诉求：有时他们只是想和模型讨论一个想法，有时他们要求 Claude 编写非常复杂的架构规范，但共同点都是：在做某事之前，先不要急着写代码。

所以，那天大概是周日晚上的十点，我正在翻看 GitHub 的 Issue 看看大家都在聊什么，同时也扫了一眼我们内部的 Slack 反馈频道。我大概花了 30 分钟就把这个功能写了出来，然后当晚就部署上线了。周一早上，大家就用上 Plan 模式了。

Jared 26:31
所以你是说以后连 Plan 模式都不需要了？我的意思是，如果你担心模型做错事或者跑偏了怎么办？难道不需要在动手前，先理清思路，确认这到底是不是你想要的吗？你总得找个地方做规划吧。

Boris 26:47
我的思考角度是基于模型能力的不断攀升。大概 6 个月前，光有个 Plan 模式是不够的。你让 Claude 做了一个计划，哪怕使用了 Plan 模式，你还是得坐在电脑前盯着它，像个保姆一样，因为它写着写着就会跑偏。

现在呢，我大概 80% 的会话都是从 Plan 模式开始的。虽然我刚才说 Plan 模式气数已尽，但我本人其实是个 Plan 模式的重度用户。我会让 Claude 开始制定计划，然后我切换到第二个终端选项卡，让它再做一个计划。等我的终端选项卡用完了，我就打开桌面版应用，切到 Code 标签页，再开一堆新会话，全部以 Plan 模式启动。

现在我发现，大概从 Opus 4.5（其实从 4.6 左右就开始了），它变得非常强大。一旦制定的计划没问题，它就能死死咬住目标不放，几乎每次都能分毫不差地完成任务。

所以你看，以前你既要在制定计划前做保姆，也要在写代码时做保姆。现在，你只需要在制定计划时把关就行了。那么顺理成章的下一步就是：你完全不需要当保姆了。你只需要抛出一个需求，Claude 自己就能想明白一切。

Garry 27:51
再下一步，就是 Claude 直接去跟你的用户沟通了！

Jared 27:56
没错，直接把你这个中间商跳过了。

Boris 27:58
挺有意思的，这其实就是我们目前的日常。我们内部的 Agent 会互相交流，它们甚至会在 Slack 上直接和我们的内部用户对话。经常有我的 Claude Agent 想要自己发推文——哈哈，没有啦，其实我把那部分代码删了，因为这感觉有点俗套，我不太喜欢那种语气。

Garry 28:14
它想发点什么推文？

Boris 28:15
有时它就是想在网上回复别人，因为我后台一直挂着 Computer Use（计算机控制）功能，这个功能特别喜欢自己去浏览网页。最搞笑也是最常见的一种模式是：我让 Claude 去开发某个功能，它去翻看代码库，查了一下 Git Blame，发现某个工程师动过相关代码。然后它就会自己摸到 Slack 上，直接给那个工程师发消息请教细节。等人家回复了之后，它再接着回去干活。

Diana 28:37
对于现在的创始人来说，如果要为未来开发产品，你有什么建议吗？听起来似乎一切都在急剧变化中，有哪些核心原则是会沉淀下来的，又有哪些是注定会被淘汰的？

Boris 28:47
我觉得有些原则非常基础，但它们在今天甚至比过去更为重要。

首先第一个原则就是：隐性需求（Latent Demand）。这个词我今天估计提了有一千次了，对我来说，这就是做产品最伟大、最核心的理念。但这也是一个很多人都不理解的概念，我在前几次创业时也绝对没搞懂。它的核心逻辑是：人们只会去做他们已经在做的事情。你不可能强迫人们去养成一个全新的习惯。如果你发现人们正试图做某件事，而你提供了一个能让他们更轻松完成的工具，那就是个好点子。但如果人们习惯这么做，你却试图用你的工具逼他们用另一种方式做事，他们绝对不买账。你唯一要做的，就是把他们原本就想做的事情变得更简单。

我认为，随着模型越发强大，Claude 会越来越擅长帮你挖掘这类产品点子，因为它能帮你分析海量的用户反馈和调试日志。

Jared 29:28
这就是你所说的“Plan 模式解决隐性需求”的意思吧？人们本来就习惯在浏览器里开着 Claude 聊天窗口，跟它反复讨论需求文档和逻辑。而现在，Plan 模式让大家可以直接在 Claude Code 终端里完成这一步。

Boris 29:44
没错。有时候我会怎么做呢？我会在我们办公楼层里瞎转悠，然后悄悄站在别人身后打个招呼：“嗨！”接着我就默默观察他们到底是怎么使用 Claude Code 的。这是我亲眼看到的高频场景，同时大家在 GitHub 的 Issue 里也都在激烈讨论这个需求。

Jared 30:01
听起来，连你自己都很惊讶终端（Terminal）竟然能走得这么远，被挖掘得这么深。考虑到现在已经进入了多智能体“蜂群”（Swarm）的时代，你觉得终端形态还能撑多久？你认为在终端之上，未来是否需要一个全新的 UI 界面？

Boris 30:17
挺好笑的，如果你一年前问我这个问题，我一定会信誓旦旦地说：终端形态最多只有三个月的寿命，然后我们肯定会进化到下一个阶段。

你其实能看到我们在这方面疯狂试探。Claude Code 诞生于终端，但现在，我们把它搬到了网页版上，放在了桌面端应用里（代码标签页已经上线好几个月了），塞进了 iOS 和 Android 移动端的代码标签页，集成到了 Slack 和 GitHub 里，甚至开发了 VS Code 和 JetBrains 插件。我们一直在拿各种各样的产品形态做实验，试图找出它的“下一站”到底在哪里。既然关于终端寿命的预测我已经错得一塌糊涂了，那我可能真不是那个适合做这种预测的人。

Jared 30:56
那对于那些开发工具（DevTools）领域的创始人，你有什么建议吗？如果现在有人想创立一家开发工具公司，他们到底该为人类工程师做开发，还是应该换个思路，去思考 Claude 的思维方式，专门去为 Agent 开发工具？

Boris 31:11
我的思路是这样的：去思考模型到底想干什么，然后想办法让它做这件事变得更简单。这也是我们观察到的。当我刚开始鼓捣 Claude Code 时，我意识到：“这家伙满脑子只想使用工具，它极度渴望与现实世界互动。”那你该如何去满足它？正确的做法绝不是把它关在一个沙盒里，然后冷冰冰地说：“这是 API，这是你和我交互的方式，那是你和世界交互的方式。”正确的做法是：去观察它试图使用什么工具，洞察它的意图，然后为它赋能，就像你在服务人类用户时做的那样。

所以，如果你在做一家开发工具初创公司，我会建议你先想清楚：你想为人类用户解决什么问题？当引入 AI 模型来解决这个问题时，模型本身倾向于怎么做？最后，什么样的技术和产品方案，能够同时满足人类与模型这双方的“隐性需求”？

Garry 31:56
如果想同时满足 YC 的需求呢？YC 下一期训练营现在已经开放申请了，初创公司可以访问 ycombinator.com/apply 提交申请。申请永远不嫌早，光是填写申请表的过程，就能让你的点子升华。好的，广告结束，回到正题。

Diana 32:10
回到十多年前，你曾是 TypeScript 的重度用户，而且你还写过一本关于 TypeScript 的书。那是在 TypeScript 大火之前，大家还深陷在纯 JavaScript 泥潭里的 2010 年代初，对吧？

Boris 32:25
是的，差不多是那个时候。

Diana 32:26
在 TypeScript 还未成为主流之前，它被视为一种非常怪异的语言，因为大家普遍认为动态脚本不应该被强加上类型系统。但现在事实证明 TypeScript 才是正解。感觉现在终端里的 Claude Code，和早年的 TypeScript 在很多方面有着异曲同工之妙。

Boris 32:44
TypeScript 确实在语言设计上做出了一些非常“诡异”的决定。如果你研究过它的类型系统，你会发现几乎任何东西都可以变成字面量类型（Literal Type）。这极其离谱，因为哪怕是像 Haskell 这样纯正的函数式语言都不会这么干，这太极端了。它甚至还有条件类型（Conditional Types），在此之前，这几乎是任何编程语言想都不敢想的概念。

Diana 33:05
是的，它是一种非常强势的强类型。

Boris 33:06
没错，类型限制极其严格。当 Anders Hejlsberg、Jonathan Turner 和早期团队在构建 TypeScript 的时候，他们的核心思路是：“好吧，现在有很多团队拥有着庞大的、没有类型约束的 JavaScript 屎山代码库。我们必须把类型系统引入进去。但我们绝不能指望工程师们去改变他们一贯的代码编写习惯。”

你不可能指望 JavaScript 程序员像 Java 程序员那样，去搞出 15 层的类继承关系。他们依旧会按自己的方式写代码：大量使用反射、随意修改状态变异（Mutation），疯狂使用那些传统意义上极难添加类型约束的动态特性。

Diana 33:36
在那些硬核的函数式程序员眼里，这些全都是极不安全的类型操作。

Boris 33:39
对极了，完全正确！所以 TypeScript 团队的破局之道是：他们并没有去强行扭转人们写代码的习惯，而是围绕着我们现有的这套开发习惯，量身定制了一套极其复杂的类型系统。

这简直是天才之举。其中很多奇思妙想连学术界的人都未曾涉猎，纯粹是在实战中观察 JavaScript 程序员到底想怎么写代码，硬生生逼出来的。

所以，回到 Claude Code 上，两者其实有着相似的内核。比如，你可以像使用 Unix 工具一样使用它：你可以把数据管道输入给它，也可以把它的输出通过管道传输给别人。从某些层面看，它确实非常严谨；但在更多层面，它就只是一个我们极其渴望拥有的纯粹工具而已。我最初只是为了满足自己的需求造了个小工具，然后团队成员觉得好用也跟着用，接着在 Anthropic 内部风靡，最终走向了所有用户群。它就这样变得不可或缺，它绝不是什么刻板的学术派产物。

Diana 34:27
事实胜于雄辩。时间快进到 15 年后的今天，我们发现没多少代码库是用更偏学术的 Haskell 写的了；相反，满世界都是更加实用主义的 TypeScript 代码库，对吧？这确实很耐人寻味。

Boris 34:43
是的，非常有趣。这说明 TypeScript 真正解决了痛点。

Diana 34:45
还有一件很酷的事不知道大家清不清楚，Claude Code 实际上是市面上最惊艳、最漂亮的终端应用之一，而且它是用 React 终端库（React Ink / React Terminal）编写的。

Boris 34:57
当我最初开始开发它时——你也知道，我以前做过一段时间的前端工程师，我也算是个介于设计和用户研究之间的“杂家”，既会写点代码也会干点别的。我们团队特别喜欢招募这样的“大通才”。所以我的出发点就是：“既然我要在终端里做个东西，而我本人又是那种菜得抠脚的 Vim 用户，那我该怎么为像我这样、要在终端里干活的人，打造一个好用的工具呢？”

我认为“体验上的愉悦感”极其重要。这应该也是你们 YC 经常布道的理念吧？如果一个产品很有用，但你用起来感受不到任何乐趣甚至讨厌它，那绝对是不及格的。它必须兼具实用和让人爱不释手这两个特点。

为终端做设计老实说很难。因为你的画布只有区区 80 乘 100 字符那么大，只有可怜的 256 种颜色，字体大小被锁死，没有鼠标交互。有太多的先天限制，迫使你必须做出极其艰难的权衡。
不过告诉你们一个小秘密，其实你可以在终端里启用鼠标交互功能，让它可以被点击。

Jared 35:53
哦？那在 Claude Code 里怎么开启？我一直想摸索怎么弄。

Boris 35:56
我们并没有把它放进 Claude Code 里。我们其实内部做了好几个原型，但发现体验极其糟糕。因为它的代价是你必须做虚拟滚动（Virtualized Scrolling）。这会导致一系列让人抓狂的权衡问题，因为终端系统里根本没有 DOM 树的概念。它有的只是老掉牙的 ANSI 转义码，以及自上世纪 60 年代以来就如同野草般自由生长的各种怪异规范。

Garry 36:14
这种感觉简直就像是在玩早期的 BBS，就像那些古老的 BBS 文字挂机游戏（Door Game）一样。我的天啊。

Boris 36:18
哈哈，这对我来说是极大的赞美。你是不是有一种在不断发掘新大陆的感觉……

Garry 36:22
就像当年的《红龙传奇》（Legend of the Red Dragon）一样，太赞了！我的天。

Boris 36:25
但正因如此，我们不得不在这片荒原上重新摸索出一整套针对终端的 UI/UX 设计准则。因为根本没人系统性地写过关于现代终端交互的教程。如果你去看看 80 年代、90 年代或者 2000 年代那些用 ncurses（终端 UI 库）写的重量级终端应用，它们有着各种复杂的窗口和边框，但以现代的审美标准来看，它们显得摇摇欲坠、过于笨重且极其反人类。

所以我们必须大量地进行重新发明。举个例子，仅仅是终端里那个表示正在加载的转圈小图标（Spinner），到现在可能已经迭代了 50 到 100 个版本了。其中有 80% 根本就没有上线。我们试了一个，感觉不对，马上换下一个；再试一个，还是不对劲，继续换。

这也是开发 Claude Code 最不可思议的优势之一：你可以以极其夸张的速度编写原型。你可以一口气写出 20 个截然不同的原型，对比一下自己最喜欢哪个，然后直接上线那个。这整个过程只需要短短几个小时。如果是在过去，你可能需要用 Origami 或 Framer 这种工具，吭哧吭哧搞两个星期，才能勉强憋出 3 个原型，耗时漫长得令人绝望。而现在我们拥有了这种极致的奢侈：我们需要去探索一片无人区，我们不知道最终的终点在哪里，但我们可以通过疯狂地高频迭代，迅速逼近正确答案。

这正是让一切变得无比轻松的秘诀，也是让我们能够打造出一款让人们感到愉悦、爱不释手的产品的原因。

Jared 37:32
你刚才好像还有一些给开发者的其他建议要分享，抱歉我们总是打断你，因为我们实在是有太多问题想问了。

Boris 37:45
好的没问题。我接下来要给出的两条建议可能听起来有点“反常”，因为它们全都是关于如何“为模型而开发”的。

第一点我之前提过：不要为今天的模型开发产品，要为 6 个月后的模型开发产品。这听起来很扯淡对吧？因为如果你的产品在当下根本没法用，你怎么去寻找 PMF（产品市场契合度）呢？但实际上，这恰恰是你最应该做的事情。否则会发生什么呢？你拼死拼活干了一堆活儿，终于在当下的模型能力上找到了产品的 PMF，然后几个月后，你就眼睁睁地被那些基于下一代模型做开发的人降维打击（Leapfrog）了。

新模型每隔几个月就会发布一次。你应该做的是：去透彻地使用模型，去不断试探它能力边界的极限在哪里，然后大胆地为你预判 6 个月后才会出现的模型能力去设计产品。

Boris 38:15
第二点建议，我们在 Claude Code 团队的办公区墙上，郑重其事地挂着《苦涩的教训》（The Bitter Lesson）的装裱副本。这是 Richard Sutton 写的旷世之作，如果没读过，我强烈建议每个人都去读一读。它的核心论点是：更通用的模型，最终一定会永远击败那些过度定制化的专用模型。这句话可以引申出很多推论，但归根结底浓缩为一句话：永远不要和模型作对（Never bet against the model）。

Boris 38:42
所以我们在思考如何给 Claude Code 添加新功能，如何把它变得更好的时候，总是会评估这种被称为“脚手架”（Scaffolding）的工作。所谓脚手架，就是所有那些我们手写的、不属于模型本身的代码。我们面临一个抉择：我们是选择现在就投入大量的工程人力，去给模型拉个偏架，勉强在雷达图的某个维度上帮它提升 10% 到 20% 的性能；还是干脆什么都不做，等上几个月，让下一代模型顺理成章地、完美地解决这个问题？

你必须时刻带着这种“权衡”思维：你的工程资源究竟该砸在哪里？并且你应该在心里预设好：你今天写下的所有脚手架代码，迟早有一天都会变成废纸。

Diana 39:15
那这绝对经受住了考验。你们重写 Claude Code 代码库的频率有多高？是按照这种理念，每六个月就重写一次吗？

Jared 39:23
是不是有很多脚手架代码已经被你们删掉了，因为模型能力已经突飞猛进，根本不需要它们了？

Boris 39:26
没错。现在的 Claude Code 已经被重写、重写、重写、再重写了无数遍。我们每隔几周就砍掉旧工具，然后加上新工具。在如今的 Claude Code 里，没有哪怕一行代码是 6 个月前留下的。它处于一种永动机般的持续重写状态中。

Diana 39:41
也就是说，现在 Claude Code 超过 80% 的代码库，实际上都只有几个月的寿命？

Boris 39:48
是的，绝对是的。甚至可能连几个月都不到。

Diana 39:52
这听起来很合理。所以这也是今天放送的另一个大招（Alpha）：在今天，你要做好心理准备，代码的保质期现在只剩下短短几个月了。

Garry 39:59
想了解最深度的内幕，一定要去看 Steve Yegge 写的那篇关于在 Anthropic 工作有多爽的博文。我记得他在文章里写了极其炸裂的一句话：目前 Anthropic 工程师的人均生产力，是谷歌鼎盛时期一名谷歌工程师的 1000 倍。这真的是个让人胆寒的数字，老实说。就在三年前，我们还在吹捧“10 倍工程师”，现在居然直接飙到了谷歌巅峰工程师的 1000 倍！这简直难以置信。

Boris 40:30
是的。如果你看我们内部，所有的技术岗员工每天都在深度使用 Claude Code；甚至连非技术员工也是如此，比如销售团队大概有一半的人也在用，不过他们最近开始转而使用 Computer Use（计算机控制）功能了，因为那个更好上手，而且是在虚拟机里运行的，安全隔离做得更好。

我们最近刚拉了一波数据：去年我们的团队规模扩大了一倍，但以最简单（也最粗暴）的指标——也就是提交的 PR 数量来衡量，每位工程师的个人生产力居然还飙升了大概 70%。当然我们也会交叉对比代码的存活周期之类的其他指标。而自从 Claude Code 问世以来，Anthropic 工程师的人均生产力已经暴涨了 150%。

我的天啊！要是在我以前的职业生涯里——我以前在 Meta 是负责整个公司代码质量的，我要管辖包括 Facebook、Instagram、WhatsApp 等所有产品的庞大代码库质量。当时我的团队还有一个核心任务就是提升研发效能。在那个年代，要想让工程师的生产力提升哪怕区区 2%，那都需要数百人苦熬整整一年的心血。而现在这动辄 100%、150% 的暴涨，绝对是闻所未闻的奇迹。

Garry 41:35
是什么驱动你加入 Anthropic 的？我的意思是，作为一个顶尖的创造者，你完全可以去世界上任何一家公司。是在哪一个瞬间，让你下定决心：“这就是我想共事的一群人，这就是我要去的地方”？

Boris 41:45
那时我正在日本的乡村隐居，我每天早晨醒来都会刷一刷 Hacker News。看着上面的新闻，不知从什么时候起，全世界的焦点突然全变成了 AI。我也开始试用一些极早期的 AI 产品，我记得第一次用的那几次，我简直连呼吸都要停止了——虽然这话听起来有点矫情，但这真的是我当时的切身感受。作为一个永远都在写代码的创造者，在使用那些极其早期、稚嫩的产品时（大概还是 Claude 2 那个时期），我体会到了一种前所未有的震撼。

于是我开始联系在 AI 实验室工作的朋友们，想探听一下前线到底在发生什么。我碰巧认识了 Ben Mann（Anthropic 联合创始人之一），他仅仅跟我聊了一次，就瞬间把我折服了。当我后来见到了 Anthropic 的其他团队成员时，我更是被彻底征服了。

Boris 42:34
我想这种吸引力主要来自两个方面：
首先，它的底层基因依然是一家极其纯粹的科研实验室。当时 Anthropic 的产品化工作微乎其微。他们真正在乎的唯一准则，就是打造出一个绝对安全的模型，这才是压倒一切的核心。在做了那么多年的商业化产品之后，这种“无限贴近最底层的核心模型”、“不在乎世俗的商业产品开发，因为模型本身才是皇冠上的明珠”的硬核科研氛围，深深地击中了我。

Boris 42:59
第二点，就是这群人那种近乎执拗的使命感。我是个狂热的科幻小说迷，我家书架上塞满了各种科幻巨著，所以我比任何人都清楚，这玩意儿如果失控，会招致多么恐怖的结局。当我去设想今年乃至未来将会发生什么时，我知道世界必将陷入疯狂。如果在最坏的情况下，事情会滑向万劫不复的深渊。所以我迫切地希望，能置身于一家真正懂得敬畏、真正把人类命运内化于心的公司。

在 Anthropic，你如果在茶水间或者走廊里偷听大家的闲聊，你会发现人们天天都在谈论 AI 安全。在这里，安全绝不是一句公关口号，而是每个人发自内心最关切的事情。我想待在一个这样的地方，对我个人而言，这种使命感重于泰山。

Boris 43:37
那么今年到底会发生什么？让我们把时间拨回 6 个月前，看看大家当时的预测是什么。Dario 曾预测 Anthropic 90% 的代码都将由 Claude 编写。对于我个人而言，这个预测已经成真了，实际上自从 Opus 4.5 以来，这个数字对我来说已经是 100%。我直接卸载了我的 IDE，我一行代码都不手敲了，百分之百纯靠 Claude Code 和 Opus 模型。我每天就这样极其稳定地提交 20 个 PR。如果看 Anthropic 整体的数据，这个比例大概在 70% 到 90% 之间，具体取决于不同的团队；而对很多团队里的很多人来说，也已经是 100% 了。

Boris 44:15
我记得大概在去年 5 月我们把 Claude Code 设为 GA（正式可用）状态时，我做出了一个大胆的预测：人类很快就不再需要 IDE 来写代码了。当时说出这句话感觉非常疯狂，我甚至能听到台下观众倒吸一口凉气的惊呼声，因为在当时，这听起来简直荒谬透顶。

Boris 44:29
但这背后的逻辑其实极其简单：你只需要去顺着指数级增长的曲线去推演。这种信仰早已深深烙印在 Anthropic 的 DNA 里，因为我们的三位创始人就是那篇著名的“缩放定律（Scaling Laws）”论文的联合作者，他们极其敏锐、极其前瞻地看到了这一切。所以，顺着指数曲线往下推演，这一切就是注定会发生的。果不其然，现在这一切都变成了现实。

如果继续沿着这条指数曲线推演，我认为将会发生的是：“写代码”这件事对所有人来说都将彻底成为历史。而在今天，对于我个人来说，编程这个难题实际上已经被彻底攻克了，并且我认为这种攻克将跨越所有领域，降临到每一个人头上。

Boris 44:57
我认为我们将开始见证“软件工程师”这个头衔的消亡。取而代之的，可能会被称为“建造者”（Builder），或者是“产品经理”（Product Manager）。也许我们会把工程师这个头衔当作某种类似阑尾一样的残迹保留下来，但这群人日常做的事情，绝不再仅仅是敲代码了。软件工程师将会去撰写规范，他们会直接跟用户面对面交流——这种趋势现在已经在我们团队内部初露端倪，工程师变得极其全能（Generalists）。并且我们团队的每一个职能角色都在写代码：我们的产品经理在写代码，设计师在写代码，工程主管在写代码，甚至我们的财务大拿都在写代码！我们即将见证这种全员开发的盛况在世界上每个角落上演。

Boris 45:31
如果说上面描述的这些，还仅仅只是我们顺着现有趋势推演出来的“下限”。那么这个未来的“上限”，说实话，要恐怖得多。
这就涉及到，当模型进化到 ASL-4（Anthropic 设立的第 4 级 AI 安全级别）时会发生什么。现在的模型正处于 ASL-3 级别。而 ASL-4 的定义是：模型获得了“递归自我进化”（Recursively self-improving）的能力。一旦这扇门被推开，我们在发布模型之前就必须跨过极其严苛的门槛和审查。这种极端的上限就是模型开始自我进化，或者出现某种灾难性的滥用——比如有人利用模型去设计生物病毒、发掘并利用零日漏洞（Zero-days）等等。这就是我们现在倾尽全力去防御的噩梦，我们绝不允许它发生。

回首这一路，看到大家是如何疯狂使用 Claude Code 的，真的让我感到无比兴奋，又深感敬畏。我起初真的只是想给自己弄个极客小玩具，没想到它最后居然变成了一个极其有用的东西。这种感觉，太让人惊喜，也太让人心潮澎湃了。

Jared 46:21
我从 Twitter 等外部渠道得来的印象是，大家似乎都是趁着假期出去放松了一下，然后回来突然发现了 Claude Code，接着整个世界就彻底陷入了疯狂的狂欢之中。你个人的感受也是这样吗？你是不是也过了个安逸的圣诞节假期，回来一看：“我去，发生甚么事了？”

Boris 46:37
哈哈，其实整个夏天我都在四处旅行，并且我给自己放了个“编程假”（Coding Vacation），就是在旅行中边玩边享受敲代码的乐趣。那时我也开始重新玩起了 Twitter，因为我早年开发过 Threads，所以一直是 Threads 的老用户，我也想看看其他平台上的人们都在讨论什么。

确实，对于很多人来说，那正是他们第一次被 Opus 4.5 的威力所震撼的节点。但我其实心里早有预期，因为在 Anthropic 内部，Claude Code 沿着那条恐怖的指数曲线已经狂飙突进了好几个月了。现在只是这条曲线变得更加陡峭而已。

如果你现在去看看 Claude Code 的战绩：有数据显示，像 Mercury（初创企业银行）这样的机构里，70% 的初创公司都在选择 Claude 作为他们的首选模型；还有 SemiAnalysis 的研究报告指出，目前全球所有公开代码库的提交（Commits）中，有 4% 是由 Claude Code 生成的。全世界各种各样的公司，从科技巨头到最微型的初创团队都在用它。它甚至还为“毅力号”（Perseverance）火星车规划了行驶路线！

这对我来说绝对是酷到爆炸的事情！我们团队甚至为此专门印了海报，大家都在惊呼：“哇塞，这也太硬核了，连 NASA 都在用这东西！”所以，是的，这让人感到极其敬畏，但同时，这也仅仅是一个宏大时代的序幕。

Garry 47:47
Claude Code 和 Computer Use 之间到底是什么关系？它是 Claude Code 的分支版本吗？是你们让 Claude Code 审视了自己的代码，然后告诉它：“来，给咱们的非技术员工写一份产品需求，保留所有的经验教训”，然后它自己跑了几天开发出来的吗？它的起源是什么？你觉得它会走向何方？

Boris 48:11
哈哈，这应该是我第五次把“隐性需求”（Latent Demand）这个词搬出来了。

其实原因很简单。我们在刷 Twitter 时看到，有个老哥居然在用 Claude Code 去监控他种的西红柿！还有人在用它从一块严重损坏的硬盘里抢救自己的结婚照！甚至有人把它用在极其复杂的金融分析上。
当我们把目光投向 Anthropic 内部时，我们发现每一个设计师都在用它，到了现在，整个财务团队、整个数据科学团队也全都在用它，而且根本不是用来写代码的。这群非技术的员工为了能用上这个神器，不惜跨越千难万险，强行在自己电脑上安装终端环境！

所以我很早之前就意识到我们必须得做点什么了。我们尝试了各种各样的产品点子，最后真正火起来的，就是给 Claude Code 套了一个简单的 GUI 外壳，把它放进了桌面端应用里。就这么简单，它的底层完完全全就是 Claude Code。就是那个一模一样的 Agent。

Garry 48:56
哇哦。

Boris 49:00
是的，Felix 和他的团队主导了这个项目。Felix 本人就是 Electron 框架非常早期的核心贡献者，他把那套技术栈玩得炉火纯青。当他们在一个又一个点子上疯狂实验时，大概只花了 10 天时间就把这个东西做了出来！而且这 10 天里 100% 的代码全都是 Claude Code 自动生成的。写完之后，它感觉就已经完美得可以直接发布了。

当然，面向非技术用户，我们还需要做大量的底层建设。它和面向极客的技术受众有点不一样。比如，非技术版本里所有的代码都必须运行在安全的虚拟机里；有极其严密的防删除保护机制；还有频繁的权限弹窗确认，以及各种用来保护用户安全的强制护栏（Guardrails）。但归根结底，这一步跨越其实是水到渠成的。

Garry 49:32
Boris，真的非常感谢你创造了这个剥夺了我所有睡眠的神器。但作为回报，它让我重新找回了那种作为“创造者”的澎湃激情，让我重新进入了极致的“创始人模式”。这三个星期简直是让人灵魂战栗的狂飙之旅，我都不敢相信自己怎么会从去年 11 月一直硬挺到现在才真正开始用它。非常感谢你能做客我们的节目。感谢你创造的一切。

Boris 49:52
感谢你们的邀请。另外，沙盒模式听起来确实不错。

Garry 49:56
听起来很棒。