Claude Code: Anthropic's CLI Agent

Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel, and I'm joined by my co-host Swyx, founder of SmolAI.

大家好,欢迎来到 Latent Space 播客。我是 Alessio,Decibel 的合伙人兼 CTO,和我一起的是联合主持 Swyx,Smol AI 的创始人。

Hey, and today we're in the studio with Cat Wu and Boris Cherny. Welcome. Thanks for having us.

嗨,今天来到演播室的是 Cat Wu 和 Boris Cherny。欢迎。——谢谢邀请。

Cat, you and I know each other from before. I just realized Dagster as well. Yeah. And then Index Ventures and now Anthropic.

Cat,我们俩之前就认识。我刚想起来还有 Dagster 那段,之后是 Index Ventures,现在到了 Anthropic。

It's so cool to see a friend that you know from before now working at Anthropic and shipping really cool stuff.

看到一个早就认识的朋友如今在 Anthropic 做出这么酷的东西,感觉真好。

And Boris, you're a celebrity because we were just having you outside, just getting coffee, and people recognize you from your video. Wasn't that neat?

还有 Boris,你现在是名人了——刚才我们就在外面喝个咖啡,就有人从视频里认出了你。是不是挺神奇?

Yeah, I definitely had that experience like once or twice in the last few weeks. It was surprising.

是啊,过去几周确实碰到过一两次。挺意外的。

Yeah. Well, thank you for making the time. We're here to talk about Claude Code. Most people probably have heard of it. We think quite a few people have tried it.

嗯,谢谢你们抽时间过来。今天我们聊 Claude Code。大多数人应该都听说过它,我们估计不少人也已经上手试过了。

But let's get a crisp, upfront definition. What is Claude Code? Yeah. So Claude Code is... Claude in the terminal.

(Swyx:)不过我们先来一个干脆利落的定义:Claude Code 是什么?——好。Claude Code 就是……终端里的 Claude。

So, you know, Claude has a bunch of different interfaces. There is desktop, there's web, and yeah, Claude Code, it runs in your terminal.

你知道,Claude 有好几种界面:有桌面端,有网页端,而 Claude Code 跑在你的终端里。

Because it runs in the terminal, it has access to a bunch of stuff that you just don't get if you're running on the web or on desktop or whatever.

正因为跑在终端里,它能拿到一堆你在网页端或桌面端根本拿不到的东西。

So it can run bash commands, it can see all of the files in the current directory, and it does all that agentically.

它能跑 bash 命令,能看到当前目录下的所有文件,而且这一切都是 agentic 地完成的。

And, yeah, I guess maybe it comes back to, like, maybe the question under the question is, like, you know, where did this idea come from?

嗯,我猜这背后真正的问题其实是:这个想法是从哪来的?

And, yeah, part of it was, we just want to learn how Claude, we want to learn how people use agents.

一部分原因是,我们就是想搞清楚人们是怎么用 agent 的。

We are doing this with the CLI form factor, because coding is kind of a natural place where people use agents today. And, you know, there's kind of product market fit for this thing.

我们选了 CLI 这个形态,因为编程是今天人们使用 agent 最自然的场景,而且这个东西算是有 product market fit 的。

But, yeah, it's just sort of this crazy research project. And obviously, it's kind of bare bones and simple. But, yeah, it's like an agent in your terminal. That's how the best stuff starts.

但说到底,它就是个疯狂的研究项目。它显然很简陋、很朴素,但它就是一个跑在你终端里的 agent。——最好的东西都是这么开始的。

Yeah. How did it start? Did you have a master plan? Did you have a master plan to build Claude Code?

是啊,它是怎么开始的?你有完整的规划吗?做 Claude Code 是带着一个 master plan 去的吗?

There was no master plan. When I joined Anthropic, I was experimenting with different ways to use the model kind of in different places.

没有什么 master plan。我刚加入 Anthropic 时,在尝试用各种方式、在各种地方使用模型。

And the way I was doing that was through the public API, the same API that everyone else has access to.

用的就是公开 API——和所有人能用的是同一个 API。

And one of the really weird experiments was this Claude that runs in a terminal.

其中一个特别怪的实验,就是这个跑在终端里的 Claude。

And I was using it for kind of weird stuff. I was using it to, like, look at what music I was listening to and react to that.

我拿它干的事也挺怪的,比如让它看我正在听什么音乐,然后做点反应。

And then, you know, like, screenshot my, you know, video player and explain. Like, what's happening there and things like this.

再比如截屏我的视频播放器,让它解释画面里在发生什么,诸如此类。

And this was, like, kind of a pretty quick thing to build. And it was pretty fun to play around with.

这个东西搭起来很快,玩起来也挺有意思。

And then at some point, I gave it access to the terminal and the ability to code. And suddenly, it just felt very useful. Like, I was using this thing every day. It kind of expanded from there.

后来某个时刻,我给了它终端权限和写代码的能力。突然之间,它就变得非常有用了——我开始每天都在用,事情就从那里扩散开了。

We gave the core team access, and they all started using it every day, which was pretty surprising. And then we gave all the engineers and researchers at Anthropic access. And pretty soon, everyone was... I was using it every day.

我们先给核心团队开了权限,结果他们全都开始每天用,这挺出乎意料。然后我们开放给了 Anthropic 所有工程师和研究员,很快所有人都在天天用。

And I remember we had this DAU chart for internal users. And I was just watching it, and it was vertical, like, for days.

我记得我们有一张内部用户的 DAU 图。我就盯着它看,曲线垂直往上,连着涨了好几天。

And we're like, all right, there's something here. We got to give this to external people so everyone else can try this, too.

我们就想:行,这里面有东西。得把它放出去,让外面的人也试试。

And were you also working with Boris already? Or did this come out, and then it started growing? And then you're like, okay, we need to maybe make this a team, so to speak.

(问 Cat)那时候你已经在和 Boris 共事了吗?还是东西先出来、开始增长,然后你们才想:好,我们得把它变成一个正式的团队?

Yeah, the original team was Boris, Sid. And Ben.

最初的团队就是 Boris、Sid,还有 Ben。

And over time, as more people were adopting the tool, we felt like, okay, we really have to invest in supporting it, because all our researchers are using it. And this is, like, our one lever to make them really productive.

随着越来越多人用上这个工具,我们觉得必须认真投入去支持它,因为所有研究员都在用——这是我们让他们真正高产的那根杠杆。

And so at that point, I was using Claude Code to build some visualizations. I was analyzing a bunch of data, and sometimes it's super useful to, like, spin up a Streamlit and, like, see all the aggregate stats at once. And Claude Code made it really, really easy to do.

那时我正用 Claude Code 做一些可视化。我在分析一堆数据,有时候快速拉起一个 Streamlit、一眼看到所有汇总统计,非常有用。Claude Code 把这件事变得特别特别容易。

So I think I sent Boris, like, a bunch. At some point, Boris was like, do you want to just work on this? And so that's how it happened.

我于是给 Boris 发了一大堆反馈。某个时刻 Boris 说:要不你干脆来做这个?事情就这么成了。

It was actually a little, like, it was more than that on my side. You were sending all this feedback, and at the same time, we were looking for a PM.

我这边其实还不止这样。你一直在发各种反馈,而我们正好在找 PM。

And we were, like, looking at a few people. And then I remember telling the manager, like, hey, I want Cat. Aww.

我们看了好几个人选。然后我记得我跟 manager 说:嘿,我要 Cat。——噢~

I'm sure people are curious. What's the process within Anthropic to, like, graduate one of these projects? Like, so you have kind of, like, a lot of growth. Then you get a PM. When did you decide, okay, we should, like, it's ready to go? It'll be opened up.

大家肯定好奇:在 Anthropic 内部,这类项目"转正"的流程是什么样的?增长起来了,配了 PM——你们是什么时候决定:好,它可以对外开放了?

Generally, at Anthropic, we have this product principle of do the simple thing first. And I think that the way we build product is really based on that principle.

总的来说,Anthropic 有一条产品原则:先做最简单的事。我们做产品的方式基本都建立在这条原则之上。

So you kind of staff things as little as you can and keep things as scrappy as you can because the constraints are actually pretty helpful.

所以团队配得越少越好,东西保持越糙越好——因为这些约束其实非常有帮助。

And for this case, we wanted to see some signs of product market fit before we scaled it.

具体到这个项目,我们想先看到一些 product market fit 的信号,再去扩大投入。

Yeah, I imagine. So, like, we're putting out the MCP episode this week. And I imagine MCP also now has a team around it in much the same way. It is now very much officially, like, sort of, like, an Anthropic product.

可以想象。我们这周正好要发 MCP 那期节目,我猜 MCP 现在也以差不多的方式有了自己的团队,正式成了 Anthropic 的产品。

So I'm kind of curious for Cat, like, how do you view PMing something like this? Like, what is, I guess, you're, like, sort of grooming the roadmap. You're listening to users. And the velocity is something I've never seen coming out of Anthropic.

所以我很好奇 Cat 怎么看:PM 这样一个东西是什么体验?你要打理 roadmap,要听用户的声音——而且这个迭代速度,是我从没在 Anthropic 见过的。

I think I PM with a pretty light touch. I think Boris and the team are, like, extremely strong product thinkers.

我觉得我的 PM 方式是很轻的。Boris 和团队本身就是极强的产品思考者。

And for the vast majority of the features on our roadmap, it's actually just, like, people who have a lot of experience. People building the thing that they wish that the product had. So very little actually is tops down.

Roadmap 上绝大多数 feature,其实就是经验丰富的人在做他们自己希望产品拥有的东西。真正自上而下的安排非常少。

I feel like I'm mainly there to, like, clear the path if anything gets in the way and just make sure that we're all good to go from, like, a legal marketing, et cetera, perspective.

我的角色主要是:有什么挡路的就去清掉,确保法务、市场等各方面都没问题、随时可以发。

And then I think, like, in terms of very broad roadmap or, like, long-term roadmap, I think the whole team comes together and just thinks about, okay, what do we think models will be really good at in three months?

至于更宏观、更长期的 roadmap,整个团队会坐在一起想:我们认为三个月后,模型会真正擅长什么?

And, like, let's just make sure that what we're building is really consistent. Yeah. Like, what do we think is really compatible with, like, the future of what models are capable of?

然后确保我们正在做的东西和这个判断一致——和模型能力的未来真正兼容。

I'd be interested to double-click on this. What will models be good at in three months?

这点我想展开问问:三个月后模型会擅长什么?

Because I think that's something that people always say to think about when building AI products. But nobody knows how to think about it because it's, everyone's just, like, it's generically getting better all the time. We're getting AGI soon, so don't bother. You know, like, how do you calibrate three months of progress?

因为大家做 AI 产品时总说要想这个问题,但没人知道该怎么想——所有人都只会说"模型反正一直在变好""AGI 快来了,别折腾了"。你们是怎么校准"三个月的进展"的?

I think if you look back historically, we tend to ship models every couple of months or so. So three months is just, like, an arbitrary number.

回看历史,我们大约每隔几个月就会发一版模型。所以三个月只是个随手取的数字。

I think the direction that we want our models to go in is being able to accomplish more and more complex tasks with as much autonomy as possible.

我们希望模型前进的方向,是能以尽可能高的自主性,完成越来越复杂的任务。

And so this includes things like making sure the models are able to explore and find the right information that they need to accomplish a task, making sure that models are thorough in accomplishing every aspect of a task, making sure the models can, like, compose different tools together effectively. These are the directions we care about.

这包括:确保模型能自己探索、找到完成任务所需的正确信息;确保模型把任务的每个方面都做扎实;确保模型能有效地把不同工具组合起来。这些就是我们关心的方向。

I guess coming back to code, this kind of approach affected the way that we built code also because we know that if we want some product that has, like, very broad a product market fit today, we would build, you know, a Cursor or a Windsurf or something like this.

回到 Claude Code 上,这套思路也影响了我们做它的方式。我们很清楚:如果想做一个今天就有广泛 product market fit 的产品,那应该去做一个 Cursor 或者 Windsurf 这样的东西。

Like, these are awesome products that so many people use every day. I use them. That's not the product that we want to build.

它们都是很棒的产品,每天有那么多人在用,我自己也在用。但那不是我们想做的产品。

We want to build something that's kind of much earlier on that curve and something that will maybe be a big product, you know, a year from now or, you know, however much time from now. As the model improves.

我们想做的,是在那条曲线上早得多的东西——随着模型变强,它也许一年后(或者不管多久之后)会成为一个大产品。

And that's why code runs in a terminal. It's a lot more bare bones. You have raw access to the model because we didn't spend time building all this kind of nice UI and scaffolding on top of it.

这就是 Claude Code 跑在终端里的原因。它简陋得多,你得到的是对模型的 raw access——因为我们没花时间在上面盖漂亮的 UI 和脚手架。

When it comes to, like, the harness, so to speak, and things you want to put around it, there's one that may be prompt optimization. So obviously I use Cursor every day. There's a lot going on in Cursor that is beyond my prompt for, like, optimization and whatnot.

说到所谓的 harness,以及你们想往模型周围加的东西——比如 prompt 优化。我每天都用 Cursor,Cursor 里在我的 prompt 之外发生了很多事,各种优化之类的。

But I know you recently released, like, you know, compacting context features and all that. How do you decide how thick it needs to be on top of the CLI?

但我知道你们最近发布了 compact 上下文这类功能。你们怎么决定 CLI 之上这一层要做多厚?

So that's kind of the share interface. And at what point are you deciding between, okay, this should be a part of Claude Code versus this is just something for the IDE people to figure out, for example?

什么时候你们会判断:这个应该做进 Claude Code,而那个就留给 IDE 厂商去解决?

Yeah, there's kind of three layers at which we can build something. So the, you know, being an AI company, the most natural way to build anything is to just build it into the model and have the model do the behavior.

我们做任何东西,大致有三层可以选。作为一家 AI 公司,最自然的方式就是直接做进模型里,让模型自己产生这个行为。

The next layer is probably scaffolding on top, so it's like Claude Code itself. And then the layer after that is using Claude Code as a tool in a broader workflow, so to compose stuff in.

下一层是模型之上的脚手架,也就是 Claude Code 本身。再往外一层,是把 Claude Code 当作一个工具,组合进更大的工作流里。

You know, so for example, a lot of people use code with, you know, Tmux, for example, to manage a bunch of windows and a bunch of sessions happening in parallel. We don't need to build all of that in.

比如很多人把 Claude Code 和 Tmux 一起用,管理一堆并行的窗口和会话。这些我们就完全不用做进来。

Compact, it's sort of this thing that kind of has to live in the middle because it's something that we want to work when you use code. You shouldn't have to pull in extra tools on top of it.

Compact 则不得不放在中间这一层:它是用 Claude Code 时就应该开箱即用的能力,你不该还要额外装工具。

And rewriting memory in this way isn't something the model can do today. So you have to use a tool for it. And so it kind of has to live in that middle area.

而"重写记忆"这件事,今天的模型自己还做不到,必须靠工具来做。所以它只能落在中间这层。

We tried a bunch of different options for compacting, you know, like rewriting old tool calls and truncating old messages and not new messages.

我们为 compact 试了一堆方案:重写旧的 tool call、截断旧消息保留新消息,等等。

And then in the end, we actually just did the simplest thing, which is ask Claude to summarize the, you know, the previous messages and just return that and that's it.

最后我们做的其实是最简单的那个:让 Claude 把之前的消息总结一下,返回总结,就这样。

And it's funny when the model is so good, the simple thing usually works. You don't have to over-engineer it. We do that for Claude Plays Pokemon too.

有意思的是,模型足够好的时候,简单方案通常就管用,不需要过度工程化。Claude Plays Pokemon 我们也是这么干的。

Just kind of interesting to see that. Yeah. It's like pattern re-emerging.

挺有意思的,同一个模式在反复出现。

And then you have the Claude.md file for the more user-driven memories, so to speak. It's like kind of like the equivalent of maybe cursor rules, I would say.

然后你们还有 Claude.md 文件,承载更偏用户主导的记忆——大概相当于 Cursor rules 吧。

Yeah. And Claude.md, it's another example of this idea of, you know, do the simple thing first.

对。Claude.md 是"先做最简单的事"的另一个例子。

We had all these crazy ideas about like memory architectures and, you know, there's so much literature about this. There's so many different external products about this and we wanted to be inspired by all this stuff.

我们当时有一堆关于记忆架构的疯狂想法——这方面文献那么多,外部产品也那么多,我们想从中吸取灵感。

But in the end, the thing we did is ship the simplest thing, which is, you know, it's a file that has some stuff. And it's auto-read into context.

但最终我们发布的是最简单的版本:一个写着一些内容的文件,自动读入 context。

And there's now a few versions of this file. You can put it in the root, or you can put it in child directories, or you can put it in your home directory. And we'll read all of these in kind of different ways. But yeah, it's the simplest thing that could work.

现在这个文件有几个版本:可以放在仓库根目录,可以放在子目录,也可以放在 home 目录,我们会以不同方式读取。但它依然是"能跑通的最简单方案"。

I think like people are interested in comparing and contrasting, obviously, because to you, obviously, this is the house tool. You work on it. People are interested in like figuring out how to choose between tools.

大家显然很关心横向对比——对你们来说这是自家工具,你们在做它,但用户想搞清楚工具之间该怎么选。

There's the Cursors of the world. There's like the Devins of the world. There's Aiders and there's Claude Code. And, you know, there's a lot of stuff. We can't try everything all at once.

市面上有 Cursor 这一类,有 Devin 这一类,有 Aider,还有 Claude Code。东西太多了,我们没法一口气全试一遍。

My question would be, where do you place it in the universe of options? Well, you can ask Claude to just try all these tools.

我的问题是:在所有这些选项构成的宇宙里,你把 Claude Code 放在什么位置?——(Boris:)你可以让 Claude 把这些工具全试一遍。

No self-favoring at all.

完全没有偏袒自家啊。

Claude plays engineer. I don't know. We use all these tools in-house, too. We're big fans of all this stuff.

Claude 扮演工程师,哈哈。说真的,这些工具我们内部也都在用,我们是它们的粉丝。

Like Claude Code is, obviously, it's a little different than some of these other tools in that it's a lot more raw. Like I said, there isn't this kind of big, beautiful UI on top of it. It's raw access to the model. It's as raw as I get.

Claude Code 和其他工具的不同之处在于它"生"得多。像我说的,上面没有那种漂亮的大 UI,它是对模型的 raw access——能有多原始就有多原始。

So if you want to use a power tool that lets you access the model directly and use Claude for automating, you know, big workloads, you know, for example, if you have like a thousand lint violations and you want to start a thousand instances of Claude and have it fix each one and then make a PR, then Claude Code is a pretty good tool.

所以如果你想要一把能直接触达模型的 power tool,用 Claude 去自动化大批量任务——比如你有一千个 lint 报错,想拉起一千个 Claude 实例,每个修一个,然后各自提 PR——那 Claude Code 是个相当不错的选择。

It's a tool for power workloads for power users. And I think that's just kind of where it fits.

它是给 power user 跑 power workload 的工具。它的生态位就在这里。

It's the idea of like parallel versus kind of like single path, one way to think about it, where like the IDE is really focused on like what you want to do versus like Claude Code. You kind of more see it as like less supervision required. You can kind of spin up a lot of them. Is that the right mental model?

一种理解是"并行 vs 单线":IDE 聚焦在你当下要做的那一件事上,而 Claude Code 更像是需要的监督更少、可以一次拉起一大批。这个心智模型对吗?

Yeah. And there's some people at Anthropic that have been racking up like thousands of dollars a day with this kind of automation. Most people don't do anything like that, but you totally could do something like that.

对。Anthropic 内部有人靠这类自动化一天烧掉几千美元。大多数人不会这么干,但你完全可以这么干。

We think of it as like a Unix utility. Right? So it's like the same way that you would compose, you know, grep or cat or something like this. The same way you can compose code into workflows.

我们把它看作一个 Unix utility。就像你平时组合 grep、cat 这些命令一样,你可以把 Claude Code 组合进各种工作流。

The cost thing is interesting. Do people pay internally or do you get free? If you work at Anthropic, you can just run this thing as much as you want every day? It's for free internally. Nice. Yeah. I think if everybody had it for free, it would be huge.

成本这事挺有意思。内部要付费吗,还是免费?在 Anthropic 工作就能天天随便跑?——(Boris:)内部免费。——爽。我觉得要是所有人都能免费用,那会是巨大的量。

Because like, I mean, if I think about, I pay Cursor. I use millions and millions of tokens in Cursor. That would cost me a lot more in Claude Code.

因为你想,我付 Cursor 的订阅费,在 Cursor 里用掉数以百万计的 token。同样的量在 Claude Code 里要花多得多的钱。

And so I think like a lot of people that I've talked to, they don't actually understand how much it costs to do these things. And they'll do a task and they're like, oh, that costs 20 cents. I can't believe I paid that much.

我聊过的很多人,其实并不理解做这些事的真实成本。他们跑完一个任务会说:啊,这花了 20 美分?我居然付了这么多。

How do you think, going back to like the product side too, is like, how much do you think of that being your responsibility to try and make it more efficient versus that's not really what we're trying to do with the tool?

回到产品层面:你们觉得"把它做得更省"在多大程度上是你们的责任?还是说,这本来就不是这个工具要解决的问题?

We really see Claude Code as like the tool that gives you the smartest abilities out of the model.

我们真心把 Claude Code 看作那个"把模型最聪明的能力直接交给你"的工具。

We do care about cost insofar as it's very correlated with latency. And we want to make sure that this tool is extremely snappy to use and extremely thorough in its work. We want to be very intentional about all the tokens that it produces.

我们在乎成本,但主要是因为成本和延迟高度相关。我们要确保这个工具用起来非常跟手、干活非常彻底,它产生的每一个 token 我们都希望是有意图的。

I think we can do more to like communicate the cost with users. Currently, we're seeing costs around like $6 per day. Per active user.

在向用户传达成本这件事上,我们可以做得更好。目前我们看到的成本大约是每个活跃用户每天 $6。

And so it's like, it does come out to a bit higher over the course of a month in Cursor. But I don't think it's like out of band. And that's like roughly how we're thinking about it.

按月算下来,确实比 Cursor 贵一些,但我不认为离谱。我们大致是这么想这件事的。

I would add that I think the way I think about it is it's an ROI question. It's not a cost question.

我补充一点:在我看来这是个 ROI 问题,不是成本问题。

And so if you think about, you know, an average engineer salary and like what, you know, we were talking about this before the podcast. Like, engineers are very expensive.

想想一个工程师的平均薪资——录节目之前我们还在聊这个——工程师是非常贵的。

And if you can make an engineer 50, 70% more productive, that's worth a lot. And I think that's the way to think about it.

如果你能让一个工程师的产出提高 50%、70%,那价值是巨大的。我认为应该这么算账。

So if you're saying, if you're targeting Claude to be the most powerful end of the spectrum, as opposed to the less powerful, but faster, cheaper side of the spectrum, then there's typically people who recommend a waterfall, right? You try this faster, simple one. That doesn't work. You upgrade, you upgrade, you upgrade. And finally you hit Claude Code, at least for people who are token constrained that don't work at Anthropic.

如果你们瞄准的是能力光谱里最强的那一端,而不是更快更便宜的那一端,那通常会有人推荐"瀑布式"用法:先试便宜简单的,不行就升级、再升级,最后才上 Claude Code——至少对那些不在 Anthropic 上班、token 受限的人来说。

And part of me wants to just fast track all of that. I just want to fan out to everything all at once. And once I, once I'm not satisfied with the next one solution, I'll just sort of switch to the next. I don't know if that's real.

但我有点想跳过整个瀑布,直接对所有工具同时 fan out,哪个不满意就切下一个。不知道这种用法现不现实。

Yeah, we're, we're definitely trying to make it a little easier to make Claude Code kind of the tool that you use for all the different workloads.

我们确实在努力让 Claude Code 更容易成为你处理各种 workload 的那一个工具。

So for example, we launched thinking recently. So for any kind of planning workload where you might've used other tools before you can just ask Claude, and that'll use, you know, chain of thought. To, to think stuff out. I think we'll get there.

比如我们最近上线了 thinking:任何规划类的任务,以前你可能要用别的工具,现在直接问 Claude 就行,它会用 chain of thought 把事情想清楚。我们会走到那一步的。

Maybe we'll do it this way. How about we recap like sort of the brief history of Claude Code, like between when you launched and now there, there've been quite a few ships. How would you highlight the major ones? And then we'll get to the thinking tool.

要不这样:我们快速回顾一下 Claude Code 的简史——从发布到现在,你们 ship 了不少东西。哪些是你们认为最重要的?然后我们再聊 thinking。

And I think I'd have to like check your Twitter to remember.

我可能得翻你的 Twitter 才想得起来。

I think a big one that we've gotten a lot of requests for is web fetch. So we worked really closely with our legal team to make sure that, you know, the code that we shipped as secure of an implementation as possible.

一个呼声很高的大功能是 web fetch。我们和法务团队贴得很紧,确保发布的实现在安全性上做到尽可能稳妥。

So we'll web fetch if a user directly provides an URL, whether that's in their Claude.md or in their message directly, or if a URL is mentioned in one of the previously fetched URLs. And so this way enterprises can feel pretty secure about letting their developers continue to use it.

规则是:只有当用户直接提供了 URL——写在 Claude.md 里或消息里——或者这个 URL 出现在之前抓取过的页面里,我们才会去抓。这样企业可以放心让开发者继续用。

We shipped a bunch of like auto features, like autocomplete, where you can, you know, press tab to complete a file name or file path. Autocompact so that users feel like they have like infinite context since we'll compact behind the scenes.

我们还发了一批 auto 系列功能:autocomplete,按 tab 补全文件名和路径;autocompact,我们在幕后自动压缩上下文,让用户感觉自己拥有"无限 context"。

And we also shipped auto accept because we noticed that a lot of users were like, hey, like Claude Code can figure it out. I've like developed a lot of trust for Claude Code. I wanted to just like autonomously edit my files, run tests, and then come back to me later. So those are some of the big ones.

还有 auto accept——因为很多用户说:Claude Code 自己能搞定,我已经很信任它了,就让它自主改文件、跑测试,完了再回来找我。这些算是几个大的。

Vim mode, custom slash commands.

还有 Vim mode、自定义 slash 命令。

People love Vim mode. Yeah. So that was a, that was a top request too. That one went pretty viral.

大家爱死 Vim mode 了。那也是呼声最高的需求之一,发布后传播得很广。

Yeah. Memory. Those are recent ones. Like the hashtag to remember.

对,还有 memory,这些都是最近的——比如用 # 号来记东西。

So yeah. I mean, I'd love to dive into, you know, on the technical side, any of them that was particularly challenging. Paul from Aider always says how much of it was coded by Aider, you know? So then the question is how much of it was coded by Claude Code? Obviously there's some percentage, but I wonder if you have a number. Like 50? 80? It's pretty high. Probably near 80 I'd say.

技术层面我很想挖一挖哪个功能最难做。Aider 的 Paul 总爱说 Aider 有多少代码是 Aider 自己写的——那么问题来了:Claude Code 有多少代码是 Claude Code 写的?肯定有个百分比,你们有数字吗?50?80?——(Boris:)挺高的,我说接近 80 吧。

It's very high.

非常高。

Yeah. That makes sense. It's a lot of human code review though.

嗯,合理。不过有大量的人工 code review。

Yeah. What a, what a human code review. I think some of the stuff has to be handwritten and some of the code can be written by Claude. And there's sort of a wisdom in knowing which one to pick and what percent for each kind of task.

是的,人工 review 很重要。有些东西必须手写,有些代码可以交给 Claude——知道哪类任务选哪种方式、各占多少比例,这本身是一种智慧。

So usually where we start is Claude writes the code. And then if it's not good, then maybe a human will dive in.

通常我们的起点是让 Claude 写。写得不行,人再下场。

There's also some stuff where like I actually prefer to do it by hand. So it's like, you know, intricate data model refactoring or something. I won't leave it to Claude because I have really strong opinions and it's easier to just do it and experiment than it is to explain it to Claude.

也有些活我其实更愿意手写,比如精细的数据模型重构。这种我不会丢给 Claude,因为我有非常强的个人意见,自己动手边做边试,比跟 Claude 解释清楚要容易。

So yeah, I think that nets out to maybe like 80, 90% Claude written code overall.

所以算下来,整体大概 80% 到 90% 的代码是 Claude 写的。

We're hearing a lot of that in our portfolio companies, like more like series A companies is like 80, 85% of the code they write is AI generated. Yeah. Well, that's a whole different discussion.

我们在 portfolio 公司里也常听到类似数字——偏 A 轮阶段的公司,80%、85% 的代码是 AI 生成的。当然那是另一个话题了。

The custom slash command. I had a question. How do you think about custom slash command MCPs? Like how does this all tie together?

关于自定义 slash 命令我有个问题:自定义 slash 命令和 MCP 之间,你们是怎么想的?这一切是怎么串起来的?

You know, is the slash command and Claude Code kind of like an extension of the MCP? Are people building things that should not be MCP, but are just kind of like self-contained things in there? How should people think about it?

Claude Code 里的 slash 命令算是 MCP 的延伸吗?大家是不是在里面做一些本不该是 MCP、就该自成一体的东西?用户该怎么理解这两者?

Yeah. I mean, obviously we're big fans of MCP. You can use MCP to do a lot of different things. You can use it for custom tools and custom commands and all this stuff. But at the same time, you shouldn't have to use it.

我们显然是 MCP 的忠实粉丝。MCP 能做很多事:自定义工具、自定义命令等等。但与此同时,你不应该"被迫"用它。

So if you just want something really simple and local, you just want, you know, some essentially like prompt that's been saved, just use local commands for that.

如果你只想要个简单的本地的东西——本质上就是一段存下来的 prompt——那用 local command 就行。

Over time, something that we've been thinking a lot about is how to re-expose things in convenient ways. So for example, let's say you had this local command. Could you re-expose that as an MCP prompt? Because Claude Code is an MCP client and an MCP server.

我们一直在想的一件事,是怎么把这些东西以更方便的方式"再暴露"出去。比如你有一个 local command,能不能把它再暴露成一个 MCP prompt?因为 Claude Code 既是 MCP client,也是 MCP server。

Or similarly, let's say you pass in a custom, you know, like a custom bash tool. Is there a way to re-expose that? Re-expose that as an MCP tool?

类似地,假如你传进来一个自定义的 bash 工具,有没有办法把它再暴露成一个 MCP tool?

We think generally you shouldn't have to be tied to a particular technology. You should use whatever works for you.

总的来说,我们认为你不应该被绑死在某一种技术上。什么好用就用什么。

Because there's some like Puppeteer. I think that's like a great way, great thing to use a Claude Code, right? For testing. There's like a Puppeteer MCP protocol, but then people can also write their own slash commands.

比如 Puppeteer——拿来配合 Claude Code 做测试很合适。已经有 Puppeteer 的 MCP server,但大家也可以自己写 slash 命令。

And I'm curious, like where MCP are going to end up being, where it's like maybe each slash command leverages MCPs, but no command itself is an MCP because it ends up being customized.

我好奇 MCP 最终会落在哪个位置——也许每个 slash 命令都会调用 MCP,但命令本身不是 MCP,因为它终归是高度定制的。

I think that's what people are still trying to figure out. It's like, should this be in the runtime or in the MCP server? I think people haven't quite figured out where the line is.

大家还在摸索:这东西该放在 runtime 里,还是放在 MCP server 里?这条线画在哪,行业还没想明白。

Yeah. For something like Puppeteer, I think that probably belongs in MCP because there's a few like tool calls that go in that too. And so it's probably nice to encapsulate that in the MCP server.

像 Puppeteer 这种,我觉得放 MCP 里更合适,因为它涉及好几个 tool call,封装进 MCP server 比较干净。

Whereas slash commands are actually just like prompts. So they're not actually tools.

而 slash 命令其实就是 prompt,并不是真正的工具。

We're thinking about how to expose more customizability options so that people can use them. People can bring their own tools or turn off some of the tools that Claude Code comes with.

我们在考虑开放更多可定制选项:让大家可以带自己的工具进来,或者关掉 Claude Code 自带的某些工具。

But there's also some trickiness there because we want to just make sure that the tools people bring are things that Claude is able to understand and that people don't accidentally inhibit their experience by maybe bringing a tool that is like confusing to Claude. So we're just trying to work through the UX of it.

但这里有些微妙之处:我们得确保大家带进来的工具是 Claude 能理解的,别因为带了个让 Claude 困惑的工具,反而把自己的体验搞坏了。我们还在打磨这块的 UX。

Yeah. I'll give an example also of how this stuff connects. For Claude Code internally in the GitHub repo, we have this GitHub action that runs. And the GitHub action invokes Claude Code with a local slash command. And the slash command is lint. So it just runs a linter using Claude.

我举个例子说明这些东西怎么串起来。Claude Code 自己的 GitHub repo 里跑着一个 GitHub Action,这个 Action 用一个 local slash 命令调起 Claude Code,命令就叫 lint——用 Claude 来跑 linter。

And it's a bunch of things that are pretty tricky to do with a traditional linter that's based on static analysis. So for example, it'll check for spelling mistakes, but also it checks that code matches comments. It also checks that, you know, we use a particular library for, you know, a specific command. So it checks for network fetches instead of the built-in library.

它检查的是传统静态分析 linter 很难做到的事:比如检查拼写错误,还检查代码和注释是否一致,检查某类操作是否用了指定的库——比如网络请求必须用我们规定的库,而不是内置库。

There's a bunch of these specific things that we check that are pretty difficult to express just with lint. And in theory, you can go in and, you know, write a bunch of lint rules for this. Some of it you could cover, some of it you probably couldn't.

这类专门的检查点,用普通 lint 规则很难表达。理论上你可以去写一堆 lint 规则,有些能覆盖,有些大概率覆盖不了。

But honestly, it's much easier to just write a one bullet in Markdown in a local command and just commit that.

但说实话,在 local command 的 Markdown 里写一行 bullet,然后 commit 进去,要容易得多。

And so what we do is Claude runs through the GitHub action. We invoke it with slash project colon lint. So which just invokes that local command. It'll run the linter. It'll identify any mistakes. It'll make the code changes. And then it'll use the GitHub MCP server in order to commit the changes back to the PR.

流程是:Claude 在 GitHub Action 里跑起来,我们用 /project:lint 调起那个 local command;它跑 lint、找出问题、改好代码,然后用 GitHub 的 MCP server 把改动提交回 PR。

And so you can kind of compose these tools together. And I think that's a lot of the way we think about code is just one tool in an ecosystem that composes nicely without being opinionated about any particular piece.

这些工具就这样组合在一起。我们对 Claude Code 的定位大体也是如此:生态里的一个工具,能优雅地参与组合,而不对任何一环强加自己的意见。

It's interesting. I have a weird chapter in my CV that makes me, I was the CLI maintainer for Netlify. And so I have a little bit of a dive. There's a decompilation of Claude Code out there that has since been taken down. But it seems like you use CommanderJS and React Ink is like the public info about this.

有意思。我简历里有段奇怪的经历——我以前是 Netlify 的 CLI 维护者,所以对这块多少有点研究。网上流传过一个 Claude Code 的反编译版本(后来被下架了),公开信息看起来你们用的是 CommanderJS 和 React Ink。

And I'm just kind of curious, like at some point you're just, you're not even building Claude Code. You're kind of just building a general purpose CLI framework that anyone, any developer can hack to their purposes. You ever think about this? Like this level of configurability is more of like a CLI framework. Or like some new form factor that doesn't exist before.

我好奇的是:到某个程度,你们做的已经不是 Claude Code,而是一个任何开发者都能改造为己所用的通用 CLI 框架了。你们想过这事吗?这种可配置程度,更像一个 CLI framework,或者某种以前不存在的新形态。

Yeah. It's definitely been fun to hack on a really awesome CLI because there's not that many of them. But yeah, we're big fans of Ink.

能在一个真正出色的 CLI 上折腾确实很爽,因为这样的 CLI 不多。我们是 Ink 的大粉丝。

Vadim Demedes. So we actually used him, used React Ink for a lot of our projects.

Vadim Demedes(Ink 作者)。我们很多项目也用 React Ink。

Ink is amazing. It's like, it's sort of hacky and janky in a lot of ways. It's like you have React and then the renderer is just translating the React code to like ANSI language. That's the way to render.

Ink 很神奇。它在很多方面其实挺 hacky、挺糙的:你写 React,渲染器把 React 代码翻译成 ANSI 转义序列,就这么渲染出来。

And there's all sorts of stuff that just doesn't work at all because ANSI escape codes are like, you know, it's like this thing that started to be written like the 1970s. And there's no really great spec about it. Every terminal is a little different.

而且有一大堆东西根本不能用——ANSI escape code 这套东西是 1970 年代开始写的,没有像样的规范,每个终端都略有不同。

So building in this way, it feels to me a little bit like building for the browser back in the day where you had to think about like Internet Explorer 6 versus Opera versus like Firefox and whatever. Like you have to think about these cross-terminal differences a lot.

这样开发的感觉,有点像当年给浏览器做网页:你得操心 Internet Explorer 6、Opera、Firefox 之间的差异。现在则要花大量心思处理跨终端差异。

So yeah, big fans of Ink because it helps abstract over that. We're also, we use Bun. So big fans of Bun. That's been, it makes writing our tests and running tests much faster. We don't use it in the runtime yet.

所以我们很感谢 Ink,它把这些都抽象掉了。我们还用 Bun,也是 Bun 的大粉丝——它让我们写测试、跑测试都快了很多。不过 runtime 里我们还没用它。

It's not just for speed, but you tell me, I don't want to put words in your mouth, but my impression is they help you ship the compilation, the executable. Yeah, exactly.

不只是为了快吧——我不想替你说话,但我的印象是 Bun 帮你们打包出了可执行文件。——(Boris:)对,正是。

So we use Bun to compile the code together.

我们用 Bun 把代码编译打包到一起。

Any other pluses of Bun? I just want to track Bun versus Deno conversations. Deno's in there.

Bun 还有什么别的好处?我想追踪一下 Bun vs Deno 的论战,Deno 也算个选项。

I actually haven't used Deno back. It's been a while. I remember Ryan.

Deno 我其实很久没用了。我记得 Ryan(Dahl)。

Ryan made it back in the day and it was like, there were some ideas that I think were very cool in it, but yeah, it just never took off to that same degree. Still a lot of cool ideas. Like being able to NPM, just import from any URL, I think is pretty amazing.

Ryan 当年做 Deno 时有一些非常酷的想法,只是它始终没有火到同等程度。但里面确实有很多好点子——比如不走 NPM、直接从任意 URL import,我觉得相当惊艳。

That's the dream of ESM.

那是 ESM 的梦想。

I was going to ask you one other feature, then we can get to the thinking tool of AutoAccept. I have this little thing I'm trying to do. I'm trying to develop thinking around for trust in agents, right?

我还想问一个功能,然后我们再聊 thinking——就是 AutoAccept。我最近在琢磨一个小课题:怎么建立对 agent 的信任。

When do you say, all right, go autonomous? When do you pull the developer in? And sometimes you let the model decide. Sometimes you're like, this is a destructive action, always ask me. And I'm just curious if you have any internal heuristics around when to AutoAccept and where all this is going.

什么时候你会说"好,放手自主跑"?什么时候要把开发者拉回来?有时让模型自己决定,有时则是"这是破坏性操作,永远要问我"。你们内部有什么启发式吗?这一切又会往哪走?

We're spending a lot of time building out the permission system. So Robert on our team is leading out this work. We think it's really important to give developers the control to say, hey, these are like the allowed permissions.

我们在权限系统上投入了大量时间,团队里的 Robert 在牵头做这块。我们认为很重要的一点,是把控制权交给开发者:明确哪些操作是被允许的。

Generally, this includes stuff like the model's always allowed to read files or read anything. And then it's up to the user to say, hey, it's about to edit files, it's about to run tests. These are like probably the safest three actions.

一般来说,模型总是被允许读文件、读任何东西;至于改文件、跑测试这类操作,则由用户来决定——这几样大概算最安全的操作了。

And then there's like a long list of other actions that users can either allow list or deny list based on regex matches with the action.

再往后是一长串其他操作,用户可以基于正则匹配,把它们加进允许清单或拒绝清单。

How good is that? Is writing a file ever be unsafe if you have version control? I think that's.

这有多必要?在有版本控制的前提下,写文件还能不安全吗?

Yeah, I think it's I think there's like a few different probably like aspects of safety to think about. So it could be useful just to break that out a little bit.

安全其实有好几个不同的层面,值得拆开讲讲。

So for file editing, it's actually less, I think, about safety, although there is still a safety risk. Because what might happen is, let's say the model fetches a URL and then there's a prompt injection attack in the URL. And then the model writes malicious code to disk and you don't realize it. Although, you know, there is code review as like a separate thing. Kind of where there is as protection.

对改文件来说,重点其实不太在安全——尽管安全风险仍然存在。比如模型抓了一个 URL,URL 里藏着 prompt injection 攻击,然后模型把恶意代码写到了磁盘上而你没察觉。当然,code review 是另一道独立的防线。

But I think generally for file writes, the model might just do the wrong thing. That's the biggest thing.

但总体上,改文件最大的问题是:模型可能就是做错了。

And what we find is that if the model is doing something wrong, it's better to identify that earlier and correct it earlier. And then you're going to have a better time. If you wait for the model to just go down this like totally wrong path and then correct it 10 minutes later, you're going to have a bad time. So it's better to usually identify failures early.

我们的经验是:模型走偏了,越早发现、越早纠正,你的体验越好。等它沿着完全错误的路走了十分钟再去纠正,你会很痛苦。所以通常要尽早识别失败。

But at the same time, there's some cases where you just want to let the model go. So, for example, if Claude Code is. You know, it's writing tests for me. I'll just hit shift tab. Enter auto accept mode and just let it run the tests and iterate on the tests until they pass. Because I know that's a pretty safe thing to do.

但同时,也有些场景你就是该放手。比如 Claude Code 在帮我写测试,我会直接按 shift+tab 进入 auto-accept 模式,让它一直跑测试、改测试,直到全部通过——因为我知道这事相当安全。

And then for some other tools like bash tool, it's pretty different. Because Claude could run, you know, rm -rf /. And that would suck. That's not a good thing. So we definitely want people to be in the loop to catch stuff like that.

而像 bash 这样的工具就很不一样了:Claude 理论上可以跑 rm -rf /,那就糟透了。这类事我们绝对希望有人在环里把它拦下来。

The model is, you know, trained and aligned to not do that. But, you know, these are non-deterministic systems. So, like, you still want a human in the loop.

模型经过训练和对齐,不会去干这种事。但这终究是非确定性系统,所以你仍然需要 human in the loop。

I think that generally the way that things are trending is kind of less time between human input. Did you see the METR paper?

总的趋势是:人工干预之间的间隔在变得越来越长。你看过 METR 那篇论文吗?

They established a Moore's law for time between human input, basically. And it's basically doubling every three to seven months is the idea.

他们基本上给"人工干预之间的时长"建立了一条摩尔定律:大约每三到七个月翻一倍。

And Anthropic is currently doing super well on that benchmark. It's roughly about autonomous for 15 minutes. And it's at the 50th percentile of human effort, which is kind of cool. Highly recommend that.

Anthropic 在那个 benchmark 上表现非常好——大约能自主运行 15 分钟,相当于人类工作量的第 50 百分位。挺酷的,强烈推荐去看。

I put Cursor in YOLO mode all the time and just run it.

我一直把 Cursor 开在 YOLO 模式直接跑。

But it's fine. Which is vibe coding, right?

反正也没事——这就是 vibe coding 嘛。

And there's a couple of things that are interesting when you talked about alignment and the model being trained. So I always put it in a Docker container. And I have a prefix every command with, like, the Docker compose.

你刚才说对齐和模型训练,有几件事挺有意思。我一直把它放在 Docker 容器里跑,每条命令都加 docker compose 前缀。

And yesterday, my Docker server was not started. And I was like, oh, Docker is not running. Let me just run it outside of Docker. And I'm like, whoa, whoa, whoa, whoa, whoa. You should start Docker and run it in Docker.

昨天我的 Docker 服务没启动,它就说:哦,Docker 没在跑,那我直接在 Docker 外面跑吧。我赶紧:哎哎哎等等——你应该把 Docker 启动起来,在 Docker 里跑。

That is, like, a very good example of, like, you know, sometimes you think it's doing something and then it's doing something else.

这是个很好的例子:有时你以为它在做 A,它其实在做 B。

And for the review side, I would love to just chat about that more. I think the linter part that you mentioned, I think maybe people skipped it over. It doesn't register the first time. But, like, going from, like, rule-based linting to, like, semantic linting, I think it's, like, great and super important.

Review 这块我想多聊聊。你刚才说的 linter,很多人可能第一遍听就滑过去了——但从规则式 lint 到语义式 lint,我觉得是了不起且极重要的一步。

And I think a lot of companies are trying to do how do you do autonomous PR review, which I've not seen one that I use so far. They're all kind of, like, mid.

很多公司在做自主 PR review,但到目前为止我没见到一个我真会用的,全都比较平庸。

So I'm curious how you think about closing the loop or making that better and figuring out especially, like, what are you supposed to review? Because these PRs get pretty big when you vibe code.

所以我好奇你们怎么想"闭环"这件事,尤其是:到底该 review 什么?vibe coding 之下 PR 会变得很大。

You know, sometimes I'm like, oh, wow. Oh, LGTM. You know, it's like, am I really supposed to read all of this? It kind of seems, most of it seems pretty standard. But, like, I'm sure there are parts in there that the model wants. I would understand that are, like, kind of out of distribution, so to speak, to really look at. So, yeah, that's a very open-ended question. But any thoughts you have would be great.

有时我就:哇,好长——LGTM。我真的该把这些全读完吗?大部分看起来都很常规,但里面肯定有些"out of distribution"的部分才真正值得细看。这是个很开放的问题,想听听你们的想法。

The way we're thinking about it is Claude Code is, like I said before, it's a primitive. So if you want to use it to build a code review tool, you can do this. If you want to, you know, build, like, a security scanning, vulnerability scanning tool, you can do that. If you want to build a semantic linter, you can do that.

我们的思路是:Claude Code 是一个原语(primitive)。你想用它搭一个 code review 工具,可以;想做安全扫描、漏洞扫描工具,可以;想做语义 linter,也可以。

And hopefully with code, it makes it so if you want to do this, it's just a few lines of code. And you can just have Claude write that code also. Because Claude is really great at writing GitHub actions.

而且有了 Claude Code,这些事希望只需要几行代码就能做到——这几行代码还可以让 Claude 来写,它写 GitHub Action 写得非常好。

Yeah, one thing to mention is we do have a non-interactive mode, which is, like, what Claude uses in these, or how we use Claude in these situations to automate Claude Code. And also a lot of our, the companies using Claude Code actually use this non-interactive mode.

值得一提的是,我们有一个非交互模式——在这些自动化场景里我们就是这么用 Claude Code 的。很多使用 Claude Code 的公司,实际上也在用这个非交互模式。

So they'll, for example, say, hey, I have, like, hundreds of thousands of tests in my repo. Some of them are out of date. Some of them are flaky. And they'll send Claude Code to look at each of these tests and decide, okay, how can I update any of them? Like, should I deprecate some of them? How do I, like, increase our code coverage? So that's been a really cool way that people are non-interactively using Claude Code.

比如有公司说:我仓库里有几十万个测试,有的过时了,有的不稳定。他们就派 Claude Code 挨个去看这些测试,决定哪些要更新、哪些该废弃、怎么提高覆盖率。这是大家非交互式用 Claude Code 的一个很酷的方式。

What are the best practices here? Because when it's non-interactive, it could run forever. And you're not necessarily reviewing the output of everything, right? So I'm just kind of curious, how is it different in non-interactive mode? What are, like, the most important hyperparameters or arguments to solve?

这里的最佳实践是什么?非交互模式下它可能一直跑下去,而你不见得会逐一检查所有输出。非交互模式有什么不同?最重要的"超参数"或命令行参数是哪些?

Yeah, and for folks that haven't used it, so non-interactive mode is just claude -p. And then you pass in the prompt in quotes, and that's all it is. It's just the -p flag.

先科普一下:非交互模式就是 claude -p,把 prompt 用引号传进去,就这么简单,一个 -p 参数。

Generally, it's best for tasks that are read-only. That's the place where it works really well. And you don't, you know, super have to think about permissions and running forever and things like that.

它最适合只读类任务,在那种场景下表现非常好,你也基本不用操心权限、跑不停这类问题。

So, for example, a linter that runs and doesn't fix any issues. Or, for example, we're working on a thing where we use Claude with -p to generate the changelog for Claude. So every PR is just looking over the commit history. And being like, okay, this makes it into the changelog, this doesn't. Because we know people have been requesting changelogs, so we're just getting Claude to build it.

比如一个只报告不修复的 linter。再比如我们正在做一件事:用 claude -p 给 Claude Code 自动生成 changelog——每个 PR 过一遍 commit 历史,判断哪条进 changelog、哪条不进。大家一直在要 changelog,我们就让 Claude 来造。

For tasks where you want to write, the thing we usually recommend is passing a very specific set of permissions on the command line. So what you can do is pass in --allowedTools. And then you can allow a specific tool. So, for example, not just bash, but, for example, git status. Or git diff. So you just give it a set of tools that it can use.

至于需要写操作的任务,我们通常建议在命令行上传一组非常具体的权限:用 --allowedTools 允许特定工具——不是笼统的 bash,而是精确到 git status、git diff。给它一组明确能用的工具。

Or, you know, edit tool, for example. It still has default tools like file read, grep, system tools like bash and ls, and memory tools.

或者比如 edit 工具。它仍然有默认工具:读文件、grep,bash、ls 这类系统工具,还有 memory 工具。

So it still has all these tools, but allowedTools just lets you, instead of the permission prompt, because you don't have that in the non-interactive mode. It's just kind of pre-accepting.

这些工具都还在,allowedTools 的作用是替代权限弹窗——非交互模式下没有弹窗,相当于预先放行。

And we'd also definitely recommend that you start small. So, like, test it on one test. Make sure that it has reasonable behavior. Iterate on your prompt. Then scale it up to 10. Make sure that it succeeds. Or if it fails, just, like, analyze what the patterns of failures are. And gradually scale up from there. So definitely don't kick off a run to fix, like, 100,000 tests.

另外强烈建议从小规模开始:先在一个测试上跑,确认行为合理,打磨你的 prompt;再扩到 10 个,确认成功——失败就分析失败的模式;然后逐步往上扩。千万不要一上来就开一个修 10 万个测试的任务。

I think the... So at this point, I just, you know, I want to... This tagline is in my head that basically at Anthropic, there's Claude Code generating code. And then Claude Code also reviewing its own code. Like, at some point, right? Like, different people are setting all this up. You don't really govern that. But it's happening.

我脑子里已经有一句 tagline 了:在 Anthropic,Claude Code 在生成代码,Claude Code 同时也在 review 自己的代码。不同的人在各自搭这些流程,你们并不真的去管,但它就在发生。

Yeah, we have to be, you know, at Anthropic, there's still a human in the loop for reviewing. And I think for, you know, for ASL, this is important. So, like, for general, like, model alignment and safety.

在 Anthropic,review 环节仍然必须有人在环。对 ASL(安全等级)来说这很重要——事关整体的模型对齐与安全。

What's ASL? — Oh, so ASL, this is, like, the kind of the safety levels. — What does it stand for? — AI safety level. — Sorry, I'm not used to the acronyms. We have a lot of these. But you've published stuff. I know. I just don't know what they're called internally.

ASL 是什么?——(Boris:)就是那套安全等级。——全称是什么?——(Cat:)AI 安全等级。——抱歉,这些缩写我还不熟。你们发表过相关内容,我只是不知道内部怎么叫它。

But the point of the thing I was thinking about was we have, you know, VPs of Eng, CTOs listening. Like, this is all well and good for the individual developer. But the people who are responsible for the tech, the entire code base, the engineering decisions, all this is going on.

我真正想问的是:听众里有 VP of Eng、有 CTO。这一切对个人开发者来说都很美好,但对要为技术、为整个代码库、为工程决策负责的人呢?

My developers, like, I manage, like, 100 developers. Any of them could be doing any of this at this point. What do I do to manage this? How does my code review process change? How does my change management change? I don't know.

假设我管着 100 个开发者,现在他们任何一个人都可能在做这些事。我该怎么管?我的 code review 流程要怎么变?变更管理要怎么变?

We've talked to a lot of VPs and CTOs. They're really excited about it. They actually tend to be quite excited because they experiment with the tool. They download it. They ask it a few questions.

我们聊过很多 VP 和 CTO,他们其实相当兴奋。因为他们会亲自试这个工具:下载下来,问它几个问题。

And, like, Claude Code, when it gives them sensible answers, they're really excited because they're like, oh, I can understand this nuance in the code base. And sometimes they even ship small features with Claude Code.

当 Claude Code 给出靠谱回答时,他们会很兴奋:哦,我能看懂代码库里这些细微之处了。有时他们甚至自己用 Claude Code ship 几个小功能。

And I think through that process of, like, interacting with the tool, they build a lot of trust in it. And a lot of folks actually come to us and they ask us, like, how can I roll it out more broadly? And then we'll often, like, have sessions with, like, VPs of Dev Prod and talk about these concerns around how do we make sure people are writing high-quality code.

在和工具互动的过程中,他们建立起了信任。很多人会主动来问:我怎么在公司里更大范围推开?我们也常和 Dev Prod 的 VP 们开会,讨论"怎么保证大家写出高质量代码"这类顾虑。

I think in general, it's still very much up to the individual developer to hold themselves up to a very high standard for the quality of code that they merge.

总体而言,对自己 merge 进去的代码保持高标准,这件事仍然落在每个开发者自己身上。

Even if we use Claude Code to write a lot of our code, it's still up to the individual who merges it to be responsible for, like, this being well-maintained, well-documented code that has, like, reasonable abstractions.

即便大量代码由 Claude Code 来写,按下 merge 的那个人,依然要为代码可维护、文档齐全、抽象合理负责。

And so I think that's something that will continue to happen where Claude Code isn't its own engineer that's, like, committing code by itself. It's still very much up to the ICs to be responsible for the code that's produced.

这一点会持续下去:Claude Code 不是一个自己提交代码的"独立工程师",产出的代码仍然由 IC 们负责。

I think Claude Code also makes a lot of this stuff, a lot of quality work becomes a lot easier. So, for example, like, I have not manually written a unit test in many months.

Claude Code 也让很多质量工作变容易了。比如,我已经好几个月没手写过单元测试了。

And we have a lot of unit tests. We have a lot of unit tests.

而我们的单元测试非常多。真的非常多。

And it's because Claude writes all the tests. And, you know, before, I felt like a jerk if on someone's PR, I'm like, hey, can you write a test? Because, you know, they kind of know they want to… For code coverage? Is that still relevant? For code coverage, yeah.

因为测试全是 Claude 写的。以前在别人的 PR 下面说"嘿,能补个测试吗",我都觉得自己像个混蛋——为了覆盖率嘛。

And, you know, they kind of know they should probably write a test and that's probably the right thing to do. And somewhere in their head, they make that trade-off where they just want to ship faster. And so you always kind of feel like a jerk for asking.

对方其实也知道该写测试、写测试是对的,只是脑子里权衡了一下,更想快点 ship。所以你开口要求,总觉得自己讨人嫌。

But now I always ask because Claude can just write the test. And, you know, there's no human work. You just ask Claude to do it and it writes it.

但现在我每次都会要求,因为 Claude 直接就能把测试写了,不费人力——让 Claude 写,它就写好了。

And I think with writing tests becoming easier and with the writing lint rules becoming easier, it's actually much easier to have high-quality code than it was before.

写测试更容易、写 lint 规则也更容易之后,维持高质量代码其实比以前轻松多了。

What are the metrics that you believe in? Like, is it… A lot of people actually don't believe in 100% code coverage. Because sometimes that is kind of optimizing for the wrong thing. Arguably, I don't know. But like, obviously, you have a lot of experience in different code quality metrics. But what still makes sense?

你信哪些指标?很多人其实不信 100% 测试覆盖率,因为那有时是在优化错误的目标。你在各种代码质量指标上经验很多——现在还有哪些指标是说得通的?

I think it's very engineering team dependent, honestly. I wish there was a one-size-fits-all answer.

说实话,这非常取决于具体的工程团队。我也希望有一个万能答案。

For some teams, test coverage is extremely important. For other teams, type coverage is very important. Especially if you're working in, you know, very strictly typed language. And, you know, for example, avoiding, like, anys in JavaScript and Python.

有的团队,测试覆盖率极其重要;有的团队,类型覆盖率更重要——尤其是在强类型语言里,比如避免 JavaScript 和 Python 里的 any。

I think cyclomatic complexity kind of gets a lot of flack. But it's still, honestly, a pretty good metric just because there isn't anything better in terms of ways to measure. For code quality.

圈复杂度老是挨骂,但平心而论它依然是个不错的指标——只是因为在衡量代码质量这件事上,还没有更好的办法。

And then productivity is obviously not lines of code. But do you care about measuring productivity? I'm sure you do.

那生产力呢?显然不能用代码行数衡量。但你们在乎度量生产力吗?肯定在乎吧。

Yeah. You know, lines of code, honestly, isn't terrible. Oh, God. It has downsides. Yeah. It's terrible. Well, lines of code is terrible for a lot of reasons. Yes. But it's really hard to make anything better. It's the least terrible. It's the least terrible.

其实……代码行数没那么糟。(我的天。)它有缺点,好吧,它很糟——出于很多原因都很糟。但真的很难找到更好的。它是"最不糟的那个"。

There's, like, lines of code, maybe, like, number of PRs. How green your GitHub is.

可选的无非是:代码行数、PR 数量、你的 GitHub 有多绿。

Yeah. The two that we're really trying to nail down are, one, decrease in cycle time. So how much faster are your features shipping because you're using these tools? So that might be something like the time between first commit and when your PR is merged. It's very tricky to get right, but one of the ones that we're targeting.

我们真正想钉死的指标有两个。第一是 cycle time 的缩短:用了这些工具后,你的 feature ship 得快了多少?比如从第一个 commit 到 PR merge 的时间。这个很难量准,但它是我们的目标之一。

The other one that we want to measure more rigorously is, like, the number of features that you wouldn't have otherwise built.

另一个想更严格度量的,是"如果没有它你根本不会去做的 feature"的数量。

We have a lot of channels where we get customer feedback. And one of the patterns that we've seen with Claude Code is that sometimes customer support or customer success will, like, post, hey, like, this app has, like, this bug. And then sometimes 10 minutes later, one of the engineers on that team will be, like, Claude Code made a fix for it.

我们有很多收集客户反馈的渠道。一个反复出现的模式是:客服或客户成功发帖说"这个 app 有个 bug",有时 10 分钟后,那个团队的某位工程师就回:Claude Code 已经修好了。

And a lot of those situations when you, like, ping them and you're, like, hey, that was really cool, they were, like, yeah, without Claude Code, I probably wouldn't have done that because it would have been too long. It would have been too much of a divergence from what I was otherwise going to do. It would have just ended up in this long backlog. So this is the kind of stuff that we really want to measure more rigorously.

事后去问他们"刚才那个很酷啊",对方往往说:没有 Claude Code 我大概不会去修——耗时太长、偏离我手头的事太远,最后只会沉进长长的 backlog。这类东西正是我们想更严格度量的。

That was the other AGI-pilled moment for me. There was a really early version of Claude Code many, many months ago. And this one engineer at Anthropic, Jeremy, built a bot that looked through a particular feedback channel on Slack. And he hooked it up to code to have code automatically put up PRs with just fixes to all this stuff.

那是另一个让我"AGI 觉醒"的时刻。很多个月前,Claude Code 还是极早期版本时,Anthropic 的工程师 Jeremy 做了一个 bot,盯着 Slack 上某个反馈频道,接上 Claude Code,自动为那些问题提修复 PR。

And some of this stuff, you know, it didn't fix every issue. But it fixed a lot of the issues. You say, like, 10%, 50%? You know, this was, like, early on, so I don't remember the number. But it was surprisingly high to the point where I became a believer in this kind of workflow. And I wasn't before.

它没能修掉每一个问题,但修掉了很多。比例是 10% 还是 50%?太早了,数字我记不清了——但高到让我信了这种工作流。在那之前我是不信的。

Isn't that scary, too, in a way? Where you can build too many things, it's almost like maybe you shouldn't build that many things. I think that's what I'm struggling with the most. It's, like, it gives you the ability to create, create, create. But then at some point, you've got to support, support, support.

这从某种角度看是不是也挺吓人?你能做的东西太多了——多到也许你本就不该做那么多。这是我最纠结的:它给你的是不停创造、创造、创造的能力,但到了某个时候,你就得不停维护、维护、维护。

This is the Jurassic Park, like, your scientists were so preoccupied with what you're doing. Yeah, exactly.

这就是《侏罗纪公园》那句:你们的科学家光顾着想"能不能做",忘了问"该不该做"。——对,正是。

How do you make decisions? Like, now that the cost of actually implementing the thing is going down as a PM, how do you decide what is actually worth doing?

作为 PM,既然实现东西的成本在不断下降,你怎么做决策?怎么判断什么才真正值得做?

Yeah, we definitely still hold a very high bar for net new features. Most of the fixes were, like, hey, this functionality is broken or this, like, there's a weird edge case that we hadn't addressed yet. So it was very much, like, smoothing out the rough edges as opposed to building something completely net new.

对全新 feature,我们仍然保持非常高的门槛。前面说的那些修复,大多是"这个功能坏了"或者"有个怪异的 edge case 没处理"——属于打磨毛边,而不是从零造新东西。

For net new features, I think we hold a pretty high bar. High bar that it's very intuitive to use. The new user experience is, like, minimal. It's just, like, obvious that it works.

全新 feature 的门槛是:用起来必须非常直觉,新用户的学习成本接近于零,一看就知道能用。

We sometimes actually use Claude Code to prototype instead of using docs. Yeah, so you'll have, like, prototypes that you can play around with. And that often gives us a faster feel for, hey, is this feature ready yet? Or, like, is this the right abstraction? Is this the right interaction pattern?

我们有时干脆用 Claude Code 做原型,替代写文档——你直接拿到可以上手玩的原型。这能更快地给我们体感:这个 feature 成熟了吗?抽象对不对?交互模式对不对?

So it gets us faster to feeling really confident about a feature. But it doesn't circumvent the process of us making sure that the feature definitely fits in, like, the product vision.

它让我们更快地对一个 feature 建立信心,但不会绕过"确认它真的符合产品愿景"这道工序。

It's interesting how as it gets easier to build stuff, it changes the way that I write software. Where, like Cat's saying, like, before I would write a big design doc. And I would think about a problem for a long time before I would build it sometimes for some set of problems.

有意思的是,做东西变容易之后,我写软件的方式也变了。像 Cat 说的:以前对某类问题,我会先写一份很长的设计文档,把问题想很久才动手。

And now I'll just ask Claude Code to prototype, like, three versions of it. And I'll try the feature and see which one I like better. And then that informs me much better and much faster than a doc would have.

现在我直接让 Claude Code 做三个版本的原型,挨个试,看更喜欢哪个。这比文档给我的判断依据更好、也快得多。

And I think we haven't totally internalized that transition yet in the industry.

而我认为整个行业还没有完全消化这个转变。

Yeah, I feel the same way for some tools I build internally. People ask me, could we do this? And I'm like, I'll just, yeah, just build it. It's like, well, it feels pretty good. We should, like, polish it, you know? Or sometimes it's like, no, that's not.

我做内部工具时感觉一样。有人问"我们能做这个吗",我就:直接做出来呗。做完一试——嗯,感觉不错,那就打磨一下;或者:不行,不是这么回事。

It's comforting that, you know, like, your max cost is, I mean, even at Anthropic where it's theoretically unlimited. The cost is roughly $6 a day. That gives people peace of mind. Because I'm like, $6 a day? Fine. $600 a day, we have to talk.

让人安心的是成本有谱——即使在理论上不限量的 Anthropic 内部,平均也就一天 $6 左右。这让人心里有底:一天 $6?没问题。一天 $600?那咱得谈谈了。

Like, you know. Yeah. I paid $200 a month to make Studio Ghibli photos. So it's all good. That is totally worth it.

我还花 $200 一个月生成吉卜力风格照片呢,所以都还好,完全值。

You mentioned internal tools. And that's actually a really big use case that we're seeing emerge. Because a lot of times, if you're working on something operationally intensive, if you can spin up an internal dashboard for it. Or, like, an operational tool where you can, for example, grant access to a thousand emails at once.

你提到内部工具——这正是我们看到的一个正在爆发的大场景。很多时候你做的事运营属性很重,如果能快速拉一个内部 dashboard,或者一个运营工具,比如一次给一千个邮箱批量开权限,就太有用了。

A lot of these things, you don't really need to have, like, a super polished design. You kind of just need something that works. And Claude Code's really good at those kinds of zero to one tasks.

这类东西不需要多精致的设计,能用就行。而 Claude Code 非常擅长这种零到一的任务。

Like, we use Streamlit internally. And there's been, like, a proliferation of how much we're able to visualize. And because we're able to visualize it, we're able to see patterns that we wouldn't have otherwise. If we were just looking at, like, raw data.

我们内部用 Streamlit,可视化的数量出现了爆发式增长。因为能可视化,我们看到了只盯原始数据时根本看不到的模式。

Yeah. Like, I was working on also this, like, side website last week. And I just showed Claude Code the mock. So I just took the, you know, the screenshot I had, dragged and dropped it into the terminal. And I was like, hey, Claude, here's the mock. Can you implement it?

上周我在做一个 side project 网站。我直接把设计 mock 给 Claude Code 看——截图拖进终端,说:嘿 Claude,这是 mock,能实现吗?

And it implemented. And it looked like, you know, it sort of worked. It was a little bit crummy. And I was like, all right, now look at it in Puppeteer and, like, iterate on it until it looks like the mock. And then it did that three or four times. And then the thing looked like the mock. This was just all manual work before.

它实现了,大致能跑,但有点糙。我接着说:现在用 Puppeteer 看看自己的成果,迭代到和 mock 一样为止。它来回迭代了三四次,东西就和 mock 一模一样了。这些以前全是手工活。

I think we're going to ask about, like, two other features of, I guess, the overall agent pieces that we mentioned. So I'm interested in memory as well. So we talked about autocompact and memory using hashtags and stuff.

我们想再问两个 agent 整体拼图里的功能。我对 memory 很感兴趣——前面聊了 autocompact 和用 # 号记忆这些。

My impression is that your, like you say, simplest approach works. But I'm curious if you've seen any other requests that are interesting to you or internal hacks of memory that people have explored that, like, you know, you might want to surface to others.

我的印象是,像你们说的,最简单的方案就够用。但有没有什么有意思的需求,或者内部玩出来的 memory hack,值得分享给大家?

There's a bunch of different approaches to memory. Most of them use external stores of various sorts. Like Chroma. Exactly. Yeah. There's a lot of projects like that. And, yeah, it's either a K value or kind of, like, graph stores. That's, like, the two big shapes for these.

记忆有一堆不同做法,大多用某种外部存储,比如 Chroma,这类项目很多。基本就两种形态:KV 存储,或者图存储。

Are you a believer in knowledge graphs for this stuff? You know, I'm a big, if you talked to me before I joined Anthropic and this team, I would have said, yeah, definitely.

(Swyx:)你信 knowledge graph 这套吗?——如果你在我加入 Anthropic 和这个团队之前问我,我会说:信,绝对信。

But now, actually, I feel everything is the model. Like, that's the thing that wins in the end. And it just, as the model gets better, it subsumes everything else.

但现在,我真心觉得一切都是模型。最终赢的是模型——它越变越好,会把其他所有东西都吞掉。

So, you know, at some point, the model will encode its own knowledge graph. It'll encode its own, like, KV store if you just give it the right tools.

到某个时候,只要给它合适的工具,模型会自己编码它的 knowledge graph,自己编码它的 KV store。

But, yeah, I think the specific tools, there's still a lot of room for experimentation. We just, we don't, we don't know yet.

不过具体用什么工具,还有很大的实验空间。我们也还不知道答案。

In some ways, are we just coping for lack of context length? Like, are we doing things for memory now that if we had, like, 100 million token context window, we don't care about?

某种意义上,我们是不是只是在为 context 长度不够"打补丁"?如果有一亿 token 的上下文窗口,现在这些 memory 工作是不是根本不用做?

I would love to have 100 million.

一亿 token,我做梦都想要。

I mean, you know, some people have claimed to have done it. We don't know if that's true or not.

有人声称做到了,真假我们也不知道。

I guess here's a question for you, Sean. If you took all the world's knowledge and you put it in your brain. And let's say, you know, there is, like, some treatment that you could get to make it so your brain can have any amount of context. You have, like, infinite neurons. Is that something that you would want to do or would you still want to record knowledge externally?

那我反问你一个问题,Sean:假如把全世界的知识都装进你的大脑——假设有某种"手术"能让你的大脑容纳任意多的 context,神经元无限。你会想要这样吗?还是仍然想把知识记录在外部?

Putting it in my head is, like, different for me trying to use an agent tool to do it because I'm trying to control the agent. And I'm trying to make myself unlimited, but I want to make the tools that I use limited because then I know how to control them.

装进我自己脑子,和用一个 agent 工具去装,对我是两回事——因为我要控制这个 agent。我想让自己无限,但想让我用的工具有限,因为有限我才知道怎么控制。

And it's not even, like, a safety argument. It's just more like I want to know what you know. And if you don't know a thing, then sometimes that's good. Like the ability to audit what's in it.

这甚至不是安全层面的论证,更多是:我想知道你知道什么。有时候你"不知道某件事"反而是好事——关键是可审计。

And I don't know if this is the small brain thinking because this is not very bitter lesson, which is, like, actually sometimes you just want to control every part of what goes in there in the context. And the more you just, you know, Jesus takes care of it. Like, if you really trust the model, then you have no idea what it's paying attention to.

不知道这算不算"小脑瓜思维",毕竟这很不 bitter lesson——有时你就是想控制进入 context 的每一部分。而越是"交给上帝"、越是完全信任模型,你就越不知道它在注意什么。

Yeah. I don't know. Did you see the Mech Interp stuff from Chris Olah and the team that was published? Like last week? What about it? I wonder if something like this is the future. So there's an easier way to audit the model itself. And so if you want to see, like, what is stored, you can just audit the model.

不好说。你看了 Chris Olah 团队上周发的机制可解释性(Mech Interp)研究吗?我在想那会不会就是未来:有更容易的办法直接审计模型本身——想知道里面存了什么,直接审计模型就行。

Yeah. The main salient thing is that they know what features activate it per token and they can tune it up, suppress it, whatever. But I don't know if it goes down to the individual, like, item of knowledge from context, you know. Not yet.

那项研究最突出的是:他们知道每个 token 激活了哪些 feature,还能调高、抑制。但能不能细到"context 里的某一条具体知识",我觉得还到不了。

Yeah. But I wonder, you know, maybe that's the bitter lesson version of it.

是啊。但我在想,也许那才是这个问题的 bitter lesson 版答案。

We've been seeing people play around with memory in quite interesting ways, like having Claude write a logbook of all the actions that it's done. So that over time, Claude develops this understanding of what your team does, what you do within your team, what your goals are. How you like to approach work.

我们看到大家在用很有意思的方式玩 memory,比如让 Claude 写一本"行动日志",记录它做过的所有事。时间一长,Claude 就形成了对你团队做什么、你在团队里做什么、你的目标是什么、你喜欢怎么干活的理解。

We would love to figure out what the most generalized version of this is so that we can share broadly.

我们很想搞清楚这件事最通用的形态是什么,然后大范围分享出去。

I think with things like Claude Code, it's actually less work to implement the feature and a lot of work to tune these features to make sure that they work well for general audiences, like across a broad range of use cases. So there's a lot of interesting stuff with the memory, and we just want to make sure that it works well out of the box before we share it broadly.

像 Claude Code 这类产品,实现一个 feature 的工作量其实不大,大头在调优——要确保它对广大用户、在各种用例下都好用。memory 这块有很多有意思的东西,我们只是想确保它开箱即用之后再放出来。

I think there's a lot more to be developed here. I guess a related problem to memory is how do you get stuff into context? Knowledge base. Knowledge base, yeah.

这里还有很多可以发展的。和 memory 相关的另一个问题是:怎么把东西弄进 context?也就是 knowledge base。

And originally, we tried very, very early versions of Claude actually used RAG. So we, like, indexed the code base, and I think we were just using Voyage. So, you know, just off-the-shelf RAG, and that worked pretty well.

最初,Claude Code 非常非常早的版本其实用的是 RAG:我们给代码库建索引,用的应该就是 Voyage——现成的 RAG 方案,效果还不错。

And we tried a few different versions. There was RAG, and then we tried a few different kinds of search tools. And eventually, we landed on just agentic search as the way to do stuff.

我们试了几个版本:RAG,然后是几种不同的搜索工具。最终落在了 agentic search 上。

And there were two big reasons, maybe three big reasons. So one is it outperformed everything. By a lot. By a lot. And this was surprising. In what benchmark? This was just vibes, so internal vibes. There's some internal benchmarks also, but mostly vibes. It just felt better.

原因有两个,或者说三个。第一:它的表现超过了所有其他方案,而且是大幅超过——这很出乎意料。(Swyx:)在什么 benchmark 上?——主要靠 vibes,内部 vibes。也有一些内部 benchmark,但主要是 vibes:它用起来就是更好。

And agentic RAG, meaning you just let it look up in however many search cycles it needs.

所谓 agentic 检索,就是让它想搜几轮就搜几轮?

Just using regular code searching, you know, glob, grep, just regular code search. So there was, like, one.

就用常规的代码搜索:glob、grep,普通的代码检索。这是第一点。

And then the second one was there was this whole, like, indexing step that you have to do for RAG. And there's a lot of complexity that comes with that because the code drifts out of sync.

第二点:RAG 需要一整个建索引的步骤,复杂度随之而来——代码会和索引漂移失同步。

And then there's security issues because this index has to live somewhere. And then, you know, what if that provider gets hacked? And so it's just a lot of liability for a company to do that. You know, even for our code base, it's very sensitive. So we're kind of, we don't want to upload it to a third-party thing. It could be a first-party thing. But then we still have this out-of-sync issue.

还有安全问题:索引必须存在某个地方,万一那个服务商被黑了呢?对企业来说是一大笔风险敞口。即使是我们自己的代码库也非常敏感,我们不想传给第三方;就算自己托管,失同步的问题依然在。

And agentic search just sidesteps all of that. So essentially, at the cost of latency and tokens, you now have really awesome search without security downsides.

而 agentic search 把这一切都绕开了。本质上,你用延迟和 token 作为代价,换来了非常出色的搜索,而且没有安全隐患。

Well, memory is like planning, right? There's kind of, like, memory is, like, what I like to do. And then planning is, like, now use those memories to come up with a plan to do these things.

memory 和 planning 是一体两面吧?memory 是"我喜欢怎么做事",planning 则是用这些记忆,拿出一个做事的计划。

Or maybe put it as, like, memory is sort of the past. Like, what we already did. And then planning is kind of what we will do. And it just crosses over at some point.

或者这么说:memory 是过去——我们已经做了什么;planning 是未来——我们将要做什么。两者在某个点交汇。

I think the maybe slightly confusing thing from the outside is what you define as thinking. So there's, like, extended thinking. There's the think tool. And it's kind of, like, thinking as in planning, which is, like, thinking before execution. And then there's, like, thinking while you're doing, which is, like, the think tool. Can you maybe just run people through the difference?

从外部看,稍微让人迷糊的是你们对 thinking 的定义:有 extended thinking,有 think tool;有"规划式思考"——执行前先想;还有"边做边想"——也就是 think tool。能给大家捋一捋区别吗?

I'm already confused listening to you.

光听你问我就已经晕了。

Well, it's one tool. So Claude can think if you ask it to think.

其实就是一件事:你让 Claude 思考,它就会思考。

Generally, the usage pattern that works best is you ask Claude to do a little bit of research. Like, use some tools, pull some code into context, and then ask it to think about it. And then it can make a plan and, you know, do a planning step before you execute.

效果最好的使用模式是:先让 Claude 做点研究——用几个工具,把相关代码拉进 context——然后让它思考,做一个 plan,在执行之前完成规划这一步。

There's some tools that have explicit planning modes. Like, RooCode has this and Cline has this. Other tools have it. Like, you can shift between, you know, plan and act mode or maybe a few different modes.

有些工具有显式的规划模式,比如 RooCode 有,Cline 有,别的工具也有——可以在 plan 模式和 act 模式之间切换,或者有好几种模式。

We've sort of thought about this approach. But I think our approach to product is similar to our approach to the model, which is Bitter Lesson. So just freeform. Keep it really simple. Keep it close to the metal.

我们考虑过这种做法。但我们做产品的思路和做模型一致:bitter lesson——保持自由形态,保持极简,贴着"金属"走。

And so if you want Claude to think, just tell it to think. Be like, you know, make a plan. Think hard. Don't write any code yet. And it should generally follow that. And you can do that also as you go. So maybe there's a planning stage and then Claude writes some code or whatever. And then you can ask it to think and plan a little bit more. You can do that anytime.

想让 Claude 思考,直接说就行:"做个计划。好好想。先别写代码。"它一般会照做。而且你随时可以来:先规划,Claude 写了点代码,然后再让它停下来多想想、多规划一点——任何时候都行。

Yeah, I was reading through the think tool blog post. And it said, while it sounds similar to extended thinking, it's a different concept. Extended thinking is what Claude does before it starts generating. And then think it, once it starts generating, how do you stop and think?

我读过 think tool 那篇博客,里面说:虽然听起来像 extended thinking,但是不同的概念——extended thinking 是 Claude 开始生成之前做的;而 think tool 是开始生成之后,怎么停下来思考。

Is this all done by the Claude Code harness? So people don't really have to think about the difference between the two, basically, is the idea? Yeah, you don't have to think about it. Okay. That is helpful. Because sometimes I'm like, man, am I not thinking right?

这些都由 Claude Code 的 harness 处理掉了?也就是说用户根本不用管两者的区别?——(Boris:)对,你不用管。——那就好。有时候我真的会想:天,是不是我 think 的姿势不对?

Yeah. And it's all chain of thought, actually, in Claude Code. So we don't use the think tool. Anytime that Claude Code does thinking, it's all chain of thought.

实际上 Claude Code 里全是 chain of thought,我们没有用 think tool。Claude Code 里所有的思考都是 chain of thought。

I had an insight. This is, again, something we had, a discussion we had before recording, which is in the Claude Plays Pokemon hackathon. We had access to more sort of branching environments feature, which meant that we could take any VM state, branch it, play it forward a little bit, and use that in the planning.

我有个洞察——也是录制前我们聊到的:在 Claude Plays Pokemon 的 hackathon 上,我们用到了"环境分支"的能力:可以取任意 VM 状态,分个叉,往前推演一段,把结果用于规划。

And then I realized. The TLDR of yesterday was basically that it's too expensive to just always do that at every point in time. But if you give it as a tool to Claude and prompt it, in certain cases, to use that tool, seems to make sense.

昨天的 TLDR 基本是:每个时间点都这么干太贵了。但如果把它作为一个工具给 Claude,在特定情况下提示它使用,似乎是说得通的。

I'm just kind of curious, like your takes on overall, like, sandboxing, environment, branching, rewindability, maybe, which is something that you immediately brought up, which I didn't think about. Is that useful for Claude? Or Claude has no opinions about it?

很好奇你们整体怎么看 sandbox、环境分支、可回退性——可回退是你刚才马上提到的,我都没想到。这些对 Claude 有用吗?

Yeah, I could talk for hours about this.

这个话题我能聊上几个小时。

Claude probably can too. Let's get original tokens from you, and then we can train Claude on that. By the way, that's like explicitly what this podcast is. We're just generating tokens for people. Is this the pre-training or the post-training? It's a pre-trained data set. We got to get in there.

Claude 估计也能聊几个小时。先从你这儿拿点原创 token,我们好拿去训练 Claude。说起来,这播客干的就是这事——给大家生成 token。这算预训练还是后训练?——是预训练数据集,我们得混进去。

Yeah. How do I buy? How do I get some tokens? Starting with sandboxing, ideally, the thing that we want is to always run code in a Docker container. And then it has freedom. And you can kind of snapshot, you know, with other kind of tools later on top. You can snapshot, rewind. Do all this stuff.

哈哈,token 怎么买?——先说 sandbox。理想状态是永远在 Docker 容器里跑代码:它有充分自由,你还可以在上面叠各种工具,做快照、回退,想干嘛干嘛。

Unfortunately, working with a Docker container for everything is just like a lot of work, and most people aren't going to do it. And so we want some way to simulate some of these things without having to go full container.

可惜的是,事事都套一层 Docker 实在太麻烦,大多数人不会这么干。所以我们想找到某种方式,不用完整容器也能模拟出其中一部分能力。

There's some stuff you can do today. So, for example, something I'll do sometimes is if I have a planning question or a research type question, I'll ask Claude to investigate a few paths in parallel.

今天已经有些事能做了。比如我自己有时的用法:遇到规划类或研究类的问题,我会让 Claude 并行调查几条路径。

And you can do this today if you just ask it. So say, you know, I want to refactor X to do Y. Can you research three separate ideas for how to do it? Do it in parallel. Use three agents to do it.

这今天就能做到,直接开口就行:"我想把 X 重构成 Y。帮我研究三种不同的做法,并行做,用三个 agent。"

And so in the UI, when you see a task that's actually like a sub-Claude, it's a sub-agent that does this. And usually when I do something hairy, I'll ask it to just investigate, you know, three times or five times or however many times in parallel. And then Claude will kind of pick the best option and then summarize that for you.

UI 里你看到的 task,其实就是一个 sub-Claude、一个 sub-agent 在干活。遇到棘手的事,我通常让它并行调查三遍、五遍,随便多少遍,然后 Claude 会挑出最好的方案,给你一份总结。

But how does Claude pick the best option? Don't you want to choose? What's your handoff between you should pick versus I should be the final decider?

但 Claude 怎么挑"最好的方案"?难道你不想自己选吗?"它来挑"和"我做最终决定"之间的交接线在哪?

I think it depends on the problem. You can also ask Claude to present the options to you.

看问题。你也可以让 Claude 把所有选项摆出来给你看。

Probably, you know, it exists at a different part of the stack than Claude Code specifically. Claude Code as a CLI, like you could use it in any environment. So it's up to you to compose it together.

这事大概存在于栈里和 Claude Code 不同的另一层。Claude Code 作为 CLI,什么环境都能用,怎么组合取决于你自己。

Should we talk about how and when models fail? Because I think that was another hot topic for you. I'll just leave it open. Like, how do you observe Claude Code failing?

我们聊聊模型在什么时候、以什么方式失败吧——这也是你们的热门话题。开放式提问:你们观察到 Claude Code 是怎么失败的?

There's definitely a lot of room for improvement in the models, which I think is very exciting. Most of our research team actually uses Claude Code day to day. And so it's been a great way for them to be very hands on and like experience the model failures, which makes it a lot easier for us to target these in model training and to actually provide better models, not just for Claude Code, but for like all of our coding customers.

模型确实还有很大改进空间,这反而让人兴奋。我们研究团队的大多数人每天都在用 Claude Code,这让他们能非常一线地亲历模型的失败——于是我们在模型训练里就更容易瞄准这些问题,产出更好的模型,受益的不只是 Claude Code,而是所有做编程的客户。

I think one of the things about the latest Sonnet 3.7 is it's a very persistent model. It's like very, very motivated to accomplish the user's goals. But it sometimes takes the user's goal very literally.

最新的 Sonnet 3.7 有个特点:非常执着。它特别特别想完成用户的目标,但有时把目标理解得过于字面。

And so it doesn't always fulfill what like the implied parts of the request are, because it's just so narrowed in on like, I must get X done.

于是请求里那些"言外之意"它不一定会满足,因为它满脑子都是:我必须把 X 搞定。

And so we're trying to figure out, okay, how do we give it a bit more common sense so that it knows the line between trying very hard and like, no, the user definitely doesn't want that.

我们在想办法给它多一点常识,让它分得清那条线:一边是"拼尽全力",一边是"不行,用户绝对不想要这个"。

Like the classic example is like, hey, go on, get this test to pass. And then, you know, like five minutes later. It's like, all right, well, I hard-coded everything. The test passes. I'm like, no, that's not what I wanted. Hard-coded the answer.

经典例子:你说"去,把这个测试跑过"。五分钟后它回来:"好了,我把所有东西都 hard-code 了,测试通过了。"我说:不,我要的不是这个——你把答案写死了。

But that's the thing. Like it only gets better from here. Like these use cases work sometimes today, not, you know, not every time. And, you know, the model sometimes tries too hard, but it only gets better.

但关键在于:从这里开始,它只会越来越好。这些用例今天是"有时能行",不是每次都行;模型有时用力过猛——但它只会越来越好。

Yeah. Like context, for example, is a big one where like a lot of times if you have a very long conversation and you compact a few times, maybe some of your original intent isn't as strongly present as it was when you first started. And so maybe the model like forgets some of what you originally told it to do.

context 也是个大问题:对话拉得很长、compact 了好几轮之后,你最初的意图可能就不像开头那么强烈地"在场"了,模型可能会忘掉一部分你最早交代的事。

And so we're really excited about things like larger effective context windows so that you can have these like gnarly, like really long hundreds of thousands of tokens, long tasks, and make sure that Claude Code is on track the whole way through. Like that would be a huge lift, I think, not just for Claude Code, but for every coding company.

所以我们非常期待"更大的有效上下文窗口"这类进展——让你能跑那种几十万 token 的超长硬核任务,并确保 Claude Code 全程不跑偏。这对 Claude Code、对每一家做编程的公司,都会是巨大的提升。

Fun story from David Hershey's keynote yesterday. He actually misses the common sense of 3.5 because 3.7 being so persistent. 3.5 actually had some entertaining stories where apparently it like gave up on tasks and just 3.7 doesn't.

昨天 David Hershey 的 keynote 里有个趣事:他居然怀念 3.5 的"常识",因为 3.7 太执着了。3.5 有些好笑的故事——它会干脆放弃任务,而 3.7 从不放弃。

And when Claude 3.5 gives up, it started like writing a formal request to the developers of the game to fix the game. And he has some screenshots of it, which is excellent. So if you're listening to this, you can find it on the YouTube because we'll post it.

3.5 放弃的时候,会开始给游戏的开发者写一封正式申请,请他们把游戏修好。他还留了截图,绝了。听到这里的朋友可以去 YouTube 找,我们会发出来。

One form of failing, which I kind of like. I kind of wanted to capture was something that you mentioned while we're getting coffee, which is that Claude Code doesn't have that much between session memory or caching or whatever you call that. Right. So it reforms the whole state for whole coffee every single time. So as to make the minimum assumptions on the changes that can happen in between.

还有一种"失败"我反而有点喜欢,是喝咖啡时你提到的:Claude Code 几乎没有跨 session 的记忆或缓存——每次都重新构建全部状态,从而对"两次之间可能发生的变化"做最少的假设。

So like how consistent can it stay? Right. Like I said, I think that one of the failures is that it forgets what it was doing in the past. Unless you explicitly opt in via Claude.md. Or whatever. Is that something you worry about?

那它能保持多稳定?像我说的,失败之一就是它忘了自己过去在干什么——除非你通过 Claude.md 之类的方式显式声明。这是你们担心的事吗?

It's definitely something we're working on. I think like our best advice now for people who want to resume across sessions is to tell Claude to, hey, like, write down the state of this session into this text doc. Probably not the Claude.md, but like in a different doc. And in your new session, tell Claude to read from that doc. But we plan to build in more native ways to handle this specific workflow.

这确实是我们在做的。目前对想跨 session 续接的人,最佳建议是:让 Claude 把本次 session 的状态写进一个文本文档——最好别写进 Claude.md,放另一个文档;新 session 里再让 Claude 去读那个文档。我们计划为这个工作流内建更原生的支持。

There's a lot of different cases of this, right? Like sometimes you don't want Claude to have the context. And it's sort of like Git. Sometimes I just want, you know, a fresh branch that doesn't have any history. But sometimes I've been working on a PR for a while and like I need all that historical context.

这事分很多种情况。有时你恰恰不想让 Claude 带着旧 context——就像 Git:有时我就想要一个干干净净、没有任何历史的新分支;但有时我在一个 PR 上做了很久,需要全部历史上下文。

So we kind of want to support all these cases. And it's tricky to do a one size fits all. But generally our approach to code is to make sure it works out of the box for people without extra configuration. So once we get there, we'll have something.

我们想把这些情况都支持好,但"一招通吃"很难。总的原则还是那条:Claude Code 必须开箱即用、零额外配置。等我们想清楚了,自然会有东西放出来。

Do you see a future in which the commits play a bigger part? Of like in a pull request, like how do we get here? You know, there's kind of like a lot of history in how the code has changed within the PR that informs the model. But today the models are mostly looking at the current state of the branch.

你觉得未来 commit 会扮演更重要的角色吗?比如在一个 PR 里,"我们是怎么走到这一步的"——代码在 PR 内的演变历史对模型是有信息量的,但今天模型基本只看分支的当前状态。

So Claude for, you know, for some things that will actually look at the whole history. So for example, if it's writing, if you tell Claude, hey, make a PR for me, it'll look at all the changes since your branch diverged from main. And then, you know, take all of those into account when generating the pull request message.

某些事情上 Claude 其实会看完整历史。比如你说"帮我提个 PR",它会看从你的分支偏离 main 以来的所有改动,在生成 PR 描述时把这些全部纳入考虑。

You might notice it running git diff as you're using it. I think it's pretty good about just tracking, hey, what changes have happened on this branch or so far and just make sure that it's like understands that before continuing on with the task.

用的时候你可能会注意到它在跑 git diff。它很会跟踪"这个分支到目前为止发生了什么改动",确保自己理解了这些再继续干活。

One thing other people have done is ask Claude to commit after every change. You can just put that in the Claude.md.

还有人这么玩:让 Claude 每改一次就 commit 一次——写进 Claude.md 就行。

There's some of these like power user workflows that I think are super interesting. Like some people are asking Claude to commit after every change. So that they can rewind really easily. Other people are asking Claude to create a worktree every time so that they could have, you know, a few Claudes running in parallel in the same repo.

这类 power user 工作流特别有意思:有人让 Claude 每次改动都 commit,这样回退极其方便;有人让 Claude 每次创建一个 worktree,好在同一个 repo 里并行跑好几个 Claude。

I think from our point of view, we want to support all of this. So again, Claude Code is like a primitive and it doesn't matter what your workflow is. It should just fit in.

从我们的角度,这些都要支持。还是那句话:Claude Code 是个原语,无论你的工作流长什么样,它都应该能嵌进去。

I know that 3.5 Haiku was the number four model on Aider when it came out. Do you see Claude Code have a world in which you have like a commit hook that uses maybe Haiku to do something like the lint? Or stuff and things like that continuously. And then you have 3.7 as the more.

3.5 Haiku 刚出时在 Aider 榜上排第四。你觉得会不会有这样的用法:commit hook 里用 Haiku 持续跑 lint 这类轻活,3.7 留给更重的活?

Yeah, you could actually do this if you want. So you're saying like through like a pre-commit hook or like a GitHub action or?

想做的话现在就能做。你是说通过 pre-commit hook,还是 GitHub Action?

Yeah, yeah, yeah. Say, well, kind of like run Claude Code, like the lint example that you had. I want to run it at each commit locally, like before it goes to the PR.

对对对。比如你刚才那个 lint 例子,我想在每次本地 commit 时就跑,在进 PR 之前。

Yeah, so you could do this today if you want. So in the, you know, if you're using like Husky or like whatever pre-commit hook system you're using or just like Git pre-commit hooks. Just add a line claude -p.

今天就能做。不管你用 Husky 还是别的 pre-commit 系统,或者裸的 Git pre-commit hook——加一行 claude -p 就行。

And then, you know, whatever instruction you have and that'll run every time. Nice. And you just specify Haiku. It's really no difference, right? It's like maybe it'll work a little worse, but like I still support it.

然后写上你的指令,每次都会跑。指定用 Haiku 就行。本质没区别吧?可能效果差一点,但依然支持。

Yeah, you can override the model if you want. Generally, we use Sonnet. We default to Sonnet for most everything just because we find that it outperforms. But yeah, you can override the model if you want.

想换模型可以覆盖设置。我们一般用 Sonnet——几乎所有场景都默认 Sonnet,因为我们发现它就是更强。但你想换就能换。

I don't have that much money to run commit hook on 3.7. Just as a side note on pre-commit hooks. I have worked in places where they insisted on. Having pre-commit hooks. I've worked at places where they insisted they'll never do pre-commit hooks because they get in the way of committing and moving quickly.

用 3.7 跑 commit hook 我可没那么多钱。顺带聊聊 pre-commit hook:我待过坚持必须上 pre-commit 的公司,也待过坚决不上的公司——理由是它妨碍快速提交、快速推进。

I'm just kind of curious. Like, do you have a stance or recommendation? Oh, God. That's like asking about tabs versus spaces. A little bit. But like, you know, I think it is easier in some ways to like if you have a breaking test, go fix the test with Claude Code. In other ways, it's more expensive to run this at every point. So like there's trade-offs.

你有立场或建议吗?——(Boris:)天哪,这跟问 tabs 还是 spaces 差不多。——有点。不过一方面,测试挂了让 Claude Code 去修确实更容易了;另一方面,每个节点都跑一遍也更贵了。有取舍。

I think for me, the biggest trade-off is. You want the pre-commit hook to run pretty quickly so that if you're either if you're a human or if you're a Claude, you don't have to wait like a minute.

对我来说最大的取舍是速度:pre-commit hook 必须跑得够快——无论提交的是人还是 Claude,都不该干等一分钟。

So generally, you know, pre-commit, you know, for our code base should run. Just types. It's like less than, you know, five seconds or so. Like just types and lint maybe. And then more expensive stuff you can put in the GitHub action or GitLab or whatever you're using. Agreed.

所以一般来说,我们代码库的 pre-commit 只跑类型检查,五秒以内——顶多类型加 lint。更贵的检查放到 GitHub Action、GitLab 或者你用的随便什么 CI 里。——(Swyx:)同意。

I don't know. I like putting prescriptive recommendations out there so that people can take this and go like, this guy said it. We should do it in our team. And then that's that's a basis for decisions. Cool. Any other technical stories to tell? You know, I wanted to zoom out into more product-y stuff, but, you know, you can get as technical as you want.

我就喜欢把这种"规定性建议"放出去,这样大家可以拿去说:"这哥们儿说的,我们团队也该这么干。"决策就有了依据。好,还有别的技术故事吗?我本来想拉回产品话题,但你想多技术都行。

I don't know. Like one anecdote that might be interesting is the night before the code launch, we were going through to burn down the last few issues and the team was up like pretty late trying to trying to do this.

讲个可能有意思的小故事:Claude Code 发布前一晚,我们在清最后几个 issue,团队熬到很晚。

And one thing that was bugging me for a while is we had this like markdown rendering that we were using. And it was just, you know, it's like the markdown rendering in Claude today is beautiful. And it's just like really nice rendering in the terminal. And it is bold and, you know, headings and spacing and stuff very nicely.

有件事困扰我很久了:我们当时用的 markdown 渲染。今天 Claude Code 里的 markdown 渲染非常漂亮——终端里的呈现很精致,加粗、标题、间距都恰到好处。

But we tried a bunch of these off the shelf libraries to do it. And I think we tried like two or three or four different libraries. And just nothing was quite perfect. Like sometimes the spacing was a little bit off between a paragraph and like a list. Or sometimes the text wrapping wasn't quite correct. Or sometimes the colors weren't perfect. So each one had all these issues.

但当时我们试了一堆现成的库——两个、三个、四个——没有一个完全令人满意。有的段落和列表之间间距不对,有的折行不正确,有的颜色不完美,每个都有各自的毛病。

And all these markdown renderers are very popular. And they have, you know, thousands of stars on GitHub and have been maintained for many years. But, you know, they're not really built for a terminal.

这些 markdown 渲染器都很流行,GitHub 上几千个 star,维护了很多年——但它们终究不是为终端而生的。

And so the night before the release at like 10 p.m., I'm like, all right, I'm going to do this. So I just asked Claude to write a markdown parser for me. And they wrote it. Zero shot. Yeah. It wasn't quite zero shot. But after, you know, like maybe like one or two prompts, they got it.

于是发布前夜晚上 10 点,我说:行,我来搞定这事。我直接让 Claude 给我写一个 markdown parser。它写出来了。零样本?——不算完全 zero shot,但大概一两个 prompt 之后,它就搞定了。

And, you know, that's the markdown parser that's in code today and the reason that markdown looks so beautiful. That's a fun one.

今天 Claude Code 里跑的就是那个 markdown parser——markdown 之所以这么好看,就是因为它。这个故事挺好玩的。

It's interesting what the new bar is, I guess, for implementing features like this exact example where there's libraries out there that you normally reach for that you find, you know, some dissatisfaction with for literally whatever reason. You could just spin up an alternative and go off of that.

有意思的是"实现功能的新门槛"变了:就像这个例子——你平时会顺手用现成库,但只要有任何不满意的地方,你都可以直接造一个替代品,然后就用它了。

I feel like AI has changed so much and, you know, literally in the last year. But a lot of these problems are, you know, like the example we had before, a feature you might not have built before or you might have used a library. Now you can just do it yourself.

AI 在过去一年里改变了太多东西。很多问题——就像刚才那个例子——以前你要么不做这个 feature,要么用现成库;现在你可以直接自己做。

I think the cost of writing code is going down and productivity is going up. And we just have not internalized what that really means yet.

写代码的成本在下降,生产力在上升。而我们还没有真正消化这件事意味着什么。

But yeah, I expect that a lot more people are going to start doing things like this, like writing your own libraries or just shipping every feature.

我预计会有越来越多人开始这么干:自己写库,或者把每个想做的 feature 都做出来。

Just to zoom out, you obviously do not have a separate Claude Code subscription. I'm curious what the roadmap is. Like, is this just going to be a research preview for much longer? Are you going to turn it into an actual product? I know you were talking to a lot of CTOs. Is there going to be a Claude Code enterprise? What's the vision?

拉远一点看:你们显然还没有单独的 Claude Code 订阅。roadmap 是什么?它会一直停留在 research preview 吗?会变成正式产品吗?你们聊了那么多 CTO,会有 Claude Code 企业版吗?愿景是什么?

Yeah. So we have a permanent team on Claude Code. We're growing the team. We're really excited to support Claude Code in the long run. And so, yeah, well, we plan to be around for a while.

Claude Code 现在有常设团队,而且在扩编。我们会长期支持它——我们打算在这儿待很久。

In terms of subscription itself, it's something that we've talked about. It depends a lot on whether or not most users would prefer that over pay-as-you-go. So far, pay-as-you-go is the most popular.

订阅这事我们讨论过,主要取决于大多数用户是不是真的更想要订阅而非按量付费。到目前为止,按量付费最受欢迎。

I think pay-as-you-go has made it really easy for people to start experiencing the product because there's no upfront commitment. And it also makes a lot more sense with a more autonomous world in which people are scripting Claude Code a lot more.

按量付费让大家上手体验产品的门槛非常低,因为没有前期承诺。而且在一个更自主化的世界里——大家越来越多地用脚本驱动 Claude Code——按量付费也合理得多。

But we also hear the concern around, hey, I want more price predictability if this is going to be my go-to tool. So we're very much still in the stages of figuring that out.

但我们也听到另一种声音:"如果这要成为我的主力工具,我想要更可预测的价格。"所以这块我们确实还在摸索。

I think for enterprises, given that Claude Code is very much like a productivity multiplier for ICs. And most ICs can adopt it directly. We've been just like supporting enterprises as they have questions around security and productivity monitoring. And so, yeah, we've found that a lot of folks see the announcement and they want to learn more. And so we've been just engaging in those.

企业侧,Claude Code 本质是 IC 的生产力放大器,而大多数 IC 可以直接用起来。我们主要在帮企业解答安全、生产力监测这类问题。很多人看到发布公告就想深入了解,我们就一个个去聊。

Do you have a credible number for the productivity improvement? Like for people who are not in Anthropic that you've talked to, like, you know, are we talking 30%? Some number would help justify things.

生产力提升有靠谱的数字吗?比如你们聊过的 Anthropic 之外的人——是 30% 这个量级吗?有个数字才好说服别人。

We're working on getting this. It's something we're actively working on. But anecdotally for me, it's probably 2x my productivity. So I'm just like, I'm an engineer that codes all day, every day. For me, it's probably 2x.

数字我们正在做,在积极推进。但就我个人体感:大概让我的生产力翻了一倍。我是那种从早写到晚的工程师——对我来说,差不多 2x。

I think there's some engineers at Anthropic where it's probably 10x their productivity. And then there's some people that haven't really figured out how to use it yet. And, you know, they just use it to generate like commit messages or something. That's maybe like 10%. So I think there's probably a big range and I think we need to study more.

Anthropic 有些工程师大概是 10x;也有人还没摸到门道,只拿它生成 commit message 之类的,那可能就 10%。区间很大,需要更多研究。

For reference, sometimes we're in meetings together and sales or compliance or someone is like, hey, like, we really need like X feature. And then Boris will ask a few questions to like understand the specs. And then like 10 minutes later, he's like, all right, well, it's built. I'm going to merge it later. Anything else?

给个参照:有时我们一起开会,销售或合规的同事说"我们真的很需要 X 功能"。Boris 问几个问题搞清需求,十分钟后来一句:"好了,做完了,待会儿 merge。还有别的事吗?"

So it definitely feels definitely far different than any other PM role I've had.

这和我以往任何一段 PM 经历都截然不同。

Do you see yourself opening that channel of the non-technical people? Talking to Claude Code and then the instance coming to you, which like they're ready to find and talk to it and explain what they want. And then you're doing kind of the review side and implementation.

你们会不会开放这样一条通道:非技术同事直接跟 Claude Code 对话,说清楚自己要什么,然后产出物到你这儿,你只做 review 和落地?

Yeah, we've actually done a fair bit of that. Like Megan, the designer on our team, she is not a coder, but she's landing pull requests. She uses code to do it. She designs the UI? Yeah.

这事我们其实已经做了不少。比如我们团队的设计师 Megan,她不写代码,但她在 land PR——用 Claude Code 来做。她负责设计 UI。

And she's landing PRs to our console product. So it's not even just like building on Claude Code. It's building like across our product suite in our monorepo.

而且她的 PR 是提到我们 Console 产品上的——不只是在 Claude Code 里折腾,而是在 monorepo 里横跨整个产品线开发。

Yeah, yeah. And similarly, you know, our data scientist uses Claude Code, right? Like, you know, like BigQuery queries.

类似地,我们的数据科学家也在用 Claude Code,比如写 BigQuery 查询。

And there was like some finance person that went up to me the other day and was like, hey, I've been using Claude Code. And I'm like, what? Like, how do you even get it installed? You don't even use Git. And they're like, yeah, yeah, I figured it out.

前几天还有个财务同事跑来跟我说:"嘿,我一直在用 Claude Code。"我当场懵了:啊?你怎么装上的?你连 Git 都不用。对方说:嗯嗯,我自己琢磨出来了。

And yeah, they're using it. They're like, so Claude Code, you can pipe in because it's a Unix utility. And so what they do is they take their data, put it in a CSV, and then they take the, they cat the CSV, pipe it into code. And then they ask it code questions about the CSV. And they've been, they've been using it for that.

他们真的在用:因为 Claude Code 是 Unix utility,可以用管道喂数据。他们把数据存成 CSV,然后 cat 这个 CSV、管道接进 Claude Code,再问关于这份数据的问题。就这么用起来了。

Yeah. That would be really useful to me because really what I do a lot of the times, like somebody gives me a feature request. I kind of like rewrite the prompt. I put it in agent mode and then I review the code. It would be great to have the PR wait for me.

这对我会非常有用。因为我现在的日常就是:有人给我一个 feature 需求,我把它改写成 prompt,丢进 agent 模式,然后 review 代码。要是 PR 能直接在那儿等着我,就太好了。

I'm kind of useless in the first step. Like, you know, taking the feature request and prompting the agent to write it. I'm not really doing anything. Like my work really sucks. It starts after the first run is done.

第一步里我其实挺多余的——把需求转成 prompt 这件事,我并没有创造什么价值。我的工作真正开始,是在第一轮跑完之后。

So I was going to say, like, I can see it both ways. So like, okay, so maybe I would simplify this to in the, in the workflow of non-technical people in the loop. Should the technical person come in at the start or come in at the end? Right. Or come in at the end and the start.

我两种都能想象。简化一下问题:在"非技术人员在环"的工作流里,技术人员应该在开头介入,还是在结尾介入?或者两头都要?

Obviously that's the highest leverage thing because like sometimes you just need the technical person to ask the right question that the non-technical person wouldn't know to ask. And that really affects the implementation.

这显然是杠杆最高的环节——有时候就是需要技术的人问出那个非技术的人想不到要问的问题,而那个问题会实实在在影响实现。

But isn't that the bitter lesson of the model? That the model will also be good at asking the follow-up question.

但这不正是模型的 bitter lesson 吗?模型也会越来越擅长问追问。

That's what I trust the model to do the least.

这恰恰是我最不信任模型能做好的事。

If you're like the model, hey, you are the person that needs to translate this non-technical person request into the best prompt for Claude Code to do a first implementation. Like, I don't know how good the model would be today. I don't have an eval for that. But that seems like a promising direction for me.

如果你跟模型说:"你来负责把这个非技术同事的需求,翻译成给 Claude Code 做首版实现的最佳 prompt。"今天的模型能做到多好我不知道,我没有这个 eval——但这个方向对我来说挺有希望。

Like it's easier for me to review 10 PRs. Than it is for me to take 10 requests, then run the agent 10 times and then wait for all of those runs to be done and review.

毕竟,让我 review 10 个 PR,比让我接 10 个需求、跑 10 次 agent、等所有结果再 review,要轻松多了。

I think the reality is somewhere in between. We spend a lot of time shadowing users and watching people at kind of different levels of seniority and kind of technical depth use code.

现实大概在两者之间。我们花大量时间贴身观察用户——看不同资历、不同技术深度的人怎么用 Claude Code。

And one thing we find is that people that are really good at prompting models from whatever context, maybe they're not even technical, but they're just really good at prompting. They're really effective at using code. And if you're not very good at prompting, then code tends to go off the rails more and do the wrong thing.

一个发现是:真正会 prompt 的人——哪怕不是技术背景——用 Claude Code 都非常高效;而不太会 prompt 的人,Claude Code 就更容易跑偏、做错事。

So I think in this stage of where models are at today, it's definitely worth taking the time to learn how to prompt models well. But I also agree that, you know, maybe in a month or two months or three months, you won't need this anymore because, you know, the bitter lesson always wins. Please. Please do it. Please do it, Anthropic.

所以在模型的当下阶段,花时间学会好好 prompt 绝对值得。但我也同意:也许一个月、两个月、三个月之后你就不需要这个技能了——bitter lesson 总会赢。——(Swyx:)拜托了,Anthropic,快实现吧。

I think there's a broad interest in people forking or customizing Claude Code. So we have to ask, why is it not open source?

很多人都想 fork 或者深度定制 Claude Code。所以这个问题必须问:为什么不开源?

Okay. So it's a not yet. There's a lot of tradeoffs that go into it. On one side, our team is really small and we're really excited for open source contributions if it was open source.

答案是"还没有"。这里有很多取舍。一方面,我们团队真的很小,如果开源了,我们当然欢迎社区贡献。

But it's a lot of work to kind of maintain everything and like look at it. Like I maintain a lot of open source stuff and a lot of other people on the team do too. And it's just a lot of work. Like it's a full time job managing contributions and all this stuff.

但维护这一切的工作量很大。我自己维护着不少开源项目,团队里很多人也是——管理 contributions 这些事,就是一份全职工作。

Yeah. I'll just point out that you can do source available and that's, you know, solves a lot of individual use cases. Without going through the legal hurdles of a full open source.

提一句:你们可以走 source available 路线——既能解决很多个人用户的诉求,又不用过完整开源的法务关。

Yeah, exactly. I mean, I would say like there's nothing that secret in the source. And obviously it's all JavaScript, so you can just decompile it. Decompilation's out there. It's very interesting.

没错。其实源码里没什么秘密——而且它全是 JavaScript,你直接反编译就行,反编译版本网上就有,挺有意思的。

And generally our approach is, you know, all the secret sauce, it's all in the model. And this is the thinnest possible wrapper over the model. We literally could not build anything more minimal. So there's just not that much in it.

我们的思路一贯如此:所有的 secret sauce 都在模型里。Claude Code 是模型之上最薄的一层 wrapper——我们真的造不出比这更简的东西了。所以里面真没多少货。

If there was another architecture that you would be interested in that is not the simplest, what would you use? What would you have picked as an alternative? You know, like, and we're just talking about agentic architectures here, right? Like there's a loop here and it goes through and you sort of pull in the models and tools in a relatively intuitive way. If you were to rewrite it from scratch and like choose the generationally harder path, like what would that look like?

如果让你选一个"不是最简"的架构,你会选什么?我们说的是 agentic 架构:一个循环跑下去,以相对直觉的方式调模型、调工具。如果从头重写、故意选难一代的路线,那会长什么样?

Well Boris has rewritten this, Boris and the team have rewritten this like five times.

这个嘛——Boris 和团队已经把它从头重写过五次了。

It is very much the simplest thing I think by design.

它的"最简",完全是有意为之的设计。

So it's got simpler. It got simpler. It doesn't go more complex. We've rewritten it from scratch. Probably every three weeks, four weeks or something.

而且是越写越简单,不是越写越复杂。我们大概每三四周就从头重写一次。

And it just like all the, it's like a ship of Theseus, right? Like every piece keeps getting swapped out and just cause Claude is so good at writing its own code.

就像忒修斯之船:每个部件都在不断被换掉——因为 Claude 太擅长写它自己的代码了。

I mean, at the end of the thing, the thing that's breaking changes is the interface, the Claude MCP, blah, blah, blah. Like all that has to kind of stay the same unless you really have a strong reason to change it.

说到底,真正构成 breaking change 的是接口——Claude、MCP 这些。除非有非常强的理由,否则这些必须保持不变。

I think most of the changes are to make things more simple. Right. Like to share interfaces across different components.

大多数改动都是为了让东西更简单,比如让不同组件共享接口。

Because ultimately we just want to make sure that the context that's given to the model is in like the purest form and that the harness doesn't intervene with the user's intent. And so very much a lot of that is just like removing things that could get in the way or that could confuse the model.

归根结底,我们要确保交给模型的 context 是最纯的形态,harness 不去干扰用户的意图。所以大量工作其实就是移除那些可能挡路、可能让模型困惑的东西。

On the UX side, something that's been pretty tricky and the reason that, you know, we have a designer working on a terminal app is it's actually really hard to design for a terminal. There's just like, there's not a lot of literature on this.

UX 这边有件很棘手的事——这也是为什么一个终端应用会配设计师:给终端做设计真的很难,这方面几乎没有现成的文献。

Like I've been doing product for a while. So like I kind of know how to build for apps and for web and, you know, for engineers in terms of like tools that have DevEx, but like terminal is sort of new.

我做产品很多年了,知道怎么做 app、做 web、做面向工程师的 DevEx 工具——但终端是个新领域。

There's a lot of these really old terminal UIs that use like curses and things like this and for very sophisticated UI systems. But these are all, they all feel really antiquated by the UI standards of today.

市面上有很多很老的终端 UI,用 curses 之类的库,有些还相当精巧。但以今天的 UI 标准看,它们都显得非常陈旧。

And so it's taken a lot of work to figure out how exactly do you make the app feel like fresh and modern and intuitive in a terminal. And we've had to come up with a lot of that design language ourselves.

怎么让一个终端应用摸起来新鲜、现代、直觉,花了我们很大功夫——很多设计语言只能自己发明。

Cool. Closing question. This is just more general. Like, I think a lot of people are wondering, Anthropic has, I think it's easy to say the best brand for AI engineering, like, you know, developers and coding models. And now with like the coding tool attached to it, it just has the whole product suite of model and tool and protocol.

好,收尾问题,比较宏观。很多人都在想:Anthropic 可以说拥有 AI 工程领域最好的品牌——开发者、编程模型,现在又加上编程工具,凑齐了模型、工具、协议的全套产品矩阵。

And I don't think this was obvious one year ago today. Like when Claude 3 launched, it was just, it was just more like, this is a general purpose models and all that. But like Claude Sonnet really took the scene as like the sort of coding tool of choice and I think built Anthropic's brand and you guys are now extending.

一年前的今天这一点远不明显——Claude 3 发布时,大家只觉得这是个通用模型。但 Claude Sonnet 真正占领了"编程首选"的位置,撑起了 Anthropic 的品牌,你们现在又在延伸它。

So why is Anthropic doing so well with developers? Like, it seems like there's just no centralized, every time I talk to Anthropic people, they're like, oh yeah, we just had this idea and we pushed it and it did well. And I'm just like, there's no centralized strategy here. Or like, you know, is there an overall overarching strategy? Sounds like a PM question to me. I would say like Dario is not like breathing down your neck going like build the best dev tools. Like he's just, you know, letting you do your thing. Everyone just wants to build awesome stuff.

所以,Anthropic 为什么在开发者这边做得这么好?每次跟 Anthropic 的人聊,他们都说"哦,我们就是有了个想法,推了一把,结果挺好"——好像根本没有集中式战略。还是说其实有一个统摄全局的战略?这听着像该 PM 答的问题。我猜 Dario 并没有在你们背后紧盯着说"给我做出最好的 dev tools",他就是放手让你们干,大家只是都想做出很棒的东西。

It's like, I feel like the model just wants to write code. Yeah, I think a lot of this trickles down from like the model itself being very good at code generation. Like we're very much building off the backs of an incredible team. I think that's the only reason why Claude Code is possible.

我感觉就是:模型自己就想写代码。这一切很大程度上源自模型本身极强的代码生成能力——我们完全是站在一个了不起的团队的肩膀上,这是 Claude Code 之所以可能的唯一原因。

I think there's a lot of answers to why the model itself is good at code, but I think like one high level thing would be so much of the world is run via software and there's like immense demand for great software engineers.

模型为什么擅长写代码,答案有很多。但站在高处看:这个世界太多东西靠软件运转,对优秀软件工程师的需求是巨量的。

And it's also something that like you can do almost entirely with just a laptop or like just a dev box or like some hardware. And so it just like is an environment that's very suitable for LLMs.

而且写代码这件事,几乎只需要一台笔记本、一个 dev box 就能完成——是非常适合 LLM 的环境。

It's an area where we feel like you can unlock a lot of economic value by being very good at it. There's like a very direct ROI there. We do care a lot about other areas too, but I think this is just one in which the models tend to be quite good and the team's really excited to build products on top of it.

这是一个"只要做得足够好,就能解锁巨大经济价值"的领域,ROI 极其直接。其他领域我们也很在乎,但这一块恰好模型很强、团队也真心想在上面做产品。

And you're growing the team you mentioned. Who do you want to hire? Who's like a good fit for your team?

你们说在扩编。想招什么样的人?什么样的人适合你们团队?

We don't have a particular profile. So if you feel really passionate about coding and about the space, if you're interested in learning how models work and how terminals work and how like, you know, all these technologies that are involved. Hit us up. Always happy to chat.

没有固定画像。如果你对编程、对这个领域真正充满热情,有兴趣搞懂模型怎么工作、终端怎么工作、这一整套技术怎么运转——来找我们,随时乐意聊。

Awesome. Well, thank you for coming on. This was fun.

太棒了。谢谢你们来,这期很开心。

Thank you. — Thanks for having us. — This was fun.

谢谢。——谢谢邀请。——真的很开心。