在 Anthropic，我们的思考方式是：我们不是为今天的模型而构建，而是为六个月后的模型而构建。这实际上仍然是我给那些基于 LLM 做产品的创始人的建议。试着去想想，那个前沿领域是什么——也就是模型今天还不太擅长的地方，因为它迟早会擅长的。
Claude Code 的全部代码已经被一遍又一遍地写、重写、重写、重写。六个月前的 Claude Code 已经没有任何一部分留到现在了。你尝试一个东西，把它交给用户，和用户交流，学习，然后最终你可能会得出一个好主意。有时候也得不出。你心里是否也在想，也许六个月后你就不需要那么显式地写 prompt 了？比如模型会足够聪明，自己就能搞明白？也许一个月就够了，一个月之后就不需要 plan mode 了。我的天。欢迎来到 the light cone 的另一期节目，今天我们有一位极其特别的嘉宾，Boris Churnney，Claude Code 的创造者工程师。Boris，感谢你来参加。感谢邀请。感谢你创造了这个让我连续三周都没睡好的东西。我对 Cloud Code 非常上瘾，感觉就像装上了火箭助推器。你这边呢，这种感觉已经持续好几个月了吧？我想大概是十一月底，我的很多朋友都说好像有什么东西变了。我记得我第一次做出 Claude Code 的时候就有这种感觉了，当时我还不知道自己是不是发现了什么。我觉得好像是发现了什么，然后就开始睡不着觉了。是的。连续三个月都是这样。那是 2024 年 9 月。对，连续三个月。我一天假都没休，周末也在工作，每天晚上都在工作。我当时就想，"天哪，我觉得这可能会成气候。但我还不知道它有没有用，因为它其实还不会写代码。"
如果你回顾从那时候到现在，此时此刻最让你惊讶的是什么？难以置信我们居然还在用终端。那本来应该只是个起点，我没想过那会是个终点。第二点是它居然真的有用，因为一开始它其实不会写代码。甚至到二月份的时候，它大概只写了 10% 的代码之类的。我并没有真的用它来写代码，它那时候还不太行。我大部分代码还是手写的。所以事实上，我们的赌注兑现了，它在我们认为它会擅长的方向上变强了，而这并不是显而易见的。在 Anthropic，我们的思考方式是：我们不是为今天的模型而构建，而是为六个月后的模型而构建。这实际上仍然是我给那些基于 LLM 做产品的创始人的建议。试着去想想那个前沿领域是什么——也就是模型今天还不太擅长的地方，因为它迟早会擅长的，你只需要等待。不过回到最初，你还记得是什么时候第一次想到这个主意的吗？能给我们讲讲吗？是某种灵光一闪，还是你脑子里最早的那个版本是什么样的？你知道吗，很有意思。它完全是意外产物，慢慢演化成了现在这样。在 Anthropic，我觉得对公司来说，押注编程已经很久了，而且押注的是：通往安全 AGI 的路径是通过编程。这基本上一直是我们的理念，而实现路径是：你先教模型编程，然后教它使用工具，再教它使用电脑。你能看出来这一点，因为我加入 Anthropic 后的第一个团队叫 Anthropic Labs 团队，它产出了三个产品：Claude Code、MCP 和桌面应用。所以你能看出这些东西是怎么交织在一起的。我们做的这个具体产品，你知道，没人要求我去做一个 CLI。我们大概知道也许是时候做某种编程产品了，因为模型看起来准备好了，但还没人真正做出一个能利用这种能力的产品。所以当时仍然有一种疯狂的产品能力悬空感。但在那时候甚至更疯狂，因为根本还没人做过这个。于是我就开始到处折腾，我当时想，"好，我们要做一个编程产品。那我第一步得做什么？我得学会怎么用 API，因为我那时候还没用过 Anthropic 的 API。"所以我就做了一个小小的终端应用来调用 API。我就做了这些。那是一个小聊天应用，因为你想啊，当时的 AI 应用，以及现在非程序员用得最多的，不就是聊天应用吗。所以我就做了这个。它跑在终端里，我可以问问题，它给我回答。然后我想是 tool use 功能发布了。我就是想试试 tool use，因为我其实不太明白这是什么。我当时觉得，工具使用挺酷的。但这真的有用吗？可能没什么用。让我试试。你把它做在终端里，只是因为这是最快能跑起来的方式？对。因为我不用做 UI。明白。那时候就我一个人。那时候 IDE、Cursor、Windsurf 正在起飞。你有没有感受到什么压力，或者收到很多建议，比如我们应该把这个做成插件，或者做成一个功能完备的 IDE？没有压力，因为我们甚至不知道自己想做什么。团队当时就是探索模式，你知道，我们隐约知道想在编程领域做点什么，但具体做什么并不明确，没人有足够高的信心。这就是我的任务，去搞清楚。于是我就给了模型 bash 工具。那是我给它的第一个工具，因为我觉得那 literally 就是我们文档里的示例。 我就是直接拿了这个示例。它是 Python 写的，我就把它移植到了 TypeScript，因为我是用 TypeScript 写的。我当时不知道模型用 bash 能做什么。所以我让它读一个文件，它能用 cat 命令显示文件内容，挺酷的。然后我就想，"好，那你到底能做什么？"我就问它，"我在听什么音乐？"它写了一些 AppleScript 来操控我的 Mac，查询我音乐播放器里正在播放的音乐。我的天。而且这是 Sonnet 3.5。而且你知道吗，我没想到模型能做到这个。我觉得那是我第一次感受到 AGI 时刻。我当时就想，"天哪，模型就是想用工具。这就是它想要的。"
这太迷人了。我是说，Claude Code 能以如此优雅简洁的形态运行得这么好，其实挺反直觉的。终端已经存在很久了，而它似乎成了一个很好的设计约束，催生了很多有趣的开发者体验。它不像是在工作，作为一个开发者，感觉就是好玩。我不用去想文件都在哪里，而这一切几乎都是偶然得来的。对，是意外。我记得在终端开始在内部走红之后，说实话，做出第一个原型大概两天之后，我就开始把它交给团队去做内部试用，因为你知道，如果你想到一个点子，而且觉得它有用，你最想做的事就是把它交给别人，看看他们怎么用。然后我第二天来上班，坐我对面的 Robert，也是一位工程师，他电脑上已经跑了 quad code，而且正在用它写代码。我当时就想，你在干什么？这东西还没准备好啊，只是个原型。但确实，在那个形态下它已经很有用了。我记得我们做上线评审、准备把 quad code 对外发布的时候，那是在 2024 年的 11 月或 12 月左右。Dario 当时问：“内部的使用数据图，就像道琼斯指数一样垂直上涨。你们是强迫工程师用的吗？为什么要强制他们？”
我就说：“没有没有，我们没有强制。我只是发了帖，然后大家就在互相传。”说实话，这完全是意外。我们从 CLI 开始，因为这是最省事的方案，它就先在那儿待了一段时间。所以在 2024 年那段时间，工程师们是怎么用的？他们已经开始用它提交代码了吗，还是用在别的地方？当时模型还不太擅长写代码。我个人是用它来自动化 git 操作。我觉得到现在我可能已经把 git 忘得差不多了，因为 cloud code 代劳太久了。不过没错，自动化 bash 命令是非常早期的使用场景，还有操作 Kubernetes 这类东西。也有人开始用它写代码，已经能看到一些早期迹象了。我觉得第一个使用场景其实是写单元测试，因为风险相对低一些，虽然当时模型在这方面还是挺烂的。但大家也在慢慢摸索，想办法怎么用好这个工具。然后我们注意到，大家开始给自己写 markdown 文件，再让模型去读这些文件。QuadMD 就是这么来的。对我来说，做产品最大的原则可能就是潜在需求。在最初的 CLI 之后，这款产品的每一个功能都是基于潜在需求长出来的。quadmd 就是一个例子。还有另一个我觉得挺有意思的原则：你可以为模型本身做优化，也可以在它周围搭脚手架来提升一点性能，具体提升多少要看领域，可能 10% 到 20% 左右，但基本上新模型一出来，这些收益就被抹平了。所以要么你搭脚手架、拿到一点性能提升、然后下次再重搭一遍；要么就等着下一个模型，性能提升白送。quadmd 和这类脚手架就是例子。其实我觉得这也是我们一直留在 CLI 的原因：我们觉得没有任何 UI 能撑过 6 个月还有意义，因为模型迭代太快了。之前我们说要对比一下各自的 cloud MD，但你说了句很深刻的话：你的其实非常短，这跟大家预想的几乎相反。为什么会这样？你的 cloud MD 里写了什么？好，我来之前特意看了一眼，我的 cloud MD 有两条，其实就两行。第一行是：每当我提交 PR，启用 automerge。这样一旦有人通过，代码就自动合并了。这样我就能专心写代码，不用来回搞 CR 之类的。第二行是：每当我提交 PR，发到内部团队的 stamps 频道。这样有人就能快速盖个章，我也能继续推进。思路是，其他所有指令都放在我们签入代码库的 quadmd 里，整个团队每周都会往里面贡献好几次。很多时候我看到别人的 PR 犯了完全可预防的错误，我就直接在 PR 里 @Claude，让它把这条加进 quad MD，我每周都会干好几次。你们会压缩 Claude MD 吗？我肯定是遇到过那种情况，顶部弹出提示说你的 cloud MD 已经几千 token 了。你们遇到这种情况怎么办？我们的 quadmd 其实挺短的，大概也就几千 token 左右吧。如果你遇到这种情况，我的建议是：删掉 quadmd，重新来过。有意思。我觉得很多人容易过度工程化这个事儿，而模型的能力每次更新都在变。所以你要做的是，用最小化的手段让模型走上正轨。如果你删掉 quadmd，然后发现模型跑偏了、做错了，这时候再一点点加回去。而且你很可能会发现，随着模型迭代，你需要加的东西越来越少。说实话，我觉得自己就是个挺普通的工程师。我不爱用花里胡哨的工具，不用 Vim，我用 VS Code，因为它更简单。我也不怎么……
等等，真的吗？我还以为既然你们是在终端里做这个东西，你肯定是那种死硬派终端用户，只用 Vim，看不起 VS Code 那帮人。我们团队确实有这种人，比如 Adam Wolf，他在团队里，他会说“除非我死了，否则你别想从我手里拿走 Vim”。所以团队里这样的人很多。这也是我很早就学到的一点：每个工程师拿开发工具的习惯都不一样，喜欢用不同的工具，没有一种工具能适合所有人。但我觉得这也是 quad code 能做得好的原因之一。我思考的角度是：什么样的产品是我自己会用的、对我有意义的。所以用 quad code，你不需要懂 Vim，不需要懂 TMX，不需要会 SSH，不需要懂那些东西，你只需打开工具，它会引导你，它会帮你搞定这一切。你们怎么决定终端输出的详细程度？有时候你得按 control O 去看，这会不会引发内部那种“自行车棚”式的争论，比如该长还是该短？每个用户可能都有自己的偏好，你们怎么做这类决策？你怎么看？现在是不是太啰嗦了？哦，我很喜欢详细的输出，因为有时候它会往奇怪的方向跑，我在旁边看着，扫一眼就能发现“不对不对，不是这个”，然后按 escape 停下来，就像拦住了一整窝 bug 正在往外冒。当然，这种情况通常是我没正确用 plan mode。这方面我们可能改得挺频繁的。我记得大概六个月前，我试过在内部把 bash 输出干掉，只保留摘要，因为我想那些又臭又长的 bash 命令我也不在乎。结果给 Anthropic 员工用了一天，所有人都在造反。他们想看自己的 dash，因为这其实挺有用的，比如 git 输出可能没那么重要，但如果你在跑 Kubernetes job 之类的东西，你确实想看。我们最近把文件读取和文件搜索的详情给隐藏了。所以你会发现，它不再显示“读了 food.md”这种，而是显示“读了 1 个文件”“搜索了 1 个模式”。我觉得这是我们六个月前无法发布的东西，因为当时的模型还没准备好。要知道，它还是会经常读错内容。作为用户，你还是得守在旁边，去发现和调试问题。但现在我注意到，它几乎每次都能走上正轨。而且因为它现在大量调用工具，其实直接做个总结反而更好。不过后来我们发布了这个功能。我们先内部试用了一个月，结果 GitHub 上的用户不喜欢。于是有个很热门的 issue，大家说"不行，我想看到详细过程"，这个反馈非常棒。于是我们就加了一个新的 verbose mode，你可以在 slash config 里开启，如果你想看到所有文件输出，还是可以继续看。然后我在那个 issue 下面回复了，但大家还是不满意，这再次说明太棒了，因为世界上最让我开心的事就是听到用户的反馈，了解他们到底想怎么用。于是我们就不断迭代，把它打磨好，做成大家真正想要的东西。我很惊讶，我现在居然这么喜欢修 bug。然后你只需要有非常完善的 logging，甚至只要说"嘿，你看看这个特定对象，它这里出错了"，它就会去搜索日志，把所有问题都理清楚。它甚至可以进入你的——你可以搭一个 production tunnel——然后它直接帮你查看线上的生产数据库。这简直不可思议。修 bug 很快就要变成"去 Sentry 复制 markdown"了。很可能不久之后就会完全变成 MCP。就像自动修 bug、自动写测试那种——他们叫什么新词来着——对，startup factory。哦，对。
——对。现在有很多这样的理念，就是说与其必须去 review 代码——你知道，我是老派作风，所以我喜欢 verbosity。我喜欢说"哦，你这么做，但我想让你那么做"。但现在有一种完全不同的思路，认为只要让真人去看代码，那就是件坏事。 ——是啊，是啊，是啊。 ——这很迷人。
——我觉得 Dan Chipper 经常聊这个话题，大致是说，每当你看到模型犯错，就试着把它写进 quadmd，或者写进 skills 之类的地方，这样以后可以复用。但我有个更上层的观点，其实这让我很纠结。人们总说 agents 能做这做那，但实际上 agents 能做什么，每个模型都不一样。所以有时候团队里来了新人，他们使用 Quad Code 的频率甚至比我还高。
——这点总是让我很惊讶。比如说，我们之前遇到过一个内存泄漏，我们一直在排查。顺便提一下，Jared Sumar 最近在全力消灭所有内存泄漏，做得非常棒。但在 Jared 加入团队之前，这事得我来做。当时有个内存泄漏，我试图去排查。于是我打了 heap dump，在 DevTools 里打开，查看 profile，又去看代码，就想把这个问题解决。然后团队里另一位工程师 Chris，他直接去问 Quad Code。他说："嘿，我觉得这里有内存泄漏，你能运行一下这个吗？"然后试着让它去排查。结果 Quad Code 自己拿了 heap dump，写了个小工具来分析这个 heap dump，然后比我更快找到了泄漏点。这是我必须不断重新学习的事情，因为我的大脑有时候还停留在六个月前的状态。
——那对于技术创始人，你有什么建议能让他们真正成为最新模型发布后的极致使用者？听起来像是刚毕业、没有任何先入为主观念的人，有时可能比工作很久的工程师更适合。那专家要怎么进步？我觉得对自己来说，大概是需要初学者心态，还有……怎么说呢，humility。我感觉工程师这个群体已经学会了要有非常强烈的观点，资深工程师往往会因此受到奖励。我以前在大公司工作时，招架构师或者这类工程师，我都会找经验丰富且观点鲜明的人。但事实证明，很多东西现在已经不适用了，很多观点也应该改变，因为模型越来越好了。所以实际上最重要的技能，是那些能够科学思考、能从 first principles 出发思考的人。
——那现在你给团队招人时，怎么筛选这一点？ ——我有时会问，能不能举个例子说说你什么时候错了。这个问题很好。你知道，一些经典的行为面试问题，甚至不是 coding 问题，我觉得挺有用的，因为你能看出一个人事后能不能认识到自己的错误，能不能为错误承担责任，以及有没有从中学到东西。我觉得很多资深人士，尤其是——有些创始人类型的人也会这样，但创始人其实通常挺擅长这个的。但其他人有时候永远不会……永远不会为错误承担责任。不过就我个人而言，我大概有一半时间都是错的。我一半的点子都很烂，你就是得去尝试，尝试一个东西，交给用户，和用户聊，从中学习，最后也许能想出好点子，有时候也想不到。这个技能我认为过去对创始人非常重要，但现在我觉得对每个工程师都很重要。
——你觉得你会根据一个人使用 claude code 与 agent 协作的 transcript 来招人吗？因为我们现在正在这么做。我们刚加了一个测试功能，你可以上传自己用 cloud code 或 codex 之类的东西写功能时的 transcript。我个人觉得这事儿能成。我是说，你能看出一个人的思考方式，比如他有没有去看日志，agent 跑偏时他能不能纠正回来。他们用不用 plan mode？用 plan mode 的时候，他们会不会确保有测试，或者……所有这些不同的事情。 ——你知道，他们有没有 systems 思维？他们到底懂不懂 systems？这里面有太多隐含的东西了。我就想要一个 spiderweb graph，你知道，像 NBA 2K 那种视频游戏里的。比如，这个人投篮或防守特别强。你可以想象一个 spiderweb graph，用来展示一个人的 claude code skill level。
——是啊。那这些技能会是什么呢？具体是哪些？ ——我是说，我觉得可能是 systems、testing，肯定还有 user behavior。应该也得有 design 的部分，比如 product sense，可能还有 automating stuff 之类的。嗯。我在 CloudMD 里最喜欢的一个功能是，我设了一条规则：每个 plan 都要判断它是 overengineered、underengineered 还是 perfectly engineered，并说明原因。
——我觉得这也是我们正在摸索的，因为当我看团队里最高效的工程师时，基本上有两类，非常两极化。一类是极端专家型。比如我之前提到的 Jared，他就是个很好的例子，还有 bun team 也是。就是超级专家。他们对 dev tools 的理解无人能及，对 JavaScript runtime systems 的理解也无人能及。然后是另一面，也就是那些极度全才，而团队里其他人也差不多。很多人横跨产品和信息，或者产品和设计，又或者产品和用户研究、产品和商业。我真的很喜欢看到那些做奇怪事情的人。我觉得这在过去某种程度上是个警示信号，因为你会想：这些人真的能做出有用的东西吗？嗯，那是极限测试。对，这确实是必经的考验。但现在，比如团队里有个工程师叫 Daisy，她原本在别的团队，后来转到了我们团队。我想让她过来的原因是，她入职大概几周后就给 Claude Code 提了一个 PR，本来是要给 Claude Code 加一个新功能。但她没有直接加功能，而是先提了一个 PR，给 Claude Code 加了一个工具，让它可以测试任意工具并验证是否正常工作。提了这个 PR 之后，她让 Quad 自己写工具，而不是她自己实现。我觉得正是这种跳出框架的思考方式非常有趣，因为还没多少人真正理解。你知道，我们用 Quad Agents SDK 把开发的几乎每个环节都自动化了：代码审查、安全审查、给所有 issue 打标签、把项目推进到生产环境，几乎什么都做。但我看到外部也有很多人开始明白过来了，不过大家其实花了很长时间才想清楚怎么这样使用 LMS，怎么使用这种新型自动化。所以这算是一种新技能。说来有点好笑，我最近和各种创始人开 office hours 时经常聊到：有一种有远见的创始人，他脑子里已经建起了一座产品的水晶宫，完全了然于胸——清楚用户是谁、他们的感受如何、驱动力是什么。然后他坐在 Claude Code 里，可以做 50 倍的活。但他手下的工程师没有那种水晶记忆宫殿，没有创始人脑子里产品的柏拉图式理想形态，只能做 5 倍的活。你听到过这样的故事吗？通常会有一个核心设计者，他就是拼命想把脑子里的东西倾泻出来。这种团队的本质是什么？你知道吗，这看起来几乎是一种稳定的配置。那个有远见的人现在被解放了，但也许回到最开始的矛盾——我现在就在经历这个。我当时想：“唉，我只是个单打独斗的人，我还要吃饭睡觉，还有一份全职工作。这…… 我怎么才能做到？” 你知道的。你知道，我们刚发布了 Quad Teams，这也是一种方式，但你也可以自己搭一套方法来做，挺容易的。
Claude Teams 的愿景是什么？就是协作。现在有一整个全新的领域，人们在探索 agent topologies。也就是你能以哪些方式配置 agents。其中有一个子概念叫 uncorrelated context windows。思路是，多个 agent 拥有全新的 context window，不会被彼此的 context 或自己之前的 context 污染。如果你针对一个问题投入更多 context，那就像一种 test time compute。这样你就能获得更多能力。而如果你在这上面有正确的 topology，agent 之间能以正确的方式通信、以正确的方式布局，那它们就能构建更庞大的东西。所以 Teams 只是其中一个想法，还有更多很快会来。思路就是也许它能多构建一点。我觉得第一个真正奏效的大型例子是我们的 plugins 功能，整个周末完全是由一个 swarm 构建的。它跑了几天，几乎没有人工干预。Plugins 发布时的样子和现在基本差不多。你是怎么设置的？是先详细写下你期望的结果，然后让它自己搞定细节，再让它跑起来？对。团队里一个工程师只是给了 Quad 一份 spec，告诉 Quad 用 Asana 看板，然后 Quad 就在 Asana 上创建了一堆 ticket，接着 spawn 了一堆 agents，agents 开始认领任务。主 Quad 只给了指令，然后它们就自己搞定了。就是独立的 agents，没有那个更大 spec 的 context，对吧？对。如果你想想现在我们的 agents 实际上是怎么启动的——我没拉过数据，但我敢打赌现在绝大多数 agents 其实都是由 Quad 来 prompt 的，以 sub agent 的形式。因为 sub agent 本质上就是递归的 Claude Code，代码里就是这样，只是由我们来 prompt，我们叫她 mama Quad。就是这样，而且我觉得如果你看大多数 agents，它们都是以这种方式启动的。我的 Claude Insights 刚才告诉我，调试时要多这么做，因为我花太多时间在调试上了。更好的做法是让多个 sub agent 并行启动，去并行调试某个问题。然后我就把它加到了我的 Claude MD 里，就写：嘿，下次你修 bug 的时候，让一个 agent 看日志，一个看代码路径。这看起来是不可避免的。遇到诡异又吓人的 bug 时，我会试着在 plan mode 里修，然后它似乎会动用 agents 去全面搜索。而如果你只是想直接在线处理，它就像是：好，我要做这个单一任务，而不是广泛搜索。这也是我经常做的事。我会说，如果测试看起来有点难，这种研究性质的测试，我会根据任务难度来校准我让它使用的 sub agent 数量。所以如果真的很难，我会说用三个，或者五个，甚至十个 sub agent，并行研究，然后看看它们能得出什么。我好奇，那你为什么不把这个写进你的 Claude MD 文件里？这要看具体情况，你知道，Quad MD 是什么？它就是个快捷方式。如果你发现自己在重复说同样的话，你就把它放进 Quad MD 里。但除此以外，你不必把所有东西都放进去，你可以直接 prompt Quad。你心里是不是也在想，也许再过六个月，你就不需要显式 prompt 这些了？模型会自己足够聪明地搞定。也许再过一个月。一个月后就不需要 plan mode 了。我的天。我觉得 plan mode 的寿命可能有限。有意思。这是给大家的一点 alpha。没有 plan mode 的世界会是什么样？你只在 prompt 层面描述，然后它就直接做了？一次性搞定？对，我们已经开始实验这个了，因为 Quad Code 现在可以自己进入 plan mode。不知道你们有没有见过。见过。所以我们正在努力把体验做好。它会在人类想要进入 plan mode 的同一个时间点自动进入。我觉得大概是这种感觉，但实际上 plan mode 没什么大秘密，它只是在 prompt 里加了一句话：请不要写代码。[哼笑]
就这样。你其实可以直接这么说。是的。所以听起来 Claude Code 的很多功能开发，非常符合我们在 YC 里说的“去和你的用户聊”，然后你们再来实现。并不是那种你有一个宏伟蓝图，然后把所有功能都实现出来的方式。对，对。我的意思是，plan mode 完全就是这么来的。我们看到用户会跟 Claude 说：“嘿，我有个想法，你先规划一下，但暂时别写代码。” 这种情况有各种版本。有时候只是聊一个想法，有时候是他们让 Claude 写非常复杂的 spec，但共同点都是：先做点事情，但还没开始写代码。所以 literally，就像某个周日晚上 10 点，我在看 GitHub issues，看大家在讨论什么，又看了我们内部 Slack 的反馈频道，然后 30 分钟就写好了这个功能，当晚就 ship 了。周一早上就上线了。这就是 plan mode。所以你的意思是，以后就不需要 plan mode 了吗？我是说，我担心模型会做错事或者朝着错误的方向走，但这个需求还是会存在的。你需要把想法想清楚，明确自己到底想要什么，而且你必须在某个地方完成这个思考过程。我倾向于从模型能力不断提升的角度来思考这个问题。大概 6 个月前，只做计划是不够的。你让 Claude 做计划，但就算用了 plan mode，你还得坐在旁边盯着，因为它可能会跑偏。虽然我觉得 plan mode 迟早会过时，但我自己是个 plan mode 的重度用户。大概 80% 的会话我都会从 plan mode 开始，Claude 会开始做计划。然后我切换到第二个 terminal 标签页，再让它做另一个计划，标签页用完了就打开 desktop app，进入 code tab，再在那开一堆标签，其中大概 80% 也是从 plan mode 开始的。一旦计划没问题了——有时候需要来回沟通几次——就直接让 Claude 去执行。而且现在我发现，用 Opus 4.5 的话，我觉得从 4.6 开始变得特别强。一旦计划没问题，它就会一直保持在正轨上，几乎每次都能准确完成要做的事情。所以，以前你得在计划前和计划后都盯着，现在只需要在计划前盯着就行了。也许下一步就是，你连盯都不用盯了，直接给一个 prompt，Claude 自己就能搞定。下一步就是 Claude 直接跟你的用户对话了。对，它直接绕过你了。有意思的是，这其实就是我们现在正在发生的事。我们的 Claude 会互相交流。它们会在 Slack 上跟用户聊天，至少内部挺常见的。呃，我的 Claude 偶尔还会发推。不会吧。呃，但我基本都会删掉。 就是有点…… cheesy。我不是很喜欢那个语气。它想发什么内容？有时候它会回复别人，因为我后台一直开着 co-work，它特别喜欢干这事，因为它喜欢用浏览器。这挺有意思的。有个非常常见的模式：我让 Claude 做点东西，它会查看代码库，看到某个工程师在 git blame 里改过什么，然后就会去 Slack 上给那位工程师发消息，问个澄清问题，等得到回复后就继续干活。那对于现在的创始人，你对“如何为未来做建设”有什么建议吗？听起来一切都在快速变化。哪些原则会保持不变，什么又将会改变？我觉得有些道理其实非常基础，但现在比以往任何时候都更加重要。比如说 latent demand。这句话我大概说过一千遍了。它是我心目中产品领域最重要的一个概念。这是个几乎没人真正理解的东西，我前几家创业公司时肯定也没搞懂。核心思路是：人们只会做他们已经在做的事。你没法让人们去做一件全新的事。如果人们正在尝试做某件事，你把它变简单了，这就是个好主意。但如果人们正在做一件事，你却试图让他们去做另一件事，他们不会干的。所以你只能把他们已经在做的事变得更简单。而且我觉得 Claude 会越来越擅长帮你发现这类产品思路，因为它能看反馈、看 debug log，它能自己琢磨出来。所以你的意思是，plan mode 就是 latent demand 的体现——人们本来就已经在浏览器里开着 Claude 的聊天窗口，跟它聊来确定 spec 和该做什么。而现在 plan mode 就是把这个过程直接放到了 Claude Code 里。对，对，就是这样。有时候我会在我们那层办公室走动，站在别人身后看 ，我会先打个招呼，免得吓到人家，然后观察他们是怎么用 Claude Code 的。这也是我经常看到的现象，而且 GitHub issues 里也有人提过。所以你很惊讶 terminal 已经走了这么远、被推到这种程度，那你觉得它还能走多远？特别是在 multiple agents 的世界里，你觉得会不会需要一种完全不同的 UI？有意思的是，如果你一年前问我，我肯定会说 terminal 只剩三个月寿命了，然后我们就会转向下一个形态。而且你看我们也在做各种实验，对吧？Claude Code 最初是从 terminal 起步的，但现在它也在 web 上，你可以在网页版用 Claude Code；它在 desktop app 里，我们大概三四个月前或半年前就在 code tab 里有了；它在 iOS 和 Android app 的 code tab 里；它在 Slack 里，在 GitHub 里；还有 VS Code 插件、JetBrains 插件。所以我们一直在为这个东西尝试不同的形态，想找出下一步是什么。但关于 CLI 的消亡，我到目前为止都判断错了。所以这事我可能没法预测。那你对 DevTool 创始人有什么建议？比如今天有人在做一家 DevTool 公司，他们应该继续为工程师和人类做建设，还是应该多想想 Claude 会怎么想、想要什么，然后为 agent 做建设？我会这样表述：去想想模型想要做什么，然后想办法怎么让它更容易做到。这也是我们当初的经验，你知道，当我最早开始捣鼓 Claude Code 的时候，我意识到这东西就是想用工具，它就是想跟世界互动。那你怎么去赋能它呢？错误的做法是把它关在一个盒子里，说：这是 API，这是你跟我交互的方式，也是你跟世界交互的方式。正确的做法是，你看它想用哪些工具，看它在尝试做什么，然后就像你为普通用户赋能那样去赋能它。所以，如果你在做一个 dev tool 初创公司，我会去想：你想为用户解决什么问题？然后当你用模型来解决这个问题时，模型想要做的是什么？那么，能同时承载这两者分量与需求的技术和产品解决方案是什么？YC 下一批项目正在招生。你心里有创业点子吗？去 ycombinator.com/apply 申请吧。永远不会太早，填写申请表本身就能让你的想法升级。好了，回到视频。早在十多年前，你曾是 TypeScript 的重度用户，还写了一本关于它的书，对吧？在 TypeScript 流行起来之前。那时候大家都埋头写 JavaScript。那是 2010 年代初，对吧？对，差不多。
TypeScript 还没火的时候，因为当时的 JavaScript 是一门很怪的语言。它本来就不是为了承载那么多类型系统的东西而设计的，而现在这反而成了正道。而且感觉终端里的 Claude Code 和早期的 TypeScript 有很多相似之处。
TypeScript 做了很多非常奇怪的语言设计决策。比如你看它的类型系统，几乎任何东西都可以是字面量类型，这超级奇怪，因为就连 Haskell 都不这么做。太极端了。或者它还有 conditional types，我觉得没有任何语言想到过这个。它好像是强类型的。对，是非常强类型。核心理念是这样的——你知道，当 Joe Pamer 和 Anders 以及早期团队在做这个东西的时候，他们的构建方式是：我们有一些团队，拥有庞大的无类型 JavaScript 代码库。我们得给它们加上类型，但我们不会让工程师改变他们的编码方式。你不可能让写 JavaScript 的人像 Java 程序员那样搞 15 层类继承，对吧？他们会按自己的方式写代码，会用 reflection，会用 mutation，会用所有这些传统上非常难以添加类型的特性。对任何坚定的函数式程序员来说，这些都是非常不安全的做法。没错，没错，没错。所以他们没有试图让人们改变编码方式，而是围绕这些做法构建了一个类型系统。这太精妙了，因为其中很多想法连学术界都没人考虑过，根本没人想到过这些点子。它纯粹来自观察实践，观察 JavaScript 程序员想怎么写代码。所以，对 Claude Code 来说，有些想法是类似的——比如你可以像用 Unix 工具一样用它，可以 pipe 进去，也可以 pipe 出来。在某些方面它确实挺严谨的，但几乎在所有其他方面，它只是我们想要的一个工具。就像我为自己做个工具，然后团队为自己做，再给 Anthropic 员工用，然后给用户用，最后发现它真的很有用。它不是那种讲究原则和学术性的东西，而我认为结果就是最好的证明。快进到今天，十五年过去了，没多少代码库是用 Haskell 写的，那东西更学术；而现在有海量代码库用 TypeScript，因为它务实得多。对。这很有意思。是啊，挺有意思的，对吧？TypeScript 解决了一个实际问题。我觉得有件事挺酷的，不知道有多少人知道，就是这个终端其实是市面上最漂亮的终端应用之一，而且是用 React Terminal 写的。我刚开始做它的时候，你知道，我做前端工程做了挺长时间。而且我也算是个混合型的人吧，我会做设计、用户研究、写代码，各种事情。我们也喜欢招这样的工程师，我们就喜欢通才。所以对我来说，就是：我要给终端做个东西。其实我 Vim 用得挺烂的。那我怎么才能为像我这样的人——就是在终端里工作的人——做个东西呢？我觉得那种愉悦感特别重要。而且我感觉在 YC 你们也经常讲这个，对吧？就是做一个让人们热爱的东西。如果产品有用，但你不会爱上它，那也不够好。所以得两者兼顾。说实话，为终端做设计挺难的，对吧？比如 80×100 字符之类的限制，只有 256 色，只有一种字号，没有鼠标交互，有很多事你做不了，而且这些权衡非常艰难。比如有个不太为人知的事，其实你可以在终端里启用鼠标交互，可以启用点击之类的功能。哦，在 Claude Code 里怎么弄？我一直想搞清楚怎么 实现这个。我们在 Claude Code 里没有这个功能，因为我们其实做过几次原型，但体验很差，因为代价是你得把滚动虚拟化，所以会有各种奇怪的权衡。因为终端的工作方式就是这样——没有 DOM，对吧？靠的是 ANSI 转义码这类东西，还有从 1960 年代左右就开始有机演化出来的各种奇怪规范。对。感觉像 BBS，就像 BBS door game 一样。天哪。这算是很高的赞美了。对。它就应该给人一种你在探索发现的感觉。
《Lord of the Red Dragon》。太棒了。天哪。对。但我们不得不自己去摸索所有这些构建终端的 UX 原则，因为根本没人写这方面的内容。如果你看 80 年代、90 年代或者 2000 年代那些大型终端应用，它们用 ncurses 之类的东西，有各种窗口和界面。按现代标准看就挺粗糙的，显得太重、太复杂。所以我们不得不大量重新发明。比如终端里的加载动画，就是那个 spinner 的文字，到现在大概经历了 50 到 100 个迭代版本，其中大概 80% 都没发布。我们试了，感觉不对，就换下一个；再试，感觉不对，再换下一个。而这其实就是 Claude Code 神奇的地方之一，对吧？你可以写这些原型，一口气做 20 个原型，看哪个你喜欢，然后发出去，整个过程可能也就几个小时。而过去你得怎么做呢？你得用 Origami 或者 Framer 之类的工具。大概做三个原型，要花两周时间。慢太多了。所以我们有这种奢侈：我们要探索新东西，我们要做个东西出来。我们不知道正确的终点在哪，但我们可以迭代得飞快，这让一切变得很容易，也让我们能做出一个让人愉悦、人们喜欢用的产品。
Boris，你本来还有给开发者的建议，我们一直在打断你，因为我们问题太多了，不过
我想说，嗯，好的，大概有两条有点奇怪的建议，因为是关于为模型做开发的。第一条是，不要为今天的模型做开发，要为六个月后的模型做开发。这听起来有点怪，对吧？因为如果产品现在跑不通，你就找不到 PMF。但实际上这才是你应该做的事，否则你就会先花大量工夫为产品找到 PMF，然后被别人弯道超车，因为他们是在为下一代模型做开发，而新模型每隔几个月就会出来。你要去使用模型，摸清它的能力边界，然后为你认为大约六个月后的那个模型去做开发。我觉得第二点是，实际上在我们所在的 Claude Code 区域，墙上挂着一幅装裱好的《The Bitter Lesson》。这是 Rich Sutton 写的，我觉得每个人都应该读一读，如果你还没读过的话。核心观点是，更通用的模型永远会战胜更专用的模型，由此可以引申出很多推论，但归根结底就是：永远不要跟模型对着干。这也是我们一直在思考的一件事：我们可以在 Claude Code 里做一个功能，把它作为产品做得更好，我们称这种代码为 scaffolding，也就是模型本身之外的所有代码。但我们也可以等上几个月，模型自己大概就能做这件事了。这里始终存在一种权衡，对吧？你现在投入工程工作，可以在某个领域把能力扩展一点，大概百分之十、二十之类的，就像你要扩展的雷达图上的某个方向；或者你也可以直接等，下一代模型就能做到。所以要始终从这种权衡的角度去思考：你到底想在哪儿投入？而且要明白，所有的 scaffolding 本质上只是技术性的工作罢了。你们大概多久重写一次 Claude Code 的代码？是每六个月一次吗？有没有因为模型进步了，就不再需要的 scaffolding 被你们删掉的？太多了。没错，整个 Claude Code 就是不断地被重写、重写、再重写。我们每隔几周就会淘汰一批工具，再新增一批工具。Claude Code 里没有任何一部分是六个月前就存在的老代码，它一直在被重写。可以说目前 Claude Code 代码库的大部分，比如说百分之八十，都只有几个月的历史吗？是的，绝对可以。甚至可能更少，没错，大概也就几个月，感觉差不多。所以现在代码的生命周期就是这样，最顶尖的创始人也会预期代码的保质期只有几个月。对。你看到 Steve Yaggi 那篇讲在 Anthropic 工作有多棒的文章了吗？我记得里面有一句话，说 Anthropic 的工程师目前平均生产力是 Google 巅峰时期工程师的 1000 倍，这数字真的太疯狂了，1000 倍啊。要知道三年前我们还在讨论 10 倍工程师，现在我们聊的是比 Google 鼎盛时期的工程师还要强 1000 倍，简直不可思议。是啊，我是说，如果你在内部看，技术人员每天都在用 Claude Code。甚至非技术人员，我觉得大概有一半的销售团队也在用 Claude Code。他们开始转向用 Co-work，因为它更易用，而且有 VM，所以更安全。不过没错，我们刚拉了一个数据，团队去年规模翻了一倍，但每位工程师的产能增长了大概 70%。衡量标准是什么？就是最粗暴简单的指标：PR。不过我们也会拿 commit 数量、commit 的生命周期之类的数据做交叉验证。自从 Claude Code 推出以来，Anthropic 每位工程师的产能增长了 150%。天哪。这太疯狂了，因为我以前负责 Meta 的代码质量。我负责所有产品线的代码库质量，包括 Facebook、Instagram、WhatsApp 等等。我们团队当时做的其中一件事就是提升生产力。那时候，看到生产力提升 2%，那都是几百人干一年的成果。所以这种 100% 的增长简直是闻所未闻，完全闻所未闻。是什么促使你加入 Anthropic？作为一个 builder，你本可以去任何地方。是哪个瞬间让你意识到，就是这群人，或者就是这种 approach？我当时住在日本乡下，每天早上刷 Hacker News，看新闻，然后大概在某一时刻，上面开始全是 AI 相关的内容。我开始用一些早期产品，记得最初几次用的时候，真的让我屏住了呼吸。这么说很老套，但那确实是当时的感受。太神奇了，作为一个 builder，我从未有过那种感觉，用那些非常早期的产品时。那时候大概还是 Claude 2 的时期，或者类似的阶段。于是我就开始和 Labs 的朋友聊天，想了解情况。然后我见到了 Ben Mann，他是 Anthropic 的创始人之一，他立刻就把我说服了。而且我一见到 Anthropic 的其他团队成员，也被完全打动了。我觉得大概有两个原因。第一，它像是一个研究实验室在运作。产品当时非常小，核心就是构建安全的模型，这才是唯一重要的事。所以这种紧贴模型、紧贴研发的理念很打动我，产品本身不再是最重要的，模型才是最重要的。在我做了这么多年产品之后，这一点真的引起了我的共鸣。第二就是它的使命驱动性。我是个科幻小说迷，书架上全是科幻作品。所以我深知这事搞砸了会有多严重。而当你想到今年会发生什么？你知道，那将完全是疯狂的一年。最坏的情况下，可能会非常非常糟。所以我想去一个真正理解这一点、并且把它内化到骨子里的地方。在 Anthropic，如果你在餐厅或走廊里无意间听到别人聊天，大家谈论的都是 AI safety。这才是每个人最在乎的事。所以我就是想去这样的地方。对我个人而言，mission 真的太重要了。今年会发生什么？
好。如果你回想六个月前，大家都在做什么预测？Dario 曾预测 Anthropic 90% 的代码会由 Claude 来写。这是真的。对我个人来说，自从 Opus 4.5 以来，一直都是 100%。我直接把 IDE 卸载了。我不手写任何一行代码，完全靠 Claude Code 和 Opus。我每天大概能合入 20 个 PR。如果看整个 Anthropic，比例大概在 70% 到 90% 之间，因团队而异。很多团队、很多人也是 100%。我记得五月份我们推出 Claude Code 时，我就做过一个预测：以后你不再需要 IDE 来写代码了。当时这么说完全是天方夜谭。我觉得观众听了都倒吸一口凉气。因为在当时这听起来是个特别荒唐的预测。其实说白了，你就是去追溯那条指数曲线。这深深植根于我们的 DNA 之中，因为我们的三位创始人都是 scaling laws 论文的共同作者，他们很早就看到了这一点。所以这就是在追溯指数曲线，这就是将会发生的事，而事实也确实如此。因此，继续沿着这条指数曲线走下去，我认为编程将基本对所有人来说都被解决。而且我觉得今天编程对我来说实际上已经被解决了，我认为对所有人都会如此。无论在什么领域，我认为我们都会开始看到“软件工程师”这个头衔消失。也许以后叫 builder，也许叫产品经理，也许我们会保留这个头衔作为某种遗留产物，但人们所做的工作将不仅仅是写代码。软件工程师还会写规格说明，还会与用户交流。就像我们现在在团队中开始看到的这样，工程师在很大程度上都是通才，团队中的每个职能都会写代码——我们的产品经理写代码，设计师写代码，EM 写代码，每个人都写代码，我们的财务人员也写代码，团队里的每个人都在写代码。我们将开始在各处看到这种现象。所以如果我们只是延续这一趋势，这某种程度上只是下限。上限则可怕得多。这涉及我们达到 ASL4。在 Anthropic，我们谈论这些安全等级。ASL3 是模型目前所处的等级。ASL4 则是模型能够递归自我改进。如果这种情况发生，我们本质上必须在发布模型前满足一系列标准。而极端情况是，这种情况发生了，或者出现某种灾难性滥用，比如人们用模型设计生物病毒、设计 zero day 漏洞，诸如此类。这是我们正在非常积极努力防止其发生的事情。说实话，看到人们如何使用 Claude Code，真是既令人兴奋又让人谦卑。我原本只是想做个很酷的东西，结果它变得非常有用，这太令人惊讶和兴奋了。我在 Twitter 上或从外界得到的印象是，基本上大家假期都出去玩了，然后发现了 Claude Code，从那之后就一直很疯狂。你们内部也是这样吗？你们是不是过了个愉快的圣诞假期，然后回来就发现情况变了？其实整个十二月我都在到处旅行。我度过了一个编程假期。我们四处旅行，而我每天都在写代码，那真的很棒。而且那时我也开始用 Twitter 了，因为我很久以前曾在 Threads 工作过。所以我用 Threads 已经有一段时间了。于是我就想看看人们在其他平台上做些什么。是的。我觉得对很多人来说，他们就是在那个时刻发现了 Opus 4.5。而我其实已经知道了。而在内部，Claude Code 在好几个月里一直处于指数级增长。所以只是变得更为陡峭了。这就是我们看到的。如果你看看现在的 Claude Code，Mercury 有个数据说大约 70% 的初创企业选择 Claude 作为他们的首选模型。Semi Analysis 还有另一个数据，所有公开提交中有 4% 是由 Claude Code 完成的，就像所有被写下的代码中。从最大的公司到最小的初创企业，所有公司都在使用 Claude Code。它还为 Perseverance（火星探测器）规划了路线。对我来说这是最酷的事情。我们甚至还印了海报，因为团队觉得“哇，NASA 选择使用这个东西太酷了”。所以这很让人谦卑，但感觉这也只是刚刚开始。
Claude Code 和 co-work 之间是什么关系？它是 Claude Code 的一个分支吗？是不是你们让 Claude Code 看了看 Claude Code，然后说“让我们为非技术人员做个新规格吧，保留所有经验”，然后它自己跑了几天就做出来了？它的起源是什么，你觉得它会走向何方？这大概是我第五次提到需求了。就是这样，我们看到 Twitter 上有个人在用 Claude Code 监测他的番茄植株。还有另一个人用它从损坏的硬盘里恢复婚礼照片。有人用它做金融方面的事。当我们看 Anthropic 内部时，每个设计师都在用它，整个财务团队都在用它，整个数据科学团队都在用它——不是用来做编程。人们费尽周折在终端里安装这个东西，就是为了能使用它。所以我们早就知道想做点什么，于是试验了一堆不同的想法，最后真正火起来的只是桌面应用里一个带有 GUI 的 Claude Code 小包装器，仅此而已。底层就是 Claude Code，是同一个 agent。哦，哇。Felix 和团队——Felix 是早期的 Electron 贡献者，他很熟悉那个技术栈，他当时在尝试各种想法，他们大概用了 10 天左右就搭建出来了。基本上 100% 由 Claude Code 写成。而且感觉已经可以发布了。针对非技术用户，我们得做很多东西。所以和技术受众有点不同。所有代码都在虚拟机里运行。有很多针对删除的保护机制之类。有很多权限提示和其他面向用户的防护措施。是的，老实说这挺显而易见的。
Boris，非常感谢你做出了一个让我睡不着觉的东西，但作为回报，它让我重新进入了创造者模式，某种创始人模式。这是令人兴奋的 3 周。真不敢相信我居然从 11 月等了这么久才真正开始用它。非常感谢你参与我们的访谈，感谢你正在打造的一切。是的，谢谢你们邀请我。多提 bug。听起来不错。来吧。