Claude产品经理Lenny播客全文精译

开场
我认为，要找到“恰到好处的 AGI 信仰”非常难。给一个超级强、接近 AGI 的模型做产品，其实很容易；真正困难的是，在当前模型能力下，如何把它的最大潜力真正激发出来。
我从来没见过你们在 Anthropic 这样的发布速度。
我们想把发布路上的每一个障碍都拿掉。很多产品功能的周期，已经从 6 个月缩短到 1 个月，有时甚至只要 1 天。你们采访了几百位 PM，我总觉得很多人对这个角色的理解方式还是不对。
PM 这个岗位正在快速变化。对 AI 原生产品来说，最重要的是极快地迭代，想办法让功能真的做到每周都能上线。
那么你觉得，PM 现在最需要培养的新能力是什么？
这还是回到“产品品味”上。随着写代码变得越来越便宜，真正更有价值的，是决定写什么。
今天的嘉宾是 Cat Woo，Anthropic 里 Claude Code 和 co-work 的产品负责人。Cat 站在 AI、产品和构建方式变化的中心位置，她和团队正在打造一种最能改变我们构建产品方式的产品。她有很多洞见、经验和判断。你绝对不能错过这期节目。

你在 Anthropic 的角色
Lenny： 我有太多问题了，非常高兴你来做客。先从你的角色说起，尤其是你和 Boris 的分工。大家都知道 Boris。他那期节目是这档播客里最受欢迎的一期。没压力哈。他创造了 Claude Code，带队工作，还能从手机上每天发出成堆的 PR。我现在都不知道具体数字了。
我觉得很多人低估了你对 Claude Code、co-work，以及你们正在做的所有东西的贡献。你帮大家理解一下：你在团队里到底做什么？你怎么和 Boris 协作？你们怎么分工？Claude Code 团队里的 PM 角色到底长什么样？
Cat： 我觉得自己很幸运能和 Boris 一起工作。他是非常棒的思考伙伴，也是我们的技术负责人。他很强的一点，是能非常清楚地描绘出产品在 3 个月、6 个月后应该是什么样子，也就是这个产品未来的“AGI 版”应该长什么样。
我的很多工作，就是去想：从今天的位置出发，怎么走到那个 3 到 6 个月后的愿景。与此同时，我花更多时间在跨团队协同上，确保市场、销售、财务、算力等团队都真正认同这个计划，大家朝同一个方向划船，并且在功能准备好时，没有任何阻碍上线的因素。
我觉得这套分工之所以有效，是因为我们在很多问题上几乎“心灵合一”，但边界其实又相当模糊。大概 80% 的事情我们是共同决定的，剩下 20% 的事情里，有些我更在意，我就会去推进；另一些他更在意，他就会直接负责。

为什么 AI 时代的 PM 角色变了
Lenny： 你之前跟我说过，你经常面试成百上千位 PM。如果我每次听到有人让我介绍 Anthropic 的人、想去 Anthropic 做 PM，我都能拿到一笔“分成”，那我大概已经有 300 亿 ARR 了。
Anthropic 现在就是大家最想去工作的地方。所以我完全能想象你面试了多少 PM。你说你经常看到有人把这件事理解错了，理解成了他们以为做一个成功的 AI 产品 PM 需要的方式。你能说说你看到了什么，以及现在想要成功到底需要理解什么吗？
Cat： 在 AI 出现之前，技术变化慢得多，所以你可以按 6 到 12 个月的时间尺度来规划。因为功能发布速度比较慢，所以大家更强调和其他协作团队配合，确保他们先把能解锁你功能的部分做出来。那时候代码很贵，制造能力也慢。
现在有了 AI，再加上工程速度被极大加速，模型能力也在快速进步，很多产品功能的周期从 6 个月缩短到 1 个月，有时甚至一周，甚至一天。也就是说，产品真的必须非常快地发布。
这意味着，作为 PM，应该少把重点放在让多季度路线图和合作团队对齐上，而应该更多思考：怎么最快把东西推到线上？怎么做一个产品角落，让工程师或 PM 有了想法后，到了周末前就能把东西交到用户手里？
我觉得，在 AI 原生产品上表现最好的 PM，都是那些能把“从想法到用户手里”的时间尽量压缩的人，并且他们能定义清楚，这个产品最重要的、必须开箱即用的任务是什么。
Lenny： 我喜欢你这一点。你的意思就是，很多人还没真正意识到自己需要多快移动，以及这份工作的很大一部分，其实就是推动团队加速。那到底是什么在帮助这件事发生？你们 PM 团队是怎么让大家跑这么快的？当然，前提是能用到最先进的模型。
Cat： 第一件事，是设定清晰、明确的目标。因为 LLM 太通用了，反而会让“我们在为谁做、我们要解决什么问题、最重要的使用场景是什么”变得很模糊。
所以一个优秀的 PM 能说清楚：我们的关键用户是专业开发者；这个功能要解决的核心问题，可能是权限提示太多，让人产生疲劳；我们希望让企业里的专业开发者在安全前提下，把权限提示降到零。这样一来，就能把很多可能的方案排除掉，让团队更聚焦地往一个明确方向做，帮助用户只用一次提示就完成更多工作。
第二件非常重要的事，是建立一个可重复的发布流程。比如在 Claude Code 里，我们几乎所有功能都会先以 research preview 的形式发布。我们会明确标注，这还是早期产品，只是一个想法，只是想收集反馈并持续迭代，它不一定会永久支持。
这样做能降低我们发布功能时的承诺压力。我们可以在一两周内先把东西发出去。
第三件事，是 PM 要帮团队建立一套工作框架，让大家知道什么时候该拉上跨职能伙伴，以及这些伙伴的预期是什么。比如我们工程、市场和文档之间的流程就非常紧密。工程师觉得某个功能准备好了，而且我们内部已经自己用过之后，就会把它发到我们的 evergreen launch room。然后负责文档的 Sarah、负责 PMM 的 Alex，以及 Devril 里的 Tar 和 Lydia，会立刻跟进，第二天就能把营销公告转出来。
因为有了这套非常紧密的流程，工程师发布东西的阻力就小很多，而 PM 的职责就是把这种机制搭起来。

PRD 现在还重要吗
Lenny： 那 PRD 在这里扮演什么角色？你刚才说“目标”很重要，关键是对成功标准达成一致——这东西是给谁用的？不是给谁用的？你还在写 PRD 吗？还是只写几条要点？在 AI 时代，这种东西怎么演化？
Cat： 我们主要做两件事。
第一，我们有非常严格的指标体系，每周都会和整个团队一起做 metrics readout。目的是让每个人都真正理解业务的各个方面：我们的关键目标是什么，趋势如何，驱动因素是什么。
第二，我们会维护一份团队原则清单。这份清单包括我们的核心用户是谁，以及为什么他们是核心用户。我们把这些写清楚，是希望团队里的每个人都理解业务是怎么运作的，理解什么对我们重要，也理解我们愿意做哪些取舍。
这样大家就可以自己做判断，而不必总卡在 PM 或其他利益相关方那里。
Lenny： 我很喜欢这一点，因为这说明“未来还是需要 PM”。外界总有人在说：为什么还需要 PM？我们直接 ship、直接 build 就好了，我们只需要工程师。
Cat： 其实我们会在某些情况下写 PRD。对于特别模糊的功能，写一页纸还是很有帮助的，写清楚目标是什么、哪些是令人愉快的使用场景、当前有哪些失败模式需要修复。
而且有些项目，尤其是需要重基础设施的项目，确实会持续很多个月。那种情况下，我们还是会写 PRD。

为什么 Anthropic 能这么快
Lenny： 我想再深入一点，了解你们为什么能这么快。我从来没见过 Anthropic 这样的发布速度。有人做了一个 Anthropic 发布日历，结果几乎每天都有一个重大功能或产品上线。
所以有个大家在网上问的问题是：你们刚刚发布的那个非常强的模型 Mythos 还处于 preview，因为太强了，大家有点担心它的能力。你们内部是不是在用它？这是不是你们能这么快推进的原因之一？
Cat： 我们其实已经连续好几个季度都很快了，所以这不完全是 Mythos 的功劳。Mythos 确实是一个极强的模型。我们内部也会使用这些模型，这确实让我们的发布速度更快了一点，但我不认为这能解释增长的大头。
我觉得很大一部分原因在于流程和团队预期。我们的流程很轻。我们希望移除一切会阻碍发布的东西。我们希望让团队里每个人都能感到自己有权把一个想法，从纯想法变成真实出现在世界里的东西，少则一周，多则一天。
Lenny： 哇，这真是太厉害了。既有最好的模型，又在做产品本身。太酷了。
Cat： 我们非常幸运，能和最前沿的模型一起工作。
Lenny： 这优势真的太大了。就是造一个东西，然后自己马上用起来，再进一步加速。

关于 Claude Code 源码泄露
Lenny： 还有几个我想单独聊的话题。Anthropic 这边最近事情很多，我真的很想听听你的看法。一个是，大概一周前，Claude Code 的完整源代码泄露了。有人把它放到了网上。我觉得那是某个人犯了错误。你能说说发生了什么、哪里出了问题、大家应该知道什么吗？
Cat： 我们一看到这件事就立刻去查了。结果发现，这是人为错误造成的。是有一位同事在用 Claude 写 PR，这其实只是一次包发布方式的更新，而且这件事还经过了两层人工审核。
所以这次确实是人为失误。我们已经加固了流程，确保以后不会再发生。
Lenny： 那个人现在还在 Anthropic 吗？他们现在还做得好吗？
Cat： 是的，是的。这是一个流程失败，最重要的是从中学习，并增加更多防护措施，避免再次发生。我们现在的重点就是这个，而且大部分改进都已经上线了。

关于 Open Claude / Open Claude 订阅限制
Lenny： 另一个问题是 Open Claude。最近有个动作，是不再允许大家把 Claude 订阅拿去给自己的 open clause 用。很多人很不开心，不明白为什么这么做。他们觉得这对开源社区造成了伤害。大家应该怎么理解这个决定？
Cat： 我们看到 Claude 的需求非常大，所以一直在努力扩展基础设施，同时让我们的 harness 更加 token efficient，这样用户能获得更多使用量。
不过，第三方产品和我们一方产品的使用模式不一样，并不是为第三方产品设计的。我们花了很多时间去想，怎么才能给出最顺滑的过渡方案。
所以我很高兴最后能说，所有订阅用户都会额外拿到一些 credits。但与此同时，我们也必须做一个艰难决定：优先照顾第一方产品和我们的 API。这个决定就是由此产生的。
Lenny： 对我来说，这其实非常合理。你们相当于以每月 200 美元的价格补贴这类用量，差不多就是无限使用。我觉得很多人不理解，做生意是要赚钱的。我们得追求盈利，不能因为需求太旺就把算力随便送出去。所以我能理解。

Anthropic 的 PM 团队如何组织
Lenny： 回到 PM 团队，Anthropic 的 PM 团队是什么样的？大概有多少 PM？组织方式是怎样的？
Cat： 我们有好几个 PM 团队。现在大概有 30 到 40 位 PM 左右。
有一个研究 PM 团队，由 Diane 负责，主要任务是理解客户对模型的所有反馈，然后把这些反馈传给最合适的研究团队去处理，同时也负责推进模型发布。
还有 Claude Developer Platform 团队，维护 Claude Code 所依赖的 API，也会发布像 managed agents 这样的功能，让你可以构建自己的 agent，由我们代为托管。
还有负责 Claude Code 和 co-work 核心产品的团队。
还有企业团队，帮助 Claude Code 和 co-work 更容易被企业客户采用，包括成本控制、RBAC、安全控制，以及确保企业在使用我们的工具时感到足够放心和舒适。
另外我们还有增长团队，负责推动整个产品矩阵的增长。我们和他们在 Claude Code、co-work 的增长上合作很多，我知道他们也会和其他团队一起做 CDP 增长，也就是 Claude API 用户的增长。

PM 会减少还是增加
Lenny： 说到增长，Amol 刚上过节目。他有一个很有意思的观点，是很多人以前没怎么讲过的。大家总觉得未来需要更少 PM，理由是“为什么还需要 PM？工程师自己就能 ship”。
但他的看法是，因为工程师太快了，PM 和设计师反而被挤压了。你很难跟上，因为每天都在发功能。他的结论是：他反而需要更多 PM，因为根本跟不上。
你怎么看？你觉得未来 PM 的招聘会增加吗？你觉得这个职业长期会怎么变化？
Cat： 我觉得所有角色都在融合。PM 在做一些工程工作，工程师在做一些 PM 的工作，设计师也在做 PM，并且也在落代码。
你可以选择招更多有很强产品品味的工程师，也可以保持工程师招聘规模不变，但招更多 PM 来帮他们的工作定方向。
我们团队更偏向于招有很强产品品味的工程师。这样可以减少发布产品时的额外开销。我们团队里有很多工程师，能完全独立地从 Twitter 上看到用户反馈，一路做到一周末把产品发出来，几乎不需要产品介入。
我觉得这其实是最高效的交付方式。工程和 PM 的边界正在重叠，而且你在任何一边多一点人手，都会有很大收益。产品品味仍然是非常稀缺的技能，只要我们觉得某个人强烈体现出了这种能力，我们基本都会招。
Lenny： 你的背景是工程师，对吗？
Cat： 对，我做了很多年工程师。后来我还短暂做过 VC，然后才加入 Anthropic。其实我们团队里几乎所有 PM，要么以前就是工程师，要么在 Claude Code 这边写过代码。这也是为什么我们团队彼此信任很强、推进很快。我们的设计师以前也都当过前端工程师。
Lenny： 这正是大家最关心的问题：这种边界融合正在发生。很多人真正想知道的是——如果你出身于工程、产品或者设计，这三种核心能力里，哪一种以后最值钱？
在 Anthropic、在 Claude Code 场景里，工程能力当然很重要。但在别的公司，如果你有设计背景，做 PM 可能更有价值，或者做 PM 本身就是最有价值的方向。
Cat： 我还是觉得，核心还是产品品味。随着代码写起来越来越便宜，真正更值钱的是决定写什么。这个功能的正确 UX 是什么？用户体验它的最佳方式是什么？
我们每天都会收到成千上万条 GitHub issue，要求各种各样的东西。要判断哪些值得做、应该怎么做，这需要大量的判断力和品味。我认为这种能力可以来自任何背景，但这是最重要的。
不过至少在接下来的几个月里，工程背景特别有用的原因是：如果你有工程背景，你会更清楚一件事情到底应该有多难。这个判断常常会影响你做什么选择。如果某件事特别容易做，可能你与其争论，不如花一个小时直接把它做掉；但如果它很难，而且你提前知道这点，那你就知道这会给团队带来更高的交付成本。
所以它对优先级排序会有帮助。
Lenny： 你说“接下来的几个月”是因为模型可能在未来几个月里变得特别好，以至于你不一定还需要这些判断吗？
Cat： 我觉得有价值的技能组合变化得非常快，所以很难预测几个月之后会怎样。我的意思不是我在预测某种具体的能力转变，而是说，大规模变化会发生，而且会很快。
Lenny： 你不是在说 Mythos 会出来，一切都变了，然后我们就不需要懂工程了。
Cat： 不是。我只是说，每隔几个月，编码能力都会大幅提升一次，然后角色的价值也会随之变化。最重要的是，你得有第一性原理思维：看清技术环境在怎么变，团队到底需要你做什么，然后直接跳进去把那个缺口补上。
因为工作正在变得更模糊，这就意味着一个优秀的 PM 要能看清所有缺口，判断出最重要的缺口，然后想办法学会那个技能，或者把自己已有的技能迁移到这个新挑战上。
所以现在的环境更看重那种什么都能上、能快速切换角色、而且对自己做什么没有太多 ego 的人——只要这样能让团队更快。

人类大脑未来还会在哪里有用
Lenny： 我一直在问像你这样站在 AI 前沿、用最新工具构建产品的人一个问题：在人类还没走到超级智能之前，人脑到底还会在哪些方面持续有用、持续必要？
我从你这里听到的基本意思是：选择该做什么、知道市场会往哪走、知道该优先做什么；再就是判断你做出来的东西是不是对的，然后至少先把早期版本推出来。这样理解对吗？还有没有别的地方，人类大脑在未来几个月里仍然会很有用？
Cat： 我觉得人类仍然能提供模型没有的常识。任何一次产品发布都有上千个在动的东西，其中很多都很小，但永远有很多地方可能出错。
模型未必总能很好地理解：谁是所有利益相关方、他们彼此之间什么关系、他们各自偏好是什么、跟他们沟通用什么渠道最合适，才能让他们继续站在你这边。
我觉得很多更偏“战术性常识”、EQ 相关的知识，现在仍然非常有价值。当然，我们也希望模型在这方面越来越强，我相信它们会越来越强，但现在还存在缺口。

怎么在变化中保持冷静
Lenny： 作为人，面对这么持续的变化，你怎么应对？就像一直待在龙卷风中心，也许里面很平静，但你怎么一直跟上发生的事？怎么在这种疯狂变化里保持正常？
Cat： 我们团队里的人基本都比较愿意拥抱混乱。我们会尽量用微笑面对每一个挑战，因为总有很多事情在发生，总有很多风险和棘手情况。如果你对每件事都太紧张，很容易就会 burnout。
所以我们会寻找这样的人：他们看到挑战时会说“这会很难，但我很想去做”，然后尽自己最大努力去做。他们知道自己不可能完美，但只要知道自己尽力了，就能安心睡觉。
Lenny： 这个回答很有意思，也在呼应你前面说的，未来什么技能会重要。有人说过，这可能是世界上最“正常”的时刻了。
Cat： 这确实会变得更难。我感觉很多周，周日晚上还只是一个 P0，等到周一已经变成另一个 P0，周一下午又变成 P0000，你会想：天啊，我怎么会那么担心周日那个 P0。
但你得承认，你能做的只有这么多；你得睡好觉，第二天才能做出好决策；你还得非常残酷地优先排序，把时间花在最重要的事情上。要接受有些事情可以先放掉。
我们确实会发一些没有我理想中那么精致的产品。但我们的首要目标是帮助专业开发者更有力量。如果某个产品不算成功，只要它没有挡住核心使用场景，那就没关系，因为我们会收到反馈，并在下一次发布里修掉。
如果发布的功能有 bug，过去我会整晚睡不着；但现在我已经可以接受了，因为我知道我们会很快收到反馈，也会在下一次更新中修掉它。
Lenny： 我脑海里浮现的是《加勒比海盗》里那个表情包：一个人走下船上的楼梯，而整艘船都在他身后被拆掉了，但他还是非常淡定地往前走。很有意思的是，我认识的所有 Anthropic 人都特别冷静，也特别乐观。
Cat： 我觉得这点非常重要——有这种平静和乐观，而不是“天啊，一切都乱套了”。如果没有这种心态，很容易 burn out。我们也倾向于招聘那些已经在行业里待了一段时间、经历过很多起伏、知道什么能给自己能量、如何长期维持能量的人，这对我们帮助很大。

角色融合会失去什么
Lenny： 我很想问一个问题：既然工程师变成 PM，大家的边界都在融合，我们会失去什么吗？会不会失去职业阶梯和清晰的晋升路径？会不会失去设计一致性、代码质量？总会有一些代价吧。你觉得我们在为更大的好处牺牲什么？
Cat： 我们确实在牺牲产品一致性。
过去，当代码很贵时，你会非常仔细地规划整个产品矩阵：每个产品彼此是什么关系、每一个产品的使用场景是什么、怎么集成，然后通常会针对每个场景做一个产品。
但现在 AI 变化太快了，而且要测试的想法太多，所以我们有时会做出相互重叠的功能。很多时候，是因为内部有两种形态我们都喜欢，希望外部用户来告诉我们到底哪种更好。
但对于新用户来说，这意味着他们可能不知道完成某个目标 X 的最佳路径是什么。我们就需要做更多教育，帮助他们理解核心功能是什么、最佳实践是什么。我觉得这就是大量功能同时上线的代价。
用户也会觉得很难跟上最新变化。传统 PM 场景下，功能一个月或一个季度才发一次，所以用户很容易理解：我每个月看一次就好，半年不看也没事，不会觉得错过了什么。
但在这些 agentic 工具里，不只是 Claude Code 和 co-work，而是整个生态里，大家会觉得自己必须每天刷 Twitter，看看最新的东西是什么。
我觉得我们还有很多可以做的，去让用户没那么像在一台越来越快的跑步机上。我希望用户能觉得：我只要打开这些工具，它们就会教育我、告诉我我需要知道什么，让我自然跟上。
Lenny： 我前几天看到你们发了一个很有意思的新功能，我记得叫 /powerup，基本上会带着你看一遍 Claude Code 的各种好用方式和最佳实践。是不是就是你说的这个方向？
Cat： 对，完全是。以前我们不太想做这种功能，因为我们觉得产品应该足够直观，用户不需要任何教程。
但后来我们意识到，功能实在太多了，用户也真的很需要内置 onboarding。我们稍微偏离了最初的原则——“不要 onboarding 流程”——加了这个功能，因为很多用户都在问：有 100 个功能，我到底必须用哪 10 个？所以我们就把这个东西做出来了。

Anthropic 为什么能逆袭
Lenny： Anthropic 在企业 B2B 这条路上非常成功，而传统企业软件通常不会天天发新东西，往往是季度更新。你们完全相反：几乎每天都有新东西。Anthropic 的这波增长太不可思议了。Anthropic 创业时其实落后很多，大家都说它是资金最少的公司之一，也没什么分发优势，不是第一个跑出来的。OpenAI 当时明显领先。很多人都觉得 Anthropic 长期没法真正竞争。
可现在你们干得非常好，甚至在一段时间里就把一些大公司的团队甩在后面，增长极快。站在内部看，Anthropic 能这么成功、能从落后打到今天，最关键的因素是什么？
Cat： 我觉得最重要的两个因素是：第一，一个统一的使命，这一点的重要性怎么强调都不过分。我们招的人，最看重的是把安全的 AGI 带给全人类。这一点会频繁出现在我们做决策时，影响我们整个产品线到底应该聚焦什么。
因为我们把这个使命放在任何单个产品线之上，所以我们可以做出跨整个组织的快速决定，并且以统一的方式执行。我觉得这是我在这么大规模的公司里从没见过的东西。
Lenny： 所以更明确一点，你的意思是，第一要务是安全对齐，确保 AI 对世界是好的。你是说，有了这个清晰的使命，做决定就会容易很多。
Cat： 如果有两个相互竞争的优先级，我们会讨论哪一个更符合 Anthropic 的使命。这样就更容易决定二者中先做哪一个，最后大家都会支持那个决定。
有时候这意味着：我们本来想在 Claude Code 上发某个功能，但另一个事情更重要，所以我们就会把这个功能往后排，等以后再发。
Lenny： 这点很有意思。它也解释了为什么和另一家名字很像的公司相比，你们不会去做社交网络，也不会去做资讯流，因为这些并不符合使命。这让 Anthropic 保持了专注，而这看起来正是成功的核心要素。
Cat： 对我来说，使命意味着把 Anthropic 的目标放在任何个人、任何单个产品之上。所以我觉得第二个我们很擅长的东西，就是专注。使命和专注不完全是一回事。
使命意味着团队愿意为了 Anthropic 的目标、Anthropic 的 KR，牺牲自己个人目标甚至自己的 KR。大家非常愿意做这种取舍。
极端一点说，如果 Claude Code 失败了，但 Anthropic 成功了，我会非常开心。我们整个团队都非常愿意按这种思路做决定。
Lenny： 我不确定你能不能深入讲这个，但你觉得 Open Claude 的决定是不是也属于这种逻辑：它并没有推进 Anthropic 的使命，所以你们必须停掉，因为它不是你们希望它发挥作用的方式？
Cat： 对 Anthropic 来说，最重要的事情之一，就是尽可能让更多用户接触到我们。我们实现这件事的一个方式，就是通过我们第一方产品的 Claude 订阅。所以我们非常希望把重心放在这上面，但这有时候确实会牺牲第三方产品。

Claude Code、Claude Desktop、co-work 怎么选
Lenny： 我们一直在聊 Claude、co-work 这些东西。我想确保大家真正理解你们是怎么用这些工具的。现在有 Claude Code、Claude Desktop、co-work。最好的理解方式是什么？什么时候用哪一个？你自己分别在什么时候用？
Cat： 我通常会在终端里用 Claude Code，尤其是我在启动一个一次性的编码任务、并且想要用到最新功能的时候。CLI 是我们的起始产品形态，也是很多功能最先落地的地方，所以它也是所有工具里最强的那个。我通常会在一口气想启动一两个任务，或者少量任务时，用它。
如果你要做前端工作，Claude Desktop 就特别好用。我很喜欢用我们的预览功能。比如我在做一个 web app 时，经常会同时打开 Claude Code 和 Desktop，把右侧的预览面板打开，这样我在和 Claude 聊天时，就能实时看到自己在做的网页应用。
对于想要更图形化体验的人来说，Desktop 也很棒。终端对非技术用户来说可能非常陌生。你的机器上会弹出一堆吓人的提示，而你又没法像在其他大多数产品里那样点击和操作，这会让很多人觉得不舒服。
如果你不习惯终端，我非常建议试试 Claude Desktop。Desktop 还有一个优势，就是能一眼看到所有在发生的事情。你可以看到自己的 CLI 终端会话，也能看到其他 Desktop 会话，还能看到在 web 和 mobile 上启动的会话。它相当于一个一站式控制台，让你看到所有任务。
web 和 mobile 的价值，在于它们特别适合“路上发起任务”。CLI 和 Desktop 都要求你在本地笔记本上操作。但现实是，你有时候人在外面，可能在散步、出门，不一定带着笔记本，也不一定会打开电脑。我见过无数人把电脑连在手机上，站在外面办公。那说明我们缺一个能满足这个需求的产品。
对我来说，移动端的意义，就是让你可以在外面直接启动任务，不必把笔记本到处带着，也不必确保自己无论去哪儿笔记本都开着。
Lenny： 我太懂了。我在飞机上也见过这种场景，已经成了一个梗：我得把这个 agent 等完，不能关掉，我得要 Wi‑Fi。
Cat： 对。
Lenny： 而 co-work 呢？
Cat： co-work 负责的是另一类工作：输出不是代码的那些工作。比如把 Slack 清零、收件箱清零，或者为即将到来的客户会议做一个幻灯片，或者写一份关于某个功能目标的简短文档，或者写一个发布计划。这些任务的输出不是代码，而 co-work 最适合做这些。
所以我心里会这样区分：如果我要做的东西输出是代码，我会用 Claude Code、Desktop，或者 mobile 上的 Claude Code；如果输出不是代码，我就会用 co-work。
Lenny： 很多人其实低估了 co-work 的成功。它增长特别快，但很多人还是不太明白它到底是干什么的。你能举几个你工作中的使用案例吗？有没有什么特别有意思、甚至有点意外的用法，能帮你省时间、提高效率？
Cat： 如果你刚开始用 co-work，最重要的第一步，就是把和你角色相关的所有数据源连上。因为只有它能拿到所有上下文，才能真正帮你把输出整理好。
对我来说，我会连 Google Calendar、Slack、Gmail 和 Google Drive。这样它就能根据需要找到相关上下文、发问、拉线程进来，结果质量会明显提升。
我经常用它做的事情，比如昨晚我们在准备 Code with Cloud 大会，我要在那里做几场分享，其中一场是讲 Claude Code 从“助手”走向“完整 agent”的转变。为了这场演讲，我想展示我们最近发的所有能推动这个转变的产品，也想找出内部有哪些成功案例可以拿来做 demo。
所以我把 Google Drive、Slack 都接上了。我们的产品营销 Alex 先整理出一版他觉得应该覆盖的要点。我就把这些都喂给 co-work，告诉它我想讲的叙事线。它真的自己干了一个小时：它去 Twitter 看了我们发了什么，查了 evergreen launch room，查了我们的 Claude Code announce channel，也就是团队在这里发 demo、分享自己如何从 Claude Code 中获得最大价值的地方。
它把这些全部综合起来，做出了一份 20 页的演示稿。我今天早上醒来就读了这份稿子，整体上已经相当不错了，只需要一些微调。我确实又给了一轮反馈，因为我喜欢幻灯片上的字非常少，而它写得有点太多了，但这仍然比我自己做快太多了。
而且因为 co-work 能访问我们的整个设计系统，它做出来的东西看起来真的就像 Anthropic 的设计师做的一样。你一眼看上去就会觉得“这非常精致”。这类事情真的快得多。做这份 slide deck 本来要花我好几个小时，但现在它先给我一个已经很不错的草稿，我就可以把精力放在把 demo 做到最好上。
Lenny： 这简直是 PM 的梦想，做 deck 太烦了，太慢了。
Cat： 是啊。

一个 co-work 提示词示例
Lenny： 而且等你之后展示这个 deck 的时候，大家都能看到。当然不会是你第一次一键生成的版本，但你会在这个基础上继续迭代。为了帮大家自己试试，你刚才说的第一步是连接什么？Slack，还有什么？
Cat： Slack、Google Calendar、Gmail、Google Drive。
你应该把自己的沟通工具，以及存放团队关键信息、自己关心的信息和正在做的事情的“源数据”都接上。
Lenny： 好的。那你大概给它的提示词是什么，才生成了这份 deck？
Cat： 我大概就是写：帮我做一份 Code with Cloud 大会的幻灯片。我的 PMM 建议它应该覆盖这些内容。
这是我当前手工做的一版，我不喜欢。我把它链接给你了。你能不能先给我一个包含细节的建议大纲？另外，别和 keynote 的内容重叠太多，因为 keynote 更重要。
然后 Claude 就读了我发给它的很多链接，生成了一个建议大纲。我读完它给出的结构和不同想法之后，自己决定最终演讲稿应该包含什么。
这其实很能体现 PM 现在的角色：co-work 很适合做头脑风暴，能非常快地综合大量信息，把所有可能性摆到你面前。但最后，PM 还是要做最终决定：最终产品里到底该放什么。
这次我最后决定，演讲要覆盖的是：从让本地任务成功，到让每个 PR 都变绿，再到帮助工程师提交更多 PR；以及每个阶段最有说服力的 demo 分别是什么。做完这个大纲决定之后，co-work 就自己跑了好几个小时，把整份幻灯片做了出来。
Lenny： 这太棒了。终于有个不用再亲手做的部分了。感觉你其实是在跟一个“会做内容理解的 deck 设计师”对话，而且它真的懂你做过什么，能把内容做成你想要的样子，而不只是让它看起来漂亮。设计系统这块你是怎么做的？它怎么知道 Anthropic 的设计系统？
Cat： 我这次其实用的是我们已经有的一套标准化演示模板，平时做对外活动都会用。然后我只是把这个模板给了 Claude。它能看到我们用什么颜色、什么字体、有哪些不同的幻灯片格式。里面大概有 20 张示例页。
Lenny： 明白了，所以就是把模板传进去，让它照着这个工作。
Cat： 对。你也可以连接你的 Figma MCP，如果你的幻灯片格式本来就在那儿存着，它也可以直接拉过来。

PM 的工具栈
Lenny： 顺着这个说，我一直很好奇，作为 PM，你的工具栈里通常有哪些工具？Anthropic 当然是 Claude Code 和 co-work，还有你们自己的工具。还有什么别的吗？你刚刚提到 Slack，还有没有别的？
Cat： 我的工具栈基本上就是 Claude Code 和 co-work。Anthropic 的日常运行很大程度上依赖 Slack，我觉得它就是我们公司的核心 OS。坦白说，我大概有 30% 的时间，是在推动 co-work 能力的边界，这样我才能非常清楚它哪里还不够好。
我也会花很多时间和模型对话，理解它为什么会犯这些错误。我们内部其实做了很多自己的工具。
我觉得 Claude Code 给整个公司带来的一个巨大变化，是它大幅降低了开发任何你想要的自定义应用的门槛。所以我们看到一种非常明显的趋势：越来越多人在做个性化工作软件，专门针对自己特定的场景，而不是继续用那些并不完全适配的通用工具。
Lenny： 你得多讲讲。能举些例子吗？你或者别人做了哪些特别流行、特别有用的东西？
Cat： 比如我们 Claude Code 的一位销售同事，他发现自己在重复做一套又一套 deck。于是他自己做了一个 web app，里面有我们知道最有效的一些 Claude Code deck 样板，比如 101、201、mastering Claude Code 这类。他还做了一个输入客户上下文的方式，这些上下文会从 Salesforce、Gong 和其他笔记里拉取，这样我们就能针对不同客户定制 deck。
它会帮你识别出很多关键信息，比如这个客户在用 Bedrock 或 Claude for Enterprise、或者 Console，这会影响他们能用哪些功能；它会识别出客户特别关心 SLC 的 code review 阶段，然后我们就在 deck 里加一页介绍代码审查能力；它还会识别客户是不是需要符合 HIPAA，或者需要某些安全控制，于是我们会在 deck 里加一两页相关内容。
如果这个客户在 Vertex 或 Bedrock 上，而且不想用 Claude for Enterprise，我们就会把那些只属于 Claude for Enterprise 的页面删掉。
这些事通常都很手工，可能要花 20 到 30 分钟，所以很多人要么自己花时间做，要么干脆懒得做，直接用通用版 deck。而现在，这些只要几秒钟，就能得到一份定制版。

Slack 的地位
Lenny： 有意思的地方在于，Slack 就像是没人想自己做的那个工具。没有人真的想造一个“替代 Slack”的产品。你刚才的描述里，它像是很多公司的 OS。
这很有意思。大家会说 Salesforce 只是 SaaS，我们不需要 SaaS 软件了，我们自己会造。可 Slack 似乎是一种很耐久的工具，没人真的想和它竞争，去做一个更好的版本。
Cat： 我觉得它是非常重要的通信基础设施，而且它在帮助所有人获取实时更新这件事上做得非常好。
Lenny： 是啊。很多人吐槽 Slack，但它在自己要做的事情上真的做得很好，而且最前沿的团队都离不开它。
Cat： 对。而且我特别喜欢它的可定制性，他们把定制做得特别容易。所以我们很喜欢做 Slack bot，这种可折腾性让我们能按自己想要的方式把 Slack 接进来，我非常感谢 Slack 在这方面的工作。

哪些团队最会用 Claude Code 和 co-work
Lenny： 你刚才讲了很多不同团队如何用 Claude Code 和 co-work 来推进工作。除了工程团队之外，你觉得哪个团队最会用这些工具？我猜工程肯定是 token 消耗最大的团队，但如果不是，那会很有意思。现在第二大 token 消耗部门是谁？
Cat： Applied AI 很擅长把 Claude Code 和 co-work 的边界推得很远。他们很多时间都在帮客户采用我们的 API。有时，他们会代表客户做原型，而 Claude Code 让这个过程比以前快太多了。
他们还有一个双重目标：一方面要处理大量客户沟通，另一方面要处理大量客户来信和历史上下文、电话记录，所以他们既重度依赖 co-work，也重度依赖 Claude Code。
Lenny： 我理解一下 Applied AI，这是不是有点像“前台工程师”那种角色？大多数人会怎么描述他们在做什么？
Cat： 他们的工作，是帮助客户在公司内部采用最新的 API 和模型能力，不管是给客户自己的产品供能，还是用于内部提速。
Lenny： 明白了。所以它有点像很技术化的 go-to-market，或者 deploy engineering 一类的角色。
Cat： 对，完全可以这么说。
Lenny： 那它很可能就是第二大 token 消耗组织了？
Cat： 对。而且我们也看到他们在不断推动 co-work 的边界。比如这些人通常同时负责很多客户，一天里高峰时可能有 5 到 10 个客户会议。
他们常用 co-work 的方式是：前一天晚上，让它总结第二天要见的所有客户会议、这位客户都提过什么需求、当前最关注什么、上次会议留下了哪些 action items。co-work 会自动整理出一份简报，让他们在下一次会议前就知道要关注什么。
co-work 还可以帮忙研究答案。比如客户问“功能 X 什么时候上线？”它可以去 Slack 里帮这位 PM 或 PI 人员查最新 ETA，再把它加到 notes 里。这样在客户电话里，这个人就能拿到最准确的最新信息。
这些都是人们自己搭出来、再分享给团队的工作流。

token 花费是否已经超过工资
Lenny： 最近还有一个很常见的话题：token 花费会不会超过人的工资，也就是大家用 AI 的成本会不会比自己赚得还多。Anthropic 这边有没有一些数字在流传，比如工程师每月、每天、PM 等等会花多少 tokens？
Cat： 我们很清楚，随着模型变强，大家会把更多任务交给它们，也会花更多时间待在 Claude Code 和 co-work 里。所以，每次模型跳跃或者产品有重大改进时，我们都会看到每位工程师、甚至每位知识工作者的 token 成本上升。
不过，这个成本仍然远低于普通工程师的工资，但它占工资的比例在持续上升。
Lenny： 真有意思。我们刚才也聊到，作为在 Anthropic 工作的优势之一，就是你们能接触到最前沿的模型。我一直听说你们基本上可以用无限 token，想用多少就用多少。是这样吗？
Cat： 我们可以用很多 token。有些人确实会碰到限制。
Lenny： 好吧，还是有限制的。Boris，别停啊。真有意思，拥有最先进的模型，会带来这么多优势。
Cat： 这确实会形成一个很有意思的飞轮。我们也很相信要赋能内部团队，让他们尽可能快地做事。同时我们也信任每个人都知道，真正提供这些模型的算力成本有多高，所以我们相信团队会负责任地使用这些 token。
浪费 token 是很不受欢迎的，但我们信任个人自己做判断。

PM 现在最该培养的能力
Lenny： 回到 PM 角色。我们刚才已经提到过一点，但我觉得大家会很想听你更系统地讲一下。你认为现在 PM 最需要培养的、AI 公司最看重的新技能是什么？
Cat： 最难的能力，是能定义一个月后产品应该长什么样。我觉得在这个时间尺度上，模型能做什么、用户行为会怎么变，都会有很多不确定性。
但最好的 PM 能从用户如何“滥用”现有产品的边界中，看出一些模式；他们能感知方向，稳定地朝那个方向执行；如果模型能力比他们最初预期的强得多或者弱得多，他们也能调整路线。
我觉得，要在 AGI 这件事上保持“刚刚好”的信念非常难。因为每个人都能看到一个未来：模型极其聪明，几乎什么都能做。在那种情况下，其实你根本不需要多复杂的产品。你甚至可以重新回到一个文本框：你告诉模型你想要什么，它就能自己加任何工具、接任何集成，去把事情做完。它知道自己什么时候不确定，也可以主动提澄清问题。
给超级 AGI、超级强模型做产品很容易。真正难的是，在当前模型能力下，怎么把最大能力激发出来；怎么帮用户走上最佳路径；怎么引导用户利用模型的长处，同时补上它的短板。
这项技能其实很稀缺。
Lenny： 那这项能力怎么培养？是不是就是不断使用每个模型，理解它能做什么、擅长什么、不擅长什么，以及它在变化？你刚才说过“品味”，我理解成：你要对模型的能力有品味，知道它哪里强、哪里弱、哪里最近发生了变化。
Cat： 我觉得就是花大量时间和模型对话、使用模型。我特别喜欢让模型自己反思自己的行为。
比如，当我注意到模型做出一些意外行为时——比如它做了前端修改，也跑了测试，但没有真正去看 UI——这时候让模型回头解释“为什么你会这么做”，其实很有帮助。
有时它会说，系统提示里某个地方有歧义，或者它没意识到前端验证也是这项任务的一部分，或者它把验证交给了某个子 agent，而那个子 agent 没做测试，它自己也没检查。这种时候，只要你对它为什么这么决定保持好奇，就能看出是什么误导了它，这样就可以修 harness，把这个缺口补上。
另一个有帮助的点，是找到那些你最信任、能给你准确反馈的用户。通常只有少数几个人，比其他人更擅长准确表达某个模型，或者某个模型 + harness 组合到底哪里好、哪里不好。很多人都会给反馈，但不是每个人的反馈都同样有资格。找到那 5 个你真正信任的人，非常关键，这样你能很快拿到高质量反馈。
第三件事也很有用，不过并不是每个人都爱做，那就是做 eval。你不需要做几百个 eval 才有用，做 10 个很好的 eval 就足够重要。它能帮助团队量化目标是什么、进展到哪一步、还缺什么。
我认为 eval 是个长期被低估的事情，更多 PM 和工程师都应该参与进来。
Lenny： 我们已经聊了很多 eval。现在有种趋势，大家都觉得产品管理的未来就是写 eval，因为它本质上就是定义成功是什么。好，具体一点地定义出来，然后我们就知道了。你自己有多少时间会花在写 eval 上？
Cat： 我觉得 eval 的重要性会随着你做的功能不同而变化，也和你要解决的问题类型有关。我们团队里有很多人会花大量时间做 eval。我们还有一小组成员，会和研究团队非常紧密地合作，更精确地理解 Claude Code 的行为，以及最大的改进空间，并尽量把这些量化得很具体。
我个人通常会在某个功能需要更明确的产品定义时介入 eval。通常最后的产出会是：我做了 5 个 eval，告诉大家怎么跑，哪些会成功、哪些不会，以及我用过什么 prompt 来提升成功率。
不过这真的很看具体功能，不是每个功能都需要；但像 memory 这类功能，就特别受益于 eval。
Lenny： 你提到“有些人特别擅长评估模型”，这一点很有意思。其实这就像人类 eval：他们知道哪里表现好、哪里有短板。有没有你特别想点名表扬的人？
Cat： 我觉得有两类人特别厉害。
第一位是 Amanda，她负责塑造 Claude 的性格。这是个非常难的角色，因为任务太模糊了。哪怕是写代码都更容易，因为你可以验证成功与否；而塑造人格，需要你对“Claude 应该是谁”有很强的确信。
我觉得她不仅能塑造这个角色，还特别擅长说清楚目标是什么、什么算成功、什么不算成功。
我真正信任的另一群人，就是 Claude Code 团队。我们经常一起吃团队午餐。每次有新模型在测，最快的反馈方式之一，就是午餐时挨个问每个人：“你对这个模型的直觉是什么？”
很多时候，大家会给出这样的反馈：这个模型没有把自己的思考解释清楚，显得太 abrupt；或者它特别爱写很多 memories，但我们还不确定这些 memories 的质量高不高；或者有人会注意到这个模型很爱自己测试自己，这很好；也有人会觉得它测试得还不够。
这些反馈会帮助我们决定接下来应该看哪些数据，去验证这是不是一个更大的模式。我们有大量数据，但从中提炼洞见非常难，所以这群人的反馈能帮助我们形成假设，再去用数据验证。

Claude 的性格为什么重要
Lenny： 你刚才说到 Claude 的性格。我之前请过联合创始人 Ben Mann 上节目，他说 Claude 的性格、人格、constitution，是 Claude 非常重要的一部分。后来我才意识到，很多人之所以喜欢 open claw（或类似讨论），原因之一就是 Claude 的性格太好了、太有趣、太吸引人了。按他的说法，性格正是 Claude 在这么多任务上都表现好的原因。
听起来这像是个很不起眼的边缘因素：让它有趣、好玩、说话风格活泼，但其实它对 Claude 的成功非常关键。你怎么看？还有什么是大家没理解到的？为什么这个“性格”和“人格”这么重要？
Cat： 当你回顾自己合作过的人，你会发现有些人就是能让你觉得：我真的很喜欢他们的能量，我真的很喜欢他们的 vibe。
人们谈到 Claude 和 Claude Code 时，经常提到的一点，就是他们真的很喜欢 Claude 的轻松和有趣。但与此同时，它对你的任务也非常胜任。大家尤其喜欢 Claude 的低 ego。比如你告诉它：“你这里做错了。”它会真诚地道歉，像在说：“哎呀，谢谢你告诉我，我来修，我们一起把它做好。”
它也非常积极。如果你觉得“这任务太难了，我都不知道从哪儿开始”，Claude 会说：“没关系，这里是我觉得我们该走的步骤。要不要我先帮你启动？”
我认为，一个很棒的 co-worker，必须有这种积极性、偏向行动的倾向，以及能给你真诚反馈的能力，而不是对你说的每一句话都一味附和。我们希望把这些特质灌进 Claude，因为我们觉得这会让一起工作变得更愉快。

新模型到来后，产品为什么会变
Lenny： 有件事我想回到前面提过的：每次有新模型出来，你们常常得重新审视以前做过的东西。这很有意思，也可能很烦——就像“天啊，我们刚 ship 出去，现在又要重新想一遍”。聊聊你们要多频繁地回来重做几个月前发过的产品。
Cat： 随着新模型上线，我们很多变化其实是把不再需要的功能删掉。因为以前我们会给产品加一些“辅助轮”，帮助模型完成它本来做不到的事情。
典型例子就是 todo list。Claude Code 刚发布时，用户让它做大型重构，它会说：“好，我要改 20 个调用点。”然后它真的去改，但只改了 5 个就停了。于是我们就想：怎么让它记住要把这 20 个都改完？
我们团队的 Sid 就想：如果换成人类会怎么做？人类会先把自己需要改的所有东西列成清单。就像你在 VS Code 里查出所有调用点后，左边会有一个列表，你会逐个替换。那我们怎么给 Claude 也配一个类似的工具？于是他加了一个 todo list。结果我们发现，有了 todo list，Claude 就能把这 20 个调用点全部改完。
但到了 Opus 4 以及之后的模型，我们发现其实不需要强迫它用 todo list 了，它自己就会自然地用。对于早期模型，我们还得不断提醒它：“你都把 todo list 做完了吗？只有全部做完才能结束。”而后来的模型，不用提示也会自然想到去完成 todo list。
现在，todo list 作为用户功能还是挺好的，因为你能更清楚地看到 Claude 在做什么。但说实话，它现在已经不是那么核心了。模型可能会用，可能不会用；要把事情做彻底，它已经不再必须依赖这个东西。
Lenny： 我记得有人在节目里说过一句话：“模型会把你的 harness 当早餐吃掉。”按你刚才的说法，就是你们会随着模型变强，慢慢去掉那些之前加在模型上方、为了弥补它表现不足而做的东西。模型越聪明，事情就会变得越简单，因为它自己就能更自然地做出你想要的事。
Cat： 对。每次模型变聪明，我们就能移除很多 prompt 干预。我们每次发布新模型都会做这件事：把整个 system prompt 读一遍，反思其中每一段提醒，模型现在真的还需要吗？如果不需要，就删掉。
不过，新模型真正最令人兴奋的地方，还是能解锁全新的功能。很多功能我们以前都试过，但因为准确率不够高，所以一直没敢正式发布。
比如 code review。我们之前尝试做过几次 code review 产品，也发过更简单的版本，比如过去的 /code review 命令。但直到最近这些模型，我们才觉得这套 code review 好到足以让工程团队真的依赖它，在合并 PR 前先过一遍 review。我们一直梦想 Claude 能成为一个可靠的 code reviewer，真正能抓住大多数 bug。只有到了 Opus 4.5、4.6 和 Sonnet 4.6，我们才觉得：可以同时跑多个 code review agent，覆盖整个代码库，综合出工程师在 merge 前必须处理的真实问题。这就是新模型解锁的新能力。
Lenny： 这也是我节目里很常见的一个主题：先做一个“未来六个月可能才会真正可行”的东西，站在当前能力的边缘上，然后等模型赶上来，你的产品就会突然变成一个很棒的产品，而且会领先所有人。
Cat： 对，完全没错。做一些“现在还不完全工作，但未来很可能会工作”的产品，非常重要。这样你才能真正看清，产品要工作还缺什么；等最新模型一出来，你就能把它直接替换进你已经做好的原型里，看它是否真的补上了那个缺口。

Claude 和 co-work 的长期愿景
Lenny： 你能说多少关于 Claude 和 co-work 未来会往哪走？我猜你不会想透露太多，但我感觉你们一直在不断往上加新功能：手机端派发任务、各种移动能力等等。怎样能更好地理解这些东西的长期愿景？
Cat： 我们会把这件事理解成“搭积木”。对于 Claude Code 和 co-work 来说，最核心的积木，是让单个任务成功。
你想产出某个结果，就给它一个清晰的 prompt 和描述，然后看它能不能持续输出你可以合并、或者可以分享给同事和外部受众的可接受结果。任务成功率，就是最核心的积木。
随着模型变聪明，单任务成功率会高很多。然后我们看到用户开始同时做多个任务。多任务并行，在 2025 年底已经变成一件大事，而且之后只会越来越普遍。
所以我们会这样看：好，一个任务现在能稳定工作了，接下来你就可以一次做 6 个任务。再往后，如果模型更聪明，我们的推演是，也许你会一次运行 50 个 Claude，甚至几百个 Claude。那我们就需要什么样的基础设施，才能支持这个规模？
到了那个时候，你大概率不会再把所有东西都本地跑在机器上，因为内存根本不够。所以我们会思考：怎么让你更容易管理这些任务？它们很可能会远程运行。
我们要怎么设计界面，让你这个人类知道哪些任务需要关注？怎么保证 agent 会彻底验证工作，这样当它告诉你“完成了”的时候，你能非常快地验证并完全信任它确实按规格完成了？又怎么让这个过程自我改进：当你发现某个任务没有达到你的要求时，可以直接给反馈，而模型在未来的所有运行中都能吸收这条反馈，再也不犯同样的错？
这就是我们带用户一起走过的演进路径。

给从业者的建议
Lenny： 很多听众是 PM、创始人，或者其他跨职能角色。大家都会担心自己的职业未来。你会给什么建议？不仅是“怎么活下来”，而是怎么在这种 AI 驱动的世界里真正做得很好、甚至蓬勃发展？大家需要听到什么、需要做什么？
Cat： 我觉得 AI 给每个人带来了比以前大得多的杠杆。所以只要你发现自己在重复做某个手工任务，就应该想一想，能不能用 Claude Code、co-work 或其他 AI 工具把它自动化。
大多数人的工作里都有很喜欢的创造性部分，也有非常讨厌的琐碎部分。我觉得 AI 最美妙的地方，就是它可以替你做那些琐碎工作，它可以从你每次做手工任务中学习，然后泛化成自动执行，这样你就能把精力放回到创造性部分。
这意味着你能做的事情会比以前多很多。所以我对大家最直接的建议是：找出那些重复性工作，把它们交给 Claude。不断迭代这些自动化，直到成功率非常高，然后再思考：我还能为团队、产品、公司做些什么，是以前因为没有带宽而没能做的？或者，有没有哪个你一直觉得公司应该做、但总没时间做的小项目？如果 AI 能处理掉那些体力活，你就会多出大约 20% 的时间。
所以我的建议是：拥抱这些工具，把你不想做的工作交出去，想办法让它们加速你。这样你就能做更多事。
Lenny： 你刚才说的核心观点，我完全同意：找到能用 AI 解决的问题。很多工具的潜力大家都看得到，但对很多人来说，最难的部分其实是“我到底该做什么”。你这套说法其实就是：多留意你一直在做、而且可以自动化的事情，多留意那些你一直想做但没时间做的点子。也就是说，给自己解决一个问题，基本就是核心建议。
Cat： 对。我也会鼓励大家，重点不是“这只是个很酷的概念”，而是把自动化真正做到 100% 可用。我看到有人会尝试自动化某件事，把准确率做到 90%、95% 就放弃了。但如果一个自动化不是 100% 稳定，那它其实就还不算真正的自动化。最后那 5% 到 10% 往往最费时间。
而且，构建自动化常常比自己做还慢。所以我鼓励大家花时间把你真的想要的自动化打磨到 100%。下功夫教好它，让它理解你的偏好，持续给它反馈，帮助它提升技能，直到它真的能稳定到 100%。这样你才真的能依赖它。95% 的自动化，价值其实不大。
Lenny： 我超级有这个毛病。这对我很有帮助。
Cat： 我也有同样的问题。我最近一直在教 co-work 帮我把 Gmail 变成 inbox zero，但这个过程非常耗时，而且你可能已经发现了，它目前还不够好。
Lenny： 哈哈，有意思的是，我脑子里想的正是这个。我有个工作流，每封邮件进来都会检查是不是垃圾邮件，就是那些“嘿，我能上你的播客吗？”或者“这个你怎么看？”之类的请求。我根本没时间处理这些，所以我给它设了一个叫 spammy 的文件夹。它大概 95% 的时候都做得很好，但偶尔也会漏掉真正重要的邮件。你这番话正好提醒我，我应该把它做到完美。
Cat： 对。我们现在也在努力把自定义这些命令的流程变得容易一些，因为目前你得知道太多概念：你得知道怎么定义 skill，还得知道怎么用这个 skill 并给它反馈，还得知道怎么让 co-work 根据所有反馈去更新 skill，还得知道去哪儿读 skill，确认反馈是不是按你想要的方式被吸收了。我们的工作之一，就是让这个流程尽可能无痛。

最后一段补充
Lenny： Cat，还有什么你想分享的？有没有什么想留给听众的话？有没有什么你想再强调一下、但我们还没聊到的？在进入很精彩的闪电问答前，你还有什么想说的？
Cat： 我看到很多人都在玩 AI，做一些原型应用，或者折腾工作流。我真的很想推动大家去构建那些你自己每天都真的在用的应用，因为只有在真实使用中，你才能真正获得价值。
如果你做了一个原型应用，但它并没有帮你做更多事情，那 AI 其实并没有真正给你的日常带来价值。
你从“只是一键生成了个东西，好酷”里能学到的也有限，尤其是之后你再也不回头用它的时候。那样你学到的不多，也没有真正获得杠杆。
Lenny： 这点说得太好了。
Cat： 我还觉得，有些人会花很多时间自定义自己的工作流。光谱一端，是那些从来不做自定义、也不做自动化的人；另一端，是那些过度沉迷于自定义工具的人，他们会疯狂加 skill、加 MCP、加各种 workflow 改进。我觉得有时候，这甚至会分散你对核心目标的注意力——比如发布一个产品、做出一个功能。
定制确实很好玩，我们也希望自己的产品很可折腾，这样你可以把它调成最适合自己的样子。但这件事也有上限。有些人可能会花太多时间在定制上，结果没睡觉，也没去做原本真正想做的核心工作。
Lenny： 我在 Twitter 上经常看到这种东西：大家晒自己的“工作流配置”，说自己已经优化到失控了。然后问题就是：那你到底做了什么？
Cat： 对啊，配置很酷，但你到底造了什么？我反而觉得，简单的配置通常更好。
Lenny： PowerUp 这类东西，就是把等级稍微提升一点。
Cat： 对。
Lenny： 昨天我看到一条 Karpathy 的推文，他说了一个很有意思的分化：一部分人早年试过 ChatGPT、Claude 之类的工具后，觉得“也就那样”，于是放弃了，变得很犬儒，认为 AI 没什么大不了；另一部分人则把它真正用来写代码，因此看到了它强大的全部力量。两边的人都不太理解对方，也不理解对方为什么会这样看世界。你这边的建议非常对：真的拿它去做现实任务，看看它究竟已经变得多强。
Cat： 我觉得最大的变化是，2024 这一代产品还是“聊天式”的，而 Claude Code 这一代产品已经是“行动式”的。
人们真正“啊哈”的时刻，是当 Claude 可以代表你直接做事。知道 agent 不只是告诉你该做什么，而是真的能替你把事做了，这种感觉太棒了。当人们体验到这一点时，那就是最震撼的时刻。
Lenny： 顺便给那个 Chrome 扩展点个赞。Claude Code 的 Chrome 扩展很有意思，你可以直接看着它帮你干活。比如你说：“帮我填个表单”，它就会说：“好，我来了。”
Cat： 对。

闪电问答
Lenny： 好，在进入我们非常激动人心的闪电问答前，还有别的吗？
Cat： 没有，来吧。
Lenny： 好的，Cat，我有 5 个问题。欢迎来到闪电问答。那个动画环节我得确保说出来。准备好了吗？
Cat： 准备好了。
1. 你最常推荐给别人的两三本书是什么？
Cat： 我很喜欢《亚洲如何运作》（How Asia Works）。它讲的是经济发展，以及哪些政策和政府能造就长期成功的经济体。
我还很喜欢《科技陷阱》（The Technology Trap）。这本书讲的是过去几轮技术革命——工业革命、计算机革命——以及它们如何影响劳动者。我喜欢这本书，是因为我觉得历史里有很多东西可以学，能帮助我们确保这次转型顺利。
还有一本比较轻松的，是《纸神》（Paper Menagerie）。这是一本短篇小说集，讲的是成长、AI 和自我发现。
2. 你最近最喜欢的一部电影或电视剧是什么？
Cat： 我很喜欢《Drive to Survive》。没有什么更深的含义，就是看人们对一个单一工程目标如此痴迷，会让人很满足，会感受到他们追求纯粹性的感觉。
我也特别喜欢《Free Solo》，讲的是 Alex Honnold 不带安全绳攀登酋长岩。类似地，这也是一种非常纯粹的成就：去完成一条极其困难、极其危险的路线，而且你必须保持绝对专注，因为一旦犯错就会死。
Lenny： 那部片子真的离谱。很有意思的是，这跟你做的工作居然也有某种关联。
Cat： 我其实就是个攀岩爱好者。我第一次看《Free Solo》是在我开始攀岩之前，所以当时只是觉得“很厉害”，但我根本不明白它到底有多离谱。
这种电影很少见，知道得越多，越会被震住。像他在墙上做的那些动作，我这辈子哪怕放在健身房里、离地一英尺、还系着绳子，可能都做不到。
Lenny： 你看过那部关于另一个年轻人的纪录片吗？就是去冰山上的那个？
Cat： 看过，那部很悲伤。
3. 你最近发现、并且非常喜欢的产品是什么？
Cat： 除了 Claude 相关产品之外，最改变我生活的产品，大概就是 Waymo 了。我是 Waymo 的铁杆用户，每天上下班都会坐两次。
我喜欢它的两个原因是：第一，Waymo 不会让我有负担感。如果它在等我，我不会觉得必须立刻跑到路边等它，所以压力会小很多。
第二，我觉得它让我更高效了。和另一个人类在车里时，我通常不太会开工作电话。我会觉得一直在笔记本上工作有点不礼貌。但 Waymo 不一样，我可以在车里接工作电话，不用担心别人听见，不用担心“这会不会不礼貌”，也不用担心“我是不是太大声了”或者“是不是得让别人换音乐”。这相当于每天给我省回了 30 分钟。
Lenny： 这些技术的二阶效应真的很有意思。
Cat： 对。我以前一直以为 Waymo 要比 Uber、Lyft 便宜才会成功，但其实我很愿意为它付 2 倍价钱。
Lenny： 我也很喜欢 Waymo。它就是那种“你一旦见过，就会觉得太疯狂了”的东西。然后你会习惯它。你一坐进去会想：“这太不可思议了。”然后过一会儿你又忘了它有多神奇。
Cat： 对，而且它还改变了我们的说法。Anthropic 很多人都很喜欢 Waymo。以前你会说“叫个打车软件”，现在大家都会直接说“Waymo 到了吗？”
4. 你最喜欢的人生格言是什么？
Cat： 就是“做事”。
Lenny： 没错。
Cat： 我觉得第一性原理思维很有价值。如果你知道自己在优化什么，而且你的第一性原理很扎实，那么你通常能推导出正确的行动路线，并且能把它清楚地讲给所有利益相关方听。然后你就应该直接去做。
我觉得很多职位其实是“假的”。如果你理解了约束条件，你就能知道自己能做什么，然后快速去做，快速从错误里学习，做错了就道歉或修正。
Lenny： 你说得太对了，谁说的这句真好。
Cat： 我觉得把这句话告诉别人，其实很解放人。在很多公司里，角色定义得特别死：好，这些是 PM 做的事，这些是设计师做的事，这些是工程师做的事。连团队边界都画得非常 rigid：这块代码我们能碰，那块不能碰。
而“做事”这件事能让人真正感到被授权，可以跨团队边界做决策，只为了把事情推进下去。
Lenny： 这听起来像是一项非常重要的技能。人们会把它叫作 agency，或者偏行动、主动推进。这些说法本质上都在讲同一件事：别等许可，先去做。
Cat： 对。我觉得，人生中最值得去体验 startup 的原因之一，就是你会学到这个。对我来说，一个真正改变人生的经历，是当公司只有 20 个人的时候，我第一次在这种规模下工作。那时候根本没流程，问题又巨大，需要我们去解决。
我非常感谢 Alex 和整个团队，他们让我和其他人都能不受“销售应该做什么、运营应该做什么、工程应该做什么”这些边界限制，直接去想办法。你手里有所有工具，面前又有一个很大很难的问题，你可以用任何办法去找到好的解决方案。
你几乎必须经历过这种环境，才能培养出这种能力，才能真的在行动上感到自在。很多人上学、读大学时，学到的是“照我们说的做，你就会得高分”。你得学会把这种思维卸下来，变成“我要做真正需要做的事情，哪怕别人觉得这很蠢，我也认为这是对的”。
Lenny： 对，就是这样。
5. Claude 思考时，你最喜欢的那个“思考词”是什么？
Cat： 我很喜欢 “manifesting”。而且这也是我最喜欢的一张贴纸。
Lenny： 很明显的冠军。
最后一个问题：如果 AGI 在我们有生之年到来，而你不需要工作了，你会做什么？
Cat： 我觉得 AGI 真正渗透到整个社会，还会花很长时间。所以眼前最重要的事，其实是帮助世界一起跟上。
如果认真讲未来，我大概率会做很多攀岩。我可能会搬去 Fountainbleau，住在一万块巨石中间，爬一阵子。
我还有好多书想读。我的目标是每周读一两本书，但现在大概只有 0.5 本。
未读清单太长了。我觉得历史里有太多东西值得学习，我也有太多地方还远远不懂，比如物理、机器人、硬件、航空航天之类的，太多有趣的话题了。所以哪怕 AI 早就知道这些，我还是会很兴奋地继续学。

收尾
Lenny： Cat，这期太精彩了。你太棒了。
再问两个追问：如果大家想在线上找到你、关注你在做什么，应该去哪里？以及听众怎样才能对你更有帮助？
Cat： 最好的方式是去 Twitter 找我，我的账号是 @Catwoo。欢迎在 Twitter 上提到我，也欢迎私信我。我会看所有私信，不一定每一条都回复，但我都会看。
而最有帮助的事情，是告诉我们 Claude Code 和 co-work 哪里不好用。我们非常感激正面反馈，但真正让我们成长的是边界情况、错误，以及那些我们能复现的具体任务——也就是 Claude Code 或 co-work 失败的地方。
如果你能把这些反馈给我们，而且我们能复现，那我们就能在下一代模型和下一代 harness 里真正把它改好。
Lenny： Twitter 上的人从来不吝啬反馈，所以请继续发。
Cat： 对，请继续把你遇到的问题发给我们。
Lenny： 真的很酷，看到你和团队这么活跃地在 Twitter 上回应大家，说明这些反馈你们真的会看到、真的会处理。
Cat： 是的，我们非常感谢大家这么积极参与。这给团队带来很多能量。我们有一个叫“user love”的频道，只要大家分享成功案例，我们就会发进去；如果大家分享产品问题，我们就放到反馈频道，方便更广泛的团队去处理。
Lenny： 能知道这个真的太好了。谢谢你分享。
Cat，非常感谢你来做客。
Cat： 谢谢邀请。
Lenny： 拜拜，大家。

我是邓小闲koki，微信 m61502202，推特@kokisanai，加好友请说明来意。

我的个人故事：

AI系列