我觉得很难把握好对 AGI 的信仰程度。 为一个超级强大的 AGI 模型做产品很容易。难的是弄清楚如何针对当下的模型激发出它的最大能力。我从未见过像 Anthropic 你们这样的发布速度。我们希望消除发布产品的所有障碍。我们很多产品功能的时间线已经从 6 个月缩短到 1 个月，有时甚至缩短到 1 天。你面试了几百个 PM，却一直觉得他们的思路非常不对。
PM 的角色正在发生很大变化。变化非常 快。构建 AI 原生产品时极其重要的是迭代速度要快。要想办法让你每周都能发布功能。你认为 PM 需要培养哪些新兴技能？回归产品品味。随着写代码的成本大幅降低，更有价值的是决定写什么。今天的嘉宾是 Kat Wu，Anthropic Cloud Coding 的产品负责人。Kat 身处 AI、产品和开发方式一切变革的中心，她和她的团队正在打造最能改变我们所有人构建产品方式的产品。她充满见解、智慧和经验。这一期节目你不容错过。在正式开始之前，别忘了查看 Lennysproductpass.com（Lenny's product pass.com），那里有专供 Lenny newsletter 订阅者的超值优惠。下面有请 Kat Wu。Kat，欢迎做客本期播客。谢谢邀请。我有太多问题了。很高兴你能来这档播客。我想先让大家了解你和 Boris 并肩作战的角色。呃，人人都知道 Boris。他那期节目是这档播客播放量最高的一期。别紧张。他呃创造了 Cloud Code。他领导工程团队，每天用手机提交数不清的 PR，我都不知道现在具体数字是多少了。我觉得人们对 Claude Code 以及 co-work 和你们正在做的所有事情所取得的成功，给你的认可还不够。帮我们理解你在团队中的角色，你如何与 Boris 协作，你们如何分工，PM 在 Claude Code 团队中到底是什么样的角色？能和 Boris 共事我感到很幸运。他是一位出色的思想伙伴。他是我们的技术负责人，非常有产品远见，很擅长设定产品在未来 3 个月、6 个月应该成为什么样子。就像是这个产品的 AGI pill 版本。而我的很多职责在于厘清，好的，从我们今天所在的位置到未来 3 到 6 个月的那个愿景，路径是什么。我把更多时间花在跨职能协作上，确保我们的市场团队、销售团队、财务、算力资源等等都认同这个计划，我们都在朝同一个方向划船。并且一旦功能准备好了，发布它就不会有任何阻碍。我觉得从很多方面来看这都很有效，因为我们有点像心灵感应，但实际上界线非常模糊。我觉得我们有 80% 是心灵感应，然后有 20% 的事情我可能比 Boris 更在意，所以我会主导那些，还有 20% 的事情他比我更在意，他就会主导那些。本期节目由我们本季的呈现赞助商 WorkOS 赞助播出。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。 如果你正在为企业构建产品，你一定体会过集成单点登录、SCIM、RBA、审计日志以及大型 公司要求的其他功能的痛苦。WorkOS 通过一个专为 B2B SaaS 打造的现代开发者平台，将这些成交障碍变成了即插即用的 API。毫不夸张地说，我投资的每一家开始向高端市场扩张的初创公司 最终都会和 WorkOS 合作。那是因为他们最出色。无论你是试图签下第一位企业客户的种子阶段初创公司，还是正在全球扩张的独角兽，WorkOS 都是让你的产品具备企业级能力、释放增长的最快路径。它本质上就是企业功能的 Stripe。访问 workos.com 开始使用，或者直接在他们的 Slack 里联系，那里有真正的工程师等着回答你的问题。WorkOS 让你通过设计精良的 API、全面的文档和流畅的开发者体验来更快地构建。前往 workos.com，让你的应用今天就具备企业级能力。其实我们在开始录制之前你分享过一件事，就是你一直在面试成百上千的 PM。这么说吧，要是每次有人托我引荐去 Anthropic 做 PM 我都能拿到五分钱，那我就会有 300 亿的 ARR 了。这里简直就是大家最想去工作的地方。所以我能想象你面试了多少 PM。你跟我说，你就是看到很多人做得不对。他们理解中成功 AI PM 该有的样子，以及他们为此采取的方式。说说你观察到的现象，以及现在大家需要明白成功到底需要什么。我觉得在 AI 出现之前，技术迭代慢得多，所以你可以按 6 到 12 个月的时间跨度来规划。因为当时发布功能的速度比较慢，所以更强调与其他合作团队协调，确保他们发布的功能不会阻塞你的功能，毕竟那时候写代码的成本很高。呃，我觉得现在有了 AI，工程开发被大幅加速，模型能力提升也非常快，我们很多产品功能的时间线已经从 6 个月缩短到 1 个月，有时甚至是 1 周或 1 天。因此，我们必须确保产品能非常快地发布出去。这意味着作为 PM，你应该少花精力去确保与合作伙伴团队的多季度路线图对齐，而要多花精力去想，我们怎么才能找到最快的方法把东西做出来？我们怎么能在产品套件里搞出一个概念角，让工程师或 PM 有个想法，到这周末就能送到用户手中？我觉得在 AI 原生产品中表现最好的 PM，是那些能想出如何缩短从有想法到把产品送到用户手中的时间的人，并且能帮助定义对于我的产品来说，哪些最重要的任务必须开箱即用。所以，我喜欢这一点，你说的就像是大家还没意识到他们需要行动得多快，以及现在这份工作有多大一部分就是行动、就是帮助团队快速行动。那什么能起到这个作用？你做了什么？你的 PM 团队做了什么来帮助他们走得这么快，除了能用到最先进的模型之外？我觉得第一件事是设定清晰的目标。因为 LLM 非常通用，这实际上会带来很多模糊性：我们为谁而做、想解决什么问题、最核心的使用场景是什么。所以，我觉得一个出色的 PM 能够说，好的，我们的核心用户是专业开发者。呃，这个功能我们要解决的主要问题，呃，主要问题可能是权限提示太多，人们感到疲劳，然后使用场景是我们希望企业里的专业开发者能够安全地实现零权限提示。这其实设定了一个相当明确的目标，因为它排除了许多减少权限提示的潜在方法，让人们能够用一个提示完成更多工作。然后我认为第二件非常重要的事，是找到一种可重复流程，来把这些功能交付上线。所以对于 Claude Code，我们的做法是几乎所有功能都以 research preview 的形式发布。我们在发布时会明确打上这个标签，让用户知道这是一个早期产品。这只是一个想法。这只是我们试图获取反馈并不断迭代的东西，而且可能不会永远得到支持。这样做的好处是降低了我们为发布某项功能所需承担的义务。我们可以在一两周内就把东西发出去。PM 应该做的第三件事是帮助团队建立框架，让他们知道什么时候该引入跨职能合作伙伴，以及这些合作伙伴的期望是什么。比如说，我们在工程、营销和文档团队之间有一个非常紧密的流程。当工程师觉得某个功能已经准备好了，而且我们在内部已经 dogfood 测试过，他们就会把它发布在我们的 evergreen launch room 里。然后 Sarah（负责我们的文档团队）、Alex（负责 PMM），以及 DevRel 的 Tarek 和 Lydia 就会立刻加入，并且能在第二天就完成营销公告。正因为有了这个非常紧密的流程，任何工程师发布功能的摩擦都降低了。PM 就是那个应该搭建这套体系的角色。
PRD 在这里面起什么作用？你提到目标非常重要，要让团队在对齐“成功是什么样的？这是给谁用的？不是给谁用的？”这些方面达成共识。你们会写 PRD 吗？还是只写几个要点？在 PM 的世界里，这是如何演变的？我们主要做两件事。第一，我们有非常严格的指标体系，每周都会和整个团队一起做 metrics readouts。这样做的目的是确保每个人都深入理解我们业务的方方面面：我们的关键目标是什么、趋势如何、以及驱动因素是什么。第二件事是我们有一份团队原则清单。其中包括我们的核心用户是谁、为什么他们是核心用户。我们把这些都阐述清楚的原因是让团队里的每个人都觉得他们理解我们的业务运作方式，理解什么对我们重要、我们愿意在哪些方面做出权衡，这样大家就可以自己做决定，而不会觉得被 PM 或其他利益相关方卡住。我很喜欢这套思路，也就是说，未来我们仍然需要 PM。现在有太多人在说“为什么还需要 PM？我们直接开发上线就好了，我们需要的是工程师。”
哦，我们有时候确实会写 PRD。我觉得对于那些特别模糊的功能，写一张单页纸说明目标是什么、令人愉悦的 use case 有哪些、目前需要修复的 failure modes 是什么，这确实很有帮助。偶尔也有一些项目，特别是需要大量基础设施投入的，确实要花好几个月，这种情况下我们仍然会写 PRD。我想再深入了解一下你们是怎么做到这么快的。我从未见过像 Anthropic 这样快的发布节奏。有人做了一张 Anthropic 所有发布的日历，几乎每天都有重大功能或产品上线。所以网上有人提问：你们刚做出了这个极其强大的模型 Mythos，还没有正式发布，只是把它做出来了，因为它太强大了，人们有点害怕它能做什么。你们内部有没有在用这个？这是不是你们能如此快速推进的部分原因？其实过去几个季度我们一直很快，所以我认为不全是 Mythos 的功劳。Mythos 是一个非常强大的模型。我们确实在内部使用这些模型，而且我觉得这稍微提升了我们的发布速度，但我不认为这能解释速度提升的大部分原因。我认为很大程度上在于流程和团队预期。我们的流程非常少。我们希望消除发布东西的每一个障碍。我们希望确保团队里的每个人都觉得自己有权把一个想法从单纯的念头变成对外发布，用时不到一周。有时甚至一天就够了。太酷了。天哪，能拥有最好的模型，同时又在 Anthropic 做产品，这是多么大的优势啊。能够使用前沿模型，我们非常幸运。天哪（笑），这是多么棒的优势啊。就像做出一个东西，然后用它，再加速变得更快。太有意思了。这场对话里还有几个支线话题我想顺带聊聊。Anthropic 最近发生了太多事，我非常好奇想听听你的看法。一个是大约一周前，Claude Code 的全部源代码泄露了，有人把它发了出去。你觉得这是有人犯了错。你对此有什么评论吗？比如发生了什么？哪里出了问题？人们应该知道什么？所以我们看到后立刻展开了调查。我们意识到这是人为错误造成的。当时有一个人正在用 Claude 写 PR，这只是关于我们发布包的方式的一次更新。而且它还经过了两层人工审核。所以这是人为错误导致的，我们已经强化了流程，确保以后不会再发生。这个人还在 Anthropic 吗？他/她还好吗？在的，在的。这是流程上的失败，最重要的是从中吸取教训，增加更多保障措施，防止再次发生。这就是我们一直专注做的事，而且大部分措施已经上线了。好的。另一个问题是关于 open claw。最近你们采取措施阻止人们把 Claude 的订阅用在他们的 open claw 上。人们很不满，我自己也感到很不高兴。他们不明白为什么会这样。感觉你们好像对开源社区造成了伤害。关于这个决定背后的考量，人们需要理解什么？我们看到 Claude 的需求非常大。我们一直在非常努力地扩展基础设施，同时让我们的 harness 更省 token，这样用户就能获得更多使用量。它并不是为第三方产品设计的，第三方产品的使用模式与我们的第一方产品不同。我们花了很多时间思考如何提供尽可能平滑的过渡方案。所以，我很高兴能够宣布每个人的订阅都会附带一些额度。但是的，我们不得不做出艰难的决定，需要优先保障我们的第一方产品和 API。这就是由此产生的决定。是的，这对我来说完全说得通。你们基本上是在以每月 200 美元的价格补贴这种使用，而且几乎是无限使用的。我觉得人们不理解企业是要赚钱的。我们要盈利。计算资源需求这么旺盛，我们不能白白送出去。所以我理解。回到 PM 团队，Anthropic 的 PM 团队是什么样的？有多少 PM？他们是怎么组织的？是的，我们有几支 PM 团队。我想我们现在大概有 30 到 40 名 PM。我们有一支由 Diane 领导的研究 PM 团队。这个团队负责理解客户对我们模型的所有反馈，并将其传达给最顶尖的研究团队去落实。他们还会主导模型的发布。此外还有 Claude 开发者平台团队，负责维护 Claude Code 所基于的 API。他们还会发布 managed agents 这类功能，让你可以构建自己的代理，由我们代为托管。然后是 Claude Code 团队，负责 Claude Code 和 Co-work 核心产品。还有企业级团队，负责帮助我们的企业客户更顺利地采用 Claude Code 和 Co-work。这包括成本控制、RBAC、安全管控等方方面面，确保这些企业在使用我们的工具时感到非常放心和舒适。然后我们还有增长团队，负责整个产品矩阵的增长。所以我们与他们紧密合作，共同推动 Claude Code 和 Co-work 的增长。我知道他们也与其他团队配合，推动 CDP 的增长，也就是 Claude API 用户群体的增长。说到增长，Amol 刚刚上过这档播客。他有一个非常有趣的洞察，是大多数人没有分享过的。大家总觉得未来我们需要更少的 PM。为什么需要 PM？工程师自己就能 ship。他的观点是，因为工程师的节奏太快了，PM 和设计师反而被挤压了。要跟上正在发生的一切，时间越来越不够。几乎每天都有功能在上线。所以他的看法是，他需要更多 PM，因为很难跟得上所有事情。你怎么看？你觉得 PM 的招聘会增加吗？你认为 PM 这个职业长期会怎么发展？我认为所有角色都在融合。PM 会做一些工程工作，工程师也会做 PM 的工作。设计师会承担 PM 的职能，也会提交代码。你有两种选择：要么招更多具备出色产品品味的工程师，要么保持工程师招聘规模不变，招更多 PM 来引导他们的工作。在我们团队，我们非常专注于招聘具备出色产品品味的工程师。这样一来，我们就能减少发布任何产品所需的开销。比如我们团队有很多工程师，完全可以端到端地完成整个流程：从在 Twitter 上看到用户反馈，到当周周末就上线一个产品，几乎不需要产品人员介入。我认为这其实才是最高效的交付方式。所以我认为工程和 PM 的职能正在重叠，无论增加哪一方，都会带来很大收益。产品品味仍然是一种非常稀缺的能力，只要我们认为某人在这方面展现出很强的天赋，我们基本上都会招。你的背景是工程，对吗？是的，我做了很多年工程师。后来在加入 Anthropic 之前，短暂做过一段时间 VC。实际上，我们团队几乎所有的 PM 都曾经是工程师，或者在 Claude Code 这里写过代码。我认为这有助于与团队建立信任，也能让我们行动得更快。而且实际上，我们的设计师以前也都是前端工程师。哇。因为这是一个大问题。显然正在发生一种融合，维恩图正在重叠。我想很多人关心的是，如果你来自工程、产品或设计背景，哪项核心技能会最有价值？我可以看到在 Anthropic 和 Claude Code，工程能力非常有价值。我好奇在其他公司，如果你有设计背景，转做 PM 是否更有价值，或者就是纯 PM 背景？我认为归根结底还是产品品味。随着写代码的成本大幅降低，更有价值的事情变成了决定写什么。比如这个功能的正确 UX 应该是什么？用户以最愉悦的方式体验它应该是什么样的？我们收到成千上万的 GitHub issue，什么样的需求都有，需要非常用心的品味去判断：哪些值得做，以及正确的做法是什么？我认为这种能力可以来自任何背景，但这才是最重要的。我认为工程背景特别有价值的原因，至少在未来几个月内是，如果你懂工程，你会对一件事本该有多难有更好的直觉，而这往往是决定做什么的重要因素。所以如果某件事很容易实现，那也许不用争论，直接花一小时做完就行了。但如果某件事更难做，而你事先就知道，那你就明白，这会让团队付出更高的成本才能交付。所以这对优先级判断有一定帮助。你说的是“在未来几个月内”，这仅仅是因为模型在未来几个月内可能会变得非常好，以至于你甚至不需要那么了解这些了吗？我认为有价值的技能组合变化得非常快，所以很难预测几个月之后的事。因此，我这么说并不是在评论我认为会发生什么转变，而更多是评论我认为会发生重大转变。所以你不是在说等 Mythos 发布就会改变一切，然后我们就不需要懂任何工程知识了？不，我只是说每隔几个月似乎就会有一次是的。编程能力的大幅提升，而这会改变其他哪些角色更有价值。我认为最重要的是具备 first principles thinking 的能力，能够判断技术格局如何变化，团队真正需要你做什么，然后主动投入去填补那个空缺。因为我认为工作正在变得更加无定形，这意味着一个优秀的 PM 要能够理解所有的缺口在哪里，判断哪些优先级最高，然后想清楚：我该如何学习那项技能，或者我现有的哪些技能可以应用到这项挑战上。所以我认为当前的环境看重那些能够身兼数职、能够灵活切换角色，并且不计较自己做什么工作、只要能帮团队提速就愿意去做的人。我很喜欢这个回答。我一直在问你这样的人，那些处于 AI 能力最前沿、用最新工具做建设的人一个问题：在达到 super intelligence 之前，人类大脑在哪些方面仍然有用且必要？我听到的是，本质上就是选择该做什么、判断市场走向、决定优先级，然后是判断你做的东西是否正确、好不好，并至少把它推出一个早期版本。是这样吗？还有别的吗？就是在未来至少几个月内，人类大脑还会在哪些方面继续有用？我认为人类仍然能提供模型所不具备的常识水平。任何产品发布都有成千上万个变动环节，有些非常小，但总是有很多地方可能出问题。我认为模型并不总是清楚所有利益相关方是谁，他们之间是什么关系，他们的偏好是什么，该通过什么渠道与他们沟通才能让他们持续支持。我认为很多这种更隐性的常识，或者说 EQ 这类的知识，仍然非常有价值。当然，我们希望模型在这方面变得更好，而且我认为它们会的。但现在，我觉得还是有差距的。作为普通人，你要如何应对如此持续不断的变化？就像身处龙卷风中心一样。也许那里很平静。但你是怎么紧跟事态发展的？又是怎么在所有这些疯狂变动中保持理智的？我觉得我们团队全是那种拥抱混乱的人。所以，我们试着微笑着面对每一个挑战，因为总有那么多事情在发生。总有那么多风险和棘手的情况，要知道，如果对任何事都太紧张，你会 burnout 的。所以我们真的很看重那些能够看着挑战说："哇，这会很难，但我很兴奋去攻克它，我会尽我所能，而且我知道我不会做到完美，但晚上我能安心入睡，因为我知道自己尽力了。"
这个回答很有趣，正好触及了未来什么技能会很重要，因为我忘了是谁说的，可能是 Ben Man，他说这是世界最正常的时候了——以后只会更不正常。是的，确实会越来越难。我感觉有很多周是这样：也许周日晚上出现一个 P0，然后周一变成了 P00，周一下午变成了 P000，然后你会想："哇，真不敢相信我周日晚上居然还在为那个 P0 担心。"
但我觉得你必须承认，你能做的事情有限，你需要睡好觉，第二天才能做出好的决策，而且要极其无情地优先安排时间，明确最重要的是什么，并且学会放手。比如我们发布的一些产品，并没有我希望的那么精致，但你知道，我们的首要目标是赋能专业开发者，如果某个产品不算成功，只要它没有阻碍核心使用场景，就没关系，因为我们会收到反馈，然后在下一版修复。发布一个有 bug 的功能，这种事以前会让我彻夜难眠，但现在我能接受了，因为我知道我们会很快得到反馈，然后在下一版修复它。我想象的是那个 GIF，我觉得可能出自《加勒比海盗》，就是那个人在船的楼梯上往下走，整艘船在他周围被彻底摧毁，而他超级淡定，就在一切崩塌时悠闲地 stroll 下楼梯。这很有意思，因为我见过的每一个 Anthropic 的人都特别 chill，而且非常乐观。是的，我觉得这是一个非常有意思的观察，就是这种冷静和乐观，对比那种"天哪，一切都疯了"的状态。对。我觉得如果没有这种心态，你会很快 burnout。我们倾向于招那些在行业里待过一段时间、经历过很多起起落落的人，他们清楚什么能给自己充电，以及如何在长期保持精力。我觉得这对我们帮助很大。太有意思了。我想问的是，现在角色在模糊化。工程师变成了 PM。所有人都是 cats，所有人都是所有人。在那个世界里我们会失去什么？我们会失去职业阶梯和清晰的职业发展路径吗？会失去设计一致性、代码质量吗？你知道，肯定有一些 downside。有哪些东西你会觉得："好吧，这是为了更大的利益而做出的牺牲"？我们牺牲的是产品一致性。历史上，写代码成本很高的时候，你会仔细规划整个产品套件，每个产品之间如何关联，每个产品的使用场景是什么，它们如何集成，基本上每个使用场景对应一个产品。而现在 AI 发展如此之快，我们有那么多想法需要测试，有时确实会出现功能重叠的情况。很多时候是因为我们内部喜欢两种 form factors，我们想让外部用户告诉我们哪个更好。但对新用户来说，这意味着他们可能不知道"完成 X 的最佳路径是什么"。我们需要做更多的教育工作，帮助人们理解核心功能是什么，以及使用它们的最佳实践是什么。我觉得这就是大量发布功能的代价。嗯，我觉得用户也会觉得很难跟上最新动态。通常在传统 PM 模式下，你每个月或每个季度发布一个功能，所以用户很容易理解："我只需要每个月查看一次，就能学到一些新东西。如果我忽略它六个月，也没关系，我不会觉得错过了什么。"我觉得对于这些 agentic 工具，不只是 Cloud Code 和 Cower，而是整个生态系统，人们会觉得需要每天刷 Twitter 才能看到绝对最新的东西。我觉得我们可以做更多事情，帮助人们减少那种身处不断加速的跑步机上的感觉，我希望人们的感觉是，他们只需要打开这些工具，工具会教育他们，嗯，或者教他们想知道的东西，然后他们能感觉更 ball along。对，我看到你们前几天上线了一个特别有意思的功能。我觉得是 {slash} powerup，它基本上会带你了解所有酷炫的用法，基本上就是使用 Cloud Code 的所有最佳实践。这是朝着那个方向做的吗？是的，完全正确。过去我们其实不想做 powerup 这类东西，因为我们觉得产品应该足够直观，你不需要经历任何教程。但随着时间推移，我们意识到功能实在太多了，而且用户对内置的 onboarding 体验需求很大，所以我们偏离了最初"不不不，不要 onboarding 流程"的原则。加上这个功能，是因为有太多用户想知道："有 100 个功能，哪 10 个是我绝对必须用的？"于是我们就做了这个。是啊，这个世界太 bizarre 了。Anthropic 在 B2B 和企业端非常成功，而传统上你不应该发布一大堆东西。你可能只是每季度发布一次，这和现在每天都有新东西完全相反。顺着这个话题说，Anthropic 这一轮的发展简直超凡脱俗。Anthropic 起步时远远落后。a mole 分享说，它曾经是最不受重视的公司之一，没有分发渠道，也不是第一个入场的。OpenAI 遥遥领先。当时给人的感觉是，Anthropic 根本不可能在长期竞争中胜出。现在它却势如破竹，击败了最大的公司和团队，增长如此迅猛，一个月 ARR 就达到 110 亿美元。Drips and growth。等这期节目播出时，数字可能更高了。身处其中，你觉得有哪些因素让 Anthropic 如此成功，能够从落后位置反超并做得这么好？最重要的有两点，第一是这一统一的使命。这有多重要，怎么说都不为过。我们招的人都是最在乎为全人类带来安全 AGI 的人。这实际上是我们在整个产品部门决定该优先发布什么时，频繁引用的准则。因为我们把这一使命置于任何单一产品线之上，所以我们能够做出横跨整个组织的非常快速的决策，并以统一的方式执行。所以我认为，这在我们这种规模的公司里是前所未有的。那么，为了把这一点说清楚。本质上，头号使命就是安全对齐，确保 AI 对世界有益，而你的意思是，只要拥有这样明确的使命，做决策就会容易得多。如果存在两个相互竞争的优先事项，我们会讨论哪一个对 Anthropic 的使命更重要。这样我们就能更容易地决定优先做哪一个，然后所有人都会支持我们做出的决定。所以有时候这意味着，比如说我们想给 Claude Code 上线某个功能，但另一件事更重要，于是我们就把这件事的优先级降低，先等等再说。这一点真正有趣的地方在于，我认为这解释了，与另一家名字可能和 OpenAI 押韵的公司相比，他们做了很多不同的事情。而我在这里听到的本质上是，「好吧，我们不会去做社交网络，不会去做一个信息流产品，因为这不符合我们的使命。」而正是这种坚持让 Anthropic 保持了专注，这似乎也是成功的核心要素。嗯，当我想到使命时，我认为是把 Anthropic 的目标置于任何单个组织或任何单个产品之上。所以对我来说，我认为我们非常擅长的第二件事是专注。我觉得使命对我来说略有不同。使命意味着团队愿意做出牺牲，损害他们自己的目标和他们自己的 KR，以服务于 Anthropic 的目标和 Anthropic 的 KR。而且人们非常乐意做出这种权衡。所以，举个极端的例子，如果 Claude Code 失败了，但 Anthropic 成功了，我会非常高兴。而且，我们整个团队都非常愿意按照这种思路来做决定。我不知道你能否深入谈谈这个，但你觉得关闭 open Claude 的决定也是其中的一部分吗？就像是，「好吧，这并没有推进 Anthropic 的使命。我们需要停止这个，因为它的运作方式不符合我们的预期。」
我认为对 Anthropic 来说最重要的事情之一是扩大我们能触达的用户数量。实现这一点的方式之一就是通过我们第一方产品的 Claude 订阅。所以，我们非常想在这一块加倍投入。但这有时候确实会以牺牲第三方产品为代价。我们一直在聊 Claude、Kwork 这些东西。有一点我想确保大家都能理解，而且我也好奇你自己是怎么使用这些工具的。目前有 Claude Code、Claude Desktop/Web，还有 Cohere。怎样才能最好地理解什么时候该用哪个？你分别在什么情况下使用这三者？所以我倾向于在终端里使用 Claude Code，当我只是要启动一个一次性的编码任务，并且想要所有最新功能的时候。CLI 是我们最初的产品形态，而且新功能往往也是先在这里上线。所以它是所有工具中最强大的。这就是我通常只在试着启动一个或可能同时几个测试时会用的东西。我认为桌面版在你需要做涉及前端的工作时真正出彩。我很喜欢做的一件事是使用我们的预览功能。所以，如果我在做一个网页应用，我经常在桌面版里使用 Claude Code。我会把预览面板开在右手边，这样我就能在和 Claude 对话的同时，实时看到我正在做的网页应用。对于那些想要图形界面更丰富一些的人来说，它也非常棒。终端对非技术人员来说可能会感到非常陌生。你的电脑上会弹出一大堆看起来很吓人的窗口，而且你没法像在其他几乎所有产品中那样点击操作。所以有很多人就是觉得用终端不舒服。如果你也是这种情况，我强烈推荐你去试试桌面版的 Claude Code。桌面版还有一个好处，就是能让你一目了然地看到所有正在发生的事。你可以在桌面版里看到你的 CLI 终端会话，可以看到你的其他桌面会话，还可以看到你在网页版和移动端上启动的会话。所以它是一个一站式的控制平面，你可以在这里看到你的所有任务。我认为网页版和移动端的好处在于，非常适合在途中启动任务。CLI 和桌面版都需要你在本地笔记本上操作。这很受限，因为有时候你在外面活动，去散个步。你没开着笔记本，而且我数不清我见过多少人，在外面的时候把笔记本开着，像连着手机热点一样拿着。而这恰恰说明我们缺少一个能满足这种需求的产品。所以对我来说，移动端让你可以随时随地启动这些任务，这样你就不需要走到哪都把笔记本带着，还要确保笔记本一直开着。我喜欢这个说法。我见过有人在飞机上——现在这都快成梗了。就是「我得让这 agent 跑完，我不能关机，我需要 Wi-Fi。」
然后我觉得对于 co-work 来说，它填补的角色是：每个人都要做很多工作，但产出不是代码。不管是把 Slack 消息清空或者把收件箱清空，还是为即将到来的客户会议做一份幻灯片，又或者是快速写一份文档，说明某个功能的目标或者上线计划。所有这些任务的产出都是非代码的，而 co-work 最适合做这些。所以我在心里划分这些产品的方式是：如果我在做一个产出是代码的东西，我会用 Cloud Code、桌面版或者移动端的 Cloud Code。如果产出是任何非代码的东西，我就会用 co-work。人们好像都没注意到 co-work 取得的成功。它的增长速度非常快。但我觉得人们可能还是不清楚它是用来做什么的。所以，能不能结合你作为 PM 的日常工作，给我们举几个用例？你使用 co-work 来节省时间、完成更多工作的方式中，有哪些是非常有趣、甚至可能出乎预料的？如果你刚开始用 co-work，你真正需要做的第一件事就是把所有和你角色相关的数据源都连上。因为 co-work 只有在你给它提供足够的上下文，让它能够为你整理产出时，才能干好活。所以对我来说，这意味着我要把它连到我的 Google Calendar、Slack、Gmail、Google Drive，这样它就能灵活地找到相关的上下文、提出问题、拉取对话线程。而这能大幅提升最终产出的质量。我用它做的事情比如，昨晚我在准备即将到来的 Code with Cloud 大会，我要在会上做几场演讲。其中一场演讲讲的是 Cloud Code 从助手到完整 agent 的转变。我想在这场演讲中展示我们为此推出的所有产品，还要弄清楚，人们在内部有哪些成功案例可以拿来当 demo。所以我连上了 Google Drive，也连上了 Slack。Alex 是我们的产品营销人员，他整理了一份草稿，写了他认为我们应该涵盖的要点。然后我就把所有这些内容都喂给了 Cohere，告诉它我想讲述的叙事逻辑。然后它真的就这样跑了一个小时。它浏览了 Twitter 查看我们发布了什么，翻看了我们的 evergreen launch room，还查看了 Cloud Code 的 announce 频道——我们团队会在那里发布 demo，展示他们如何从 Cloud Code 中获取最大价值。随后，它把这一切综合成了一份 20 页的幻灯片，这是我今天早上醒来时看到的。我通读了一遍，感觉相当不错。有几处需要调整，所以我确实得给它一轮反馈。我喜欢幻灯片上的文字极度精简，而它生成的内容有点太啰嗦了。但你知道，这比我亲自做要快得多。而且因为 Cohere 可以访问我们整套 design system，最终效果看起来就像 Anthropic 的设计师亲手做的一样。视觉上你看过去会觉得："哇，这太精致了。"所以，这类工作的速度提升了非常多。做这份幻灯片本来会花掉我几个小时，但现在它直接生成了一份相当不错的草稿，这样我就能专注于确保我们嵌入其中的 demo 足够精彩。这听起来像是产品经理的梦想成真了，毕竟做幻灯片太烦人了。太慢了。
我很期待大家在你演讲时看到这份幻灯片。它很快就会公开——显然这不是一稿过的版本，你已经迭代过了。那么，为了帮助大家自己动手尝试，第一步是连接他们的……你刚才说什么？Slack？你还建议连接什么？
Slack、Google Calendar、Gmail、G Drive。你应该连接你的通讯工具，以及存储团队关注点、你个人关注点和当前工作内容这些 source of truth 数据的地方。好的。那你输入的 prompt 大致是什么样的，用来生成这份幻灯片？我就写："帮我做一份 Code with Claude 会议的幻灯片。这是我们的 PMM 建议要涵盖的内容。这是我自己做但目前不满意的草稿。这是我手动做但同样不喜欢的一份，不过我把链接附上了。你能先创建一个带细节的拟议大纲吗？另外，确保不要和 keynote 演讲内容重叠太多，那个更重要。"然后 Claude 读了我发给它的很多链接，生成了一份拟议大纲。接着我读完了它的提案，以及我自己生成的关于我们可以涵盖哪些内容的各种想法，然后做出了决定，确定最终幻灯片里到底要放什么。我认为这很好地说明了如今产品经理的角色是什么。Claude 是一个很棒的头脑风暴伙伴，它能非常快速地综合大量信息，把所有可能性呈现给你，但产品经理的角色仍然是做出最终决策——最终产品里应该包含什么？所以针对这次演讲，我最终决定希望内容涵盖从让本地任务成功，到让每个 PR 都通过，再到帮助工程师合并更多 PR 这样的演进过程。而且对于每一个环节，哪个 demo 最有说服力。在确定了大纲之后，co-work 就像去忙了几个小时，然后把整套幻灯片做出来了。这太棒了。再也不用做这部分工作，简直太好了。感觉就像是在和一个幻灯片设计师对话，而且它对你做过的事情有真正的了解，能做出你真正想要的内容，而不只是让页面看起来漂亮。你是怎么处理 design system 这部分的？具体怎么运作？它是怎么知道 Anthropic 的 design system 的？我这样做是因为我们其实已经有一份标准化的幻灯片模板，用于所有对外活动。所以我就让 Claude 访问了这份模板。这样它就能看到我们用什么颜色、什么字体，以及各种……这叫什么来着？就是可用的幻灯片版式。所以它大概有 20 张这样的示例幻灯片，示例，明白了。所以你就像是上传了"这是我们的模板，请基于这个来做"。对。你也可以连接 Figma MCP，如果你把幻灯片版式存在那里的话，它就能直接调用。顺着这个话头，我一直很好奇，作为 Anthropic 的产品经理，你的工具栈里都有哪些东西？显然有 Claude Code、co-work 和所有 Anthropic 的工具。你还用什么？你提到了 Slack，还有别的吗？我的工具栈主要就是 Claude Code、co-work 和 Slack。Anthropic 基本上是在 Slack 上运转的。我觉得它就像我们公司的核心 OS。日常工作中，我大概 30% 的时间都在探索 Cogram 和 Cogram Code 的边界，这样我就能非常清楚地知道我们哪些地方还不够好。我也花很多时间和模型对话，理解它为什么会犯那些错误。实际上我们自己做了很多内部工具。我认为 Cogram Code 给我们整个公司带来的一大突破是，它大大降低了制作任何你想要的定制应用的门槛。所以我们看到出现了大量针对特定用例的 crystallized work software，人们为特定场景自己搭建工具，而不是使用那些并不能完美契合需求的现成工具。我想多听听。有哪些例子？你或其他人做了哪些很受欢迎、很有用的东西？有一位做销售的同事用 Cogram Code，他意识到自己一直在重复做类似的幻灯片。所以他搭了一个 web app，里面放了我们已知效果很好的核心 Cogram Code 幻灯片案例，比如入门 101、进阶 201 和 Mastering Cogram Code。然后他设置了一个输入特定客户上下文的方式，可以从 Salesforce、Gong 和其他笔记中拉取信息，这样我们就能为特定客户定制幻灯片。比如我们会提取出这样的信息："好的，这个客户在用 Bedrock 或者 Cogram for Enterprise 或者 Console。"这会影响到他们可用哪些功能。还会提取出："这个客户关注的是 SDLC 里的 code review 阶段。"那我们就会在那里加一页关于我们 code review 功能的幻灯片。还会提取出："这个客户需要符合 HIPAA 合规，或者需要某些安全管控措施。"那我们就会确保在他们的幻灯片里加一两页相关内容。再举个例子，如果客户用的是 Vertex 或 Bedrock，不想用 Cloud for Enterprise，那我们就会删掉一些仅适用于 Cloud for Enterprise 功能的页面。通常这种手动操作要花 20 到 30 分钟，人们要么花这个时间去做，要么干脆不做，直接用通用版本。而有了这个工具，只要几秒钟就能生成一份定制化的幻灯片。有意思的是，Slack 这个工具好像没人……就是没人想自己做一个替代版。Slack 一直在赢，而且就像你说的，它已经成了很多公司的 OS。这太有意思了。人们谈论 Salesforce 时会说，它就是 SaaS，我们不再需要 SaaS 软件了，我们要自己建。但 Slack 就像是一个很讨喜的工具，没人想去竞争并做一个更好的版本。我认为它是相当重要的通讯基础设施，而且在帮助每个人获取实时更新这个核心任务上，他们做得非常好。是啊，人们总爱吐槽 Slack，但它在自己想做的事情上确实做得很好。而且大多数最前沿的团队都离不开它。真有意思。是的，我也很喜欢他们把定制做得多么简单。我们很喜欢做 Slack 机器人，这种可改造性意味着我们能按自己想要的方式与 Slack 集成。所以真的很感谢 Slack 在这方面的努力。该买点 CRM 股票了。我非常高兴地向你介绍本季的赞助伙伴 Vanta。Vanta 帮助超过 15,000 家公司——如 Cursor、Ramp、Duolingo、Snowflake 和 Atlassian——赢得并证明客户的信任。得益于 AI，团队构建和交付产品的速度比以往任何时候都快。但结果是，你的产品和业务中引入的风险也达到了前所未有的高度。我接触的每一位安全负责人都感受到保护组织、业务以及客户数据的负担日益加重。因为节奏太快了，他们只能不断被动应对，不得不猜测优先级，并凑合着用过时的解决方案。Vanta 通过超过 35 个安全与隐私框架（包括 SOC 2、ISO 27001 和 HIPAA）自动化合规与风险管理。这帮助企业快速实现合规并保持合规。信任比以往任何时候都更能成就或毁掉你的业务。了解更多请访问 vanta.com/lenny。 作为本播客的听众，你可以获得 1,000 美元的 Vanta 优惠。网址是 vanta.com/lenny。好的，你谈到了这些不同的团队，以及他们如何使用 Quad Code 和 Co-work 来运作。除了工程团队之外，你觉得哪个团队——我猜工程团队是消耗 token 最多的，但如果不是的话，那会很有意思——现在哪个职能是 token 消耗的第二名？哦，Applied AI 团队在突破 Quad Code 和 Co-work 的能力边界方面表现得非常出色。我们的 Applied AI 团队花很多时间与客户在一起，帮助他们采用我们的 API。所以有时候，Applied AI 团队会代表这些客户制作原型，而 Quad Code 让这个过程比以前快多了。他们还有双重目标，就是需要处理大量客户沟通、客户 inbound 和历史背景、通话记录。所以他们在 Co-work 和 Quad Code 上的使用量都非常大。想确认一下我对 Applied AI 的理解，这是不是有点像前沿部署工程（forward deployed engineering）的角色？大多数人会如何描述 Applied AI 团队在做什么？是的，就是帮助客户在整个公司范围内采用最新的 API 和功能，既用于驱动他们公司的产品，也用于内部提速。明白了。所以有点像客户成功，又带点 go-to-market 性质的前沿部署工程。没错。就像一个非常技术化的 go-to-market 人员。明白了。好的，太棒了。所以你是说，这可能是消耗 token 第二多的组织。是的。而且我们也看到他们在不断突破 Cohere 的能力边界。比如，这些人通常覆盖多个客户，高峰时一天可能有五到十次客户互动。所以他们经常用 Cohere 来做的事是：前一天晚上，让 Cohere 总结——"我明天有哪些客户会议？这个客户之前都向我提过哪些需求？他们最关心什么？过去会议的待办事项有哪些？"然后 Cohere 会整理出一份档案，一份简报，让他们在参会前了解所有需要注意的信息。Cohere 还能帮忙查找答案。比如客户问："功能 X 什么时候上线？"Cohere 可以帮这位 PII 同事在 Slack 里搜索最新的预计时间，加到笔记里，这样在客户通话中，这位 PII 同事就能掌握最新信息。这些都是人们为自己搭建的工作流，然后分享给团队里的其他人。太酷了。最近有个问题或者说趋势经常冒出来——就是 token 开销超过人的工资，人们使用 AI 的成本比他们赚的还多。Anthropic 内部有没有流传什么数字，比如工程师每月或每天消耗多少 token，或者产品经理（PM）之类的？我们清楚地看到，随着模型变得更好，人们会把更多任务委托给它，并在 Claude Code 和 Co-work 这类工具上花费更多时间。所以我们确实观察到，每次模型有飞跃或产品有重大改进时，每位工程师或任何知识工作者的 token 成本都会上升。我觉得这仍远低于普通工程师的薪资水平，但我们看到这个比例在随时间增长。这很有意思。我们之前聊到你在 Anthropic 能接触到最前沿的模型，另一个优势是——我相信你们基本上有无限的 token 额度。你们想用多少就用多少，对吗？我们可以用很多 token。但有些人确实会遇到限制，所以——
还是有限制的。好吧。 Boris，快住嘴。呃，好吧。拥有最先进模型能带来这么多优势，这太有意思了。就像一个开始转动的飞轮，非常有趣。我觉得我们也非常相信要赋能内部团队以尽可能快的速度构建，而且我们相信每个人都理解服务这些模型的真正算力成本，我们相信团队会负责任地使用 token。所以浪费 token 是非常不被认可的。但我们确实信任每个人去做出这个判断。太棒了。回到产品经理（PM）的角色，我们之前稍微聊过这个，但我觉得大家会很想听。我想了解的是，你认为产品经理需要培养哪些新兴技能，或者说 AI 公司在招聘 PM 时最看重什么？我认为最难的技能是能够定义产品一个月之后应该是什么样子。在那个时间尺度上，模型能做到什么、用户行为会如何变化，都存在很大的不确定性。但我觉得最优秀的产品经理能看出一些模式——基于用户如何试探现有产品的极限。最优秀的产品经理能感知到这一点，能设定方向，[清嗓子] 并稳步朝着目标执行；如果模型能力远超或远低于最初的预期，他们也能调整路径。我觉得很难把握对 AGI 笃信的恰当程度。因为所有人都能看到这样一个未来：模型极其聪明，几乎无所不能，到那时你其实不需要那么复杂的产品。你可以再次只用一个文本框，告诉模型你想要什么。它聪明到可以添加任何工具、任何集成来完成任务。它知道什么时候不确定，可以提出澄清问题。为超级 AGI 级别的强模型做产品其实很容易。难的是弄清楚：针对当前模型，如何激发出它的最大能力？如何帮助用户走上"黄金路径"？如何引导用户利用模型的长处、弥补它的短板？这种技能相当稀缺。嗯。那如何培养这种技能呢？这是否只是要了解每个模型的边界，培养一种对其能力的判断力——也就是你所说的“品味”——知道它擅长什么、不擅长什么，以及它发生了哪些变化？我认为这需要花大量时间与模型对话和使用它。我很喜欢做的一件事，是让模型反思自身行为。所以有时候当我注意到模型做出了意料之外的举动，比如模型会修改前端并运行测试，但实际上并没有使用 UI。这时问模型为什么这样做会很有用。有时它们会说：“system prompt 里有些东西令人困惑”，或者“我没意识到前端验证也是任务的一部分”，又或者“我把验证委派给了 sub-agent，但它没完成任务，我也没检查它的工作”。很多时候，只要对模型为何做出某个决定保持强烈好奇，就能发现是什么误导了它，这样你就能修复 harness 来弥补这个差距。另一件有帮助的事，是找出你最信任的、能给你关于模型准确反馈的用户。通常有少数人能比其他人更清楚地讲明白，什么让某个特定模型或模型-harness 组合表现优异。会有很多人给你反馈，但并非所有人的反馈都同样有价值。所以找到这样一群你信任的人——比如五个——对于获得快速反馈非常重要。我认为第三件有用的事——尽管不是每个人都喜欢做——是构建 evals。你不需要建几百个 evals 才能见效，只要做出 10 个优质的 evals，就能帮助团队量化目标是什么、进展如何、以及还缺什么。所以我认为 evals 是一件被低估的事，更多产品经理和工程师应该投入其中。我们已经多次讨论过 evals 了。现在有种趋势认为，未来的产品管理工作就是写 evals，因为本质上这就是在回答“成功是什么样的”。好，那我就具体把它定义出来，然后我们就知道了。你觉得自己花了多少时间在写 evals 上？我认为 evals 的重要性因你做的功能或要解决的问题而异。我们团队里有很多人确实花了很多时间在 evals 上。我们有一个小 pod 的人与研究团队紧密合作，更精确地理解 Claude Code 的行为，以及最大的改进空间在哪里，并试图非常具体地衡量这些。我个人会在某个功能需要更多产品定义时投身 evals，产出通常是：我做了五个 evals，这是运行方法，这些通过了，那些没通过，这是我用来提升成功率的 prompt。不过这也因具体功能而异。不是每个功能都需要，但我认为像 memory 这样的功能就从中受益良多。你提到有些人非常擅长评估模型，这点很有意思。这几乎就像一种人工 eval——他们能感知模型在哪里表现出色，哪里可能存在不足。有什么特别想点名表扬的人吗？我认为有两个人在这方面非常出色。一个是 Amanda，她塑造 Claude 的性格。这是一个非常困难的职位，因为任务本身很模糊。甚至编程都更容易，因为你可以验证成功与否，而塑造性格需要对“Claude 应该成为什么样的存在”有极强的信念感。我认为她不仅有塑造性格的能力，还能清晰地阐述目标是什么、角色在什么情况下算成功、什么情况下不算。另一群我非常信任的人就是 Claude 团队本身。我们经常有团队午餐，每当在测试新模型时，最快的反馈方式之一就是在午餐时走到每个人面前问：“嘿，你对这个模型的 vibe 感觉怎么样？” 很多时候我们会得到这样的反馈：“这个模型没有完全解释它的思路，太突兀了”，或者“这个模型喜欢写大量 memories，但我们不确定 memories 的质量高不高”，又或者有人会注意到“这个模型喜欢自我测试，这很好”，或者“这个模型自我测试不够”。这会影响我们查看哪些数据来验证“这是否是一个更大的模式”。我们拥有海量数据，但很难从中提取洞察。所以这群人的反馈帮助我们明确“我们要验证哪些假设”，然后我们就能提取数据来测试。你提到的关于 Claude 性格这一点，我之前播客请过联合创始人 Ben Mann，他谈到过 Claude 的性格、constitution，我当时没意识到，后来才发现人们那么喜欢 Claude，原因之一就是 Claude 的性格——它的性格比其他模型更出色、更有趣、更有意思。他说，性格正是 Claude 在很多方面表现出色的原因。这听起来像是件微不足道的附带品——它会变得风趣幽默、说话好玩——但这其实是 Claude 成功的核心。关于性格/个性为何如此关键，有什么是人们可能不了解的、你愿意分享的吗？当你回顾所有共事过的人，总会有一些人让你感叹“我真的很喜欢他们的能量，我很喜欢他们的 vibe”。当人们想到 Claude 和 Claude Code 时，这是人们最常提到的一点——他们真的很喜欢 Claude 轻松有趣。但它在执行任务时又极其自信。人们也很喜欢 Claude 的 low ego。所以如果你告诉它“你这件事做错了”，它会真心道歉：“哎呀，谢谢你告诉我，让我修正，我们一起解决。” 它也非常积极。所以如果你感觉“这是个难以逾越的任务，我不知道怎么开始”，Claude 会说：“没关系，这些是我认为我们应该采取的步骤，你想让我帮你开始吗？” 我认为优秀同事的一部分特质就是这种积极性、这种行动导向、这种能给你真诚反馈而不只是附和你说的一切的能力。所以我们试着将这些注入 Claude，因为我们认为这会让与它合作变得更加愉快。有件事我想回头再聊聊。你谈到新模型出来时，经常需要重新审视已经构建的东西。这很有意思，可能也挺让人沮丧的——“该死，又得调整这个，现在得重新思考。” 聊聊你多久需要随着新模型的到来而重新审视，然后发现“好吧，我们得重做几个月前发布的这个产品”。我们针对新模型所做的很多改动，其实是移除那些不再需要的功能。很多时候，我们给产品加功能其实是为了弥补模型的不足，因为它自己不会自然而然地去做。最典型的例子就是待办清单。我们刚推出 Claude Code 的时候，用户会让它做一些大规模重构，Claude Code 会说：“好的，我需要修改大概 20 个调用点。”然后它改了 5 个就停下来了。我们就想：“那怎么强制它记住把剩下这 20 个全部改完？”团队里的 Sid 就说：“我们不妨想想人类会怎么做。人类会把所有要改的地方列一个清单。就像在 VS Code 里，你会查找所有调用点，左侧会列出一个清单，然后你一个一个地替换过去。我们怎么给 Claude 提供类似的工具？”于是他加上了待办清单功能。我们发现有了这个功能后，Claude 确实能把这 20 个调用点全部修好。但到了 Opus 4 及之后的模型，我们意识到已经不需要强迫它去用这个待办清单了，它会自然地主动使用。对于早期模型，我们得不断提醒它：“嘿，待办清单上的事都做完了吗？没做完就不能结束。”而对于后期模型，不需要提示，它自然就会想着把待办清单上的事项全部完成。如今，待办清单对用户来说依然有点用，因为你能更清楚地看到 Claude 在做什么。但说实话，这个功能目前在产品里已经被极大弱化了，模型用不用它都行。对它来说，要做彻底的修改已经不再需要这个工具了。我忘了是谁在这期播客里说的，模型会把你加给它的那些“缰绳”当早餐吃掉。我听下来的意思是，随着时间的推移，你们会不断移除那些因为模型表现不达预期而不得不额外加上去的东西；而随着模型越来越聪明，它做你想让它做的事就变得越来越简单。是的，每次模型变聪明，我们都能去掉很多 prompt 层面的干预。实际上，每次发布新模型，我们都会通读整个 system prompt，然后反思：“这些部分里，模型真的还需要这条提醒吗？”如果不需要，我们就删掉。不过新模型最激动人心的地方在于解锁了全新的功能。有很多功能我们之前用旧模型测试过，但准确率不够高，所以没敢上线。代码审查就是一个例子。我们试过好几次做代码审查产品，也推出过比较简单的版本，就是以前那个 /code-review 命令。直到最近的模型，我们才觉得：“好了，这个代码审查已经好到我们的工程团队在合并 PR 之前都依赖它通过了。”我们发现，这是我们一直梦想的——Claude 能成为一个可靠的代码审查员，让我们有信心它能发现大部分 bug。直到 Opus 4.5、4.6，还有 Sonnet 4.6，我们才觉得：“好了，我们现在可以同时运行多个代码审查 agent，遍历整个代码库，然后汇总出一组工程师在合并前必须解决的真实问题。”所以这是最新模型解锁的新能力。这是本播客里很常见的另一个趋势：先去做那些未来 6 个月内可能实现的东西。你有点走在“勉强能用”的边缘，然后技术会赶上来，接着它就变成了一款很棒的产品，而你就领先了所有人。没错，去做那些目前还未必能跑通的产品非常重要，这样你才能清楚地知道，要让这个产品成功还缺什么。然后等新模型一出来，直接把它换进你已经做好的原型里，看看这个新模型能不能补上那个缺口。关于 Claude 和 Claude Code 的长期愿景，你能谈到什么程度？我猜你不想透露太多最终目标，但感觉你们在不断叠加各种很棒的功能，比如 Dispatch、手机端控制，还有各种移动应用功能。要怎么理解所有这些事的长期愿景？我们把它想象成积木。对 Claude Code 和 Claude 来说，最核心的积木就是让单个任务成功。你希望我们产出某个结果，给它一个清晰的 prompt 描述。它能不能持续产出可接受的结果，让你可以直接 merge，或者分享给同事、外部受众？任务就是这个核心积木。随着模型越来越聪明，任务成功率大幅提高，然后我们就看到人们开始同时推进多个任务。2025 年底前后，multi-Claude 曾经非常火，而且此后一直只增不减。所以我们把这看作是：“很好，单个任务能跑通了，现在你可以一次跑六个任务。”随着模型进一步变强，我们 extrapolate 的下一个阶段是：“接下来，你可能要同时跑 50 个 Claude，甚至几百个 Claude。”那么，我们需要搭建什么样的基础设施来支持这种规模？到那时候，你大概不会再把所有东西都在本地机器上运行了，RAM 根本不够。所以我们正在思考，怎么让你更轻松地管理所有这些任务，它们很可能会在远程运行。我们要设计什么样的界面，让你作为人类能知道哪些任务需要你去查看。我们要怎么确保 agent 能完整地验证工作，这样当你看到某个任务显示已完成时，你能非常快速地验证并完全相信它是按照你的 spec 完成的。还有，我们要怎么确保这个流程是能自我改进的？也就是说，当你发现某个任务做得不符合心意，你可以给它反馈，模型就会知道在以后的每一次运行中都吸收这个反馈，不再犯同样的错误。这就是我们正带领用户一步步走过的演进路线。有很多听众，很多产品经理，很多创始人，还有很多跨职能的同事在听。很多人很担心自己的角色、职业的未来。你会给大家什么建议，才能不只是在这个 AI 驱动的世界过渡中生存下来，而是真正成功，乃至在这个未来中蓬勃发展？人们需要听到什么、需要去做什么？我觉得 AI 给每个人带来的 leverage 比以前大得多。所以我想推动大家：任何时候你意识到自己在反复做某项手动任务，就想想怎么用 Claude Code、Co-work 或其他 AI 工具把它自动化。大多数人工作中都有绝对热爱的创造性部分，也有非常讨厌的繁琐部分。我觉得 AI 的美妙之处就在于，它可以帮你做那些繁琐的事。它可以从你每一次手动操作中学习，然后 generalize，自动执行。这样你就能专注于创造性工作，也意味着你能做到比以前多得多的事。所以我想立刻敦促大家：找出那些可以交给 Claude 的重复性工作，不断迭代这些自动化流程，直到成功率非常高。然后你要专注于，你还能为自己的团队、自己的产品、自己的公司多做些什么，那些是目前大家还没精力去接手的事？或者说，有没有什么你一直都觉得公司应该做、但始终没精力去做的 pet project？如果 AI 能处理掉前期的基础工作，那你现在就拥有了额外的 20% 时间，这是你以前可能没有的。所以，我的建议是积极拥抱这些工具，把你不想做的工作交出去，想办法让它为你提速，这样一来，你就能做成更多事情。你刚才分享的有一点非常关键，我非常赞同，那就是要用 AI 去解决问题。这些工具潜力巨大，有那么多可能性。但对很多人来说，最难的部分其实就是：“我到底该做什么？”而你这里说的是，去留意那些你一直在做、可以自动化的事；去留意那些你一直没时间去做的想法。基本上就是，为你自己解决一个问题。这算是核心的建议。没错。我还想推动听众去做的是，把你的自动化从“好吧，这是个很酷的概念”推进到“嘿，这东西真的能 100% 可靠运行”。有时候我看到用户尝试自动化某件事，做到了 90-95% 的准确率，然后就放弃了。但如果一个自动化不能 100% 运行，那它就不算真正的自动化。最后那 5% 到 10% 确实需要花更多时间。而且，搭建自动化往往比你自己亲手做要慢得多。但我鼓励听众投入时间，去规划一些你真正想做到 100% 的自动化。花点力气去教 Claude 你的偏好，给它反馈，让它提升 skill，这样它才能达到 100%，到那时候你才能真正依赖它。一个 95% 的自动化其实没什么价值。我在这方面太典型了。这对我来说真是很好的建议。我也有这个问题。我一直在教它。我一直在教 Coda，想让它帮我把 Gmail 清空到 inbox zero，但这件事非常耗时，而且显然还没做到位，你可能也意识到了。是啊，说来有趣，我想到的也正是这个。我设置了一个工作流，每封邮件进来，它会找出那些垃圾邮件，就是那种“嘿，我能上你的播客吗”或者“这个怎么样”之类的，这些事我就是没时间处理，然后我会把它们归类到一个叫 spammy 的文件夹里。这个流程 95% 都很好用，但偶尔就会想，“天哪，我漏掉了一封邮件，因为它被放进那里了”。所以这对我是个很好的推动，我要去搞定这个，我要把它做到完美。是的。我们也在努力让自定义这些命令的流程变得更简单，因为我觉得现在你需要了解的概念太多了。你得知道怎么定义一个 skill，得知道怎么使用这个 skill 并给它反馈，然后还得知道怎么让 Coda 根据你给出的所有反馈去更新 skill，还得知道去哪里查看这个 skill，确保反馈是以你想要的方式被采纳的。让这套流程变得真正无缝，让操作起来不觉得痛苦，这也是我们的责任。太棒了。Kat，你还有什么想分享的吗？还有什么想留给听众的吗？在进入我们非常激动人心的 lightning round 之前，有什么你想着重强调但我们还没聊到的吗？我看到很多人在玩 AI，搭建一些原型应用， tinkering 着搭建工作流。我真的很想推动大家去搭建那些你每天都会真正用到的应用，因为我觉得只有通过使用，你才能真正获得价值。如果你搭了一个原型应用，但它并没有帮你完成更多事情，那 AI 其实没有给你的日常生活增加价值。而且如果你只是随便试了一次，“哦，好酷”，然后就不再碰了，那你能从中学到的东西也很有限。你也从中获得不了多少 leverage。而且是真正的 leverage，是啊，这点说得太好了。我还觉得有很多人花大量时间去定制自己的工作流。我觉得这像是光谱的两端。一端是那些从不定制、从不搭建自动化的人，但另一端截然相反，有些人痴迷于定制自己的工具，比如添加大量 skill、MCP 和这种那种工作流改进。我觉得这有时甚至会分散你对核心目标的注意力，比如发布某个产品或开发某个功能。定制确实很有趣，我们也肯定想让产品具有很高的可 hack 性，让你能把它调教得很适合自己，但有用终归是有限度的。我觉得还有一类人可能花太多时间定制，以至于不睡觉，也不去做他们最初打算做的核心任务了。我在 Twitter 上看到很多这种情况。就像“看看我的 setup，太疯狂了，优化到了极致”。那你到底在搭建什么？你实际在做什么？不，但我的 setup 真的很棒。就像，你能完成超多事情。我觉得简单的 setup 其实效果更好。嗯。稍微 power up 一下。让水平也提升一点。是啊，是啊。
Karpathy 昨天发了一条 tweet，谈到了一种很有趣的分歧：有些人早年试过 ChatGPT 和 Claude，觉得“也就这样”，然后就说“不，这太糟糕了”，他们基本上放弃了让 AI 为自己做事，变得特别爱唱反调，觉得“不可能，这根本没那么大不了的”。而另一波人基本上是用它来编程，他们看到了 AI 全部的强大力量和它有多好用。两边的人都不理解对方，不理解对方为什么那样看待世界。所以你这里的建议真的很好，就是真正拿它去做实际的事情，看看它其实已经变得多强了。是的。我觉得最大的转变在于，2024 年的那一代产品是基于聊天的，而 Claude 代码生成这一代产品是基于 action 的。人们最大的 aha moment 就是当 Claude 能真正代表你去做事的时候。知道 agent 能做的远不止告诉你该做什么，它实际上能自己去做，这种感觉太 amazing 了。当人们感受到这一点时，我觉得那就是让人 eye-opening 的时刻。
Shout-out 一下 Chrome extension，Claude 的 Chrome 扩展，你可以看着它在那操作。你就说“帮我把这个表填了”，然后它就说“好的，我来了”。没错。好的。在进入我们非常激动人心的 lightning round 之前，还有什么要说的吗？没了，开始吧。开始吧。Kat，我有五个问题要问你。欢迎来到 lightning round。这里会播放一段动画，所以我必须把这套欢迎词说出来。你准备好了吗？我准备好了。第一个问题，有哪两三本书是你发现自己最常推荐给别人的？我很喜欢 How Asia Works。这本书讲的是经济发展的故事，以及什么样的政策和政府能造就长期成功的经济体。另外一本我很喜欢的书是 The Technology Trap。这其实是关于过去几次科技革命的，也就是工业革命和计算机革命，以及它们如何影响了劳动者。我非常喜欢的一点是，我认为我们可以从历史中学到很多，来确保这次转型顺利进行。另外说个轻松的话题，我很喜欢《Paper Menagerie》。这是一本短篇小说集，讲的是成长、AI 和自我发现。最近你最喜欢的一部电影或电视剧是什么？我很喜欢《Drive to Survive》。这背后没有什么深层的含义，我只是觉得，看到人们如此痴迷于一个纯粹的工程目标，以及这种追求的纯粹性，会让人感到非常满足。另外我也很喜欢《Free Solo》，讲的是 Alex Honnold 不系安全带攀登酋长岩的故事。我觉得这两部作品很像，能爬上这条极具挑战、极其危险的路线，本身就是一种非常纯粹的成就。你需要极度专注，因为你知道只要犯一个错，就会丧命。太疯狂了。对，那部电影简直不可思议。有趣的是，这些在某种程度上和你做的工作也有联系。我其实是个攀岩爱好者。但我是在开始攀岩之前看的《Free Solo》。所以当时我觉得很震撼，但并不完全理解它到底有多震撼。这是一部很少见的电影，你对攀岩了解得越多，就越会觉得这简直不可思议。他在岩壁上做的那些动作，就算是在离地面只有一英尺的岩馆里，我觉得我这辈子也做不到。而且还是有保护绳的情况下。有保护绳。你看过那部关于另一个年轻人的纪录片吗？就是去爬冰山的那个？那部非常悲伤。但那部也很疯狂。好了，你最近发现的最喜欢的一款产品是什么？除了云产品之外，最改变我生活的产品大概是 Waymo。我是个 Waymo 的忠实用户，每天上下班各用一次。我很喜欢它的两点：第一，如果 Waymo 在等我，我不会感到不好意思，所以不用给自己压力，必须在它到达的那一刻就站到路边。第二，我觉得它让我效率更高。当我和另一个人同坐一辆车时，我通常尽量不打工作电话，如果全程都在用笔记本电脑，我也会觉得有点不礼貌。但用 Waymo 的时候，我可以拨入工作电话，不用担心有人听到我说话，也不用担心这是不是不礼貌、我是不是说话太大声、要不要请人换个音乐。所以我觉得它每天帮我省出了大概 30 分钟。科技带来的所有这些二阶效应，真的很有意思。是啊，我以前一直觉得 Waymo 要成功，定价必须比 Uber 和 Lyft 低，但实际上我很乐意为它付两倍的价格。我也喜欢 Waymo。就是你第一次坐的时候会觉得，天哪这太疯狂了，然后你就习惯了。刚上车时觉得不可思议，过一会儿就忘了。完全同意。我觉得它还改变了大家的说法。Anthropic 里有很多人喜欢 Waymo，以前大家会说“嘿，叫个网约车吧”，现在每个人都直接问：“Waymo 到了吗？”
好，再问两个问题。你有没有什么最喜欢的人生格言，在工作或生活中经常会想到的？去做就好。说得通。这句不错。我觉得第一性原理思维很有价值。如果你清楚自己的优化目标是什么，并且有扎实的第一性原理，通常就能推导出正确的行动方案，并能向所有利益相关者清晰地阐述，然后你就应该直接去做。我觉得职位头衔都是虚的。如果你理解了约束条件，就能想出你能做什么，然后快速去尝试，从错误中学习，如果做错了就道歉或修正。你就直接去做。这是谁说的来着？其实我觉得告诉大家可以“直接去做”是一种解放。在很多公司里，角色划分得非常严格：产品经理做这个，设计师做那个，工程师做另一个，甚至团队的职责范围也定得很死，比如这块代码我们能碰，那块不能碰。而“直接去做”让人们觉得自己有权做这些决定，有权跨团队边界行事，把事情办成。这感觉是一项非常重要且需要掌握的技能。人们称之为 agency。就是去做那些需要做的事。偏向行动。这些说法都是在描述不要等待许可。对，我觉得这是人生中某个阶段去创业公司工作最让我喜欢的一点。因为我人生中的一个重大转变，是在 Scale 只有 20 人的时候加入的。当时完全没有流程，我们要解决非常大的问题。我非常感激 Alex 和团队的其他成员，赋予我和其他人权力，让我们在没有边界的情况下去解决问题——不用管销售该做什么、运营该做什么、工程师该做什么。你手头有一切工具，面对一个宏大而棘手的问题，你可以做任何需要做的事来找到好的解决方案。就好像你几乎需要那段经历来培养这种技能，才能心安理得地这么做。因为很多人从学校到大学，一路都是“我们让你做什么你就做什么，然后你就能拿高分”。你必须慢慢摆脱这种思维，变成：我要去做需要做的事，即使别人觉得这么做很蠢，只要我认为这是对的。对，没错。好，我还有两个快问快答。最后两个问题。一个是，当 Claude 思考时，会出现一堆……我不知道你们是不是叫它们 verbs。这些该怎么称呼？叫 thinking words。思考词。有趣的是，这些全都在源代码里泄露了。你有最喜欢的思考词吗？嗯，我很喜欢 manifesting。我笔记本电脑上也贴了这个词的贴纸。哦，太棒了。那它显然是赢家了。好，最后一个问题。我也问了 Boris。如果 AGI 可能在我们有生之年到来，到时候你或许不必工作了，你会做什么？你会怎么支配所有时间？我觉得 AGI 要普及到整个社会还需要很长时间。所以我认为做媒体相关的事其实就是在帮助世界跟上这个进程。如果不认真回答的话，等这件事发生之后，我可能会花很多时间攀岩。我或许会搬到枫丹白露，生活在上万块巨石之间，爬上一阵子。还有很多书我想读，我的目标是每周能读一到两本书，现在大概只有 0.5 本。待读书单很长。我觉得历史上有太多我们可以学习的东西，也有太多我希望能更好理解的东西。比如我对物理、机器人、硬件、航空航天一无所知，有太多有趣的话题了。所以，即便知道 AGI 最终都会知晓这一切，我现在依然很期待能学到这些。
Cat，这次访谈太棒了，你很厉害。还有两个后续问题。如果人们想联系你、关注你的动态，在网上哪里可以找到你？以及听众可以怎样帮到你？最好的联系方式是我在 Twitter 上的账号 _catwo。嗯，欢迎大家 @ 我，也欢迎直接给我发私信。我会读所有的私信。虽然不一定每条都回复，但我会全部看完。然后最有帮助的事，是告诉我们 Claude Code 和 Co-work 在哪些方面表现不够好。我们非常感激大家给予的大量正面反馈，但我们真正赖以进步的是边缘案例、错误，也就是那些我们可以复现的、Claude Code 或 Co-work 会出现失败的具体任务。因为如果你能把这些问题分享给我们，而我们也能够复现，那这就是我们可以在下一代模型和下一批配套工具中积极改进的地方。太酷了。Twitter 上的大家分享反馈都很积极，所以请继续保持。是的，请把你们遇到的问题分享给我们，请务必分享。是啊，看到你们整个团队在 Twitter 上这么活跃，还回复大家，真的很酷。所以我的理解是，这些反馈你们确实都会看到并作出反应，对吧。没错，我们很感激大家能这么积极地与我们互动。这给团队带来了巨大的能量。我们有一个“用户喜爱”的频道，每当大家分享成功案例，我们就会发到那里；而每当大家分享产品问题，我们就会放到反馈频道，这样更广泛的团队就能据此采取行动。知道这些太酷了。谢谢你分享这些。好了，Cat，非常感谢你今天能来。谢谢邀请。各位再见。非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。另外，也请考虑给我们评分或留下评论，这确实能帮助其他听众发现这个播客。你可以访问 lennyspodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期再见。