AI 原生产品的新产品经理手册

我认为要恰到好处地信奉 AGI 非常困难。为超级 AGI 强模型构建产品很容易，难的是针对当前模型，如何激发其最大能力。

I think it is very hard to be the right amount of AGI pilled. It's very easy to build a product for the super AGI strong model. The hard thing is figuring out for the current model, how do you elicit the maximum capability?

我从未见过像 Anthropic 这样的发布速度。

I've never seen anything like the pace you folks at Anthropic are shipping at.

我们希望消除发布产品的每一个障碍。我们许多产品功能的时间线已从 6 个月缩短到 1 个月，有时甚至缩短到 1 天。

We want to remove every single barrier to shipping things. The timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to even 1 day.

你面试了数百名产品经理，却一直觉得他们的方法非常不对。

You're interviewing hundreds of PMs and you just keep feeling like they're approaching it very incorrectly.

产品经理的角色正在发生巨大变化，而且变化非常快。构建 AI 原生产品极其重要的一点是快速迭代，找到一种方法让你每周都能实际发布功能。

The PM role is changing a lot. It's changing really quickly. The thing that is extremely important for building AI native products is iterating so quickly. Figuring out a way for you to actually launch features every single week.

你认为产品经理需要培养哪些新兴技能？

What do you think are the emerging skills PMs need to develop?

回到产品品味。随着代码编写成本大幅降低，更有价值的是决定写什么。

Back to product taste. As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.

今天的嘉宾是 Kat Wu，Anthropic Claude Coding 的产品负责人。Kat 处于 AI、产品和构建变革的中心，她和她的团队正在构建最改变我们所有人构建产品方式的产品。她充满了洞察、智慧和经验。这是一集你不能错过的节目。在开始之前，别忘了查看 Lenny's product pass.com，那里有专为 Lenny 通讯订阅者提供的超值优惠。话不多说，有请 Kat Wu。Cat，欢迎来到播客。

Today my guest is Cat Wu, head of product for Claude Coding who work at Anthropic. Cat is at the center of everything that is changing in AI and product and building and she and her team are building the product that is most changing the way that we all build our products. She is so full of insights and wisdom and lessons. This is an episode you cannot miss. Before we get into it, don't forget to check out Lenny's product pass.com for an insane set of deals available exclusively to Lenny's newsletter subscribers. With that, I bring you Cat Wu. Cat, welcome to the podcast.

谢谢邀请。

Thanks for having me.

我有很多问题。很高兴你能来这个播客。我想先让大家了解你和 Boris 的合作。大家都知道 Boris，他的那期节目是本播客最受欢迎的一期，没有压力。他创建了 Claude Code，领导工程团队，每天从手机提交无数个 PR，我都不清楚具体数字了。我认为人们没有给予你足够的认可，对于 Claude Code 的成功以及你们正在构建的一切。请帮助我们了解你在团队中的角色，你如何与 Boris 合作，如何分工，以及 Claude Code 团队的产品经理角色是什么样的？

I have so many questions. I'm so excited to have you on this podcast. I want to start with giving people an understanding of your role alongside Boris. Uh everybody knows Boris. This he's his episode is the number one most popular episode on this podcast. No pressure. He uh created Claude Code. He leads the eng team, ships a a bazillion PRs a day from his phone just like I don't even know what the number is anymore. I think people don't give you enough credit for the success that Claude code has had and co-work and all the things y'all are building. Help us understand your role on the team, how you work with Boris, how you split responsibilities, just like what does the PM role look like on the on the Claude code team?

我很幸运能与 Boris 共事。他是一位出色的思想伙伴。他是我们的技术负责人，也是产品愿景的制定者，他擅长设定产品在未来 3 到 6 个月应该达到的状态，也就是产品的 AGI 版本。我的很大一部分职责是弄清楚从我们现在的位置到那个 3 到 6 个月后的愿景的路径。我更多时间花在跨职能协调上，确保我们的市场团队、销售团队、财务、产能等认同计划，并且我们朝着同一个方向努力。一旦功能准备就绪，确保没有任何阻碍发布的障碍。我认为在很多方面，我们合作得很好，因为我们有点像心灵相通，但实际上界限非常模糊。我想我们大概有 80%的心灵相通，然后有 20%的事情可能我比 Boris 更关心，所以我会推动这些；另外 20%他比我更关心，他就直接推动。

I feel very lucky to work with Boris. He's been an amazing thought partner. He's our tech lead, he's very much the product visionary, and he is great at setting like this is what the product needs to be in like 3 months, 6 months from now. This is like what the AGI pill version of the product is. And a lot of my role is figuring out, okay, what is the path from where we are today to like that vision 3 to 6 months from now. And I I spend more of my time on the cross-functional, so making sure that our marketing team, sales team, finance, capacity, etc. are like bought in on the plan and that we're all rowing the same direction. And that once the feature is ready, that there aren't any blockers to shipping it. I think in many ways it works well because we kind of like mind meld, but it is actually like remarkably blurry of a line. Like I think we're like 80% mind meld, and then there's like this 20% of things that like maybe I care a lot more about than Boris, so like I'll drive those and then like 20% where he cares a lot more than me and he just like drives those.

本集由我们本季的赞助商 WorkOS 呈现。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，你一定感受过集成单点登录、SCIM、RBA、审计日志等大型公司所需功能的痛苦。WorkOS 将这些交易障碍转化为即插即用的 API，并提供一个专为 B2B SaaS 打造的现代开发者平台。实际上，我投资的每一家开始向上扩展的初创公司最终都与 WorkOS 合作。这是因为他们是最好的。无论你是种子阶段初创公司试图获得第一个企业客户，还是独角兽公司全球扩张，WorkOS 都是实现企业就绪和解除增长障碍的最快途径。它本质上是企业功能的 Stripe。访问 workos.com 开始使用，或者直接联系他们的 Slack，那里有真正的工程师等着回答你的问题。WorkOS 让你通过令人愉悦的 API、全面的文档和流畅的开发者体验更快地构建。立即访问 workos.com，让你的应用企业就绪。

This episode is brought to you by our season's presenting sponsor WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBA, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are seed stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise ready today.

在我们开始录制之前，你分享了一件事，那就是你一直在面试数百名产品经理。如果有人每次让我介绍去 Anthropic 做产品经理，我就能得到五分钱，那我早就拥有 300 亿 ARR 了。这简直是人们最想去工作的地方。所以我可以想象你面试了多少产品经理。你告诉我你发现人们做得不对，他们对于成为成功的 AI 产品经理所需条件的理解有误。谈谈你看到了什么，以及人们需要了解什么才能在这些日子取得成功。

Something that you shared actually before we started recording is the fact that you're interviewing hundreds of PMs all the time. Like, if I had a nickel every time someone asked me for an intro to someone at Anthropic to go work at Anthropic as a PM, I'd be I'd be I'd have 30 billion in ARR. It's just like the number one place people want to go work at. So, I can only imagine how many PMs you're interviewing. You told me that you're just seeing people doing it doing it wrong. The way they're approaching what they think it takes to be a successful AI PM. Talk about what you're seeing and what people need to understand about what it is what it takes to be successful these days.

我认为在 AI 之前，技术变革要慢得多，所以你可以按 6 到 12 个月的时间范围来规划。由于功能发布速度较慢，更多精力放在与所有其他合作团队协调，确保他们发布的功能能解锁你的功能，因为那时代码编写成本很高。现在有了 AI，工程速度大大加快，模型能力提升迅速，我们许多产品功能的时间线已从 6 个月缩短到 1 个月，有时甚至 1 周或 1 天。因此，我们需要确保产品快速发布。这意味着作为产品经理，应该减少对与合作伙伴团队对齐多季度路线图的关注，而更多关注如何找到最快的方法将产品推出。如何在我们产品套件中创建一个概念角落，让工程师或产品经理有了想法，到周末就能交到用户手中。我认为在 AI 原生产品上做得最好的产品经理，是那些能缩短从想法到产品实际交付给用户的时间，并帮助定义产品开箱即用所需的最重要任务的人。

I think before AI, technology shifts were a lot slower, so you could plan on these 6 to 12-month time horizons. And because you were shipping features at a bit of a slower rate, there was a lot more emphasis on coordinating with all the other partner teams to make sure that they're shipping features that unblock your features because code at that time was very expensive to make. Um I think now with AI and with how much that has accelerated engineering and with how quickly the model capabilities are improving, the timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to 1 week or even 1 day. And with that, we actually need to make sure that products ship quite quickly. And what that means is as a PM, there should be less emphasis on making sure that you're aligning your like multi-quarter roadmaps with your partner teams, and more emphasis on, okay, how can we figure out the fastest way to get something out the door? How can we figure out how to make like a concept corner of our product suite where we can just an engineer has an idea or a PM has an idea, and like by the end of the week, we are able to get into our users' hands. I I think the PMs who do the best on AI native products are are the ones who can figure out, how can I like shorten the time from having this idea to actually getting the product in the hands of users, and help define what are the most important tasks that need to work out of the box for my product.

所以我喜欢你说的这一点，就是人们还没意识到他们需要多快行动，而现在的工作很大程度上就是帮助团队快速推进。是什么帮助做到这一点？你做了什么？你的产品经理团队除了能接触到最先进的模型之外，还做了什么来帮助他们如此快速地推进？

So, what I love about this is what you're saying is just like people haven't grasped how fast they need to move and how much of the job now is just moving, is helping the team move fast. What helps do that? What do you do? What does your PM team do to help them move this fast other than have access to the most advanced models?

我认为第一件事是设定清晰的目标。因为大语言模型非常通用，这实际上造成了很大的模糊性：我们为谁构建、试图解决什么问题、最重要的用例是什么。所以，我认为优秀的产品经理能够说，好的，我们的关键用户是专业开发者。我们要为这个功能解决的主要问题可能是权限问题太多，人们感到疲劳，用例是让企业中的专业开发者安全地实现零权限提示。这实际上设定了一个非常清晰的目标，因为它排除了许多减少权限提示的潜在方法，让人们可以通过一个提示完成更多工作。然后我认为第二件非常重要的事情是找出一个可重复的流程来发布这些功能。所以，对于 Claude Code，我们实际上几乎所有的功能都是以研究预览的形式发布的。我们在发布时明确标注，让用户知道这是早期产品，只是一个想法，我们正在尝试获取反馈并迭代，可能不会永远支持。这样做减少了我们对发布某物的承诺，我们可以在一两周内推出。第三件产品经理应该做的事情是帮助团队建立框架，让他们知道何时引入跨职能合作伙伴，以及这些合作伙伴的期望是什么。例如，我们在工程、市场和文档之间有一个非常紧密的流程。当工程师觉得某个功能已经准备好并且我们在内部进行了 dogfood 测试后，他们会将其发布在我们的常青发布房间中。然后负责文档的 Sarah、负责产品营销的 Alex，以及开发者关系团队的 Tarek 和 Lydia 会立即介入，第二天就能完成市场公告。因为我们有这样一个紧密的流程，它降低了任何工程师发布功能的阻力。产品经理的角色就是建立这个流程。

I think the first thing is to set clear goals. Because LLMs are so general, that actually creates a lot of ambiguity in who we're building for, what problems we're trying to solve, what the top use cases are. And so, I think a great PM is able to say, okay, our key user is professional developers. The main problem we want to solve for this feature is maybe there's too many permission problems and people are feeling fatigue, and the use case is we want professional developers at enterprises to safely get to zero permission prompts. And that actually sets a pretty clear goal because it rules out a lot of potential approaches for reducing permission prompts so that people can get a lot more done with one prompt. And then I think the second thing that's very important is figuring out some repeatable process for getting these features shipped. So, for Claude Code, what we do is we actually ship almost all of our features in research preview. We clearly brand this when we ship something so that users know that this is an early product. This is just an idea. This is just something that we're trying to get feedback on and iterating on and that this might not be supported forever. And what this does is it reduces our commitment for shipping something. We can just get something out in a week or two. And the third thing that a PM should do is help create the framework for the team so that they know when to pull in cross-functional partners and what those cross-functional partners' expectations are. So, for example, we have a really tight process between engineering, marketing, and docs. So, when engineers have a feature that they feel is ready and that we've dogfooded internally, they post it in our evergreen launch room. And then Sarah, who leads our docs, and Alex, who leads PMM, and Tarek and Lydia on DevRel just jump in and can turn around the marketing announcement for it the very next day. And because we have this really tight process, it lowers the friction for any engineer to ship something. PM is the role that should be setting this up.

产品需求文档（PRD）如何融入其中？你说目标非常重要，是为了对齐成功的样子、为谁而做、不为谁而做。你们会写 PRD 吗？还是只是几个要点？在产品经理的世界里，这如何演变？

How do PRDs fit into this? So, the fact that you said that goals are really important part of just like being aligned on what does success look like? Who is this for? Who is this not for? Are you writing PRDs? Is it just like a couple bullet points? How does that evolve in the world of a PM?

我们做两件事。一是我们有非常严格的指标，并且每周与整个团队进行指标解读。这样做的目的是确保每个人都深入理解我们业务的各个方面、我们的关键目标是什么、趋势如何以及驱动因素是什么。第二件事是我们有一份团队原则清单。其中包括我们的关键用户是谁、为什么他们是关键用户，我们阐明这一切的原因是让团队中的每个人都觉得自己理解业务如何运作、什么对我们重要、我们愿意权衡什么，并且让人们能够自己做决定，而不觉得被产品经理或其他利益相关者阻碍。

So, there are two things that we do. One is we have very rigorous metrics and we do metrics readouts with the entire team every week. The goal of this is to make sure that everyone deeply understands all the facets of our business, what our key goals are, how they're trending, and what drives them. The second thing that we do is we have this list of team principles. And this includes who our key users are, why those are our key users, and the reason that we articulate all of this is so that everybody on the team feels like they understand how our business works, they understand what's important to us, and what we're willing to trade off, and it lets people make decisions by themselves without feeling like they're blocked on PM or any other stakeholder.

我喜欢这其中的很多内容，比如，好吧，我们未来仍然需要产品经理。有很多讨论说，为什么我们需要产品经理？我们只需要发布和构建，我们需要工程师。

I love how so much of this is like, okay, we still need PMs in the future. There's so much talk of like, why do we need PMs? We're just going to ship and build, we need engineers.

哦，我们有时确实会写 PRD。所以，我认为对于特别模糊的功能，写一页纸说明目标是什么、令人愉悦的用例是什么、当前需要修复的失败模式是什么，确实有帮助。偶尔有些项目，尤其是需要大量基础设施的项目，确实需要几个月时间，对于这些情况，我们仍然会写 PRD。

Oh, we actually do PRDs sometimes. So, I think for our features that are particularly ambiguous, it does help to write out just a one-pager on what the goals are, what the delightful use cases are, what the failure modes currently are that we need to fix. And there are occasionally some projects, especially things that require heavy infrastructure, that do take many months, and for those situations, we do write PRDs still.

我想进一步探讨一下你们是如何做到如此快速的。我从未见过像 Anthropic 团队这样的发布速度。有人制作了 Anthropic 的发布日历，几乎每天都有一个主要功能或产品。所以网上有人问，你们刚刚发布了这个不可思议的模型 Mythos，它还在预览中，因为它太强大了，人们有点害怕它能做什么。你们一直在使用它吗？这是你们能如此快速推进的部分原因吗？

I want to drill a little bit further into just how you're able to move so fast. I've never seen anything like the pace folks at Anthropic are shipping at. Like, someone made this calendar of launches across Anthropic, and it was literally every day there was like a major feature or product. So, one question people had online is you guys just launched this incredible model, Mythos, that is still in preview because it's so powerful people are a little afraid of what it can do. Have you guys been using this? Is this part of the reason you've been able to move so fast?

我们已经快速推进了好几个季度，所以我认为不完全是 Mythos 的原因。Mythos 是一个非常强大的模型。我们确实在内部使用这些模型，我认为这稍微提高了我们的发布速度，但我不认为这是增长的主要原因。我认为很大程度上是流程和团队的期望。所以我们的流程非常精简。我们希望消除发布产品的每一个障碍。我们希望确保团队中的每个人都感到有能力将自己的想法从仅仅一个想法变成现实，时间不超过一周，有时甚至一天。

We've been moving pretty fast for several quarters now, so I think it's not fully Mythos. Mythos is an incredibly powerful model. We do use the models internally, and I think this has increased our rate of shipping a little bit, but I don't think it explains the bulk of the increase. I think a lot of it is the process and the expectation on the team. So, we're very low on process. We want to remove every single barrier to shipping things. We want to make sure every single person on our team feels empowered to take their idea from just an idea to out in the world in less than a week. Sometimes even in a day.

酷。哦，天哪，拥有最好的模型并且同时在 Circle 构建产品，这是多大的优势啊。

Cool. Oh man, what an advantage to have the best model and also be building product at Circle.

我们非常幸运能够与前沿模型合作。

We are very lucky to be able to work with the frontier models.

哦，我的天，多么棒的优势。就像构建一个东西，然后使用它，然后加速更快。太有趣了。我想在这段对话中顺便谈一些其他事情。Anthropic 发生了很多事情，我很好奇你的见解。一个是大约一周前，Claude Code 的整个源代码泄露了。有人把它泄露了出去。你认为这是有人犯的错误吗？你有什么要评论的吗？比如发生了什么？出了什么问题？人们应该知道什么？

Oh my god, what an awesome advantage. Just like build a thing and then use it and then accelerate faster. It's so interesting. There's a couple like these other side things I want to just kind of go on these like side quests on this conversation. There's so much happening with Anthropic and I just I'm so curious to get your insight. One is a week ago or so the whole source code of Claude code leaked. Somebody got it out there. You think it was a mistake someone made. Is there anything you comment there? Just like what happened? What went wrong? What should people know?

所以我们一看到就立即调查了。我们意识到这是人为错误的结果。有一个人与 Claude 合作编写了一个 PR。这只是一个关于我们如何发布包的更新。它实际上经过了两次人工审核。所以这是人为错误的结果，我们已经加强了流程，确保将来不会发生这种情况。

So we immediately looked into this when we saw it. We realized that this was the result of human error. There was a human working with Claude to write a PR. This was just an update to how we release our packages. And it actually went through two layers of human review. And so this was a result of human error and we've hardened our processes to make sure that it doesn't happen in the future.

这个人还在 Anthropic 吗？他们还好吗？

Is this person still at Anthropic? Are they doing all right?

是的，是的。这是一个流程失败，最重要的是从中学习并增加更多保障措施，防止再次发生。

Yes, yes. It's a process failure and the most important thing is to just like learn from it and to add more safeguards so that doesn't happen again.

好的。我还有一个关于 OpenClaude 的问题。最近你们采取措施，阻止人们用 Claude 的订阅来使用 OpenClaude。人们非常不满，不明白为什么会这样。感觉你们对开源社区造成了伤害。人们需要理解这个决定背后的原因是什么？

Okay. Another question I had is OpenClaude. So recently there's been this move to keep people from using Claude's subscription with their OpenClaude. People got really upset. They're confused why this is happening. It feels like you're causing harm to the open source community. What do people need to understand about what went into this decision?

我们看到对 Claude 的需求很大。我们一直在努力扩展基础设施，并提高 token 效率，以便用户能获得更多使用量。但 Claude 并非为第三方产品设计，它们的使用模式与我们的第一方产品不同。我们花了很多时间研究如何提供最无缝的过渡方案。所以，我很高兴能告诉大家，每个订阅用户都会获得一些积分。但确实，我们不得不做出艰难的决定，优先考虑我们的第一方产品和 API。这就是最终的决定。

So we've been seeing a lot of demand for Claude. And we've been working very hard to both scale our infrastructure and also to make our harness more token efficient so that you can get more usage out of it. It wasn't designed for third-party products which have different usage patterns than our first-party ones. We spent a bunch of time trying to figure out what is the most seamless transition that we can offer. And so, I was very happy to be able to say that everyone gets some credits alongside their subscription. But yeah, we did have to make the hard decision that we needed to prioritize our first-party products and our API. And so, this is the decision that resulted from that.

是的，这对我来说非常合理。你们每月补贴 200 美元，基本上是无限制使用。我认为人们不明白企业是要赚钱的。我们得盈利。算力需求这么大，我们不能随便送人。所以我理解。

Yeah, this to me makes so much sense. Like you guys are subsidizing this usage at like 200 bucks a month and there's basically unlimited use of this. I think people don't understand businesses are trying to make money. We're trying to be profitable here. We can't just give away compute when it's so in demand. So, I get it.

回到 PM 团队，Anthropic 的 PM 团队是什么样的？有多少 PM？他们是如何组织的？

Coming back to the PM team, what does the PM team look like at Anthropic? How many PMs are there? How are they organized?

是的，我们有几个 PM 团队。目前大概有 30 到 40 个 PM。我们有研究 PM 团队，由 Diane 领导。这个团队负责理解客户对我们模型的所有反馈，然后将其传递给最好的研究团队去处理。他们还负责模型发布。还有 Claude 开发者平台团队，维护 Claude Code 所依赖的 API。他们还发布像托管智能体这样的功能，让你可以构建智能体，我们替你托管。然后是 Claude Code 团队，负责 Claude Code 和 Co-work 核心产品。还有企业团队，帮助所有企业客户更容易采用 Claude Code 和 Co-work。这包括成本控制、RBAC、安全控制，确保企业对我们工具有信心和舒适感。我们还有增长团队，负责整个产品套件的增长。我们与他们紧密合作，推动 Claude Code 和 Co-work 的增长。我知道他们也与其他团队合作推动 CDP 增长，即使用 Claude API 的用户增长。

Yeah, so we have a few PM teams. I think we're maybe around 30 or 40 PMs right now. We have the research PM team who Diane leads. This team is responsible for understanding all of the feedback from our customers for our models and then feeding that to the best research team to act on it. And they also shepherd the model launch. There is the Claude developer platform team that maintains the APIs that Claude Code is built on top of. And they also release things like managed agents, which is a way for you to build your agents and we can host it on your behalf. And then there's Claude Code that works on both Claude Code and the Co-work core products. There's enterprise that helps make Claude Code and Co-work easier to adopt for all of our enterprise customers. And so, this is everything from cost controls, RBAC, security controls, and just making sure that these enterprises feel very confident and comfortable using our tools. And then we also have our growth team that is responsible for growing across our entire product suite. So we work very closely with them on Claude Code and Co-work growth. And I know they also work with our other teams on CDP growth, so growth of people who use the Claude API.

说到增长，Amol 刚来过播客。他有一个很有趣的见解，大多数人没分享过。总有一种感觉，未来我们需要更少的 PM。我们为什么需要 PM？工程师就能交付。他的观点是，因为工程师行动太快，PM 和设计师被挤压了。没有足够时间掌握所有动态。每天都有新功能发布。所以他认为需要更多 PM，因为很难跟上。你怎么看？你觉得 PM 的招聘会增加吗？长期来看，PM 这个职业会怎样？

So speaking of growth, Amol was just on the podcast. He had this really interesting insight that most people haven't been sharing. There's always the sense that we need fewer PMs in the future. What do we need PMs? Engineers can ship. His take is that because engineers are moving so fast, PMs and designers are squeezed. There's less time to stay on top of everything. Every day a feature ships. So his take is he needs more PMs because it's hard to keep up. What's your take there? Do you feel like there'll be an increase in hiring of PMs? What do you think is going on with the PM profession long-term?

我认为所有角色都在融合。PM 在做一些工程工作，工程师在做 PM 工作，设计师既做 PM 也写代码。你可以招聘更多有出色产品品味的工程师，或者保持工程师招聘不变，招聘更多 PM 来指导他们的工作。在我们团队，我们专注于招聘有出色产品品味的工程师。这样我们可以减少交付任何产品的开销。比如我们团队有很多工程师，完全能够端到端地从看到 Twitter 上的用户反馈到周末发布产品，几乎不需要产品参与。我认为这实际上是最高效的交付方式。所以我认为工程和 PM 是重叠的，拥有更多其中任何一种都会带来很大好处。我认为产品品味仍然是一种非常稀缺的技能，我们会招聘任何我们认为在这方面表现出色的人。

I think all of the roles are merging. PMs are doing some engineering work. Engineers are doing PM work. Designers are PMing and also landing code. You can either hire a lot more engineers who have great product taste or you can keep your engineering hiring the same and hire a lot more PMs to help guide some of their work. On our team we're pretty focused on hiring engineers with great product taste. This way we can reduce the amount of overhead for shipping any product. Like there are many engineers on our team who are fully able to end-to-end go from see user feedback on Twitter through to ship a product at the end of the week with almost no product involvement. And this I think is actually the most efficient way to ship something. So I think engineering and PM are kind of overlapping and you will get a lot of benefit from having more of either. I think product taste is still a very rare skill to have and we'll pretty much hire anyone who we feel has demonstrated this strongly.

你的背景是工程，对吧？

And your background was in engineering, right?

是的，我做了很多年工程师。之后在加入 Anthropic 前短暂做过 VC。实际上，我们团队几乎所有 PM 要么是工程师出身，要么在 Claude Code 上写过代码。我认为这有助于建立团队信任，也让我们行动更快。而且我们的设计师以前也是前端工程师。

Yeah, I was an engineer for many years. I was then a VC very briefly before joining Anthropic. And actually almost all the PMs on our team have either been engineers or shipped code here on Claude Code. And so that's one of the things that I think helps build trust with the team and also just enables us to move a lot faster. And then actually our designers also have been front-end engineers before.

哇。因为这是个重要问题。确实在发生融合，维恩图在合并。我认为很多人的大问题是，如果你来自工程、产品或设计，哪项核心技能会最有价值？在 Anthropic 和 Claude Code，工程非常有价值。我好奇其他公司，如果有设计背景成为 PM 是否更有价值，还是仅仅作为 PM。

Wow. Because that's the big question. There's definitely this merging happening, the Venn diagrams are combining. I think the big question for a lot of people is if you're coming from engineering or product or design, which of those core skills is going to be most valuable? I could see it at Anthropic and on Claude Code, engineering is very valuable. I'm curious if other companies, if you have a design background becoming a PM is more valuable or just the PM.

我仍然认为归根结底是产品品味。随着代码编写成本越来越低，更有价值的是决定写什么。比如这个功能的正确 UX 是什么？用户最愉悦的体验方式是什么？我们收到成千上万的 GitHub 问题，要求各种功能，需要很多心思和品味来判断哪些值得构建，以及正确的构建方式。我认为这种技能可以来自任何背景，但这是最重要的。我认为工程背景特别有用的原因，至少在接下来几个月，是如果你有工程背景，你更清楚某件事的难度，这通常会影响你选择构建什么。如果某件事很容易构建，那么也许不用争论，花一个小时做就行了。但如果某件事很难构建，并且你事先知道，那么你就会知道团队需要付出更多成本才能交付。所以这对优先级排序有帮助。

I still think it comes back to product taste. As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write. Like what is the right UX for this feature? What is the most delightful way that a user can experience it? We get tens of thousands of GitHub issues asking for every single thing under the sun and it takes a lot of care and taste to figure out which of these is worth building and what is the right way to build it. I think that skill set can come from any background, but I think that's the most important thing. I think the reason why an engineering background is particularly useful, at least for the next few months, is if you have an engineering background, you have a better sense for how hard something should be and that's often a factor in what you choose to build. So if something is very easy to build, then maybe instead of debating it, you just spend an hour doing it. But if something is harder to build, and you know that up front, then you know that it will cost a lot more for our team to get this out the door. So it helps a bit with the prioritization.

你说在接下来的几个月里，是不是因为模型可能会变得非常好，你甚至不需要知道那么多？

You said in the next few months, is that just because the models will get so good potentially in the next few months, you may not even need to know that as much?

我认为技能组合的价值确实变化很快，所以很难预测几个月以后的事情。这与其说是我认为会发生什么转变，不如说是我认为会发生大的转变。

I think the value of skill sets does change quite frequently, and so it's really hard to predict more than a few months out. So, it's less a commentary on what shift I think will happen, and more of a commentary that I think large shifts will happen.

所以，你并不是说当 Mythos 发布时就会改变一切，我们不需要了解任何工程知识。

So, you're not saying that's when Mythos comes out and will change everything, and we don't need to know anything about engineering.

不，我只是说每隔几个月，编码能力似乎都会大幅提升，这进而改变了其他角色的价值。我认为最重要的是能够拥有这种第一性原理思维，你可以弄清楚技术格局如何变化，团队真正需要你做什么，然后跳进去填补那个空缺，因为我认为工作正变得更加模糊，这意味着一个优秀的产品经理能够理解所有的差距，找出最高优先级的那些，然后弄清楚，好吧，我如何学习那套技能，或者我有什么技能可以应用于这个挑战。所以，我认为当前的环境重视那些能够身兼多职、能够切换角色、并且对所做工作非常谦逊以帮助团队更快前进的人。

No, I'm just saying that every few months it seems like there's a large increase in coding capability, which then changes what other roles are valuable. I think the most important thing is to be able to have this first principles thinking, where you can figure out how the tech landscape is changing, what the team really needs from you, and to jump in and fix that hole, because I think the work is becoming more amorphous, which means that a great PM is able to understand what all the gaps are, to figure out what the highest priority ones are, and then to figure out, okay, how do I learn that skill set, or what is the skill set that I have that I can apply to this challenge. So, I think the current environment values people who are able to wear a lot of hats, are able to swap them, and are very low ego about what work they do to help the team move faster.

我喜欢这个回答。我一直在问和你处境相似的人，那些处于 AI 能力前沿并用最新工具构建的人，就是人类大脑在超级智能到来之前，还会在哪些方面继续有用和必要。我在这里听到的，本质上是选择要做的事情，了解市场走向，确定优先事项，然后知道你所构建的东西是否良好正确，并至少以早期版本发布出去。这听起来对吗？还有没有其他方面，人类大脑至少在未来几个月内还会继续有用？

I love this answer. There's this question I've been asking people in your shoes, folks that are at the bleeding edge of what AI is capable of and building with the latest tools, which is just like where will human brains continue to be useful and necessary for a while until we get to superintelligence. What I'm hearing here is essentially picking the things to work on, knowing where the market's going and figuring out what to prioritize, and then it's knowing if the thing you've built is good and right and getting it out there in some early version at least. Does that sound right? Is there anything else of just like where human brains will continue to be useful for at least the next few months?

我认为人类仍然提供了一定程度的常识，而模型不具备。任何产品发布都有成千上万个移动部件。有些非常小，但总有很多可能出错的地方。我认为模型并不总能很好地理解所有利益相关者是谁，他们之间的关系如何，他们的偏好是什么，以及用什么合适的渠道与他们沟通以保持他们的支持。我认为很多这种更隐性的常识，比如情商类的知识，仍然非常有价值。当然，我们希望模型在这方面变得更好，而且我认为它们会的。但就目前而言，我认为仍有差距。

I think humans still provide a level of common sense that the models don't. And there's like a thousand moving pieces to any product launch. Some of them are very small, but there's always a lot that could potentially go wrong. I think the model doesn't always have a great sense of who all the stakeholders are, how they relate to each other, what their preferences are, what are the right venues to communicate with them to keep them on board. I think a lot of this more tacit common sense like EQ kind of knowledge is still very valuable. Of course, we want the models to get better at this and I think they will be. But right now, I think there's still gaps.

作为一个人，经历这么多持续的变化，就像身处龙卷风内部，你是如何应对的？也许那里很平静。但你是如何掌握最新情况的？在经历这一切疯狂时，你是如何保持理智的？

How do you just kind of deal as a human going through this so much constant change just like being on the inside of the tornado? Maybe it's calm there. But just like how do you stay on top of what's going on? How do you stay sane through all this craziness that we're moving through?

我认为我们的团队里都是乐于拥抱混乱的人。所以，我们努力微笑着面对每一个挑战，因为总有那么多事情发生。总有那么多风险和棘手的情况，你知道，如果你对任何事情都过于紧张，你会精疲力竭。所以，我们真正寻找的是那些能够看着一个挑战，说：‘哦，这很难，但我很兴奋去解决它，我会尽我所能，我知道我不会完美，但我知道我尽了最大努力，就能安然入睡。’

I think our team is full of people who lean into the chaos. So, we try to face every challenge with a smile because there's always so much going on. There's always so many risks and tricky situations that, you know, if you get too stressed about anything, you'll burn out. And so, we really look for people who can kind of look at a challenge, be like, 'Oof, that's going to be hard, but I'm excited to tackle it, and I'm going to do the best that I possibly can, and I know I won't be perfect, but I'll be able to sleep at night knowing that I did my best.'

这是一个有趣的回答，关于未来哪些技能会很重要，因为——我忘了是谁说的，也许是 Ben Man——这是世界最正常的时候了。

That's an interesting answer to just like what skills will be important in this future cuz it's I forget who said this, maybe Ben Man, that this is the most normal this is the world will ever be.

是的，它确实变得更难了。我觉得有很多周，也许周日晚上有个 P0，然后到了周一又有个 P00，到了周一下午又有个 P000，你会想：‘哇，我真不敢相信我周日还为那个 P0 那么担心。’但我认为你只需要承认，你能做的只有这么多，你需要睡好觉，这样第二天才能做出好的决定，然后残酷地优先安排你的时间，什么是最重要的事情，并且要能接受放手。比如，我们发布的一些产品并不像我期望的那么完善，但你知道，我们的首要目标是帮助赋能专业开发者，如果一个产品不成功，只要它不阻塞核心用例，就没问题，因为我们会收到反馈，并在下一个版本中修复。发布一个有 bug 的功能以前会让我夜不能寐，但现在我能接受，因为我知道，好吧，我们会很快得到反馈，并在下一个版本中修复它。

Yeah, it definitely gets harder. Like I feel like there are a lot of weeks where maybe Sunday night there's some P0, and then by Monday there's like a P00, and by Monday afternoon there's a P000, and you're like, 'Wow, I can't believe I was so worried about that P0 from Sunday.' But I think you just have to acknowledge that there's only so much that you can do, that you need to sleep well so that you can make good decisions next day, and just like brutally prioritize where you spend your time, what's the most important thing to get right, and be okay letting things go. Like there's products that we ship that aren't as polished as I wish they were, but you know, our top goal is to help empower professional developers, and if a product isn't successful, as long as it's not blocking the core use case, it's okay, because we'll hear the feedback and we'll fix it in the next release. Launching a feature that is buggy is the kind of thing that would have kept me up at night, but it is something that I'm now able to live with knowing that okay, we're going to get that quick feedback, and we're going to fix it in the next release.

我想象的是那个动图，我想可能来自《加勒比海盗》，一个人走下船上的楼梯，整艘船在他周围被摧毁，他却非常淡定，悠然自得地走下楼梯，一切都在崩塌。这很有趣，因为我遇到的每个来自 Anthropic 的人都非常淡定，非常乐观。

What I'm imagining is there's that gif, I think it's maybe from Pirates of the Caribbean, where it's this guy walking down a pair of stairs on a ship, and the whole ship is just being demolished around him, and he's so chill, just strolling down the staircase as everything's falling apart. And that's interesting cuz everyone I've met from Anthropic is just so chill, and just so like optimistic.

是的，我认为这是一个非常有趣的见解，就是拥有这种冷静和乐观，而不是‘哦，我的天，一切都疯了，要失控了。’

Yeah, that's I think that's a really interesting insight is just like having this calmness and optimism versus just like, 'Oh my god, everything's crazy and going nuts.'

是的。我认为如果你没有这种心态，你会很容易精疲力竭。我认为我们也倾向于雇佣那些在行业里待了一段时间、经历过很多起起落落、并且很清楚什么能给他们能量以及如何长期保持能量的人。我认为这对我们帮助很大。

Yeah. I think if you don't have it, you'll get pretty burnt out. I think we also tend to hire people who have been in the industry for a while and have experienced lots of ups and downs and have a good sense for what gives them energy and how to maintain their energy over time. And I think that helps us a lot.

太有趣了。我想问的是，这些角色正在模糊。工程师变成了产品经理。每个人都是多面手，每个人都是所有人。在那个世界里，我们失去了什么？我们失去了职业阶梯和清晰的职业道路吗？我们失去了设计一致性、代码质量吗？你知道，可能有一些缺点。你发现有哪些事情是‘好吧，这是我们为了更大的利益而牺牲的。’

So interesting. Something that I wanted to ask about is so there's these roles blurring. Engineers are becoming PMs. Everyone's cats, everyone's everyone. What do we lose in that world? Do we lose like career ladders and clear career paths? Do we lose design consistency, code quality? You know, there's probably some downsides. What are some things you find are just like, 'Okay, that's something we're sacrificing for the greater good.'

我们牺牲了产品一致性。历史上，当代码编写成本很高时，你会仔细规划你的整个产品套件，每个产品如何相互关联，每个产品的用例是什么，它们如何集成，并且你基本上会为每个用例提供一个产品。

We're sacrificing product consistency. Historically when code was expensive to write, you would carefully plan out everything your product suite, how every product relates to each other, what the use case for every one is, how they integrate, and you would pretty much have one product for each use case.

现在 AI 发展如此之快，有太多想法需要测试，我们有时确实会有功能重叠的情况。很多时候是因为我们内部喜欢两种形态，想让外部用户告诉我们哪个更好。但对新用户来说，他们可能不知道‘完成 X 的最佳路径是什么’。我们需要做更多教育，帮助人们理解核心功能以及使用它们的最佳实践。我认为这是推出大量功能的代价。用户也会觉得很难跟上最新动态。在传统的产品管理中，你每个月或每个季度发布一个功能，用户很容易理解‘我只需要每月查看一次，就能学到新东西。如果忽略六个月也没关系，不会觉得错过什么。’但有了这些智能体工具，不仅是 Claude Code 和 Cursor，整个生态系统都是如此，人们觉得需要每天刷 Twitter 看最新动态。我认为我们可以做得更多，让人们不再感觉像在越来越快的跑步机上，而是希望他们能直接打开这些工具，工具会教育他们，教他们想知道的东西，让他们感觉更轻松。

And now with AI moving so quickly and with so many ideas that we need to test out, we do sometimes have features that overlap with each other. A lot of times it's because there are two form factors that we love internally and we want the external audience to tell us which one is better. What that means for someone who's a new user though is a new user might not know, 'Okay, what is the best path to accomplish X?' There is more education we need to do to help people understand what the core features are and what the best practices are for using them. I think this is the cost of launching a lot of features. I think users also feel like it's hard to keep up with the latest. Usually in traditional PM, you ship a feature every month or quarter, and so it's really easy for a user to understand, 'Okay, I just need to check in on this once a month, and I'll learn some new things. And if I ignore it for 6 months, it's fine. I don't feel like I'm missing out.' I think with these agentic tools, not just Claude Code and Cursor, but across the whole ecosystem, people feel this need to check Twitter every single day to see what the absolute latest thing is. And I think there's more we can do to help people feel less like they're on this ever-increasingly fast treadmill, and that they can just open these tools, the tools will educate them, or teach them what they want to know, and that they can just feel more ball along.

是的，我看到你们前几天推出了一项非常有趣的功能。我想是/powerup，它基本上带你了解所有使用 Claude Code 的最佳实践。这算是沿着这个思路吗？

Yeah, I saw you launch this really interesting feature the other day. I think it's /powerup, where it basically walks you through all the cool ways to all basically all the best practices to use Claude Code. Is that kind of along these lines?

是的，没错。过去我们其实不想做像 powerup 这样的东西，因为我们觉得产品应该足够直观，不需要任何教程。但随着时间的推移，我们意识到功能太多了，对内置入门体验的需求很大，所以我们稍微偏离了最初‘不做入门流程’的原则，增加了这个功能。因为有太多用户想知道‘有 100 个功能，哪 10 个是我必须用的？’所以我们把它整合了起来。

Yeah, exactly. So, in the past, we didn't actually want to do something like powerup, because we felt like the product should be intuitive enough that you don't actually need to go through any tutorial. And over time, we've just realized that there's just so many features, and there's so much demand for a built-in onboarding experience, that we diverged a bit from our original principle saying, 'No onboarding flow.' And added this because there's just so many users who wanted to know, 'There's 100 features, what are the 10 that I absolutely need to use?' And so we put that together.

是的，这真是个奇怪的世界。Anthropic 在 B2B 和企业领域非常成功，传统上你不会发布一大堆东西，可能只是每季度发布一次，这与每天都有新东西相反。顺着这个思路，Anthropic 的崛起简直超凡脱俗。Anthropic 起步时远远落后，是资金最少的公司之一，没有分销渠道，也不是第一个进入市场的。OpenAI 遥遥领先，看起来 Anthropic 根本没有机会长期竞争。但现在它表现惊人，击败了最大的公司团队，增长如此之快，一个月内 ARR 达到 110 亿美元。到节目播出时可能更高。作为内部人士，是什么因素让 Anthropic 如此成功，能够后来居上？

Yeah, it's such a bizarre world. So, Anthropic has been really successful with B2B and enterprises, where traditionally you don't launch a bunch of stuff. You just kind of have quarterly release maybe, and it's like the opposite of every day we got some new. So, just maybe following that thread, the run Anthropic has been on is just other worldly. Anthropic was way behind when it started. It was a mole shared this just like one of the least funded companies didn't have distribution wasn't the first to go. OpenAI was way ahead. It was just like no way Anthropic has any chance to compete significantly long term. Now it's just killing it just beating the biggest companies teams with so much just like the growth is just like 11 billion dollars in ARR in one month. Drips and growth. By the time this comes out it'll probably be even higher. Just being on the inside what are some ingredients that have allowed Anthropic to be this successful and kind of come from behind and do this well?

最重要的两件事是：第一，统一的使命。很难说这有多重要。我们招聘最关心将安全 AGI 带给全人类的人。这实际上是我们经常参考的东西，用来决定整个产品组织应该专注于发布什么。因为我们把这一使命置于任何单个产品线之上，所以能够做出非常快速的决策，跨越整个组织，并以统一的方式执行。我认为这是我在我们这种规模的公司从未见过的。

The two most important things are one this unifying mission. It's hard to state how important this is. We hire people who care most about bringing safe AGI to all of humanity. And this is actually something that we reference frequently in our decisions about what our entire product org should focus on shipping. And because we put this mission above any individual product line, we're able to make very fast decisions that cut across the entire org and execute on them in a unified way. So I think this is something I've never seen at a company of our scale.

所以为了确保清楚。基本上，首要使命是安全对齐，确保 AI 对世界有益，你是说拥有这样一个清晰的使命让决策变得容易得多。

And so just to make sure that's clear. So essentially having the number one mission is safety alignment making sure AI is good for the world and you're saying just having that as a clear mission makes decisions a lot easier to make.

如果有两个相互竞争的优先级，我们会讨论哪一个对 Anthropic 的使命更重要。这让我们更容易决定优先考虑哪一个，然后每个人都会支持我们做出的决定。所以有时这意味着我们想在 Claude Code 上发布某个功能，但另一件事更重要，于是我们降低这个功能的优先级，等到以后再发布。

If there are two competing priorities, we'll talk about which one is more important for Anthropic's mission. And it makes it a lot easier to decide which of the two we prioritize and then everyone will stand behind the one that we decide. And so sometimes that means that hey we want to ship something on Claude Code, but this other thing is more important, and so we deprioritize shipping this, and we just wait until later.

这很有趣，我认为这解释了与另一家公司（可能和 OpenAI 押韵）相比，他们做了很多不同的事情。我在这里听到的实质上是：‘好吧，我们不会推出社交网络。我们不会推出有趣的信息流，因为这不符合这个使命。’这让 Anthropic 保持专注，这似乎是成功的核心要素。

What's really interesting about that is that explains, I think, versus another company, maybe rhymes with OpenAI, did a lot of different things. And what I'm hearing here essentially is like, 'Okay, we're not going to launch social network. We're not going to launch a feed of interesting information because it's not aligned to this mission.' And that has kept Anthropic focused, which seems to be a core ingredient to the success.

嗯，当我想到使命时，我想到的是将 Anthropic 的目标置于任何单个组织或单个产品之上。所以，对我来说，我认为我们非常擅长的第二件事是专注。我认为使命对我来说略有不同。使命意味着团队愿意做出牺牲，损害自己的目标和关键结果，以服务于 Anthropic 的目标和关键结果。人们非常乐意做出这些权衡。所以，一个极端的例子是，如果 Claude Code 失败了，但 Anthropic 成功了，我会非常高兴。整个团队都非常愿意做出遵循这种思维链的决策。

Well, when I think about mission, I think about putting Anthropic's goals ahead of any individual org or any individual product. And so, for me, I think the second thing that we're very good at is focus. I think mission to me is slightly different. Mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs. And people are very happy to make those trade-offs. So, like an extreme example is if Claude Code failed, but Anthropic succeeded, I would be extremely happy. And like, we're like, the whole team is very willing to make decisions that follow that chain of thought.

我不知道你是否能深入谈谈，但你觉得开放 Claude 的决定是其中的一部分吗？就像‘好吧，这没有推进 Anthropic 的使命。我们需要停止，因为它没有按照我们想要的方式运作。’

I don't know if you can talk about this in depth, but do you feel like the open Claude decision is a part of this? Just like, 'Okay, this is not furthering the mission of Anthropic. We need to stop this because it's not working in the way we want it to work.'

我认为对 Anthropic 来说，最重要的事情之一是增加我们能够触及的用户数量。实现这一目标的方法之一是通过 Claude 订阅和我们的第一方产品。所以，我们非常想在这方面加倍努力。但这有时会以牺牲第三方产品为代价。

I think one of the most important things for Anthropic is to grow the number of users that we're able to reach. One of the ways that we're able to do this is with the Claude subscriptions with our first-party products. And so, we just very much want to double down on that. But that does come at the expense of third-party products sometimes.

所以，我们一直在谈论 Claude、Cursor 等等。我想确保人们理解，而且我很好奇你如何使用这些工具。有 Claude Code、Claude 桌面版/网页版、Cursor。理解何时使用哪个的最佳方式是什么？你什么时候使用这三个中的每一个？

So, we've been talking about Claude, Cursor, all these things. Something that I want to make sure people get, and I'm curious just how you use these tools. So, there's Claude Code, there's Claude Desktop/Web, there's Cursor. What's the best way to understand when to use which? When do you use each of these three?

所以，我倾向于在终端中使用 Claude Code，当我只是启动一个一次性的编码任务，并且想要所有最新功能时。

So, I tend to use Claude Code in the terminal when I'm just kicking off like a one-off coding task, and I want all of the latest features.

CLI 是我们最初的产品界面，也是功能最先落地的界面。所以它是所有工具中最强大的。当我只想一次性启动一两个测试时，我通常会用它。我认为桌面版在需要前端工作时表现最佳。我喜欢做的一件事就是使用预览功能。如果我在构建一个网页应用，我经常在桌面版上使用 Claude Code。我会在右侧打开预览面板，这样在与 Claude 聊天时就能实时看到我正在制作的网页应用。对于想要更图形化界面的人来说，这也非常棒。终端对非技术用户来说可能非常陌生。你的机器上会出现一堆吓人的弹窗，而且你不能像使用其他产品那样点击操作。所以很多人对终端感到不自在。如果你是这样，我强烈推荐试试桌面版的 Claude Code。桌面版还非常适合一目了然地查看所有正在发生的事情。你可以在桌面版上看到你的 CLI 终端会话、其他桌面会话，以及你在网页和移动端启动的会话。它是一个一站式控制面板，可以查看所有任务。我认为网页和移动端的优势在于非常适合在外出时启动任务。CLI 和桌面版都需要你在本地笔记本电脑上操作。这有限制，因为有时你外出散步、接触自然，没有打开笔记本电脑。我见过无数人在外面像拴着手机一样打开笔记本电脑。这意味着我们缺少一个满足这种需求的产品。对我来说，移动端让你可以在外出时启动这些任务，这样你就不必随身携带笔记本电脑，也不必确保笔记本电脑在任何地方都打开。

Uh the CLI is our initial product surface, and it's also the one where our features often land first. And so, it's the most powerful of all the tools. So, that's what I tend to use when I'm just trying to kick off one or maybe a handful of tests at a time. I think desktop really shines when you're doing something that requires front-end work. And so, one thing that I love to do is to use our preview feature. So, if I'm building a web app, I'll often use Claude Code in desktop. I'll have the preview pane open on the right-hand side, so that I can actually see the web app that I'm making in real time as I'm chatting with Claude. It's also really great for people who want something a bit more graphical. A terminal can feel very unfamiliar to someone who's non-technical. You got a bunch of scary pop-ups on your machine, and you can't click around the way that you're used to in pretty much every other product that you use. So, there's a lot of people who just don't feel comfortable in terminal. And if that's you, I would highly recommend checking out Claude Code on desktop. Desktop is also great for getting an at-a-glance view of everything that's happening. So, you can see your CLI terminal sessions in desktop. You can see your other desktop sessions. You can see your sessions that you kicked off on web and mobile. So, it's a one-stop control plane where you can see all of your tasks. I think the benefit of web and mobile is that it's really great for kicking things off on the go. So, CLI and desktop both require you to be on your local laptop. And this is constraining because sometimes you're out and about, you're touching grass, you're going on a walk. And you don't have your laptop open, and I can't count the number of people who I've seen holding their laptop open like tethered to their phone while they're outside. And this just means that we're missing a product that solves that need. And so, for me, what mobile lets you do is kick off these tasks on the go so that you don't need to bring your laptop everywhere and make sure that your laptop's open wherever you are.

我喜欢这个。我在飞机上看到过人们，这现在简直成了一个梗。就是‘我需要完成。让这个智能体完成。我不能关掉它。我需要 Wi-Fi。’

I love that. I've seen people on plane like it's just such a meme now. Just I need to finish. Let this agent finish. I can't shut this down. I need Wi-Fi.

然后我认为对于 co-work 来说，它填补的角色是每个人都会做很多输出不是代码的工作。无论是处理 Slack 未读消息或收件箱归零，还是为即将到来的客户会议制作幻灯片，或是快速撰写关于功能目标或发布计划的文档。所有这些任务的产出都不是代码，而 co-work 最适合处理这些。所以我在心里划分产品的方式是：如果我在构建输出是代码的东西，我会使用 Claude Code、桌面版或移动端的 Claude Code。如果输出不是代码，我就会用 co-work。

And then I think for co-work, the role that this fills is there's a lot of work that everyone does where the output isn't code. So, whether that's getting to Slack zero or inbox zero, or whether that's creating a slide deck for some customer meeting that's coming up, or whether that's writing a quick doc on what the goals of a feature or what the launch plan for a feature is. All these tasks produce outputs that are non-code, and co-work is best positioned for that. So, the way that I split the products in my mind is if I'm building something where the output is code, I'll use Claude Code or desktop or Claude Code on mobile. And if the output is anything that's not code, I'll use co-work for it.

人们似乎忽视了 co-work 的成功。它增长得非常快。我想人们可能仍然不明白它的用途。那么，作为 PM，你能给我们举几个你在工作中使用 co-work 的例子吗？有哪些非常有趣、可能出乎意料的方式，让你用 co-work 节省时间、完成更多工作？

People are just sleeping on the success that co-work is having. It's just growing incredibly fast. And I think people still don't understand maybe what it's for. And so, what if you give us a couple of use cases just in your work as a PM? What are some really interesting, maybe unexpected, ways you use co-work to save you time, get more work done?

如果你刚开始使用 co-work，第一件要做的事就是连接所有与你角色相关的数据源。因为 co-work 只有访问到所需的所有上下文，才能为你策划出好的输出。对我来说，这意味着我把它连接到我的 Google 日历、Slack、Gmail 和 Google Drive，这样它就能灵活地找到相关上下文、提问、拉取线程。这大大提高了结果的质量。我使用它的例子是：昨晚我在准备即将到来的 Code with Claude 大会，我要在那里做几个演讲。其中一个演讲是关于 Claude Code 从助手到完整智能体的转变。我想在演讲中展示我们发布的所有支持这一转变的产品，并找出内部有哪些成功案例可以用作演示。我连接了 Google Drive 和 Slack。我们的产品营销人员 Alex 整理了一份他认为应该涵盖的要点草稿。我就把这些都输入到 Cohere 中，告诉它我想讲述的叙事。它实际上工作了一个小时。它浏览了 Twitter 看我们发布了什么，查看了我们的常青发布室，查看了我们的 Claude Code 公告频道——那是我们团队发布如何从 Claude Code 中获得最大价值的演示的地方。它把所有内容综合起来，生成了一份 20 页的幻灯片，我今天早上醒来就看到了。我通读了一遍，觉得相当不错。有一些需要调整的地方，所以我给了它一轮反馈。我喜欢幻灯片文字极少，但它有点过于冗长。但你知道，这比我能够制作的速度快得多。而且因为 Cohere 可以访问我们的整个设计系统，它看起来就像是由 Anthropic 的设计师制作的。当你看到它时，你会觉得‘哦，这非常精致’。所以这类事情快得多。制作这份幻灯片本来需要我几个小时。但相反，它生成了一个相当不错的草稿，这样我就可以专注于确保我们嵌入的演示非常出色。

If you're getting started on co-work, the first thing that you really need to do is connect all the data sources that are relevant to your role. Because co-work can only do a great job if it has access to all the context that it needs to be able to curate the output for you. So, what that means for me is I connect it to my Google Calendar, I connected to my Slack, to my Gmail, to my Google Drive, so that it just knows it has the flexibility to find relevant context, to ask questions, to pull in threads. And this substantially improves the quality of the result. The kinds of things I use it for are like last night I was working where we have this Code with Claude conference coming up and there's a few talks that I'm giving there. And one of the talks that we're doing talks about the transition of Claude Code from an assistant to like a full-on agent. And one of the things that I wanted to do in this talk was to showcase all of the products that we've been shipping that enable this transition and also to figure out, okay, what are the success stories that people have had internally that we can use as demos. And so I have my Google Drive connected, I have Slack connected. Alex, who is our product marketer, put together like a draft of what the points that he thinks we should cover are. And so I just fed this all into Cohere, I told Cohere the narrative that I want to tell. And it actually just worked for an hour. It walked through Twitter to see what we launched, it looked through our evergreen launch room, it looked in our Claude Code announce channel, which is where our team posts demos of how they've been getting the most value out of Claude Code. And it synthesized all this together to this 20-page deck that I woke up to this morning. And I read through it and it was like pretty good. There were a few tweaks, so I did have to give it a round of feedback. I like my slides to have extremely minimal words and it was a little too wordy. But, you know, it was far faster than what I would be able to produce. And because Cohere has access to our whole design system, it actually looks like an Anthropic designer put it together. Like when you visually see it, you're like, 'Oh, this is incredibly polished.' So, these are the kinds of things that are so much faster. Like making this slide deck would have taken me hours. But instead, it turns out a draft that is actually quite good, so I can focus on making sure that the demos are amazing that we plug into it.

这对 PM 来说简直是梦想成真，做幻灯片太烦人了。

This sounds like a dream come true to PMs that putting decks together is so annoying.

太慢了。

It's so slow.

我喜欢人们会在你展示时看到这份幻灯片。它将会面世。显然它不是一次成型的版本，但你迭代了它。那么，为了帮助人们自己尝试，第一步是连接他们的……你说了什么？Slack？你还建议他们连接什么？

I love people will see this deck whenever you present this. This will be out in the world. Obviously it's not the one-shotted version, but you've iterated on it. So, just to help people try this for themselves. So, step one is connect their... What did you say? Slack? What else do you suggest they connect?

Slack、Google 日历、Gmail、Google Drive。你应该连接你的通讯工具以及存储团队关心、你关心以及你正在做的事情的真实数据源的地方。

Slack, Google Calendar, Gmail, G Drive. You should connect your communications tools and where you store your source of truth data for what your team cares about, what you care about, and what you're working on.

好的。那么你大概输入了什么提示来生成这份幻灯片？

Okay. And then what was the prompt roughly that you put in there to generate this deck?

所以我只是写了：‘为 Code with Claude 大会制作一份幻灯片。这是我们 PMM 建议涵盖的内容。’

So, I just wrote, 'Make me a slide deck for the Code with Claude conference. This is what our PMM suggested it should cover.'

这是我目前做的草稿，我不太满意。这是我手动做的一个，我不喜欢，但我把它链接上了。你能先创建一个带有细节的提议大纲吗？另外，确保它不要与更重要的主题演讲重叠太多。然后 Claude 读取了我发送给它的一堆链接，并创建了一个提议大纲。于是，我阅读了它的提案以及我生成的所有不同想法，然后决定最终演示文稿中实际要包含的内容。我认为这仍然是今天 PM 角色的一个例子。Claude 是一个很好的头脑风暴伙伴，它能快速综合大量信息，向你展示所有可能性，但 PM 的角色仍然是做出最终决定：哪些内容应该属于最终产品？所以对于这个，我最终决定演讲要涵盖从让本地任务成功到让每个 PR 变绿，再到帮助工程师落地更多 PR 的进展。对于每一步，哪个演示最引人入胜。在确定大纲后，Claude 就花了几个小时构建了整个幻灯片。

This is the current draft that I made that I don't like. This is one that I made manually that I don't like, but I linked it. Can you start by creating a proposed outline with details? Also, make sure it doesn't overlap too much with the keynote talk, which is more important. And then Claude read a bunch of the links that I sent to it and created a proposed outline. So, then I read through its proposal and all the different ideas that I had generated for what we could cover and I just made a decision on what I wanted to actually be in the final deck. And I think this is like an example of what the role of the PM still is today. It's like Claude is a great brainstorming partner. It's able to synthesize a massive amount of information really quickly and present all of the possibilities to you, but the role of the PM is still to make the end decision of okay, what should belong in the final product? And so for this, what I ended up deciding was that I wanted the talk to cover the progression from making local tasks successful to making every PR green to like helping engineers land more PRs. And for each of these, which demo would be the most compelling. And then after this decision about the outline, Claude just went off for a few hours and built the whole slide deck.

这太棒了。工作中再也不用做这部分了，真是太好了。感觉你就像在和一个演示文稿设计师交谈，这个设计师不仅了解你做过什么，还能让内容符合你的要求，而不仅仅是让它看起来漂亮。你是怎么做设计系统部分的？它是怎么工作的？它怎么知道 Anthropic 的设计系统？

This is so awesome. What a great part of the job to not have to do anymore. And it feels like you're talking to essentially a deck designer that also has actual knowledge about what you've worked on and can make the content what you want it to be, not just make it look really nice. How did you do the design system piece? How does that work? How does it know the design system of Anthropic?

所以，我为此做的是，我们实际上已经有一个标准化的演示文稿，用于所有外部活动。我让 Claude 访问了那个。这样它就能看到我们使用的颜色、字体，以及各种可能的幻灯片格式。它大概有 20 个这样的示例幻灯片……

So, what I did for this is we actually already have like a standardized deck that we use across all of our external engagements. And so I just gave Claude access to that. And so it's able to see like what colors we use, what fonts we use, the different kinds of slide formats that are possible. And so it has like 20 of these example slides that...

一个例子，明白了。所以你上传了“这是我们的模板”，然后基于此工作。是的。

An example, got it. So you upload 'here's our template', work from this. Yeah.

如果你把幻灯片格式保存在 Figma MCP 里，你也可以连接它，然后它就能拉取那些内容。

You can also connect your Figma MCP if you have your slide format saved there and it can pull that in.

顺着这个思路，我一直好奇的是，作为 Anthropic 的 PM，你的工具栈里都有什么？显然有 Claude Code、Cogram 和所有 Anthropic 的工具。你还用别的吗？你提到了 Slack？还有其他吗？

Along those lines, something I'm always curious about is what's in your stack of tools as a PM at Anthropic? Obviously Claude Code and Cogram and all the Anthropic tools. What else are you using? What other Slack you mentioned? Is there anything else?

所以，我的工具栈主要是 Claude Code、Cogram 和 Slack。Anthropic 很大程度上运行在 Slack 上。我觉得它就像我们公司的核心操作系统。日常工作中，我大概 30%的时间在探索 Cogram 和 Cogram Code 的边界，以便清楚了解我们不擅长什么。我花很多时间与模型对话，理解它为什么会犯那些错误。我们实际上做了很多内部工具。我认为 Cogram Code 为整个公司解锁的一件事是，它真正降低了制作任何自定义应用的门槛。所以我们看到人们为定制用例构建的固化工作软件激增，而不是使用不完全适合用例的工具。

So, my stack is pretty heavily Claude Code, Cogram, and Slack. Anthropic largely runs on Slack. I feel like it's the core OS of our company. And day-to-day, a lot of—I would say maybe 30% of my time is pushing the boundaries of what Cogram and Cogram Code can do so that I have a very strong sense of what we're not good at. And I spend a lot of time talking with the model to understand why it makes mistakes that it does. We actually have a lot of internal tools that we make. Like I think one of the things that Cogram Code has really unlocked for our entire company is it really lowers the barrier to making any custom app that you want. And so we've seen this surge in crystallized work software that people are building for custom use cases instead of using tools that don't perfectly fit the use case.

我想多听听。有哪些例子？你或其他人构建的哪些东西非常受欢迎且有用？

I got to hear more. What are some examples? What are things you built, other people built that are really popular and useful?

有一个销售同事在用 Cogram Code，他意识到自己反复制作重复的演示文稿。于是他构建了一个 Web 应用，里面包含了我们知道效果很好的核心 Cogram Code 演示文稿示例，比如 101、201 和精通 Cogram Code。然后他有一种方法输入特定的客户背景，这些信息从 Salesforce、Gong 和其他笔记中提取。这样我们就可以为特定客户定制演示文稿。我们会提取出诸如“这个客户正在使用 Bedrock 或 Cogram for Enterprise 或 Console”之类的信息，这会影响他们可用的功能。它会提取出诸如“这个客户关注 SDLC 的代码审查阶段”之类的信息，然后我们会在那里添加一张关于我们代码审查功能的幻灯片。它会提取出诸如“这个客户需要符合 HIPAA 或需要 XYZ 安全控制”之类的信息，然后我们会确保在他们的演示文稿中添加一两张关于这个的幻灯片。然后，例如，如果这个客户使用 Vertex 或 Bedrock，并且不想使用 Claude for Enterprise，那么我们就移除一些仅限 Claude for Enterprise 功能的幻灯片。通常这是手动工作，可能需要 20-30 分钟。人们要么花时间做，要么决定不做而使用通用演示文稿。有了这个，只需要几秒钟，你就能得到一个定制的演示文稿。

One of the sales folks on Cogram Code, he realized he was making these repetitive decks over and over again. And so he actually has this web app that he built with the examples of the core Cogram Code decks that we know work well. So like a 101, 201, and Mastering Cogram Code. And then he has a way to input specific customer context that pulls from Salesforce, that pulls from Gong, that pulls from other notes. So that we can customize the decks for specific customers. And so we'll pull out things like, 'Okay, this customer is using Bedrock or Cogram for Enterprise or Console.' Which affects what features are available to them. It will pull out things like, 'Okay, this customer is concerned about the code review stage of the SDLC.' And so we'll add a slide about our code review features there. It will pull out things like, 'Okay, this customer needs to be HIPAA compliant or needs XYZ security controls, and so we'll make sure to add a slide or two in their deck about that. And then, for example, if this is a customer that's on Vertex or Bedrock and doesn't want to use Claude for Enterprise, then we'll just take out some of the slides that are Claude for Enterprise only features. And so, normally this is manual work that could take 20-30 minutes. Or people will either spend that time doing it or they'll just decide not to do it and use the general deck. With this, it takes like a few seconds and you get a tailored deck.

有趣的是，Slack 是一个没人试图自己创建的工具。Slack 一直在赢，就像你描述的那样，它是很多公司的操作系统。这很有趣。就像人们谈论 Salesforce 只是 SaaS 一样。我们不再需要 SaaS 软件了。我们要自己构建。而 Slack 是一个可爱的工具，没人想和它竞争并构建更好的版本。

What's interesting about it is like Slack is the tool that nobody's trying to create their own. Slack just continues to win and it's just like the way you describe it is kind of the OS of so many companies. It's so interesting. Like people talk about Salesforce as just SaaS. We don't need SaaS software anymore. We're going to build our own. It's like Slack is an adorable tool that nobody wants to try to compete with and build a better version.

我认为它是非常重要的通信基础设施，他们在帮助每个人获得实时更新这一核心任务上做得非常好。

I think it's pretty important communications infrastructure and I think they do the core task of helping everyone get real-time updates incredibly well.

是的，人们讨厌 Slack，但它在它想做的事情上真的很棒。大多数前沿团队都离不开它。真有趣。

Yeah, like people hate on Slack, but it's really great at what it's trying to do. And like most cutting-edge teams are hooked on it. So interesting.

是的，我也很喜欢他们让定制变得如此简单。所以我们喜欢制作 Slack 机器人，这种可破解性意味着我们可以按照自己想要的方式与 Slack 集成。所以，非常感谢 Slack 在这方面的努力。

Yeah, and I also love how easy they've made it to customize it. And so we love making Slack bots and this kind of hackability means that we're able to integrate with Slack the way that we want to. So, really appreciate Slack's work on that.

是时候买一些 CRM 股票了。我非常兴奋地告诉你本季度的支持赞助商 Vanta。Vanta 帮助超过 15,000 家公司，如 Cursor、Ramp、Duolingo、Snowflake 和 Atlassian，赢得并证明客户的信任。由于 AI，团队比以往任何时候都更快地构建和发布产品。但结果是，引入产品和业务的风险比以往任何时候都高。我交谈过的每一位安全负责人都感受到保护组织、业务以及客户数据的压力越来越大。因为事情发展得太快，他们不断被动应对，不得不猜测优先级，并凑合使用过时的解决方案。

Time to buy some CRM stock. I am so excited to tell you about this season's supporting sponsor, Vanta. Vanta helps over 15,000 companies, like Cursor, Ramp, Duolingo, Snowflake, and Atlassian earn and prove trust with their customers. Teams are building and shipping products faster than ever thanks to AI. But as a result, the amount of risk being introduced into your product and your business is higher than it's ever been. Every security leader that I talked to is feeling the increasing weight of protecting their organization, their business, and not to mention their customer data. Because things are moving so fast, they are constantly reacting, having to guess at priorities, and having to make do with outdated solutions.

你谈到了所有这些不同的团队以及他们如何使用 Claude Code 和 Co-work 来运作。除了工程团队——我猜工程团队是最大的 token 消耗者，但如果不是，那会很有趣——目前 token 消耗量第二大的职能是什么？

You talked about all these different teams and how they use Claude Code and Co-work to operate. Which teams do you find, other than engineering—I imagine engineering is the biggest token spender, but if not, that'd be really interesting—what's kind of the second place function right now for tokens?

Applied AI 在推动 Claude Code 和 Co-work 的能力边界方面表现出色。我们的许多 Applied AI 团队成员会花时间与客户一起，帮助他们采用我们的 API。例如，有时我们的 Applied AI 团队会代表这些客户制作原型，而 Claude Code 使这一过程比以前快得多。他们还有一个双重目标，即需要管理大量的客户沟通、客户咨询、历史背景和通话记录。因此，他们既大量使用 Co-work，也大量使用 Claude Code。

Applied AI is amazing at pushing the boundaries of what Claude Code and Co-work can do. A lot of our Applied AI team spends time with our customers helping them adopt our API. So sometimes our Applied AI team will, for example, make prototypes on behalf of these customers, which Claude Code makes so much faster than it used to be. They also have the dual goal of needing to manage a lot of customer comms, a lot of customer inbound, and historical context, call notes. So they're both extremely heavy on Co-work and on Claude Code.

为了理解 Applied AI，这有点像前向部署工程师的角色吗？大多数人会如何描述 Applied AI 团队的工作？

Just to understand Applied AI, is that like forward-deployed engineering sort of role? How would most people describe what an Applied AI team is doing?

是的，它帮助我们的客户在整个公司采用最新的 API 和功能，既用于驱动公司产品，也用于内部加速。

Yeah, it's helping our customers adopt the latest API and features across their company, both for powering their company's products and also for internal acceleration.

明白了。所以这有点像客户成功和上市相关，类似于前向部署工程。

Got it. So it's like customer success and go-to-market-y, kind of like forward-deployed engineering.

没错。就像一个非常技术性的上市人员。

Exactly. It's like a very technical go-to-market person.

明白了。好的，太棒了。所以那可能是使用 token 第二多的组织。

Got it. Okay, awesome. So that might be the second org that uses the most tokens.

是的。我们还看到他们在推动 Cohere 的能力边界。例如，很多这些人负责多个客户，在高峰期一天可能有五到十次客户接触。所以他们经常在头天晚上让 Cohere 总结：‘好的，我第二天有哪些客户会议？这个客户向我要求过什么？他们最关心什么？过去会议的行动项是什么？’然后 Cohere 会整理出一份档案，一份简报，让他们在进入下一次会议前了解情况。Cohere 还可以研究答案。所以如果客户问：‘好的，功能 X 什么时候上线？’Cohere 可以帮助 PII 人员通过 Slack 研究获取最新的预计时间，并将其添加到笔记中，这样在客户通话期间，PII 人员就能掌握最新信息。这些只是人们为自己构建并与团队其他人分享的工作流程。

Yeah. And then we also see them pushing the boundaries of what Cohere can do. For example, a lot of these folks cover multiple customers and in any given day can have like five to ten customer engagements on a high day. So what they often use Cohere to do is the night before, they'll ask it to summarize: 'Okay, what are all my customer meetings that are coming up the next day? What are all the things that this customer has asked me for? What's top of mind for them? What are the action items from the past meetings?' And Cohere will just put together this dossier, this brief of what they should be aware of going into the next meeting. Cohere can also research answers. So if a customer asked, 'Okay, when is feature X going to launch?' Cohere can help the PII person research through Slack to get the latest ETA, add that to the notes so that during the customer call, the PII person has the absolute latest. And these are just workflows that people are building for themselves and sharing with other people on their team.

最近经常出现的一个话题是 token 消耗超过了人们的工资，人们使用 AI 的成本超过了他们的收入。Anthropic 内部有没有一些数字，比如工程师、产品经理每月或每天消耗多少 token？

Something that comes up a lot recently is token spend exceeding people's salary, where people just use AI and it costs more than how much they're making. Are there any numbers floating around Anthropic of just how much token spend, say engineers, spend a month, a day, or PMs, anything like that?

我们很清楚，随着模型变得更好，人们将更多任务委托给它，并在 Claude Code 和 Co-work 等工具上花费更多时间。因此，每次模型跃升或产品重大改进时，每个工程师或每个知识工作者的 token 成本都会增加。我认为这仍然远低于普通工程师的工资，但我们看到这个比例随着时间的推移在增加。

It's clear to us that as the models get better, people delegate far more tasks to it and they spend a lot more hours in tools like Claude Code and Co-work. So we do see the token cost per engineer or per any knowledge worker increase every time that there is a model jump or a substantial product improvement. I think it's still much lower than what the average engineer salary is, but we see the percentage increasing over time.

这真是一个有趣的飞轮。我们谈到你们可以使用最前沿的模型，这是在 Anthropic 工作的另一个优势。我相信你们基本上有无限的 token，想用多少就用多少，对吗？

It's such an interesting flywheel. We talked about how you have access to the most cutting-edge models and another advantage of working at Anthropic. I believe you guys have basically unlimited tokens. You can use as much as you want. Is that right?

我们可以使用很多 token。有些人确实会遇到限制，所以……

We can use a lot of tokens. Some people do run into limits, so...

有限制。好的。Boris，关掉它。拥有最先进的模型带来了这么多优势，这真是一个有趣的飞轮开始运转。

A limit. Okay. Boris, shut it down. It's so interesting how many advantages come from having the most advanced model. It's such an interesting flywheel that starts to kick in.

我认为我们也非常相信要赋能内部团队尽可能快地构建，并且我们相信每个人都理解服务这些模型真正消耗多少容量，我们信任团队负责任地使用 token。所以浪费 token 是非常不受欢迎的。但我们确实信任个人做出判断。

I think we also believe a lot in empowering our internal teams to build as fast as possible and we also trust that everyone understands how much capacity that serving these models truly costs and we trust our team to use the tokens responsibly. So it's very frowned upon to waste tokens. But we do trust individuals to make that judgment call.

回到产品经理的角色，我们之前谈过一点，但我觉得这对听众来说会非常有趣。我想了解的是，你认为产品经理需要培养哪些新兴技能，或者说如今 AI 公司在招聘产品经理时最看重什么？

Coming back to the PM role, we talked a little bit about this, but I think this will be really interesting for people to hear. What I want to understand is what do you think are the emerging skills that PMs need to develop, or you most look for when AI companies most look for when they're hiring PMs these days?

我认为最难的技能是能够定义产品一个月后应该是什么样子。我认为在那个时间线上，模型的能力以及用户行为将如何变化存在很多不确定性。但我认为最好的产品经理能够根据用户如何滥用现有产品的限制看到一些模式。最好的产品经理能感知到这一点，设定方向，并稳步执行，如果模型能力远好于或差于预期，则调整路径。我认为很难把握好 AGI 的度。因为每个人都能看到这个未来：模型极其智能，几乎能做所有事情，在这种情况下你实际上不需要那么复杂的产品。你实际上可以再次只有一个文本框，告诉模型你想要什么。它非常智能，可以添加任何工具或集成来完成任务。它知道何时不确定，可以问澄清问题。为超级 AGI 强模型构建产品非常容易。我认为困难的是，对于当前模型，如何激发最大能力？如何帮助用户走上黄金路径？如何引导用户利用模型优势并弥补其弱点？这种技能非常罕见。

I think the hardest skill is being able to define what the product should look like a month from now. I think there's a lot of ambiguity in what models are capable of in that timeline and how user behavior will change. But I think there are patterns that the best PMs can see based on how users are abusing the limits of the existing product. And the best PMs can sense that, can set a direction, and can steadily execute towards it, and change the path if the model capabilities are much better than or worse than what they'd originally expected. I think it is very hard to be the right amount of AGI pilled. Because I think everyone can see this future where the models are extremely smart and can do almost everything, in which case you actually don't need that complicated a product. You can actually just have a text box again where you tell the model what you want. And it's so smart that it can add any tool or add any integration that it needs to get the job done. It knows when it's uncertain, it can ask clarifying questions. It's kind of very easy to build the product for the super AGI strong model. I think the hard thing is figuring out for the current model how do you elicit the maximum capability? How do you help users go get onto the golden path? How do you guide users to interact with the model strengths and patch its weaknesses? This skill is pretty rare.

那你怎么培养这种技能？就是通过使用每个模型来理解它们的局限吗？你是在说品味，理解模型可能擅长什么、不擅长什么、哪里变了？

And how do you build that skill? Is it just using each like basically understanding the limits of each model, having like Are you talking about taste, understanding having taste into what the model maybe is capable of, what it's great at, not great at, where it's changed?

我认为是花大量时间与模型对话和使用它。我非常喜欢做的一件事是让模型反思自己的行为。有时当我注意到模型做了意想不到的事，比如模型会做前端更改并运行测试，但实际上没有使用 UI。让模型反思为什么这样做非常有用。有时它们会说：‘嘿，系统提示里有些令人困惑的地方，或者我没意识到前端验证是任务的一部分，或者我把验证委托给了子智能体，但子智能体没做，我也没检查它的工作。’很多时候，对模型决策的原因保持好奇，会揭示是什么误导了它，这样你就可以修复框架来缩小差距。另一件有帮助的事是找出哪些用户是你最信任的，能给你关于模型的准确反馈。通常有少数人比其他人更擅长表达特定模型或模型-框架组合好在哪。很多人会给你反馈，但并非所有人的反馈都同样有分量。所以，找到五六个你信任的人对于快速获得反馈非常重要。我认为第三件有用但并非所有人都喜欢做的事是构建评估。你不需要构建数百个评估才有用。只构建 10 个好的评估就能帮助团队量化目标、进展和缺失之处。所以，我认为评估是被低估的东西，更多的产品经理和工程师应该投入其中。

I think it's spending a ton of time talking and using the model. One of the things I really like to do is to ask the model to introspect on its own behaviors. So sometimes when I notice that the model does something unexpected, like for example, there's like situations where the model will make a front-end change and run tests, but not actually use the UI. It's actually pretty useful to ask the model to reflect on why it did this. And sometimes they'll say that, 'Hey, there's like something confusing in the system prompts, or I didn't realize that the front-end verification was like part of this task, or hey, I delegated the verification to this sub-agent, and the sub-agent didn't do the task, and I didn't check its work.' A lot of times just like being very curious about why the model made the decision that it did will show you what misled it, so that you can fix the harness in order to close this gap. The other thing that helps is to figure out who the taste who are the users who you trust the most to give you accurate feedback about the model. Usually there's like a handful of people who are much better than others at articulating what makes a specific model or model-harness combination good. And there's a lot of people who will give you feedback, but not everyone's feedback is as qualified. And so, finding a group of those like five people you trust is really important for getting very fast feedback. I think the third thing that is useful, but not everyone loves doing, is building evals. You don't need to build hundreds of evals for them to be useful. Just building 10 great evals is important for helping the team quantify what the goal is, and what their progress towards it is, and what they're missing. And so, I think evals is this like underappreciated thing that more PMs, more engineers should be working on.

我们聊了很多评估。有一种趋势是，未来的产品管理就是写评估，因为它本质上定义了成功是什么样。好吧，让我具体定义它，然后我们就知道了。你大概花多少时间写评估？

We've covered evals a bunch. There's this trend of just like that is the future product management is writing evals because it and essentially it's what does success look like? Okay, cool. Let me actually concretely define it and then we'll know. How much of your time are you spending writing evals would you say?

我认为评估的重要性因你正在开发的功能或试图解决的问题而异。我们团队有很多人花大量时间做评估。我们有一个小组与研究人员紧密合作，更精确地理解 Claude 代码的行为以及最大的改进领域，并尝试具体衡量。我个人会在某个功能需要更多产品定义时介入评估，通常产出是：这是我做的五个评估，这是运行方法，这些是成功的，这些是失败的，这是我用来提高成功率的提示。但这因具体功能而异。不是每个功能都需要，但我认为像记忆这样的功能从中受益很大。

I think the importance of evals varies a bit based on the feature that you're working on and or like what the problem you're trying to solve is. So there are a lot of folks on our team who do spend a lot of time working on evals. We have a small pod of folks who collaborate very closely with research to more precisely understand our Claude code behaviors and what the largest areas of improvement are and trying to measure those pretty concretely. I personally jump into evals when there's a feature that I think needs a bit more product definition and often the output of this is okay, here are like five evals that I made. This is how you run them. These are the ones that succeed and these are the ones that don't and this is like the prompt that I've used to increase the success rate. It varies a lot though based on the exact feature. Not every feature needs it but I think features such as memory benefit a lot from it.

你提到的有些人非常擅长评估模型，这很有趣。这几乎就像人类评估，他们知道模型哪里突出或哪里不足。有没有特别想表扬的人？

This point you made about people being very good at evaluating models so interesting. It's almost like a human eval of just like okay, they understand where it's spiking or it's maybe lacking. Is there anyone specific that you want to shout out that's very good at this?

我认为有两个人非常出色：一个是 Amanda，她塑造了 Claude 的性格。这角色很难，因为任务非常模糊。甚至编码都更容易，因为你可以验证成功，而塑造性格需要对 Claude 应该成为什么样有很强的信念。我认为她不仅有出色的塑造能力，还能清晰地表达目标、什么成功、什么不成功。另一群我非常信任的人是 Claude 团队。我们经常有团队午餐，每当测试新模型时，最快获得反馈的方式就是在午餐时走到每个人面前问：‘你对这个模型感觉如何？’我们经常得到反馈，比如：‘这个模型没有完全解释它的思考，太突兀了。’或者：‘这个模型喜欢写大量记忆，但我们不确定记忆质量如何。’或者有人会注意到：‘这个模型喜欢自我测试，这很好。’或者：‘这个模型自我测试不够。’这指导我们查看哪些数据来验证：‘这是一个更大的模式吗？’我们有大量数据，但很难提取见解。所以这个群体的反馈帮助我们确定：‘我们要测试哪些假设？’然后我们就能提取数据来测试。

Two people who I think are incredible at this are one Amanda who molds Claude's character. It's just like such a hard role because the task is so ambiguous. Even coding is easier because you can verify the success whereas crafting the character requires a very strong sense of conviction in what who Claude should be. And I think she has like an incredible ability to not only mold the character, but also to articulate what the goals are, what the character what's successful and what's not. The other group of people who I really trust is just like the Claude team. So we often have team lunches and whenever there's a new model we're testing, one of the fastest ways for us to get feedback is to just like at these team lunches, just like go to every single person and just be like, 'Hey, what is your vibe on the model?' And often times we'll get feedback like, 'Okay, this model is like not fully explaining its thinking. It's like too abrupt.' Or like, 'Hey, this model is like just loves writing a ton of memories, but like we're not sure if the memories are high quality or not.' Or like some people will notice that, 'Okay, this model loves to test itself, which is great.' Or like, 'This model isn't testing itself enough.' So that informs what data we look at to verify, 'Okay, is this a larger pattern?' So we have a ton of data, but it is very hard to extract insights. And so the feedback from this group helps us inform, 'Okay, what are the hypotheses we want to test?' And then we're able to extract data to test that.

你提到的 Claude 性格这一点，我采访过联合创始人 Ben Mann，他也谈到性格和构成是 Claude 非常重要的一部分。我后来才意识到，比如人们用 Open Claude 时，一个让人难过的原因是 Claude 的性格太好了，有趣又好玩，与其他模型不同。他的说法是，性格让 Claude 在很多事情上表现出色。这看起来像是个琐碎的附属品——它会变得有趣、好玩、说话有趣——但这实际上是 Claude 成功的核心。你能分享一些人们可能不理解的东西吗？为什么你描述的性格和个性如此关键？

This point you made about the character of Claude, I had Ben Mann on the podcast co-founder and he talked about this just like the character, the constitution of Claude is such an important part of Claude and I didn't realize until afterwards just like like people like with Open Claude actually, one of the example one of the reasons people are sad is like the personality of your Claude is like because Claude's personality is so good and fun and interesting unlike other models. And there's And the way he put it is the personality is what makes Claude so good at so many things. It feels like this like trivial side thing. Okay, it's going to be funny and interesting and talk in a fun way, but it's like so core to the success of Claude. Is there anything you'd share there about just like what people may not understand about why the character as you described and the personality is so key?

当你回想所有共事过的人，有些人就是让你觉得‘我真的很喜欢他们的能量，喜欢他们的氛围’。当人们想到 Claude 和 Claude Code 时，这是他们最常提到的一点：他们非常喜欢 Claude 轻松有趣的特质。但它对你的任务也极其自信。人们很喜欢 Claude 的低自我。所以如果你告诉它：‘嘿，你做错了。’它会真诚道歉：‘哦，糟糕，谢谢你告诉我，让我修复它，我们一起合作。’它也非常积极。所以如果你觉得：‘哦，这是个无法完成的任务，我不知道如何开始。’Claude 会说：‘没关系。’

When you reflect on everyone you've worked with, there's just some people where you're like, I really like their energy. Like, I really like their vibe. And when people think about Claude and Claude Code, this is one of the things that people bring up the most where they just really love that Claude is like it's like light-hearted and fun. But it also is extremely confident at your task. People really like that Claude's low ego. And so, if you tell it, 'Hey, you did this thing wrong.' it's like truly sorry. It's like, 'Oh, shoot. Like, thanks for telling me. Like, let me fix it. Let's work together.' It's also very positive. So, if you're feeling like, 'Oh, this is like an insurmountable task. I don't know how to get started.' Claude is like, 'Okay. It's okay.'

这些是我认为我们应该采取的步骤。比如，你想让我开始做吗？我认为一个优秀同事的部分特质是这种积极性、这种行动偏向、这种给予你真诚反馈的能力，而不是一味同意你说的每一件事。所以，我们试图将这一点注入 Claude，因为我们认为这会让与它合作更加愉快。

These are like the steps that I think we should take. Like, do you want me to get started on it for you? I think part of what makes a great coworker is this positivity, this like bias towards action, this ability to give you like earnest feedback, not just agreeing with every single thing that you say. And so, we try to imbue this into Claude because we think it makes it a lot more enjoyable to work with.

有件事我想回头再谈。你提到当新模型发布时，你经常需要重新审视你构建的东西。这很有趣，也可能有点令人沮丧。就像，‘哦，该死的。重新调整这个东西。现在我必须重新思考。’谈谈你多久需要带着新模型回来，然后他们说，‘好吧，我们必须重做几个月前推出的这个产品。’

There's something I want to come back to. You talked about how when new models come out, you often have to kind of revisit things you've built. That's so interesting and so like frustrating maybe. Just like, 'Oh, god damn it. Reshift this thing. Now I have to rethink it.' Talk about just how often you have to come back with a new model and they're like, 'Okay, we have to redo this product that we launched a few months ago.'

我们对新模型所做的很多改动是移除不再需要的功能。很多时候，我们为产品添加功能作为模型的拐杖，因为它本身不会自然做到。一个典型的例子是待办事项列表。当我们首次推出 Claude Code 时，人们要求它进行大型重构，Claude Code 会说，‘好的，我需要更改这 20 个调用点。’然后它会更改其中五个就停下来。于是我们想，‘我们如何强制它记住要完成所有这 20 个？’我们团队的 Sid 说，‘如果我们想想人类会怎么做？人类会列出所有需要更改的事项。就像在 VS Code 中，你会查找所有调用点，左侧会有一个列表，然后你逐一替换。我们如何给 Claude 这样的工具？’于是他添加了待办事项列表。我们发现有了这个，Claude 确实能够修复所有 20 个调用点。但到了 Opus 4 及之后的模型，我们意识到不需要强制它使用这个待办事项列表，它会自然使用。对于早期模型，我们必须不断提醒它，‘嘿，你完成了待办事项列表上的所有内容吗？只有完成所有待办事项你才能结束。’而对于后来的模型，无需提示，它就会自然思考完成待办事项列表上的所有内容。如今，待办事项列表作为用户仍然不错，因为你可以更清楚地看到 Claude 在做什么。但老实说，它现在在产品中已经不那么重要了，模型可能会用，也可能不会用。它对于进行彻底更改已经不再必要了。

A lot of the changes that we make with a new model is removing features that are no longer needed. So, a lot of times we add features to the product as a crutch for the model because it's not naturally doing itself. So, the classic example for this is a to-do list. When we first launched Claude Code, people would ask it to do these large refactors and Claude Code would say, 'Okay, cool. I need to change these like 20 call sites.' And it would go and change five of them and then stop. And then we were like, 'Okay, how do we force it to remember to get every single one of these 20?' And so Sid on our team was like, 'Okay, what if we just think about what a human would do? A human would make a list of everything that they need to change. Similar to how in VS Code you would look up all the call sites and it'll be a list on the left side and you would go through them one by one and replace all. How do we give this kind of a tool to Claude?' And so he added the to-do list. And we found that with that, Claude was actually able to fix all these 20 call sites. But then with Opus 4 and later models, we realized that we didn't need to force it to use this to-do list. It would naturally use it itself. For the earlier models, we had to keep reminding it, 'Hey, did you finish everything on the to-do list? You can't finish until you're done with everything on the to-do list.' And for the later models, without prompting, it just naturally thinks to do everything on the to-do list. These days, the to-do list is still nice to have as a user because then you can more clearly see what Claude is working on. But honestly, it's such a de-emphasized part of the product right now that the model may use it, the model may not use it. It's really not necessary for it to make thorough changes anymore.

我忘了是谁在播客上说过，模型会吃掉你的束缚。我在这里听到的是，随着时间的推移，你移除了那些你不得不添加到模型之上的东西，因为模型之前没有按你想要的方式运作。本质上，随着模型变得更聪明，它做你想让它做的事情变得越来越简单。

I forget who said this on the podcast that the model will eat your harness for breakfast. And what I'm hearing here is essentially you remove things over time that you've had to add on top of the model where it was not operating the way you wanted and essentially as the models get smarter, it just becomes simpler and simpler for it just to do the thing you want it to do.

是的，每次模型变得更聪明，我们都可以移除很多提示干预。我们实际上每次发布模型时都会这样做。我们会通读整个系统提示，反思，‘好吧，对于每个部分，模型真的还需要这个提醒吗？如果不需要，我们就移除它。’不过，新模型解锁的最令人兴奋的事情是全新的功能。有很多功能我们之前用旧模型测试过，但准确率不够高，所以我们没有发布。其中一个例子是代码审查。我们尝试构建代码审查产品几次，过去发布过简化版本，比如斜杠代码审查命令。直到最近的模型，我们才觉得，‘好吧，这个代码审查如此出色，以至于我们的工程团队在合并 PR 之前依赖它通过。’我们发现，我们一直梦想着 Claude 能够成为一个可靠的代码审查者，能够自信地捕捉大多数错误。只有在 Opus 4.5、4.6 和 Sonic 4.6 上，我们才觉得，‘好吧，我们现在能够同时运行多个代码审查智能体，遍历整个代码库，并综合出一组工程师在合并前需要解决的实际问题。’所以，这是最新模型解锁的新能力。

Yeah, we can remove a lot of prompting interventions every time the model gets smarter. And we actually do this every time we launch a model. We read through the entire system prompt and we reflect on, 'Okay, for each of these sections, does the model really need this reminder anymore? And if not, we'll remove it.' The most exciting thing that new models unlock though is just entirely new features. So, there's all the features that we've been testing out with prior models and the accuracy wasn't high enough for us to want to launch them. And so, one example of this is code review. We tried to build a code review product a few times and we've launched like simpler versions of code review which is the slash code review command in the past. And it was only with the most recent models that we felt like, 'Okay, this code review is so good that our engineering team relies on this code review to pass before we merge PRs.' And we found that this was we've always dreamed of Claude being able to be a reliable code reviewer that can actually confidently catch the majority of bugs. And it was only with Opus 4.5 and 4.6 and Sonic 4.6 that we felt like, 'Okay, we are now able to run multiple code review agents simultaneously to traverse the entirety of the code base and to synthesize a set of real issues that an engineer needs to address before merge.' And so, this is like a new capability that the newest models have unlocked.

这是这个播客上非常常见的另一个趋势：构建一些可能在接下来 6 个月内变得可行的东西。你处于可行性的边缘，然后它会赶上，然后它会成为一个惊人的产品，你会领先于所有人。

This is another trend that is very common on this podcast of build something that will possibly be possible in the next 6 months. You kind of at the edge of what's working sort of and then it'll catch up and then it'll be an amazing product and you'll be ahead of everyone.

是的，完全正确。构建那些还不一定可行的产品非常重要，这样你就能知道，好吧，这个产品还缺少什么才能工作，然后随着最新模型的发布，你可以直接把它换入你已经制作的原型中，看看这个新模型是否填补了那个差距。

Yeah, exactly. It's pretty important to build products that don't necessarily work yet so that you know, okay, what is missing for this product to work and then with the newest model, you can just swap it in to the prototype you've already made and see, okay, does this new model close that gap?

你能谈谈 Claude 和 Cork 的发展方向以及愿景吗？我想你不想透露太多目标，但感觉你们正在添加所有这些很棒的功能。Dispatch、手机控制、所有移动应用等等。有什么方法可以理解所有这些事情的长期愿景？

How much are you able to speak to just kind of where things are going with Claude and Cowork as kind of the vision of it? I imagine you don't want to give away too much about the goal, but it feels like you're There's all these awesome features being added on top. Dispatch, control from phone, and all these mobile app, all these things. What's kind of just like with a way to understand the vision for all these things long term?

我们从构建块的角度来思考。对于 Claude Code 和 Cork，核心构建块是让单个任务成功。所以，你想要我们产生一些输出，你给出清晰的提示描述。它能否持续产生可接受的输出，让你能够合并或与同事或外部受众分享？所以，任务是核心构建块。随着模型变得更聪明，任务成功率大大提高，然后我们看到人们开始同时执行多个任务。所以，多 Claude 在 2025 年底是一件大事，而且从那以后只增不减。我们将其视为，‘好的，很好。一个任务可行，现在你可以同时做六个任务。’随着模型变得更聪明，我们推断，‘好的，接下来，你可能一次运行 50 个或数百个 Claude。’那么，我们需要构建什么基础设施来实现这一点？到那时，你可能不再在本地机器上运行所有东西了。没有足够的 RAM 来做这件事。所以，我们正在思考如何让你更容易管理所有这些。这些可能会远程运行。

We think about this in terms of building blocks. So, for both Claude Code and Cowork, the core building block is making individual tasks successful. So, you want us to produce some output, you give it a clear prompt description. Is it able to consistently produce acceptable output that you're able to either merge or share with your colleagues or external audience? So, the task is the core building block. As the models get smarter, the task success rate gets a lot higher, and then we see people moving towards doing multiple tasks at the same time. So, multi-cloding was this big thing in towards the end of 2025, and it's only increased since then. And so, we see this as, 'Okay, great. One task works, and now you can do like six tasks at a time.' As the models get even smarter, the way that we were extrapolating this is, 'Okay, next, maybe you're going to run like 50 clods at a time or hundreds of clods at a time.' And so, what is the infrastructure we need to build to enable that? At that point, you're probably not going to run everything locally on your machine anymore. There's just not enough RAM to do it. And so, we're thinking about how do we make it easier for you to manage all these. These will probably run remotely.

我们如何构建界面，让你作为人类知道哪些任务需要你查看？我们如何确保智能体完全验证工作，这样当你看到一个任务显示已完成时，你能快速验证并完全信任它符合你的规格？我们又如何确保这个过程是自我改进的？这样当你看到一个不符合你心意的任务时，你可以给出反馈，模型会在未来的每次运行中纳入该反馈，从而不再犯同样的错误。所以，这就是我们引导用户经历的进步过程。

How do we build the interface so that you as a human know which tasks you need to look into? How do we make sure that the agent is fully verifying work so that when you look at a task and it says it's done, you can very quickly verify and fully trust that it is done to your spec? And how do we make sure that this process is self-improving? So that when you do see a task that isn't done to your liking, you can give it feedback and the model will know for every future run to incorporate that feedback so it never makes that mistake again. So, this is the progression that we're bringing our users along for.

有很多听众，很多产品经理，可能还有很多创始人，以及其他跨职能的人。他们非常担心自己的角色和职业前景。你会给人们什么建议，让他们不仅能在向这个高度 AI 驱动的世界过渡中生存下来，而且能真正成功，在这个未来中茁壮成长？人们需要听到什么，需要做什么？

There's a lot of people listening, a lot of product managers, a lot of maybe founders, a lot of other cross-functional folks listening. There's a lot of worry about just how their role, the future of their careers. What advice would you give to people to not just survive this transition to this very AI-driven world, but to be really successful, to essentially just to thrive in this future? What are just like things people need to hear, need to be doing?

我认为 AI 给每个人带来了比以往更多的杠杆效应。所以，我会鼓励你，每当你意识到自己在重复做某些手动任务时，就想想如何利用 Claude Code、Co-work 或其他 AI 工具来自动化这些任务。大多数人的工作中都有他们非常热爱的创造性部分，也有他们非常讨厌的繁琐部分。我认为 AI 的美妙之处在于它可以为你做那些繁琐的部分。它可以从你每次执行手动任务中学习，进行泛化，然后自动运行。这样你就可以专注于创造性部分，这意味着你可以比以前做更多的事情。所以，我立即想对人们说的是：找出那些可以交给 Claude 的重复性部分。不断迭代这些自动化，直到成功率非常高。然后专注于：你还能为你的团队、产品、公司做哪些以前没有精力去做的事情？或者，那个你一直认为公司应该做但从未有精力去做的个人项目是什么？如果 AI 能处理前端工作，那么你现在就有了额外的 20%时间，这是以前没有的。所以，我的建议是：拥抱这些工具，把你不感兴趣的工作交出去，弄清楚它们如何加速你的工作，结果就是你能做更多的事情。

I think AI gives everybody a ton more leverage than they used to. And so, I would push you towards anytime you realize that you're doing some manual task multiple times, think about how you can use Claude Code, Co-work, or other AI tools to automate that for you. Most people have creative parts of their job that they absolutely love and then tedious parts that they really hate doing. I think the beauty of AI is that it can do those tedious parts for you. It can learn from every time that you've done that manual task and generalize and then run it automatically. And so that you can focus on the creative parts and that means you can do a lot more than you used to be able to do. So, I think my immediate push for people is figure out the repetitive parts that you can pass to Claude. Iterate on those automations until the success rate is very high. And then focus on, okay, what more can you be doing for your team, for your product, for your company that people haven't had the bandwidth to pick up so far? Or like, what is that pet project that you always thought the company should do that you've never had bandwidth to do? If AI can take care of the front work, then you have this extra 20% time now that you might not have before. So, my push is to lean into these tools, hand off the work that you're not excited to do, figure out how it can accelerate you, and then as a result, you'll be able to do so much more.

你刚才分享的核心观点，我完全同意，就是找到可以用 AI 解决的问题。这些工具有很多潜力。对很多人来说，最难的部分就是‘我到底该做什么？’而你在这里说的是，关注那些你一直在做、可以自动化的事情。关注那些一直存在但你一直没有时间做的想法。基本上就是为自己解决一个问题。这算是核心建议。

Something core to what you just shared, which I fully agree with, is find problems to solve with AI. There's all this potential what all these tools can do. Some of the hard for a lot of people, the hardest part is just like, 'What should I actually do?' And what you're saying here is just pay attention to things that you are doing constantly you can automate. Pay attention to just like ideas that have been floating around that you haven't had time to do. It's basically it's like solve a problem for yourself. It's kind of the core advice there.

完全正确。我还想推动听众专注于将你的自动化从‘好吧，这是个很酷的概念’提升到‘嘿，这实际上 100%有效’。有时我看到用户试图自动化某件事，达到了 90-95%的准确率，然后就放弃了。如果一个自动化不能 100%有效，那它就不是真正的自动化。最后那 5-10%确实需要更多时间。而且，构建自动化通常比你亲自做要慢得多。我会鼓励听众投入时间，规划一些你真正想达到 100%的自动化。付出努力去教 Claude 你的偏好，给它反馈，这样它就能提高技能，达到 100%，然后你才能真正依赖它。一个 95%的自动化价值不大。

Exactly. I would also push listeners towards focusing on bringing your automations from, 'Okay, this is a cool concept.' to like, 'Hey, this actually works 100% of the time.' Like sometimes I see users trying to automate something, getting it to like 90-95% accuracy, and then giving up on it. And this if an automation doesn't work 100% of the time, it's not really an automation. And that last 5 to 10% does take more time. Also, building the automation is often a lot slower than you doing it yourself. I would encourage listeners to put in that time to scope some automation that you really want to get to 100%. Put in the elbow grease to teach Claude your preferences, to like give it feedback so that it can improve its skill, so that it can get to that 100%, and then like really then you'll be able to rely on it. There's just not much value in a 95% there automation.

我在这方面超级有罪。这对我来说真是个好建议。

I am super guilty of that. This is really good advice for me.

我也犯过这个错。我一直在教它。我一直在教 Coda 帮我实现 Gmail 收件箱清零，但非常耗时，而且显然还没成功，你可能也意识到了。

I've been guilty of this, too. I've been teaching it. I've been teaching Coda to try to get me to inbox zero for Gmail, and it has not been it has been very time-consuming and it is definitely not there as you probably realized.

是啊，有趣的是，我正好也想到了这个。我设置了一个工作流，每封邮件都会检查是否是垃圾邮件，比如‘嘿，我能上你的播客吗’或‘这个怎么样’之类的，我没时间处理这些，我就把它们归类到一个叫‘垃圾’的文件夹里。它 95%都很好，但然后就会发生‘哦，我错过了一封邮件，因为它进了那个文件夹’。所以这对我来说是个很好的推动，我要努力把它做到完美。

Yeah, I funny enough that's exactly where my mind goes. I have this workflow I set up where every email I get it looks for things that are spammy which is just like all these like 'hey can I come on your podcast' or 'what about this' like all these things I'm just like I don't have time for these sorts of things and I have it categorized it into a folder called spammy. And it's just like it's 95% great but then there's like oh man I missed an email cuz it went in there. So this is a good push for me to like I'm going to work on this. I'm going to get it to perfect.

是的。我们也在努力让定制这些命令的流程更简单，因为现在我认为你需要了解太多概念。你需要知道如何定义一个技能。你需要知道如何使用技能并给出反馈。然后你需要知道如何告诉 Coda 根据你给出的所有反馈更新技能。然后你还需要知道在哪里查看技能，以确保反馈按你想要的方式被纳入。让这个流程真正无缝，做起来不痛苦，也是我们的工作。

Yeah. We also are working on making the flow for customizing these commands a lot easier because right now I think you have to know too many concepts. You have to know to define a skill. You have to know to use the skill and give it feedback. And then you have to know to tell Coda to update the skill based on all the feedback that you gave. And then you also have to know where to read the skill to make sure that the feedback was incorporated the way that you want. It's also our job to make this flow really seamless so that it doesn't feel painful to do.

太棒了。Cat，你还有什么想分享的吗？还有什么想留给听众的吗？在我们进入非常激动人心的快速问答环节之前，有什么你想强调而我们还没有涉及的吗？

Amazing. Is there anything else Cat you wanted to share? Anything else you wanted to leave listeners with? Anything you want to double down on that we haven't already touched on before we get to our very exciting lightning round?

我看到很多人玩 AI，构建原型应用，摆弄工作流。我真的会推动人们去构建你每天实际使用的应用，因为我认为只有通过使用，你才能真正获得价值。如果你构建的原型应用不能帮你完成更多工作，那么 AI 并没有真正为你的日常增加价值。

I see a lot of people playing around with AI and building prototype apps and tinkering with building workflows. I would really push people towards building apps that you're actually using every single day because I think only through that usage are you actually getting the value. Like if you build a prototype app that isn't helping you get more done then the AI isn't really adding value to your day.

而且你从中学到的东西有限，比如‘好吧，我试了一次，哦，很酷’，然后你再也不碰它了。你并没有学到很多。

And there's only so much you learn from that when it's like okay I just did one shot at something oh that's cool and then you never come back to it. Like you're not learning a lot.

而且你也没有从中获得多少杠杆效应。

And you're not getting much leverage from it.

真正的杠杆效应，是的，这点说得很好。

And actual leverage yeah that's such a good point.

我还认为有很多人花大量时间定制他们的工作流。所以，我认为有两个极端。一端是那些从不定制或从不构建自动化的人，但另一端是那些痴迷于定制工具的人，比如添加大量技能、MCPs 和工作流改进。

I also think there's a lot of people who spend a lot of time customizing their workflow. So, there's like I think there's like two ends of the spectrum. One is like people who never customize or never build automations, but there's like this polar opposite end of people who, like, obsess around customizing their tool, like, adding a ton of skills and MCPs and these workflow improvements.

而且我认为有时候这甚至会分散你对核心目标的注意力，比如推出某个产品或构建某个功能。我觉得定制化很有趣，我们当然希望让产品非常可定制，这样你可以让它非常适合你，但它的有用性是有限度的。我认为有一群人可能花了太多时间定制，以至于不睡觉，也不做他们最初设定的核心任务。

And I think sometimes that can even distract from your core goal of like launching some product or building some feature. I think there's a lot of fun in customizing and we definitely want to make our products very hackable so that you can make it work really well for you, but there is a limit to how much it's useful. And I think there's a camp of people who maybe spend so much time customizing that they're like not sleeping and not doing the core task that they originally set out to do.

我在推特上看到很多这种情况。就像，‘看我的设置，太疯狂了，太优化了。’但你到底在构建什么？不，但我的设置太棒了。就像，你可以完成很多事情。

I see a lot of that on Twitter. Just like, 'Look at my setup. It's out of control. It's so optimized.' And what are you actually building? No, but my setup is so awesome. Like, you can get so much done.

我认为简单的设置实际上效果更好。

I think the simple setups actually work better.

嗯。斜杠增强。稍微提升一个级别。

Mm. Slash power up. Getting Take level up a little bit.

是的，是的。

Yeah, yeah.

昨天 Karpathy 发了一条推文，他谈到了一个有趣的分歧：一边是那些早期尝试 ChatGPT 或 Claude 的人，他们觉得‘好吧’，然后说‘不，这太糟糕了’，基本上放弃了 AI 能为他们做什么，变得非常愤世嫉俗，认为‘不可能，这没那么了不起’。另一边是那些用它来编程的人，他们看到了它强大的能力和优秀的表现。双方都不理解对方，也不理解对方为什么那样看待世界。所以你的建议非常好，就是真正用它来做实际的事情，看看它到底变得多好。

There's this Karpathy tweet that just came out yesterday where he talked about this divide that's interesting between people that tried ChatGPT Claude back in the day, it was like, 'Okay.' And they're like, 'Nah, this is terrible.' And they kind of gave up on what AI could do for them and they're just so cynical like, 'No way, it's not actually that big of a deal.' And then there's people that are using it to code, essentially, who see the full intense power of it and how good it is. And people on both sides don't understand the other side and why they see the world the way they do. So your advice is really good here of just actually use it for real things and see how good it actually has gotten.

是的。我认为巨大的转变在于，2024 年的产品是基于聊天的，而 Claude 代码生成产品是基于行动的。人们最大的顿悟时刻是当 Claude 能代表你做事时。知道智能体不仅能告诉你该做什么，还能实际执行，这种感觉太棒了。当人们体验到这一点时，我认为那就是大开眼界的时刻。

Yeah. I think that big shift is that the 2024 generation of products were chat-based and the Claude code generation of products is action based. The big aha moment people have is when Claude can just do things on your behalf. It is an amazing feeling to know that the agent is capable of doing so much more than telling you what to do. Like the agent can actually just do it itself. And when people feel that, I think that's the eye-opening moment.

特别推荐 Chrome 扩展，Claude 的 Chrome 扩展，你可以看着它做事。你说‘帮我填这个表格’，然后它就说‘好的，开始’。

Shout out Chrome extension, the Claude Chrome extension which you can just watch it doing stuff. You be like 'fill out this form for me' and I'm like 'all right, here I go.'

完全正确。

Exactly.

好的。在进入我们非常激动人心的快问快答环节之前，还有什么要说的吗？

Okay. Anything else before we get to our very exciting lightning round?

没有了，开始吧。

No, let's do it.

开始吧。Cat，我有五个问题要问你。欢迎来到快问快答环节。这里有一段动画要播放，所以我得确保说出来。你准备好了吗？

Let's do it. Cat, I've got five questions for you. Welcome to the lightning round. There's this animation that plays so I have to make sure to say it. Are you ready?

我准备好了。

I'm ready.

第一个问题，你经常向别人推荐哪两三本书？

First question, what are two or three books that you find yourself recommending most to other people?

我非常喜欢《亚洲如何崛起》。这是一个关于经济发展的故事，讲述了哪些政策和政府造就了长期成功的经济体。另一本我很喜欢的书是《技术陷阱》。这本书实际上讲的是过去几次技术革命，工业革命和计算机革命，以及它们如何影响工人。我之所以喜欢它，是因为我认为我们可以从历史中学到很多，以确保这次转型顺利进行。也许轻松一点，我很喜欢《纸动物园》。它是一本短篇小说集，关于成长、AI 和自我发现。

I really like 'How Asia Works'. It's a story about economic development and what are the policies and governments that make long-lasting successful economies. The other book that I'm really into is 'The Technology Trap'. So this is actually about the past few technology revolutions, the industrial revolution and the computer revolution, and how this has affected workers. The reason that I really like this is because I think there's a lot we can learn from history to make sure that this transition goes well. And maybe on a fun note, I really like 'Paper Menagerie'. It's just a book of short stories about coming of age and AI and just self-discovery.

最近你非常喜欢的电影或电视剧是什么？

Favorite recent movie or TV show you have really enjoyed?

我非常喜欢《极速求生》。它没有什么深层含义，我只是觉得人们如此痴迷于一个单一的工程目标，以及追求的纯粹性，这非常令人满足。我也非常喜欢《徒手攀岩》，讲的是 Alex Honnold 无保护攀登酋长岩。我认为同样，能够攀登这条极具挑战性、危险的路线，是一种纯粹的成就。而且能够有心理专注力去做，知道如果犯一个错误就会死。

I really like 'Drive to Survive'. There's no deeper meaning to it. I just find something very satisfying about people being so obsessed with a singular engineering goal and just the purity of the pursuit. And I also really love 'Free Solo', which is about Alex Honnold climbing El Capitan without a harness. And I think similarly, it's such a pure achievement to be able to climb this extremely challenging, dangerous route. And to be able to have the mental focus to do it knowing that if you make a single mistake, you die.

太疯狂了。是的，那部电影太不可思议了。有趣的是，这些在某种程度上与你所做的工作有关。

It's insane. Yeah, that movie is out of control. And it's interesting how these relate in some way to the work you do.

我其实是个攀岩者。但我第一次看《徒手攀岩》是在我开始攀岩之前。所以我觉得它令人印象深刻，但我不理解它有多令人印象深刻。这是一部少有的电影，你知道得越多，就越被它的疯狂所震撼。比如他在岩壁上做的那些动作，我觉得我这辈子都做不到，即使是在离地一英尺的健身房里。

I actually am a rock climber. But I first watched 'Free Solo' before I climbed rocks. And so I thought it was impressive, I didn't understand how impressive it was. It's one of the rare movies where the more you know about it, the more you're blown away by how insane this is. Like the kinds of moves he's doing on the wall are things that I don't think I will ever be able to do in my lifetime if it were set in a gym like 1 ft off the ground.

还带着绳子。

With a rope.

你看过关于另一个人的纪录片吗？那个更年轻的，去爬冰山的那种？

Did you see that documentary on that other guy, the younger one that went on like ice mountains?

那个很悲伤。

That one was very sad.

但那很狂野。好的，你最近发现并非常喜欢的产品是什么？

But that was wild. Okay, favorite product you've recently discovered that you really love?

除了 Claude 产品之外，对我的生活改变最大的产品可能是 Waymo。我是 Waymo 的忠实用户。每天用两次，上下班。我非常喜欢它的两点是：第一，如果 Waymo 在等我，我不会感到内疚。所以我不必在它到达的那一刻就站在路边。第二，我觉得它让我更有效率。当我和另一个人一起坐车时，我通常不会打工作电话。如果我一直用笔记本电脑，我会觉得有点不礼貌。但 Waymo 让我可以参加工作会议，不用担心有人偷听，也不用担心‘嘿，这礼貌吗？我说话太大声了吗？我需要请人换音乐吗？’所以这让我每天多出了 30 分钟。

The product that has most changed my life outside of Claude products is probably Waymo. I'm a die-hard Waymo user. Use it twice a day, get to and from work. The two things that I really like about it are: one, I don't feel bad if a Waymo is waiting for me. So I feel less pressure to be right at the curbside the moment it arrives. And the second thing is, I feel like it lets me be a bit more productive. When I'm in the car with another human, I typically try not to do any work calls. I feel a little rude if I'm on my laptop the whole time. But one thing I really appreciate about the Waymo is I can call into a work call, I'm not worried about someone overhearing me, I'm not worried about 'hey, is this rude, am I talking too loud, do I need to ask someone to change the music?' So this has given me back like 30 minutes every day.

所有这些技术的二阶效应，太有趣了。

All these second order effects of technology, it's so interesting.

是的，我一直以为 Waymo 需要比 Uber 和 Lyft 定价更低才能成功，但实际上我很乐意支付两倍的价格。

Yeah, I always thought Waymo needed to be priced lower than Uber and Lyft to succeed, but actually I'm very happy to pay a 2x premium for it.

我喜欢 Waymo。就像你第一次看到它时，你会想‘这太疯狂了’，然后你就习惯了。你坐进去，觉得‘这太疯狂了’，然后你就忘了。

I love Waymo. It's just like once you see it, you're just like 'how is this insane' and then you get used to it. Like you get in there, you're like 'this is crazy' and then you forget about it.

完全同意。我认为它也改变了用语。比如 Anthropic 的很多人喜欢 Waymo，过去你会说‘嘿，叫个拼车应用’，现在大家都说‘好的，Waymo 到了吗？’

Totally. I think it's also changed the vernacular. Like a lot of people at Anthropic love Waymo and I think in the past you'd be like, 'hey, what's call like follow a ride share app' and now everyone's just like, 'okay, is Waymo here?'

好的，还有两个问题。你有没有一个经常在工作中或生活中回顾的座右铭？

Okay, two more questions. Do you have a favorite life motto that you often come back to in work or in life?

只管去做。

Just do things.

说得通。这是个好座右铭。

That tracks. That's a good one.

第一性原理思考很有价值。如果你知道自己在优化什么，并且有扎实的第一性原理，那么你通常能推导出正确的行动方案，并向所有利益相关者清晰传达，然后直接去做就行。我认为职位是虚假的。如果你理解了约束条件，就能弄清楚自己能做什么，然后快速尝试，从错误中学习，如果做错了就道歉或修正。

A lot of value in first principles thinking. If you know what you're optimizing for and you have strong first principles, then you can normally deduce the right course of action and clearly articulate that to all stakeholders, and then you should just do it. I think jobs are fake. If you understand the constraints, you can figure out what you can do and then just try to do it quickly, learn from the mistakes and apologize or fix them if you did something wrong.

你直接去做就行。谁说的来着？

You could just do things. Whoever said that?

我觉得告诉人们这个其实很解放。在很多公司，角色定义非常严格，比如产品经理做什么、设计师做什么、工程师做什么，甚至团队范围也划分得很死板。比如，我们只碰代码库的这一块，那一块我们不能碰。'直接去做'让人们感到有权做决定，跨团队协作，把事情搞定。

I think it's liberating actually to tell people this. In a lot of companies roles are very strictly defined. Like, okay, this is what the PM does, this is what the designer does, this is what the engineer does, and even team scopes are very rigidly defined. So, hey, this corner of the code base we touch and this corner we're not allowed to touch. 'Just do things' lets people feel empowered to make decisions, operate across team boundaries, and just get something done.

这感觉是一项非常重要的技能。人们称之为主动性。就是去做需要做的事情。

That feels like a big important skill to be good at. People call it agency. Just do the things that need to be done.

行动导向。所有这些描述方式都是说不要等待许可。

Bias towards action. All these ways of describing just don't wait for permission.

是的，我认为这是人生某个阶段在初创公司工作的最佳理由。对我来说，改变人生的一件事是在 Scale 只有 20 人时的工作经历。当时完全没有流程，我们要解决非常大的问题。我非常感谢 Alex 和团队其他成员，他们赋予我和其他人权力，让我们不受销售、运营、工程师职责界限的限制，自由解决问题。你拥有所有工具，面对一个雄心勃勃的棘手问题，你可以做任何必要的事情来找到好的解决方案。

Yeah, I think this is my favorite reason to work at a startup at some point in your life. One thing that was very life changing for me was actually working at Scale when we were 20 people. There was just no process and we had really big problems to solve. I really appreciate Alex and the rest of the team for empowering me and the rest to just figure things out without any boundaries for what sales is supposed to do, what ops is supposed to do, what engineers are supposed to do. Just you have all the tools at your disposal, some ambitious hairy problem statement, and you can do whatever you need to get to a good solution.

你几乎需要那种经历来培养这种技能，才能自如地这样做。很多人经历学校和大学，都是'做我们告诉你的事，然后你会得到好成绩'。你必须忘掉那种模式：好吧，我就去做需要做的事，即使别人觉得傻，我认为这是对的。

You almost need that experience to build that skill to feel comfortable doing that. A lot of people go through school and college and all these 'do the thing we tell you to do and then you will get a good grade.' You have to kind of unlearn that: okay, I'm just going to do the thing that needs to be done, even if people think it's dumb, I think it's the right thing to do.

对，完全正确。

Yeah, exactly.

好的，我其实还有两个快速问题。最后两个问题。一个是当 Claude 思考时，有这些——我不知道你是否称之为动词。这些术语是什么？

Okay, I actually have two more quick questions. Two more final questions. One is when Claude thinks, there's all these—I don't know if you call them verbs. What's the term for these things?

思考词。

Thinking words.

思考词。有趣的是这些都在源代码中泄露了。你有最喜欢的思考词吗？

Thinking words. And interestingly these all leaked in the source code. Do you have a favorite thinking word?

我真的很喜欢'manifesting'（显化）。这也是我笔记本电脑上的贴纸。

I really like manifesting. It's also the sticker that I have on my laptop.

哦，太棒了。它显然是赢家。好的，最后一个问题。我也问过 Boris。如果 AGI 可能在我们有生之年到来，那时你也许不必工作，你会做什么？你会怎么打发所有时间？

Oh, amazing. It's clearly the winner. Okay, final question. Asked Boris this too. With AGI potentially arriving in our lifetime, when you don't potentially have to work, what are you going to do? What are you going to do with all your time?

我认为 AGI 需要很长时间才能渗透到整个社会。所以，我觉得媒体实际上是在帮助世界跟上步伐。对于这之后的事，我的非严肃回答是：我可能会做很多攀岩。我可能会搬到枫丹白露，住在 10,000 块巨石中间，爬上一阵子。还有好多书我想读。我的目标是每周能读一两本书，目前大概只有 0.5 本。积压的书单相当长。我认为我们可以从历史中学到很多，还有很多我不太理解但很想弄懂的东西。比如我对物理、机器人、硬件或航空航天一无所知。有趣的话题太多了。所以，我很期待学习，即使知道 AGI 已经知道这些。

I think it will take a long time for AGI to diffuse across society. So, I think that media thing is actually just helping bring the world along. My non-serious answer for after this happens is I'll probably just do a lot of rock climbing. I'll probably move to Fontainebleau and just live amongst 10,000 boulders and climb for a bit. There's also so many books I want to read. My goal is to be able to read one or two books a week, and I'm currently at probably like 0.5. The backlog is pretty big. I think there's just so much we can learn from history and so much that I don't understand as well as I would love to. Like I don't know anything about physics or robotics or any hardware or aerospace. There's just so many interesting topics. So, I'm excited to learn, even knowing that the AGI will already know it.

Cat，这太棒了。你太棒了。两个后续问题。如果人们想联系你或关注你的动态，可以在网上哪里找到你？听众怎样才能帮到你？

Cat, this was amazing. You're awesome. Two follow-up questions. Where can folks find you online if they want to reach out and just follow what you're up to? And how can listeners be useful to you?

最好的联系方式是 Twitter 上的 @_catwo。欢迎在帖子里 @ 我，也欢迎私信。我会阅读所有私信，虽然不一定会回复每一条，但都会看。最有帮助的是告诉我们 Claude Code 和 Co-work 在哪些地方对你不好用。我们非常感谢所有的正面反馈，但我们真正需要的是边缘案例、错误、以及我们可以复现的 Claude Code 或 Co-work 失败的具体任务。因为如果你能分享给我们，并且我们能复现，那么我们就可以在下一代模型和工具中积极改进。

The best way to reach out is I'm @_catwo on Twitter. Feel free to tag me in things, feel free to DM me. I read all my DMs. I don't always respond to every single one, but I will read them all. And then the thing that is most helpful is tell us where Claude Code and Co-work aren't working well for you. We're very grateful for the amount of positive feedback, but the thing that we thrive on is edge cases, errors, specific tasks that we can reproduce where Claude Code or Co-work fail. Because if you're able to share that with us and we're able to reproduce it, then this is something that we're able to actively improve for our next generations of models and for our next harnesses.

非常酷。Twitter 上的人分享反馈从不害羞，所以继续来吧。

Extremely cool. Everyone on Twitter are not shy with sharing this feedback, so keep it coming.

是的，分享给我们——请把你们遇到的问题告诉我们。

Yes, share us—please share the problems that you're having with us.

是的，看到你们团队在 Twitter 上如此活跃并回复大家，真的很酷。所以我听到的是，这些反馈你们确实会看到并做出反应。

Yeah, and it's really cool to see all your team being so active on Twitter and responding to people. So what I'm hearing is this is actually stuff you guys actually see and react to.

是的，我们感谢大家如此投入。这给了团队巨大的能量。我们有一个用户喜爱频道，每当你们分享成功故事，我们就发在那里。每当你们分享产品问题，我们就放入反馈频道，这样整个团队就能据此采取行动。

Yeah, we appreciate everyone being so engaged with us. It gives the team a ton of energy. We have this channel of user love, and whenever you guys share a success story, we post it there. And whenever you guys share issues with our product, we put it into our feedback channel so that our broader team is able to act on it.

知道这个太酷了。谢谢分享。那么，Cat，非常感谢你来做客。

That is so cool to know. Thanks for sharing that. Well, Cat, thank you so much for being here.

谢谢邀请。

Thanks for having me.

大家再见。非常感谢收听。如果你觉得有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或写评论，这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有过往剧集或了解更多节目信息。下期再见。

Bye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.