这是 Lenny’s Podcast 对话 Anthropic Claude Code / Co-work 产品负责人 Cat Wu 的完整中文翻译。原视频来自 YouTube：https://www.youtube.com/watch?v=PplmzlgE0kg 。译文尽量保留口语节奏，技术术语与公司名、产品名保留英文。
Cat：我觉得，“被 AGI 洗脑”的分寸是很难拿捏的。给那个无所不能的超强模型做产品其实很容易，真正难的是面对当下这个版本的模型，你怎么把它的能力尽可能地激发出来。
Lenny：我从没见过哪家公司能像你们 Anthropic 这样快地出货。
Cat：我们就是想把所有阻碍出货的障碍一个个拆掉。我们很多产品功能的交付周期，已经从六个月缩短到一个月，有时候甚至一天就能上。
Lenny：你面试过上百位 PM，你一直觉得很多人切入这件事的方式是不对的。
Cat：PM 这个角色正在发生非常大的变化，而且变化非常快。想把 AI 原生产品做好，最关键的一点是迭代要足够快，要能做到每周都有新功能上线。
Lenny：那你觉得未来 PM 需要培养的能力是什么？
Cat：归根结底还是产品品味。当写代码变得越来越廉价，真正值钱的就是判断该写什么。
Lenny：今天我请到的嘉宾是 Cat Wu，Anthropic Claude Code 和 Co-work 的产品负责人。Cat 正处在 AI、产品与构建这三件事交汇的中心，她和她的团队正在做的，是那个正在最深刻地改变我们每个人造产品方式的产品。她身上满是洞察、智慧和经验，这一期你绝对不能错过。进入正题之前，记得去 lennysnewsletter.com 看看为 Lenny’s Newsletter 订阅者准备的一堆专属福利。OK，那就有请 Cat Wu。Cat，欢迎来播客。
Cat：谢谢你邀请我。
Lenny：我有一大堆问题，超级兴奋你能来。我想先让大家理解一下你和 Boris 的角色。大家都知道 Boris，他在这个播客的那集是目前排名第一的最受欢迎的一期，压力不小啊。他创造了 Claude Code，带着团队，从手机上一天不知道 merge 多少个 PR，我已经跟不上那个数字了。我觉得大家给你的认可是不够的，Claude Code 和 Co-work 以及你们做的所有东西能走到今天，你功不可没。能不能讲讲你在团队里的角色，你和 Boris 怎么分工，Claude Code 团队里 PM 这个角色具体长什么样？
Cat：我觉得能和 Boris 共事是非常幸运的事。他是我非常棒的思考搭档，是技术负责人，也是真正意义上的产品远见者。他特别擅长定义”三个月后、六个月后这个产品应该是什么样”，也就是那个被 AGI 洗脑之后的产品形态。我的工作很大一部分，是想清楚从今天这个状态出发，怎么一步步走到三到六个月后那个愿景。我在跨职能协作上花的时间更多，确保我们的 marketing、sales、finance、capacity 这些团队都认同计划，大家朝同一个方向使劲，并且在功能准备好的那一刻，出货没有任何阻碍。我觉得这种分工挺顺畅的，我们两个人有点像心灵相通，其实界限非常模糊。大概 80% 是共识区，另外 20% 里，有些事我更在乎，我就去推；有些事他更在乎，他就去推。
Lenny：本期节目由我们这一季的冠名赞助商 Work OS 赞助播出。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 这些公司，还有几百家头部公司的共同点是什么？他们都跑在 Work OS 上。如果你在做面向企业的产品，你一定感受过做 single sign-on、SCIM、RBAC、audit logs 这些大客户必备能力的痛苦。Work OS 把这些阻碍成单的东西，变成了可以直接接入的 API，是一个专为 B2B SaaS 打造的现代开发者平台。几乎我投的每一家开始向上拓展企业客户的创业公司，最后都用 Work OS，因为他们真的是做得最好的。不管你是想拿下第一个企业客户的种子轮团队，还是要全球扩张的独角兽，Work OS 都是让你最快变得 enterprise ready、打通增长瓶颈的选择。本质上就是面向企业功能的 Stripe。去 workos.com 上手，或者直接去他们的 Slack，那里有真正的工程师在等着回答你的问题。API 顺手、文档齐全、开发体验流畅，今天就去 workos.com，让你的应用具备企业级能力。
Lenny：开录之前你提到过，你一直在面试 PM，而且量非常大。每次有人让我给他介绍去 Anthropic 做 PM 的人，我要是能收五毛，大概早就积累 30 billion ARR 了，Anthropic 就是所有人最想去的公司。所以我完全能想象你面了多少 PM。你说你看到大家做这件事的方式都是错的，很多人对”怎么做成一个 AI PM”的理解从一开始就跑偏了。讲讲你看到的情况，大家需要理解的到底是什么？
Cat：AI 出现之前，技术变迁比较慢，所以你可以按 6 到 12 个月的时间窗来规划。因为功能交付节奏没那么快，重心会更多放在和合作团队对齐路线图，确保对方的功能能解锁你的功能，因为那时候写代码的成本非常高。现在 AI 把工程提速了这么多，模型能力升级又这么快，我们很多产品功能的交付周期从 6 个月缩到 1 个月，有时候是 1 周，甚至 1 天。这意味着产品必须非常快地出货。对 PM 来说，就不应该把那么多注意力放在”确保我的多季度路线图和合作团队对齐”，而是要放在”怎么用最快的方式把东西推出去”。我们要想怎么在产品矩阵里开出一块”concept corner”，让一个工程师或者 PM 有个想法，当周就能到用户手里。在 AI 原生产品上做得最好的 PM，往往是那些能想清楚”如何把从有想法到产品到用户手中的时间压到最短”的人，同时能帮团队定义哪些任务是产品最核心、必须开箱即用的能力。
Lenny：我特别喜欢你这个观点。你是在说，很多人压根还没意识到现在节奏需要多快，以及 PM 现在有多大一部分工作其实就是推着团队跑得更快。除了用上最强的模型，你们还做了什么来让自己跑得这么快？
Cat：首先是定义清晰的目标。因为 LLM 太通用了，这反而在”我们到底在为谁做、在解决什么问题、核心用例是什么”这些事上制造了大量模糊性。一个优秀的 PM 要能说：我们的核心用户是专业开发者；这个功能要解决的主要问题，是权限弹窗太多、用户会疲劳；对应的用例是，让企业里的专业开发者能安全地把权限弹窗降到 0。这就划出了一个非常清楚的目标，因为它排除掉了很多减少权限弹窗的其他做法，让用户用一次 prompt 就能做更多事。第二件重要的事是建立一个可复用的出货流程。Claude Code 这边，几乎所有功能我们都是以 research preview 的形式上线的，在上线的时候我们明确地把它打上研究预览的标签，让用户知道这是个早期产品、一个想法，我们是想拿反馈、做迭代，而且它不一定会被长期支持。这样做会降低我们上线一个东西的承诺成本，一两周就能把它推出去。第三件 PM 该做的事，是给团队搭好协作框架，让他们知道什么时候需要把跨职能伙伴拉进来、这些伙伴的期望是什么。比如我们在 engineering、marketing 和 docs 之间有一套非常紧的流程。工程师觉得功能已经准备好、内部也 dogfooding 过了，就把它 post 到 evergreen launch room 里；然后 docs 的负责人 Sarah、PMM 的 Alex 以及 DevRel 的 Tar 和 Lydia 就会冲进来，第二天就把发布宣传稿搞定。因为流程够紧，任何工程师想上线一个东西的阻力都很低，这套流程就应该由 PM 来搭。
Lenny：那 PRD 在这里面处于什么位置？你刚刚说目标对齐很重要：成功长什么样、目标用户是谁、不是给谁的。你们现在还写 PRD 吗？还是只是几句 bullet？PM 的这一块工作在现在的状态下是怎么演变的？
Cat：我们主要做两件事。一是非常严格的指标读数，每周整个团队会做一次 metrics readout，目的是让每个人都深刻理解业务的方方面面：我们的关键目标是什么、趋势如何、被哪些因素驱动。二是我们有一份团队原则，里面包括我们的核心用户是谁、为什么是他们。我们把这些都写清楚，是为了让每个人都觉得自己理解这个业务是怎么跑的、我们看重什么、我们愿意牺牲什么。这样大家就能自己做决策，不会觉得被 PM 或者其他相关方卡住。
Lenny：我很喜欢这一点，它其实在回答”未来还需不需要 PM”这个问题。现在很多人在说”我们就直接上线、直接做就好了，要 PM 干嘛，工程师就够了”。
Cat：我们有时候其实也写 PRD。对一些特别模糊的功能，写一页纸把目标、让人愉悦的使用场景、目前需要修掉的失败模式讲清楚，是有用的。还有一些项目，尤其是需要重度基础设施投入、要做几个月的，我们也会写 PRD。
Lenny：我想再往里挖一点，你们怎么能跑这么快？我真没见过有公司能像 Anthropic 这样出货。有人做了一张 Anthropic 的发布日历，几乎每天都有一个重大功能或产品。大家线上有个问题：你们刚刚上线了一个叫 mythos 的超强模型，因为它太强了，目前还在 preview，因为你们自己也对它能干的事有点顾虑。你们是不是自己在用它？这是不是你们跑得这么快的原因之一？
Cat：我们其实已经跑了好几个季度这种节奏了，所以不是完全归功于 mythos。Mythos 是一个非常强的模型，我们内部确实在用这些模型，这让我们的出货速度又快了一点，但远不能解释大部分的提速。提速更多来自流程和团队对自己的预期。我们非常 light process。我们想把出货路径上的每一道障碍都拆掉，想让团队里每一个人都觉得自己有权把一个想法从”只是个想法”推到”出现在世界上”，而且不超过一周，有时候一天就够。
Lenny：哇，拥有最强模型同时还在做产品，这优势也太猛了。
Cat：我们非常幸运，能和 frontier model 一起工作。
Lenny：天哪，真是一个超爽的优势：造一个东西，自己用它，然后加速自己做下一个东西。说到这我想岔开聊几个别的话题，因为 Anthropic 最近发生的事太多了，我很想听你讲讲。第一个是大概一周前，Claude Code 的全部源代码泄露了。好像是有人犯了个错。这件事你能说点什么吗？到底发生了什么？出了什么问题？大家应该知道些什么？
Cat：我们看到之后立刻介入调查。这件事的根源是人为错误：有一个人在用 Claude 写一个 PR，这个 PR 是关于我们怎么 release packages 的更新，而且它其实经过了两层 human review。所以这是人为疏忽，我们已经强化了流程，确保以后不会再发生。
Lenny：这个人还在 Anthropic 吗？没有被怎样吧？
Cat：还在，还在。这是流程失误，最重要的是从中学习、加固防线，避免再发生。这也是我们最近在做的，大部分加固已经上线。
Lenny：OK。我还有一个问题是关于 open Claude 的。最近你们采取了一些措施，限制别人用 Claude 订阅去驱动 open Claude 这样的第三方工具，用户里炸了一些，他们很困惑为什么要这么做，觉得这对开源社区是伤害。大家需要理解的是什么？
Cat：我们最近看到对 Claude 的需求非常大，一直在很努力地扩容基础设施，同时让我们的 harness 在 token 使用上更高效，让你能用同样的额度做更多事。订阅并不是为第三方产品设计的，第三方产品的使用模式和我们自己的一方产品不同。我们花了很多时间在找最平滑的过渡方式。所以我很开心能告诉大家，每个订阅用户都会附赠一些 credit。但我们确实需要做这个艰难的决定：优先照顾自己的一方产品和 API。这个决定就是从这个取舍里来的。
Lenny：这件事我觉得很说得通。你们每个月 200 刀在补贴这种几乎无限的使用量，大家可能没意识到，公司是要赚钱的，我们是要盈利的，在算力这么紧张的时候不可能随便送。所以我理解。回到 PM 团队本身，Anthropic 的 PM 团队是什么样的？一共多少人？怎么组织的？
Cat：我们有好几个 PM 团队，现在大概总共 30 到 40 个 PM。有一个 research PM 团队，由 Diane 带队，负责把客户对我们模型的反馈理解透、反馈给研究团队，同时负责模型发布的节奏。还有一个 Claude Developer Platform 团队，维护 Claude Code 所依赖的 API，同时发布像 managed agents 这样的能力，让你可以构建自己的 agent，由我们代为托管。然后是 Claude Code 团队，同时做 Claude Code 和 Co-work 这两个核心产品。还有 enterprise 团队，让 Claude Code 和 Co-work 对企业客户更容易落地，从 cost controls、RBAC、security controls 等等，确保企业放心使用我们的工具。还有 growth team，负责整个产品矩阵的增长，在 Claude Code 和 Co-work 上和我们配合非常紧密，在 Claude Developer Platform 即 Claude API 的增长上和另外的团队协作。
Lenny：说到增长，Amole 前几期刚上过播客，他有一个很有意思的观察，和大多数人讲的不一样。大家通常都说未来需要的 PM 会更少，PM 干嘛、工程师直接出东西就好。他的判断是，正因为工程师跑得太快，PM 和 designer 被挤压了：每天都有新功能出，根本追不过来。所以他反而需要更多 PM。你怎么看？你觉得 PM 会越招越多吗？PM 这个职业长期会往哪走？
Cat：我觉得所有角色都在融合。PM 在做一些工程的工作，工程师在做 PM 的工作，designer 既 PM 又写代码。你可以有两种选择：要么多招一堆有强产品品味的工程师，要么工程招聘规模不变，额外招很多 PM 去引导他们的工作。在我们团队，我们更偏向招有强产品品味的工程师。这样能把出货任何产品的协作成本降到最低。我们团队里有很多工程师完全可以端到端地搞定一个东西，从”在 Twitter 上看到用户反馈”一直到”周末把产品上线”，几乎不需要产品介入。这其实是出货效率最高的方式。所以我觉得工程师和 PM 在重叠，不管你是哪一种，多招都能带来很大收益。产品品味目前仍然是一种稀缺能力，只要有人明显展示出这个能力，我们基本都会愿意招进来。
Lenny：你自己的背景是工程对吧？
Cat：对，我做了很多年工程师，后来短暂做过一段 VC，然后加入 Anthropic。其实我们团队几乎所有 PM 都做过工程师或者在 Claude Code 这边本身就写代码，这也是我们团队内部建立信任、跑得更快的重要原因。而且我们的 designer 此前也都做过前端工程。
Lenny：哇，这就是很多人最关心的问题：确实有一种融合在发生，Venn 图在合并。对很多人来说真正的问题是，如果你从工程、产品或设计任一方向来，这三种核心技能里哪一种最值钱？在 Anthropic 和 Claude Code 上，工程看起来非常重要。但在别的公司里，你如果是设计背景转 PM，或者你本身就是 PM，会不会更有价值？
Cat：我还是觉得归根到底是产品品味。当写代码变便宜以后，真正稀缺的是判断该写什么。这个功能合适的 UX 是什么？最让用户愉悦的体验是什么？我们每天收到几万条 GitHub issue，来自五湖四海，挑出哪些值得做、怎么做，这需要很多细心和品味。这种能力可以来自任何背景，但它是最重要的。为什么未来几个月工程背景特别有用？因为工程背景能让你对一件事”应该多难”有直觉，而这个直觉经常会影响你要不要做。一个东西很容易做，你可能就直接花一个小时做了，省得开会讨论；一个东西你预判起来会很难，你就知道要投入多少团队成本才能把它推出去。这对优先级判断有帮助。
Lenny：你特别说”未来几个月”，是因为几个月之后模型可能强到你都不用懂这些了？
Cat：我觉得”有价值的技能集”这件事变化相当频繁，很难做超过几个月的预测。所以这并不是说某一次特定的变化要来了，而是说一定会有大的变化发生。
Lenny：那你不是在暗示 mythos 一旦发布就把一切改写，工程就不重要了？
Cat：不是，我只是说几乎每隔几个月，编码能力就会有一次大幅跃升，这会改变其他角色的价值。我觉得最关键的是要有 first principles thinking，你要能搞清楚技术格局在怎么变、团队现在最需要你补哪个洞，然后跳进去填上。因为工作本身变得越来越”无形”，一个优秀的 PM 要能看清楚所有缝隙在哪、判断哪个最重要，然后想：我要怎么学这个能力，或者我已有的哪种能力可以用来解决这个挑战。所以当下这个环境特别看重那种能戴多顶帽子、能随时切换、对”我该做什么工作才能帮团队跑得更快”不计较、没有架子的人。
Lenny：我很喜欢这个回答。我一直在问处在你这种位置的人、在 AI 能力最前沿做产品的人一个问题：在走到超级智能之前，人脑还能在哪些地方发挥作用？从你刚刚说的听下来，一个是选题：知道市场往哪走、判断要优先做什么；另一个是做出来之后知道这个东西好不好、对不对，把一个早期版本推出去。是这样吗？除此之外还有吗？
Cat：我觉得人类还在提供一种模型目前缺少的常识。任何一个产品发布，都有成百上千个小细节要处理。每一个看起来都不大，但能出问题的地方非常多。模型并不总能清楚地知道所有相关方是谁、他们之间什么关系、他们各自的偏好是什么、在什么场合怎么沟通才能让大家跟得上这个发布。这些偏隐性、偏 EQ 的常识，目前还是很值钱的。我们当然希望模型在这些方面也越做越好，我相信它们也会，但当下仍然有差距。
Lenny：作为一个身处这种高强度持续变化中的人，你是怎么撑下去的？身在龙卷风的中心，也许那里反而最安静？你怎么保持对局面的把握，又怎么在这种疯狂里保持清醒？
Cat：我们团队里都是一群会主动拥抱混乱的人。我们会尽量带着笑去面对每一个挑战，因为该发生的事永远在发生，风险和复杂的情况永远在冒出来。如果你为每件事都紧张，你会烧尽的。所以我们很在意找这样一种人：看到一个挑战能说”这会很难，但我很兴奋能上手去搞，我会尽最大努力，我知道我不会做到完美，但我能安心睡觉”。
Lenny：这其实也是对”未来什么技能重要”这个问题的一个有趣回答。我忘了是谁说过，“现在是这个世界未来最正常的一天”。
Cat：对，确实只会更难。很多个星期我的体感是：周日晚上有个 P0；到了周一，上面又叠了个新的 P0；周一下午直接变成 P0000，然后你发现自己周日晚上还在担心那个最早的 P0 简直好笑。你得承认你能做的事是有限的，你得保证睡眠才能第二天做出好决策，同时要非常残酷地排优先级：最需要搞定的是什么，然后对其他东西放手。我们出的某些产品打磨得没有我希望的那么到位。但我们的首要目标是帮助专业开发者更强大，只要这个产品失败不挡在核心用例前面，就 OK，我们会听到反馈，下个版本改。一个功能有 bug 就上线，以前会让我睡不着，现在我能和它共处，知道我们会很快拿到反馈、下一版修掉它。
Lenny：我脑子里浮现的是《加勒比海盗》里那个画面吧，一个人从船上的楼梯走下来，整艘船围着他在崩塌，他却非常淡定，悠悠地走下楼。这个反差很有意思，我接触过的所有 Anthropic 的人都很松弛、很乐观。
Cat：对，我觉得这里面有一个挺有意思的洞察，就是保持一种平静的乐观，而不是”我天全崩了”。如果你没有这种心态，很快就会烧掉。我们也倾向于招那些在行业里摸爬滚打过一段时间、经历过起伏、清楚什么给自己带来能量、清楚怎么长期维持能量的人，这对我们帮助很大。
Lenny：很有意思。我想问，角色都在融合，工程师变 PM，大家都你中有我我中有你，这样的世界里我们失去了什么？职业阶梯、清晰的职业路径是不是没了？设计一致性、代码质量会不会打折？总有一些代价吧。你觉得我们为了整体更好牺牲了什么？
Cat：我们在牺牲产品一致性。过去写代码昂贵，你会非常谨慎地规划整个产品矩阵：每个产品之间怎么关联、每个产品对应什么 use case、怎么集成，基本上一个 use case 就一个产品。而现在 AI 这么快，要测的点子太多，我们确实有时会出现功能之间相互重叠的情况。很多时候是因为有两种 form factor 我们内部都很喜欢，希望让外部用户来告诉我们哪一种更好。对新用户而言，代价就是”我不知道要做 X 应该走哪条路最好”，我们得做更多教育，帮用户理解核心功能是什么、最佳实践是什么。这是功能密集上线的代价。用户也会觉得跟不上最新进度。传统 PM 节奏里，每月或每季度发一次功能，用户很容易知道”我每个月看一下就够了，忽略半年也没关系，我不会错过什么”。而现在这些 agentic 工具，不只是 Claude Code 和 Co-work，而是整个生态，大家都觉得要天天刷 Twitter 才知道最新是什么。我们可以做更多事，让大家不觉得自己被扔上一台越转越快的跑步机。我希望用户的体感是：打开这些工具，工具本身会教你、告诉你它想让你知道什么，你会有一种被它带着走的感觉。
Lenny：对，你前两天上线的那个 /powerup 我觉得挺有意思，它基本上把 Claude Code 的各种玩法和最佳实践串着介绍了一遍。这是沿着这个思路吗？
Cat：对，正是。以前我们其实不太愿意做 /powerup 这样的东西，因为我们觉得产品应该直觉到你不需要任何教程。时间久了我们意识到，现在功能太多了，对一个内嵌的 onboarding 体验需求非常大。我们从”坚决不加 onboarding 流程”的原则稍微让步了一下，加上了 /powerup，因为太多用户想知道”一共 100 个功能，哪 10 个是我必须会用的”，我们就把它做出来了。
Lenny：是啊，这真是一个很怪的世界。Anthropic 在 B2B 企业市场非常成功，而企业市场传统上不喜欢每天上新，最多一个季度一次。和”天天有新东西”几乎是反着的。顺着这个话题，Anthropic 这条增长曲线几乎是反常识的。开头你们非常落后，是融资最少的那一批公司之一，没有渠道，不是先发的，OpenAI 领先太多，很多人觉得 Anthropic 长期没有任何追上的可能。现在呢，你们在把那些体量大得多的公司打得服服帖帖，节目上线时可能 ARR 已经超过月度 11 billion、增速极快。作为内部人，你觉得让 Anthropic 能做到这样反超的几个配料是什么？
Cat：最重要的两件事，第一是统一的使命，这件事重要到无法强调。我们招的人最在意的事，是让安全的 AGI 惠及全人类。我们在决定整个产品要做什么的时候，会非常频繁地回到这个使命上。因为我们把使命放在任何单独的产品线之上，整个组织就能非常快地做跨部门决策，而且大家会以统一的方式去执行。我在我们这个规模的公司里，没见过别的能这样运转的例子。
Lenny：为了说清楚：你们的首要使命是 safety alignment，让 AI 对世界是好的，你在说只要有这样清晰的使命，很多决策就简单得多。
Cat：如果有两个优先级在打架，我们会讨论哪个对 Anthropic 的使命更重要，就会容易得多地决定优先推哪个，所有人都会站在那个决定后面。有时候意味着”我们本来想在 Claude Code 上线一个功能，但另外那件事更重要，所以我们把这个功能先放一放，等以后再做”。
Lenny：这一点很有意思，它能解释为什么另一家某个名字和”bopen bi”押韵的公司会同时做很多不同的东西。你这边听下来的感觉是，我们不会去做一个社交网络，不会去做一个有趣信息的 feed，因为它们和这个使命不对齐，所以 Anthropic 保持了专注，而专注是你们成功的一个核心配料。
Cat：我说使命的时候，其实是说把 Anthropic 的整体目标放在任何个体或任何单独产品之上。我觉得第二个我们做得特别好的事，是聚焦。使命对我的意义略微不一样——使命意味着团队愿意做对自身目标和 KR 有损害但对 Anthropic 整体目标和 KR 有利的取舍，而且大家真心乐意做这种取舍。一个极端的例子：如果 Claude Code 失败了，但 Anthropic 成功了，我会非常开心；我们整个团队也都愿意沿着这条思路做决策。
Lenny：不知道你能不能深入讲，open Claude 那个决定是不是这个逻辑的一个体现——这件事没有推动 Anthropic 的使命，所以我们要停下它？
Cat：对 Anthropic 来说，最重要的事之一是扩大我们能服务的用户规模。通过 Claude 订阅和我们的一方产品，我们能把用户规模做大，我们非常希望 double down 在这件事上，有时候代价就是对第三方产品不那么友好了。
Lenny：我们一直在聊 Claude、Co-work 这些东西。我想让大家能分清楚你们的产品：Claude Code、Claude Desktop、Co-work。什么时候用哪一个？你自己是怎么用这三个的？
Cat：我在终端里用 Claude Code，一般是那种”我就想扔一个一次性的 coding task”、并且想要最新功能的时候。CLI 是我们最初的产品形态，功能通常也最先在 CLI 上线，所以它是这几个工具里能力最强的那个。我一个人扔一个或少量几个任务的时候会用它。Desktop 在你需要做前端工作的时候特别好用。我很喜欢用它的 preview 功能：做 web app 的时候我经常同时用 Claude Code 和 Desktop，右边开一个 preview 面板，这样我和 Claude 聊的时候能实时看到正在构建的 web 应用。对喜欢图形化界面的人，Desktop 也很合适。终端对很多非技术用户来说陌生，屏幕上弹出的各种吓人弹窗、没法像用其他软件一样点来点去，会让人很不舒服。如果你是这种用户，我强烈推荐试试 Desktop 里的 Claude Code。Desktop 还适合”一眼看全局”：你能看到 CLI 里的 terminal session，看到其他 Desktop session，看到你从 web 或手机上发起的 session，是一个一站式的控制面板。Web 和 mobile 的价值是让你在外面的时候也能发起任务。CLI 和 Desktop 都要求你守着笔记本，有时候你在外面 touching grass，在散步，没开笔记本。我见过数不清的人在外面抱着开着盖子的笔记本、连着手机热点走路——这意味着我们缺一个产品解决这个需求。Mobile 就是让你在路上把任务发起来，你不用到哪儿都带着笔记本。
Lenny：我太喜欢这个了。我看过好多人在飞机上那种画面，现在都成梗了：“我得让这个 agent 跑完，我不能关机，我得要 Wi-Fi”。
Cat：对 Co-work 来说，它补的那块是：大家每天做的工作里有很多产出并不是代码。比如把 Slack 清到 0、把收件箱清到 0、为一个马上要开的客户会议做一份 slide、写一份关于某个功能目标或发布计划的 quick doc。这些任务的产出都是非代码的东西，Co-work 是最适合这些的。我在自己脑子里是这样切的：如果我做的东西产出是代码，我会用 Claude Code、Desktop 或者 mobile 上的 Claude Code；如果产出是任何非代码的东西，我会用 Co-work。
Lenny：很多人在睡过 Co-work 的成功。它其实在以非常快的速度增长，但我觉得大家还没完全理解它是做什么的。能不能以你自己 PM 的日常为例，讲几个很具体的、可能有点意外的用法，让大家看到它是怎么帮你省时间、让你多干活的？
Cat：如果你刚开始用 Co-work，真正该做的第一件事是把所有对你角色相关的数据源接上。Co-work 只有在能够访问所有必要上下文时，才能真正帮你产出合适的结果。对我来说就是把 Google Calendar、Slack、Gmail、Google Drive 都连上，这样它有足够的灵活性去找上下文、问问题、把线索串起来，结果质量会大幅提升。我用它做的事情是这种感觉：昨天晚上我们有一个 Code with Claude 的会议要来，我要在上面做几个分享。其中一场要讲 Claude Code 从一个助手进化成一个完整 agent 的这段路径。我在这个分享里想展示我们上线的、支撑这条路径的一系列产品，还想找出团队内部有哪些成功故事可以拿来做 demo。我连着 Google Drive 和 Slack，我们的 PMM Alex 写了一版草稿、列出他觉得应该覆盖的要点，我把这些一股脑交给了 Co-work。我告诉 Co-work 我想讲的叙事是什么，它就干了差不多一个小时：它翻了 Twitter 看我们发过什么，翻了 evergreen launch room，翻了 Cloud Code Announce 频道——那是团队内部贴 demo、分享自己怎么从 Claude Code 中拿到最多价值的地方。它把这些全部综合起来，拼成了一份 20 页的 slide，我早上醒来读了一遍，挺不错。我做了一轮反馈，因为我希望 slide 上文字极少，它还是略显啰嗦了。但它的产出比我自己能做出来的快得多。而且因为 Co-work 能访问我们整个 design system，这份 slide 看起来就像一个 Anthropic designer 做的——视觉上极其精致。像这种事省了我很多小时，原本做这份 deck 我要花几个钟头，它交出来的稿子已经相当好了，我可以把精力放在确认 demo 够不够惊艳上。
Lenny：对 PM 来说这简直是梦成真，做 deck 太烦了。
Cat：太慢了。
Lenny：而且有意思的是，这份 deck 你之后演讲时大家会看到，它会公开出去。它显然不是一次性生成的版本，你已经迭代过。为了让大家自己也能试试，第一步是连接数据源，除了 Slack，你还建议连什么？
Cat：Slack、Google Calendar、Gmail、Google Drive。把你的沟通工具连上，把你团队关心什么、你关心什么、你在忙什么的 source of truth 连上。
Lenny：OK，你给它的 prompt 大概长什么样？
Cat：我就写：“给我做一份 Code with Claude 会议的 slide deck。我们的 PMM 建议覆盖这些内容。这是我自己做的当前版本，我不喜欢。这是我手写的一版，我也不喜欢，但我都把链接贴给你了。先帮我出一个带细节的提纲，注意别和主题演讲重叠太多，那个更重要。” 然后 Claude 就读了我发过去的一堆链接，写了一版提议的提纲。我再把它列出的所有方向读一遍，选出我最终想要的那几个放进 slide。这其实就是今天 PM 这个角色还在做什么的一个例子：Claude 是很棒的 brainstorming 搭档，能非常快地综合海量信息、把可能性摆到你面前；但 PM 的角色仍然是最终拍板，决定什么进入最终产物。对这件事我最终决定，talk 要讲从”让单个 task 成功”到”让每个 PR 都绿”，再到”帮工程师合入更多 PR”这条进阶路径，并为每一阶段挑出最有说服力的 demo。定完提纲以后 Co-work 就自己跑了几个小时，把整份 slide 建出来了。
Lenny：太棒了，工作里不用再亲手做这件事简直是一种解脱。这感觉就像在和一个既懂设计系统、又真的了解你工作内容的 deck designer 说话，它能实打实地把内容做对，而不是只把视觉做漂亮。你们是怎么把 design system 这一块接进去的？它怎么知道 Anthropic 的设计系统？
Cat：我做的就是我们对外场合用的那份标准化 deck 模板，我把它给 Claude 用。它能看到我们用什么颜色、什么字体，有哪些可能的 slide 布局，大概 20 个示例 slide。
Lenny：明白了，你就相当于上传一个模板：照着这个风格来。
Cat：对。你也可以把 Figma MCP 连上，如果你的 slide 模板存在 Figma 里的话，它能拉过来用。
Lenny：说到这个，我一直挺好奇你的 PM 工具栈长什么样。Anthropic 自己的工具肯定是 Claude Code 和 Co-work，还有什么？你刚刚提到 Slack。
Cat：我的栈很重度地压在 Claude Code 和 Co-work 上。Anthropic 基本是靠 Slack 跑的，我觉得它就是我们公司的核心 OS。日常来说，我大概 30% 的时间是在测试 Co-work 的边界，好让自己对”我们现在哪里做得不好”有很强的感觉。我花很多时间和模型聊，去理解它为什么会犯它犯的那些错。我们内部也做了很多自己的工具。Claude Code 给整个公司释放出来的一个很大价值是：做任何一个 custom app 的门槛被打到很低。所以我们能看到一波”个性化工作软件”的爆发，大家为了特定的用例在自己造工具，而不是迁就那些并不合身的现成工具。
Lenny：讲几个例子？有哪些你做的、别人做的、又好用又流行的？
Cat：Claude Code 这边有一位做销售的同事，他意识到自己一直在反复做非常相似的 deck。于是他做了一个 web app，把我们知道效果好的那几套 Claude Code 核心 deck（像 101、201、Mastering Claude Code）放进去，然后有个地方输入某位客户的具体上下文，这个上下文会从 Salesforce 拉、从 Gong 拉、从其他笔记里拉，然后为这个客户定制 deck。它会拉出诸如”这个客户用的是 Bedrock 还是 Claude for Enterprise 还是 Console”，这会影响哪些功能对他们可用；也会拉出”这个客户最关心 SDLC 里的 code review 阶段”，于是加一张关于我们 code review 能力的 slide；或者”这个客户需要 HIPAA 合规”或需要某些安全控制，就会再加一两张；如果客户用的是 Vertex 或 Bedrock、不打算用 Claude for Enterprise，就把 Claude for Enterprise 专属那些 slide 拿掉。平常这种手工活儿要花 20、30 分钟，要么你就花这个时间做，要么你就放弃、直接用通用 deck。有了这个，几秒钟就能生成一份量身定做的 deck。
Lenny：有意思的是，Slack 是那种”没人在尝试重新发明的工具”。Slack 一直在赢，用你的话说，它是很多公司的 OS。大家都在说 Salesforce 不过如此、SaaS 也就那样、我们要自己造，可是 Slack 是一个没人愿意挑战、没人想做一个更好版本的耐用工具。
Cat：我觉得 Slack 是非常重要的沟通基础设施，他们把”让所有人实时同步”这件核心事做得极好。
Lenny：对，大家嘴上骂 Slack，但它真的很擅长它要做的事，最前沿的团队都离不开它。
Cat：对。而且我也很喜欢他们把 Slack 做得这么容易定制。我们很喜欢写 Slack bot，这种可 hack 性让我们能按自己想要的方式集成，真的很感谢 Slack 在这件事上的投入。
Lenny：看来要去买点 CRM 的股票了。非常开心向大家介绍本季度的支持赞助商 Vanta。Vanta 帮助超过 15,000 家公司——像 Cursor、Ramp、Duolingo、Snowflake、Atlassian——赢得并证明客户对他们的信任。得益于 AI，团队前所未有地快速构建和出货产品，但与此同时，引入产品和业务的风险量也前所未有。我接触的每一位安全负责人都在感受到越来越重的压力，既要保护组织、业务，更要保护客户数据。因为节奏太快，他们一直在被动应对、猜测优先级、用过时的工具凑合。Vanta 把合规和风险管理自动化，覆盖 35 个以上的安全和隐私框架，包括 SOC 2、ISO 27001、HIPAA，让公司更快合规、并比以往更能持续合规。信任能成就你的业务，也能摧毁它。去 vanta.com/lenny 了解更多，作为这个播客的听众可以减 1000 美元，记得是 vanta.com/lenny。
Lenny：OK，你说过很多团队都在用 Claude Code 和 Co-work 来跑工作。除了工程以外，你觉得哪个团队用得最凶？工程应该是 token 花得最多的，但如果不是会很有趣。现在排第二的职能是谁？
Cat：Applied AI 团队在突破 Claude Code 和 Co-work 边界这件事上特别厉害。我们 Applied AI 的很多人花大量时间和客户一起，帮他们采用我们的 API。所以他们有时候会替客户做原型，Claude Code 让这件事比以前快很多。他们同时还要处理大量客户沟通、inbound、历史上下文、通话记录。他们在 Co-work 和 Claude Code 上都用得非常重。
Lenny：帮大家理解下 Applied AI，它是那种 forward-deployed engineering 的角色吗？你一般怎么描述 Applied AI 团队在做什么？
Cat：它是在帮客户在他们整个公司里采用我们最新的 API 和模型能力，同时服务于客户自己的产品，也服务于他们的内部提效。
Lenny：明白了，有点像 customer success × go-to-market × forward-deployed engineer 的结合。
Cat：对，就是非常懂技术的 go-to-market 人员。
Lenny：OK，所以你说他们可能是 token 消耗第二的团队。
Cat：对，而且我们也看到他们在把 Co-work 能做的事推得更远。比如一个 Applied AI 的人可能同时覆盖很多客户，忙的一天可能有 5 到 10 个客户约会。他们常用的一个 Co-work 用法是：前一晚让它总结一下第二天的所有客户会议——这些客户都问过我什么、他们现在最在意什么、过往会议里的 action items 有哪些，Co-work 会生成一份 dossier、一份 brief，告诉他们进下一个会议该提前知道什么。Co-work 还能帮忙查答案：如果一个客户问”某个功能什么时候上线”，Co-work 能在 Slack 里找最新 ETA、加到笔记里，客户开会时他就有最新信息。这些其实都是大家为自己构建、然后分享给团队其他同事的 workflow。
Lenny：这个超酷。还有一个最近常被讨论的话题：每人的 token 花费超过工资。Anthropic 这边有没有什么数字在流传，比如工程师一个月、一天的 token 支出，或者 PM 的？
Cat：我们能非常清楚地看到，随着模型变好，大家会把更多任务委托给它，在 Claude Code 和 Co-work 这类工具上投入的时间大幅上升。每当有一次模型跃迁或一次大的产品改进，每位工程师或每位知识工作者的 token 成本都会上升。这个数字仍然远低于一个普通工程师的薪资，但它占比在随时间增长。
Lenny：这件事挺有意思。你们在 Anthropic 的另一个优势是能用最前沿的模型，我听说你们基本上 token 无限制，可以随便用，对吗？
Cat：我们可以用很多 token。有些人确实会碰到上限。
Lenny：所以还是有上限的，OK，Boris 听见没。真有意思，有最强模型带来的优势是连锁的、会形成飞轮。
Cat：我们也很相信要充分赋能内部团队尽可能快地构建，同时信任大家理解提供这些模型服务真正的资源成本。我们信任每个人会负责任地使用这些 token，浪费 token 这件事在我们内部是被非常不鼓励的，但我们尊重每个人的判断。
Lenny：回到 PM 角色，你前面已经聊到一些了，但我觉得大家还会想听：现在 AI 公司招 PM 时最看重的、正在崛起的技能是什么？
Cat：最难的能力是能定义”一个月后产品应该长什么样”。模型在那个时间尺度上能做什么、用户行为会怎么变，本身就高度模糊。最好的 PM 能从用户是如何”滥用”现有产品边界的信号里看出模式，据此给出方向、稳定地朝那个方向推进，并在模型能力超过或低于预期的时候及时调整路径。真正难的是把”AGI pill”的剂量拿捏得刚刚好。大家都能预见一个模型极其聪明、几乎无所不能的未来，那个时候你根本不需要复杂的产品，一个文本框就够了——用户说想要什么，模型自己把工具、集成都接好，搞不清楚的时候主动问你。为一个 super AGI 模型做产品其实很容易，真正难的是针对当下这个模型，把它的最大能力激发出来：怎么引导用户进入黄金路径，怎么让用户和模型的强项打交道、帮它补短板。这种能力比较稀缺。
Lenny：这种能力怎么练？是不是就是花时间用每个模型，像你说的建立 taste，理解这个模型擅长什么、不擅长什么、哪些地方变了？
Cat：很大一块就是花大量时间和模型对话、使用模型。我特别喜欢的一个做法是让模型自己内省它刚才的行为。有时候我发现模型做了出乎意料的事，比如它改了前端还跑了测试，但没有用 UI 验证，我会让它反思自己为什么这么做。它有时会说”system prompt 里有一段让我困惑”，或者”我以为 verification 不是这次任务的一部分”，或者”我把 verification 委托给了 subagent，subagent 没做 test 我也没检查它的工作”。很多时候只要你对模型的决策足够好奇，就能看到是什么把它带偏的，你就能修 harness、补上这个缝。第二件事是找到那些你最信任的、对模型给反馈最准的用户。通常真正擅长把”这个模型或这套 model + harness 组合好在哪”讲清楚的人只有那么几个，很多人愿意给反馈，但不是每个人的反馈都同样有分量。找到你信任的那 5 个人，对拿到非常快的反馈非常重要。第三件有用但不是每个人都爱做的事，是建 evals。你不需要做几百个 evals 才有用，做 10 个好的 evals 就能帮团队量化目标、量化进展、看到自己缺什么。我觉得 evals 被低估了，更多 PM 和工程师都该去做。
Lenny：evals 我们聊过好多次。有一种趋势是”写 evals 就是产品管理的未来”，因为它本质上在回答”成功长什么样？好，让我把它具体定义出来，这样我们就能知道”。你自己花多少时间写 evals？
Cat：evals 的重要性要看你在做的功能、你要解的问题。我们团队有一个专门的小组花很多时间做 evals，和 research 紧密合作，精细地理解 Claude Code 的行为、找出最大的改进空间、对这些做可测的度量。我个人是在某个功能需要更多产品定义时会跳进来做 evals，通常产出是”这里是我写的 5 个 eval、跑法是这样的、这几个通过、这几个没通过、我用的 prompt 是这个、它把成功率提高到了多少”。不同功能差异很大，不是每个功能都需要，但像 memory 这种功能从 evals 里受益很多。
Lenny：你刚才讲”有些人对模型评估特别在行”，有点像人肉 eval，他们清楚模型在哪里冒尖、在哪里乏力。有谁是你想点名说特别擅长这件事的？
Cat：有两个人我觉得极其厉害。一个是 Amanda，她塑造 Claude 的 character。这是一个极难的角色，因为任务本身非常模糊。写代码还算容易，因为你能验证成功；塑造 character 需要极强的信念，即”Claude 应该是谁”。她不仅能把这个 character 塑造出来，还能非常清楚地 articulate 目标是什么、这个 character 的成功长什么样、失败长什么样。另一群我很信任的人是 Claude Code 团队。我们经常有团队午餐，每当在测试新模型，最快拿到反馈的方式就是在午餐上一个个问：“你对这个模型的 vibe 是什么？”经常能听到”这个模型在解释思考时不够完整，太仓促”、“这个模型很爱记 memory，但我们不确定这些 memory 质量高不高”、“这个模型喜欢给自己跑测试，很好”、或者”这个模型不太自己做 test”。这些就能启发我们去看哪些数据来验证这是不是普遍模式。我们数据非常多，但从数据里抽出洞察很难，这种反馈能告诉我们要测哪个假设、再从数据里去验证。
Lenny：你说的这点——Claude 的 character，让我想到 Ben Mann 上播客时讲过的话。Claude 的 character、它的 constitution，是 Claude 的核心一部分。我事后才意识到，很多人——包括 open Claude 用户——之所以难过，是因为他们觉得”Claude 的个性”是它独有的、很多其他模型没有的东西。Ben 的说法是：正是这种个性让 Claude 在这么多事上都好用。这件事表面上好像很附带，“它会讲笑话、说话有趣”，但它真的是 Claude 成功的内核。你想补一点吗？大家可能还没意识到 character 和个性为什么这么关键？
Cat：回想你合作过的所有人，总有一些人你的感觉是”我真的喜欢他的能量、他的 vibe”。大家讲 Claude 和 Claude Code 时最常提到的就是它很轻松、很有趣，同时在任务上又非常能干。大家喜欢 Claude 很 low ego：你说”你做错了这件事”，它会真的道歉：“啊糟糕，感谢你告诉我，我来修，我们一起搞。”它也很正向——你如果觉得”这事我搞不定，不知道从哪开始”，它会告诉你”没事，我想我们可以这样走几步，要我帮你开始吗？“我觉得一个好的 co-worker 的核心是这种正向、偏向行动、愿意真诚给反馈而不是什么都顺着你说的能力。我们试图把这些植入到 Claude 里，因为这让和它一起工作愉快得多。
Lenny：我想回到你前面说过的一点：新模型出来时，你们常常要回头重新审视已经做好的东西。这个既有意思又有点让人头疼：“完了，我们上线的这个东西现在得重做了。”你们大概多频繁会因为新模型、需要重新做几个月前上线过的产品？
Cat：大多数时候不是重做，而是把已经不再需要的功能去掉。很多功能之前是加进来当模型的拐杖，因为它不会自然地去做某件事。经典例子是 to-do list：早期 Claude Code 上线时，用户会让它做大型重构，Claude Code 会说”好，我要改这 20 个调用点”，然后改了 5 个就停了。我们当时想：“怎么强制它记得 20 个都得搞定？”团队里的 Sid 说：“不如想想人会怎么做——人会列一个要改的清单，就像在 VS Code 里查所有调用点，在左边展开成一个列表，然后一条条替换过去。我们把这种工具给 Claude。”他加了一个 to-do list，结果 Claude 真的能搞定那 20 个。但是到了 Opus 4 以及之后的模型，我们发现已经不需要强制它用这个 to-do list 了，它会自然地自己用。早期模型我们得一直提醒它”你 to-do list 上的事做完了吗？你要把它们都做完才算结束”，后期模型不用提示它就会自己这样去思考。现在的 to-do list 对用户来说仍然是个好东西，因为你能更清楚地看到 Claude 在忙什么，但它在产品里的权重已经非常低，模型可能用也可能不用，对它做彻底的修改来说已经不再是必要的了。
Lenny：这期节目里我忘了是谁说的：“模型会把你的 harness 当早饭吃掉。” 我听你讲的其实就是：随着时间推移，你们会把当初为了弥补模型短板加在模型之上的东西一点点移除。模型越聪明，产品就越简单，直接让它做你想让它做的事就行。
Cat：对，每次模型变聪明一点，我们就能去掉一大堆 prompt 干预。每次上线一个新模型，我们都会重新读一遍整个 system prompt，每一段都反思一下”这条提醒模型还真的需要吗？“如果不需要就删掉。但新模型最让人兴奋的不是”删东西”，而是解锁全新的功能。有很多功能我们在更早的模型上试过，但准确率不够，所以没上线。比如 code review 我们尝试过好几次，过去上线过比较简单的版本，比如 /code-review 命令。只有到了最近的模型，我们才觉得这个 code review 好到工程团队会在 merge PR 之前依赖它通过。我们一直梦想 Claude 能做一个我们有信心的 code reviewer，真的能抓住大部分 bug，这件事直到 Opus 4.5、4.6 和 Sonnet 4.6 才让我们觉得”好了，我们可以同时跑多个 code review agent 去 traverse 整个代码库、把 engineer 合入前需要处理的一组真问题综合起来”。这就是新模型才解锁的新能力。
Lenny：这其实又是这个播客里非常常见的一种模式：“去做那些未来 6 个月可能才做得成的事。”先站在可行的边缘，然后当模型补上那个 gap，你就有了一个很棒的产品，还领先所有人。
Cat：对，做一些现在还不太 work 的产品非常重要，因为你会知道”为什么这个产品现在还没 work”，等新模型来了你就能直接把它换进原型里，看看新模型是不是把那个 gap 补上了。
Lenny：你能聊多少 Claude Code 和 Co-work 的长远方向？我相信你不会泄露太多，但这些 dispatch 控制、手机里启动任务、mobile app 之类的新功能让人很期待。怎么理解它长期的产品愿景？
Cat：我们把这件事拆成一块块积木。对 Claude Code 和 Co-work 来说，最基础那块积木是”让单个任务成功”——你要一个产出，给它一个清晰的 prompt，它能不能稳定地产出你可以 merge 或者发给同事、发给外部的东西。任务是基本单元。模型越聪明，任务成功率越高。然后我们看到用户开始同时做多个任务。Multi-claude 在 2025 年底成了一件大事，此后只在加速。我们把它看成”一个任务能 work，那接下来可以同时跑 6 个”。再聪明一些，我们的外推是”下一步是同时跑 50 个 Claude，或者上百个”。我们要建什么样的基础设施来支撑这一切？到那时候，你肯定不会再把这些都跑在本地机器上了，光 RAM 就不够。我们在思考怎么让你更容易地管理这么多任务，它们很可能会跑在远端。我们要怎么设计界面，让你这个”人”知道自己要回头看哪些任务？怎么让 agent 充分验证自己的产出，让你看到一个任务标记为完成时，能很快地验证并真正相信它按你的规格做完了？这个过程怎么做到自我改进？当你看到一个不符合自己偏好的结果，你给它一条反馈，以后每次它都会把这个反馈考虑进去、再也不犯这个错。这是我们要把用户一起带过去的路径。
Lenny：听众里有很多 product manager、有些可能是创始人、还有很多跨职能的人。大家都在担心职业的走向。你想给大家什么建议，让他们不只是”活下来”，而是能在这个越来越 AI 驱动的世界里真正胜出？
Cat：AI 给每个人带来了过去无法企及的杠杆。所以我会推你做一件事：一旦你发现自己在手工做一件重复的事，就去想怎么用 Claude Code、Co-work 或者其他 AI 工具把它自动化。每个人都有自己职业里创造性的、你爱的部分，也有繁琐的、你讨厌的部分。AI 的美妙之处在于它可以帮你做那些繁琐的部分，它可以从你每次做这件事里学习、泛化、然后自动跑起来，这样你就能把精力放在创造性的部分，做的事也会比以前多得多。所以我的直接建议是：找出那些可重复的工作、交给 Claude，迭代这些自动化直到成功率非常高，然后把注意力放在”我还能为团队、为产品、为公司多做些什么，那些以前因为带宽不足没人做的事，或者我一直觉得公司应该做、但从没腾出手的 pet project”。如果 AI 能接住那些累活，你就多出 20% 的时间。我推你的是：拥抱这些工具，把你不想做的活交出去，找到它能在哪里加速你，结果你能做的事会多得多。
Lenny：这和我完全同意的一点是：找值得用 AI 去解的问题。这些工具潜力巨大，但对很多人来说最难的正是”我到底该做什么”。你说的其实就是：留意自己反复在做的事，留意那些一直悬在脑子里、你没时间做的想法。本质上就是”先解决你自己的一个问题”。
Cat：对。我还想推听众一件事：把自动化从”这是个不错的概念”推到”这真的 100% 都 work”。我经常看到用户把一个东西自动化到 90%、95% 的准确率，就放弃了。可一个 95% 才 work 的自动化其实不是自动化。最后那 5% 到 10% 确实要花更多时间，而且搭自动化往往比你自己手做还慢。但我想鼓励大家投入那个时间，选一件你真的希望自动化的事，把它推到 100%。多花点力气教 Claude 你的偏好、给它反馈，让它把技能练到那 100%，你才能真正依赖它。95% 的自动化价值有限。
Lenny：我对这个完全有罪，这对我是一个特别好的 push。
Cat：我也一样。我一直在教 Co-work 帮我把 Gmail 整理到 inbox zero，过程非常耗时，到现在也还没到。
Lenny：好笑的是我的思路正好也是 Gmail。我搭了一个 workflow：每封邮件都过一遍，看它是不是 spammy，比如”能来上你的播客吗”、“这个事怎么样”之类的我没时间处理的事，我就把它们分到一个叫 spammy 的文件夹。95% 还不错，但偶尔会：“哎呀，我漏了一封，它被归到那儿去了。” 所以你这段正好在推我——我要把它做到真正可依赖。
Cat：我们也在做一件事：把自定义这些 command 的流程做得更顺。现在你要知道太多概念：要会定义 skill，要会使用并反馈 skill，要告诉 Co-work 根据反馈去更新 skill，还要知道去哪里查看 skill 内容、确认反馈被按你想要的方式吸收了。让这个流程不痛苦，也是我们的工作。
Lenny：很棒。Cat，还有什么想留给听众的吗？我们接下来要进非常激动人心的 lightning round，在那之前你想强调什么？
Cat：我看到很多人在玩 AI、做原型、折腾 workflow，我会很强烈地推大家去做你每天真的会用的 app，因为只有在真实使用中你才真正拿到价值。如果你做了一个原型 app，但它没让你多完成什么事，那 AI 其实没给你的日子真正创造价值。而你从”一次性 shot 出来一个东西，酷，然后再也不碰它”里能学到的东西也有限。
Lenny：并且你没拿到真正的 leverage。
Cat：对。我还想说，有不少人花很多时间去个性化自己的 workflow。我觉得人们会分布在两端：一端是从不 customize、从不搭自动化；另一端是沉迷于 customize 他们的工具——加一堆 skill、MCP、各种 workflow 改造——有时候反而会分散他们对”我原本的目标是上线某个产品或做某个功能”的注意力。customize 是很有趣的事，我们也希望产品足够 hackable，让你能把它调成特别适合自己的样子。但 customize 有它的边际收益上限。有一群人 customize 到不睡觉、反而不做当初想做的核心任务了。
Lenny：Twitter 上这种人我看了好多：“看我这套 setup，夸张得不行，极度优化。” 那你实际在做什么？“不不，我的 setup 超棒，完成了很多事。”
Cat：简单的 setup 其实往往更管用。
Lenny：Slash powerup 让大家稍微 level up 就好。
Cat：对对。
Lenny：Karpathy 昨天发了一条推，讲一个很有意思的分裂：当年试过 ChatGPT、Claude 的一部分人觉得”还好吧、不行”，对 AI 能做什么没抱希望，非常 cynical；而另一部分人用它写代码，看到了它全部强大的能力，知道它真的有多好。两边都不理解对方，不理解对方为什么会这样看世界。你的建议其实也是：去真的用它做真的事，亲眼看看它到底进步到什么程度了。
Cat：对。真正的大转变是：2024 那一代产品是 chat-based，Claude Code 这一代产品是 action-based。大家真正 aha 的时刻就是当 Claude 真的能替你做事。知道一个 agent 能做的远比”告诉你该怎么做”多，是非常震撼的体感。当 agent 真的直接自己去做，这才是让人眼睛一亮的瞬间。
Lenny：给 Claude 的 Chrome 扩展打个 call out——你可以看着它帮你填完一张表，“帮我填这个表”，它说”好，开始啦”。
Cat：完全正确。
Lenny：OK，进 lightning round 前还有什么要说的吗？
Cat：没了，来吧。
Lenny：来吧，Cat，我有 5 个问题，欢迎来到 lightning round。这里有个动画效果，我得念一下。准备好了吗？
Cat：准备好了。
Lenny：第一个问题：你最常推荐给别人的两三本书是什么？
Cat：我很喜欢《How Asia Works》，讲的是经济发展，以及什么样的政策和政府能打造长期成功的经济体。我也很入迷《The Technology Trap》，讲过去几次技术革命——工业革命、计算机革命——是如何影响工人的。我很喜欢它，是因为我觉得我们可以从历史里学到很多，以保证这一次技术转型不出大问题。再加一个轻松点的，我挺喜欢《The Paper Menagerie》，是一本短篇小说集，关于成长、AI、自我发现。
Lenny：最近最喜欢的电影或电视剧？
Cat：我很喜欢《Drive to Survive》，没有什么更深的原因，就是看到一群人这么痴迷地追求一个工程目标，那种纯粹让我非常满足。我也很喜欢《Free Solo》，就是 Alex Honnold 徒手攀登 El Capitan 那部。同样地，能爬完这样一条极其困难、极其危险的路线，并且有足够的专注——知道只要一个失误就会丧命——本身就是一种非常纯粹的成就。
Lenny：疯狂。那部电影看完脑袋都炸了。很有意思的是这些作品和你自己的工作在某种意义上也有呼应。
Cat：我自己就是个 rock climber。我是在开始攀岩之前看的《Free Solo》，当时觉得”很厉害”；但你越懂就越觉得惊人，这是少有的那种”你越懂内情，越觉得不可思议”的片子。他在岩壁上做的那些动作，哪怕是放在攀岩馆里、离地一尺、挂着绳子，我这辈子估计都做不出来。
Lenny：挂着绳子都做不出来，你看过另一个年轻一点的人去冰山那部纪录片吗？
Cat：看过，那个挺让人难过的。
Lenny：但也太猛了。下一个问题：你最近发现的、非常喜欢的产品？
Cat：除了 Claude 相关产品以外，最改变我生活的产品大概是 Waymo。我是忠实用户，一天两次，上下班用。我最喜欢它两件事：第一，如果 Waymo 要等我，我不会有愧疚感，所以我没有那种”必须准时站在路边”的压力。第二，它让我可以更高效地利用时间。和另一个人在车上时，我一般不会开工作电话，我觉得在车里抱着笔记本干一路有点不礼貌。但在 Waymo 里我可以放心接工作电话，不担心被谁偷听、不担心”我说话是不是太大声”、“要不要让司机把音乐调小”。我觉得它每天帮我找回了大概 30 分钟。
Lenny：技术的二阶效应就是这么有意思。
Cat：对。我以前一直觉得 Waymo 得比 Uber 和 Lyft 便宜才能成，但现在我真的愿意为它付 2 倍的溢价。
Lenny：我爱 Waymo。一旦你见过它，你就会觉得”这太疯了”。然后你就会习惯它，进去、觉得”这真的还挺不可思议”，然后就忘了它是怎么运作的。
Cat：对，它也改变了大家的用语。Anthropic 很多人爱 Waymo，以前你会说”我们叫个某某打车 app 吧”，现在大家就是”Waymo 到了吗？”
Lenny：OK，还有两个问题。你有没有一句人生格言，是你在工作或生活里会反复回到的？
Cat：Just do things（就去做）。我觉得 first principles thinking 非常有价值。如果你知道自己在为什么而优化，并且有非常坚实的 first principles，你一般能推导出正确的行动路径，能把它清楚地讲给所有 stakeholder，然后你就去做就好了。工作是 fake 的——如果你理解了约束，你能想清楚你能做什么，然后赶紧做，从错误中学，做错了道歉或改正。
Lenny：你可以直接去做，谁说的来着。
Cat：告诉大家这件事本身是一种解放。很多公司里角色定义得非常死：这是 PM 做的，这是 designer 做的，这是工程师做的；甚至团队边界也很死：“这一块代码库我们动，那一块我们不能碰。” “Just do things” 让人觉得自己有权去做这些决定，有权跨团队边界去把事情搞定。
Lenny：这是一种现在很重要的能力。有人叫它 agency、bias toward action，各种说法都指一件事：不要等授权。
Cat：我觉得这也是我人生中至少要在一家初创公司待过一段的最重要原因。我当初在 Scale 的时候整家公司只有 20 个人，那时候没有什么流程，要解决的问题却非常大。我真的很感谢 Alex 和团队当时那样赋能我和其他人：没人规定 sales 该干啥、ops 该干啥、engineer 该干啥，所有工具都在你手里，你面对的是一个非常 ambitious、hairy 的问题陈述，你可以做一切必要的事去找到好的解法。
Lenny：你几乎必须要有这种经历才能练出这种技能、敢做这种事。很多人在学校或大学里被训练成”按要求做、就会拿到好分数”，要 unlearn 这一套才能说”我就做那件需要做的事，哪怕别人觉得傻，我觉得对，我就做”。
Cat：对，就是这样。
Lenny：OK，我其实还有两个很短的问题。一是：Claude 在思考时会显示各种词，不知道叫什么，是这些——
Cat：thinking words。
Lenny：thinking words。好玩的是它们都在源代码泄露里曝光了。你有最喜欢的 thinking word 吗？
Cat：我很喜欢 “manifesting”。我最喜欢的贴纸上印的就是它。
Lenny：毫无疑问是冠军。最后一个问题，也问过 Boris。如果 AGI 在我们有生之年到来，你可能不再需要工作，你打算拿这些时间做什么？
Cat：我觉得 AGI 要在社会里扩散开要很久，所以眼下的事其实就是帮着把世界一起带过去。更不正经的回答是，真到那一天，我大概会去爬很多岩。搬到像 Fontainebleau 那种地方，和一万块巨石住在一起，爬一阵子。还有我想读的书多到没边，我的目标是一两周读一本，现在我大概是 0.5 本一周，积压很大。历史里能学的东西也太多，有好多我特别想深入理解但还差得很远的领域——物理、机器人、硬件、航空航天——这些都是我完全不懂、但又特别有意思的话题。我很期待去学，哪怕 AI 已经全知道了。
Lenny：Cat，真的太棒了。最后两个小问题：大家想关注你可以在哪里找到你？听众怎么对你最有帮助？
Cat：最好的方式是在 Twitter 上找 @Catwoo。欢迎 at 我、欢迎 DM，我会把所有 DM 都读一遍，不一定每条都回，但我一定会读。对我们最有帮助的是告诉我们 Claude Code 和 Co-work 在哪些地方对你没 work。我们非常感激大家的正面反馈，但真正让我们往前跑的是边缘情况、错误、那些能被复现的、Claude Code 或 Co-work 失败的具体任务。如果你愿意分享，我们能复现，这就是我们下一代模型和下一代 harness 能主动修好的事。
Lenny：太酷了，Twitter 上的大家在给反馈这件事上从来不害羞，继续来。
Cat：求大家 share，把你遇到的问题分享给我们。
Lenny：我也觉得你们整个团队在 Twitter 上这么活跃、会回应用户真的挺酷，听你这么讲，这些东西确实是你们真的在看、在回应的。
Cat：对，我们非常感激每个人和我们这么密切互动，给整个团队很多能量。我们有一个叫 “user love” 的频道，每当有人分享成功故事，我们会贴进去；有人分享遇到的问题，我们会放进 feedback 频道，这样整个团队都能去响应。
Lenny：知道这件事太好了，谢谢你告诉我们。Cat，非常感谢你来。
Cat：谢谢你邀请我。
Lenny：大家再见。谢谢你听到这里。如果你觉得有价值，欢迎在 Apple Podcasts、Spotify 或你常用的播客 app 订阅节目，也请考虑给个评分或留个评论，这真的能帮到其他听众找到这个播客。过往节目和更多信息都在 lennyspodcast.com，下期见。
来源：Lenny’s Podcast YouTube 原片 · 本文为 YouTube 人工字幕的完整中文翻译，仅为工作稿，未经说话人审阅