整理 | 华卫
在大多数公司还在按季度推出新产品时，Anthropic 已经把发布节奏压缩到了“按天迭代”。站在这一切背后的，是一名 90 后的华裔女性 Cat Wu。从工程师到 Anthropic 旗下两款王牌产品 Claude Code 和 Cowork 的产品负责人，她不仅亲手推动着这一代 AI 产品的演进，也在面试成百上千位试图进入 AI 领域的产品经理，亲眼见证了哪些人在成功、哪些人已经落后。
Cat Wu 全名是 Catherine Wu，在加入 Anthropic 之前曾做了多年的工程师，还在风险投资领域短暂工作过。据了解，她本科毕业于普林斯顿大学计算机科学专业，曾担任 Scale AI 产品工程师、Dagster 工程经理和 Index Ventures 风险投资人，于 2024 年 8 月加入 Anthropic。2025 年 7 月初，Cat Wu 与 Boris Cherny 两位高管级人物一同被 AI 编程初创公司 Cursor 挖角。约两周后，两人便回归 Anthropic。回归后，他们全面接管 Claude Code 产品线。
“我们许多产品功能的开发进度从 6 个月缩短到了 1 个月，有时候甚至只需要一天。”近日，Cat Wu 在一场深度访谈中表示。她谈到，这种状态在 Anthropic 已持续了好几个季度了。“内部用模型提升了一些效率，更关键的是流程和团队的预期。我们尽量减少流程，移除所有阻碍发布的因素，让每个人都觉得自己可以把一个想法在一周、甚至一天内，变成一个上线的产品。”
而在做产品功能的优先级决策时，他们只围绕一个使命：为全人类带来安全 AGI。“如果 Claude Code 失败了，但 Anthropic 整体成功了，我会非常开心。整个团队也都愿意按照这样的思路来做决策。”有趣的是，Cat Wu 指出，新模型发布时除了解锁全新功能，带给他们更大变化的其实是“删除功能”，因为很多功能原本是为了弥补模型能力的不足。
对于此前 Claude Code 源码泄露一事，她透露“这是一个人为错误”，涉事员工目前仍然在公司工作，“这是流程问题，最重要的是从中学习，增加防护措施，这也是我们现在在做的事情。”
Cat Wu 还分享了 Anthropic 内部当前使用模型 token 的情况。除了工程团队之外，其公司里用 token 最多的是并没怎么出现在外界视线的 Applied AI 团队，他们的工作是帮助客户在公司内部落地 API 和模型能力。此外，她表示，尽管每次模型有明显升级时，人均 token 消耗都会上升。但目前来看，这个成本仍然远低于工程师的平均薪资。并且，内部团队用自家模型也有上限，浪费 token 是不被鼓励的。
以下是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。
发布节奏快到几天，怎么做到的？
主持人： 我想先从你的角色讲起，特别是你和 Boris 的分工。大家都知道 Boris，他创造了 Claude Code，带团队推进，每天从手机上提交无数 PR。我甚至都不知道现在具体是多少了。我觉得大家没有给你足够的认可，其实 Claude Code、Cowork 以及你们正在做的一切的成功，都有你的贡献。能不能帮我们讲讲你在团队里的角色？你和 Boris 是怎么合作的？你们如何分工？在 Claude Code 团队里，PM （产品经理）的角色到底是什么样的？
Cat Wu： 我觉得自己非常幸运能和 Boris 一起工作，他是一个很棒的思维伙伴。他是我们的技术负责人，同时也是产品愿景的提出者，非常擅长定义产品未来的方向，比如三个月、六个月之后产品应该是什么样，甚至是“AGI 完全体版本”的产品形态。
我更多是在思考，从现在到那个三到六个月后的愿景、中间的路径是什么。我花了很多时间在跨团队协作上，比如确保市场、销售、财务、算力等团队都认同这个计划，大家朝着同一个方向前进，同时确保功能准备好之后不会在发布环节被卡住。某种程度上，我们合作得很好，是因为我们有点“脑回路融合”的感觉。但其实边界也挺模糊的，大概 80% 是重叠的，剩下 20% 是我特别在意的部分，我会主导；还有 20% 是他更在意的，他就会主导。
主持人： 之前你提到，你一直在面试大量 PM。如果每次有人找我内推去 Anthropic 当 PM 我能拿一块钱，那我现在可能已经有 300 亿 ARR 了。这是现在大家最想去的公司之一，所以我能想象你面试了多少人。你说很多人其实做错了，他们对“成为一个成功的 AI 产品经理”的理解有偏差。你能讲讲你观察到的问题吗？以及现在到底需要什么能力才能成功？
Cat Wu： 我觉得在 AI 之前，技术变革的节奏是比较慢的。你可以按 6 到 12 个月的周期来规划，而且因为功能发布节奏也比较慢，当时很强调和其他团队的协同，确保他们的功能能为你解锁路径，因为写代码本身是很昂贵的。但现在，AI 大幅提升了工程效率。随着模型能力也在快速提升，我们许多产品功能的开发进度从 6 个月缩短到一个月，再到一周，有时候甚至是一天。在这种情况下，我们需要更快地把产品推出去。
这意味着，作为 PM，你不应该再把重点放在跨多个季度的 roadmap 对齐上，而是要思考：怎么用最快的方式把东西做出来？怎么让一个想法在一周内就能交到用户手中？我觉得在 AI 原生产品中表现最好的 PM，是那些能极大缩短“从想法到用户手中”这段时间的人，同时还能清楚定义，产品中哪些核心任务必须开箱即用。
主持人： 我很喜欢你说的这一点，本质上是很多人还没意识到节奏有多快，以及现在工作中有多大一部分是“帮助团队加速”。那具体怎么做到？你们 PM 团队是怎么帮助团队这么快推进的？
Cat Wu： 第一件事是设定清晰的目标。因为大模型本身很通用，会带来很多模糊性：我们到底在为谁做产品？解决什么问题？最重要的使用场景是什么？一个优秀的 PM 能够明确这些，比如：我们的核心用户是专业开发者；这个功能要解决的问题是权限弹窗太多导致疲劳；我们的目标是让企业里的开发者安全地实现“零权限弹窗”。这样目标就很清晰，也会自动排除很多不必要的方案。
第二，是建立一个可复用的发布流程。比如在 Claude Code，我们几乎所有功能都是以“研究预览”的形式发布。我们会明确告诉用户这是早期产品，是一个想法，还在收集反馈，也可能不会长期支持。这样做的好处是降低了承诺成本，我们可以在一两周内快速上线一个东西。第三，是为团队建立一个协作框架，让大家知道什么时候需要拉跨职能团队以及他们的预期是什么。
我们在工程、市场和文档之间有非常紧密的流程：工程师觉得功能 ready 并完成内部使用后，会发到一个发布频道，文档、PMM、开发者关系团队会立刻跟进，第二天就能发布公告。
这种流程降低了发布摩擦，而 PM 的职责之一就是把这个体系搭建好。
主持人： 那 PRD 在这个体系里是什么角色？你刚刚提到目标很重要，那你们还写 PRD 吗？还是只是简单几条 bullet point？在 AI 时代，这件事是怎么演变的？
Cat Wu： 我们主要做两件事。第一是非常严格的数据指标，每周都会和整个团队一起做指标复盘，确保每个人都深入理解业务的各个方面：核心目标是什么、趋势如何、驱动因素是什么。第二是我们有一套团队原则，包括核心用户是谁、为什么是他们。这样做的目的是让每个人都理解业务运作方式，知道什么重要、什么可以取舍，从而可以自主决策，而不是被 PM 卡住。对于一些特别模糊的功能，我们还是会写一页纸，说明目标、理想使用场景，以及当前需要解决的失败模式。当然，也有一些项目，特别是涉及重基础设施的确实需要几个月时间，那种情况下我们还是会写完整的 PRD。
主持人： 我还想再深入问一下你们为什么能这么快。我从没见过像 Anthropic 这样的发布节奏，几乎每天都有重要功能上线。有个问题是，你们最近做了一个叫 Mythos 的模型，还在预览阶段，因为太强大了，大家甚至有点担心它的能力。你们是不是在内部用了它，这也是你们变快的原因之一？
Cat Wu： 我们已经快了好几个季度了，所以不完全是 Mythos 的原因。它确实非常强大，我们内部也会用模型，这确实提升了一些效率，但不是主要原因。更关键的是流程和团队的预期。我们尽量减少流程，移除所有阻碍发布的因素，让每个人都觉得自己可以把一个想法在一周内、甚至一天内，变成一个上线的产品。
主持人： 太酷了，既有最强模型，又在做产品，这种优势真的很难复制。
Cat Wu： 我们确实很幸运能用到这些前沿模型。
工程师和 PM 的边界正在重叠，“产品感”依然稀缺
主持人： 最近发生了一件事，就是 Claude Code 的源码泄露，大概一周前，有人把代码放出来了。你能讲讲发生了什么吗？
Cat Wu： 我们看到之后第一时间做了调查。这是一个人为错误。当时有人在用 Claude 写 PR，这是一次关于发布流程的更新，而且经过了两层人工审核。最终这是一个人为失误，我们也加强了流程，确保未来不会再发生。
主持人： 那这个人还在公司吗？
Cat Wu： 在的。这是流程问题，最重要的是从中学习，增加防护措施，这也是我们现在在做的事情。
主持人： 还有一个问题是 OpenClaw。最近你们限制了用 Claude 订阅去跑 OpenClaw，社区反应很大，很多人觉得这对开源社区有伤害。你怎么看？
Cat Wu： 我们确实看到对 Claude 的需求非常高，所以一直在努力扩展基础设施，同时优化 token 使用效率，让大家用得更久。但这个产品本来不是为第三方产品设计的，它们的使用模式和我们的一方产品差异很大。我们也花了很多时间思考怎么做一个尽可能平滑的过渡，比如给订阅用户提供额外 credits。但最终我们还是做了一个艰难的决定：优先支持我们的一方产品和 API，这也是这个决策的背景。
主持人： 对我来说这其实很合理。你们一个月 200 美元基本是无限用，但算力成本又这么高，公司还是要赚钱的，不可能一直补贴。回到 PM 团队，你们的团队结构是怎样的？大概有多少 PM？
Cat Wu： 我们现在大概有 30 到 40 个 PM，分成几个团队。有研究 PM 团队，负责收集模型用户反馈，并传递给研究团队，同时也参与模型发布；有云开发者平台团队，维护 Claude Code 的 API，并发布像托管 Agent 这样的能力；有 Claude Code 团队，负责 Claude Code 和 Cowork 的核心产品；有企业团队，负责让这些产品更容易被企业采用，比如成本控制、权限管理、安全等；还有增长团队，负责整个产品线的增长，我们和他们在 Claude Code 和 Cowork 上合作很紧密。
主持人： 说到增长，Amole 最近刚上过我们的播客。他提了一个很有意思、但很少有人讲的观点。现在大家普遍有一种感觉：未来会需要更少的 PM，甚至有人说“还要 PM 干嘛，工程师自己就能发版”。但他的看法正好相反：因为工程师的速度变得太快了，PM 和设计师反而被“挤压”了，每天都有新功能上线，很难跟上节奏。所以他觉得反而需要更多 PM。你怎么看？你觉得未来 PM 的招聘会增加吗？这个职业长期会怎么演变？
Cat Wu： 我觉得各种角色正在融合。PM 在做一些工程的事情，工程师也在做 PM 的事情，设计师既在做 PM，也在写代码。你可以选择招更多有产品感觉的工程师，或者保持工程师数量不变，增加更多 PM 来帮助引导他们的工作。在我们团队，我们更倾向于招聘有很强产品感觉的工程师。这样可以减少产品发布过程中的“摩擦成本”。比如我们团队里有很多工程师，可以从在 Twitter 上看到用户反馈，到一周内直接上线一个产品，中间几乎不需要 PM 参与。我觉得这其实是最高效的方式。
所以我认为工程师和 PM 的边界正在重叠，不管你增加哪一类人，都会带来价值。不过我觉得“产品感”仍然是一个非常稀缺的能力，只要我们看到有人在这方面特别强，就会非常愿意招。
主持人： 你之前是工程师出身，对吧？
Cat Wu： 对，我做了很多年工程师。后来短暂做过风投，然后加入了 Anthropic。实际上，我们团队几乎所有 PM 要么是工程师出身，要么在 Claude Code 上写过代码。我觉得这有助于建立团队信任，也能让我们推进得更快。甚至我们的设计师很多也曾是前端工程师。
主持人： 这正好引出一个关键问题：现在这些角色在融合，很多人会想，如果我是工程、产品或设计背景，到底哪种能力未来最有价值？在你们这里，工程能力显然很重要。但在其他公司，比如设计背景转 PM，会不会更有优势？
Cat Wu： 我还是觉得核心在于“产品感”。随着写代码变得越来越便宜，更有价值的能力变成了：决定“该写什么”。比如这个功能的最佳用户体验是什么？怎样才能让用户感到最愉悦？
我们每天会收到成千上万的 GitHub issue，用户什么都在提。这时候就需要很强的判断力和品味，去决定哪些值得做，以及应该怎么做。这个能力可以来自任何背景，但它是最重要的。我觉得工程背景之所以在接下来几个月特别有价值，是因为它能帮助你判断一件事的实现难度，而这往往会影响优先级。比如，如果一个功能很容易做，那可能就不用讨论太久，直接花一小时做出来；但如果很复杂，你就会意识到它的成本很高，这会影响决策。
“牺牲产品一致性”，团队的人都很“享受混乱”
主持人： 你刚才说“接下来几个月”，是因为模型很快会变得更强，到时候可能连这个判断都不重要了吗？
Cat Wu： 我觉得更准确的说法是：技能的价值变化非常快，很难预测几个月之后会怎样。这不是说某个具体模型会改变一切，而是过去的趋势是，每隔几个月，代码能力就会有一次明显提升，从而改变其他岗位的价值结构。
主持人： 明白，不是某个具体节点，而是变化本身在加速。
Cat Wu： 对。
主持人： 在这样的环境下，人类的大脑在哪些方面还会持续有价值？至少在短期内。
Cat Wu： 我觉得最重要的是“第一性原理思考”。你要能理解技术环境在如何变化，团队现在真正需要你做什么，并主动去填补那个空缺。现在的工作越来越“模糊”，一个优秀的 PM 要能看清所有缺口，判断优先级，然后要么去学习新技能，要么用已有能力去解决问题。所以现在更受欢迎的是那种可以“多角色切换”、愿意承担各种工作的、且不太在意头衔的人。
主持人： 我很喜欢这个回答。我最近一直在问类似你这样的前沿从业者一个问题：在人类还没到超级智能之前，人类大脑的价值在哪里？听你说，核心就是选题、判断方向、做优先级，以及判断一个东西是否“对”。还有把它快速推向市场。是这样吗？还有补充吗？
Cat Wu： 我觉得人类还有一个优势是“常识”。一个产品发布涉及成千上万个细节，有很多可能出问题的地方。模型目前还不太擅长理解所有利益相关方是谁、他们之间的关系、各自的偏好，以及应该通过什么方式沟通。这些更偏“隐性知识”、类似情商的能力，目前仍然很重要。当然我们也希望模型在这方面变得更强，但现在还是有差距。
主持人： 在这样高速变化的环境里，作为一个人，你是怎么保持理智的？感觉像是在龙卷风中心。
Cat Wu： 我觉得我们团队的人都很“享受混乱”。我们会带着笑面对挑战，因为事情永远很多、风险也很多。如果你对每件事都焦虑，很快就会透支。我们更倾向于找那种看到困难会说“这很难，但我很期待解决它”的人。他们会尽力而为，也接受不完美，但能安心睡觉，因为知道自己已经做到最好。
主持人： 这其实也是一种重要能力。有人说，现在就是“世界最正常的时候”，之后只会更疯狂。
Cat Wu： 确实会越来越难。有时候周日晚上有一个 P0 级问题，周一早上又来一个更严重的，到了下午可能出现更夸张的，你就会觉得，昨天那个问题根本不算什么。你只能接受你能做的事情是有限的。你要保证睡眠，才能第二天做出好决策。同时要极度优先级排序，专注最重要的事，并接受有些事情做不好。比如我们有些产品上线时不够精致，但只要不影响核心用户价值，就可以接受，因为我们会快速拿到反馈，在下一次迭代修复。
主持人： 听起来就像《加勒比海盗》里那个场景：船都快炸了，有个人还在优雅地下楼。我接触到的 Anthropic 的人确实都很冷静、很乐观。
Cat Wu： 如果没有这种状态，很容易透支。我们也倾向于招聘那些在行业里经历过很多起伏的人，他们更知道什么能给自己带来能量，以及如何长期保持状态。
主持人： 那在这种角色融合的趋势下，我们会失去什么？比如职业路径、设计一致性、代码质量？
Cat Wu： 我们确实会牺牲一些“产品一致性”。以前代码成本高的时候，你会非常精细地规划整个产品体系，每个产品的定位、使用场景、如何协同，通常一个场景对应一个产品。但现在 AI 发展太快，我们需要测试很多想法，所以有时候会出现功能重叠。很多时候是因为我们内部同时喜欢两种不同形态，希望用户来告诉我们哪种更好。但这对新用户来说会带来困惑：他们不知道完成某个任务的最佳路径是什么。这意味着我们需要做更多用户教育，帮助他们理解核心功能和最佳实践。
另外一个问题是用户会觉得“跟不上”。过去你一个月甚至一个季度才有一次更新，不看也没关系。但现在这些工具发展太快，很多人会每天刷 Twitter 看最新进展。我们也在思考如何让用户不那么焦虑，希望他们打开工具时，工具本身就能引导和教学，而不是让他们感觉在一条越来越快的跑步机上。
主持人： 我看到你们最近上线了一个很有意思的功能，好像叫 /powerup，它会带用户了解 Claude Code 的最佳用法。这是不是为了解决这个问题？
Cat Wu： 对，就是这个思路。其实我们以前不太想做这种 onboarding，因为我们觉得产品应该足够直观，不需要教程。但后来发现功能太多了，而且用户非常希望有一个内置的引导，告诉他们在上百个功能里，最重要的 10 个是什么。所以我们调整了原来的理念，加上了这个功能。
“Claude Code 能失败，但 Anthropic 必须成功”
主持人： Anthropic 这几年的发展非常夸张。一开始其实很落后、融资少、没有分发渠道，OpenAI 遥遥领先，大家都觉得没机会。但现在你们增长非常惊人。站在内部看，你觉得成功的关键是什么？
Cat Wu： 我觉得最重要的是两点。第一，是一个高度统一的使命感。这一点非常关键。我们招聘的是那些真正关心“为全人类带来安全 AGI”的人。而且这不是一句口号，我们在做产品决策时会反复参考这个使命。因为我们把使命放在单一产品之上，所以可以在整个组织层面做出快速决策，并统一执行。这一点在我们这个规模的公司里其实很少见。
主持人： 我再确认一下是否理解正确。也就是说，你们把“安全对齐（确保 AI 对世界有益）”作为第一使命。只要这个使命足够清晰，很多决策其实就更容易做了。比如当有两个优先级冲突时，就看哪个更符合 Anthropic 的使命，然后优先做那个。这样一来，一旦做出决定，大家也都会支持它。
Cat Wu：有时候这也意味着，比如我们想在 Claude Code 上发布某个功能，但发现有更重要的事情，于是就降低这个功能的优先级，推迟到以后再做。
主持人： 这点很有意思。我觉得这也解释了你们和另一家公司 OpenAI 之间的差别，他们做了很多不同的事情。而你们的逻辑是：我们不会去做社交网络，也不会去做信息流，因为这些不符合使命。这种克制让 Anthropic 保持了专注，而这似乎正是成功的关键因素之一。
Cat Wu： 当我谈“使命”的时候，我理解的是把 Anthropic 的目标放在任何个人、任何单个产品之上。对我来说，我们做得第二好的事情其实是“专注”，但使命和专注还是有点不同。使命意味着团队愿意做出牺牲，哪怕会影响自己的目标或 KR，只要这是为了服务 Anthropic 的整体目标和 KR。而且大家是很乐意做这种权衡的。举个极端的例子，如果 Claude Code 失败了，但 Anthropic 整体成功了，我会非常开心。整个团队也都愿意按照这样的思路来做决策。
主持人： 这个问题你可能不方便讲太多细节，但你觉得像 OpenClaw 的决策，是不是也属于这种逻辑？比如说：这个方向没有推动 Anthropic 的使命，所以就要停掉？
Cat Wu： 我觉得对 Anthropic 来说，非常重要的一点是扩大我们能够触达的用户规模。实现这一点的方式之一，是通过 Claude 订阅以及我们的第一方产品。所以我们会非常坚定地加码这些方向，但这有时候确实会以牺牲第三方产品为代价。
Claude 内部 skill 大放送
主持人： 我们刚刚提到了 Claude、Cowork 等产品。我想确认大家能理解这些工具的区别，也很好奇你自己是怎么用的。比如有 Claude Code、Claude desktop 还有 Cowork，到底什么时候该用哪个？
Cat Wu： 我通常会在终端里使用 Claude Code，尤其是当我只是想快速启动一个一次性的编码任务，并且希望用到最新功能的时候。CLI 是我们最早的产品形态，很多新功能也最先在这里上线，所以它是功能最强的一个工具。一般我在同时处理一个或少量几个任务时会用。desktop 更适合需要做前端工作的场景。我很喜欢用它的预览功能，比如我在做一个 web app 时，会同时用 Claude Code 和 desktop，在右侧打开预览面板，这样可以一边和 Claude 对话，一边实时看到网页效果。
对于非技术用户来说，desktop 也更友好。终端对很多人来说很陌生，会弹出各种“看起来很吓人”的提示，也不像其他产品那样可以点击操作。所以如果你不习惯终端，我会非常推荐用 desktop 版的 Claude Code。另外，desktop 还可以提供一个全局视图，你可以看到 CLI 会话、desktop 会话，还有在 web 或 mobile 上发起的任务，是一个统一的控制面板。至于 web 和 mobile，它们最大的优势是“随时随地发起任务”。CLI 和 desktop 都需要你在本地电脑上使用，但现实是你不可能一直带着电脑。
我见过很多人一边在外面走路，一边用手机给电脑热点、还要开着电脑不敢关。这说明我们其实缺一个解决这种场景的产品。mobile 就很好地解决了这个问题，你可以随时发起任务，不需要把电脑带到任何地方。
主持人： 太真实了。我在飞机上都见过这种场景，大家不敢关电脑，就等 Agent 跑完，还得一直连着 Wi-Fi。
Cat Wu： 至于 Cowork，它解决的是另一类问题：很多工作产出并不是代码。比如清空 Slack、清空邮箱、做客户演示用的 PPT、写一个功能目标文档或者发布计划,这些都是“非代码产出”。Cowork 就非常适合这些场景。所以我自己的划分很简单： 如果输出是代码，就用 Claude Code（无论是在 desktop 还是 mobile 上）； 如果输出不是代码，就用 Cowork。
主持人： 我觉得大家有点低估 Cowork 的成功了。它增长非常快，但很多人可能还不太清楚它到底能做什么。能不能结合你作为 PM 的工作，分享一些实际用例？有没有一些比较出乎意料的用法？
Cat Wu： 如果你刚开始用 Cowork，第一步一定是把所有和你工作相关的数据源都接入进去。
因为只有拿到足够的上下文，它才能给出高质量的结果。对我来说，我会连接 Google Calendar、Slack、Gmail、Google Drive，让它可以自由地获取上下文、提取信息、串联线程，这会显著提升结果质量。我举个例子，昨晚我在用 Cowork，因为我们有一个 Code with Claude 的大会，我需要做几场演讲。其中一个演讲主题是：Claude Code 如何从“助手”进化成“真正的 Agent”。我想展示我们发布的产品，以及内部的一些成功案例。
我把 Google Drive 和 Slack 都接入了。我们的产品市场同事 Alex 已经整理了一份初稿，我就把这些材料全部喂给 Cowork，并告诉它我想讲的叙事逻辑。然后它工作了一个小时： 它去看了 Twitter 上我们发布过什么； 查看了内部的发布记录； 翻了 Claude Code 的公告频道（里面有很多团队分享的实际案例）；最后把所有信息整合成了一份 20 页的 PPT。我早上醒来一看，整体质量已经相当不错了。虽然我还是做了一些修改，比如我更喜欢“少字”的幻灯片，而它一开始写得有点多。
但整体速度远远超过我自己做的效率。而且因为它能访问我们的设计系统，这份 PPT 看起来就像是专业设计师做的，非常精致。
主持人： 这简直是 PM 的梦想，做 PPT 太痛苦、太慢了。为了让大家也能尝试一下，你刚才说的步骤是：先接入 Slack、Google Calendar、Gmail、Google Drive，对吗？
Cat Wu： 对，核心是连接你的沟通工具，以及团队的“信息源”。
主持人： 那你当时的 prompt 大概是怎么写的？
Cat Wu： 我其实写得很简单： “帮我做一个 Code with Claude 大会的 PPT，这是 PMM 建议的内容，这是我现在不满意的草稿，还有一个我手动做的版本（附链接）。先给我一个详细的大纲，同时避免和 keynote 重复。”Claude 会先读取这些链接，然后生成一个大纲。我再根据它的建议，决定哪些内容要保留。这其实也体现了现在 PM 的角色： Claude 是一个很强的“头脑风暴伙伴”，能快速整合大量信息并给出多种可能性； 但最终决策仍然由 PM 来做。
我最后确定的结构是： 从“让本地任务成功”，到“让每个 PR 都通过”，再到“帮助工程师提交更多 PR”，每一阶段配对应的 demo。在我确定大纲之后，Cowork 又花了几个小时，把整份 PPT 完整做出来。
主持人： 太棒了。这相当于你在和一个“既懂设计又懂内容”的设计师对话。那设计系统这部分是怎么实现的？它怎么知道 Anthropic 的风格？
Cat Wu： 我们本来就有一套标准的对外演示模板，我直接把这个模板给 Claude。它就能学习我们的配色、字体、版式等，比如我们有大概 20 种常用的幻灯片格式。你也可以连接 Figma 的 MCP，如果你的模板在那里面，它也可以直接读取。
主持人： 说到这里我很好奇，你作为 PM 的工具栈是什么？除了 Claude Code、Cowork，还有什么？
Cat Wu： 我的工具栈主要就是 Claude Code 和 Cowork。Anthropic 基本是围绕 Slack 运转的，我觉得它几乎就是公司的“操作系统”。日常工作中，我大概有 30% 的时间是在不断尝试 Cowork 的边界，看看它哪里做得不好。我也会花很多时间和模型对话，理解它为什么会犯错。另外，我们内部也做了很多工具。Claude Code 最大的一个价值，是大幅降低了开发定制应用的门槛。所以现在公司内部出现了大量“个人化工作软件”，用来解决非常具体的场景，而不是依赖那些不完全适配的通用工具。
主持人： 能举一些例子吗？
Cat Wu： 比如我们 Claude Code 的一位销售同事，他发现自己要反复做类似的客户演示 PPT。于是他做了一个 web app： 内置了几个效果最好的模板（比如 101、201、进阶教程）； 然后可以输入客户信息，这些信息会从 Salesforce、Gong 等系统自动拉取；系统会根据客户情况自动调整内容，比如： 客户用的是 Bedrock 还是企业版 Claude； 他们更关注代码评审还是安全合规； 是否需要 HIPAA 等合规支持；然后自动生成定制化 PPT。原本需要 20–30 分钟的工作，现在几秒钟就完成了。
主持人： 很有意思的一点是，像 Slack 这样的工具，几乎没人尝试替代它。大家都在说 SaaS 要被自建工具取代，但 Slack 反而像是一个不可替代的基础设施。
Cat Wu： 我觉得它确实是非常关键的沟通基础设施，而且在“实时信息同步”这件事上做得非常好。
主持人： 是的，很多人会吐槽 Slack，但它在自己要做的事情上确实做得很好，而且最前沿的团队基本都离不开它，这一点挺有意思的。
Cat Wu： 对，而且我也很喜欢它在“可定制性”上的设计。我们很喜欢做 Slack bot，这种“可 hack 性”让我们可以按自己的方式去集成 Slack。所以在这方面我真的很认可 Slack 的工作。
浪费 token 不被鼓励，内部用自家模型也有上限
主持人： 你刚刚提到很多不同团队，以及他们如何使用 Claude Code 和 Cowork。除了工程团队之外，哪个团队用的 token 最多？我猜工程应该是第一，如果不是那就很有意思了。那第二名大概是谁？
Cat Wu： Applied AI 团队在探索 Claude Code 和 Cowork 的边界方面非常厉害。他们的很多工作是和客户一起，帮助他们落地我们的 API。所以有时候他们会直接帮客户做原型，而 Claude Code 让这个过程比以前快了很多。同时，他们还要处理大量客户沟通，比如客户的需求、历史会议记录等等。所以他们在 Cowork 和 Claude Code 上的使用都非常重。
主持人： 那 Applied AI 团队具体算什么角色？类似前线工程（forward deployed engineering）吗？
Cat Wu： 可以这么理解。他们的工作是帮助客户在公司内部落地我们的 API 和模型能力，无论是用在客户自己的产品上，还是用于内部提效。
主持人： 明白了，就是一种偏技术的 go-to-market / 客户成功角色。
Cat Wu： 对，是一种非常技术化的 go-to-market 角色。
主持人： 所以你觉得他们大概是 token 使用量第二多的团队？
Cat Wu： 是的。而且他们也在不断探索 Cowork 的使用边界。比如很多人同时负责多个客户，一天可能有 5 到 10 场客户会议。于是他们会在前一天晚上用 Cowork 做准备：“帮我总结明天所有客户会议，每个客户关注什么、提出过什么需求、之前的行动项是什么。”Cowork 会自动生成一份“作战简报”，帮助他们快速进入状态。另外，如果客户在会议中问：“某个功能什么时候上线？” Cowork 甚至可以去 Slack 里查最新进展，给出最新 ETA，并补充进会议资料。这些其实都是大家自己搭出来的工作流，并在团队内部分享。
主持人： 太酷了。最近有个很有意思的趋势：有些人用 AI 的 token 成本，已经超过了他们自己的工资。Anthropic 内部有没有类似的数据？比如工程师或 PM 每天、每月大概用多少 token？
Cat Wu： 我们确实观察到，随着模型能力提升，人们会把更多任务交给它，也会在 Claude Code 和 Cowork 上花更多时间。所以每次模型有明显升级时，人均 token 消耗都会上升。目前来看，这个成本仍然远低于工程师的平均薪资，但这个比例是在持续增长的。
主持人： 你们还有一个很大的优势，就是可以用最先进的模型，而且 token 基本不限量，对吧？
Cat Wu： 我们可以用很多 token，不过确实也会有人遇到限制。
主持人： 原来还是有上限的。
Cat Wu： 我们非常重视让内部团队尽可能快地开发，同时也相信大家理解模型运行的成本，并且会负责任地使用 token。浪费 token 是不被鼓励的，但我们信任每个人做出判断。
主持人： 回到 PM 这个角色。你刚刚提到了一些，我想再系统问一下：现在 AI 公司最看重 PM 的哪些新能力？
Cat Wu： 最难的一项能力，是定义“一个月后的产品应该是什么样”。因为在这个时间尺度上，模型能力和用户行为都存在很大不确定性。但优秀的 PM 能从用户如何“突破产品边界”中看到模式，然后设定方向，并持续推进。如果模型能力变化超出预期，也能及时调整。
还有一点很难：你需要对 AGI 有“恰到好处”的信仰。大家都能想象一个未来：模型非常强大，几乎无所不能，那产品甚至可以退化成一个文本框。但真正困难的是： 在当前模型能力下，如何最大化它的潜力？ 如何引导用户走上“最佳路径”？ 如何放大它的优势、弥补它的弱点？这种能力其实非常稀缺。
主持人： 那这种能力怎么培养？是不是要大量使用模型、理解它的边界？
Cat Wu： 对，就是要大量和模型互动。我很喜欢做的一件事是让模型“自我反思”，
比如有时候模型做了一些奇怪的事情，我会问它为什么这么做。它可能会说： 是 system prompt 有歧义； 或者没意识到前端验证是任务的一部分； 或者把任务交给子 Agent，但没有检查结果。这种分析可以帮你理解它哪里被误导，从而优化系统。
另外一个重要点是找到你信任的“反馈来源”。不是所有用户的反馈都同样有价值。通常会有少数几个人，特别擅长判断模型表现。找到这 5 个人非常关键。第三点是做 eval。你不需要做上百个 eval，只需要 10 个高质量的，就能帮助团队明确目标、衡量进展。这是一个被严重低估的工作，更多 PM 和工程师应该参与。
上线新模型后，做的更大变化是“删除功能”
主持人： 很多人都在说，产品经理的未来就是写 eval，本质上就是定义“成功是什么”。
你大概花多少时间在这上面？
Cat Wu： 这取决于具体问题。有些团队会投入很多时间做 eval。我们有一个小团队专门和 research 合作，精细分析模型行为。我个人通常是在某个功能需要更清晰定义时才会参与，比如做 5 个 eval，说明怎么跑、哪些成功、哪些失败，以及如何优化 prompt。像 memory 这种功能，就特别依赖 eval。
主持人： 你刚才提到 Claude 的“性格”。我之前采访过联合创始人，他也强调这一点。很多人一开始会觉得这只是“有趣”的附加项，但其实它是 Claude 成功的核心。你怎么看？
Cat Wu： 你可以想想现实中的同事，有些人就是让你觉得“很喜欢和他一起工作”。Claude 也是一样。大家喜欢它，是因为它： 轻松、有趣； 但同时非常专业； 没有 ego； 愿意承认错误； 态度积极；比如当你觉得任务很难时，它会说：“没关系，我们一步一步来，要不要我先帮你开始？”优秀同事的特质是积极、主动、真诚反馈，我们都在努力注入到 Claude 中。
主持人： 你提到新模型发布后，往往要重新思考产品，这听起来既有趣又让人崩溃。这种情况多频繁？
Cat Wu： 其实更大的变化是“删除功能”。因为很多功能原本是为了弥补模型能力不足。比如早期的 to-do list： 模型在做大规模修改时会漏掉步骤，所以我们加了任务列表来强制它执行完。但在新模型里，它已经能自然完成这些步骤，所以这个功能就不再那么重要了。我们每次发布新模型，都会重新检查 system prompt，把不再需要的部分删掉。
主持人： 所以模型会“吃掉”你之前做的那些产品层补丁？
Cat Wu： 对。但更令人兴奋的是：新模型也会解锁全新功能。比如 code review，我们尝试了很多次，直到最近模型足够强，才真正达到可用水平。现在我们甚至可以并行运行多个 code review Agent，扫描整个代码库，输出高质量问题。
主持人： 最后聊一下愿景。Claude Code 和 Cowork 的长期方向是什么？
Cat Wu： 我们是从“任务”这个基本单元来思考的。第一步，是让单个任务稳定成功。随着模型变强，任务成功率提升，人们开始同时运行多个任务。下一步可能是：同时运行几十、上百个 Claude。这时候问题就变成： 如何管理这些任务？ 如何构建界面，让人类知道该关注哪些？ 如何确保 Agent 已经完成并验证了工作？ 如何建立反馈机制，让系统持续自我改进？
这就是我们在思考的长期方向。
95%自动化价值不大，过度优化配置效果也更差
主持人：有很多人在听这个节目，包括很多产品经理、创业者，还有各种跨职能岗位的人。大家现在都很担心自己的角色，以及未来的职业发展。你会给大家什么建议？不仅是如何在这个高度 AI 驱动的世界里生存下来，而是如何真正取得成功、实现“蓬勃发展”？你觉得大家应该听到什么、又该做些什么？
Cat Wu：我觉得 AI 给了每个人比过去大得多的杠杆。所以我会建议你：每当你意识到自己在反复做某个手动任务时，就去思考，能不能用 Claude Code、Cowork 或其他 AI 工具把它自动化掉。大多数人的工作里都有一部分是他们非常喜欢的创造性内容，同时也有一些他们非常讨厌、很繁琐的部分。而 AI 的美妙之处就在于，它可以帮你处理这些枯燥的工作。它可以从你每一次做这些手动任务中学习，总结规律，然后自动执行，这样你就能把精力集中在更有创造性的部分上。这意味着你能做的事情会比以前多得多。
所以我最直接的建议是：找出那些可以交给 Claude 去做的重复性工作，不断去迭代这些能够自动化的工作流，直到成功率很高，接着，去思考你还能为团队、产品、公司做些什么，那些以前因为没有时间或精力而一直搁置的事情，或者有没有什么你一直觉得公司应该做、但从来没有时间去做的项目？如果 AI 能帮你处理掉那些“苦活累活”，那你就相当于多出了 20% 的时间。我的建议是：拥抱这些工具，把你不喜欢做的工作交出去，找到它们如何加速你的方式，然后你就能做得更多。
主持人：你刚刚说的一个核心点，我非常认同，就是用 AI 去解决问题。现在工具很多、潜力很大，但对很多人来说，最难的是到底该做什么？你这里的建议其实是：留意那些你反复在做、可以自动化的事情；以及那些一直想做但没时间做的想法。本质上就是为自己解决问题，对吗？
Cat Wu：对，完全正确。我还会建议大家：把自动化从“这是个不错的概念”，推进到“它真的 100% 可用”。我有时会看到用户把某个流程自动化到 90% 或 95%的程度，然后就放弃了。但如果不能做到 100% 自动化，那它其实就不算真正的自动化。最后那 5% 到 10%，往往需要更多时间。而且，构建自动化的过程，也比你手动去做还慢。但我还是鼓励大家，选一个你真的很想做到 100% 自动化的事情，投入足够的精力去打磨它：教模型你的偏好，给它反馈，让它不断提升，直到达到 100%。只有这样，你才能真正信任它。一个 95% 程度的自动化工作，其实价值不大。
主持人：我完全中枪了，这对我来说是非常好的建议。
Cat Wu：我自己也是这样。我最近在教 Cowork 帮我把 Gmail 做到 inbox zero，但这个过程非常耗时，而且确实还远远没达到理想状态。
主持人：太巧了，我也是。我做了一个自动分类邮件的流程，把那些“垃圾请求”（比如想上播客之类的）自动分类到一个文件夹里。它大概 95% 都是对的，但偶尔会漏掉重要邮件。
所以你这个建议很好，我要把它做到完美。
Cat Wu：我们其实也在努力让这些自定义流程更容易使用。现在的流程确实有点复杂：你要定义一个 skill，要学会调用它、给它反馈，还要让 Cowork 根据反馈更新这个 skill，最后还要检查更新结果。这也是我们的责任，让整个流程变得更顺滑，而不是让人觉得痛苦。
主持人：太棒了。Cat，还有没有什么你想补充的？或者有什么想特别强调的，在我们进入最后的快问快答之前？
Cat Wu：我看到很多人在用 AI 做各种尝试，比如做原型应用、或者搭建一些工作流。但我更建议大家：去做那些你每天都会用的应用。因为只有在真正使用中，你才能获得价值。如果你只是做了一个原型，但它并没有帮你提高效率，那 AI 实际上并没有为你带来价值。那种“一次性做个东西，觉得挺酷，然后就再也不用”的方式，你学到的东西其实很有限，也没有真正获得杠杆。
主持人：这是个很好的观点。我还注意到另一种极端：有些人会花很多时间去定制自己的工作流。有一类人从不做自动化，但另一类人则是过度优化工具，加各种 skill、MCP、工作流优化。有时候，这反而会让人偏离最初的目标，比如真正发布产品或做出功能。
Cat Wu：对，我也这么觉得。定制这些东西确实很有趣，我们也希望产品足够“可 hack”，让你能按自己的方式使用。但它是有一个边界的。我看到有些人花太多时间在定制上，甚至不睡觉，反而忽略了最初想完成的核心任务。
主持人：我在 Twitter 上也看到很多这种情况，“看我的配置，多么极致优化”。但问题是，你到底在做什么？
Cat Wu：其实很多时候，简单的配置反而更有效。
主持人：说到这个，我昨天看到 Andrej Karpathy 发了一条推文，说现在有一个很有意思的分裂：一类人是早期用过 ChatGPT 或 Claude，但觉得“也就那样”，然后就放弃了，对 AI 持怀疑态度；另一类人则是用它来写代码的人，真正看到了它的威力。这两类人彼此完全无法理解对方。所以你的建议其实很关键，要用它做真正的事情，才能理解它的能力。
Cat Wu：对，我觉得一个很大的转变是：2024 年的产品大多是“对话式”的，而现在 Claude Code 这一代产品是“行动式”的。真正的“顿悟时刻”是，当 Claude 能够替你执行任务的时候。当你意识到，它不仅能告诉你该怎么做，还能直接帮你做，那种感觉是非常震撼的。
主持人：没错。我还想提一个 Chrome 插件，你可以看着 Claude 自动操作，比如“帮我填这个表单”，然后它就真的去做了。
Cat Wu：对，就是这种感觉。
闪电问答环节
主持人：Cat，欢迎来到闪电问答环节。准备好了吗？
Cat Wu：准备好了。
主持人：有没有两三本你最常推荐给别人的书？
Cat Wu：我很喜欢《How Asia Works》。这本书讲的是经济发展，以及哪些政策和政府能够打造长期成功的经济体。另外我很喜欢《The Technology Trap》。这本书讲的是过去几次技术革命，比如工业革命和计算机革命，以及它们对劳动者的影响。我喜欢这本书的原因是，我觉得我们可以从历史中学到很多东西，从而让这次转型走得更顺利。如果说轻松一点的，我很喜欢《The Paper Menagerie》。这是一本短篇小说集，讲成长、AI，还有自我探索。
主持人：最近你很喜欢的一部电影或电视剧是什么？
Cat Wu：我很喜欢《Drive to Survive》。没有什么特别深的意义，我只是觉得，看一群人如此专注于一个工程目标，那种纯粹的追求特别让人满足。我也非常喜欢《Free Solo》，讲的是 Alex Honnold 无保护攀登酋长岩的故事。我觉得这同样是一种非常纯粹的成就，攀登这样一条极其困难、危险的路线，同时还要保持极致的专注，因为一旦犯错就会死亡。这真的太疯狂了。
主持人：那部电影确实很震撼。而且挺有意思的是，这些好像也和你的工作有点关联。
Cat Wu：其实我自己也攀岩。我是在还没开始攀岩的时候看了《Free Solo》，当时觉得很厉害，但没意识到有多厉害。这是那种你了解越多，就越觉得不可思议的作品。他在岩壁上的那些动作，就算是在离地一英尺、有绳索保护的室内攀岩馆里，我这辈子可能都做不到。
主持人：对，就算有绳子都很难。你看过那个讲另一个年轻攀登者去攀冰山的纪录片吗？
Cat Wu：看过，那部挺让人难过的，但也非常震撼。
主持人：好，下一个问题：最近有没有一个你特别喜欢的新产品？
Cat Wu：如果不算我们自己的产品，对我生活改变最大的大概是 Waymo。我是它的重度用户，每天通勤都会用。我最喜欢它的两点：第一，如果车在等我，我不会有负担感，所以不会有那种“必须马上冲到路边”的压力。第二，它让我更高效。当我和真人司机同车时，我通常不会开工作会议，也不太好意思一直用电脑。但在 Waymo 里，我可以直接参加电话会议，不用担心被人听到，也不用担心礼不礼貌、声音大不大、要不要让人换音乐。我感觉它每天帮我节省了大概 30 分钟。
主持人：这些技术带来的“二阶效应”真的很有意思。
Cat Wu：是的。我以前一直觉得 Waymo 必须比 Uber、Lyft 更便宜才会成功，但现在我其实很愿意为它支付两倍的价格。你第一次用会觉得“这太疯狂了”，但很快就习惯了。而且它甚至改变了大家的表达方式。在 Anthropic，大家以前会说“叫个打车软件”，现在直接说“Waymo 到了吗？”
主持人：你有没有一个经常回到的生活或工作信条？
Cat Wu：就是：直接去做。我觉得“第一性原理思考”很重要。如果你知道自己在优化什么，也有清晰的基本原则，那你通常能推导出正确的行动方向，并清楚地向所有相关方解释。然后你就该去做。我觉得“职位”这种东西其实是虚构的。如果你理解了约束条件，你就可以判断自己能做什么，然后尽快去做，从错误中学习，如果做错了就道歉或修正。你真的可以“直接去做”。
主持人：谁说的这句话我不知道，但确实很解放人。
Cat Wu：我觉得在很多公司里，角色是被严格定义的：这是 PM 的工作，这是设计师的，这是工程师的，甚至连团队边界都很严格。而“直接去做”让人有勇气跨越这些边界，去把事情完成。
主持人：这其实是一种很重要的能力，有人叫它“主动性”或者“行动导向”。
Cat Wu：对。我觉得这也是我建议大家在职业生涯中某个阶段去创业公司的原因。我有一个改变人生的经历，是在 Scale 只有 20 人的时候工作。当时几乎没有流程，但问题很大。我很感谢 Alex 和团队，他们让我们可以没有边界地去解决问题，不管是销售、运营还是工程，你都有所有工具，可以用任何方式去解决一个复杂的问题。
主持人：很多人需要这样的经历，才能培养这种能力。因为在学校里，我们习惯了“按要求完成任务就能拿高分”，但现实不是这样。
Cat Wu：完全同意。
主持人：好，我再加两个快问。第一个是：Claude 在“思考”时有很多“思维词”（thinking words），你有最喜欢的吗？
Cat Wu：我很喜欢“manifesting”。我甚至还有一个贴纸。
主持人：我也问过 Boris，如果 AGI 在我们有生之年实现，你可能不需要工作了，你会做什么？
Cat Wu：我觉得 AGI 在社会中的普及会需要很长时间。短期来看，我可能会去帮助这个世界适应它。如果说轻松一点的答案，我大概会多去攀岩。可能会搬到 Fontainebleau，住在成千上万块巨石之间，天天攀岩。还有很多书我想读。我希望能做到一周读一两本，现在大概只有半本。我的“待读清单”很长。我觉得历史里有太多可以学习的东西，而我还有很多领域不了解，比如物理、机器人、硬件、航天等等。所以我很期待去学习，即使 AI 已经知道这些。
主持人：最后两个问题：大家可以在哪里找到你？以及听众可以怎么帮到你？
Cat Wu：最好的方式是在 Twitter 找我，我的用户名是 Catwoo。可以 @ 我，也可以私信我。我会看所有私信，虽然不一定每条都回复。对我们来说，最有帮助的是：告诉我们 Claude Code 和 Cowork 在哪里做得不好。我们非常感激正面的反馈，但真正让我们进步的是那些边缘案例、错误，以及那些可以复现的失败任务。如果你能把这些分享给我们，并且我们能复现，那我们就可以在下一代模型和系统中改进它。
主持人：太好了，大家在 Twitter 上从来不吝反馈，所以继续多提问题吧。
Cat Wu：是的。而且看到大家这么积极参与，我们团队也会非常有动力。我们有一个“用户喜爱”频道，会分享大家的成功案例；也有一个反馈频道，会收集问题，让整个团队都能看到并行动。
主持人：太棒了，谢谢你的分享。
参考链接：
https://www.youtube.com/watch?v=PplmzlgE0kg
