ABOUT THIS VIDEO
这一期，聊些什么？ 本期 Lenny 对话 Anthropic 旗下 Claude Code 与 Cowork 产品负责人 Cat Wu。她分享了团队如何把功能交付周期从六个月压缩到一个月甚至一天：用研究预览降低发布成本、靠每周指标复盘和团队原则让每个人自主决策、以产品品味决定该写什么代码，并建议做出当下还不完全可用的产品，等下一代模型补上差距。她还谈到让模型自我反思错误、evals 的价值、Claude 性格为何是核心竞争力，以及使命对齐如何消除大公司的内耗。背景说明：Cat Wu 于 2026 年 10 月 30 日离开 Anthropic，11 月 4 日宣布加入 OpenAI；录制本片时她仍以 Anthropic 产品负责人身份发言。本页全程中文配音由阿里云通义千问 qwen3-tts-flash 生成（Cat Wu 为 Cherry（年轻女声）、Lenny Rachitsky 为 Ryan（男声）音色），并以低音量保留原视频声音作为背景。
RECAP · 图文回顾
看完再回顾：这一期讲了什么 点击任意时间戳，可跳到对应位置播放中文配音。
一句话核心观点
AI 原生时代，PM 的核心不再是写文档、对齐长期路线图，而是定清目标、扫清发布障碍、让团队每周甚至每天上线；当写代码越来越便宜，最稀缺的能力是产品品味——决定该做什么。
分章节要点 01:33 与 Boris 的分工：愿景家 + 落地路径规划者
Boris 是 Claude Code 的技术负责人和产品愿景家，擅长定出产品 3 到 6 个月后的样子，即「对 AGI 信念拉满」的产品形态 02:16 Kat 的工作是想清楚从当下到那个愿景的路径，并负责跨职能协调：让市场、销售、财务、算力团队认同计划，确保功能就绪后发布零阻碍 02:30 两人大约 80% 心灵相通，剩下 20% 谁更在意就由谁来推动，角色界限相当模糊 03:07 04:30 AI 原生时代，PM 的工作方式彻底变了
Kat 面试过几百位 PM，发现多数人思路不对：还停在 AI 之前那种 6 到 12 个月规划周期、重协调的打法 04:30 现在功能周期从 6 个月缩到 1 个月，有时 1 周甚至 1 天，PM 应少花时间对齐跨季度路线图，多想怎样最快把东西推出去 05:27 三个抓手：设定清晰目标（核心用户是谁、解决什么问题）；用 research preview 形式发布几乎所有功能以降低承诺成本；建立工程—市场—文档的紧密发布流程，让工程师发功能像发消息一样顺 06:57 PRD 没有完全消失：特别模糊的功能写一页纸，重基础设施的大项目仍会写正式 PRD；但更重要的是每周全员数据复盘和一份写清核心用户与取舍的团队原则清单 09:12 10:29 高速交付的背后：Mythos、源码泄露与 OpenClaude
内部确实在用 Mythos，它让发布快了一点，但提速的主因是极简流程和「每个人都能在一周内把想法推上线」的团队预期 11:03 Claude Code 源码泄露是人为失误：一位同事与 Claude 协作写的发布脚本 PR 经过了两层人工审核仍出问题；当事人留任，团队视其为流程失误并已加固流程 12:15 OpenClaude 决策：Claude 订阅并非为第三方产品设计，使用模式不同；Anthropic 选择优先保障自家产品和 API，同时给订阅用户发放额度作为过渡 13:18 14:20 PM 组织：30–40 人团队与角色融合
Anthropic 约有 30 到 40 位 PM，分为研究 PM（Diane 带队，负责模型反馈与发布）、Claude 开发者平台、Claude Code + Cowork、企业版、增长几个团队 14:26 对「PM 会消失吗」的回答：角色在融合——PM 写代码、工程师做产品、设计师也提代码；Kat 团队更倾向招有产品品味的工程师，他们能端到端从看 Twitter 反馈到周末上线，几乎不需要 PM 介入 16:15 团队里几乎所有 PM 都当过工程师或写过代码，设计师也有前端工程背景；但最稀缺的仍是产品品味——GitHub 上数以万计的 issue，要靠品味判断哪些值得做 17:35 25:20 快发布的代价，与 Anthropic 后来居上的秘诀
代价是产品一致性：功能会重叠，新用户不知道最佳路径，用户感觉必须每天刷 Twitter 追新；为此团队做了内置引导功能 Power Up，帮用户从上百个功能里找到最该用的 10 个 25:42 成功秘诀之一是统一使命——把安全的 AGI 带给全人类；使命高于任何单条产品线，优先级冲突时按「哪个对使命更重要」来裁决，全员支持 29:29 秘诀之二是专注：团队愿意牺牲自己的 KR 服务 Anthropic 的目标，极端地说「Claude Code 失败但 Anthropic 成功，我会非常开心」 31:40 心态上：团队招的都是「迎向混乱」的人——P0 会变成 P00、P000，你只能睡好觉、狠心排优先级、敢放手，接受发布不那么精致的产品再靠反馈修 23:23 32:29 Claude Code、Desktop、Cowork 怎么选 + Cowork 实战
Kat 的分法：一次性编码任务用终端里的 Claude Code（功能最全最新）；前端或图形化需求用 Desktop（可开实时预览、汇总所有会话）；出门在外用网页和手机版启动任务 32:44 产出是代码就用 Claude Code 系列，产出不是代码（幻灯片、文档、清收件箱）就用 Cowork 35:04 上手 Cowork 第一步是连接与岗位相关的数据源：Slack、Google 日历、Gmail、Google Drive 36:08 实战案例：为 Code with Claude 大会准备演讲，她把 PMM 草稿、自己不满意的手工版丢给 Cowork，说明叙事主线，它翻遍 Twitter、发布频道、演示频道，跑出一版 20 页幻灯片草稿，风格符合公司设计系统（给了约 20 页模板示例，也可接 Figma MCP）；她负责拍板大纲——这正是今天 PM 的角色 37:19 41:49 自建内部工具、Applied AI 团队与 token 开销
Kat 的工具栈主要是 Claude Code、Cowork、Slack——Anthropic 基本「跑在 Slack 上」，还爱做 Slack 机器人 42:02 Claude Code 大幅降低了定制应用的门槛：一位销售自建网页应用，从 Salesforce、Gong 拉客户背景，把原本 20–30 分钟的手工定制幻灯片变成几秒钟自动生成（如按 Bedrock/Vertex/HIPAA 合规需求增删页面） 43:12 工程之外 token 用量第二大的是 Applied AI 团队：帮客户落地 API 和模型功能，忙时一天对接 5 到 10 个客户，前一晚让 Cowork 汇总次日会议简报和最新 ETA 47:04 每次模型跃升，每位工程师/知识工作者的 token 成本都会上升，但仍远低于工程师平均工资；内部 token 用量很大但有人也会撞到上限，浪费 token 不被认可 49:50 51:16 PM 的新兴技能：品味、模型内省、evals 与 Claude 的性格
最难的技能是定义「一个月后产品该长什么样」：为超级 AGI 做产品很容易（一个文本框就够），难的是针对当前模型激发出最大能力，引导用户走「黄金路径」 51:35 练法一：大量使用模型，并让模型反思自己的行为——比如它改了前端、跑了测试却没打开 UI，追问原因能发现系统提示或子代理的问题，进而修复 harness 53:36 练法二：找到约 5 个最信任的、能说清模型好坏的用户获取快速反馈；练法三：建 evals——不用几百个，10 个好 evals 就能帮团队量化目标与差距 54:31 点名两位「品味担当」：负责塑造 Claude 性格的 Amanda（角色极难，因为没有可验证的成功标准），以及整个 Claude Code 团队——新模型测试时，团队午餐上挨个问「你对这模型感觉如何」是最快的反馈渠道 57:00 Claude 的性格是成功核心：轻松有趣、不自负（被指错会说「真的很抱歉，我来修」）、积极、给真诚反馈而非一味附和 59:34 60:46 模型吃掉 harness：删功能、解锁新能力与产品愿景
新模型带来的改动常常是「删功能」：待办清单本是给早期模型的拐杖（让它记住改完 20 个调用点），从 Opus 4 起模型会自然自己用，这个功能已被边缘化 61:03 每次发新模型，团队会通读整个系统提示词，逐段删掉不再需要的提醒；更兴奋的是新模型解锁全新功能——代码审查产品试做过多次，直到 Opus 4.5/4.6、Sonnet 4.6 才强到工程团队合并 PR 前都要靠它把关 63:09 打法是「先做现在还跑不通的产品」：原型放在那里，等新模型出来直接换进去看差距是否补上 64:52 愿景按积木推演：先让单个任务成功 → 同时跑 6 个任务 → 未来同时跑 50 甚至几百个 Claude（需远程运行），配套要做的是任务管理界面、智能体自我验证、以及吸收反馈永不再犯的自我改进流程 65:32 67:49 职业建议与闪电问答
核心建议：凡是重复的手工活，想想怎么用 AI 自动化，把省下的时间投到创造性工作和一直想做的「兴趣项目」上 67:49 自动化要做到 100% 可靠才算数——很多人做到 90–95% 就放弃，但那 5–10% 才决定能否真正依赖它；Kat 自曝教 Cowork 清 Gmail 收件箱也还没成功 69:45 两个提醒：要做自己每天都在用的工具（只做原型不落地学不到东西）；别沉迷于折腾配置（一堆技能和 MCP）而偏离发布产品这个核心目标——简单的配置反而更好用 72:08 闪电问答：推荐《亚洲如何运作》《技术陷阱》《纸兽》；爱看《徒手攀岩》（本人是攀岩者）；是 Waymo 死忠、愿付两倍溢价；座右铭「Just do things」；若 AGI 到来，想搬到枫丹白露住在上万块巨石之间攀岩、每周读一两本书；联系方式是 Twitter @_katwu，最有用的是分享可复现的失败案例 75:34 关键人物 / 产品 / 数字 人物 Kat Wu（逐字稿标注为 Cat Wu） Anthropic 旗下 Claude Code 与 Cowork 的产品负责人；工程师出身，曾短暂做风投，曾在 20 人时期的 Scale 工作；Twitter 账号 @_katwu Lenny Rachitsky 播客主持人，本期采访者 Boris Claude Code 创造者、技术负责人，Kat 的搭档；他那期是本播客最受欢迎的一期 Diane 研究 PM 团队负责人，负责模型反馈收集与模型发布推进 Sarah / Alex / Tarek / Lydia 分别负责文档、产品营销（PMM）、开发者关系，在「常驻发布频道」中快速接力发布 Amanda 负责塑造 Claude 的性格，被 Kat 盛赞为品味极强的人 Sid 团队成员，提出了待办清单（to-do list）功能 Amal 此前上过播客，提出「工程师太快，反而需要更多 PM」的观点 Ben Mann Anthropic 联合创始人，谈过 Claude 性格/宪章的重要性 产品与概念 Claude Code Anthropic 的编码智能体产品，CLI 是最早、功能最先落地的界面；几乎所有功能以 research preview 形式发布 Cowork 面向「产出不是代码」的工作（幻灯片、文档、收件箱清零等），可连接 Slack、Gmail、日历、网盘等数据源 Claude Desktop / Web / Mobile 图形化界面与随时启动任务的入口；Desktop 可做实时预览并汇总所有会话，像一站式控制台 Mythos Anthropic 内部构建的强大模型，仍在预览阶段，内部在用但并非提速主因 Power Up Claude Code 的内置引导功能，带用户了解最佳实践，从上百个功能中找出必用的 10 个 Managed agents Claude 开发者平台产品：帮你构建智能体并由 Anthropic 代为托管 OpenClaude 第三方产品，因订阅并非为其设计而被 Anthropic 限制使用，订阅用户获得额度补偿 Waymo Kat 眼中最改变自己生活的非 Claude 产品，她每天通勤坐两趟、愿付两倍溢价 Work OS / Vanta 本期赞助商：Work OS 提供企业级功能 API；Vanta 做合规与风险管理自动化 视频里提到的数字 6 个月 → 1 个月 → 1 天 00:17 很多产品功能的交付周期从 6 个月缩到 1 个月，有时甚至只要 1 天 几百位 PM 04:30 Kat 一直在面试的产品经理数量，并认为多数人思路不对 80% / 20% 03:07 Kat 与 Boris 大约 80% 心灵相通，各自主导剩下 20% 更在意的事 30–40 位 14:26 Anthropic 目前的产品经理总数 110 亿美元 ARR 29:04 Lenny 引述：Anthropic 一个月内年化收入的增长额 每月 200 美元 14:01 Lenny 提到 Claude 订阅价格，称公司是在补贴用量 20 页 37:51 Cowork 为 Kat 的演讲自动生成的幻灯片草稿页数 20–30 分钟 → 几秒 44:26 销售手工定制客户幻灯片的耗时，自建工具后缩短到几秒 5–10 个 48:26 Applied AI 成员忙碌时一天的客户对接数量 10 个 / 5 个 55:11 建 10 个好 evals 就足以量化目标；找到约 5 个信任的用户获取模型反馈 20 个调用点 61:27 早期 Claude Code 做大重构只改 5 处就停，待办清单让它改完全部 20 处 6 个 → 50 个甚至几百个 66:13 从同时跑 6 个任务，推演到未来同时运行几十上百个 Claude 90%–95% 69:56 很多人做自动化到这个准确率就放弃，但不到 100% 就不算真正的自动化 2 倍溢价 / 30 分钟 78:48 Kat 愿为 Waymo 付两倍溢价；它每天帮她省回约 30 分钟 金句摘录 · 中英对照 “I think it is very hard to be the right amount of AGI pilled.” 我觉得，对 AGI 的信念把握到恰到好处的程度是很难的。
— Cat Wu 00:00 “We wanna remove every single barrier to shipping things.” 我们想扫清发布路上的每一个障碍。
— Cat Wu 00:17 “As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.” 当写代码变得越来越便宜，更有价值的是决定该写什么。
— Cat Wu 00:48 “So like an extreme example is if Claude Code failed but Anthropic succeeded, I would be extremely happy.” 极端点说，如果 Claude Code 失败了但 Anthropic 成功了，我会非常开心。
— Cat Wu 31:40 “And we actually do this every time we launch a model. We read through the entire system prompt, and we reflect on, okay, for each of these sections, does the model really need this reminder anymore?” 每次发模型我们都会这样做：通读整个系统提示词，逐段反思——模型还需要这个提醒吗？
— Cat Wu 63:09 “If an automation doesn't work 100% of the time, it's not really an automation.” 自动化如果不能百分百可靠，就谈不上真正的自动化。
— Cat Wu 70:07 “Like, I think jobs are fake.” 我一直觉得，职位分工是虚的。
— Cat Wu 79:53 可以借鉴的做法 / 启发 用「research preview」心态发布：明确标注早期产品、收集反馈，能把承诺成本降到一两周上线一个想法，尤其适合探索性功能。 把目标写到极清：核心用户是谁、解决什么问题、成功长什么样——LLM 太通用反而会带来模糊，清晰目标能排除大量错误方案。 让 AI 替你做重复劳动前先想清楚：挑一个真想做到 100% 可靠的自动化，投入时间教会模型你的偏好，别停在 95%。 新模型发布时做一次「减法复盘」：通读系统提示词和产品功能，删掉模型已不再需要的拐杖；同时把旧原型换上新模型，看差距是否补上。 像 Anthropic 一样设「常驻发布频道」：工程师功能就绪后，文档、营销、DevRel 第二天就能接力发布，让发布阻力趋近于零。 优先做「现在跑不通、半年后可能跑通」的产品：原型先行，等模型能力追上来时你已经领先所有人。 回顾 / 思考问题 你的产品里，从「有想法」到「用户手里」现在需要多久？哪些环节可以被压缩到一周甚至一天？ 当写代码的成本趋近于零，你团队里谁在负责「决定写什么」？这个能力如何评估和培养？ 你上一次「删掉为模型打的补丁」是什么时候？你的系统提示词和产品功能里，有多少是旧模型时代的拐杖？ 你有没有一个做到 95% 就放弃的自动化？把它推到 100% 需要补上什么？ 你的团队有没有类似「使命高于产品线」的裁决机制？两个优先级冲突时，你们按什么标准取舍？ 按 Kat 的分类法（产出是代码 vs 不是代码），你日常工作里有多少比例其实属于 Cowork 类任务？ 本回顾由 AI 根据英文逐字稿整理，时间戳、引文与数字已对照逐字稿核对；如有出入，以原视频为准。
◉ 正在收听配音
