Claude Code 的起源：从意外到智能代理

好了，我们需要听听起源故事。Claude Code 是怎么来的？

All right, so we need the origin story. Where did Claude Code come from?

顺便说一句，坐在这里听到你们的声音感觉很不真实，因为我习惯了听你们的声音时大概都是 2 倍速，而且经过了我们所有那些编辑，去掉了各种口头禅。嗯，是的，它在很多方面都算是个意外。我在 2024 年底加入了 Anthropic 的一个团队，那是一个原型团队，叫做 Labs 团队。我们实际上重新启用了它。想法是找出下一个大产品。同时，我们推动模型的边界，弄清楚如何改进模型以最好地支持那个尚未构建的未来产品。很难知道该往哪个方向演进模型，因为直到有一个真正推动边界的产品出现，你才真正知道。当时，有一种强烈的产品过剩感——模型能做所有这些事情，但还没有产品能捕捉到它。如果你想想当时的编码工具，有自动补全工具，你可以向智能体提问，但它不能写代码。差不多就这样。直到最近，模型还不够好，它真的做不到。所以我们觉得有空间全力以赴，构建一个纯粹的编码智能体产品。我们构建了它，一开始它很烂。它可能只写了我 10%到 20%的代码，持续了一段时间。

By the way, it's crazy being here and hearing you guys' voices cuz I'm used to hearing you like at 2x speed, probably, with all the editing that we do on all of our little verbal ticks. Yeah, it was sort of an accident in a lot of ways. I joined a team at Anthropic late in 2024, and it was kind of a prototyping team called the Labs team. We actually brought it back. The idea was to figure out what's the next big product. At the same time, we push the frontier of the model and figure out how to improve the model to support that best, you know, that future product that hasn't been built. It's hard to know which way to evolve the model because until there's a product that really pushes the frontier, you don't really know. At the time, there was this crazy feeling of product overhang—the model can do all this stuff, but there's no product that has yet captured it. If you think about coding tools at the time, there were autocomplete tools, you could ask the agent a question, but it couldn't write code. That's about it. Until recently, the model just wasn't good enough. It couldn't really do it. So we felt there was room to go all in and build a product that's just a coding agent. We built it, and it kind of sucked at the beginning. It wrote maybe 10-20% of my code for a while.

快速问一下，在此之前，Anthropic 的编码状况如何？它有多受重视？

Real quick, before this moment, what was the state of coding at Anthropic? How much of a focus was it?

在 Anthropic 内部，我们当时仍然在使用 IDE。但作为一家公司，Anthropic 一直关注编码。我们一直关注工具使用和计算机使用。这始终是核心研究方向，因为我们存在的目的是研究 AI 安全。这就是我们存在的原因。如果你在 Anthropic 随便拉一个人，在走廊里问他：‘你为什么在这里？’他们会说 AI 安全。这是公司里每个人在这里的原因。他们深信，包括我在内，这是唯一最重要的问题。有很多方法可以解决它。你可以研究机械可解释性，可以做对齐工作。有各种方法在培养皿中研究模型。但根本上，你必须在现实世界中研究它，看看它在其他方面安全后会做什么。这就是 Claude Code 的用武之地。对于 Anthropic 这家公司来说，方向一直是安全。研究安全的方式有多个层次，包括将模型置于现实世界。一个有用的方式是什么？是编码。因为这是模型与世界互动的方式。所以如果你想研究各种模型失调，你需要让它足够有用，让人们使用它，这样你才能研究它。编码是一个非常明显的应用。从一开始这就是重点。它是一个难以置信的干净宇宙，因为你有所有这些训练数据。它要么工作要么不工作。根据语言，它要么编译要么不编译。有一个非常清晰的通过/失败测试方式。它是一个非常受限的正确解宇宙。英语中有无数正确优美的诗歌，但解决某个问题的正确代码写法是有限的。

Internally at Anthropic, we were using IDEs still at the time. But for Anthropic as a company, we've always cared about coding. We've always cared about tool use. We've always cared about computer use. This has always been kind of the core research direction because we exist to research AI safety. That's the reason we exist. If you ask a random person at Anthropic, pull them over in the hallway and ask, 'Why are you here?' They're going to say AI safety. That's the reason every single person is at the company. They deeply believe, including me, this is just the single most important problem to solve. There are a bunch of ways to solve it. You can look at mechanistic interpretability, you can do alignment work. There are all sorts of ways to study the model in a petri dish. But fundamentally, you have to study it in the wild to see what it does once it's safe in all these other ways. That's kind of where Claude Code comes in. For Anthropic as a company, the direction has always been safety. The way you study safety has all these layers, including setting the model in the wild. What's a useful way to do that? It's coding. Because that's the way the model interacts with the world. So if you want to study various sorts of model misalignment, you want to make it useful enough that people use it so that you can study it. Coding is just a very obvious application. That's been the focus from the beginning. It's such an unbelievably clean universe because you've got all this training data. It either works or doesn't work. Depending on the language, it either compiles or doesn't compile. There's a very clear pass-fail ability to test it. It's a very constrained universe of correct solutions. English has an infinite number of correct, beautiful poems, but there is a non-infinite number of ways to write the correct code to solve a certain problem.

而且用它作为你的培养皿有一种优雅之处，鉴于这一点。

And there's a sort of elegance to using it as your petri dish, given that.

是的，没错。有个叫侯世达的人，他写了《哥德尔、埃舍尔、巴赫》。他在 80 年代写了另一本奇怪的书，关于他对人工智能路径的想法。他在学校教 AI。他谈到认知的基础，智能的基础是识别模式。他研究这个的一种方式是将诗歌从英语翻译成法语。直接翻译很少是正确的翻译。其中涉及很多品味。有时你想稍微调整一下，让韵律更好。这是一个模糊的问题。但编码更容易解决，我认为。它也非常有商业价值。它帮助我们建立业务。这是我们最喜欢的客户——企业、初创公司、公司——所拥有的那种业务。所以它帮助我们拥有这种一致的业务模式。我们不需要做广告。我们可以专注于安全，这是我们在乎的事情。它帮助我们建立一个真正能做到这一点的业务。

Yeah, that's right. There was Hofstadter, the guy who wrote Gödel, Escher, Bach. He wrote this other weird book in the '80s about his idea about the path to artificial intelligence. He taught AI in school. He was talking about the basis of cognition, the basis of intelligence is recognizing patterns. One way he studied that was translating poetry from English to French. A direct translation is rarely the right translation. There's a lot of taste that goes into it. Sometimes you want to fudge it a little bit so the meter is good. It's a fuzzy problem. But coding is easier to solve, I think. It's also very commercially valuable. It helps us build a business. It's the kind of business that our favorite customers—enterprises, startups, companies—have. So it helps us have this kind of aligned business model. We don't need to do ads. We can focus on safety, which is the thing we care about. It helps us build a business where we can actually do that.

你在来 Anthropic 之前来自 Meta，你在 Meta 非常关注代码。我很好奇，现在回顾起来，你在 Meta 所做的工作如何帮助塑造了 Claude Code 的开端？

You came from Meta before coming to Anthropic, and you had a lot of focus on code at Meta. I'm curious, connecting the dots looking back now, how did what you were doing at Meta help inform the beginnings of Claude Code?

对我来说，构建开发者工具一直是个副业。它从来不是主要工作。我觉得这是构建开发者工具的最佳方式，因为你想要专注于解决业务问题，构建人们喜爱且有用的东西。这从根本上来说是我们作为工程师的使命。YC 总是把这个理念灌输给你。我实际上是 2010 或 2011 年一家 YC 公司的第一个员工，那是早期批次之一。所以对我来说，开发者工具一直是个副业。我构建产品，在构建产品的过程中，如果开发者体验不好，我就会构建工具来改善它。我一直都是这样做的。在这里我只是应用了这种心态：先为自己构建东西，然后希望它对别人也有用。我很惊讶地发现它确实有用，这太棒了。

For me, building dev tools has always been a side hustle. It was never the main thing. I feel like that's the best way to build dev tools because you want to focus on solving a business problem and building a thing that people love and that's useful for people. That's fundamentally what we're here for as engineers. YC always beats this into you. I was actually the first hire at a YC company back in 2010 or 2011, one of the first batches. So for me, dev tools has always been this kind of side hustle. I build product, and on the way to building product, if the dev ex isn't good, then I'll build tools to make that a little bit better. That's just always been the way I approach it. Here I just applied that mindset: build the thing for yourself first, and then hopefully it's useful for others. I was surprised to see that it is, which is awesome.

所以你说它一开始很烂，你只信任它处理大约 10%的工作，它也只完成了你大约 10%的工作。

So you said it was kind of crappy at first, and you only trusted it with like 10% of your work, and it only did about 10% of your work.

早期的瓶颈是什么，你们又是如何解决并改进的？据我所知，你已经大约六个月没在工作中写过一行代码了。是的。所以这和它只做大约 10%的情况截然不同。是什么改变了？

What was the bottleneck early on, and how did you solve it to make it better? Because from what I understand, it's been like six months since you've written a line of code in your job. Yes. So that's extremely different from it only doing about 10%. What changed?

我记得是在五月，Sonnet 4 和 Opus 4，然后十一月是 Opus 4.5。所以只是底层模型变了。就是模型的问题。我们在工具链上做了很多工作，在改进 Claude Code 上也花了很多功夫。你知道，每个人都喜欢以不同的方式使用这些东西。这就是为工程师构建产品的特点。它不是消费产品，因为工程师对自己喜欢的使用方式非常固执己见。所以我们从 CLI 开始，但后来我们构建了桌面应用、移动应用、iOS 和 Android 应用。我们有 Slack 应用、GitHub 应用。你可以用任何你喜欢的方式使用 Claude Code。所以，这其中很多是我们创新、学习、试图找出哪些功能有用的过程。比如计划模式就是由此产生的。很多不同的工具和体验都由此而来。但根本上，当我思考阶跃变化以及模型编写了我多少代码时，那就是模型本身。模型变好了，比例就上升了。

I remember it was in May, it was Sonnet 4 and Opus 4, and then in November, it was Opus 4.5. So it was just the underlying model changing. It was the model. There was a lot of work that went into the harness. There was a lot of work into making Claude Code better. You know, everyone likes to use this stuff differently. This is the thing about building for engineers. It's not a consumer product because engineers are so opinionated in the way they like to use stuff. And so, we started with a CLI, but then we built a desktop app, a mobile app, iOS and Android apps. We have a Slack app, a GitHub app. You can use Claude Code in whatever way you want. And so, a lot of this was us innovating, learning, trying to figure out what features are useful. Plan mode, for example, came out of this. A lot of different tools and experiences came out of this. But fundamentally, when I think about the step changes and what percent of my code the model wrote, it was just the model. The model got better, and it just went up.

在你能谈论的范围内，Claude Code 的体验在多大程度上反馈到了 4.0、4.5 等版本的模型工作中？

How tightly, to the extent you are able to talk about it, was the experience that Claude Code was having feeding back into the model work leading up to 4.0, 4.5, etc.?

Anthropic 的每个人每天都使用 Claude Code。构建模型的研究人员使用 Claude Code，构建产品的人使用 Claude Code。所以这基本上就是循环。

Everyone at Anthropic uses Claude Code every day. The researchers building the model use Claude Code, and the people building the product use Claude Code. So that's essentially the cycle.

你们有没有什么指标可以量化地描述它改变了公司的发展轨迹？从外部看，你们现在发布的产品比以前多得多。似乎可以合理地假设，其中很大一部分是因为你们在公司内部到处使用 Claude Code。正确理解其中有多少归因于 Claude Code 的方法是什么？

Do you have any metrics that numerically describe how much it's changed the company's trajectory? It feels from the outside that you guys are shipping a whole lot more product now than you used to. It seems reasonable to assume a lot of that is because you guys are using Claude Code all over the company internally. What's the right way to really grasp how much of that is attributable to Claude Code?

在 AI 实验室，你会习惯用指数思维。基本上所有图表都是指数型的。所以我们实际上几乎对所有东西都使用对数线性图表。x 轴是线性的，y 轴是对数线性的。一切基本上都是指数型的。收入是指数型的，使用量是指数型的，这对工程师来说是最有趣的问题。感谢你忍受这一点。基本上，一切都在增长，包括代码。当我们查看自发布 Claude Code 以来 Anthropic 员工编写的代码行数和拉取请求数量时，这已经增长了数百个百分点。我想我们最近分享的是大约 3 倍，但这实际上已经非常过时了。现在要高得多。

Being at an AI lab, you get used to thinking in exponentials. Essentially, all the charts are exponential. So we actually use log-linear charts for pretty much everything. The x-axis is linear and the y-axis is log-linear. Everything is kind of exponential. Revenue is exponential, usage is exponential, which is just the funnest problem as an engineer. And thank you for bearing with it. Essentially, everything is going up, including the code. When we look at the lines of code written, the number of pull requests written by people at Anthropic since we released Claude Code, this has grown many hundreds of percentage points. I think the latest that we shared was something like 3x, but this is actually very outdated. It's a lot higher now.

什么增长了 3 倍？

What was 3x?

Anthropic 每位工程师编写的代码量。

The amount of code per engineer that everyone at Anthropic is writing.

我明白了。所以工程团队的规模增长了很多倍。通常随着工程团队规模的增长，生产力会下降。我在 Meta 时，我的职责之一是所有代码库的代码质量。我们关心这个是因为它对生产力有用。如果代码质量高，工程师就更高效。我们通过经验证明了这一点。通常，随着工程师数量增加，生产力会下降，因为新人会问工程师“这个怎么做？那个怎么做？”被问的工程师就没时间写代码了。而且需要上手时间。我们在 Anthropic 看到的第一件事是，新人加入后，上手时间大约是两天。因为以前需要几周，但现在只需要两天，因为你直接问 Claude。我们还得向新加入团队的人解释，比如有人问“我如何查询数据库？”答案是打开 Claude，在 Claude Code 代码库中运行，让 Claude 查询数据库。因为查询数据库有专门的技能，而 Claude 知道。

I see. So the size of the engineering team went up many multiples. And usually what happens as the size of the engineering team grows is productivity goes down. When I was at Meta, one of my responsibilities was code quality for all the code bases. And the reason we cared about that was it's useful for productivity. If the code is high quality, it makes engineers more productive. We kind of showed this empirically. Typically, as the number of engineers grows, productivity goes down because new people ask engineers, 'How do I do this? How do I do this?' So the engineers they're asking don't get to write code. And it takes ramp-up time. The first thing we saw at Anthropic is when new people join, the ramp-up time is like two days. Because this used to be weeks, but now it's two days because you just ask Claude. We still have to explain to new people that join the team, like people ask, 'How do I query the database?' And the answer is open Claude, run it in the Claude Code code base, and have Claude query the database. Because there's a skill for querying the database, and it just knows.

在你们 2026 年招聘的新工程师中，有多少人写过代码？

Of the new engineers that you've hired in 2026, how many of them have written any code?

我的意思是，定义一下写代码。

I mean, define writing code.

对，对。那是……等等，等等。你怎么定义写代码？

Right, right. That's... Wait, wait, wait. How do you define writing code?

对我来说，工程一直是……我爷爷用打孔卡编程。在苏联，对他来说，编程是纸上的事情，打孔，然后喂进一个大机器，它轰隆一阵，给你答案。那就是编码。我爸爸写了很多汇编，他会嘲笑我写 Python，说“你不是在编程”。没错。这不是真正的工程师干的，或者太高级了。但这就是编程的本质：指令的抽象层次一直在提高。从开关到打孔卡，到汇编，然后到 Cobol、Fortran，再到 Java 和高级语言，然后到 JavaScript 和 Python 以及真正的高级语言。这一直都在发生，我认为我们正在做的事情就在这个连续谱上。对我来说，一年前我编码的方式是在 IDE 中用某种自动补全来写代码。十一月，我卸载了我的 IDE，因为我不再使用它了。

For me, engineering has always been like... my grandpa coded with punch cards. In the Soviet Union, for him, programming was a paper thing, punch holes into it, and you feed it into this big machine that chugs for a while, and it gives you the answer. That was coding. My dad, who wrote a lot of assembly, would have made fun of me for writing Python, and be like, 'You're not coding.' Exactly. It's not for real engineers or it's very high-level. But this is the nature of programming: the level of instruction always goes up. It went from switches to punch cards to assembly, then to Cobol, Fortran, then Java and high-level languages, and then JavaScript and Python and really high-level languages. This has just always happened, and I see what we're doing as somewhere on this continuum. For me, the way that I coded a year ago was I wrote code with some kind of autocomplete in an IDE. In November, I uninstalled my IDE because I wasn't using it.

我只是……上个月，我一直没打开它，所以我就卸载了它。哇。

I just... I was in the last month, I just haven't opened it, so I'll just uninstall it. Wow.

那时，我可能并行运行五到十个 Claude 实例。我的编码就是提示 Claude 写代码。现在，它实际上又提升到了下一个抽象层次，我不再提示 Claude 了。我有正在运行的循环。它们负责提示 Claude 并弄清楚该做什么。我的工作是写循环。我认为这是我们在未来几个月甚至今年剩余时间里将要看到的下一个转变。哇。

At that point, I was running maybe five to ten Claude instances in parallel. And my coding was prompting Claude to write code. Now, it's actually leveled up again to the next level of abstraction where I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops. And this is the next transition that I think we're going to see in the next few months and maybe through the rest of the year. Wow.

假设我——显然不是真的我——是一名想加入 Anthropic 工程团队的工程师。你今天如何评估我？

Hypothetical me, obviously not actual me, is an engineer who wants to join the engineering team at Anthropic. How do you evaluate me today?

我认为我在我们团队中特别看重的一点是，我们喜欢通才。

I think something that I look for in our team in particular for Claude Code is we love generalists.

所以，我觉得大概六个月前我们开始看到的是，团队里很少有工程师只是做传统意义上的工程。你知道，就是有个用户研究员，他们跟用户聊，然后把结果写成文档交给设计师，设计师做出模型，再交给产品经理确定范围，最后才给工程师去实现。

So, I think a thing that we started to see maybe six months ago is there were very few engineers on the team that were just doing engineering in the traditional sense. You know, you have a user researcher, they talk to the user, and then they handed that down in a document to a designer who then made a mock, and then that went to a product manager, scoped it, and then it goes to an engineer for implementation.

我在微软工作过，对这个流程非常熟悉。

I worked at Microsoft. I'm extremely familiar with this process.

过去是这样，但我们意识到团队不再这么做了。我们的团队一直比这更偏向原型开发，但大概六个月前，我们发现团队里的每个工程师都做范围界定。每个人都每天跟用户交流。人们在搞设计。工程师，团队里的每个人都习惯于拉数据、做数据科学工作、建仪表盘之类的。所以，我觉得我们开始看到所有角色融合，几乎融为一个构建者。萨提亚称之为构建者，差不多就是这个意思。

This is what it used to be, but we realized this is not what the team is doing anymore. Our team was always kind of more prototypy than this, but maybe six months ago, we found every engineer on the team does scoping. Everyone talks to users every day. People are doing design. Engineers, everyone on the team is comfortable pulling data and doing data science work, building dashboards, and things like that. So, I think we're starting to see all the roles merge and kind of melt into one builder. Satya calls it a builder, so something like that.

这几乎就像一个产品工程师，但你甚至不一定非得是工程师。

It's almost like a product engineer, but you don't even really necessarily have to be an engineer.

没错。我们有设计师在发布代码，或者财务人员在发布代码。我觉得这是……

That's right. And we have designers that are shipping code or a finance guy ships code. I think this is...

我们的参谋长也在发布代码。

Our chief of staff ships code.

是的。实际上，我们现在在 Acquired 的所有基础设施都很快迁移到了 Claude code，这就是为什么……我能讲一个 Acquired 的小趣事吗？我们是一个音频播客。YouTube 没有只上传音频的方式，你必须上传视频内容，这应该挺有意思的。很长一段时间，我们只是用一个黑屏的 MP4。所以，有字幕会是个好主意，但我们还没有字幕，因为人工制作字幕需要一周时间。幸运的是，有 AI。总之，有一整套 Claude code 脚本，我胡乱写的，嗯，我和 Claude 一起写的，然后某个时候我把它扔给了 David，我说：“你能继续搞这个吗？”一开始有点抵触，但后来你确实想出了一个主意……嗯，打开终端。大学毕业后的一天，那是我最后一次打开终端。之后的一天，Codox 就出来了。Codox 的卖点是，如果你想要 Claude code 的能力，但又不想处理终端、输入命令、安装 NPM 之类的。我们听说 David 不得不打开终端，所以我们就想：“我们必须发布这个。我们只有一天时间。”所以，我想用这个作为引子，来讲讲 Claude Codox 的故事，因为在我看来，Claude Codox 的市场更大，是那些不想打开终端的人，而不是那些知道怎么打开终端的人。有趣的是，它先是走了 Claude code 的方向，然后老实说，过了很久 Codox 才出来。

Yeah. We actually all of our infrastructure at Acquired now is pretty rapidly shifted to Claude code, which is why... Can I tell a little fun Acquired story? So, we are an audio podcast. YouTube doesn't have a way to upload just audio. You have to upload something in the video. It should be interesting. For a long time it was just a black screen MP4. So, a transcript would be a good idea, but we don't have a transcript yet because it takes a week for humans to make the transcript. Fortunately, there's AI. Anyway, there's a whole Claude code set of scripts that I sloppily wrote, well, I and Claude wrote, and then at some point I sort of heaved it over to David and I was like, "Can you continue working on this?" And there was at first a little resistance, but then you did spin up an idea like... Yeah. Yeah. Yeah. Yeah. Um open the terminal. One day after classes in college, and that was the last time I opened a terminal. One day after that, Codox comes out. And the pitch for Codox is it's if you want the power of Claude code, but you don't want to have to deal with the terminal and typing commands and installing NPM and blah blah blah. We actually heard that David had to open a terminal, so we were like, "We have to release this. We have one day." So, I want to use that as my hook to tell us the story of Claude Codox because to me it seems Claude Codox is a much bigger market of people who don't want to open terminals than people who do know how to open terminals. It's kind of interesting that it went the direction of Claude code first, and then to be honest, kind of a really long time before Codox came out.

是的，没错。说实话，故事就是这样。有点像这个版本上演了。四月的时候，我记得走进办公室，就在 Codox 团队坐的地方旁边，有几个数据科学家。我走进去，其中一个数据科学家屏幕上开着 Codox。那还是 Codox 只在终端里可用的时候，还没有桌面应用，也没有移动应用。所以你真的得知道自己在干什么。我问 Brandon：“老兄，你在干嘛？你在内部试用吗？只是想搞明白这东西是什么？”因为他刚加入团队。他说：“不，我在用它做数据分析。”于是，他搞清楚了怎么打开终端，怎么下载 Node.js，因为必须得这么做。他搞清楚了怎么安装 Codox，怎么设置 API 密钥。我觉得当时我们甚至还没有订阅。他就用它做分析。然后，接下来一周，所有数据科学家都开了好几个 Codox 窗口做分析，因为它就是很擅长。然后快进到大概五月或六月，有个推特上的家伙。你们看到了吗？他用它来种番茄。他有个小网络摄像头，设置好来监控他的番茄植物。它控制着植物的营养，持续了几周。然后某个时候，小番茄长出来了。Codox 说：“这太令人愉快了。我们所有的工作都有回报了。”我看到这条推文，心想：“天哪，我觉得时机到了。现在我们开始突破到主流了。花了一段时间让工程师理解这是什么，他们终于理解了。现在我们开始看到非工程师的临界质量也在使用它。当这种重量和需求如此强烈时，我觉得这意味着是时候构建一个产品了。于是，我们开始探索。有很多不同的想法。Claude code 本身我们构建它只花了一周多一点，大概八九天。差不多这样。它 100%是用 Claude code 构建的。它是众多想法中的一个。我们一拿到它就觉得，就是它了。

Yeah, that's right. Honestly, it was the story. It was like some version of this played out. In April, I remember walking into the office, and right next to where the Codox, you know, a few of us sit, there's a couple data scientists. And I walked in, and one of the data scientists had Codox up on his screen. And this was back in the day when Codox was only available in a terminal. It wasn't yet available in the desktop app. It wasn't available in the mobile app. So, you really had to know what you're doing. And I asked Brandon like, "Dude, what are you doing? Are you dog fooding it? Just trying to figure out what this thing is?" Because he just joined the team. And he was like, "No, I'm using it for data analysis." And so, he figured out how to open a terminal. He figured out how to download Node.js because you had to do that. He figured out how to install Codox, how to set up the API key. I don't think we even had subscriptions then. And he was just using it to do analysis. And then, the next week all of the data scientists had multiple Codox windows doing their analysis because it was just good at it. And then fast forward to maybe May or June or something, and there was some guy on Twitter. You guys see this? He was using it to grow his tomato plants. He had like a little webcam, and he set it up to just monitor his tomato plants. And it was controlling the nutrition for the plants, over weeks. And then at some point the little tomato got it. And Codox was like, "This is so delightful. All our work is paying off." And I just saw this tweet, and I was like, "Oh my god, I think it's time. Now we're starting to break through to the mainstream. It took a while to get engineers to understand what this is, and finally they did. And now we're starting to see a critical mass of non-engineers do it. And when the weight and demand is that strong, I think that just means it's the time to build a product. And so, we started exploring. There's a bunch of different ideas. Claude code itself we built in it was like a little over a week, maybe eight, nine days. Something like that. It was 100% built using Claude code. It was one of a bunch of ideas. And as soon as we had it we were like, this is it.

你们砍掉了哪些其他路径？因为如果我把创意简报描述为“把 Claude code 的所有能力带给不想打开终端的人”，这并不能一对一地转化。你必须在构建的产品中有所取舍，只承担 Claude code 能做的部分工作。

What were the other paths that you killed? Because if I were to describe the sort of creative brief as take all the power of Claude code and make it available to people who don't want to open a terminal, it doesn't really translate one-to-one. You kind of have to be opinionated in the product that you build to bite off some set of the work that Claude code can do.

是的，我们试过了，老兄。我甚至不记得所有原型了。我们试过一个基于 Slack 的，但效果不好，因为构建好用的 Slack 聊天机器人真的很难。我们试过一个基于网页的，有很多不同的网页原型，我们都不确定，没有一个感觉特别好。在浏览器里就是感觉不太好。而且如果在浏览器里，它就无法访问你所有的工具。所以如果我在桌面上有一个 Word 文档，我无法在浏览器里告诉它。文件系统访问感觉是必要的。仅仅是必须把文件拖拽到浏览器这一点点的摩擦，就足以让它感觉不好。

Yeah, we tried man. I don't even remember all the prototypes. We tried something I think that was based on Slack. And it didn't really work because building Slack chatbots that feel good is just really hard. We tried something that was based on web. There was a bunch of different web-based prototypes that we weren't sure about and none of them really felt great. There's something about being in a browser that just didn't feel really good. And also if it's in a browser it doesn't have access to all your tools. So I have a Word document on my desktop. I can't tell something in the browser. File system access feels necessary. And just that little bit of friction of having to drag and drop the file to the browser, that was enough to make it feel not good.

我认为这又回到了我们对产品的思考方式：我们打造自己热爱的东西。你要打造一个你自己会爱上、每天都会使用的产品，然后也许一些用户也会喜欢它，希望它也能对其他人有用。

I think this is just back to the way that we think about product: we build the thing that we love. You want to build a product that you yourself fall in love with and that you use every day, and then maybe some users will like it too, and hopefully it will work for other people too.

让我惊讶的是，我的 Claude Code 使用量下降了，因为很多 Python 代码都是在聊天窗口里写的。我会问它一些需要大量数据分析的问题，然后我看到，哦，它正在写一些软件来做分析，然后它会写一堆 HTML、CSS 和 JavaScript，再渲染出一个全新的界面让我操作。这用了很多 Claude Code 生成，但我从未与 Claude Code 这个产品交互就完成了这一切。

It has been surprising to me how my Claude Code usage has dropped because of how much Python gets written in the chat window. I'll ask it questions that require a lot of data analysis, and I can see, oh, it's writing some software right now to do the analysis, and then it's going to write a bunch of HTML, CSS, and JavaScript, and then render a brand new UI for me to play with it in. That used a lot of Claude Code generation, although I never once interacted with Claude Code the product to have that be accomplished.

有一个有趣的理论问题：你希望什么时候进行计算？是在从模型采样进行推理时实时计算？还是预先计算，让模型写一个程序，然后你可以免费重复运行那个程序？本质上我们想尽可能做后者。但这真的取决于模型。模型作为软件存在，需要一种与世界互动的方式。因为它作为软件存在，它做这件事的方式就是编码。那是它说的自然语言，它理解的东西。从 Claude Code 最早的日子开始，第一个版本我就给了它一个 bash 工具，这样它可以在我的电脑上运行命令。我没有告诉它任何关于这个工具的信息，它自己就学会了怎么用。有一个我讲过一千遍的轶事：我问它我在听什么音乐？它打开了 bash 工具，写了一个小程序，又写了一个 AppleScript 脚本——我从来没写过 AppleScript——然后它打开我的音乐播放器，说，这是你正在听的歌。即使在那个时候，那是 Sonnet 3.5，按现代标准并不是很智能的模型。它就知道怎么做。所以写代码、用工具与世界互动，这是模型想要做的事情。

There's this interesting theoretical thing about when do you want to do the computation? Do you want to do it in real time when you sample from the model and do inference? Or do you want to pre-compute so the model writes a program and you can run that program repeatedly for free? Essentially we want to do the latter as much as possible. But it really is up to the model. The model exists as software and needs a way to interact with the world. Because it exists as software, the way it does this is coding. That's just the natural language it speaks, the thing it understands. From the earliest days of Claude Code, the very first version I gave it a bash tool so it can run commands on my computer. I didn't tell it anything about the tool, and it just figured out how to use it. There's this anecdote I've told a thousand times: I asked it what music am I listening to? It opened up the bash tool, wrote a little program that wrote an AppleScript script—I've never written AppleScript—and it opened my music player and said, this is the song that you're listening to. Even back then, this was Sonnet 3.5, not a very intelligent model by modern standards. It just knew how to do this. So there's something about writing code, using tools to interact with the world, that the model wants to do.

我想问一下文化和组织设计。你是技术员工。我想很多人都有这个头衔。这是怎么回事？有什么优点？有什么缺点？你会向这个群体推荐吗？

I want to ask about culture and org design. You're a member of the technical staff. I think a lot of people have that title. What's up with that? What are the pros? What are the cons? Would you recommend that to this group?

最糟糕的是，我加入时很烦人的一点是，你在 Slack 上给人发消息，上面只写着“技术员工”。这个人是设计师、工程师还是经理？你不知道。他们做什么工作？你不知道。我其实很喜欢这个头衔。在 Meta 的时候，我很喜欢的一点是每个软件工程师的头衔都是“软件工程师”。没有高级或首席。真的吗？对，没有这个说法。我喜欢它，因为如果你给人高级头衔，有时他们会给你糟糕的想法，而别人出于尊重就会接受那些想法。但实际上他们应该反驳。这是一个很好的文化强制力，让每个人都处于同一水平。

The worst thing, pretty annoying when I joined, is you message someone on Slack and it just says 'member of technical staff.' Is this person a designer, an engineer, a manager? You don't know. What do they work on? You don't know. I actually really like it. When I was at Meta, something I really liked is every software engineer's title is 'software engineer.' There's no senior or principal. Really? Yeah, it's not a thing. I like it because if you give people senior titles, sometimes they'll give you bad ideas and people out of deference will just go with those ideas. But actually they should push back. It's a really good cultural forcing function to put everyone on the same playing field.

但这会不会暴露出来？比如，好吧，我知道你只是个软件工程师，我也只是个软件工程师，但我很清楚你是个某个级别的软件工程师，尽管头衔里没有体现。

Does it come out though? Like, okay, yeah, I know you're just a software engineer and I'm just a software engineer, but I'm well aware you're a level something software engineer even though it's not in your title.

我认为有时你知道，但很多时候你不知道。在 Facebook 的时候，我是 L4 工程师。我有一个想法，找到了连接部门的副总裁，走过去对他说，这是我的想法，我们去做吧。他不知道我是什么级别。那是个坏主意，没有成功。但后来我又对另一个副总裁做了同样的事，也没成功，但第三次成功了。我们成立了一个团队，开始构建东西。我现在经常看到这种情况。我们团队里的人，所有这些老套的资历观念都不再重要了。有 20 或 30 年经验的工程师必须忘掉很多东西。你要花几个月教他们忘掉那些不再相关的旧习惯。有时一个新毕业生加入，会教我如何更好地使用 Claude Code，因为他们天生就会这么想。这特别难，因为每个新模型，你都得重新校准和学习。回到技术员工这件事，我认为它非常重要，因为所有这些旧的区分——工程师、产品经理、设计师、用户研究员——到年底就消失了。这帮助我们清楚地看到这一点，并今天就这样行动。我认为在 AI 实验室里你必须做的是推动每个人更加敏捷，并以这种方式思考未来。

I think sometimes you know, but often times you don't. When I was at Facebook, I was an L4 engineer. I had an idea, found the VP of connectivity, went to him and said, here's my idea, let's go build it. He didn't know what level I was. It was a bad idea and it didn't work. But then I did this again with a different VP, that also didn't work, but the third time it worked. We started a team and built stuff. I see this all the time now. People on our team, all these old seniority ideas don't matter anymore. Engineers with 20 or 30 years of experience have to unlearn so much. You spend months teaching them to unlearn old habits that aren't relevant. Sometimes a new grad joins and teaches me something about how to use Claude Code better, because they think about it natively. It's extra hard because with every new model, you have to recalibrate and relearn. Going back to the member of technical staff thing, I think it's really important because all these old distinctions between engineer, PM, designer, user researcher—by the end of the year it's gone. This helps us see this clearly and act in this way today. I think you have to do within an AI lab is push everyone to be more agile and think about the future in this way.

我对此很好奇，也许稍微概括一下。对于在座的所有创始人和公司，他们现在应该为年底的组织考虑什么？你认为创始人和公司在未来几个月需要在心态上做出哪些改变？

I'm curious on that front, maybe generalize a bit. For all the founders and companies in this room, what should they be thinking about now for their organizations by the end of the year? What do you think founders and companies are going to have to change in their mindset over the coming months?

我认为今天我会做的是给每个人尽可能多的 token。引用黄仁勋的话，买得越多，省得越多。所以我会从这里开始：给人们尽可能多的 token，让他们实验。另一件事是稍微削减每个项目的资金。所以如果你在做一个项目，感觉需要四个工程师，那就放两个工程师，给他们一堆 token，让他们想办法完成。他们很可能能做到。

I would think today the thing that I would do is give everyone as many tokens as possible. The more you buy, the more you save, to quote Jensen. So this is where I would start: give people as many tokens as possible, let them experiment. The other thing I would do is underfund everything a little bit. So if you're working on a project and it feels like it needs four engineers, put two engineers on it and give them a bunch of tokens and have them figure out how to do it. Chances are they can do it.

他们可能可以自动化很多东西，可以简化很多东西，而且因为他们在自动化，下次可以做得更好，但只会更便宜。所以这就像一种复利效应。

There's probably a bunch of stuff they can automate, there's a bunch of stuff they can streamline, and because they're automating it, they can do it better next time, but it'll just be cheaper next time. So it's like a compounding effect.

是复利的。

It's compounding.

除了 token 之外，资源更少也会产生复利效应。

It's like a compounding effect to having fewer resources besides tokens.

没错。就像在商业和产品中，你要做很多决策，有一套原则会很有帮助。这样你就不必每次都临时做决定。通常创始人和公司都有这些原则文档，这有点像那样，但模型也可以使用这些原则，而且它以技能的形式出现。当然，如果某个用例爆发并消耗大量 token，那时你就要去优化它，让它更高效。但总的来说，如果我要总结一下，给你的建议是：用更少的人，把预算从人转移到 token。这样做的结果是提高前期成本，但降低持续成本。因为你已经提前做了大量工作，使得重复性的任务变得简单而高效。

That's right. It's sort of like in business and product, you make so many decisions, it's really good to have a set of principles. So you don't have to make ad hoc decisions every time. Often founders and companies have these principles documents, and this is kind of like that, but the model can use these principles also, and it comes in the form of skills. And of course, if there's some use case that takes off and uses a bunch of tokens, that's when you go in and optimize it and try to make it efficient. But in general, if I were to pair it back, the advice to you is: staff with fewer humans, shift budget from humans to tokens. What the output of that is, is to raise your upfront costs but decrease your ongoing costs. Because you've already done a big pile of work upfront so that the over and over and over again tasks are easy and streamlined.

是的，是的。这也许是一种思考方式。而且因为你投入的人更少，这意味着你公司的人可以做更多的事情。

Yeah, yeah. That's maybe a way to think about it. And because you put less people on it, that means the people at your company can do much more.

这对我来说是组建团队时最大的冲击：人们非常习惯于拥有头衔和专业领域，人们为自己是一个好的 PM 而自豪。'我要写一堆关于产品专业的博客文章。'或者设计师：'我等不及要展示我漂亮的设计作品集了。'我们是否都需要在 12 个月内摆脱'我们是什么'的想法，每个人都只是这个灵活的 token 生成袋？嗯，Ben，你太乐观了。

This feels like the biggest reckoning to me of building teams: people are pretty used to having a title and a discipline, and people take great pride in being a good PM. 'I'm going to write a bunch of blog posts about the discipline of product.' Or designers: 'I can't wait to show off my portfolio of my beautiful designs.' Do we all just need to, within 12 months, shake off the idea that we are anything, and everybody is just this flexible bag of token generation? Well, Ben, you're so optimistic.

我可能会用稍微不同的词，但没错。就是这样。你应该把这个印在 T 恤上。

I might use slightly different words, but yeah. There you go. You should make a t-shirt out of that.

我觉得差不多是这样。对我来说，我做过一段时间工程师，但我一直身兼多职。我以前创过业，做过业务、产品、用户研究、设计。所以对我个人来说，我就是喜欢构建产品。我不在乎我戴的是不是工程师的帽子。而现在我正看到这一点在实现。所以，是的，我觉得现在就是通才的黄金时代。那些想干不止一件事的人，从来没有这么有趣过，也从来没有这么容易过。

I think it's something like that. So, for me, I've been an engineer for a bit, but I've always worn different hats. I've started startups before, I've been on the business side, the product side, the user research side, the design side. So for me personally, I just love building product. I don't care that it has to be an engineering hat that I'm wearing. And so right now I see that being born out. So, yeah, I feel like right now this is just the golden age of the generalist. People that want to do more than one thing, it's just never been more fun. It's never been easier.

也许再问一个问题。我们和 Jared 聊过一点。我很好奇你的看法。你怎么看待品味？无论是你个人还是 Anthropic？

Maybe one more question. We spoke about with Jared a little bit. I'm curious your take on it. How do you think about taste? Either you personally or Anthropic?

我觉得每次我认为自己写代码的方式有什么特别之处时，我都错了。我以前对代码怎么写有很多看法。比如我非常喜欢函数式编程。所以我特别喜欢 Haskell 和 Scala 这些奇怪的函数式语言。一开始，我对我们的代码库有个规定：没有类，只有函数。因为那是我写代码的方式，是我喜欢的方式。然后周末的时候，工程师们开始偷偷加入有类的改动。我周一发现后就会撤回那个 PR，说'不，不，不，别这么做。'后来模型开始写所有代码，它直接就开始写类了。我就想，'好吧，也许模型是对的。也许这个看法有点蠢，只是我个人的偏好，而且这并不重要，因为业务目标达到了，而且因此实现得更快。代码实际上也不差。'显然代码随着时间的推移越来越好。所以我觉得每次我有这种'我在某方面很特别'的感觉时，我往往被证明是错的。我认为现在，以当前的模型能力，人们经常谈论的是 alpha 在于产品品味。而我认为这也会消失。这是今天的 alpha，但现在，我有几百个 quads 在运行，其中很多在查看 Twitter 反馈、GitHub issues、Slack，并决定下一步构建什么。现在大多数想法都很糟糕，但也许 20% 是好的。如果你等到下一个模型，再展望 3 个月、6 个月，大多数想法可能都会是好的。而且会有一些新的东西是我们真正擅长的，但我认为从长远来看，这种优势会逐渐消失。

I feel like every time I think there's something kind of special about the way that I do coding, I'm wrong. I used to have all these opinions about the way that we write the code. Like I really like functional programming. So I'm a big fan of Haskell and Scala and these kind of weird functional languages. At the very beginning, I had this rule for our code base: no classes, only functions. Because that's the way that I write my code, that's the way that I like it. And on the weekends, engineers just started sneaking in changes that had classes. I would find that on Monday and then pull out the pull request and be like, 'No, no, no, don't do that.' Then at some point the model started writing all the code and it just started writing classes. And I was like, 'Okay, well, maybe the model's right. Maybe this opinion is kind of stupid and it's just this particular thing that I have, and it doesn't matter because the business outcome is met, and it's met faster as a result. And the code actually is not bad.' Obviously the code's been getting better over time. And so I feel like every time that I have this kind of sense that I'm special in some way, I'm often proven wrong. And I think right now, with the current model capabilities, something that people talk a lot about is that the alpha is product taste. And I think this is also going to go away. This is alpha today, but also, right now I have a couple hundred quads running doing stuff, and a bunch of them are looking at Twitter feedback, GitHub issues, Slack, and figuring out what to build next. Right now most ideas are bad, but maybe 20% are good. If you wait for the next model and project out maybe 3 months, 6 months, most ideas will probably be good. And there's going to be some new thing that we're really great at, but I think in the long term this kind of erodes.

你猜那是什么？有没有什么最终的东西是人类独一无二擅长的？

Any guesses at what it is? Is there some final thing where humans are uniquely good at it?

我认为我们最终要教给模型的是价值观。如何成为——就像我们教孩子如何成为好人一样——我们要教模型如何成为一个好模型。

I think the final thing that we're going to be teaching the models is values. How to be, you know, the way that we teach our kids how to be good people, we're going to teach the model how to be a good model.

太有意思了。好吧，我们就停在这里。是的。Boris，非常感谢你。这太有意思了。谢谢。

Fascinating. Well, that is quite the place to leave it. Yeah. Boris, thank you so much. This is fascinating. Thank you.