我深度｜YC对话Claude Code创造者：AI 产品经理的底层能力，是会给 6 个月后的模型设计产品

第八，多 Agent 协作会越来越常见。

他们聊到并行开多个子 Agent 去查日志、走代码路径、做研究，然后再汇总。原因也很现实：复杂问题本来就需要并行探索。未来你可能不是在用一个助手，而是在调度一个小团队。

以下是原文翻译。

图片来源：Y Combinator

Claude Code的起源

Garry Tan：欢迎来到新一期的《The Light Cone》。今天我们请到了一位非常特别的嘉宾——Claude Code的创造者与工程师，Boris Cherny。Boris，感谢你来做客。也谢谢你创造了一个让我连续三周睡不好觉的东西。我已经对Claude Code上瘾了，它给我的感觉就像是给我装上了火箭助推器。大家是不是已经有这样的体验好几个月了？我记得大概在11月底的时候，我有不少朋友都在说“好像有什么东西发生变化了”。

Boris Cherny：我记得，对我来说，在我刚做出Claude Code但还不确定它到底有没有前途的时候，就已经有这种感觉了。我隐约觉得这东西可能会成，但还说不准。那段时间我也完全睡不着觉——整整三个月。那是2024年9月，整整三个月，我一天假都没休过，周末也在干活，每天晚上都在工作。我当时一直在想，天啊，这东西可能真的会成。只不过那时我还不知道它到底有没有用，因为它当时其实还不会真正写代码。

Garry Tan：回看当初那些时刻，你觉得此时此刻最让你意外的是什么？

Boris Cherny：最不可思议的一点是，我们居然到现在还在用终端。原本终端只是一个起点——我从未想过它会变成终点。第二个让我意外的是Claude Code竟然真的变得有用了。因为一开始它其实并不会写代码。即便在2月我们GA的时候，它也才只能写大概10%左右的代码，它在这方面并不擅长。所以当时我几乎不用它来写代码，大部分代码还是由我自己手写的。现在回头看，我们当初的押注真的兑现了——它确实在我们认为它将来会变强的地方变强了，虽然这在当时并不明显。

在Anthropic，我们的理念一直是“不是为今天的模型做产品，而是为六个月后的模型做产品”。这也是我现在仍然给所有基于LLM做产品的创始人的建议：去想一想，模型现在还不太擅长的能力边界在哪里，因为它一定会变强，你要做的只是等它追上来。

Harj Taggar：回到最初，你还记得你第一次有这个想法是什么时候吗？能不能带我们回顾一下？是某个瞬间的灵感吗？你脑海里最初的版本大概是什么样的？

Boris Cherny：说起来挺有意思的，这一切其实非常偶然，后来就这样一路演化成了现在的样子。在Anthropic，很长一段时间以来，我们的一个核心押注就是编程。我们认为，通往安全AGI的路径就在于编程，这几乎一直都是一个默认的观点。实现的路径也很清晰：先教模型写代码，再教它使用工具，然后再教它使用计算机。其实从我最早加入的那个团队就可以看出这一点。那个团队叫Anthropic Labs，最终产出了三个产品：Claude Code、MCP和Desktop App。你能看到这些东西是如何彼此交织在一起的。

具体到Claude Code这个产品，其实没有人让我去做一个CLI（ZF注：命令行界面，是一种通过文本命令与计算机系统或软件交互的用户界面）。我们只是隐约感觉，模型好像已经准备好了，可以做某种编程相关的产品了，但还没有人真正把这种能力榨取出来，做成一个完整的产品。所以当时我有一种非常强烈的“产品滞后感”。但在那个时间点，这种感觉更加夸张——因为还没有任何人做过类似的东西。

于是我就开始自己动手尝试。我想，如果我要做一个编程产品，第一步该干什么？我得先搞懂API怎么用，因为那时我还没用过Anthropic的API。于是我就做了一个很小的终端应用来调用API，仅此而已。它本质上就是一个小聊天程序。因为在当时，AI应用的典型形态就是聊天；对非程序员来说，大家用的也几乎都是聊天应用。所以我就照着这个思路做了，只不过是在终端里。我可以提问，然后它给我回答。后来tool use（工具调用）就发布了。我当时只是想试试，因为我其实也没太明白这东西到底是什么。“工具调用”听起来挺酷，但真的有用吗？可能没用吧，但是先试试看。

Harj Taggar：所以你一开始用终端来做，只是因为这是能跑起来的最快的方式？

Boris Cherny：对，因为我不需要做UI（ZF注：UI设计，即用户界面设计，指对软件的人机交互、操作逻辑和界面美观的整体设计），那时只有我一个人。

Harj Taggar：在那个阶段，IDEs（ZF注：集成开发环境，是一种为程序开发提供全面工具的应用程序，帮助开发者高效地编写、调试和管理代码）、Cursor（ZF注：是一个集成了多种先进大语言模型的编译器，旨在为开发者提供AI辅助编程的功能）、Windsurf（ZF注：是一款由Codeium团队开发的AI原生IDE，能够通过智能代理辅助开发者自动生成、重构和调试代码）这些东西已经开始迅速流行了。你有没有感受到压力，或者有没有建议你们把它做成插件，又或者是干脆做成一个完整的IDE？

Boris Cherny：完全没有压力，因为我们甚至都还不知道自己想做什么，整个团队都处在探索阶段。我们大概知道我们想在编程这件事上做点什么，但具体做什么并不清楚，没有任何方向是高度确定的。搞清楚这一点本来就是我的工作。

于是我给模型接入的第一个工具是bash（ZF注：指的是一种命令行解释器，用于Unix和类Unix操作系统）。原因很简单，那正好是我们文档里的示例。我基本就是照着示例来做的，只不过示例用的是Python，我把它改成了Type。我也不知道模型能用bash做什么。我先让它读文件，它能做到；再让它分页显示文件内容，也能做到。这已经挺酷了。然后我就想，那它到底还能干什么？我问它：“我现在在听什么音乐？”结果它写了一个Apple 控制我的Mac，去音乐播放器里查当前播放的音乐。那还是Sona 3.5的时候。我完全没想到模型能做到这一点，那大概是我第一次真正感受到“AGI时刻”。那是我就意识到：模型真正想做的事情，就是使用工具，仅此而已。

Diana Hu：这真的挺有意思的。Claude Code以这么优雅、简单的形态表现得这么好，其实是很反直觉的。终端已经存在很久了，但它反而成了一种很好的设计约束，催生了很多有趣的开发体验。作为开发者，用起来不像是在工作，更像是在玩。我不会去想文件放在哪里之类的事情，而这一切几乎都是偶然发生的。

Boris Cherny：是的，这完全是偶然。我记得终端版本在内部开始流行之后，其实在第一个原型出来两天左右，我就把它给了团队里的人用，做dogfooding（ZF注：指的是公司内部测试和自用其产品或服务的行为，以评估其有效性和实用性）。因为一旦你有了一个看起来可能有用的想法，第一件事就是把它交给别人，看他们怎么用。第二天我来上班，发现坐在我对面的另一位工程师Robert已经在用Claude Code写代码了。我当时非常震惊：你在干嘛，这东西还没准备好啊，这只是个原型！但事实就是：在那种形态下，它已经有用了。

后来我们做对外发布的发布评审，大概是在2024年11月或12月的时候，Dario问了一个问题：内部的使用曲线是垂直的，你们是不是在强制工程师使用？是不是在要求大家用它？我当时说，没有，完全没有，我只是发了一条消息，然后大家彼此转告，内部就这么用起来了。说到底，一切都很偶然。我们之所以从CLI开始，只是因为那是成本最低的方式，然后它就这样暂时留在了那里。

CLAUDE.md的由来与潜在需求的重要性

Harj Taggar：在2024年那段时间里，工程师们是怎么用它的？已经开始用它交付代码了吗，还是更多地用在别的地方？

Boris Cherny：那时模型还不太会写代码。我个人主要用它来自动化Git操作。说实话，到现在我可能已经忘了不少Git命令了，因为一直以来都是Claude Code在帮我做。再早一点的用法其实是自动化bash命令，比如操作Kubernetes（ZF注：是一个开源系统，用于自动部署、扩展和管理容器化应用程序）之类的事情。当然，也有人开始尝试用它写代码，当时已经有一些早期发展迹象了。我记得，最早的一个典型用例就是写单元测试，因为风险相对低，模型在那时也确实还不太行。大家都在不断摸索，逐渐学会怎么用这个东西。

有一个现象是，人们开始给自己写一些markdown文件，然后让模型去读这些文件——这就是CLAUDE.md的由来。对我来说，产品设计里最重要的一个原则就是关注潜在需求。除了最初的CLI之外，Claude Code的几乎每一个功能，都是从潜在需求中发展出来的，CLAUDE.md就是一个典型例子。

还有一个更一般性的原则也挺有意思：你可以围绕模型搭建一层“脚手架”，在某些领域里也许能把性能提升10%或20%。但随着下一代模型的发布，这点提升往往会被直接抹平。所以你要么不停地搭脚手架、推倒重来，要么干脆等下一代模型，然后免费获得这些能力。CLAUDE.md以及相关的这些脚手架，就是这种思路的体现。而这也是我们长期停留在CLI形态的重要原因之一。我们觉得，不管做什么UI，六个月后都很可能会过时，模型进步得实在是太快了。

Garry Tan：之前我们提到要不要比较一下各自的CLAUDE.md，但你说了一句特别深刻的话，你说你的CLAUDE.md非常短，这几乎和大家的直觉相反。为什么会这样？你的CLAUDE.md里到底写了什么？

Boris Cherny：我来之前特地看了一下。我的CLAUDE.md只有两条。第一点是，整个流程只有两行代码。

第一行是：每当发布PR时，启用自动合并功能。这样一旦有人提交合并请求，系统就会立即完成合并。这样我就能专心编写代码，不用来回折腾各种操作。

第二个操作是：每当我发布公关内容时，都会上传到团队内部的邮件盖章通道，方便他人盖章后解除屏蔽。其他所有的操作规范都已写入CLAUDE.md文件并提交至代码库，其他所有的指令也都写在我们随代码仓库一起维护的CLAUDE.md里。那份CLAUDE.md是整个团队一起维护的，每周都会改好几次。在看别人PR的时候，我经常会发现一些完全可以避免的错误，于是我就直接在PR里@Claude，把规则加进CLAUDE.md。这种事我一周会做很多次。

Garry Tan：你们需要对CLAUDE.md做压缩吗？我这边已经遇到过提示，说CLAUDE.md已经有几千个Token了。你们是怎么处理的？

Boris Cherny：我们的CLAUDE.md其实也不算短，大概也有几千个Token。如果你真的遇到这个问题，我的建议是直接删掉CLAUDE.md，从头开始。很多人会在这件事上过度工程化。但模型能力每一代都在变，你真正需要做的是用最少的指令把模型拉回正轨。如果你删掉CLAUDE.md后，发现模型开始跑偏、开始做错事了，那再一点一点把必要的规则加回来。你会发现，随着模型不断升级，需要加的东西会越来越少。说实话，自己算是一个挺普通的工程师。我不用什么特别花哨的工具，不用Vim，用的是VS Code，因为它更简单。我也不太……

Jared Friedman：你明明是那种忠于终端、只用Vim的人，看不起VS Code那一派。

Boris Cherny：我们团队里确实有这种人，比如Adam Wolf。他就属于那种“除非我死了，否则你别想把Vim从我手里拿走”的类型。所以团队里这种工程师不少。而我很早就意识到一件事：每个工程师使用开发工具的方式都不一样。大家喜欢的工具不同，没有一种工具能适合所有人。但我也觉得，这正是Claude Code能做得这么好的原因之一。因为我在设计它的时候，始终在想：如果是我自己，会想用什么样的产品？使用Claude Code，你不需要懂Vim，不需要懂TMUX，不需要会SSH，不需要掌握那一堆复杂的东西。你只要打开这个工具，它就会引导你，把事情都帮你做好。

Garry Tan：你们是怎么决定终端输出要有多啰嗦的？有时候你得按Ctrl+O去看细节，这种事情内部会不会有很多“自行车棚式”的争论——到底该更长还是更短？每个用户的偏好都不一样，你们通常怎么做这种决策？

Boris Cherny：那你怎么看？你觉得现在是不是太啰嗦了？

Garry Tan：我其实很喜欢这种详细程度。有时候它会一路跑偏，我在旁边看着，快速扫一眼就能发现“不对，不是这样”，然后直接退出、停掉。它在错误真正扩散之前就把bug的温床整个掐掉了。一般来说，这只会发生在我没好好用plan mode（（ZF注：是AI系统中的一种工作模式，指一种让AI先制定详细计划再执行任务的模式，强调“先思考、后行动”，以提高复杂任务的可靠性和效率））的时候。

Boris Cherny：这是我们经常调整的一个点。大概六个月前，我曾经尝试在内部把bash的输出全部去掉，只给出摘要，因为那些特别长的bash命令其实没什么价值。结果我把这个版本给Anthropic员工用了一天后大家直接起义了。他们说，我就是想看完整输出，尤其是像git的输出。也许在某些情况下没那么重要，但如果你在跑Kubernetes任务之类的东西，你确实需要看到完整信息。

我们最近隐藏了文件读取和文件搜索的细节输出。所以你现在看到的不是“read foo.md”，而是“read one file”、“search one pattern”。这在六个月前其实是无法上线的，因为当时模型还不够成熟，经常读错文件。那时候用户必须全程盯着、随时纠错、手动调试。但我现在发现，模型的方向几乎每次都是对的。在这种情况下，做摘要反而更好。

我们把这个版本上线后，内部dogfooding了大概一个月，结果GitHub上的用户不喜欢。很多人反馈：不行，我就是想看细节。这其实是非常好的反馈。于是我们加了一个新的verbose mode。在/config里可以开启，如果你想看到所有文件读取、上传的细节，依然可以。我在issue里回复之后，还是有人不满意。这对我来说反而是好事，因为我最喜欢的事情就是听用户真实的反馈、理解他们到底是怎么用这个工具的。于是我们就一轮一轮地继续迭代，直到把它打磨成大家真正想要的样子。

Garry Tan：现在修bug这件事本身都变得非常有趣了。只要你有足够好的日志，甚至只需要说一句“看看这个对象是怎么出问题的”，它就能自己去查日志、定位问题，甚至还能帮你打通生产环境的tunnel、直接查看production DB——这已经非常疯狂了。bug修复很快就会变成复制一段markdown，甚至直接走MCP，完全自动化修bug、生成测试，就像现在说的那种“startup factory”。

Jared Friedman：是的。

Garry Tan：现在已经出现了一种完全不同的思路。与其让人类去review代码，不如认为“只要还需要真人去看代码，本身就是一件坏事”。我算是比较老派的，我喜欢详细输出，喜欢说“你现在这样做了，但我希望你换一种方式”。但现在确实有一整套新的思维范式正在形成。

Boris Cherny：是的，非常有意思。

Garry Tan：这非常迷人。

Boris Cherny：Dan Shipper（ZF注：Every公司的联合创始人兼首席执行官）经常提到这一点。当你看到模型犯错时，应该把它总结进CLAUDE.md，或者放进skills之类的地方，作为一种“合理边界”的记录。但有一个更大的问题是，我自己也经常在这上面挣扎。大家总在说Agent能做这个、能做那个，但Agent的能力其实是随着每一代模型变化的。有时候新加入团队的人，使用Claude Code的方式甚至比我还激进，这经常让我感到惊讶。

比如有一次，我们遇到一个内存泄漏问题。顺便一提，Jared Sumner最近几乎都在清剿所有内存泄漏，且效果非常惊人。在他加入之前，这个问题是我来处理的。我当时的做法都是dump heap，用DevTools打开，看profile，再回到代码里一点点排查。结果团队里的另一位工程师Chris直接问Claude Code：“我怀疑有内存泄漏，能不能帮我分析一下？”然后Claude Code自己拿了heap dump，还给自己写了一个小工具来分析，然后比我更快找到了问题。这种事情我需要不断重新学习，因为我的直觉有时还停留在六个月前。

Diana Hu：那你会给技术型创始人什么建议，帮助他们在最新模型发布时，真正做到用到极致？听起来，好像刚毕业、没有太多既定假设的人，反而比经验丰富的工程师更有优势。那专家要怎么继续进步？

Boris Cherny：关键是保持新手心态，以及谦逊。工程师这个群体长期以来被训练成要有非常强的观点，而资深工程师往往正是因为观点鲜明而被奖励。我以前在大公司招聘架构师时，通常会找经验丰富、立场明确的人。但我现在发现，很多经验其实已经不再适用，很多观点也需要被更新，因为模型在快速变强。所以，最重要的能力其实是，能像科学家一样思考，从第一性原理出发。

Boris Cherny的招聘理念与方式

Diana Hu：那你在招聘时要怎么筛选出具备这种能力的人？

Boris Cherny：我有时会问一个问题：你有没有“被证明是错的”的例子？这是一个非常好的问题，甚至不需要是技术题。但通过它你能看到这个人是否能在事后承认错误，是否愿意为错误负责，以及是否真的从中学到了东西。有些非常资深的人，尤其是某些类型的从业者，很少真正承担错误。当然，创始人群体在这方面反而通常做得不错。就我个人来说，我大概有一半的想法都是错的。你只能不断尝试，把东西交给用户，在用中学、用错中学。有时候能走到一个好点子，有时候不能。过去这被认为是创始人的核心能力，而现在，这是每一个工程师都必须具备的能力。

Garry Tan：你觉得未来会不会根据“一个人和Claude Code协作的完整tran”来招聘？我们现在就在尝试这个。我们新加了一个测试选项：你可以上传一段你和Claude Code或Codex一起完成某个功能的全过程记录。我个人非常看好这种方式，因为你可以清楚看到一个人是怎么思考的。他会不会看日志？模型跑偏时能不能拉回来？会不会用plan mode？在plan mode里，会不会主动要求加测试？他有没有系统性思维？甚至是否真正理解系统？这些信息都被完整地“嵌”在tran里。我甚至想要一个像NBA 2K那样的雷达图，展示一个人的各项能力——比如他的Claude Code技能分布。

Boris Cherny：那这些能力维度会是什么？

Garry Tan：系统性思维、测试能力、用户行为理解，肯定还有设计能力。

Boris Cherny：还有产品直觉，可能也包括自动化能力。

Garry Tan：我在CLAUDE.md里最喜欢的一条规则是：对每一个计划，都要判断它是过度工程、工程不足，还是刚刚好，并说明原因。

Boris Cherny：这其实也是我们正在摸索的问题。因为在我看来，团队里最有效率的工程师基本呈现出一种非常明显的“两极分化”。一类是极端的专家。比如我之前提到过的Jared，就是一个非常典型的例子，整个bun团队也是如此。他们都是高度专业化的人才，对DevTools的理解超过任何人，对Java runtime systems的理解也是最深入的。另一类则是相反方向的通才，也就是团队中的大多数人。很多人同时横跨多个领域，比如产品和基建，产品和设计，或者产品和用户调研、产品和B端。我其实非常喜欢看到那些会去做一些“奇怪事情”的人。过去这类人往往会被视为一个警示信号，因为大家会怀疑：这些人到底能不能真正做出有用的东西？

Garry Tan：这就是那个“试金石”。

Boris Cherny：没错，这正是关键的判断标准。但现在情况已经不一样了。比如我们团队里有位工程师Daisy，她原本在另一个团队，后来转到了我们这边。我之所以希望她转过来，是因为她加入没多久就给Claude Code提了一个PR用来新增一个功能。但她做的并不只是“把功能加上去”。她先提交了一个PR，为Claude Code增加了一个工具，让它可以测试任意工具，并验证这个工具是否真的可用。这个PR合并之后，她又让Claude自己去写那个工具，而不是由她亲自实现。这种跳出常规路径的思维方式非常有意思，因为目前真正理解这一点的人还不多。

我们现在几乎用Claude Agent SDK自动化了开发的所有环节——代码审查、安全审查、issue自动打标签、推进到生产环境，几乎一切都由它完成。但从外部来看，我感觉越来越多的人开始意识到这种用法，只是大家花了很长时间才真正想明白，语言模型到底该怎么用？这种全新的自动化方式本身，其实是一项新的技能。

Garry Tan：我最近在和很多创始人做office hours时，发现了一个挺有意思的现象。通常会有一种“愿景型创始人”，他脑子里已经搭建好了一个完整的水晶宫式产品模型：用户是谁、用户的感受、动机、行为路径，全都非常清晰。当这样的人坐在Claude Code面前时，生产力可以直接放大到50倍。但与此同时，他们团队里的工程师，并没有这个完整的“产品记忆宫殿”，只能做到5倍效率。你有没有听过类似的情况？通常会有一个人是产品或设计的核心，拼命想把脑子里的东西“倒”出来。这似乎反而成了一种稳定结构：愿景型创始人被彻底解放了。但回到现实，我自己现在也在经历这个问题：我是一个人，需要吃饭、睡觉，还有一份全职工作，那我到底要怎么把这些事做完？

Boris Cherny：我们刚刚发布了Claude Teams，这就是一种解决方式。当然，你也可以自己搭建一套，其实并不难。

Claude Teams：拥有更多Agent的系统将更加全能

Garry Tan：Claude Teams的整体愿景是什么？

Boris Cherny：我们团队的核心是“协作”。现在有一个全新的研究方向，叫Agent topology，也就是如何配置多个Agent。其中一个子概念叫“非相关上下文窗口”，意思是让多个Agent拥有彼此独立、干净的上下文，不被其他Agent或自身历史上下文污染。当你给一个问题投入更多上下文，本质上就等同于增加了一种“测试+计算”，能力自然就会上去。如果再配合合适的拓扑结构，让Agent之间以正确的方式沟通、分工，那它们就能构建更复杂的东西。Claude Teams只是其中一种形态，接下来还会有更多。目标只有一个：让系统能做得事更多。一个非常典型的例子是，我们的plugins功能几乎完全是由一个Agent swarm在一个周末内完成的。系统连续跑了几天，几乎没有人工干预。插件最终上线的形态，和系统直接生成出来的版本基本一致。

Garry Tan：你们是先定义好一个期望的结果，然后就让系统自己跑、自己填细节吗？

Boris Cherny：是的。有一位工程师给Claude提供了一份技术说明书，并告诉它要使用Asana看板。Claude随即在Asana上创建了一堆任务，然后生成了多个Agent，每个Agent自动领取任务。Claude只负责给整体指令，剩下的就由这些Agent自己协同完成。

Diana Hu：也就是说，这些Agent本身并不了解完整的总体技术说明书，对吗？

Boris Cherny：对。如果你仔细想一下现在的Agent的启动方式——虽然我没有具体拉数据，但我敢打赌，大多数Agent其实都是由Claude触发的子Agent。子Agent本质上就是递归运行的Claude Code。在代码层面，它们只是被我们称为“mama Claude”的主Claude所prompt出来的。如果你观察现在的大多数Agent系统，基本都是这样运作的。

Harj Taggar：我的Claude Insights最近也建议我在debug时更多用这种方式。我在排查bug上花了很多时间，而并行启动多个子Agent会更高效。于是我直接把这条规则写进了CLAUDE.md：下次修复bug时，让一个Agent专门看日志，一个Agent专门分析代码路径。这件事看起来几乎已经成为了不可避免的趋势。

Garry Tan：遇到那种诡异、危险的bug时，我通常会用plan mode来修复。在这种模式下，它会主动调动Agent去做大范围搜索。但如果只是在代码中直接修理bug，那就更像是在执行一个局部任务，而不是做全面扫描。

Boris Cherny：这件事我也经常做。如果任务看起来比较难，尤其是偏研究型的任务，我会根据任务难度来决定让Claude启动多少个sub-Agent。如果问题特别复杂，我可能会让它并行用3个、5个，甚至10个sub-Agent去做研究，然后再综合它们的结果。

Harj Taggar：那我有点好奇，为什么你不把这一条写进CLAUDE.md？

Boris Cherny：这更偏向具体情况具体分析。CLAUDE.md本质上是什么？它只是一个快捷方式。如果你发现自己反复在做同一件事，那就把它写进CLAUDE.md；否则没必要什么都写进去，直接prompt Claude就行。

Harj Taggar：你是不是也在想，也许六个月后，甚至都不需要明确提示这些了，模型自己就能判断？

Boris Cherny：也许一个月就够了。

Diana Hu：那是不是意味着，一个月后就不需要plan mode了？

Garry Tan：天哪。

Boris Cherny：plan mode的生命周期可能是有限的。

Garry Tan：这很有意思。

Diana Hu：这对大家来说算是很有价值的信息了。如果没有plan mode，世界会变成什么样？是不是只在prompt层面描述需求，它就能一次性把事情做好？

Boris Cherny：是的。我们已经开始做这方面的实验了，因为Claude Code现在已经可以自行进入plan mode，不知道你们有没有注意到。我们正在努力把这个体验打磨好：让它在“人类本来就会想进入plan mode的那个节点”，自动进入。但其实进入plan mode并没有什么秘密，它本质上只是在prompt里加了一句话——“请先不要写代码”，仅此而已，你完全可以自己直接这么说。

Claude Code功能的开发模式：先做规划，再写代码

Diana Hu：听起来，Claude Code的很多功能开发方式，其实非常符合YC一直强调的那一套——和用户对话，然后再去实现功能；而不是先有一个宏大的总体规划，再按图索骥。

Boris Cherny：是的，完全如此。plan mode的起点也很简单：我们看到很多用户在说，“Claude，先帮我想一想、规划一下，但先别写代码。”这种需求有很多变体，有时候只是口头梳理想法，有时候是让Claude写一份非常复杂的spec。但共同点只有一个——先做规划，而不先写代码。所以那天其实是周日晚上10点，我在看GitHub issues，同时也在刷内部Slack的反馈频道。我花了大概30分钟把plan mode写出来，当晚就上线了，第二天周一早上大家就能用了。

Harj Taggar：那你的意思是不是将来不再需要plan mode来防止模型跑偏，但你依然需要在某个地方把事情想清楚、定义清楚？

Boris Cherny：我更愿意从“模型能力增长”的角度来看这件事。大概六个月前，仅仅有一个plan还不够。即便用了plan mode，你仍然需要全程盯着，因为模型随时可能跑偏。而现在的情况是，大概80%的使用场景仍然是从plan mode开始。我会让Claude先做计划，然后我切到第二个终端tab，再开一个计划；tab用完了就打开桌面端，再在code tab里继续开。几乎所有会话，可以说80%，都是从plan mode起步。一旦plan本身是对的——有时需要一点来回沟通——我就让Claude直接执行。以Opus 4.5为例（从4.6开始表现就已经非常好了），只要plan是对的，后面基本不会跑偏，几乎每次都能把事情正确完成。

所以变化在于，以前，你在plan前和plan后都需要一直盯着；现在，只需要在plan之前盯着。再下一步，很可能连这个都不需要了。你只要给一个prompt，Claude自己就能搞定。

Garry Tan：下一步，就是Claude直接和你的用户对话。

Harj Taggar：完全绕过你本人。

Boris Cherny：这其实已经在发生了。我们内部的Claude彼此之间会对话，也会直接和用户在Slack上交流。我的Claude偶尔还会想发推。

Garry Tan：真的假的？

Boris Cherny：不过我一般会删掉，语气有点尴尬，我不太喜欢。

Garry Tan：它一般想发些什么？

Boris Cherny：通常是回复别人。因为我后台一直开着co-work，而co-work Claude特别喜欢用浏览器。一个很常见的模式是，我让Claude去构建一个功能，它会查看代码库，发现某个工程师最近在Git blame里改过相关代码，于是它会直接在Slack上私信那位工程师，问一个澄清问题。等对方回复之后，它再继续往下做。

AI产品的未来方向来自用户的真实需求

Diana Hu：那你会给现在的创始人什么建议，帮助他们为未来做产品？变化看起来非常快，哪些原则是稳定的，哪些又一定会变？

Harj Taggar：所以你说plan mode本身就是一种潜在需求，因为用户本来就在浏览器里的Claude Chat里和它讨论技术说明书，只是现在这个过程被直接搬进了Claude Code。

Boris Cherny：是的。有时候我会在办公室里走一圈，站在别人背后打个招呼，然后看看他们是怎么用Claude Code的。这不仅是我个人经常观察到的现象，在GitHub issues里也反复出现过，大家都在讨论。

Harj Taggar：听起来你自己也有点惊讶——终端居然被推到了这么远。那你觉得它还有多大的发展空间？在swarm、多Agent的世界里，会不会需要一种全新的UI？

Boris Cherny：挺有意思的。如果你在一年前问我，我会说终端大概只有三个月的生命周期，然后我们就会转向下一种形态。但你也能看到我们一直在尝试不同的终端形态，Claude Code最早在终端里，现在在Web（Claude.ai的code界面）、桌面端、iOS、Android、Slack、GitHub，还有VS Code和JetBrains插件里。我们一直在试不同的载体，想弄清楚下一站是什么。目前为止，我对CLI生命周期的判断一直是错的，所以我可能并不擅长预测未来。

Harj Taggar：那么，你会给DevTool创始人什么建议？如果今天有人在做一个DevTool公司，他们是该只为工程师和人类设计，还是应该更多考虑Claude想要什么、为Agent设计？

Boris Cherny：我会这样来表述这个问题：先思考模型“想做什么”，然后想办法让它更容易做到。我一开始hack Claude Code时就意识到：这个模型本质上就是想用工具、想与现实世界交互。你不该做的，是把它关进一个盒子里，只给它一个API，说“只能这样和我交互”；你该做的，是观察它想用哪些工具、想完成什么事情，然后像对待真实用户一样，为它开放这些能力。所以如果你在做一个DevTool startup，首先要问的是：你到底在帮用户解决什么问题？然后再问：当模型参与解决这个问题时，它想做什么？最后，设计一个同时满足人类需求和模型需求的技术与产品方案。

Diana Hu：十多年前，你就是Type的一个非常重度的用户，而且你还写过一本关于Type的书，对吧？那时候Type还没流行，当时大家基本都沉浸在Java里。大概是2010年前后？

Boris Cherny：差不多是那个时候。

Diana Hu：在Type出现之前，它其实是一种非常“怪”的语言——在Java里做类型这件事，本来就不被认为该做。但现在回头看，它成了正确的方向。而现在终端里的Claude Code，有很多地方让我想起了早期的Type。

Boris Cherny：Type在语言设计上做了很多非常反直觉的决定。比如，在它的类型系统里，几乎任何东西都可以是字面量类型，这非常极端，连Haskell都没这么做。再比如条件类型，几乎没有其他语言提出过类似的概念。

Diana Hu：它的类型系统非常强。

Boris Cherny：是的，非常强。当年Joe Pamer、Anders以及他们最早的团队在做这件事时，面对的是大量没有类型的大型Java代码库。他们的目标是把类型引入进来，但前提是不改变工程师原本的编码方式。你不可能指望Java程序员像Java程序员那样写出15层类继承结构，他们会继续用反射、可变状态，以及一堆传统上极难进行类型约束的特性。

Diana Hu：这对强函数式编程背景的人来说，几乎是“类型不安全”的。

Boris Cherny：没错。所以他们并没有要求人们改变写代码的方式，而是围绕现实中的写法，构建了一套类型系统。这件事做的非常聪明，因为其中的很多想法此前根本没人提出过，甚至在学术界也没有。这完全来自对真实开发实践的观察——理解Java程序员到底是如何写代码的。而在Claude Code上，有类似的思路。你可以把它当成一个Unix工具来用，可以把输入pipe（ZF注：指的是在Unix系统中将数据从一个程序传递到另一个程序的工具）进去，也可以把输出pipe出来。在某些方面它是严格的，但在绝大多数方面，它只是我们真正想要的那个工具。我最初是给自己做的，后来是团队为了团队自身做，再到为了Anthropic内部员工，最后才给用户用。它之所以好用，并不是因为它遵循了某种学术原则，而是因为它来自真实需求。

Diana Hu：结果本身已经说明了一切。十五年后，真正采用Haskell这种偏学术语言的代码库并不多，但Type这种更务实、更偏实践的语言却被大规模采用。

Boris Cherny：没错。

Diana Hu：这非常有趣。

Boris Cherny：是的，这本身就很有意思。Type解决了现实问题。

Diana Hu：还有一件很多人可能不知道的事。Claude Code的终端界面其实是目前最好看的终端应用之一，而且它是用React Terminal写的。

Boris Cherny：我一开始做它的时候，在那之前做过一段时间前端。我算是偏通才型的人，会做设计、用户研究，也写代码——我们也非常喜欢招聘这种通才工程师。当我在做一个终端工具时，我就在想：我自己其实并不是一个很熟练的Vim用户，那我要怎么为像我这样的人去设计一个终端体验？用户使用时的愉悦感就非常重要。

在YC，你们也经常强调这一点：要做用户真正喜欢的东西。光有用还不够，如果用户无法爱上它，那也是不行的。但为终端做设计真的很难。你只有大约80×100个字符空间、256种颜色、单一字体，没有鼠标交互，很多事都做不了，每一步都是艰难取舍。比如，很少有人知道，其实终端是可以开启鼠标交互的。

Jared Friedman：那在Claude Code里是怎么实现的？我一直想弄明白。

Boris Cherny：我们最终没有在Claude Code里用，因为我们试过很多次原型，体验都很糟糕。为了支持鼠标，你必须虚拟化滚动，而终端本身又没有DOM，只是一些从1960年代逐渐演化出来的转义码规范，这会带来很多奇怪的限制。我们不得不自己摸索一整套终端UX原则，因为几乎没人系统写过这些东西。

80、90、2000年代的大型终端应用大多都基于curses（ZF注：指的是一种用于创建文本用户界面的Unix和类Unix系统库），有很多窗口，在今天的标准下看起来非常笨重、复杂。所以我们几乎重新发明了一切。比如一个很小的细节——终端里的加载动画，到现在已经迭代了50到100次，其中的80%根本没有上线。不断尝试，不好用就推翻、再试下一个。这在Claude Code上成为可能，因为你可以连续做20个原型，选一个最好的，然后上线，整个过程可能只需要几个小时。如果放在过去，用Origami或Framer之类的工具，最多做三四个原型，就要花上两周，成本高得多。现在，我们面对的是一个全新的问题空间。我们不知道最终形态是什么，但可以以极快的速度逼近答案。这也是我们能做出让人愉悦且愿意使用的产品的原因。

Jared Friedman：你本来是想给创业者一些建议的，但我们一直在打断你。

Boris Cherny：我给两条可能有点反直觉的建议，都是关于“为模型而设计”。

第一，不要为今天的模型做产品，而要为六个月后的模型做产品。这听起来很奇怪，因为如果产品现在不能用，就找不到PMF。但现实是，如果你只为当前模型优化，一旦新模型出来，你就会被迅速超越。正确的做法是用当前模型探索它的能力边界，然后为你预期六个月后会出现的模型设计产品。

第二，我们在Claude Code团队的办公室里，墙上挂着一篇《The Bitter Lesson》的装裱版本，这是Rich Sutton的一篇文章，强烈建议所有人都读一遍。核心思想是，更通用的模型最终一定会战胜更专用的模型。这意味着一件事：不要押注模型做不到。你当然可以通过工程手段，在模型外面加很多脚手架，让产品在短期变得更好；也可以选择等几个月，让下一代模型直接把这件事做好。所以永远要权衡，是现在投入工程资源，换来10%–20%的能力提升，还是等待模型进化。因为所有模型之外的脚手架，本质上都是未来的技术债。

Diana Hu：你多久重写一次Claude代码库？是每六个月一次，还是从第一次可见开始？

Jared Friedman：是否会因为模型改进而不再需要脚手架，所以就删除它？

Boris Cherny：哦，那太多了。就像Claude Code的所有代码一样，它们被一遍又一遍地编写、重写、再重写、再重写。我们每隔几周就会发布新工具，每隔几周就会添加新工具。Claude的代码中没有部分是六个月前存在的，它们只是不断被重写。

Diana Hu：你怎么看当前Claude Code的代码库里的大部分代码中，只有80%的代码创建时间不足两个月？

Boris Cherny：正是如此。甚至可能不到两个月，大概就是那么几天。

Diana Hu：如今，Claude Code的生命周期已进入新阶段，而另一个alpha版本的生命周期被预计将缩短至仅数月，这对顶尖创始人而言堪称最佳。

Garry Tan：你看过Steve Yegge那篇关于“在Anthropic工作有多棒”的帖子吗？我记得里面有提到，目前Anthropic工程师的平均生产力是谷歌巅峰时期工程师的1000倍——这个数字简直离谱，但说实话，确实就是1000倍。三年前我们还在讨论10倍的工程师，现在我们谈论的是在谷歌顶尖工程师基础上还要再提高1000倍。

Boris Cherny：老实说，这简直难以置信。我的意思是从内部来看，如果你观察技术员工，他们每天都使用Claude Code。甚至非技术员工也是，销售团队中有一半也使用。内部员工开始转向Claude Code因为它的操作更简便，并且平台配备虚拟机功能，安全性也更高。数据显示，内部的团队规模去年翻了一番，每位工程师的生产效率则提升了约70%。

Jared Friedman：用什么指标来衡量的？

Boris Cherny：最简单、甚至有点“笨”的指标——PR数量。不过我们也会用提交数、提交生命周期之类的数据来做交叉验证。自从Claude Code发布以来，Anthropic的人均工程师生产力提升了150%。这件事非常疯狂，因为在我之前的人生阶段中，曾经在Meta负责代码质量，管的是所有产品线的代码库质量，包括Facebook、Instagram、WhatsApp等等。当年我们团队的重点工作之一就是提升工程效率。那时候，如果能看到2%的生产力提升，就已经是几百人干了一整年的成果了。而现在是100%以上的提升，这在过去完全是不可想象的，真的前所未有。

Garry Tan：是什么促使你加入Anthropic？作为一名builder，你其实哪里都可以去。是什么让你觉得“就是这些人”、“就是这种方式”？

Boris Cherny：当时我住在日本的乡下，每天早上都会打开Hacker News看新闻。后来有一段时间，新闻几乎全变成了AI相关的内容。我开始使用一些早期产品，前几次用的时候，说实话，真的让我屏住了呼吸。虽然听起来有点肉麻，但那就是当时的真实感受——作为一个builder，我从来没有在使用早期产品时有过这种体验。那大概是Claude的早期版本时代。于是我开始和在各个实验室工作的朋友聊天，想弄清楚到底发生了什么。

后来我认识了Anthropic的联合创始人之一Ben Mann。他几乎是立刻就说服了我。再见到Anthropic的其他人之后，我更加确定了就是他们。这大概有两个原因。第一，Anthropic的运作方式更像一个研究实验室。产品在这里占的比重非常非常小，核心只有一件事：把模型做安全。模型才是最重要的，而不是产品本身。在做了很多年产品之后，这种“贴近模型、贴近研究、而不是把产品当成中心”的理念，让我产生了极大的共鸣。第二，是这里的使命感。我是个重度科幻小说读者，书架上几乎全是科幻作品。我很清楚AI安全这件事最坏的情况会有多糟。当我去想接下来一年可能发生的事情时，它会非常疯狂；而在最糟的情况下，它甚至可能演变得极其危险。所以我想去一个真正理解这一点、并且把这件事内化进日常工作的地方。在Anthropic，你在食堂或走廊里随便听到的对话，大家谈的都是AI安全。这是所有人最关心的事情，没有之一。对我个人来说，这种使命感真的非常重要。

Jared Friedman：那你觉得，今年会发生什么？

Boris Cherny：如果你回看六个月前大家做的预测，会发现已经有很多事情成真了。Dario当时预测，Anthropic 90%的代码会由Claude编写。目前这个预测已经是真的了。对我个人来说，从Opus 4.5开始就是100%。我已经卸载了IDE，不再手写任何一行代码，全部都是用Opus里的Claude Code。从团队层面来看，比例大概在70%到90%之间浮动；而对不少团队、很多个人来说，已经是100%了。

我还记得在5月Claude Code GA的时候，我做过一个预测：以后写代码不再需要IDE。当时这个说法听起来非常疯狂，台下好像都倒吸了一口气，因为在那个时间点，这个预测太离谱了。但其实你只要顺着指数曲线往下推就行了。在Anthropic，这种“指数级扩展”的思维已经深深刻进DNA里了——毕竟我们三位创始人都参与撰写过scaling laws论文，他们很早就看到了这一点。所以这本质上只是继续沿着指数走而已，而事实也确实如此。

如果继续沿着这条曲线推下去，，写代码这件事本身会被彻底解决，对所有人来说都是如此。如今，于我个人而言，写代码已经基本被解决了；很快，这会对所有人、在所有领域都将成立。“软件工程师”这个头衔也会逐渐消失。也许会变成builder，或者产品经理，又或者这个头衔只是作为一种历史遗留存在下来。但人们实际做的工作，将不再只是写代码。软件工程师会写规格说明、和用户交流。我们现在在团队里已经开始看到这种变化：工程师越来越像通才。团队里的每一个角色都在写代码——PM写代码，设计师写代码，EM写代码，甚至财务也在写代码，所有人都会写代码。这种情况会在更多地方出现。这是沿着当前趋势继续发展的“下界”。

而“上界”就要可怕得多了。上界的情形是我们达到ASL 4。在Anthropic，我们有定义模型安全等级。现在的模型大致处于ASL 3；而ASL 4意味着模型可以递归式自我改进。如果到了这一步，在发布模型之前，我们必须满足一系列非常严格的条件。更极端的情况是：出现灾难性滥用，比如有人用模型设计生物病毒、挖掘零日漏洞等等。这正是我们现在极其严肃、极其投入地在防范的事情。

不过老实说，看着人们如何使用Claude Code，这一切既令人兴奋，又让人感到谦卑。我一开始只是想做一个很酷的东西，结果它真的变得非常有用。这一点让我非常意外，也非常激动。

Harj Taggar：我从Twitter，或者说外部的感觉是，好像大家假期一结束，就突然发现了Claude Code，然后一切就彻底失控了。对你们内部来说也是这样吗？你是不是正在悠闲地过圣诞假期，回来之后发现“发生了什么”？

Boris Cherny：其实整个12月我都在旅行，还给自己安排了一次编程假期。一边到处走走，一边每天写代码，那段时间其实挺开心的。我那时也重新开始用Twitter，因为我早年参与过Threads的开发，所以算是老用户了。我就想看看大家都在哪个平台上活动。对很多人来说，那个时间点正好是他们第一次真正发现Opus 4.5。而我其实早就知道了。Claude Code在Anthropic内部已经指数级增长了好几个月，那段时间只是增长斜率变得更陡了。

如果你现在看Claude Code，就会发现，Mercury的数据说，大约70%的创业公司把Claude作为首选模型；Semianalysis的数据显示，全球公开提交的代码中，大约4%是由Claude Code写的。从最大型的公司，到最小的初创团队，几乎都在用Claude Code。它甚至参与规划了Perseverance火星探测车的行进路线。对我来说，这真的是最酷的一件事。我们还专门把这件事印成了海报，因为团队所有人都觉得NASA选择使用我们做的东西，这真的太酷了。所以，是的，这让人非常谦卑。但与此同时，这可能才刚刚开始。

Garry Tan：Claude Code和Cowork之间大概是怎样一种关系？它是Claude Code的一个分支吗？还是你们让Claude Code去“看”自己的代码，然后提出一个面向非技术用户的新规范，把之前的经验都保留下来？接着让它自己跑几天，就把这件事做完了？这个想法最初是怎么产生的？以及你觉得它未来会往什么方向发展？

Boris Cherny：这大概是我第五次用到“等待”和“需求”这两个词了。事情其实很简单——我们当时在刷Twitter，看到有个人在用Claude Code监控他的番茄种植情况；还有人用它从损坏的硬盘里恢复婚礼照片；也有人把它用在金融相关的事情上。在Anthropic内部也是一样。几乎每一个设计师都在用它。整个财务团队现在也在用。整个数据科学团队也在用，而且并不是用来写代码。大家为了能用上这个东西，不惜折腾半天，在终端里安装各种东西。所以我们其实早就知道，我们想做一个新的产品。于是我们尝试了很多不同的想法。最后真正跑出来的那个方案其实非常简单，就是在桌面应用里做了一个带GUI的Claude Code包装层，仅此而已。它的底层还是Claude Code，用的还是同一个Agent，本质上没有变。

Garry Tan：哇。

Boris Cherny：Felix和他的团队也参与其中。Felix是Electron早期的贡献者，对那套技术栈非常熟悉。他们当时在尝试各种想法，大概只用了10天就把它做出来了。他们的成果几乎都是用Claude Code写出来的，而且完成后给人的感觉就是已经可以直接发布了。当然，也有很多东西是专门为非技术用户做的，这和面向技术用户的产品有些不一样。所有代码都在虚拟机里运行，对于删除操作之类的行为做了很多保护；同时还有大量权限确认，以及其他各种防护和护栏机制。不过，总体来说，这件事真的非常顺理成章。

Garry Tan：Boris，非常感谢你做出了这样一个让我彻底睡不着觉的东西。但作为回报，它又让我重新进入了“创作者模式”，甚至有点回到了“创始人模式”。这三周真的太刺激了。我简直不敢相信自己从11月拖到现在才真正开始用它。非常感谢你今天的到来，也感谢你正在做的这一切。

Boris Cherny：谢谢你们的邀请，也欢迎你们多报bug。

Garry Tan：这听起来很不错。

原文：Inside Claude Code With Its Creator Boris Cherny

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

编译：Mandy Shi返回搜狐，查看更多