天弘优配深度｜Claude Code产品负责人：面试了上百个PM后发现，大多数人还在用互联网时代的逻辑应聘AI公司

Cat Wu 是 Anthropic Claude Code 与 CoWork 的产品负责人，也是站在 AI 原生产品第一线的人。

这期 Lenny’s Podcast 表面上聊的是 Claude Code、CoWork、Anthropic 的产品方法论，但真正的看点其实更尖锐：当 AI 开始接管代码、文档、PPT、邮件和客户简报，产品经理到底还剩下什么？当一个团队每天都能发新功能，传统互联网时代那套半年路线图、PRD、跨部门排期，还能不能继续成立？

Cat Wu 给出的答案很直接：AI 没有让产品经理消失，而是把产品经理重新推回了最核心的位置——判断、品味、取舍，以及在不确定中定义方向。

1. AI 时代，产品经理最重要的能力是判断“一个月后的产品应该长什么样”。过去产品规划看半年、一年；现在模型能力几周一变，用户行为也在不断漂移。稀缺的 PM，是能在混沌里提前看见下一步的人。

2. 代码越来越便宜，产品品味反而越来越贵。当 Claude Code 这类工具让工程实现成本急剧下降，竞争的核心就从“能不能做出来”变成“该不该做、怎么做才对”。

3. 为超级 AGI 设计产品很简单，为今天这个“不完美的 AI”设计产品才难。想象一个无所不能的 AGI，只需要一个输入框就够了。但现实是，模型仍会犯错、会误解、会中断。真正考验产品团队的，是如何在模型还没抵达终局时，把它包装成一个真正好用、可信、可交付的产品。

4. 95% 的自动化，其实不叫自动化。如果一个 AI 工作流不能做到 100% 稳定，它就不能被真正信任。

5. Anthropic 跑得快，不只是因为模型强，而是因为组织被改造成了“高速发布机器”。功能可以先以 research preview 上线，工程师可以从用户反馈一路跑到发布，市场、文档、开发者关系团队第二天就能接上。AI 时代的产品竞争，不只是模型竞赛，也是组织速度竞赛。

6. 产品经理、工程师、设计师的边界正在被 AI 打碎。在 Claude Code 团队里，PM 要懂代码，工程师要有产品品味，设计师也要能参与实现。未来真正有价值的人，不是守住岗位说明书的人，而是看到哪里缺人、哪里卡住，就能立刻补位的人。

7. Agent 的拐点，不是“更会聊天”，而是“真的能替你干活”。2024 年的 AI 产品还是对话框，2026 年的 AI 产品已经开始进入行动层。用户真正的震撼时刻，不是 AI 给出一个好建议，而是它真的帮你写完代码、做完 PPT、整理完客户简报。AI 从“回答问题”变成“完成任务”，这才是认知断层真正开始的地方。

AI产品经理：岗位变革与核心能力重构

Lenny：今天我们邀请到的嘉宾是Cat Wu，她是Anthropic Claude Coding的产品负责人。Cat正站在AI、产品以及如何构建产品这场变革的最前沿。她和团队打造的产品，正在深刻改变我们每个人做产品的方式。她有非常多值得分享的洞见、经验和思考，这是一期绝对不容错过的节目。在开始之前，别忘了访问Lenny’s Newsletter,那里有一系列专门为订阅者准备的超值优惠。接下来，让我们欢迎Cat Wu来到节目。

Cat Wu：谢谢邀请。

Lenny：我有很多问题，也非常期待这次对话。我们先从一个背景问题开始：能不能帮大家理解一下，你和Boris Cherny在团队中的分工？大家应该都很熟悉Boris Cherny,他的那期节目是本播客最受欢迎的一期。他打造了Claude的Claude Code，带领团队高速推进开发，甚至可以用手机完成大量代码提交。但与此同时，我觉得很多人低估了你在Claude Code，以及你们整个团队所构建的一切中的关键作用。

所以也想借这个机会，请你详细讲讲：你在团队中的角色是什么？是如何与Boris Cherny协作的？你们是如何划分职责的？以及，在这样一个团队中，产品经理的角色具体是怎样运作的？

Cat Wu：我很幸运能和Boris Cherny一起工作，他是一个非常出色的思维伙伴，也是我们的技术负责人和产品愿景制定者。他很擅长定义产品未来的样子，比如三个月、六个月之后产品应该发展成什么样，以及那种AGI导向的理想版本是什么。而我的工作更多是在思考，从我们现在所处的位置，如何一步步走到三到六个月后的那个愿景，我也会花很多时间在跨团队协作上，确保市场、销售、财务、资源等各个团队都认可这个计划，大家朝着同一个方向推进。同时也要确保当功能准备好之后，不会在上线环节遇到任何阻碍。

我们合作顺畅，很大原因是思路一致，但分工其实没有明确边界。大约80%的事情是我们共同关心、一起推进的，剩下20%里，有一部分是我更在意的，由我来主导，另一部分是他更在意的，由他来负责。

Lenny：你刚刚提到一直在面试大量产品经理，这一点让我很有感触。如果每次有人请我推荐去Anthropic做产品经理我都能收费，那我可能已经有300亿美元ARR了。可以说，这是现在最受欢迎的公司之一。所以我很好奇，你在面试中到底看到了什么问题。你提到，很多人理解错了成为一名优秀AI产品经理所需要的能力，能不能展开讲讲你的观察，以及今天真正成功需要具备哪些关键点？

Cat Wu：在前AI时代，技术演进较慢，产品规划通常基于6到12个月。由于交付节奏较低，产品经理更强调跨团队协同与路线图对齐，以确保依赖能力能够按时提供支持，这在代码成本较高的背景下尤为重要。随着AI带来的工程效率提升以及模型能力的快速进化，产品开发周期被显著压缩，从半年缩短到一个月，甚至一周或一天，这要求产品具备更高频的发布能力。

因此，产品经理的核心职责也在转变，从以跨团队对齐为中心，转向以最快交付为核心。关键在于构建机制，使想法可以被快速验证并上线，例如建立快速实验通道，让创意在一周内触达用户。在AI原生产品环境中，优秀产品经理的关键能力在于缩短从构想到交付的周期，并定义出产品中最关键、必须即刻可用的核心功能。

Lenny：这个观点特别有意思，本质上是在说，很多人还没有适应现在这种速度，也没有意识到，产品经理工作的核心已经变成了推动速度。那我很好奇，你们具体是怎么实现这一点的？你和你的团队都做了哪些事情，来让团队可以跑得这么快？除了模型本身，还有哪些关键做法？

Cat Wu：因为LLM太通用了，反而会带来很多模糊空间，比如我们到底在为谁做产品、要解决什么问题、最核心的使用场景是什么，优秀的产品经理首先要做的是把这些问题讲清楚。比如，你可以明确：我们的目标用户是专业开发者，这个功能要解决的问题是权限提示太多，导致用户疲劳。目标场景是，让企业开发者在安全前提下实现零权限提示。这样一来，目标就变得非常清晰，同时也自然排除了很多不合适的方案，让团队能更聚焦。

第二个关键点是，要建立一套可复用的发布机制。像Claude Code，我们几乎所有功能都是以研究预览的方式上线，我们会明确告诉用户，这是一个早期想法，正在收集反馈，未来不一定长期支持。这样做的好处是，大大降低了发布的心理负担，很多功能可以在一到两周内快速上线。

第三点是，产品经理需要搭建一个清晰的协作框架，让团队知道什么时候需要引入市场、文档等跨职能角色，以及他们的工作预期是什么。比如内部有一套非常紧密的流程：当工程师觉得功能准备好了，并且已经内部验证过，就会发到一个固定的发布渠道。然后文档、产品营销、开发者关系团队会立刻接入，甚至可以在第二天就完成对外发布。正是因为这套机制足够顺畅，工程师发布功能的阻力被降到很低，而建立这种机制，本身就是产品经理最重要的职责之一。

Lenny：那PRD在这个过程中扮演什么角色？你刚才说目标很重要，本质上就是在对齐成功标准，以及明确这个产品是为谁做的、不为谁做。那你们现在还会写PRD吗？还是更多是用几条关键要点来表达？在现在这种环境下，PRD的形式和产品经理的工作方式发生了哪些变化？（ZP注：PRD就是用来说明“要做什么产品、解决什么问题、怎么做”的文档。）

Cat Wu：我们主要做两件事。第一，我们有一套非常严格的指标体系，并且每周都会和全团队一起做数据复盘。目的就是让每个人都真正理解业务的全貌，包括核心目标是什么、当前的趋势如何，以及背后的驱动因素。

第二，我们会明确一套团队原则，比如核心用户是谁、为什么是他们。之所以要把这些讲清楚，是为了让团队里的每个人都理解业务逻辑，知道什么最重要、哪些是我们愿意做的取舍。这样一来，大家就可以自己做判断和决策，而不是每件事都要依赖产品经理或者其他角色，从而避免被卡住。

Lenny：我很喜欢你刚才讲的这些，因为它其实在说明一件事：未来我们还是需要产品经理的。现在外面有很多声音在说，是不是只靠工程师就可以不断开发和上线产品，不再需要产品经理了。

Cat Wu：我们其实还是会写PRD。对于特别模糊的功能，写一页纸说明目标、令人愉悦的用例和当前失败模式，有帮助。有些项目，尤其基础设施密集型，可能要花几个月，仍会写PRD。

Lenny：我想再深入探讨一下你们如何能这么快。我从未见过Anthropic这样的发布节奏。有人做了个全公司的发布日历，几乎每天都有重大功能或产品。一个网上问题是，你们刚发布了令人难以置信的模型——Mythos，还在预览阶段因为太强大，人们有点怕。你们内部用这个模型吗？这是你们能如此快的原因之一吗？

Cat Wu：我们已经快了好几个季度了，所以不只是Mythos的原因。Mythos非常强大，我们内部确实用模型，这提高了发布速度一点，但不是主要原因。主要是流程和团队期望。我们流程极少，要消除所有阻碍发布的障碍，确保团队中的每个人都有能力把自己的想法从概念到发布在不到一周内完成，有时甚至一天。

Lenny：有最好的模型，同时还以这种速度构建产品，真是巨大优势。

Cat Wu：我们很幸运能与前沿模型一起工作。

Lenny：真是巨大优势。构建东西，然后使用它再加速，太有意思了。有几个话题我想聊聊，一周前Claude Code的完整源代码泄露了，有人把它放出来了，可能是失误。你有什么看法吗？发生了什么，哪里出错了，大家应该知道什么？

Cat Wu：我们看到后立刻调查，意识到这是人为错误。有人用Claude辅助写PR，是更新我们发布包的方式。实际上经过两层人工审核。这完全是人为错误，我们已经加固了流程，防止未来发生。（ZP注：PR是软件工程中的标准流程，指代码变更提交后进入评审并合并至主分支的过程。）

Lenny：这个人还在Anthropic吗？还好吗？

Cat Wu：是的，没事。这是流程失误，最重要的是从中学习，增加更多防护措施。我们已经在做这些，大部分已经上线。

Lenny：另一个问题关于Open Claw。最近有举措阻止人们用Claude订阅使用Open Claw。很多人不满，困惑为什么，感觉对开源社区造成了伤害。人们需要理解这个决定背后的考量是什么？

Cat Wu：我们看到了对Claude的巨大需求，一直在努力扩展基础设施，同时让防护栏更token高效，让用户能获得更多使用量。Claude订阅不是为第三方产品设计的，它们的使用模式与第一方产品不同。我们花了很多时间试图找出最平滑的过渡方案。很高兴我们能让每个订阅者获得一些credits。但我们必须做出艰难决定：优先保证第一方产品和API。这就是决定的来源。

Lenny：在我看来这很合理。你们以每月200美元的价格补贴这种使用，基本上是无限使用。我觉得人们不理解商业运作——需要赚钱，需要盈利。不能免费送出这么紧缺的算力。回到产品经理团队，Anthropic的产品经理团队是什么样？有多少产品经理？怎么组织的？

Cat Wu：我们有几个产品经理团队，大概30到40个产品经理。有research产品经理团队，由Diane领导，负责收集客户反馈并反馈给研究团队，同时负责模型发布流程。Claude Developer Platform团队，维护Claude Code构建其上的API，也发布managed agents。Claude Code团队，负责Claude Code和CoWork核心产品。企业团队帮助大型企业客户采用产品，包括成本控制、RBAC、安全控制等。增长团队负责全产品套件增长，与Claude Code和CoWork紧密合作，也参与CDP用户增长。

Lenny：说到增长，Ilya不久前上了播客，他有一个大多数人不分享的洞见：大家觉得未来需要更少产品经理，他认为因为工程师太快，产品经理和设计师被挤压，很难跟上每天发布的功能，所以他需要更多产品经理。你怎么看？长期来看产品经理职业会扩招吗？

Cat Wu：所有角色都在融合。产品经理做一些工程工作，工程师做产品经理工作，设计师做产品经理M工作，也参与提交代码。你可以选择招聘更多有出色product taste的工程师，或保持工程招聘不变，招聘更多产品经理指导他们的工作。我们团队专注于招聘有出色product taste的工程师，这样可以减少发布产品的开销。团队有很多工程师能够端到端，从看到Twitter用户反馈到周末前发布产品，几乎不需要产品经理参与。我认为这是最高效的发布方式。Product taste仍非常稀缺，任何在此方面表现强的人，我们几乎都会雇佣。

Lenny：你的背景是工程，对吗？

Cat Wu：对，我做了多年工程师，也在VC短暂待过，然后加入Anthropic。团队几乎所有产品经理要么以前是工程师，要么现在在Claude Code写代码。这有助于建立团队信任，也让我们更快。设计师也有前端工程背景。

Lenny：对于来自工程、产品或设计背景的人，哪个核心技能最有价值？

Cat Wu：我仍然觉得，归根结底还是产品品味。当编写代码的成本骤降，决定写什么才变得更有价值。比如：这个功能怎样设计UX才对？用户怎么用才会觉得最爽？我们收到上万条GitHub需求，五花八门。要从里面挑出哪些值得做，并且选对实现方式，是需要很多心思和品位的，这项能力可以来自任何背景，但我认为它才是最重要的。工程背景之所以在至少未来几个月里特别有用，是因为有工程背景，对事情的难度会有更准的感觉，而这常常影响着选择。要是某个东西实现起来很容易，那还讨论什么，花一小时直接搞定，但如果一早就知道它比较难，知道把这东西交付出去，团队代价会大很多，那这就能更好地排优先级了。

Lenny：你提未来几个月，是不是在说模型在这段时间可能突飞猛进，到时候可能就不需要掌握那些东西了？

Cat Wu：重要的技能变得太快，几个月后的事根本猜不准。所以我这话的重点，不是预测会有什么转变，而是强调转变一定会很大。

Lenny：所以，不是在说等到那个叫Mythos的东西出来，就会彻底改变一切，我们都不用懂工程了吧？

Cat Wu：不是，好像每隔几个月，编程能力就会猛增一截，然后其他角色的含金量也跟着变。最关键的，就是要有第一性原理的思考方式，能看清技术版图在怎么变，团队到底缺什么，然后二话不说冲上去补位。因为工作边界越来越模糊，一个厉害的产品经理就得明白所有缺口在哪，锁定最高优先级的那个，再去琢磨：行，我怎么把这项技能学到手？或者手里有什么本事可以拿来解决这个难题？所以，当下最需要的是那种能身兼数面、随时换挡、而且对活儿不分贵贱、一心帮团队加速的人。

Lenny：我喜欢这个答案。我一直在问你们这些AI前沿玩家：超级智能到来前，人脑暂时还有用武之地的地方在哪？听下来就是两点：一是决定做什么、看准市场、定优先级；二是判断产品好不好、对不对，再把它推出去，哪怕只是个早期版本。对吗？未来几个月里，人脑还能在哪些方面继续发挥价值，还有没有要补充的？

Cat Wu：人在常识这一块，还是比模型强。任何一次产品发布，背后牵扯的环节多如牛毛，很多小事看似不起眼，但随时都可能出状况。模型往往很难真正把握：都有哪些利益相关方，他们彼此间是什么关系，各自有什么偏好，以及用什么方式、在什么场合跟他们沟通，才能让他们一直站在这边。这种偏内隐的常识，也就是那种高情商的东西，依然特别珍贵，我们当然希望模型这块能越来越强，也相信会有那一天，但眼下来看，还是存在短板。

Lenny：作为身处龙卷风中心的人，你如何应对持续不断的变化？

Cat Wu：我们的团队是由一群向乱而生的灵魂组成的，我们试着笑对每一个挑战，毕竟要做的事永远没完，风险和棘手状况也总是层出不穷。要是动不动就压力山大，人早晚得累垮。所以我们特别看重这样一种人：面对困难，他会觉得“这有难度，但我等不及要试试，只管尽力做到最好。就算不完美，晚上我也能问心无愧地安然入睡。”

Lenny：关于未来哪些技能会变得重要，这个回答耐人寻味。这让我想起一句话，忘了是出自谁，他说：此刻，已是世界所能呈现的最‘正常’的状态了。

Cat Wu：这确实会越来越难，很多时候是这样：周日晚上还在处理一个P0问题，到了周一变成更大的问题，甚至下午又升级一层。回头看会觉得，有点好笑，昨天居然那么担心那个P0。但你慢慢会意识到一件事：能做的事情是有限的，需要睡好觉，保证自己第二天能做出正确判断，然后就是非常狠地排优先级，抓住最重要的事情，同时接受有些事情必须放掉。我们确实会发布一些没那么完美的产品，这点我以前会很难接受。但现在的核心是：只要不影响最关键的用户价值，比如帮助专业开发者完成核心任务，那就可以接受。剩下的可以通过反馈，在下一轮迭代中修复。以前如果上线一个有bug的功能，我会很焦虑，但现在我能接受，因为我知道会很快得到反馈，并迅速把它修掉。

Lenny：我脑子里有个特别形象的画面，好像是《加勒比海盗》里的一个画面：一个人从船上楼梯慢慢走下来，周围全在塌，但他特别淡定。而且很有意思的是，我认识的Anthropic的人，几乎都是这种感觉，就是很chill，很稳。

Cat Wu：就是一种偏乐观的心态。

Lenny：这其实是个挺有意思的点：在这种环境里，保持冷静和乐观，比起那种“天啊，一切都在失控”的状态要重要得多。

Cat Wu：是的，如果缺少这种自我调节能力，其实很容易就会陷入疲惫甚至倦怠。我们在招聘时也会偏向那些有一定行业经验的人，他们经历过波动，更了解自己的节奏，知道什么能让自己恢复能量，以及如何长期维持良好状态，这对团队来说是非常重要的。

Lenny：这点其实很有意思。我想深入问一下：随着工程师、产品经理等角色的边界逐渐模糊，大家的职责越来越交叉，这种变化会带来哪些损失？比如，是否会削弱传统的职业发展路径？是否会对设计一致性或代码质量产生影响？换句话说，在这种更高效但更模糊的组织形态下，有哪些是你们明确意识到、并愿意为更大目标而接受的代价？

Cat Wu：在AI快速迭代的背景下，产品一致性在一定程度上被主动弱化。传统模式下，由于开发成本高，产品体系通常是高度规划且一一对应使用场景的。而当前模式更强调实验速度，因此允许功能重叠，通过用户反馈来完成形态选择。同时，高频发布带来了认知负担。用户从“低频关注即可理解产品”转变为“持续跟踪更新以避免错过”。这种节奏在整个Agent工具生态中普遍存在。未来的关键在于，通过产品内的引导与教育机制，降低用户的跟进压力，使其从“被动追赶变化”转为“自然掌握工具”。

Lenny：我注意到你们最近上线了一个很有意思的功能，叫“/powerup”。它基本是在引导用户了解Claude Code的各种高阶用法和最佳实践。我很好奇，这是不是也是你刚才提到的那种上手引导思路的延伸？

Cat Wu：早期我们的原则是避免引导流程，强调产品应具备足够的直观性，使用户无需教程即可使用。但随着功能复杂度提升和用户规模扩大，我们观察到对系统化引导的需求显著增加。用户面临的核心问题不再是“如何使用”，而是“在众多功能中应优先使用哪些”。因此在这一点上做了策略调整，引入了内置的入门引导机制，以帮助用户聚焦最关键的功能路径。

Lenny：这个行业现在确实有点反常。Anthropic在B2B企业市场取得了很大的成功，但这个市场原本是低频发布的，比如按季度节奏，而现在却变成了高频迭代，甚至接近每天发布。更有意思的是，如果回顾起点，Anthropic当时其实处于明显劣势，资金、分发和先发优势都不占优，而OpenAI当时遥遥领先，外界普遍不看好它的长期竞争力。但现在它却实现了非常强劲的增长，在很多维度上已经可以和甚至超过更大的竞争对手。所以想请你从内部视角分享一下：Anthropic能够后来居上，实现这种跨越式发展的关键因素是什么？

Cat Wu：最关键的因素之一是统一的使命，其重要性几乎无法被高估。团队在招聘时就强调将安全AGI带给全人类的认同，并在产品决策中持续以此作为最高原则。由于该使命优先级高于任何单一产品线，组织能够实现跨团队的快速决策与一致执行，这种以使命驱动的高效协同，在Anthropic这一规模的组织中极为罕见。

Lenny：我想再确认一下这个点：当“安全对齐、让AI对世界产生正面影响”成为最核心的使命之后，很多原本复杂的决策反而变简单了，是这样吗？

Cat Wu：在优先级冲突的情况下，团队会以Anthropic的使命与原则作为最高决策标准，从而确定资源分配方向。一旦达成共识，团队会统一执行。这意味着即使某些功能已具备发布条件，例如在Claude Code上的功能，也可能因更高优先级事项而被主动延后。

Lenny：这点很有意思，也在某种程度上解释了你们和另一家公司的差异，比如OpenAI，后者在很多方向上都有探索。但从刚才的描述来看，你们的原则更简单也更严格：不符合使命的事情就不做。无论是社交网络还是信息流产品，都不会进入优先级。这种高度克制，反而让Anthropic保持了非常强的聚焦，而这似乎正是你们成功的关键之一。

Cat Wu：在我看来，使命的核心在于将Anthropic的整体目标优先级置于任何单一团队或产品之上。这与专注不同，后者更多是执行层面的能力，而使命是一种价值取向。具体体现为，团队愿意在必要时牺牲自身OKRs，以换取公司整体目标的最大化，并且这种取舍是被主动接受的。在极端情况下，即使像Claude Code这样的产品未达预期，只要Anthropic整体成功，团队依然会认为这是正确的结果，并据此做出决策。

Lenny：我很好奇，你是否认为开放CLA的决策，本质上也是基于同样的判断？也就是当它不再有效推动Anthropic的使命时，就会果断调整甚至停止？

Cat Wu：对Anthropic来说，一个非常重要的目标是扩大用户覆盖范围。而实现这一点的一个关键方式，就是通过我们自己的产品来做订阅服务，我们会持续加码这一块。但这也意味着，有时候对第三方产品的支持可能会有所取舍。

Lenny：刚才聊了Claude Code、CoWork这些工具。想帮大家搞清楚一件事，在实际使用中怎么区分它们的？比如Claude Code、Claude桌面、网页版，还有CoWork，这三种分别适合在什么场景下用？

产品落地与团队生态：工具场景、用户引导与发展逻辑

Cat Wu：我一般在终端里用Claude Code，主要是用在想快速跑一个一次性的编程任务，或者想用最新功能的时候。CLI是最早的产品形态，新功能基本都会先在这里上线，所以它也是功能最强的一种形式。比如我只是想跑几个测试，通常就会直接用它。但如果是做前端相关的事情，桌面端就特别好用。我很喜欢它的预览功能，比如做一个Web应用时，可以在右侧开一个预览窗口，一边和Claude对话，一边实时看到页面效果。另外，对于喜欢图形界面的用户来说，桌面端也更友好。因为对很多非技术背景的人来说，终端其实挺不适应的，看起来有点复杂，还会弹出各种让人紧张的提示，也不像其他软件那样可以点来点去。所以如果你不太习惯终端，很推荐直接用Claude Code的桌面版。

Desktop更像是一个总控视图，可以一眼看到所有正在发生的事情，可以在里面查看CLI终端、桌面任务，以及在网页和手机上发起的任务，相当于一个统一的任务控制台。而网页和移动端的优势在于随时启动。CLI和桌面端都依赖本地电脑，这其实是有约束的。比如你在外面散步，不可能一直带着电脑。我甚至见过有人在外面用手机给电脑开热点继续工作，这其实说明这个场景一直缺一个更好的解决方案。对我来说，移动端最大的价值就是可以随时发起任务，不用带电脑，也不用保证电脑一直开着。

Lenny：我很喜欢这种感觉，不用再时时刻刻盯着细节，更像是把任务交给AI，然后安心让这个agent把它跑完。

Cat Wu：我现在基本停不下来用它了，CoWork解决的是一类很典型但被忽视的工作：很多任务的产出其实不是代码。比如实现Slack和Gmail的清零，或者为客户会议准备一份PPT，又或者写一份功能目标或上线计划的文档。这些都是日常工作中非常高频的事情，但它们的输出都是非代码。而CoWork在这类任务上特别强。所以我的使用逻辑很简单：如果要做的是写代码，就用Claude Code，但只要产出不是代码，比如文档、PPT、沟通内容，就会用CoWork。

Lenny：很多人还在低估CoWork的表现，它的增长其实非常惊人，但大家可能还没有真正理解它的价值在哪里。所以我很好奇，能不能从你作为产品经理的日常工作出发，分享几个具体的使用案例？有没有一些比较有趣，甚至是意料之外的用法，可以帮助你节省时间、完成更多工作？

Cat Wu：如果你刚开始用CoWork，第一步一定是把和工作相关的数据源全部接进来。只有有了足够的上下文，它才能真正帮你做好事情。把Google Calendar、Slack、Gmail和Google Drive都连上，它就能主动找到相关信息、调取历史内容、甚至串联不同来源的数据。这样做之后，效果会明显提升。比如昨天晚上我在准备“Code with Claude”的演讲，其中一场是讲Claude Code如何从一个助手进化成真正的Agent，我希望在这场演讲里展示我们发布的产品，以及一些内部真实的成功案例作为演示。

因为我已经接入了Google Drive和Slack，产品营销同事Alex之前做过一版内容草稿，直接把这些资料全部喂给CoWork。只需要告诉它要讲的故事线，它就自己工作了大概一个小时，它会去看我们在Twitter上的发布内容，查内部的发布频道，还会翻团队分享demo的频道，把这些信息全部整合起来。最后生成了一份大概20页的PPT，我第二天早上看了一下，整体已经挺不错了。当然还是做了一些调整，比如个人更偏好极简风格，而它一开始写得有点多。但整体来说，这个效率提升是巨大的。而且因为它接入了我们的设计系统，做出来的PPT视觉效果非常专业，看起来就像是Anthropic的设计师做的一样。原本这种PPT可能要花好几个小时，现在它很快就能给我一个高质量初稿，只需要专注在把demo打磨到最好。

Lenny：这对产品经理来说简直就是梦想成真，毕竟做PPT真的很让人头疼。

Cat Wu：太慢了，自己做需要几个小时。

Lenny：而且这套PPT在你每次展示时都会被很多人看到，也会在外部流传，显然它不是一次生成的，而是经过多轮迭代优化的。如果让大家自己动手尝试这个流程，第一步是连接这些工具，比如你提到的Slack。那么除此之外，你还建议他们接入哪些工具？

Cat Wu：建议接入Slack、GoogleCalendar、Gmail、GoogleDrive等工具，将团队关注事项、个人优先级以及当前工作内容的核心数据源统一打通，作为决策和协作的基础。

Lenny：明白了，那你当时大概是怎么写prompt来生成这份PPT的？

Cat Wu：我当时是这么跟Claude说的：帮我做一份“Code with Claude”大会的PPT。这是产品经理M建议要覆盖的内容，那是我的一版草稿，我不太满意，还有一版是我自己手动做的，也不太好，不过我也一起发给你。先帮我整理一个更完整的内容大纲，并且尽量避免和更重要的主题演讲重复。然后Claude会去读我给它的那些链接，生成一个初步的大纲。我再把它给的方案过一遍，看它提出了哪些思路和方向，最后由我来决定哪些内容要放进最终版本里。

这正好说明了现在产品经理的价值所在。像Claude这样的工具，是一个非常强的思考伙伴，可以快速整合大量信息，把各种可能的方向都摆在你面前，但最终拍板的人还是产品经理，需要决定什么才应该进入最终产品。比如在这个案例里，我最后决定内容结构是一个递进过程：从提升本地任务的成功率，到让每一个PR都顺利通过，再到帮助工程师完成更多PR。同时，我还要为每一部分挑选最有说服力的演示方式。当这个框架确定之后，Claude基本就可以自己完成剩下的工作，它花了几个小时就把整套PPT做出来了。

Lenny：这真的太爽了，相当于工作里有一块可以彻底交给AI来做。而且感觉就像在和一个PPT设计师合作，但这个设计师不仅会设计，还真正理解你做过的内容，能把内容和呈现一起做好，而不只是让它看起来更漂亮。

那我很好奇，你是怎么处理设计系统这一块的？它具体是怎么工作的？又是怎么学会Anthropic的设计规范的？

Cat Wu：我们本来就有一套用于所有对外场景的标准演示模板，把这套模板直接交给Claude，让它学习我们的配色、字体，还有不同类型的页面结构，现在它相当于有二十页示例可以参考。

Lenny：你相当于是上传了模板，让它基于这个来做。

Cat Wu：对。你也可以连接自己的Figma integration，如果你的幻灯片模板是存在那里，它也可以直接拉进来用。

Lenny：作为一个产品经理，在Anthropic，你的工具栈大概是什么样的？肯定有Claude Code、CoWork，还有Anthropic 自家的工具。你还在用什么？你刚刚提到Slack，还有别的吗？

Cat Wu：我的工具栈基本上就是重度依赖Claude Code、CoWork和Slack。Anthropic基本上是跑在Slack上的，它有点像我们公司的核心操作系统。日常工作里，我大概有30%的时间是在不断试探CoWork和Claude Code的能力边界，这样我能非常清楚地知道它们目前做不好的地方。同时我也会花很多时间和模型对话，去理解它为什么会犯那些错误。

从手动制作到AI生成，AI工具正在显著提升工作效率

Cat Wu：我们内部也做了很多工具。Claude Code给整个公司带来的一个重要变化是，它极大降低了开发自定义应用的门槛。于是你会看到一个现象：大家开始大量构建个性化工作软件，针对非常具体的使用场景，而不是再去用那些并不完全契合需求的通用工具。

Lenny：有什么具体例子吗？你们自己或者别人做过哪些特别受欢迎、特别有用的东西？

Cat Wu：我们Claude Code团队里有个做销售的同事，他发现自己一直在反复做同样类型的PPT，一遍又一遍。于是他做了一个Web应用，里面内置了那些我们已经验证效果很好的Claude Code PPT模板，比如101、201，以及Mastering Claude Code。

然后他做了一套输入机制，可以把客户的具体背景信息拉进来，这些信息来自Salesforce、Gong，以及其他笔记系统。这样我们就可以针对每个客户定制PPT。比如，它会自动提取信息：这个客户在用的是Bedrock、Claude for Enterprise，还是Console。这会直接影响他们能用哪些功能。

它还会识别，比如这个客户特别关注SLC（软件生命周期）里的代码审查阶段，那我们就会自动加一页介绍我们代码审查功能的幻灯片。再比如，如果客户有HIPAA合规要求，或者有特定的安全控制需求，它也会自动在PPT里加上相关内容。还有一种情况，如果客户是在Vertex或Bedrock上运行，而且不打算用Claude for Enterprise，那我们就会自动删掉那些只适用于Claude for Enterprise的幻灯片。

这些工作本来都是手动做的，通常要花20到30分钟。很多人要么花时间做，要么干脆就不做，直接用通用PPT。但现在，用这个工具只需要几秒钟，就能生成一个完全定制化的PPT。

Lenny：像Slack这种工具，几乎没有人想自己重新造一个。Slack就一直在赢。你刚才说它有点像很多公司的操作系统，这个比喻很贴切。比如大家现在会说，像Salesforce这种SaaS，其实不一定还需要，我们可以自己做。但Slack就不一样，它就像一个很讨喜的工具，没有人真的想去跟它竞争、再造一个更好的版本。

Cat Wu：它本质上是一种非常关键的通信基础设施。而且在最核心的一点——让所有人实时获得更新，它做得非常非常好。

Lenny：很多人嘴上会吐槽Slack，但它在自己要解决的问题上做得特别好。最前沿的团队基本都离不开它。

Cat Wu：是的。我也很喜欢它在可定制性上做得非常简单。比如我们很喜欢做Slack bot，这种高度的可定制性让我们可以按自己的方式把各种系统接入Slack。在这一点上，确实很认可Slack的设计。

Lenny：你刚刚提到很多不同的团队，以及他们是如何使用Claude code和CoWork来工作的。除了工程团队之外，哪个团队用的token最多？我猜工程团队应该是最大的token消耗方。现在排第二的是哪个职能？

Cat Wu：Applied AI团队在不断推动Claude code和CoWork的能力边界，这一点非常明显。我们很多Applied AI团队成员都会花时间和客户一起工作，帮助他们在公司内部落地我们的API。所以有时候，他们会直接替客户做一些原型，而在这方面，Claude Code相比以前，速度提升非常明显。

同时，他们还要处理大量客户沟通，包括客户的历史上下文、会议记录、通话笔记等等。所以他们在CoWork和Claude Code上的使用非常频繁。

Lenny：我想更具体理解一下Applied AI。它是不是有点类似forward-deployed engineering（前线部署工程）这种角色？一般人会怎么描述这个团队在做什么？

Cat Wu：可以这么理解。他们的核心就是帮助客户在整个公司范围内，落地最新的API和模型能力，既包括客户对外产品，也包括内部效率提升。

Lenny：可以理解为一个融合客户服务、业务拓展与技术落地能力的复合型团队。这个团队的token使用量，可能是第二高的？

Cat Wu：是的。而且我们也看到他们在不断探索CoWork的能力边界。比如，这些人通常要同时负责多个客户，有时候一天要参加5到10场客户沟通。他们一个很典型的用法是：在前一天晚上，让CoWork帮他们总结：明天所有的客户会议有哪些？每个客户最近都提了什么需求？他们当前最关心的是什么？过去会议的待办事项是什么？

CoWork会自动整理出一个资料包，也就是一个简报，让他们在进入下一场会议前一目了然。此外，CoWork还能帮他们做信息检索。比如客户问：“某个功能什么时候上线？”CoWork可以直接在Slack里查找最新的ETA（预计时间），把结果整理进笔记里。这样在客户通话时，他们拿到的就是最新信息。这些都是员工自己搭出来的工作流，然后在团队内部分享使用。

Lenny：有一个最近经常被提起的问题，或者说一种趋势，就是token的花费开始超过人的薪资。也就是说，人们使用AI的成本，甚至可能高于他们自己赚的钱。有没有一些数据在流传，比如工程师或者产品经理一个月或一天大概会消耗多少token？

Cat Wu：随着模型能力的提升，人们会把越来越多的任务委托给它，同时也会在像Claude Code 和CoWork这样的工具上花更多时间。因此，每当模型出现一次跃迁，或者产品有显著改进时，单个工程师，或者更广义上的知识工作者的人均token成本都会上升。目前这个成本仍然远低于一个普通工程师的薪资，但它所占的比例正在逐渐提高。

Lenny：你们能接触到最前沿的模型，这本身就是在Anthropic工作的一大优势。你们基本上是无限token，可以随便用，对吗？

Cat Wu：我们可以用很多token，不过也有人会碰到限制。

Lenny：拥有最先进模型会带来这么多优势，这就像一个开始不断加速的飞轮效应。

Cat Wu：我们也非常重视让内部团队尽可能快地推进工作。同时，我们也相信大家都理解运行这些模型背后的真实成本，会负责任地使用token。浪费token是不被鼓励的，但我们也相信每个人都能自己做出判断。

Lenny：回到产品经理这个角色。在现在这个阶段，产品经理需要具备哪些正在出现的新能力？或者说，AI公司在招聘产品经理时最看重什么？

Cat Wu：最难的一项能力，是能够定义“一个月之后这个产品应该长什么样”。在这个时间尺度上，模型到底能做到什么、用户行为会如何变化，都存在很大的不确定性。但优秀的产品经理能从用户如何突破当前产品边界的方式中，看到一些模式。最优秀的产品经理能感知这些信号，设定方向，并持续推进执行；同时，如果模型能力的发展比预期更好或更差，也能及时调整路径。

还有一点很难，就是在面对AGI这个终局时，保持一种恰到好处的判断力。大家都能想象这样一个未来：模型非常聪明，几乎可以完成一切任务。在那种情况下，你根本不需要一个复杂的产品。你可能只需要一个输入框，告诉模型你想做什么。模型足够聪明，它可以自己调用工具、接入各种系统来完成任务；它知道什么时候不确定，也会主动提出澄清问题。

从这个角度来看，为一个超级AGI设计产品其实是很容易的。真正困难的是：在当前模型能力还有限的情况下，你如何把它的能力最大化地激发出来？如何帮助用户进入一条最佳使用路径？如何引导用户发挥模型的优势，同时弥补它的不足？这种能力是非常稀缺的。

Lenny：这种能力是怎么培养出来的？本质上是不是去理解每一个模型的能力边界，比如你刚才说的那种“品味”，对模型能做什么、擅长什么、不擅长什么，以及它在哪些地方发生了变化，有一种判断力？

Cat Wu：核心还是要花大量时间去使用模型、和模型对话。有一件我特别喜欢做的事情，就是让模型对自己的行为进行自我反思。有时候我会发现模型做了一些不太符合预期的操作。举个例子，有些情况下模型会去修改前端代码、跑测试，但却没有真正去使用UI。

这种时候，很有价值的一件事是直接问模型：你为什么会这样做？有时候它会回答说，系统提示里有些地方让它产生了误解；或者它没有意识到前端验证是这个任务的一部分；又或者它把验证工作交给了某个子Agent，但这个子Agent没有执行测试，而它自己也没有去检查结果。

很多时候，只要你对模型为什么会做出这个决策保持足够的好奇心，就能发现它是在哪一步被误导了，从而可以去调整整个运行框架，把这个问题补上。

另外一个很有帮助的方法，是找出那些你最信任的用户，他们能给你关于模型的高质量反馈。通常会有少数几个人，在描述“某个模型+某种运行框架为什么好用”这件事上，比其他人更清晰、更准确。当然，会有很多人给你反馈，但不是每个人的反馈都同样有价值。所以找到那样一小群你真正信任的、比如五个人左右的用户，对于快速获得有效反馈非常关键。

第三点是一个很有用、但不是每个人都喜欢做的事情，就是构建评估体系。你不需要做上百个评估才能产生价值，只需要做十个高质量的评估，就能很好地帮助团队明确目标、衡量进展，以及发现当前的不足。评估这件事被低估了，应该有更多产品经理和工程师参与进来。

Lenny：我们之前其实聊过不少关于评估的话题。现在有一种趋势是，未来的产品管理，很大程度上就是在写评估，因为评估本质上定义了什么才算成功。也就是说，你可以把成功标准具体化，一旦定义清楚，就知道自己是否达到了。那你自己大概会花多少时间在写这些评估上？

Cat Wu：评估的重要性，取决于你在做的具体功能，或者你要解决的问题类型。我们团队里有不少人会花很多时间在评估上。还有一个小团队，会和研究团队非常紧密地合作，更精确地理解Claude Code的行为，以及当前最大的改进空间在哪里，并尽可能用量化的方式去衡量这些问题。

对我来说，一般是在某个功能还需要进一步明确产品定义时，才会亲自下场做评估。通常产出会是这样：我做了五个评估，这是运行方式，这些是成功的案例，这些是失败的案例，以及这是我用来提升成功率的提示词。当然，这个投入会因功能而异，并不是所有功能都需要。但像记忆这类功能，就会从评估中获益很大。

Lenny：你刚才说，有些人特别擅长评估模型。某种程度上，这些人本身就像一个评估器，他们能判断模型在哪些地方表现突出、在哪些地方不足。有没有某些具体的人，在这方面特别厉害，值得点名表扬一下？

Cat Wu：在这方面做得非常出色的有两类人。一个是Amanda，她主要负责塑造Claude的“角色”。这是一个非常难的工作，因为这个任务本身极其模糊。哪怕是做编程，相对来说都更容易一些，因为你可以验证结果是否正确；但塑造角色这件事，需要对Claude应该成为什么样的存在，有一种非常强的判断力和确定性。她不仅在塑造这个角色上能力很强，而且还能清晰地表达：目标是什么，这个角色什么算成功，什么不算成功。

另一类我非常信任的人，就是Claude Code团队。我们经常会一起吃团队午餐，每当有新模型在测试时，我们获取反馈最快的方式之一，就是在这种场合挨个去问大家：你对这个模型的整体感觉怎么样？

通常我们会得到一些很直观的反馈，比如：这个模型没有很好地解释它的思考过程，说话太直接了；或者这个模型特别喜欢写很多可复用上下文记忆，但我们不确定这些记忆的质量到底怎么样；又或者有人会注意到，这个模型很喜欢自我测试，这很好；也有人会说，这个模型自我测试还不够。

这些反馈会帮助我们判断接下来应该去看哪些数据，从而验证：这是不是一个更普遍的现象。我们有非常多的数据，但要从中提炼出洞察是非常困难的。所以，这一小群人的反馈会帮助我们明确：我们应该提出哪些假设，然后再去用数据验证这些假设。

Lenny：你刚才提到Claude的“角色”，我之前在播客里请过Ben Mann，他也谈到过这一点——Claude的“性格”或者说“行为准则”，其实是非常核心的一部分。我也是后来才意识到，比如在Open Claw这样的场景里，很多人之所以会感到失落，其中一个原因就是Claude的“个性”。因为Claude的性格相比其他模型来说，确实更好玩、更有趣、更有吸引力。

他的说法是：正是这种“性格”，让Claude在很多事情上表现得更出色。乍看之下，这好像只是一个很边缘的点，比如让它更有趣一点、更会聊天一点，但实际上它对Claude的成功至关重要。从你的角度看，为什么你所说的这种“角色”或“性格”会这么关键？有哪些是大家可能没有意识到的？

Cat Wu：如果你回想一下自己合作过的所有人，总有一些人是你会觉得：我真的很喜欢和他们一起工作的那种感觉，我很喜欢他们的气场或者说氛围。当人们谈到Claude和Claude Code时，这是被提到最多的一点之一，大家真的很喜欢Claude的那种轻松、有趣的感觉。

但与此同时，它在完成任务时又非常专业、非常可靠。大家也很喜欢Claude的“低ego”。如果你告诉它：“你这里做错了”，它会真的很抱歉，会说“哦，确实是我错了，谢谢你指出来，我来改一下，我们一起把它做好”。它也非常积极。如果你觉得一件事情很难、无从下手，Claude会说：“没关系，我们可以一步一步来。这是我建议的步骤，你需要我帮你先开始吗？”

一个优秀的协作伙伴，往往具备这种积极性、这种偏向行动的倾向，以及一种能够给出真诚反馈的能力，而不是对你说的每一句话都附和。所以我们会刻意把这些特质注入到Claude里，因为我们认为，这会让它变得更容易合作，也更让人愿意与之一起工作。

随着模型能力提升，产品功能在删减与重构中不断演进

Lenny：你刚才提到，每当新模型发布时，你们往往需要重新审视之前做过的东西。这点可能挺让人沮丧的。就像是，好不容易把一个功能上线了，结果现在又得重新思考一遍。能不能讲讲这种情况大概有多频繁？比如新模型一出来，你们就会觉得，几个月前上线的这个产品得重新做一遍了。

Cat Wu：我们在新模型发布后做的很多调整，其实是删除那些已经不再需要的功能。很多时候，我们之所以在产品里加某些功能，是因为模型本身还做不到，需要这些功能作为辅助。一个很典型的例子就是待办列表。

在我们最早发布Claude Code的时候，用户会让它去做一些大规模的重构。Claude Code会说，好，我需要修改这20个调用点，然后它可能只改了其中5个就停下来了。于是我们就在想，怎么让它记住必须把这20个全部改完？团队成员提出，可以从人类的做法出发。人通常会先列一个清单，把所有需要修改的地方列出来，就像你在VS Code里查找所有调用点，左侧会列出一个清单，然后你逐个处理、全部替换。

那我们能不能给Claude一个类似的工具？于是他就加了待办列表。结果我们发现，有了这个之后，Claude确实可以把这20个调用点全部处理完。但到了Opus 4以及之后的模型，我们发现，不需要再强制它使用这个待办列表了，它会自然地这么做。

在更早的模型里，我们需要不断提醒它：你是不是已经完成了待办列表里的所有事项？只有全部完成才能结束任务。而在新的模型里，即使不提示，它也会自发地把这些事情全部做完。现在来看，待办列表对用户来说仍然是一个不错的功能，因为你可以更清楚地看到Claude正在做什么。但从模型本身的能力来说，这已经不是一个关键组件了，它用不用这个功能都不影响它完成完整的修改。

Lenny：有人在播客里说过一句话：模型会把你的运行框架“当早餐吃掉”。换句话说，随着模型能力不断提升，那些曾经为了让模型按预期工作而叠加上去的机制，会被逐渐剥离。模型本身变得越强，就越能够直接完成你想要的任务，产品反而会变得更加简单。

Cat Wu：是的。每当模型变得更强，我们都可以删掉很多提示层面的干预。我们每次发布新模型时，都会做一件事：把整个系统提示从头到尾读一遍，逐条判断，这些提醒现在还需要吗？如果不需要，就删掉。不过，新模型带来的最令人兴奋的，是全新的功能能力。

有很多功能，我们在之前的模型上已经尝试过，但因为准确率不够高，一直没有正式上线。比如代码审查。我们尝试过好几次做代码审查产品，也上线过一些比较简单的版本，比如之前的/code-review命令。但一直到最近的模型，我们才真正觉得，这个功能已经好到可以依赖了。

现在，我们的工程团队在合并PR之前，会依赖这个代码审查来通过。我们一直希望Claude能成为一个可靠的代码审查员，能够捕捉大部分bug，而这一点直到Opus 4.5、4.6，以及Sonnet 4.6之后才真正实现。现在我们可以同时运行多个代码审查Agent，遍历整个代码库，然后综合输出一组工程师在合并前需要解决的真实问题。这是新模型解锁的一种全新能力。

Lenny：这也让我想到一个在这个播客里经常出现的趋势：去构建那些可能在未来六个月内才真正可行的产品。你其实是在能力边界附近做东西，然后随着模型能力追上来，它就会变成一个非常出色的产品，而你也会领先其他人。

Cat Wu：是的。去构建那些暂时还跑不通的产品非常重要，因为这样你才能知道，这个产品要真正成立，还缺什么。等到新模型出来，你只需要把它替换进你已经做好的原型里，就可以验证：这个新模型有没有把之前的差距补上。

Lenny：你能不能讲讲，像Claude和CoWork这些产品整体的长期方向大概是什么？你可能不方便透露太多具体目标，但感觉现在不断在往上叠加各种很酷的功能，比如Dispatch、手机端控制、各种移动应用等等。从一个更宏观的角度，大家应该怎么理解这些东西的长期愿景？

Cat Wu：我们是用构建模块的方式来思考这个问题的。对于Claude Code和CoWork来说，最核心的构建模块是：让单个任务成功完成。也就是说，你给它一个清晰的需求描述，它能不能稳定地产出一个可接受的结果，这个结果可以直接合并、分享给同事，或者对外使用。

所以，任务是最基本的单位。随着模型越来越强，单个任务的成功率会显著提高。接下来我们看到的趋势是，人们开始同时处理多个任务。到2025年底，多任务并行已经成为一个很重要的趋势，而且现在还在持续增强。也就是说，从一个任务可以做好，发展到可以同时做六个任务。

再往前推演，当模型更强时，也许你会同时运行50个甚至上百个任务。那问题就变成：我们需要什么样的基础设施来支撑这一点？到那个阶段，你很可能已经无法再在本地机器上运行所有东西了，因为内存根本不够。所以我们在思考，如何让你更容易去管理这些任务？它们很可能会运行在远程环境中。

我们还要思考，如何设计一个界面，让你作为人类，可以快速知道哪些任务需要关注？如何确保Agent能够充分验证自己的工作，这样当它告诉你“已经完成”时，你可以很快确认，并且真正信任这个结果符合你的要求？还有一点是，如何让整个流程具备自我改进能力？当你发现某个任务结果不符合预期时，你可以给出反馈，而模型在之后的所有运行中都能吸收这个反馈，不再重复同样的错误。

这就是我们希望带着用户一起走的演进路径。

Lenny：现在有很多人在听这个播客，包括产品经理、创业者，还有各种跨职能角色的人。大家其实都在担心自己的角色、以及职业未来会怎样变化。你会给他们什么建议？不仅是如何活下来，而是如何在这个高度由AI驱动的世界里真正变得成功，甚至做到脱颖而出？有哪些是大家此刻真正需要认清的，以及需要开始去做的事情？

Cat Wu：AI给了每个人远超以往的杠杆。一旦你发现自己在重复做某个手动任务，就去想：能不能用代码、CoWork，或者其他AI工具，把它自动化掉？大多数人都有这样的工作结构：有一部分是自己很喜欢的创造性工作，另一部分是非常繁琐、重复、让人不想做的事情。AI的价值就在于，它可以帮你完成这些重复劳动。

它可以从你每一次手动操作中学习，总结规律，然后自动执行。这样你就可以把精力集中在更有创造性的部分上，也意味着你能完成的事情会比以前多得多。所以我最直接的建议是：找出那些可以交给CoWork处理的重复任务，不断优化这些自动化流程，直到成功率足够高。

然后再去思考，你还能为团队、为产品、为公司做哪些以前没有精力去做的事情？有没有那些你一直觉得公司应该做，但从来没有时间推进的项目？如果AI能帮你承担那些基础性的工作，你就相当于多出了20%的时间，而这些时间以前是不存在的。主动拥抱这些工具，把那些你不想做的工作交出去，找到它们能为你带来的加速效果。这样一来，你能做的事情会远远超过过去。

自动化的边界，不在于能否实现，而在于是否足够可靠

Lenny：你刚才分享的一个核心观点是去找那些可以用AI解决的问题。现在这些工具的潜力都很大，但对很多人来说，最难的一点其实是：我到底该做什么？

你这里的意思是，要多留意那些你反复在做的事情，看看能不能把它们自动化；同时也可以关注那些你一直有想法、但一直没时间做的事情。本质上就是——先为自己解决问题，这是最核心的建议。

Cat Wu：没错。另外我也会建议大家，把注意力放在一件事上：把自动化从“这是个挺酷的概念”，推进到“这个东西真的可以100%稳定运行”。我有时会看到一些用户，把某个自动化做到90%或95%的准确率，然后就放弃了。但如果一个自动化不能做到100%，它其实就不算真正的自动化。

而最后那5%到10%，确实需要投入更多时间。而且，构建自动化的过程，往往比你自己手动完成还要慢。我会建议大家，花时间去打磨那些你真的希望做到100%的自动化。多下点功夫，把你的偏好教给CoWork，多给它反馈，让它不断提升能力，直到达到完全可靠的程度。只有做到这一点，你才能真正依赖它。95%的自动化，其实价值不大。

Lenny：这对我来说是个很好的提醒。

Cat Wu：我自己也有这个问题。我一直在训练CoWork，想让它帮我把Gmail的收件箱做到清零。但这个过程非常耗时，而且现在还远远没达到理想状态。

Lenny：说到这个我也有同感。我做过一个流程：每收到一封邮件，它都会判断哪些是垃圾信息，比如各种“能不能上你的播客”“要不要看看这个”的邮件，我根本没时间处理。

然后我让它把这些邮件分类到一个叫“疑似垃圾”的文件夹里。这个流程大概有95%的效果都很好，但问题是，有时候会把重要邮件也误放进去，结果我就错过了。这提醒我要继续优化，把它做到真正可靠。

Cat Wu：我们也在努力让这种自定义流程的体验变得更简单。因为现在的流程还是有点复杂，你需要理解很多概念，比如要定义一个技能、要调用这个技能、要不断给它反馈，然后还要告诉CoWork根据这些反馈去更新这个技能。

同时你还需要知道去哪里查看这个技能，确认它是否按你的预期更新了。让这一整套流程变得更顺畅，也是我们的工作之一，这样用户在使用时就不会觉得很痛苦。

Lenny：在进入闪电问答之前，还有没有什么你特别想补充的内容？有没有什么你希望听众带走的重点，或者你想再强调一下、但我们还没聊到的？

Cat Wu：我看到很多人在尝试AI，做一些原型应用，或者搭一些工作流。但我会更建议大家去做那些你每天都会用到的应用。因为只有在真实使用中，你才能真正获得价值。如果你做了一个原型，但它并没有帮你提高效率，那AI其实并没有为你的日常工作带来实际价值。

Lenny：而且如果只是做一次、觉得挺酷，然后就再也不用了，你能学到的东西是很有限的。

Cat Wu：这样其实也拿不到太多真正的杠杆。有一类人会花大量时间去定制自己的工作流。某种程度上可以说有两个极端：一类人完全不做定制，也不做自动化；另一类则走向另一个极端，会非常执着于优化自己的工具，比如加很多技能、MCP，以及各种工作流优化。

但有时候，这反而会分散注意力，让你偏离最核心的目标，比如发布产品、或者真正把某个功能做出来。当然，定制本身是很有趣的，我们也确实希望把产品做得足够可扩展，让你可以按照自己的方式去使用。但这种优化是有边界的。有一类人可能会在定制上花太多时间，甚至影响睡眠，反而没有去完成他们一开始想做的核心任务。

Lenny：我在Twitter上经常看到这种情况。大家都在展示自己的配置，说你看我的setup，有多复杂、多极致优化。但问题是，你到底在做什么？“我现在还没在做具体的东西，但我的setup超强，我能做很多事情。”

Cat Wu：简单的配置反而更有效。

Lenny：昨天Andrej Karpathy发了一条很有意思的推文，讲到一个分化现象：有一类人早期尝试过ChatGPT，觉得不怎么样，就放弃了，对AI的能力也变得很怀疑，觉得这东西没什么大不了的。但另一类人，尤其是用它来写代码的人，已经看到了它真正的强大能力，知道它可以做到什么程度。

而这两类人彼此很难理解对方是怎么看世界的。所以你刚才的建议真的很关键：把它用在真实的问题上，才能真正感受到它已经进化到什么程度。

Cat Wu：一个很大的变化是，2024年那一代产品主要是基于对话的，而像Claude Code这一代产品，更偏向行动导向。很多人真正的顿悟时刻，是在发现模型可以直接帮你完成事情，而不仅仅是告诉你该怎么做。当你意识到Agent不只是给建议，而是可以真正替你执行任务，这种体验是非常震撼的。一旦体验到这一点，很多人的认知都会被彻底改变。

Lenny：顺便提一下那个Chrome扩展，你可以直接看着Claude帮你做事，比如你说“帮我填这个表单”，它就真的开始操作了。好，在进入我们接下来非常精彩的闪电问答之前，还有什么你想补充的吗？

Cat Wu：没有，我们来吧。

快问快答

Lenny：我们有五个问题要问你。第一个问题，你最常推荐给别人的两三本书是什么？

Cat Wu：我很喜欢《How Asia Works:Success and Failure in the World's Most Dynamic Region》，它讲的是经济发展，以及哪些政策和政府能够打造出长期成功的经济体。另外一本我也很喜欢的是《The Technology Trap:Capital, Labor, and Power in the Age of Automation》。这本书主要讲过去几次技术革命，比如工业革命和计算机革命，以及这些变化是如何影响劳动者的。我之所以很喜欢这本书，是因为我们可以从历史中学到很多，从而确保这一次转型能够走得更好。如果说轻松一点的读物，我很喜欢《The Paper Menagerie》。它是一个短篇小说集，讲成长、AI，以及自我认知。

Lenny：最近有没有什么你特别喜欢的电影或者电视剧？

Cat Wu：我很喜欢《Drive to Survive》。它没有什么特别深刻的意义，看到人们如此专注于一个单一的工程目标，本身就很让人满足，那种纯粹的投入感很吸引我。

我也非常喜欢《Free Solo》，讲的是Alex Honnold在没有任何保护装备的情况下攀登酋长岩（El Capitan）。这同样是一种非常纯粹的成就：去完成一条极其困难、极其危险的路线，而且需要极强的心理专注力，因为只要犯一个错误，就意味着死亡。

Lenny：那部电影真的让人难以置信。这些内容某种程度上也和你的工作有点呼应。

Cat Wu：我自己也会攀岩。我是在看完《Free Solo》之后才开始攀岩的，当时只是觉得很厉害，但并没有完全理解它到底有多厉害。这是一部很少见的电影：你对这件事了解得越多，就越会被震撼到它到底有多不可思议。像他在岩壁上做的那些动作，就算是在室内攀岩馆、离地只有一英尺的地方，我这辈子可能都做不到。

Lenny：你有没有看过另一个人的纪录片？那个更年轻的，在冰面上攀登的那个。

Cat Wu：看过。那个挺让人难过的。

Lenny：但确实也很震撼。好，下一个问题。最近有没有发现什么特别喜欢的产品？

Cat Wu：如果说除了云产品之外，对我生活影响最大的一个产品，大概是Waymo。我是个非常忠实的Waymo用户，每天上下班都会用，一天两次。我最喜欢它的两点是：第一，如果车在等我，我不会有负担感。所以我不用在它刚到的时候就必须立刻站在路边等着。

第二，它让我更高效。如果车里是一个人类司机，我通常不会去接工作电话，也不太会一直在电脑上工作，会觉得有点不礼貌。但在Waymo里，我可以直接开会，不用担心被人听到，也不用考虑会不会不礼貌，或者说话声音会不会太大，也不用去让别人调音乐之类的。这个产品每天大概帮我“多拿回”了30分钟时间。

Lenny：这些技术带来的“二阶效应”（ZP注：不是直接结果，而是由它引发的一系列间接变化）真的很有意思。

Cat Wu：是的。我以前一直觉得Waymo要想成功，价格必须比Uber和Lyft更低。但现在我很乐意为它付出两倍的价格。

Lenny：我也很喜欢Waymo。第一次看到的时候会觉得，这也太不可思议了；但用着用着，就习以为常了。

Cat Wu：它甚至改变了大家的说话方式。在Anthropic，很多人都很喜欢用Waymo。以前大家会说，“我们叫个打车软件吧”，但现在大家会直接问：“Waymo到了吗？”

Lenny：好，最后两个问题。你有没有一句自己很常回想的座右铭？不管是工作还是生活。

Cat Wu：就是一句话：去做就对了。从第一性原理出发去思考是很有价值的。如果你清楚自己的目标，也有比较扎实的第一性原则，那通常是可以推导出正确的行动路径的，而且也能清晰地向相关各方解释清楚。接下来就应该去做。

“岗位”这件事本身有点被高估了。如果你理解了约束条件，你就能知道自己可以做什么。然后就是尽快去尝试，从错误中学习。如果做错了，就道歉，或者修正。

把这个理念讲给大家听，其实是一种解放。因为在很多公司里，角色划分是非常严格的，比如这是产品经理的职责，这是设计师的职责，这是工程师的职责。甚至团队的职责范围也被划分得很死，比如这块代码我们可以动，那一块我们就不能碰。

而“去做就对了”带来的变化是，它会让人更有自主性，敢于做决策，也敢于跨越团队边界去推进事情，只为了把事情真正做成。

Lenny：这听起来像是一项非常重要的能力。很多人把它叫做agency，本质就是去做那些该做的事情。还有人会说“偏向行动”“行动优先”，都是在描述同一种能力——不等别人批准。

Cat Wu：是的。这是人生中某个阶段一定要去创业公司工作的一个重要原因。对我来说，一个非常改变人生的经历，是在一家只有20人规模的公司里工作。当时基本没有什么流程，但我们要解决的问题却非常大。

我很感激Alex和团队里的其他人，他们给了我以及团队其他成员充分的自由，让我们可以在没有明确边界的情况下自己去摸索，不再有“销售该做什么”“运营该做什么”“工程师该做什么”这种限制。你手里有所有可用的工具，有一个宏大而复杂的问题需要解决，你可以用任何方式去找到一个好的答案。

Lenny：某种程度上，你可能必须经历过这样的环境，才能真正培养出这种能力，才能在心理上对这种做事方式感到舒服。很多人从学校一路走来，习惯的是“按要求完成任务就能拿到好成绩”。你需要反学习这种模式，转而变成：我要去做那些真正需要被做的事情。哪怕别人觉得这很蠢，但我认为这是正确的，我就去做。

好，再来两个快问快答的问题。当Claude在思考时，会用到一些“动词”？这些东西应该怎么称呼？

Cat Wu：我们叫它“thinking words”（思考词）。

Lenny：这些词后来在源码里也被曝光了。你有没有特别喜欢的一个？

Cat Wu：我很喜欢manifesting（显化）。我电脑上还贴了这个词的贴纸。

Lenny：这个选得很好。最后一个问题，我们也会问很多嘉宾这个问题。如果AGI在我们有生之年真的实现了，甚至你不再需要工作了，你会做什么？你会怎么使用你的时间？

Cat Wu：AGI在社会中的普及还需要很长时间，所以短期内更重要的事情，是帮助整个世界一起走到那个阶段。如果说一个不那么严肃的答案，在那之后我大概会去多攀岩。我可能会搬到Fontainebleau，在那里和成千上万块巨石一起生活，专心攀一段时间。

我还有很多书想读，我的目标是每周能读一到两本，但现在大概只有每周0.5本，积压的书已经很多了。我们能从历史中学到的东西太多了，还有很多我想理解但还不够了解的领域，比如物理、机器人、硬件、航空航天等等，都是非常有意思的话题。所以我很期待继续学习，哪怕AGI早就已经知道这些知识。

Lenny：谢谢你的分享。Cat，非常感谢你今天的参与。

Cat Wu：谢谢邀请。

原文：How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)https://youtu.be/PplmzlgE0kg?si=IJIjrCcvlZroq-13编译：Evelyn Zhang、Eleanor Liang

永信证券提示：文章来自网络，不代表本站观点。