Anthropic 的产品团队为何比其他团队都快 | Cat Wu（Claude Code 产品负责人）
How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
Guests: Cat Wu
Full transcript · Read the full conversation in order, with its original context.
Contents1 chapter
§01原文文稿 · 00:00–1:25:09§01原文文稿 · 00:00–1:25:09
我认为，要恰到好处地相信 AGI 是非常难的。为超级 AGI 强模型打造产品很容易。难的是弄清楚，面对当前的模型，怎样才能发挥出它最大的能力。
我从来没见过 Anthropic 的人以这样的速度发布产品。
我们想消除发布产品的每一道障碍。很多产品功能的开发周期已经从六个月缩短到一个月，有时甚至缩短到一天。
你在面试数百名产品经理，而且你一直觉得他们的做法完全不对。
产品经理的角色正在发生很大变化，而且变化得非常快。要构建 AI 原生产品，极其重要的一点是快速迭代，想办法让自己能够每周都发布功能。
你认为产品经理需要培养哪些正在出现的新技能？
这又回到了产品品味。随着编写代码变得便宜得多，更有价值的事情就变成了决定写什么。
今天，我的嘉宾是 Cat Wu，她是 Anthropic 负责 Claude Code 和 Cowork 的产品负责人。Cat 正处在 AI、产品和构建方式一切变化的中心，她和她的团队正在打造一款最能改变我们所有人构建产品方式的产品。她充满洞察、智慧和经验教训。这一期节目你绝对不能错过。在进入正题之前，别忘了去看看 lennysproductpass.com，那里有一大批专门为 Lenny 的 Newsletter 订阅者提供的超值优惠。下面，让我们请出 Cat Wu。（00:01:33）：Cat，欢迎来到播客。
谢谢你的邀请。
我有太多问题想问了。非常兴奋能邀请你参加这档播客。我想先让大家了解一下你和 Boris 如何一起工作。大家都认识 Boris。他那一期是这档播客最受欢迎的一期，别有压力。他创造了 Claude Code，领导工程团队，每天从手机上发出海量 PR，就像……我甚至不知道现在具体是多少了。我觉得大家没有充分认可你对 Claude Code 成功、Cowork 以及你们正在构建的一切所作的贡献。请帮助我们理解你在团队中的角色、你如何与 Boris 合作、你们如何分工。Claude Code 团队的 PMO 究竟是什么样的？
我觉得能和 Boris 共事非常幸运。他一直是很棒的思想伙伴，也是我们的技术负责人。他在很大程度上是产品愿景的提出者，擅长设定产品在三个月、六个月后的目标状态，以及产品的 AGI 版本应该是什么样。我的很多工作，就是弄清楚从今天的现状走到三至六个月后那个愿景的路径。我把更多时间花在跨职能协作上，比如确保市场、销售、财务、容量等团队都认同这个计划，确保大家朝着同一个方向努力，并且功能准备好之后不会有任何发布障碍。（00:03:00）：我觉得这种合作在很多方面都很顺利，因为我们几乎心意相通，但职责边界实际上模糊得惊人。我觉得我们有 80% 是心意相通的，剩下 20% 是一些我可能比 Boris 更在意的事情，所以由我来推动；另有 20% 的工作是他比我更在意的，就由他来推动。
本期节目由本季冠名赞助商 WorkOS 赞助。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，就会感受到整合单点登录、SCIM、RBAC、审计日志和大公司所需的其他功能有多痛苦。WorkOS 将这些交易阻碍转化为开箱即用的 API，并提供专为 B2B SaaS 打造的现代开发者平台。事实上，我投资的每一家开始向高端市场扩张的初创公司最终都会与 WorkOS 合作，因为他们是最好的。无论你是正努力拿下第一家企业客户的种子期初创公司，还是正在全球扩张的独角兽，WorkOS 都是实现企业就绪、解除增长阻碍的最快路径。它本质上就是企业功能领域的 Stripe。访问 workos.com 开始使用，或者直接加入他们的 Slack，那里有真正的工程师等着回答你的问题。WorkOS 让你可以借助令人愉悦的 API、全面的文档和顺畅的开发者体验更快地构建产品。今天就访问 workos.com，让你的应用做好服务企业的准备。（00:04:30）：在我们开始录制之前，你分享了一件事：你一直在面试数百名产品经理。如果每当有人让我介绍 Anthropic 的人、想去 Anthropic 做产品经理时我都能得到五美分，我现在已经有 300 亿美元的 ARR 了。这里是人们最想去工作的地方，所以我只能想象你要面试多少产品经理。你告诉我，你看到很多人做错了，他们对成功的 AI 产品经理需要做什么的理解是错的。谈谈你看到的情况，以及如今要取得成功，人们需要明白什么。
我认为在 AI 之前，技术变革要慢得多，所以人们可以按六到十二个月的时间跨度来规划。由于功能发布速度稍慢，当时更强调与所有合作团队协调，确保他们发布的功能能够解除你所依赖功能的阻碍，因为那时编写代码的成本很高。我认为现在有了 AI，工程效率大幅提升，模型能力也在快速进步，很多产品功能的周期已经从六个月缩短到一个月，有时缩短到一周甚至一天。因此，我们实际上需要确保产品能够非常快速地发布。（00:05:49）：这意味着，作为产品经理，不应该再那么强调确保自己的跨季度路线图与合作团队对齐，而应该更多地关注：怎样才能找到最快的方式把东西交付出去？怎样才能在产品套件里建立一个概念验证角落，让工程师或产品经理有了想法后，到周末就能把它交到用户手里？我认为，在 AI 原生产品上表现最好的产品经理，是那些能想办法缩短从产生想法到真正把产品交到用户手中的时间，并帮助定义产品开箱即用时最重要任务的人。
我喜欢你说的这一点：人们还没有理解自己需要多快地行动，也没有理解如今这份工作有多大一部分是在帮助团队快速前进。什么能做到这一点？除了能够使用最先进的模型之外，你会做什么，你的产品经理团队会做什么来帮助团队以这样的速度前进？
我认为第一件事是设定清晰的目标。由于 LLM 非常通用，这反而让我们要为谁构建产品、要解决什么问题、首要用例是什么变得很模糊。因此，我认为优秀的产品经理能够说：‘好，我们的核心用户是专业开发者。这项功能想解决的主要问题，也许是权限提示太多，人们已经感到疲劳；我们的用例是让企业中的专业开发者能够安全地做到零权限提示。’这实际上设定了一个相当清晰的目标，因为它排除了许多减少权限提示的潜在做法，让人们可以只通过一次提示完成更多工作。（00:07:42）：我认为第二件非常重要的事，是为发布这些功能找到某种可重复的流程。以 Claude Code 为例，我们实际上几乎所有功能都以研究预览的形式发布。发布时我们会清楚地标明这一点，让用户知道这是早期产品、只是一个想法、只是我们正在尝试获取反馈并迭代的东西，而且未来不一定会永久支持。这样做降低了我们发布某个东西的承诺成本。我们可以在一两周内把东西发布出来。（00:08:17）：产品经理应该做的第三件事，是帮助团队建立一个框架，让大家知道什么时候需要引入跨职能合作伙伴，以及这些合作伙伴的预期是什么。比如，我们在工程、市场和文档之间有非常紧密的流程。工程师认为某项功能已经准备好，并且已经在内部试用后，就会把它发布到我们的常青发布频道。然后，负责文档的 Sarah、负责 PMM 的 Alex，以及开发者关系团队的 Antaric 和 Lydia 就会加入进来，并在第二天完成营销公告。正因为流程非常紧密，任何工程师发布东西的摩擦都降低了，而产品经理的职责就是建立这样的流程。
PRD 在这里扮演什么角色？你说目标非常重要，比如对成功是什么、产品服务谁达成一致。你们会写 PRD 吗？只是写几条要点吗？产品经理的工作在这个世界里发生了怎样的变化？
我们做两件事。第一，我们有非常严格的指标体系，每周都会和全团队一起做指标复盘。这样做的目标，是确保每个人都深入理解业务的各个方面、我们的关键目标、目标的变化趋势，以及哪些因素会推动这些目标。第二，我们有一份团队原则清单，其中包括我们的核心用户是谁、为什么他们是核心用户。我们把这些都阐明出来，是为了让团队中的每个人都觉得自己理解业务的运作方式，理解什么对我们重要、我们愿意做出哪些取舍。这样大家就可以自行做决定，而不会觉得自己被产品经理或其他利益相关者卡住。
我喜欢这其中很多内容，因为人们一直在说，未来我们还需要产品经理吗？我们只要发布和构建就好了，我们需要工程师。
哦，我们有时确实会写 PRD。所以我认为，对于特别模糊的功能，把目标、令人愉悦的用例、当前需要修复的失败模式写成一页纸确实有帮助。偶尔也有一些项目，尤其是需要大量基础设施的项目，确实要花几个月；在这些情况下，我们仍然会写 PRD。
我想再深入了解一下，你们究竟是如何做到这么快的。我从来没见过 Anthropic 的人以这样的速度发布产品。有人制作了一份 Anthropic 的发布日历，几乎每天都有一个重大功能或产品。网上有一个问题：你们刚刚推出了，不，应该说构建了一个令人难以置信的 Mythos 模型，它目前仍处于预览阶段，因为它太强大了，人们有点害怕它的能力。你们一直在使用它吗？这是你们能够如此快速推进的原因之一吗？
我们已经以相当快的速度推进了好几个季度，所以我认为这并不完全是 Mythos 的功劳。Mythos 是一个极其强大的模型。我们确实在内部使用这些模型，我认为这让我们的发布速度有所提高，但我不认为它解释了增速的大部分原因。我认为很大一部分原因在于流程和团队的预期。我们的流程非常少。我们想消除发布产品的每一道障碍。我们想确保团队中的每个人都有能力把自己的想法从一个想法变成现实，在不到一周内推向世界，有时甚至只需要一天。
太棒了。天哪，既拥有最好的模型，又在构建产品，这种优势太酷了。
我们非常幸运，能够使用前沿模型。
天哪，这种优势太棒了：构建一个东西，然后使用它，再以更快的速度推进。太有意思了。关于 Anthropic，还有一些其他旁支问题，我想在这场对话中聊聊。Anthropic 正发生着太多事情，我非常想听听你的看法。其中一个问题是，大约一周前，Claude Code 的全部源代码泄露了。有人把它弄到了外面，我认为是有人犯的错误。你对此有什么评论？发生了什么？哪里出了问题？人们应该知道什么？
我们看到后立刻调查了这件事。我们意识到这是人为错误造成的。当时有人在和 Claude 一起编写 PR。这只是对我们发布软件包方式的一次更新，而且实际上经过了两层人工审查。因此这是人为错误造成的，我们已经强化了流程，确保未来不会再发生这种事。
这个人还在 Anthropic 吗？他们还好吗？
是的，是的。这是流程失误，最重要的是从中吸取教训，增加更多防护措施，避免再次发生。所以这正是我们一直关注的事情，而且其中大多数措施都已经调整了。
好。我的另一个问题是 OpenClaw。最近有人开始阻止用户将 Claude 的订阅用于自己的 OpenClaw。人们对此非常不满，也不明白为什么会发生这种事。这让人感觉对开源社区造成了伤害。人们需要了解这项决定背后的哪些因素？
所以，我们一直看到很多人对 Claude 有需求，也一直在努力扩展基础设施，同时让我们的 harness 更高效地使用 token，这样大家就能获得更多用量。它最初并不是为第三方产品设计的，因为第三方产品的使用模式与我们的第一方产品不同。我们花了很多时间试图找出能够提供的最顺畅过渡，所以我很高兴能说，每个人的订阅都会附带一些额度。但没错，我们确实不得不做出一个艰难决定：需要优先支持我们的第一方产品和 API，而这就是最终导致这一决定的原因。
是的。对我来说，这完全说得通。你们每月收 200 美元，却在补贴这种使用，而且基本上是无限使用。我觉得人们没有理解，企业是要赚钱的，我们也在努力实现盈利。当计算资源如此供不应求时，我们不能直接把算力送出去。所以我能理解。回到产品经理团队，Anthropic 的产品经理团队究竟是什么样？有多少产品经理？他们大致如何组织？
是的，我们有几个产品经理团队。我觉得现在大约有 30 到 40 名产品经理。首先是 Diane 负责的研究产品经理团队。这个团队负责理解客户对模型的所有反馈，然后把这些反馈传递给最合适的研究团队去处理，同时也负责推动模型发布。还有 Claude 开发者平台团队，负责维护 Claude Code 所构建于其上的 API，也会发布 Managed Agents 之类的东西，让你可以构建自己的智能体，而我们可以代表你托管它。（00:15:08）：然后是 Claude Code 团队，同时负责 Claude Code 和 Cowork 这两项核心产品。还有企业团队，帮助所有企业客户更容易采用 Claude Code 和 Cowork，工作内容包括成本控制、后端安全控制，以及确保这些企业能够非常放心、安心地使用我们的工具。我们还有增长团队，负责整个产品套件的增长。我们会和他们密切合作，推动 Claude Code 和 Cowork 的增长。我知道他们也会和其他团队合作推动 CDP 增长，也就是使用 Claude API 的人群增长。
说到增长，Amol 刚刚上过这档播客。他有一个非常有意思、但大多数人还没有分享过的洞察。人们总有一种感觉，未来我们需要更少的产品经理。为什么需要产品经理？工程师可以完成发布。他的看法是，工程师的速度越来越快，产品经理和设计师反而承受了压力，因为留给他们跟上所有变化的时间变少了。每天都有功能发布。所以他的结论是，他需要更多产品经理，因为跟上变化很难。你的看法是什么？你觉得未来会增加产品经理的招聘吗？你认为从长期来看，产品经理这个职业会发生什么？
我认为所有角色都在融合。产品经理在做一部分工程工作，工程师在做产品经理的工作，设计师也在做产品经理的工作，同时提交代码。你可以招聘更多拥有出色产品品味的工程师，或者维持工程师招聘规模不变，招聘更多产品经理来帮助指导他们的一部分工作。在我们的团队里，我们非常专注于招聘拥有出色产品品味的工程师。这样，我们就能减少发布任何产品所需的管理成本。我们团队里有很多工程师，完全能够端到端地完成工作：从在 Twitter 上看到用户反馈，到周末发布产品，几乎不需要产品团队介入。我认为这实际上是发布产品最高效的方式。（00:17:05）：所以我认为工程师和产品经理的角色正在重叠，多招聘其中任何一种人都会带来很多好处。我觉得产品品味仍然是非常稀缺的技能，只要我们觉得某个人有充分证据证明自己具备这种能力，我们几乎都会雇用他。
你的背景是工程，对吧？
是的，我做了很多年工程师。后来在加入 Anthropic 之前，我短暂做过风险投资。实际上，我们团队里几乎所有产品经理要么当过工程师，要么会在这里的 Claude Code 上提交代码。我认为这有助于建立团队信任，也让我们能够快很多。我们的设计师以前也做过前端工程师。
哇。因为这正是一个大问题：确实有某种正在出现的融合，维恩图的圆圈正在合并。对很多人来说，大问题是，如果你来自工程、产品或设计领域，哪些核心技能会最有价值？我可以想象，在 Anthropic 和 Claude Code，工程能力非常有价值。我很好奇，在其他公司，如果你有设计背景，转做产品经理会更有价值，还是说成为一名纯产品经理更有价值？
我仍然认为，关键还是产品品味。随着编写代码变得便宜得多，更有价值的事情就变成了决定写什么。这个功能正确的用户体验是什么？用户以怎样的方式体验它会最愉悦？我们会收到数以万计的 GitHub issue，要求加入各种各样的功能，需要投入大量的细心和品味，才能弄清楚哪些值得构建，以及构建它们的正确方式是什么。我认为这种能力可以来自任何背景，但我觉得这是最重要的事情。（00:18:53）：我认为，至少在未来几个月，工程背景特别有用的原因是，如果你有工程背景，就更能判断一件事应该有多难，而这通常会影响你选择构建什么。如果某件事非常容易构建，也许你不必争论，直接花一个小时做出来；但如果某件事更难构建，而且你事先知道这一点，就会知道，好吧，这会让团队付出更多成本才能把它交付出去。因此，它对确定优先级会有些帮助。
你说‘未来几个月’，是不是因为模型可能在未来几个月变得非常强，以至于你不再需要那么了解这些事情？
我认为，有价值的技能组合确实变化得非常频繁，所以很难预测几个月以后的情况。这并不是在评论我认为会发生什么具体转变，而是在说，我认为大的转变会不断发生。
所以你不是说 Mythos 会在那时发布、改变一切，以后我们就不需要了解任何工程知识了？
不，我只是说，编码能力似乎每隔几个月就会大幅提升，进而改变其他角色的价值。最重要的是具备第一性原理思维，能够判断技术环境如何变化、团队真正需要你做什么，然后主动填补那个空缺，因为工作正在变得更加模糊。这意味着，优秀的产品经理能够了解所有缺口，找出优先级最高的缺口，然后想办法学习相应技能，或者找到自己已有、可以应用于这一挑战的技能。所以我认为，当前环境看重的是那些能够身兼多职、能够在不同角色之间切换，而且对于自己做什么工作没有太强自我意识、愿意帮助团队更快前进的人。
我很喜欢这个回答。我一直在问和你处境相似的人、那些处在 AI 能力前沿并用最新工具构建产品的人一个问题：在达到超级智能之前，人类的大脑还会在哪里继续有用、继续不可或缺？我从你的回答中听到的基本是：选择要做的事情，知道市场走向，确定优先级，然后判断你构建的东西是否好、是否正确，至少先以早期版本把它推出去。这样说对吗？至少在未来几个月，人类的大脑还会在哪些方面继续有用？
我认为，人类仍然能提供模型不具备的一定程度的常识，而任何产品发布都有上千个活动部件，其中一些很小，但总有很多事情可能出错。我认为模型并不总能很好地理解所有利益相关者是谁、他们彼此的关系、他们的偏好，以及与他们沟通、让他们继续支持项目的合适场合。很多这种更隐性的常识和情商知识仍然非常有价值。当然，我们希望模型在这方面变得更好，我认为它们会做到，但目前仍然存在缺口。
作为一个人，面对这么多持续不断的变化，你是怎么应对的？你身处这场龙卷风的中心，也许那里很平静，但你是怎么跟上发生的一切的？面对我们正在经历的所有疯狂，你是怎么保持理智的？
我认为，我们团队成员仍然是那种会主动拥抱混乱的人。所以我们努力面带微笑地面对每个挑战，因为总有太多事情在发生，也总有太多风险和棘手的情况。如果你对任何事情都过度紧张，就会筋疲力尽。因此，我们真正寻找的是这样的人：他能看着一个挑战说，‘呼，这会很难，但我很兴奋要迎接它，我会尽我所能做到最好。我知道自己不会完美，但我会知道自己已经尽力，因此晚上能够安心入睡。’
这是对未来哪些技能会重要这个问题的有趣回答，因为……我忘了是谁说的，也许是 Ben Mann：现在是世界将永远保持的最正常状态。
是的，事情确实会越来越难。我觉得有很多个星期，可能周日晚上出现某个 P0，到了周一就变成 P00，周一下午又变成 P000，然后你会想：‘哇，我真不敢相信自己居然会为周日的那个 P0 如此担心。’但我认为你只能承认自己能做的事情有限，同时要睡好觉，这样第二天才能做出好的决定；还要极其严格地决定时间花在哪里、最重要的是把什么做对，并且接受有些事情可以放手。我们发布过一些产品，它们没有我希望的那么 polished，但我们的首要目标是帮助专业开发者获得能力。如果某个产品没有成功，只要它没有阻碍核心用例，就没关系，因为我们会听取反馈，在下一次发布中修复它。（00:24:17）：发布一个有 bug 的功能，以前会让我彻夜难眠，但现在我能够接受这一点，因为我知道，好吧，我们会很快获得反馈，并在下一次发布中修复它。
我想象的是那个 GIF。我觉得它可能来自《加勒比海盗》，里面有个人走下船上的一段楼梯，整艘船在他周围被摧毁，但他非常镇定，只是悠闲地走下楼梯，周围一切都在坍塌。这很有意思，因为我遇到的每个 Anthropic 人都非常镇定、非常乐观。是的，我觉得一个很有意思的洞察是：保持镇定和乐观，而不是只会说‘天哪，一切都疯了，都失控了。’
是的，如果你没有这种状态，就会很快筋疲力尽。我觉得我们也倾向于招聘在这个行业里工作了一段时间、经历过许多起起落落，并且很清楚什么能给自己带来能量、如何长期保持能量的人，这对我们帮助很大。
很有意思。我想问的是，既然这些角色正在变得模糊，工程师变成产品经理，每个人的狗都是猫，每个人又都是所有人，那么我们会在这个世界里失去什么？我们会失去职业阶梯和清晰的职业路径吗？会失去设计一致性、代码质量吗？这里可能有一些弊端。你发现哪些事情是‘好吧，为了更大的目标，我们正在牺牲它’？
我们牺牲了产品一致性。过去，编写代码的成本很高，所以你会仔细规划产品套件中的一切：每个产品如何相互关联、每个产品的具体用例是什么、它们如何整合，而且基本上每个用例都会对应一个产品。现在，随着 AI 快速发展、需要测试的想法越来越多，我们有时确实会出现功能相互重叠的情况。很多时候，这是因为我们内部很喜欢两种形态，希望让外部用户告诉我们哪一种更好。但对新用户来说，这意味着他们可能不知道，完成某件事的最佳路径是什么。我们需要做更多教育，帮助人们理解核心功能是什么，以及使用这些功能的最佳实践。（00:26:41）：我认为这是发布大量功能的代价。我觉得用户也会觉得很难跟上最新进展。传统产品经理通常每月或每季度发布一个功能，因此用户很容易理解：我每月关注一次就行，也就能学到一些新东西；就算六个月不看也没关系，不会觉得自己错过了什么。我认为，对于这些智能体工具，不只是 Claude Code 和 Cowork，而是整个生态系统，人们会觉得自己需要每天查看 Twitter，了解绝对最新的东西。我认为，我们还可以做更多事情，让人们不再觉得自己处在一条越来越快的跑步机上。我希望人们打开这些工具后，工具本身就能教会他们想知道的东西，让他们感觉自己可以更从容地跟上。
是的。我前几天看到你们发布了一个非常有意思的功能。我觉得它叫 /powerup，基本上会带你了解使用 Claude Code 的各种酷方法，以及几乎所有最佳实践。这是不是你说的这种方向？
是的，完全如此。过去我们其实不想做类似 powerup 的东西，因为我们觉得产品应该足够直观，用户不需要经过任何教程。但随着时间推移，我们意识到功能实在太多了，而且人们对内置入门体验的需求非常强烈，所以我们稍微偏离了原来的原则，不设置入门流程，并添加了这个功能。因为有太多用户想知道：这里有一百个功能，我绝对需要使用的十个是什么？所以我们就把它做出来了。
是的，这是一个非常奇怪的世界。Anthropic 在 B2B 企业领域取得了很大成功，而传统上，企业产品不会发布一大堆东西，可能每季度发布一次，结果你们却几乎每天都有新东西。顺着这个话题，Anthropic 一路走来的表现简直超乎想象。Anthropic 刚开始时远远落后。Amol 分享过，当时它是资金最少的公司之一，没有分发渠道，也不是最早入场的公司；OpenAI 遥遥领先，人们觉得 Anthropic 长期来看根本不可能有机会进行有意义的竞争。现在你们却表现得非常出色，击败了最大的公司和团队。增长实在太惊人了，一个月就增长到 110 亿美元 ARR。等这一期节目发布时，可能还会更高。你身处其中，哪些因素让 Anthropic 能够如此成功、后来居上并取得这样的成绩？
最重要的两件事，第一是统一的使命。这一点的重要性很难用语言表达。我们招聘那些最在意为全人类带来安全 AGI 的人，而在决定整个产品组织应该专注发布什么时，我们实际上会经常引用这一点。因为我们把这一使命置于任何单独的产品线之上，所以能够非常快速地做出跨越整个组织的决定，并以统一的方式执行。我认为，这是我在我们这个规模的公司里从未见过的事情。
为了确保我理解准确：基本上，你们最重要的使命是安全、对齐，确保 AI 对世界有益，而你是说，仅仅拥有这样一个清晰的使命，就能让决策更容易做出？
如果有两个相互竞争的优先事项，我们会讨论哪一个对 Anthropic 的使命更重要。这样就更容易决定优先哪个，然后所有人都会支持我们做出的选择。所以有时这意味着，我们想在 Claude Code 上发布某个东西，但另一件事更重要，于是我们会降低这个发布的优先级，等到以后再做。
这件事非常有意思，因为我认为它解释了你们与另一家名字听起来像 OpenAI 的公司之间的区别。那家公司做了很多不同的事情，而我从你这里听到的基本是：好吧，我们不会推出社交网络，也不会推出有趣信息的资讯流，因为那与这一使命不一致。这让 Anthropic 保持了专注，而这似乎是成功的核心要素。
我理解使命时，想到的是把 Anthropic 的目标置于任何单独的组织或产品之上。因此对我来说，第二件我们非常擅长的事是专注。我觉得使命和专注略有不同。使命意味着，团队愿意牺牲自身的目标和 KR，来服务 Anthropic 的目标和 KR，而且大家都很乐意做出这些取舍。极端一点的例子是，如果 Claude Code 失败了，但 Anthropic 成功了，我会非常高兴。整个团队都非常愿意遵循这条思路来做决定。
我不知道你能不能深入谈谈，但你觉得 OpenClaw 的决定是否也是这种思路的一部分：好吧，这件事没有推进 Anthropic 的使命，我们需要停止，因为它没有按照我们希望的方式运作？
我认为，对 Anthropic 来说，最重要的事情之一是扩大我们能够触达的用户数量。我们实现这一目标的方式之一，是通过 Claude 订阅和我们的第一方产品。因此，我们非常希望加倍投入这件事，但这有时会以牺牲第三方产品为代价。
我们一直在谈 Claude、Cowork 以及所有这些东西。我想确保大家理解，同时也很好奇你是如何使用这些工具的。这里有 Claude Code、Claude 桌面版／网页版，还有 Cowork。怎样才能最好地理解什么时候该使用哪一个？你什么时候使用这三个产品中的每一个？
如果我刚要开始一个一次性的编码任务，而且想使用所有最新功能，我通常会在终端里使用 Claude Code。CLI 是我们最初的产品界面，也是功能通常最先落地的地方，因此它是所有工具中最强大的。我要开始一个或几个任务时，通常会使用它。需要进行前端工作时，我认为桌面版特别出色，我很喜欢使用我们的预览功能。（00:33:22）：如果我在构建一个网页应用，通常会同时使用 Claude Code 和桌面版。我会在右侧打开预览面板，这样在和 Claude 聊天时，就能实时看到正在制作的网页应用。对于想要更图形化体验的人来说，它也非常好用。终端对非技术人员来说可能很陌生。你的电脑上会弹出一堆吓人的提示，你也不能像在几乎所有其他产品中那样随意点击操作。因此，有很多人就是不习惯使用终端。如果你属于这种情况，我强烈建议你试试桌面版的 Claude Code。桌面版也很适合一眼查看所有正在发生的事情：你能在桌面版里看到 CLI 终端会话、其他桌面会话，以及你在网页和移动端启动的会话。所以它是一个统一的控制中心，可以查看自己的所有任务。（00:34:16）：我认为网页版和移动端的好处是，非常适合在外出时启动任务。CLI 和桌面版都要求你使用本地笔记本电脑，这很受限制，因为有时你出门在外、接触大自然、出去散步，没有打开笔记本电脑；我数不清见过多少人出门时还把笔记本电脑打开，用手机给它提供网络连接。也就是说，我们缺少一个能解决这种需求的产品。对我来说，移动端让你可以在外出时启动这些任务，不必到处带着笔记本电脑，也不必确保无论在哪里都打开电脑。
我喜欢这一点。我在飞机上见过有人这样做。现在这已经成了一个梗：我得让这个智能体跑完，不能关掉它。我需要 Wi-Fi。
没错。至于 Cowork，我认为它解决的是这样一类问题：每个人都会做很多最终产出不是代码的工作。比如把 Slack 或收件箱清到零，或者为即将到来的客户会议制作幻灯片，或者快速写一份文档，说明某个功能的目标是什么、发布计划是什么。所有这些任务产生的输出都不是代码，而 Cowork 最适合处理它们。所以我在心里这样区分这些产品：如果我构建的东西最终输出是代码，我会使用 Claude Code、桌面版，或者移动端的 Claude Code；如果输出不是代码，我就会使用 Cowork。
人们只是低估了 Cowork 取得的成功。它增长得非常快，我觉得人们可能仍然不明白它是做什么的。你能不能结合自己作为产品经理的工作，举几个用例？你有哪些非常有意思、也许出乎意料的使用 Cowork 的方式，可以帮你节省时间、完成更多工作？
如果你开始使用 Cowork，真正需要做的第一件事，是连接所有与你的角色相关的数据源，因为 Cowork 只有在获得所需的全部上下文后，才能很好地为你整理输出。对我来说，这意味着我连接了 Google 日历、Slack、Gmail 和 Google Drive，这样它就能灵活地寻找相关上下文、提问、调取讨论串，结果质量会大幅提升。我使用它做的事情包括：昨晚，我们即将举办 Code with Claude 大会，我要在那里发表几场演讲。（00:36:54）：其中一场演讲讲的是 Claude Code 如何从助手转变为完整智能体。我想在这场演讲中展示我们已经发布的、推动这一转变的所有产品，同时找出内部人员取得过哪些成功，可以把它们用作演示。我连接了 Google Drive，也连接了 Slack。我们的产品营销负责人 Alex 写了一份草稿，列出了他认为我们应该涵盖的要点。（00:37:33）：于是我把这些全部输入 Cowork，告诉它我想讲述的叙事。它实际上运行了一个小时：查看 Twitter，了解我们发布过什么；查看我们的常青发布频道；查看 Claude Code 公告频道，团队会在那里发布他们如何从 Claude Code 中获得最大价值的演示。它把所有这些内容综合起来，生成了一份 20 页的幻灯片，我今天早上醒来后看了看，觉得相当不错。确实有一些地方需要调整，所以我还要给它一轮反馈。我喜欢幻灯片上的文字极少，而它写得有点太多了，但它的速度仍然比我自己能完成的快得多。因为 Cowork 可以访问我们完整的设计系统，做出来的东西确实像 Anthropic 的设计师完成的。你看到视觉效果时会想：‘哇，这精致度太高了。’（00:38:29）：这类事情的速度快得多。制作这套幻灯片本来要花我几个小时，但它反而给我生成了一份质量相当好的草稿，让我可以专注于确保接入其中的演示足够精彩。
这对产品经理来说听起来像梦想成真：制作幻灯片太让人烦了。
太慢了。
而且我很期待大家在你展示时看到这份幻灯片。这份幻灯片会公开于世。当然，它不是一次生成的最终版本，而是你迭代过的。为了帮助大家自己尝试，第一步是连接他们的……你刚才说什么？Slack。你还建议他们连接什么？
Slack、Google 日历、Gmail、GDrive。你应该连接沟通工具，以及存放团队关心的事情、你关心的事情和你正在处理的事情的事实来源的地方。
好。然后，你大致输入了什么提示词来生成这份幻灯片？
所以我只是写道：‘为 Code with Claude 大会制作一套幻灯片。这是我们的产品营销负责人建议涵盖的内容。这是我目前制作的、但不喜欢的草稿。这是我手动制作的、也不喜欢的版本，不过我附上了链接。你能不能先创建一个详细的提纲？另外，确保它不要与主题演讲重叠太多，因为主题演讲更重要。’然后 Claude 读了我发给它的大量链接，创建了一份提议的提纲。接着我读完它的提议，以及我为可能涵盖的内容生成的各种想法，自己决定最终幻灯片里应该放什么。我认为，这就是产品经理如今仍然扮演的角色。（00:40:07）：Claude 是一个很棒的头脑风暴伙伴，能够极快地综合海量信息，把所有可能性呈现给你，但产品经理仍然要做最后的决定：好吧，最终产品里应该有什么？在这个例子中，我最后决定演讲要涵盖这样一条发展路径：从让本地任务取得成功，到让每个 PR 都通过，再到帮助工程师提交更多 PR；对于每一步，还要决定哪个演示最有说服力。确定提纲后，Cowork 就运行了几个小时，完成了整套幻灯片。
这太棒了。这是工作中一个不用再做的部分，真是太棒了。而且听起来，你实际上是在和一位幻灯片设计师对话，它不仅知道你做过什么，还能让内容真正符合你的需求，而不只是把外观做得漂亮。你是怎么处理设计系统这一部分的？它如何知道 Anthropic 的设计系统？
我为这件事做的是：我们实际上已经有一套用于所有对外活动的标准化幻灯片。所以我只是让 Claude 访问这套幻灯片，它就能看到我们使用的颜色、字体、各种可能的——怎么说呢——幻灯片格式，因此它有 20 张这样的示例幻灯片。
所以举个例子，我明白了。你上传‘这是我们的模板，请基于它制作’。对。
如果你的幻灯片格式保存在 Figma 里，也可以连接 Figma MCP，它就能把格式拉进来。
顺着这个话题，我总是很好奇，作为 Anthropic 的产品经理，你的工具栈里有什么？显然有 Claude Code、Cowork 以及所有 Anthropic 工具。你还使用什么？还有哪些工具……你提到了 Slack。还有别的吗？
我的工具栈主要是 Claude Code、Cowork 和 Slack。Anthropic 基本上运行在 Slack 上。我觉得它是我们公司的核心操作系统。日常工作中，我大概会用 30% 的时间推动 Cowork 和 Claude Code 能做到的边界，这样我就能非常清楚地知道我们不擅长什么；我也会花很多时间和模型对话，理解它为什么会犯这些错误。我们实际上有很多内部工具。我认为，Claude Code 为整个公司真正解锁的能力之一，是大幅降低了制作任何定制应用的门槛。因此，我们看到个性化工作软件激增，人们正在为定制用例构建软件，而不是使用那些与用例并不完全匹配的工具。
我想听得更多。能不能举一些例子？你自己或其他人构建了哪些非常受欢迎、非常有用的东西？
Claude Code 团队的一位销售人员发现，自己一直在反复制作相似的幻灯片，于是他用核心 Claude Code 幻灯片的示例制作了一个网页应用。我们知道这些示例效果很好，比如 101、201 和 Claude Code 精通课程。然后，他可以输入特定客户的上下文，应用会从 Salesforce、Gong 和其他笔记中提取信息，从而为特定客户定制幻灯片。它会提取类似这样的信息：这个客户正在使用 Bedrock、Claude for Enterprise 或 Console，这会影响他们能使用哪些功能；或者，这个客户关心软件开发生命周期中的代码审查阶段，于是我们会在幻灯片中加入一页介绍代码审查功能；又或者，这个客户需要符合 HIPAA，或需要某些安全控制，于是我们会确保在他们的幻灯片中加入一两页相关内容。（00:44:14）：例如，如果客户使用 Vertex 或 Bedrock，不想使用 Claude for Enterprise，我们就会删掉一些只适用于 Claude for Enterprise 的幻灯片。通常，这种工作需要手动完成，可能要花 20 到 30 分钟。因此，人们要么花时间做它，要么干脆不做，使用通用幻灯片。有了这个应用，只需几秒钟就能得到一套定制幻灯片。
Slack 有一点很有意思：这是一个没人想要……似乎没人想自己创建的工具。Slack 只是不断胜出，而你把它描述成许多公司的操作系统，这一点很有意思。人们把 Salesforce 说成 SaaS，觉得我们不再需要 SaaS 软件了，要自己构建。Slack 却像是一种持久的工具，没有人想要尝试与它竞争、构建一个更好的版本。
我认为它是相当重要的通信基础设施，而且它非常擅长完成帮助每个人获取实时更新这一核心任务。
是的，人们喜欢批评 Slack，但它真的很擅长自己想做的事，而且最前沿的团队都离不开它。这很有意思。
是的，我也很喜欢他们让 Slack 变得很容易定制。因此我们很喜欢制作 Slack 机器人，这种可改造性意味着我们可以按照自己的方式与 Slack 集成。所以我很感谢 Slack 在这方面所做的工作。
是时候买 CRM 股票了。（00:45:40）：我非常高兴向大家介绍本季支持赞助商 Vanta。Vanta 帮助 Cursor、Ramp、Duolingo、Snowflake 和 Atlassian 等超过 15,000 家公司赢得并证明客户信任。得益于 AI，团队正以前所未有的速度构建和发布产品，但因此引入到产品和业务中的风险也达到了前所未有的水平。我接触到的每一位安全负责人都感受到保护组织、业务，更不用说客户数据的压力正在增加。由于事情发展太快，他们一直在被动应对、猜测优先级，不得不凑合使用过时的解决方案。Vanta 通过超过 35 个安全与隐私框架自动化合规与风险管理，包括 SOC 2、ISO 27001 和 HIPAA。这能帮助公司快速实现合规并保持合规。信任比以往任何时候都更能决定企业的成败。请访问 vanta.com/lenny 了解更多。作为本播客听众，你可以获得 Vanta 1000 美元的折扣，网址是 vanta.com/lenny。（00:46:49）：好。你刚刚谈到不同团队如何使用 Claude Code 和 Cowork 开展工作。除了工程团队之外，你还发现哪些团队在使用？假设工程团队消耗的 token 最多，但如果不是这样，那就很有意思了。现在消耗 token 第二多的职能是什么？
应用 AI 团队非常擅长推动 Claude Code 和 Cowork 能力的边界。我们的应用 AI 团队有很多时间在帮助客户采用 API，所以有时他们会代表这些客户制作原型，而 Claude Code 让这件事比过去快得多。他们还需要管理大量客户沟通、客户来信、历史上下文、通话记录，因此他们既重度使用 Cowork，也重度使用 Claude Code。
为了理解应用 AI，它是不是一种面向客户、类似工程的角色？大多数人会怎样描述应用 AI 团队正在做的事情？
是的，他们帮助客户在整个公司采用最新的 API 和模型功能，既用于驱动客户公司的产品，也用于提升内部效率。
明白了。所以它有点像客户成功、进入市场，类似部署工程的角色。
没错。它就像一个非常技术化的市场拓展人员。
明白。好，太棒了。所以你的意思是，它可能是使用 token 第二多的组织？
是的。我们还看到他们在不断拓展 Cowork 的能力边界。比如，很多人会负责多个客户，在忙碌的日子里一天可能有五到十场客户会。因此，他们经常在前一天晚上让 Cowork 总结：第二天即将举行的所有客户会议是什么？客户提出过哪些要求？他们最关心什么？过去会议有哪些行动项？Cowork 会整理出一份档案或简报，列出他们参加下一场会议前需要了解的事情。Cowork 还可以研究答案。如果客户问：‘功能 X 什么时候发布？’Cowork 可以帮助应用 AI 人员在 Slack 中查找最新预计时间，把它加入笔记，这样在客户通话期间，应用 AI 人员掌握的就是最新信息。这些只是人们为自己构建工作流，然后与团队其他人分享的例子。
很酷。最近经常出现一个相关的问题或趋势：人们使用 AI 的 token 花费超过了自己的工资，使用 AI 的成本甚至超过了他们赚到的钱。Anthropic 内部有没有一些数字，比如工程师每月或每天大约消耗多少 token，或者产品经理之类的？
我们很清楚，随着模型变好，人们会把更多任务委托给它，也会在 Claude Code 和 Cowork 之类的工具中花更多时间。因此，每当模型升级或产品有重大改进时，我们都会看到每名工程师或每名知识工作者的 token 成本增加。我认为这仍然远低于普通工程师的工资，但我们看到这一比例在不断上升。
这很有意思……我们之前谈到，你们能够使用最前沿的模型，这是在 Anthropic 工作的另一个优势。我相信你们基本上拥有无限 token，可以随便用，对吗？
我们可以使用很多 token。有些人确实会遇到限制，所以——
好，原来有限制。好吧，Boris，关掉它。好有意思，拥有最先进的模型会带来这么多优势。这是一个非常有意思、开始发挥作用的飞轮。
我认为，我们也非常相信要赋能内部团队，让他们尽可能快地构建产品；同时，我们相信每个人都理解服务这些模型真正需要多少容量，也相信团队会负责任地使用 token。因此，浪费 token 是非常不受欢迎的，但我们相信个人能够自行判断。
太棒了。回到产品经理的角色，我们之前稍微谈过这一点，但我觉得大家会很有兴趣听。我的问题是，如今 AI 公司招聘产品经理时，你认为产品经理需要培养、或者你最看重的正在出现的技能是什么？
我认为最难的技能，是能够定义一个月后的产品应该是什么样。我认为，在这段时间里，模型能做什么以及用户行为会如何变化，都存在很大的不确定性。但优秀的产品经理能够根据用户如何突破现有产品的限制，看到其中的模式；最优秀的产品经理能够感知这些模式，设定方向，稳步执行，并在模型能力远好于或远差于原先预期时调整路径。我认为，要恰到好处地相信 AGI 是非常难的，因为每个人都能看到这样一个未来：模型极其聪明，几乎什么都能做。这样一来，你实际上不需要多么复杂的产品，甚至又可以只有一个文本框，告诉模型你想要什么；模型足够聪明，可以添加完成任务所需的任何工具或集成。它知道自己何时不确定，也能提出澄清问题。（00:52:45）：为超级 AGI 强模型打造产品很容易。难的是弄清楚，面对当前的模型，怎样发挥出它最大的能力？怎样帮助用户走上黄金路径？怎样引导用户利用模型的优势、弥补它的弱点？这种技能相当稀缺。
那要如何培养这种技能？只是使用每个模型吗？基本上，是理解每个模型的局限？你之前谈到品味，也就是理解模型可能做什么、擅长什么、不擅长什么，以及这些能力发生了怎样的变化？
我认为需要花大量时间与模型对话、使用模型。我很喜欢做的一件事，是让模型反思自己的行为。有时我注意到模型做了某件出乎意料的事，比如模型修改了前端并运行了测试，却没有真正使用 UI。这时，让模型反思自己为什么会这么做非常有用。它有时会说：‘系统提示词里有些东西令人困惑’，或者‘我没有意识到前端验证是这项任务的一部分’，或者‘我把验证委托给了这个子智能体，但子智能体没有做测试，而我没有检查它的工作。’很多时候，只要对模型为什么做出那个决定保持强烈好奇，就能发现是什么误导了它，从而修复 harness，弥合这一缺口。（00:54:31）：另一件有帮助的事，是找出你最信任、能够准确反馈模型情况的用户。通常有少数几个人比其他人更擅长说明某个具体模型或模型与 harness 组合为什么好。很多人会给你反馈，但并不是每个人的反馈都同样有依据。因此，找到一组你信任的五个人，对于获得非常快速的反馈很重要。我认为第三件有用、但不是所有人都喜欢做的事，是构建评测。你不需要构建数百个评测，它们才会有用。只构建十个高质量评测，就足以帮助团队量化目标是什么、朝着目标取得了哪些进展，以及还缺少什么。因此我认为，评测是一件被低估的事，更多产品经理和工程师应该参与。
我们已经多次谈到评测。有一种趋势是，评测的编写就是产品管理的未来，因为它本质上回答了‘成功是什么样的’。好，那我来具体定义它，然后我们就知道了。你觉得自己有多少时间花在编写评测上？
评测的重要性在一定程度上取决于你正在做的功能，或者你想解决的问题。我们团队里有很多人确实会花大量时间做评测。我们有一个小团队，与研究团队密切合作，更准确地理解 Claude Code 的行为，找出最大的改进空间，并尝试非常具体地衡量它们。我个人会在某项功能需要更多产品定义时参与评测，最终通常会得到这样的结果：‘这是我做的五个评测。这是运行它们的方法。这些评测成功了，这些没有成功，这是我用来提高成功率的提示词。’不过，这很大程度上取决于具体功能。不是每个功能都需要评测，但像记忆这样的功能从评测中获益很大。
你提到有些人非常擅长评估模型，这一点很有意思。它几乎就像是对人的评测：他们能理解模型在哪些地方表现突出、哪些地方可能不足。有没有什么人是你想特别表扬的，而且非常擅长这件事？
我认为有两类人特别厉害。第一位是负责塑造 Claude 性格的 Amanda。这是一个非常难的角色，因为任务极其模糊。即使是编码也更容易，因为你可以验证是否成功；而塑造性格需要非常坚定地理解 Claude 应该成为谁。我认为她不仅拥有塑造性格的惊人能力，也非常擅长表达目标是什么、性格应该是什么、成功和失败分别是什么样。另一群我非常信任的人就是 Claude Code 团队。（00:57:46）：我们经常一起吃团队午餐。每当测试新模型时，最快获得反馈的方法之一，就是在午餐时逐一问每个人：‘你对这个模型的感觉是什么？’我们经常得到这样的反馈：‘好，这个模型没有完整解释自己的思路，太突然了’，或者‘这个模型特别喜欢写很多记忆，但我们不确定这些记忆质量高不高’，又或者有人注意到：‘这个模型很喜欢自我测试，这很好’，或者‘这个模型自我测试得还不够。’这些反馈会告诉我们要查看哪些数据，以验证这是不是更大的模式。我们有大量数据，但提取洞察非常困难，因此这组人的反馈能帮助我们确定要测试哪些假设，然后我们就能提取数据进行验证。
你提到 Claude 的性格，这让我想到我曾在播客中采访过联合创始人 Ben Mann，他谈到 Claude 的性格、宪法是 Claude 极其重要的一部分。后来我才意识到，至少在 OpenClaw 这件事上，人们难过的原因之一，是你的 Claude 的个性……因为 Claude 的个性非常出色、有趣、耐人寻味，不像其他模型。Ben 的说法是，个性正是 Claude 能够在这么多事情上表现出色的原因。它看起来像一个无关紧要的小事：好吧，它会很有趣、很有意思、说话方式很有趣；但它其实是 Claude 成功的核心。对于你所说的性格和个性为什么如此关键，有没有什么人们可能不了解的地方？
回想一下你共事过的所有人，总有一些人会让你觉得：‘我真的喜欢他们的能量，我真的喜欢他们的氛围。’人们谈到 Claude 和 Claude Code 时，这正是最常提到的事情之一：他们真的喜欢 Claude，因为 Claude 轻松有趣，同时在完成任务时又极其自信。人们很喜欢 Claude 的低自我，它不会自负。如果你告诉它：‘嘿，你把这件事做错了。’它真的会道歉，说：‘糟糕，谢谢你告诉我。让我修好它，我们一起解决。’它也非常积极。如果你觉得：‘这项任务无法完成，我不知道从哪里开始’，Claude 会说：‘好，没关系。我认为我们应该采取这些步骤。你想让我替你开始吗？’（01:00:28）：我认为，优秀 Coworker 的一部分特质就是这种积极性、偏向行动的倾向，以及给你真诚反馈的能力，而不只是对你说的每件事都表示赞同。所以我们努力把这些特质注入 Claude，因为我们认为这会让合作变得愉快得多。
我想回到一个话题。你说过，每当新模型发布，你经常需要重新审视已经构建的东西。这很有意思，也可能很令人沮丧：‘天哪，又要重新发布这个东西，现在我得重新思考它。’谈谈你们多久会因为新模型而回头重做几个月前发布的产品。
我们因新模型做出的很多改变，是移除不再需要的功能。很多时候，我们给产品增加功能，是因为模型还不能自然地完成某件事，所以这些功能只是模型的拐杖。经典例子就是待办清单。Claude Code 刚发布时，用户会让它处理较大的重构任务，Claude Code 会说：‘好，我需要修改这 20 个调用点。’然后它改了其中五个就停下来了。于是我们想：‘好，怎样才能强迫它记住这 20 个都要完成？’我们团队的 Sid 说：‘如果我们想想人类会怎么做呢？人类会列出所有需要修改的东西。就像在 VS Code 里，你会查找所有调用点，它们会在左侧列成清单，然后你会逐个处理并全部替换。我们怎样给 Claude 这样的工具？’（01:01:55）：于是他添加了待办清单，我们发现有了它，Claude 确实能修复这 20 个调用点。但后来随着 Opus 4 和后续模型发布，我们意识到不需要强迫它使用待办清单，它会自然地使用自身能力。对于早期模型，我们必须不断提醒它：‘你完成待办清单上的所有事情了吗？完成所有待办事项之前不能结束。’而对于后来的模型，即使没有提示词，它也会自然想到要完成待办清单上的所有事情。如今，待办清单作为用户功能仍然很好，因为你可以更清楚地看到 Claude 正在处理什么。但说实话，它现在已经是产品里被大幅弱化的一部分，模型可能使用它，也可能不使用。要让模型进行彻底修改，它已经不再是必需的。
我忘了是谁在播客里说过，模型会把你的 harness 当早餐吃掉。我从这里听到的基本是：随着时间推移，你们会移除那些不得不加在模型之上的东西，因为它当时没有按照你们希望的方式运行。模型越来越聪明后，完成你想让它做的事情就变得越来越简单。
是的，模型每变聪明一次，我们就能移除很多提示词干预。实际上，每次发布模型时我们都会这样做：通读整个系统提示词，然后反思每个部分：模型真的还需要这个提醒吗？如果不需要，我们就删掉。新模型解锁的最令人兴奋的事情，是全新的功能。我们一直在用早期模型测试许多功能，但准确率不够高，所以不想发布。其中一个例子是代码审查。我们尝试过几次构建代码审查产品，也曾发布过更简单的代码审查版本，也就是过去的 /codereview 命令。直到最近的模型，我们才觉得：好，这个代码审查太好了，工程团队依赖它在合并 PR 之前通过代码审查。（01:03:58）：我们一直梦想 Claude 能成为可靠的代码审查者，让我们有信心认为它能发现大多数 bug。直到 Opus 4.5、4.6 和 Sonnet 4.6，我们才觉得，现在可以同时运行多个代码审查智能体，遍历整个代码库，并综合出工程师在合并前需要处理的真实问题。这是最新模型解锁的一项新能力。
这是播客中另一个很常见的趋势：构建一个可能要到未来六个月才会实现的东西，处在‘差不多能运行’的前沿；然后模型追上来，它就会成为一个很棒的产品，而你会领先所有人。
是的，构建目前还不一定能运行的产品非常重要，这样你就能知道：要让这个产品运行起来，还缺什么？然后有了最新模型，你可以把它直接替换进已经做好的原型里，看看这个新模型是否弥补了那个缺口。
关于 Claude 和 Cowork 的愿景，你能谈到它们将走向哪里？我猜测你不想透露太多目标，但现在感觉有许多很棒的功能正在叠加：任务派发、手机控制、各种移动应用功能。长期来看，理解这些东西的愿景有什么方式？
我们用构建模块来思考这件事。对于 Claude Code 和 Cowork，核心构建模块都是让单个任务成功。你想产出某种结果，于是给它一段提示描述。它能否持续地产出可接受的结果，让你可以合并或分享给同事或外部受众？所以任务是核心构建模块。模型变得更聪明后，任务成功率会大幅提高，然后我们看到人们开始同时执行多个任务。多 Claude 曾是 2025 年底的一件大事，此后这种趋势还在增长。因此我们的理解是：很好，一个任务已经能运行了，现在你可以同时做六个任务。模型变得更聪明后，我们的推演是：下一步也许你会同时运行 50 个 Claude，或者数百个 Claude，那么我们需要构建什么基础设施来支持这种规模？（01:06:30）：到那时，你可能已经不会再把所有东西都在本地电脑上运行，因为内存根本不够。所以我们在思考，怎样让你更容易管理这些任务？它们可能会在远程运行。我们怎样设计界面，让你作为人类知道哪些任务需要查看？怎样确保智能体充分验证自己的工作，让你看到任务显示完成时，可以非常快速地验证，并完全相信它已经按照你的规格完成？怎样确保这个过程能够自我改进，让你发现某项任务没有达到要求时，可以给它反馈，而模型在今后的每次运行中都知道要吸收这条反馈，从此不再犯同样的错误？这就是我们正在带领用户走过的演进路径。
有很多人在听，包括很多产品经理、也许还有很多创始人和其他跨职能人员。很多人担心自己的角色，以及职业生涯的未来。对于那些不仅想在这个高度由 AI 驱动的世界转型中生存下来，还想真正取得成功、在未来蓬勃发展的人，你有什么建议？有哪些事情是人们需要听到、需要去做的？
我认为，AI 给了每个人比过去大得多的杠杆，所以我会建议你：每当发现自己重复做某项手动任务时，就想想如何使用 Claude Code、Cowork 或其他 AI 工具来自动化它。大多数人的工作都有自己非常喜欢的创造性部分，也有非常讨厌做的繁琐部分。我认为 AI 的美妙之处在于，它可以替你完成那些繁琐的部分。它能从你每次执行手动任务的过程里学习，然后进行泛化并自动运行，这样你就可以专注于创造性部分，也就能完成比过去多得多的工作。（01:08:32）：所以我对大家最直接的建议是，找出可以交给 Claude 的重复性部分，不断迭代这些自动化流程，直到成功率非常高。然后思考：我还能为团队、产品或公司做什么，是大家此前没有余力接手的？或者，那个你一直认为公司应该做、却始终没有时间做的个人项目是什么？如果 AI 能处理苦差事，你现在就多出了过去可能没有的 20% 时间。所以我的建议是拥抱这些工具，把自己不想做的工作交出去，弄清楚它如何加速你；这样一来，你就能完成多得多的事情。
你刚才分享的内容中有一个核心点，我完全同意：找出可以用 AI 解决的问题。所有这些工具都有巨大的潜力，但对很多人来说，最难的只是‘我到底应该做什么？’你这里说的是，关注自己经常做、可以自动化的事情，也关注那些一直萦绕在脑中、却没有时间做的想法。基本上，核心建议就是为自己解决一个问题。
没错。我还建议听众把自动化从‘这是个很酷的概念’推进到‘它实际上 100% 有效’。有时我看到用户尝试自动化某件事，把准确率做到 90% 或 95% 就放弃了。如果自动化不是 100% 有效，它其实就不算自动化，而最后的 5% 到 10% 确实需要更多时间。此外，构建自动化往往比你亲自完成任务慢得多。我建议听众投入这段时间，明确一个你真正想做到 100% 的自动化流程，付出努力教会 Claude 你的偏好，给它反馈，让它改进技能，达到 100%，这样你才能真正依赖它。95% 有效的自动化其实没有多大价值。
我对此非常有罪恶感。这对我来说真是很好的建议。
我也有同样的问题。我一直在教 Cowork 帮我把 Gmail 收件箱清到零，但这件事非常耗时，而且你可能也已经意识到，它绝对还没做到。
有意思的是，我想到的正是这个。我设置了一个工作流，每次收到邮件时，它都会寻找那些像垃圾邮件一样的内容，比如‘嘿，我能来上你的播客吗？’或者‘那这个怎么样？’之类的东西。我总觉得‘我没时间处理这些’，于是把它们归类到一个叫 Spammy 的文件夹里。它有 95% 的时候都做得很好，但有时会出现‘哇，我错过了一封邮件，因为它被放进去了’的情况。所以这给了我很好的推动：我要处理这件事，把它做到完美。
是的，我们也在努力让定制这些命令的流程变得容易得多。现在我觉得你必须了解太多概念：要知道如何定义一个技能，知道如何使用这个技能并给它反馈，还要知道如何告诉 Cowork 根据你提供的所有反馈更新技能，然后还要知道去哪里查看技能，确认反馈是否按照你的期望被纳入。让这个流程真正无缝、不让人觉得痛苦，也是我们的工作。
太棒了。Cat，在我们进入非常令人期待的闪电问答之前，你还有什么想分享的吗？还有什么想留给听众的吗？有没有什么想再次强调、但我们还没谈到的？
我看到很多人在玩 AI、构建原型应用、试着构建工作流。我真的希望大家去构建自己每天都会实际使用的应用，因为我认为只有通过这种使用，你才能真正获得价值。如果你构建了一个不能帮助自己完成更多工作的原型应用，那么 AI 实际上并没有给你的一天增加价值。
而且，当你只是一次性生成了某个东西，觉得‘哦，真酷’，然后再也不回来使用时，你能从中学到的东西也很有限。你学不到太多。
而且你也没有从中获得多少杠杆。
真正的杠杆。是的，这一点说得太好了。
我还认为，有很多人花了大量时间定制自己的工作流。所以我觉得这里有两个极端。一端是从不定制、从不构建自动化的人；另一端则是痴迷于定制工具、添加大量技能和 MCP，以及改进工作流的人。有时，这甚至会分散你发布产品或构建功能这一核心目标的注意力。定制确实很有趣，我们当然希望让产品非常容易改造，让它能很好地为你工作，但它的用处是有上限的。我认为，有一类人可能花太多时间定制，结果既不睡觉，也不做自己最初想完成的核心任务。
我在 Twitter 上经常看到这种情况：‘看看我的配置，已经失控了，优化得太好了。’那你到底构建了什么？‘不，但我的配置太棒了，完成了这么多事情。’
我认为简单的配置实际上效果更好。
/powerup。稍微升级一下。
是的。
是的。Karpathy 昨天刚发了一条推文，谈到一个很有意思的分化：一类人过去试过 ChatGPT、Claude，觉得‘好吧’，然后说‘不，这太糟糕了’，就放弃了 AI 能为他们做什么，对‘不可能，它没那么重要’这件事非常怀疑。另一类人则在使用 AI 编码，看到它全部强大的能力以及它有多好。两边的人都不理解另一边是怎么看世界的。所以你这里的建议非常好：真正用它处理实际事情，看看它到底已经变得多么出色。
是的。我认为最大的转变是，2024 年那一代产品是基于聊天的，而 Claude Code 这一代产品是基于行动的。人们最大的顿悟时刻，是 Claude 能够代表你做事情。意识到智能体能够完成的事情远多于告诉你该做什么，这种感觉非常棒。智能体实际上可以自己完成任务，而当人们感受到这一点时，我认为那就是让他们大开眼界的时刻。
为 Chrome 扩展、Claude Code Chrome 扩展喝彩。你可以看着它做事，对它说‘替我填这个表’，然后我就想，‘好，我这就去。’
没错。
好，在我们进入非常令人期待的闪电问答之前，还有什么吗？
没有，我们开始吧。
开始吧。Cat，我有五个问题要问你。欢迎来到闪电问答环节。有一段动画会播放，我得先说出来。你准备好了吗？
我准备好了。
第一个问题，你发现自己最常向别人推荐哪两三本书？
我非常喜欢《How Asia Works》。这是一本关于经济发展的书，讲的是哪些政策和政府能够造就长期成功的经济体。我还特别喜欢《The Technology Trap》。它讲的是过去几次技术革命，比如工业革命和计算机革命，以及这些革命如何影响劳动者。我喜欢它的原因是，我认为我们可以从历史中学到很多东西，确保这次转型顺利进行。再推荐一本轻松一点的，我很喜欢《Paper Menagerie》。这是一本短篇小说集，内容涉及成长、AI 和自我发现。
你最近真正喜欢的电影或电视剧是什么？
我非常喜欢《Drive to Survive》。没有什么更深层的意义，只是人们如此痴迷于一个单一的工程目标，以及这种追求本身的纯粹性，让人感到非常满足。我也非常喜欢《Free Solo》，它讲的是 Alex Honnold 不系安全绳攀登酋长岩。我觉得它同样展现了一种非常纯粹的成就感：攀登这条极其困难、危险的路线，并保持足够的心理专注去完成它，同时知道只要犯一个错误就会死。
太疯狂了。是的，那部电影太不可思议了。而且很有意思，这些内容似乎以某种方式与你所做的工作有关。
我其实是攀岩者，但我是在攀岩之前第一次看《Free Solo》的。所以我觉得它很震撼，却没理解它到底有多震撼。这是少数几部你了解得越多，就越会被它的疯狂程度震撼的电影之一。电影里在岩壁上做出的那些动作，即使是在离地一英尺的室内攀岩馆里，我也觉得自己这辈子可能永远做不到。
系着绳子。
系着绳子。
你看过另一位、那位去爬冰山的年轻人的纪录片吗？
看过。那部很悲伤。
但那太疯狂了。好，你最近发现、而且非常喜欢的产品是什么？
除了 Claude 产品之外，最改变我生活的产品可能是 Waymo。我是 Waymo 的铁杆用户，每天使用两次，往返上下班。我最喜欢它的两点是：第一，如果 Waymo 在等我，我不会感到内疚，所以不必在它到达的那一刻正好站在路边，压力小多了；第二，我觉得它让我更有效率。和另一个人一起坐车时，我通常尽量不打工作电话。如果一直盯着笔记本电脑，我会觉得有点不礼貌。但我很喜欢 Waymo 的一点是，我可以接入工作电话，不用担心别人听到，也不用担心‘这样是不是不礼貌？我是不是说话太大声？要不要请别人换首音乐？’所以我觉得它每天还给了我 30 分钟。
技术的所有这些二阶影响，真有意思。
是的。我过去总觉得 Waymo 要想成功，定价必须低于 Uber 和 Lyft，但实际上我很愿意为它支付两倍的溢价。
我喜欢 Waymo。你第一次看到它时，会想‘这太不可思议了’。然后你习惯了它，坐进去时还会想‘这太疯狂了’，接着就忘了这件事。
完全同意。我觉得它也改变了我们的用语。Anthropic 的很多人都喜欢 Waymo。过去你可能会说‘叫我们的网约车应用吧’，现在大家只会说：‘好，Waymo 到了吗？’
好，还有两个问题。你有没有一个在工作或生活中经常想起的、最喜欢的人生格言？
做事就好。
很符合你。很符合你。
我认为第一性原理思维很有价值。如果你知道自己在优化什么，并且拥有强大的第一性原理，那么通常就能推导出正确的行动路径，清楚地向所有利益相关者表达出来，然后去做就好。我觉得职位都是虚构的。如果你理解约束条件，就能弄清楚自己可以做什么，然后快速尝试，从错误中学习；如果做错了，就道歉或修正。
不管是谁说的，你都可以直接做事。
实际上，把这句话告诉人们很有解放感。在很多公司里，角色定义非常严格：产品经理做这些，设计师做那些，工程师做另一类工作，甚至团队边界也定义得非常死。比如我们负责代码库的这个区域，那个区域则不允许碰。我觉得‘做事就好’让人们感到自己有权做出这些决定，有权跨越团队边界开展工作，只为了把事情完成。
这似乎是一项很重要、而且很难做好的技能。人们称之为能动性，也就是去做自己需要做的事。
偏向行动。
偏向行动。还有很多说法，本质上都是不要等待许可。
是的。我认为，这也是人生中某个阶段去初创公司工作的最大理由之一。对我来说，真正改变人生的一件事，是在只有 20 个人时参与大规模工作：当时没有流程，但我们有需要解决的重大问题。我非常感谢 Alex 和团队其他成员赋予我以及整个团队权力，让我们可以自行解决问题，而不受销售应该做什么、运营应该做什么、工程师应该做什么之类的边界限制。你拥有所有可用工具，面对一个雄心勃勃、棘手的问题定义，可以做任何必要的事情来找到好的解决方案。
你几乎需要有过那种经历，才能培养出这项技能，才能自在地这样做。因为很多人上学或上大学时，接受的都是‘做我们告诉你做的事，然后你就会得到好成绩’的教育。你必须在某种程度上忘掉这一套，告诉自己：‘好，我只做需要完成的事情。即使别人觉得它很蠢，我也认为这是正确的事。’
是的，完全正确。
好。其实我还有两个简短的问题，最后两个问题。Claude 思考时会出现很多这样的东西，我不知道你们是否称它们为动词，应该怎么称呼这些东西？
思考词。
思考词。有意思的是，这些词都在源代码泄露时被公开了。你最喜欢哪个思考词？
我非常喜欢 manifesting（显化）。这也是我贴在笔记本电脑上的贴纸，是我最喜欢的。
显然是赢家。好，最后一个问题。我也问过 Forest：AGI 可能在我们的有生之年到来，到那时你可能不必工作了，你会做什么？你会用所有时间做什么？
我认为 AGI 要扩散到整个社会还需要很长时间。所以眼下要做的，其实是帮助全世界跟上变化。认真回答的话，事情发生后，我可能会大量攀岩。我大概会搬到枫丹白露，生活在一万块巨石之间，攀岩一阵子。还有很多书我想读。我的目标是每周能读一两本书，而我目前大概只能读半本，积压的书非常多。我认为我们可以从历史中学到很多东西，还有很多事情我并没有像自己希望的那样理解。我对物理、机器人、任何硬件、航空航天都不了解，但有太多有意思的主题。所以我很期待学习，即使我知道 AGI 已经会了解这些事情。
Cat，这太棒了。你太厉害了。我还有两个后续问题。如果大家想联系你、关注你在做的事，可以在哪里在线找到你？听众可以怎样帮助你？
联系我的最佳方式是去 Twitter 找我，用户名是 _catwu。欢迎在内容中提到我，也欢迎给我发私信。我会阅读所有私信，虽然不一定逐条回复，但我都会看。对我们最有帮助的是，告诉我们 Claude Code 和 Cowork 哪些地方对你来说运行得不好。我们非常感谢大家提供的大量正面反馈，但真正让我们不断进步的是边界案例、错误，以及可以复现的具体任务：Claude Code 或 Cowork 在这些任务上失败。如果你能把这些情况分享给我们，而我们又能复现，那么我们就可以积极改进下一代模型和下一代 harness。
太酷了。Twitter 上的大家在分享反馈时毫不客气，所以请继续。
是的，请把你们遇到的问题分享给我们。
是的，而且看到你们整个团队都很活跃，在 Twitter 上回应大家，真的很酷。所以我听到的是，这些内容确实会被你们看到并作出回应。
是的。我们很感谢大家如此积极地参与。你们的参与给团队带来了巨大的能量。我们有一个‘用户喜爱’频道，所以每当大家分享成功案例，我们就会把它发布在那里；每当大家分享产品问题，我们就会把它放进反馈频道，这样更广泛的团队就能采取行动。
知道这一点真是太酷了。谢谢你分享。Cat，非常感谢你参加节目。
谢谢你的邀请。
大家再见。（01:25:11）：非常感谢大家收听。如果你觉得这一期有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅节目。另外，也请考虑给我们评分或留下评论，这会极大帮助其他听众发现这档播客。你可以在 lennyspodcast.com 找到往期节目，或进一步了解这档节目。我们下一期再见。