生产环境中的氛围编程：负责任的 AI 代码生成

大家好，欢迎。今天我们来聊聊大家最喜欢的话题：vibe coding。而且有点争议的是，如何负责任地在生产环境中进行 vibe coding。那么，我们先谈谈什么是 vibe coding。

Hey everyone, welcome. I'm here to talk about everyone's favorite subject, vibe coding. And somewhat controversially, how to vibe code in prod responsibly. So let's talk about vibe coding and what this even is.

首先，我是 Erik，Anthropic 的研究员，专注于编码智能体。我和 Barry Zang 合著了《构建高效智能体》，其中为大家概述了创建智能体的最佳科学方法和最佳实践，无论应用场景是什么。这个话题对我来说意义重大。去年，我骑车上班时摔断了手，打了两个月石膏，那两个月里 Claude 替我写了所有代码。所以，弄清楚如何高效地做到这一点对我来说非常重要，幸运的是我很好地解决了这个问题，并通过我的研究帮助将其应用到 Anthropic 的许多其他产品和模型中。

First of all, I'm Erik. I'm a researcher at Anthropic focused on coding agents. I was the author along with Barry Zang of building effective agents where we outlined for all of you our best science and best practices for creating agents no matter what the application is. This is a subject that's near and dear to my heart. Last year I actually broke my hand while biking to work and was in a cast for two months and Claude wrote all of my code for those two months. So figuring out how to make this happen effectively was really important to me and I was luckily able to figure that out well and sort of help bring that into a lot of Anthropic's other products and in our models through my research.

那么，首先我们来谈谈什么是 vibe coding。很多人把 vibe coding 和大量使用 AI 生成代码混为一谈。但我觉得这不完全正确。很多人，你知道，他们在用 Cursor，用 Copilot。大量代码来自 AI，而不是他们自己写。但我认为，当你仍然与模型保持紧密的反馈循环时，那并不是真正的 vibe coding。我所说的 vibe coding，需要引用 Andrej Karpathy 的定义：vibe coding 是指你完全沉浸在氛围中，拥抱指数级增长，甚至忘记代码的存在。我认为关键点是“忘记代码的存在”。

So let's first start talking about what is vibe coding. A lot of people really conflate vibe coding with just extensive use of AI to generate your code. But I think this isn't quite true. A lot of people, you know, they're using Cursor, they're using Copilot. It's a lot of AI and a lot of the code is coming from the AI rather than them writing it themselves. But I think when you are still in a tight feedback loop with the model like that, that isn't truly vibe coding. When I say vibe coding, I think we need to go to Andrej Karpathy's definition where vibe coding is where you fully give into the vibes, embrace exponentials, and forget that the code even exists. I think the key part here is forget the code even exists.

这之所以重要，是因为 vibe coding 让工程行业以外的人真正开始对代码生成感到兴奋。Copilot 和 Cursor 很棒，但主要面向工程师；而一个不会编程的人，突然通过 vibe coding 就能自己编写整个应用。这非常令人兴奋，对很多人来说是一个巨大的突破。当然，这也有很多缺点，有些人第一次编程，完全不知道自己在做什么。你会说，“嘿，你看，各种奇怪的事情发生了，我的 API 密钥被用爆了，有人绕过订阅，在数据库里乱搞。”所以，这就是 vibe coding 开始出现的一些负面影响。而你能看到的正面案例，都是那些风险很低的事情。比如人们构建视频游戏，或者一些有趣的副项目，即使有 bug 也没关系。

Now the reason this is important is that vibe coding was when people outside of the engineering industry really started getting excited about code generation. Copilot and Cursor were great but only sort of for engineers, but someone that didn't know how to code suddenly with vibe coding they could find themselves coding an entire app by themselves. And this was a really exciting thing and a big unlock to a lot of people. Now, of course, there were a lot of downsides of this and you had people coding for the first time and really without knowing what they were doing at all. And you said, 'Hey, you know, random things are happening, max out usage on my API keys, people are bypassing the subscription, creating random on the DB.' And so, this is kind of the downside of vibe coding of what started happening. And the positive sides of vibe coding that you'd see were all things that were really kind of low stakes. It was people building video games, building sort of fun side projects, things where it's okay if there was a bug.

那么，如果 vibe coding 用于真实产品风险很高，而最成功的案例又都是些低风险的玩具示例或有趣的东西，我们为什么还要关心它呢？我的答案是，因为指数级增长。AI 能完成的任务时长每七个月翻一番。现在大概是 1 小时。这没问题。你不需要 vibe coding。你可以让 Cursor 为你工作，让 Claude Code 写一个需要 1 小时的功能。你可以审查所有代码，在 AI 编写大量代码时仍然深度参与。但明年呢？后年呢？当 AI 强大到一次就能生成你一整天甚至一整周的工作量时，如果我们仍然需要亦步亦趋，我们根本无法跟上。这意味着，如果我们想利用这种指数级增长，就必须找到一种方法，负责任地融入其中，并利用好这个任务。

So, you know, why do we even care about vibe coding if it seems like something where the stakes are really high if you do it for a real product? And the most successful cases of it are kind of these toy examples or fun things where the stakes are very low. And my answer for why we should care about vibe coding is because of the exponential. The length of tasks that AI can do is doubling every seven months. Right now we're at about an hour. And that's fine. You don't need to vibe code. You can have Cursor work for you. You can have Claude Code write a feature that would take an hour. And you can review all that code and you can still be intimately involved as the AI is writing a lot of your code. But what happens next year? What happens the year after that? When the AI is powerful enough that it can be generating an entire day's worth of work for you at a time or an entire week's worth of work, there is no way that we're going to be able to keep up with that if we still need to move in lock step. And that means that if we want to take advantage of this exponential, we are going to have to find a way to responsibly give into this and find some way to leverage this task.

我最喜欢的类比是编译器。我相信在编译器早期，很多开发者并不信任它们。他们可能会用编译器，但还会去读编译器输出的汇编代码，确保它看起来像自己会写的那样。但这根本无法扩展。到了某个阶段，你需要处理的系统足够大，你只能信任系统。问题在于，如何负责任地做到这一点？我认为，未来几年我对整个软件行业的挑战是：我们如何安全地在生产环境中进行 vibe coding？我的答案是：我们会忘记代码的存在，但不会忘记产品的存在。

I think my favorite analogy here is like compilers. I'm sure in the early days of compilers, a lot of developers really didn't trust them. They might use a compiler, but they'd still read the assembly that it would output to make sure it looks how they would write the assembly. But that just doesn't scale. At a certain point, you start needing to work on systems that are big enough that you just have to trust the system. The question though is how do you do that responsibly? And I think my challenge to the whole software industry over the next few years is how will we vibe code in prod and do it safely? And my answer to that is that we will forget that the code exists but not that the product exists.

再回到编译器的类比，我们都知道底层有汇编代码，但希望大多数人不需要真正去思考汇编到底是什么。但我们仍然能够在不懂底层汇编的情况下构建出优秀的软件。我认为，对于软件，我们也会达到同样的水平。我想强调的一点是，这并不是一个新问题。CTO 如何管理一个自己并非专家的领域里的专家？产品经理如何评审一个工程功能，如果自己无法阅读其中的所有代码？或者 CEO 如何检查会计的工作，如果自己不是财务会计方面的专家？这些问题已经存在了几百年甚至几千年，我们也有解决方案。

Thinking again to that compiler analogy, we all still know that there's assembly under the hood, but hopefully most of us don't need to really think about what the assembly actually is. But we still are able to build good software without understanding that assembly under the hood. And I think that we will get to that same level with software. And one thing I really want to emphasize is that this is not a new problem. How does a CTO manage an expert in a domain where the CTO is not themselves an expert? How does a PM review an engineering feature when they themselves can't read all the code that went into it? Or how does a CEO check the accountant's work when they themselves are not an expert in financial accounting? And these are all problems that have existed for hundreds or thousands of years and we have solutions to them.

CTO 仍然可以为下属的专家编写验收测试，即使他们不理解底层的实现。他们可以看到这些验收测试通过，工作质量很高。产品经理可以使用工程团队构建的产品，确保它按预期工作，即使他们不写代码。CEO 可以抽查他们理解的关键事实和数据片段，从而建立对整个财务模型的信心，即使他们自己可能不是整个流程的专家。所以，思考这些例子，管理你自己并不理解的实现，实际上是一个与文明一样古老的问题。世界上的每一位管理者其实都在处理这个问题。只是我们软件工程师不习惯这样。我们习惯于做纯粹的个体贡献者，理解从底层到上层的全部深度。但为了达到最高效率，我们需要放弃这一点，就像每一位管理者为了最高效率都需要放弃一些细节一样。就像我们软件工程师，我们放弃了对底层汇编代码细节的理解。

A CTO can still write acceptance tests for an expert that works for them even if they don't understand the implementation under the hood. They can see that these acceptance tests pass and that the work is high quality. A product manager can use the product that their engineering team built and make sure that it works the way they expected even if they're not writing the code. And a CEO can spot check key facts that they do understand and slices of the data so that they can build confidence in the overall financial model even though they themselves might not be an expert in how the entire thing flows. And so thinking about these examples, managing implementations that you yourself don't understand is actually a problem as old as civilization. And every manager in the world is actually already dealing with this. Just we as software engineers are not used to this. We are used to being purely individual contributors where we understand the full depth down to the stack. But that's something that in order to become most productive, we are going to need to let go of in the way that every manager in order to be most productive is going to need to let go of some details. And just like us as software engineers, we let go of some of the details of understanding the assembly itself that's happening under the hood.

在保证安全且负责任的前提下，做到这一点的方法是找到一个抽象层，即使不了解底层的实现，也能对其进行验证。不过，今天我要提一个例外，那就是技术债务。目前，除了亲自阅读代码之外，还没有很好的方法来衡量或验证技术债务。生活中大多数其他系统，比如会计的例子、项目经理，你都有办法在不了解实现的情况下验证你关心的事情。我认为技术是少数几个真正没有好的验证方法、除非你是实现本身的专家的领域之一。所以这是我们目前还无法很好验证的一件事。但这并不意味着我们完全不能这样做。它只是意味着我们需要非常聪明和有针对性，清楚在哪些地方可以利用编码的优势。

And the way that you do this while still being safe and being responsible is to find an abstraction layer that you can verify even without knowing the implementation underneath it. Now I have one caveat to that today which is tech debt. So right now there is not a good way to measure or validate tech debt without reading the code yourself. Most other systems in life, like the accountant example, the PM, you have ways to verify the things you care about without knowing the implementation. Tech, I think, is one of those rare things where there really isn't a good way to validate it other than being an expert in the implementation itself. So that is the one thing that right now we do not have a good way to validate. However, that doesn't mean that we can't do this at all. It just means we need to be very smart and targeted, aware of where we can take advantage of coding.

我的答案是专注于代码库中的叶子节点。我的意思是，代码和系统中没有任何其他部分依赖的那些部分。它们有点像最终的功能，是锦上添花的东西。而不是像白色部分那样，是它们下面的分支或主干。这里的橙色点都是这些叶子节点，老实说，如果你的系统是这样的，这些叶子节点里有点技术债务也没关系，因为没有其他东西依赖它们。它们不太可能改变，也不太可能在上面构建更多东西。而白色部分，即系统的主干和底层分支，才是核心架构，我们作为工程师仍然需要深入理解，因为那些是会变化的，其他东西会构建在它们之上。保护这些部分，确保它们保持可扩展、可理解和灵活，非常重要。

My answer to this is to focus on leaf nodes in our codebase. And what I mean by that is parts of the code and parts of our system that nothing depends on them. They are kind of the end feature. They're the end bell or whistle. Rather than things that are the branch or trunks beneath them, like here in white. Here the orange dots are all these leaf nodes where honestly, if you have a system like this, it's kind of okay if there is tech debt in these leaf nodes because nothing else depends on them. They're unlikely to change. They're unlikely to have further things built on them, versus the things that are in white here, the trunks and the underlying branches of your system. That is the core architecture that we as engineers still need to deeply understand because that's what's going to change. That's what other things are going to be built on, and it's very important that we protect those and make sure that they stay extensible, understandable, and flexible.

这里我要说的一点是，模型一直在变得更好，所以我们可能会进入一个世界，这种信任会越来越深入，我们越来越信任模型能写出可扩展且没有技术债务的代码。过去一两周在 Anthropic 内部使用 Claude 4 模型，真的非常令人兴奋，我对它们的信任比 3.7 版本多得多。所以我认为这种情况会改变，我们将能够以这种方式处理栈中越来越多的部分。

Now the one thing I will say here is that the models are getting better all the time, and so we might get to a world where this gets further and further down, where we trust the models more and more to write code that is extensible and doesn't have tech debt. Using the Claude 4 models over the last week or two within Anthropic has been a really exciting thing, and I've given them much more trust than I did with 3.7. So I think that this is going to change, and more and more of the stack we will be able to work with in this way.

那么我们来谈谈如何成功地进行 vibe coding。我的主要建议是：不要问 Claude 能为你做什么，而要问你能为 Claude 做什么。我认为当你进行 vibe coding 时，你基本上是在扮演 Claude 的产品经理。所以你需要像产品经理一样思考。一个新员工在你的团队中需要什么样的指导或背景信息才能成功完成这项任务？我认为很多时候我们太习惯于和 AI 进行非常快速的来回对话，比如“实现这个功能，修复这个 bug”，但如果一个人第一天上班，你只说“嘿，实现这个功能”，你绝不会指望他真的能成功。你需要带他熟悉代码库。你需要告诉他实际的需求、规格和约束是什么。我认为当我们进行 vibe coding 时，我们有责任将这些信息输入给 Claude，确保它拥有所有相同的上下文，并为成功做好准备。

So let's talk about how to succeed at vibe coding. And my main advice here is: ask not what Claude can do for you, but what you can do for Claude. I think when you're vibe coding, you are basically acting as a product manager for Claude. So you need to think like a product manager. What guidance or context would a new employee on your team need to succeed at this task? I think a lot of times we're too used to doing a very quick back and forth chat with AI of "make this feature, fix this bug," but if a human were on their first day on the job and you just said, "Hey, implement this feature," there's no way you'd expect them to actually succeed at that. You need to give them a tour of the codebase. You need to tell them what are the actual requirements, specifications, and constraints that they need to understand. And I think that as we vibe code, that becomes our responsibility to feed that information into Claude to make sure that it has all of that same context and is set up to succeed.

当我和 Claude 一起开发功能时，我经常花 15 到 20 分钟将指导信息收集到一个提示中，然后让 Claude 去执行。这 15 到 20 分钟并不只是我手动写提示。这通常是一个单独的对话，我和 Claude 来回交流。它探索代码库，查找文件。我们一起制定一个计划，捕捉我想要的核心内容，哪些文件需要修改，应该遵循代码库中的哪些模式。一旦我有了那个产物，所有那些信息，我就把它交给 Claude，要么在新的上下文中，要么说“嘿，我们来执行这个计划”。我通常发现，一旦我付出努力收集了所有这些信息，Claude 就能以非常好的方式完成事情，成功率非常高。

When I'm working on features with Claude, I often spend 15 or 20 minutes collecting guidance into a single prompt and then let Claude cook after that. And that 15 or 20 minutes isn't just me writing the prompt by hand. This is often a separate conversation where I'm talking back and forth with Claude. It's exploring the codebase. It's looking for files. We're building a plan together that captures the essence of what I want, what files are going to need to be changed, what patterns in the codebase should it follow. And once I have that artifact, all of that information, then I give it to Claude, either in a new context or say, "Hey, let's go execute this plan." And I've typically seen once I put that effort into collecting all that information, Claude has a very, very high success rate of being able to complete something in a very good way.

这里我还要说的是，你需要能够提出正确的问题。尽管我演讲的标题如此，但我并不认为 vibe coding 和产品开发适合所有人。我认为完全非技术人员不应该尝试从零开始构建一个完整的业务。我认为那是危险的，因为他们无法提出正确的问题。当他们这样做时，他们无法成为 Claude 有效的产品经理，所以他们不会成功。

And the other thing I'll say here is that you need to be able to ask the right questions. And despite the title of my talk, I don't think that vibe coding and prod is for everybody. I don't think that people that are fully non-technical should go and try to build a business fully from scratch. I think that is dangerous because they're not able to ask the right questions. They're not able to be an effective product manager for Claude when they do that, and so they're not going to succeed.

我们最近合并了一个 22,000 行的变更到我们的生产强化学习代码库中，这个变更很大程度上是由 Claude 编写的。那么我们到底是如何负责任地做到这一点的呢？是的，这是 GitHub 上那个 PR 的 diff 的实际截图。首先，我们问了自己能为 Claude 做什么。这不仅仅是一个提示然后我们就合并了。仍然有数天的人工工作投入其中，包括提出需求、指导 Claude 以及弄清楚系统应该是什么样子。我们真的、真的拥抱了自己作为 Claude 产品经理的角色。

We recently merged a 22,000-line change to our production reinforcement learning codebase that was written heavily by Claude. So how on earth did we do this responsibly? And yes, this is the actual screenshot of the diff from GitHub for the PR. The first thing is we asked what we could do for Claude. This wasn't just a single prompt that we then merged. There was still days of human work that went into this of coming up with the requirements, guiding Claude, and figuring out what the system should be. And we really, really embraced our roles as the product manager for Claude in this feature.

这个变更主要集中在代码库的叶子节点上，我们知道在这些地方有一些技术债务是可以接受的，因为我们预计这些部分在近期内不需要更改。而对于我们认为重要、需要可扩展的部分，我们对这些部分进行了大量的人工审查。最后，我们精心设计了稳定性压力测试。我们设计了整个系统，使其具有非常容易人工验证的输入和输出。最后这两点让我们能够创建这种可验证的检查点，这样即使不了解或不阅读完整的底层实现，我们也能确保其正确性。

The change was largely concentrated in leaf nodes in our codebase where we knew it was okay for there to be some tech debt because we didn't expect these parts of the codebase to need to change in the near future. And the parts of it that we did think were important that would need to be extensible, we did heavy human review of those parts. And lastly, we carefully designed stress tests for stability. And we designed the whole system so that it would have very easily human verifiable inputs and outputs. And what that let us do, these last two pieces, is it let us create these sort of verifiable checkpoints so that we could make sure that this was correct even without understanding or reading the full underlying implementation.

我们最大的担忧是稳定性，我们能够通过创建这些压力测试并长时间运行来测量稳定性，甚至无需阅读代码。我们能够根据我们设计的系统的输入和输出来验证正确性。所以基本上，我们设计了这个系统，使其即使我们不阅读所有代码也能被理解和验证。最终，通过结合这些方法，我们对这个变更的信心与对代码库中任何其他变更的信心一样高，但交付它所花费的时间和精力却只是手工编写并逐行审查整个代码所需的一小部分。

Our biggest concern was stability, and we were able to measure that even without reading the code by creating these stress tests and running them for long durations. And we were able to verify correctness based on the inputs and outputs of the system that we designed it to have. So basically we designed this system to be understandable and verifiable even without us reading all the code. And so ultimately, by combining those things, we were able to become just as confident in this change as any other change that we made to our codebase, but deliver it in a tiny fraction of the time and effort that it would have taken to write this entire thing by hand and review every line of it.

我认为这件事最令人兴奋的一点，不仅仅是它为我们节省了一周的人力时间，而是知道我们能这样做之后，它让我们重新思考我们的工程方式，思考我们能做什么。现在，当某件事的成本从两周变成一天时，你会意识到你可以去实现更大得多的功能和变更。这就像软件的边际成本降低了，让你能够消费和构建更多的软件。所以我认为真正令人兴奋的是，不仅节省了时间，而且现在感觉，哦，那些需要两周的事情，我们就去做吧，反正只需要一天。这就是令人兴奋的地方。那么，关于如何在生产环境中负责任地进行 vibe coding，我给大家的结束思考是：做 Claude 的产品经理。不要问 Claude 能为你做什么，而要问你能为 Claude 做什么。把你的 vibe coding 集中在叶节点上，而不是核心架构和底层系统，这样如果有技术债务，它也是被限制的，不会出现在重要区域。思考可验证性，以及如何在不亲自阅读代码的情况下知道这个变更是否正确。最后，记住指数效应。今天你不做 vibe coding 没关系，但一两年后，如果你坚持要求自己阅读每一行代码或编写每一行代码，那将是一个巨大的劣势。你将无法利用最新一波能够为你生成大量工作的模型。如果我们不擅长这个，你就会成为瓶颈。总而言之，这就是在生产环境中负责任地进行 vibe coding。我认为这将在未来几年成为软件工程行业最大的挑战之一。谢谢。我有充足的时间回答问题。

And I think one of the really exciting things about this is not just that it saved us a week's worth of human time, but knowing that we could do this, it made us think differently about our engineering, about what we could do. And now suddenly when something costs one day of time instead of two weeks, you realize that you can go and make much bigger features and much bigger changes. It's like the marginal cost of software is lower and it lets you consume and build more software. So I think the really exciting thing is not just saving the time but now feeling like, oh, things that are going to take two weeks, let's just do them. It's only going to take a day. And that's the exciting thing here. So to leave you with closing thoughts about how to vibe code in production responsibly: be Claude's PM. Ask not what Claude can do for you, but what you can do for Claude. Focus your vibe coding on the leaf nodes, not the core architecture and underlying systems, so that if there is tech debt, it's contained and not in important areas. Think about verifiability and how you can know whether this change is correct without needing to go read the code yourself. And finally, remember the exponential. It's okay today if you don't vibe code, but in a year or two, it's going to be a huge disadvantage if you yourself are demanding that you read every single line of code or write every single line of code. You're going to not be able to take advantage of the newest wave of models that are able to produce very large chunks of work for you. And you are going to become the bottleneck if we don't get good at this. So overall, that is vibe coding in production responsibly. And I think this is going to become one of the biggest challenges for the software engineering industry over the next few years. Thank you. And I have plenty of time for questions.

过去我们花大量时间处理语法问题、库或者代码组件之间的连接，我们就是这样通过编码来学习的。但现在我们怎么学习？我们如何成为更好的程序员？我们如何了解更多，从而成为智能体 AI 更好的产品经理？

In the past we spent a lot of time dealing with syntax problems or libraries or connections among components of the code, and that was how we learned by coding like that. But how do we learn now? How do we become better coders? How do we know more to become better product managers of the agent AI?

是的，我认为这是一个非常有趣的问题，既有令人担忧的理由，也有令人乐观的理由。令人担忧的理由，正如你提到的，是我们将不再经历那种挣扎和磨砺。我认为这其实没关系。我大学时的一些教授会说，‘啊，现在的程序员没那么好了，因为他们从不需要手写汇编。他们并不真正感受让程序跑得飞快的痛苦。’我认为积极的一面是，我发现使用这些 AI 工具，我能更快地学习东西。很多时候，当我用 Claude 编码时，我会审查代码，然后说，‘嘿 Claude，我从未见过这个库。给我讲讲。它是什么？你为什么选择它而不是另一个？’拥有这样一个随时在线的结对编程伙伴。再次强调，我认为会改变的是，懒惰的人不会学习，他们只会混过去。但如果你花时间并且想学习，有这么多惊人的资源，Claude 会帮你理解它为你 vibe coding 的内容。另外我想说的是，对于学习那些更高层次的东西——比如什么让项目进展顺利，什么功能能让你实现产品市场契合而非失败——我们将能够有更多的尝试机会。我觉得尤其是系统工程师或架构师，通常需要两年时间才能在代码库中做出重大改变，并真正判断那是否是一个好的架构决策。如果我们能把那个时间压缩到六个月，我认为那些投入时间并努力学习的工程师，在同样的日历时间内，将能够学到四倍的经验教训，只要他们付出努力去尝试。

Yeah, so I think this is a really interesting question and I think there are reasons to be very worried about this and also reasons to be very optimistic. I think the reason to be worried, like you mentioned, is that we are not going to be there in the struggle in the grind. I think that is actually okay. I've met some of my professors in college who would say, 'Ah, coders today aren't as good because they never had to write their assembly by hand. They don't really feel the pain of how to make something run really fast.' I think the positive side of this is that I have found that I'm able to learn about things so much more quickly by using these AI tools. A lot of times when I am coding with Claude, I'll be reviewing the code and I'll say, 'Hey Claude, I've never seen this library before. Tell me about it. What is it? Why did you choose it over another?' And having that always-there pair programmer. Again, I think what's going to change is that people who are lazy are not going to learn. They're just going to glide by. But if you take the time and you want to learn, there are all these amazing resources and Claude will help you understand what it vibe coded for you. The other thing I will say is that for learning some of these higher-level things about what makes a project go well, what is a feature that gets you product-market fit versus flops, we're going to be able to take so many more shots on goal. I feel like especially system engineers or architects, it often takes two years to make a big change in a codebase and really come to terms with whether that was a good architecture decision or not. And if we can collapse that time down to six months, I think engineers who are investing in their own time and trying to learn are going to be able to learn from four times as many lessons in the same amount of calendar time, as long as they're putting in the effort to try.

回到你的预规划流程，在给太多信息和太少信息之间如何平衡？你会给它完整的 PRD 吗？在你真正进入 vibe coding 之前，有没有某种标准化的模板？

Going back to your pre-planning process, what's the balance between giving it too much information and too little? Are you giving it a full product requirement document? Is there a kind of standardized template that you put together before you actually move into vibe coding?

是的，我认为这在很大程度上取决于你在意什么。对于我不太关心它如何实现的事情，我根本不会谈论实现细节。我只会说这是我的需求，这是我最终想要的。其他时候，我对代码库很熟悉，我会深入得多，比如，‘嘿，你应该用这些类来实现这个逻辑。看看这个类似功能的例子。’我认为归根结底取决于你最终在意什么。不过我要说，我们的模型在你不过度约束它们时表现最好。所以，我不会花太多精力去创建非常严格的格式之类的东西。我会像对待初级工程师一样思考，你会给他们什么来让他们成功。

Yeah, I think it depends a lot on what you care about. I would say that for things where I don't really care how it does it, I won't talk at all about the implementation details. I'll just say these are my requirements, this is what I want at the end. There are other times where I know the codebase well and I will go into much more depth, like, 'Hey, these are the classes you should use to implement this logic. Look at this example of a similar feature.' I'd say it all comes down to what you care about at the end of the day. I would say though that our models do best when you don't over-constrain them. So I wouldn't put too much effort into creating a very rigorous format or anything. I would just think about it like a junior engineer, what you would give them in order to succeed.

你是如何平衡有效性和网络安全的？几个月前有报道说，排名前十的 vibe coding 应用非常脆弱，大量重要信息被泄露。嗯，不是泄露，而是被证明可以泄露，而且做这件事的人甚至不是专业黑客。那么，你是如何平衡在叶节点层面保持安全，同时又保持有效性的？因为有些东西可能有效但不安全。

How did you balance effectiveness and cyber security? There were reports a couple months back of the top 10 vibe-coded apps being super vulnerable and a lot of important information was released. Well, not released but proven to be released, and the person who did it wasn't even a pro hacker. So how did you balance being able to keep things secure even at a leaf node level, and also being effective, because something can be effective but not secure?

是的，这是个很好的问题，我认为这完全归结于第一点：做 Claude 的产品经理，对上下文有足够的理解，基本上知道什么是危险的，什么是安全的，以及在哪里应该小心。我认为那些关于 vibe coding 的大量报道，都是些根本不该编码的人在搞这些。这没问题。这对游戏很好，对创造力和让人们能够创造很好。但我认为对于生产系统，你需要知道足够多的问题来引导 Claude 走向正确的方向。至于我们内部的这个例子，它是一个完全离线的场景。

Yeah, that's a great question and I think that all comes down to this first point of being Claude's PM and understanding enough about the context to basically know what is dangerous, know what's safe, and know where you should be careful. And I think the things that get a lot of press about vibe coding are people that have no business coding at all doing these. And that's fine. That's great for games, that's great for creativity and having people be able to create. But I think for production systems, you need to know enough about what questions to ask to guide Claude in the right direction. And for our internal case of this example, it was something that is fully offline.

所以我们知道不会出现任何安全问题。在我们的案例中，它是在完全离线的环境中运行的。

And so we knew there weren't any security problems that could happen into this. In our case, it's run in something that's fully offline.

所以这更多是关于你提到的那些人不应该在重要系统的生产环境中进行 vibe coding。我会这么说。但如果我们看看数据，全球只有不到 0.5% 的人口是软件开发人员，而软件是扩展想法的绝佳方式。那么你认为产品需要如何改变，才能让人们更容易进行 vibe coding 和构建软件，同时避免像泄露 API 密钥这类问题？

So this is more about people you're mentioning as having no business vibe coding in production for an important system. I will say that. But if we look at the numbers, less than 0.5% of the world's population are software developers, and software is an amazing way to scale ideas. So how do you think the products need to change to make it easier for people to vibe code and build software while also avoiding some of the things that we run into with people leaking API keys and things like that?

这是一个非常好的问题，我会非常兴奋地看到更多类似可证明正确的产品和框架出现。我的意思是，我相信人们可以构建一些后端系统，其中重要的部分（比如支付部分）已经为你建好了，你只需要填充 UI 层。你可以进行 vibe coding，它基本上给你一些很好的填空式沙盒来放置你的代码。我觉得有很多类似的东西可以存在。最简单的例子是 Claude Artifacts，Claude 可以帮助你编写代码，这些代码直接托管在 Claude AI 中显示。当然，这很安全，因为它非常有限。没有支付功能，只有前端。但也许这是一个好的产品思路：构建一种可证明正确的托管系统，其后端无论前端发生什么恶作剧都是安全的。我希望人们能构建与 vibe coding 互补的好工具。

That's a really great question, and I would be super excited to see more products and frameworks emerge that are kind of like provably correct. Maybe what I mean by that is I'm sure people could build some backend systems where the important parts, the payment parts, are built for you and all you have to do is fill in the UI layer. You can vibe code that, and it basically gives you some nice fill-in-the-blank sandboxes where to put your code. I feel like there are tons of things like that that could exist. The simplest example is Claude Artifacts, where Claude can help you write code that gets hosted right there in Claude AI to display. Of course, that is safe because it is very limited. There are no payments, it's front end only. But maybe that's a good product idea that someone should do: build some way to make a provably correct hosting system that can have a backend that is safe no matter what shenanigans happen on the front end. I hope people build good tools that are complements to vibe coding.

你好。关于测试驱动开发，你有什么建议吗？因为我经常看到 Claude 直接输出整个实现，然后编写测试用例。有时测试会失败，然后我想提示它先写测试用例，但我不想自己验证它们，因为我还没看到实现。所以你有可迭代的方法吗？你试过用于测试驱动开发吗？

Hi. For test-driven development, do you have any tips? Because I often see that Claude just spits out the entire implementation and then writes test cases. Sometimes they fail, and then I want to prompt it to write the test cases first, but I also don't want to verify them by myself because I haven't seen the implementation yet. So do you have an iterable approach? Have you ever tried it for test-driven development?

是的，我绝对认为测试驱动开发在 vibe coding 中非常有用，只要你能理解测试用例是什么。即使你不看测试，它也能帮助 Claude 保持更自洽。但很多时候，Claude 很容易陷入编写过于实现特定的测试的困境。当我尝试这样做时，我会给 Claude 一些例子，比如“嘿，只写三个端到端测试：快乐路径、一个错误案例和另一个错误案例。”我对此非常具体。我希望测试是通用的、端到端的。我认为这有助于确保我能理解，并且 Claude 不会陷入细节。我还要说，很多时候当我进行 vibe coding 时，我首先阅读的唯一代码部分就是测试，以确保我同意它们。如果测试通过了，我对代码就很有信心。如果你能鼓励 Claude 编写非常简约的端到端测试，效果最好。

Yeah, I definitely think test-driven development is very useful in vibe coding, as long as you can understand what the test cases are. Even without that, it helps Claude be a little more self-consistent, even if you yourself don't look at the tests. But a lot of times, it's easy for Claude to go down a rabbit hole of writing tests that are too implementation-specific. When I'm trying to do this, I will give Claude examples like, 'Hey, just write three end-to-end tests: the happy path, an error case, and this other error case.' I'm very prescriptive about that. I want the tests to be general and end-to-end. I think that helps make sure it's something I can understand, and something Claude can do without getting too in the weeds. I'll also say that a lot of times when I'm vibe coding, the only part of the code I read first is the tests, to make sure I agree with them. If the tests pass, I feel pretty good about the code. That works best if you can encourage Claude to write very minimalist end-to-end tests.

非常感谢你精彩的演讲。我也很欣赏你做了很多人没做的事，尝试解读 Karpathy 原始帖子中比较奇特的一句话“拥抱指数增长”。所以我想再追问一下：我怎么知道我是否拥抱了指数增长？遵循这个建议到底意味着什么？更具体地说，我认为它暗示了模型会变得更好。你认为这样说是否有道理：模型会变得更好，并不意味着它们会在我们可能想象的每一个维度上都变得更好？那么我该如何拥抱指数增长？

Thank you for the very fascinating talk. I also appreciate that you've done what a lot of people haven't done and tried to interpret one of the more peculiar lines in Karpathy's original post, 'embrace exponentials.' So I wonder if I could pin you down a little more: how would I know if I've embraced the exponentials? What precisely does following that advice mean? To put it down a little more in what I think it intends to mean, it sort of alludes to the fact that the models will get better. Do you think there's some legitimacy in saying that just because the models will get better doesn't mean they'll get better at every conceivable dimension we might be imagining? So how do I embrace exponentials?

是的，完全正确。我认为你接近了“不断假设模型会变得更好”这句话，但还要更进一步。指数增长的概念不仅仅是它们会不断变好，而是它们会以我们无法想象的速度变得更好。当你看到这些点的形状时，它不仅仅是稳步提升；而是变得更好，然后变得疯狂。我从 Dario 和 Mike Krieger 的演讲中听到的另一句有趣的话是：“《爱之机器》不是科幻小说，而是产品路线图。”尽管这听起来很遥远，但当你处于指数曲线上时，事情会变得非常快，比你预期的要快。如果你和 90 年代做计算机的人聊天，他们会说：“好吧，我们有几 KB 的 RAM，再多几 KB。”但快进到现在，我们有 TB 级的内存。这不仅仅是好了一倍；而是好了数百万倍。这就是 20 年间指数增长的结果。所以我们不应该把 20 年后想象成“如果这些模型好两倍会怎样”，而应该想象如果这些模型比今天聪明一百万倍、快一百万倍会怎样，这很疯狂。我们甚至无法想象这意味着什么，就像 90 年代做计算机的人无法想象如果计算机快一百万倍社会会变成什么样一样。但那就是发生的事情。所以这就是我们所说的指数增长：它会变得疯狂。

Yeah, absolutely. I think you got close with the quote of 'keep assuming the models are going to get better,' but it's a step beyond that. The idea of the exponential is not just that they're going to keep getting better, but they're going to get better faster than we can possibly imagine. When you can see the shape of the dots here, it's not just that it's getting steadily better; it's that it's getting better and then it goes wild. Another funny quote I heard from Dario and Mike Krieger's talk is 'Machines of Loving Grace is not science fiction; it's a product roadmap.' Even though it sounds like something very far out, when you are on an exponential, things get wild very fast, faster than you expect. If you talk to someone doing computers in the 90s, it's like, 'Okay, we have a couple kilobytes of RAM, a couple more kilobytes of RAM.' But fast forward to where we are now, we have terabytes. It's not just that it got twice as good; things got millions of times better. That's what happens with exponentials over 20 years. So we shouldn't think about 20 years from now as 'what happens if these models are twice as good.' We should think about what happens if these models are a million times smarter and faster than they are today, which is wild. We can't even think about what that means, in the same way that someone working on computers in the 90s couldn't think about what would happen to society if a computer was a million times faster. But that's what happened. So that's what we mean by the exponential: it's going to go bonkers.

是的。我有一个问题，但有两部分。第一部分：关于 vibe coding，我有两种不同的工作流程。一种是在终端里，另一种是在 VS Code 或 Cursor 中。

Yes. I have one question, but it's kind of two parts. The first part: when it comes to vibe coding, I have two different workflows. One where I'm in my terminal, and one when I'm in VS Code or Cursor.

你使用哪种工作流？如果你在终端中使用 Claude Code，你多久压缩一次？因为我发现，我写代码的时间越长，函数就会得到新名字，或者事情就会偏离轨道。如果我压缩，这种情况仍然会发生。如果我创建一个文档来引导它，我仍然需要让它回到正轨。

Which workflow do you use? And if you're using Claude Code in the terminal, how often do you compact? Because what I find is my functions will get a new name as the longer I vibe code, or things just kind of go off the rails the longer I go. And if I compact, it still happens. If I create a document to kind of guide it, I still have to get it back on track.

是的。好问题。我两种都用。我经常在 VS Code 的终端中打开 Claude Code 来编码。可以说 Claude Code 完成了大部分编辑工作，而我则在 VS Code 中一边进行一边审查代码，这在这里并不是真正的“氛围编码”。或者我可能只是审查它生成的测试。我喜欢在 Claude 达到一个好的停止点时进行压缩，或者直接开始一个新会话。这个点感觉就像，作为一个人类程序员，我什么时候会停下来休息一下，也许去吃个午饭再回来。如果我觉得自己处于那个阶段，那就是压缩的好时机。所以，我可能会先让 Claude 找到所有相关文件并制定一个计划，然后我会说，好的，把所有这些写到一个文档里，然后进行压缩。这样就去掉了创建计划和查找这些文件所花费的 10 万个 token，将其缩减到几千个 token。

Yeah. Great question. I do both. I often code with Claude Code open in my terminal in VS Code. And I'd say that Claude Code is doing most of the editing, and I'm kind of reviewing the code as I go in VS Code, which is not true vibe coding in the sense here. Or maybe I'm reviewing just the tests from it. I like to compact or just start a new session whenever I get Claude to a good stopping point, where it feels like, okay, as a human programmer, when would I stop and take a break and maybe go get lunch and then come back. If I feel like I'm at that kind of stage, that's a good time to compact. So maybe I'll start off with having Claude find all the relevant files and make a plan, and then I'll say, okay, write all this into a document, and then I'll compact. That gets rid of 100k tokens that it took to create that plan and find all these files, and boils it down to a few thousand tokens.

有一个问题是接着他之前的问题：你是否使用过其他工具与 Claude Code 一起使用来进一步提高速度，比如使用 git worktrees 同时运行多个 Claude Code，然后合并一些东西，或者堆叠 PR 之类的？这是你个人遵循或会建议的做法吗？第二个问题是，你如何以一种结构化的、非常好的工程方式，去处理代码库中你不太熟悉的部分，但又想非常快速地提交一个 PR，并且想以一种非常好的方式来做，而不是“氛围编码”？那么，你使用 Claude Code 来帮助完成这两件事的方法是什么？

One question is following up on his previous question: have you used other tools along with Claude Code to increase your speed a little bit more, like running multiple Claude Codes together using git worktrees and then merging few things, or stack PRs or something like that? Is that something you personally follow or would advise? Second question is, how do you structurally and in a very nice engineering way approach a part of the codebase that you're not very familiar with, but you want to ship a PR in it really fast and you want to do it in a really nice way and not vibe code it? So yeah, what are your ways of using Claude Code to help do both these things?

是的。所以，我肯定同时使用 Claude Code 和 Cursor。而且我通常会用 Claude Code 开始工作，然后用 Cursor 来修复问题。或者，如果我有非常具体的更改，如果我知道要对这个文件做什么更改，我会直接用 Cursor 自己来做，并定位到我知道需要修改的确切行。你问题的第二部分是，如何快速上手代码库的新部分。在我开始尝试编写功能之前，我会使用 Claude Code 来帮助我探索代码库。所以我可能会说，告诉我这个代码库中 X 发生在哪里，或者这个代码库中某个事情发生在哪里。告诉我与此类似的功能，并让它告诉我文件名。让它告诉我应该查看哪些类。然后利用这些信息来建立一个心理模型，确保我能做到这一点，而不是“氛围编码”。确保我仍然能很好地理解正在发生的事情。然后我再和 Claude 一起开发这个功能。

Yep. So, I definitely use Claude Code as well as Cursor. And I'd say typically I'll start things with Claude Code and then I'll use Cursor to fix things up. Or if I have very specific changes, if I know exactly the change that I want to do to this file, I'll just do it myself with Cursor and sort of target the exact lines that I know need to change. The second part of your question was, oh yeah, how to get spun up on a new part of the codebase. Before I start trying to write the feature, I use Claude Code to help me explore the codebase. So I might say, tell me where in this codebase X happens, or where in this codebase something happens. Tell me similar features to this, and have it tell me the file names. Have it tell me the classes that I should look at. And then kind of use that to try to build up a mental picture to make sure that I can do this and not vibe code. Make sure I can still get a good sense of what's happening. And then I go work on the feature with Claude.

非常感谢。我还会在这里，可以回答其他问题。

Thank you so much. I'll be still around and can answer other questions.