摘要：Anthropic Claude Code 产品负责人 Cat Wu 在 Lenny's Podcast 谈为什么多数 PM 候选人思路都错了、团队为何几乎不写 PRD，以及她如何把源码泄露和 OpenClaw 封堵说成官方语言
Cat Wu，工程师出身、短暂做过 VC、如今在 Anthropic 掌管 Claude Code 和 Cowork 两条主要产品线的产品负责人——她跟 Boris Cherny 的分工她自己形容成"80% 心电感应，20% 各管一半"。在 Lenny’s Podcast 最新一期里，Cat 聊了她每周面试一堆 PM 候选人的观察、Anthropic 内部几乎没有 PRD 的日常、把 research preview 当常态发货的原因，也被主持人拎出来正面回应了两件最近让社区炸锅的事：Claude Code 源码泄露和 OpenClaw 封堵。全程她用词稳得像拿着公关提纲，但在"token 其实有没有上限"这种细节上又轻轻修正了主持人一下。
原始视频：https://www.youtube.com/watch?v=PplmzlgE0kg
要点速览
- Cat 说大多数 PM 候选人还在用 6-12 个月路线图 的语言谈工作，而她团队正常的发货节奏是 一周、有时一天
- Claude Code 团队几乎所有 PM 都有工程背景，设计师也当过前端——“有产品品位的工程师"是他们真正在招的人
- 加速 Anthropic 发货的不是 Mythos，而是 research preview 品牌 + 一个常驻的 launch room + 明确的用户画像三件事
- 在"源码泄露"和"OpenClaw 封堵"两个敏感话题上，Cat 的答案几乎是同一个句式——都是 process failure、hard decision、prioritize first-party，措辞工整到可以直接当对外口径
- 新模型上线后，Cat 团队做的第一件事往往是删功能——to-do list 这种当年给模型当拐杖的东西，Opus 4 之后基本就可以退场
- Anthropic 里普遍相信 “AGI pilled 要恰到好处”，过度相信下一代模型的团队会错过为"现在这个模型"设计交互的所有红利（推断）
- token 不是无限的，只是"非常多”——Cat 在主持人追问时轻轻改了一下说法（推断：对外宣传和内部额度之间有一层 Cat 不打算展开的细节）
1. 与 Boris Cherny 搭档：她自称负责"从今天到三个月后的路"
Cat 解释她和 Boris 的分工时选了一个不太常见的比喻——“mindmeld”。她说 Boris 是 Claude Code 的技术 lead，也是产品愿景的提出者，擅长讲出"三个月、六个月后这个产品应该长什么样，AGI pilled 的版本长什么样"；她自己的工作则是把那个愿景拆成从今天到那儿的一条可走的路。 她补充说自己更多时间花在 cross-functional 上：marketing、sales、finance、capacity 都要拉进来同步，确保 feature 真做完时没有任何环节拖后腿。这个分工听起来像传统"PM vs 技术 lead"，但 Cat 立刻拧了一下——她说这条分工线 remarkably blurry，“80% 我们心电感应，另外 20% 里各有一块对方更在意的事，谁在意谁自己开车”。这话可以翻译成：她不喜欢定义边界。
注： Boris Cherny 在 2024 年 9 月以 founding engineer 身份加入 Anthropic，在这之前他在 Meta 做了约五年的 Principal Engineer，并在 O’Reilly 出过一本《Programming TypeScript》。Claude Code 最初的原型由他主导构建，目前他在 Anthropic 的内部头衔是 Claude Code 技术负责人。
2. 那道让几百个 PM 候选人栽跟头的题
Cat 面试过的 PM 候选人用 Lenny 的话讲是 hundreds。让她困扰的不是具体某条答案错，而是整批人思路的坐标系错了。 她的诊断很具体：AI 之前，技术迭代慢，PM 可以按 6 到 12 个月的路线图思考，用大量时间去和伙伴团队对齐 dependency，因为代码贵、协调成本必须前置。而现在——她说的数字是——很多 feature 的从构想到用户手上的时间，已经从 6 个月压到 1 个月，某些情况下压到 1 周甚至 1 天。多数候选人回答 AI PM 应该做什么时，仍在讲跨季度对齐、讲怎么把合作方的路线图拧进来。Cat 的判断是：这个答案本身就证明了候选人没意识到节奏已经变了。
我们要把发货路上的每一个阻碍都拆掉。每个人都应该觉得，一个 idea 从脑子里到用户手上，一周就够了，有时候一天。——Cat Wu 她给出的反向画像是：她真正想招的 PM，能把"这个 idea 怎么在本周末落到用户手里"当成默认问题。能回答这个问题的人，她说其实不多。
3. 从 6 个月到 1 天：Cat 列出的三件让团队真能这么快的事
Lenny 追问具体怎么做到，Cat 给了三件事，而且顺序有讲究。 第一件是把目标说清楚到 “不能再清楚”。她举的例子是"减少 permission prompts"这个议题——泛泛做是一个方向，但加上"面向企业专业开发者"“安全地做到零 prompt"的限定，一堆方案就被自动排除了。她说 LLM 自身的泛用性反而制造出新的模糊，如果 PM 不把目标钉死，团队会在同一个问题上扯无数条线。 第二件是 research preview 品牌化。Cat 说 Claude Code 几乎所有 feature 都以 research preview 形式先发——包装明确、清楚告诉用户"这是个早期想法、可能不会长期保留”。这个品牌动作有一个工程意义：它把发布所需的承诺强度降下来了，于是团队可以在一两周内就把东西放出去，而不是等到六个月后的 GA 版本。 第三件是常驻 launch room。Cat 说他们有一个叫 evergreen launch room 的 Slack 频道，工程师觉得 feature 准备好了就往里贴，docs 负责人 Sarah、PMM 负责人 Alex、Devrel 的 Tara 和 Lydia 会立刻跳进来，当天或第二天出 marketing 稿。她强调这个链条不是她写 PRD 建起来的，而是她作为 PM 主动建的、而且每次都得有人维护。
4. 关于 PRD：不是废了，是被挤到两种极端场景里
主持人问 PRD 是不是在 Anthropic 已经没人写了。Cat 的回答有两层。一层是"日常意义上的 PRD"——那种动辄几页、用来对齐全团队的文档——基本被两样东西取代掉：每周全员 metrics 复盘（让大家懂业务各条线数字怎么在走），和一份团队原则文档（写清楚谁是核心用户、为什么是他们、我们愿意牺牲什么），后者让具体决策可以下放，不必每次都等 PM 拍板。 但她同时承认 PRD 并没死。她说：对于目标特别模糊的 feature，他们还是会写一个 one-pager 把目标、delightful use cases、当前 failure mode 列清楚；对于基础设施密集、会做好几个月的项目，他们也还是写完整 PRD。换句话说，PRD 被挤到了"极小"和"极大"两端——中间层没了，中间层被 research preview 和 launch room 吞掉了。
5. Mythos 没让 Anthropic 变快——流程和期望才是
Lenny 抛了一个社区里的猜测：是不是你们因为已经在内部用上了 Mythos，所以节奏这么离谱？Cat 的回答干脆否定：团队"好几个季度前"就是这个速度了，Mythos 带来的加速是有的、但不是主项。 她把真正的原因归给两个字——流程和期望。她说团队极度"低流程"，每一个可能变成发货门槛的环节都被主动拆掉；每个人都被明确告知一个 idea 可以在一周内、甚至一天内走到线上。这个回答值得玩味——她显然不想把"速度"归因到一个还没对外的模型上，因为那意味着速度是买来的、不是方法。她要的是"方法"这个答案。
注： Mythos 是 Anthropic 内部代号"Capybara"层级的模型（位于 Haiku/Sonnet/Opus 之上），最早因 2026 年 3 月 26 日一次 CMS 配置错误导致一篇草稿文章外泄而被社区注意到；4 月 7 日以 Research Preview 形式被有限开放，最初用途是一个名为 Project Glasswing 的网络安全研究项目。本期播客录制时 Mythos 尚未全量发布。
6. 源码泄露她说了什么，又没说什么
主持人把三月底那次 Claude Code 源码泄露摆到桌面上。Cat 的答复短得像公关声明：他们立刻查了，确认是 human error——一个同事在 Claude 协助下发了一个 PR，内容是"如何发布我们 package 的更新"，经过两层人工 review，仍然漏掉了。之后他们 hardened 了流程，大部分改动已经上线。 Lenny 顺手追问了一句"那个人还在公司吗、还在做原来的工作吗"，Cat 答的是"Yes. Yes.", 后半句立刻转成"这是流程问题，最重要的是从里面学到东西、把保护网补上"。这里她的措辞值得玩味——两个 Yes 是对人的事实陈述，接下来的话立即把镜头从人转到 process。这段里她没有解释为什么两层 human review 都没拦下来，也没说漏掉了什么具体的规则。
注： 这次泄露的直接原因是 2026 年 3 月 31 日发布的
@anthropic-ai/claude-code2.1.88 版本中，.npmignore漏了*.map规则，59.8 MB 的 source map 随 npm 包一起发布，包内包含约 51 万行未混淆 TypeScript、1906 个文件、44 个未公开 feature flag 以及一个代号 KAIROS 的后台 Agent。事件距离 Mythos 3 月 26 日那次草稿外泄仅 5 天，是 13 个月内 Anthropic 的第二次代码层面事故。
7. OpenClaw 被封：Cat 给出的三段式解释
同一个话题装了两件事：Anthropic 最近限制了用户用 Claude Max/Pro 订阅驱动第三方 harness（主要指 OpenClaw），社区的反应用 Lenny 的话是 “got really upset”。Cat 的回答结构非常整齐，三段：需求太大、基础设施在扩、Anthropic 也在让自家 harness 更省 token；第三方产品的用量模式跟第一方不同，没被设计进来；团队研究了半天，最平滑的过渡是让所有订阅用户同时拿到一些 API credits。 然后才是那句关键话——"we did have to make the hard decision 必须要优先第一方产品和 API"。“hard decision"是一个典型的软化词，用在这里意味着她明确知道这件事对社区伤害了谁。整段她避免用"禁用"“封堵"这种动词，用的是 prioritize 和 decision。这个答案她显然是准备过的。
我们确实不得不做出一个艰难的决定——必须优先我们自己的第一方产品和 API。——Cat Wu
注： OpenClaw 原名 Clawdbot，由奥地利开发者 Peter Steinberger 于 2025 年 11 月左右发布，2026 年 1 月因商标顾虑改名；GitHub star 一度冲到 24.7 万。Steinberger 本人在 2026 年 2 月 14 日加入 OpenAI。Anthropic 的订阅条款更新发生在 2026 年 4 月 4 日，核心内容是 Pro/Max 订阅的 Claude 额度不再能走第三方 harness，需要改走 API credits。
8. PM 团队怎么分：五个块 30-40 人
Cat 给了一个少见的透明切面。Anthropic 目前 PM 规模在 30 到 40 人之间，大致分五块：
- Research PM（Diane 带队）：负责把客户对模型的反馈收拢，喂给 research 团队，同时 shepherd 每次模型发布；
- Claude Developer Platform：守 API 本身，同时推进像 “Managed Agents”（托管用户自己搭的 agent）这类面向开发者的产品线；
- Claude Code & Cowork：Cat 自己的团队，两条产品线合管；
- 企业：面向大客户做 cost controls、RBAC、安全控制；
- 增长：横跨所有产品线，和 CDP 一起推 API 用量。 她重点花了两段讲企业团队，说大企业需要的是 “我非常确信把这个工具放到内部没问题” 这种确定感——成本可控、权限可控、审计可查。这一块的 PM 工作她讲得比其他几块都细。
9. 工程、PM、设计三个圈正在同心
Lenny 提到同事 Amole 在前几期的观点：因为工程在变快，PM 和设计反而被挤爆——不是更不需要 PM，而是更需要。Cat 同意但给了一个不一样的切法。她说整个三角在 merge：PM 在做工程，工程师在做 PM 的活，设计师在 PM 的同时 land 代码。 Cat 团队的策略很明确：偏招有产品品位的工程师，而不是招更多 PM 去指导工程师。她说自己团队里有工程师可以”从看到 Twitter 上一条反馈，到这周末把 feature 发出去"，全程几乎没有 PM 介入——她的原话是这种人 “is the most efficient way to ship something”。 Cat 自己也是工程师出身，进 Anthropic 前在 Scale AI 做产品工程师、在 Dagster Labs 做 engineering manager、还短暂在 Index Ventures 做过 VC。她说团队里几乎所有 PM 都写过代码或正在写，设计师也都当过前端——这不是偶然，是 Anthropic 的筛选标准。
10. 人类大脑还剩下什么比较优势
主持人问了一个这类访谈里常见但 Cat 答得不常见的问题——“接下来几个月，人脑还能做什么机器做不了的事？” Cat 的回答没有提"创造力"“同理心"这种万金油词。她挑了一个具体的——common sense。她的例子是任何一次产品发布都有上千个活动部件，很多部件很小但任何一个都可能翻车；模型目前对"谁是利益相关者、他们彼此什么关系、他们的偏好、用什么渠道沟通最不翻车"这类 tacit EQ knowledge 把握不稳。这些不是写在文档里的东西。 她也承认这个比较优势"会被追上”，但补了一句当下模型还没覆盖到这里。这个答案的有意思之处在于：她没往"永远需要人"的方向说，她说的是"几个月内还用得着”。
11. Sunday P0 到 Monday P000：活在龙卷风眼里
Lenny 问这么多变化怎么扛，Cat 的答案是团队选人选得就偏好"lean into the chaos“的类型。她给了一个具体的时间段：周日晚上出了个 P0，周一一早多出一个 P0，周一下午你会发现 P000 已经来了——到那时你反而会笑自己周日那个 P0 怎么这么小。 她的生存策略不是抗压技巧而是减法：“brutally prioritize"哪件事最要紧，其他的允许它翻。她说：“发过几次 bug 产品是那种以前会让我睡不着的事，现在我能接受——因为我们知道反馈会很快回来，下个 release 修掉就行。“这句背后是一个软性承诺：我们卖的不是一次发完美，是一次发得够快、够多轮。
12. 一致性是高速迭代的祭品——然后 /powerup 补了一刀
主持人问高速迭代有没有代价。Cat 承认有，最大的一项是 产品一致性。代码贵的时候每条产品线 map 到一个 use case；现在两个团队都觉得某种形态值得试，就会出现两个并存的入口，新用户不知道该走哪条。 她举 /powerup 这个 slash command 作为例子——这个功能本身很矛盾。Anthropic 过去坚持产品应该不需要 tutorial 就能用好；但用户越来越多问 “100 个 feature 里我必须用的 10 个是哪些”，团队最终让步了，做了一个内建的引导命令。Cat 说这是"从原则上退了一步”——退得不勉强，但她给了这件事一个明确的标签：偏离了之前的立场。
13. 使命 + 专注：Cat 自己给的两个弯道超车原因
被问到 Anthropic 从"起步最晚、融资最少、没 distribution"到现在 ARR 11 billion 的路径，Cat 挑了两件事。 第一件是统一的 mission。她说团队在做产品决策时经常直接引用 “safe AGI” 这个词来 break tie——两个都重要的优先级，谁更契合 Anthropic 的 mission 就做谁，另一个就推后。这让她能在全司层面快速决策、而不是每条产品线内部自己 PK。 第二件她特意和 mission 区分开，叫 focus。她的定义很具体：“团队愿意为 Anthropic 的 KR 牺牲自己的 KR”。她给了一个极端例子——“如果 Claude Code 失败但 Anthropic 成功了，我会非常开心”。这种话通常是 spin，但她接下来的补充给了它一点 substance：她不把 cloud 社交 feed、聊天机器人这类 Anthropic 没做的方向列成遗憾清单，因为它们不在 mission 上。
如果 Claude Code 失败但 Anthropic 成功了，我会非常开心。——Cat Wu
14. 四个入口怎么选：Cat 给的决策表
Cat 被问 Claude Code terminal、Claude Desktop、Claude Code mobile、Cowork 之间怎么挑，她给了一张近乎可复制的决策表：
- Claude Code CLI：一次性任务、想要最新功能——她的原话是 “the CLI is our initial product surface”，新东西先在 CLI 落；
- Claude Desktop：前端相关任务、或不习惯 terminal 的非技术用户。也是看所有 session 的"控制面板”——CLI 会话、desktop 会话、web/mobile 会话全能在这儿汇总；
- mobile/web：touching grass 的时候派任务。Cat 说她见过太多人在飞机场把笔记本架在腿上只因为一个 agent 还没跑完——mobile 就是为了让这种场景消失；
- Cowork：输出不是代码的一切活儿——Slack 清理、slide 制作、doc 起草。她的分法很简单：输出是代码用 Claude Code，输出不是代码用 Cowork。
15. Cat 用 Cowork 做 slide 的那一晚
她给了一个具体案例：Code with Claude 大会前夜她要一份 20 页 slide。她做了三件事——先把 Google Drive、Slack、Gmail、Google Calendar 全连上 Cowork；把 PMM Alex 写的大纲草稿扔进去；告诉 Cowork 她想讲的叙事主线。 Cowork 工作了大约一小时，期间自己去翻 Twitter、翻 evergreen launch room、翻 Claude Code announce 频道里的团队 demo 帖，把这些素材合成了 20 页 slide。Cat 说第二天早上她打开时 “it was pretty good”——她做了一轮反馈（她自己偏好非常精简的文字，初版偏啰嗦），然后就定稿了。 这个故事里她特意点出一件事：因为 Cowork 可以访问 Anthropic 的 design system——团队早就有一套标准化 deck 模板和 20 个范例页——产出视觉上"就像 Anthropic 设计师做的”。这是她给 “连接数据源 + 给范例 + 明确叙事"这个工作流背书的一处细节。
16. Anthropic 内部人人造 App：那个定制 Deck 的销售
Cat 说 Claude Code 在公司内部引发了一波"个性化软件爆炸”——以前用现成 SaaS 凑合的 use case，现在每个人会为自己造个小 app。 她给的例子是 Claude Code 团队的一位 sales 同事，重复做客户 deck 做到烦——于是他自己造了一个 web app：输入客户 slug，app 自动从 Salesforce、Gong、内部 notes 把上下文拉齐，判断这个客户用的是 bedrock 还是 Claude for Enterprise 还是 console，有没有 HIPAA 合规要求，关心的是 SDLC 里哪一段，然后自动挑模板、拼出一份定制 deck。Cat 说原本这种手工工作要 20-30 分钟、通常会被省掉直接发通用 deck；现在几秒钟出一份。 她没明说但暗示了一件事——这类 tool 不经过中央 PM、没写 PRD、没被产品化。它就是那个 sales 自己做的，然后别人抄走用。
17. 没人想取代 Slack 的那个问题
主持人注意到 Cat 把 Slack 称为 “the core OS” of Anthropic，问她怎么看"SaaS 必死、自己造"这波讨论里 Slack 的位置。Cat 的回答有点反常——她说 Slack 做对了两件事：通讯基础设施的那份无聊工作它做得好得出奇，以及可定制性极高（Anthropic 把 Slack bot 当一等公民接到自己流程里）。 这段短但观察角度有意思——她没说 Slack 躲过了 AI 浪潮，而是说因为 Slack 做了足够多的 hackability，AI 浪潮的结果反而是 Anthropic 内部造了更多 bot，Slack 反而更 sticky。这个暗示是：并不是所有 SaaS 都会被 agent 吃掉，那些把自己做成 hackable substrate 的会活下来。
18. “对 AGI 要信得刚刚好”——Cat 给出的最稀缺 PM 能力
Lenny 问 AI PM 最稀缺的能力是什么。Cat 挑了一个看起来很虚、但她讲得很具体的东西——定义一个月后产品该长什么样。 她说困难在两头。一头是过度不信——你只根据当下模型能力规划，会错过两个月后就能做的东西；另一头是过度相信，也就是她原话里的 “too AGI pilled”——你假设模型下周就会万能，你就会去造那种"一个 textbox 接收指令、剩下让模型自己搞定"的产品，结果当下模型根本撑不起那个交互，用户体验全靠模型勉强兜底。 Cat 给 AI PM 的任务定义是：为当下这个模型设计能把它的强项用到最大的交互，同时为接下来两次模型跳跃留出 migration 路径。她没给这个能力一个缩写，但讲得够具体——“the right amount of AGI pilled”。
为 super AGI 设计产品其实很简单。难的是：针对当下的模型，你怎么把它的最大能力挖出来。——Cat Wu
19. 培养"产品品位 × 模型感知"的三条土办法
Cat 把"为当下模型造产品"这个能力拆成三件可以练的事。 第一件：跟模型聊它自己为什么犯错。她的例子很具体——模型有时会做了前端改动、跑了测试、但没实际打开 UI 验证。这时不要直接骂，问它为什么。有时它会说"system prompt 里某处让我误以为 UI 检查不属于这个任务”，或者"我 delegate 给 sub-agent 但没 check 它的活"。顺着这个回答去改 harness，比盲目加 prompt 管用得多。 第二件：锁定你最信得过的五个反馈者。Cat 说不是所有用户反馈都等价——有少数人能把"这个模型哪里变坏了"讲得精确到可以验证的程度。她团队的做法是每次有新模型就在 team lunch 上挨个问"你对这个模型的 vibe 是什么"，收到的反馈会直接变成去跑数据验证的假设——比如"这个模型似乎太急着写 memory"，那就去查 memory 写入频率的分布。 第三件：写 10 个好 eval。她强调不是写 hundreds，是 10 个质量高的。eval 在她的定义里不是测试用例，是 PM 对成功的量化定义——它让团队对着一个具体靶子迭代，而不是各自对"够好"有不同理解。她说 eval 写作是"被低估的 PM 工作"，应该更多 PM 和工程师自己写。
20. 新模型来了，她团队第一件事往往是删功能
这节的观察性反直觉更强。Cat 说每次新模型发布，他们的动作不是"加个 feature"，而是——打开系统提示，逐段问：“模型还需要这个提醒吗？“不需要就删掉。 她讲了 to-do list 的完整生命周期作为例子。Claude Code 早期，模型被要求做 20 个 call site 的重构时会改 5 个然后停下来；团队加了一个 to-do tool 强迫它枚举所有任务并一一完成。Opus 4 之后，模型不需要提示也会自己做 to-do；到更新的模型，to-do 基本成了 UI 级的”让用户知道它在想什么“而非正确性机制。 她把这件事拓到普遍规律：“model will eat your harness for breakfast”——每次模型能力跳跃，很多昨天还是刚需的 harness 明天就成了负担，定期清扫 harness 是 Claude Code 团队的默认动作。
每次模型变聪明，我们会去掉很多 prompting 层面的干预。每次新模型上线，我们都会把整份系统提示从头读一遍，一段一段问：这个提醒它还需要吗？——Cat Wu
21. 刻意造一个现在还不 work 的产品：Code Review 的三次尝试
Cat 提了一个更反直觉的策略：主动造那些目前还不太 work 的产品。 她举的例子是 Code Review。Claude Code 团队试过做 code review 工具若干次，早期版本是 /slash code review 这种轻量命令，效果一般——模型漏率太高，他们不敢把 CI 绿灯交给它。直到 Opus 4.5、4.6 和 Sonnet 4.6，准确率才跨过他们自己设的可靠门槛。现在他们能并行跑多个 code review agent 扫过整个 codebase，合成一份"merge 前必须 address"的 issue 清单，Anthropic 内部工程团队已经开始依赖它。 她给这个方法一个抽象：造原型时不要等模型能做；造到"差一点"的状态，等下一代模型出来换上去看看够不够。这种造法的产出——如果当下不 work，也能看清楚差距在哪儿、缺什么、下一代需要什么。
22. 从 1 个任务到 100 个任务：Cat 给出的 Claude Code 产品走向
被问 Claude Code 和 Cowork 的路线图方向，Cat 给了一个以"building blocks"为框架的叙述——她说原子单元是 task success：一个 prompt、一份描述、稳定产出可以 merge 或 share 的东西。模型越强，单任务成功率越高。 下一层是 multi-task——她说 2025 年末 multi-coding（一人同时开多个 Claude 跑并行活）成为了明显趋势，并且一直在涨。她的外推是：往后人均不只 6 个并行任务，可能同时跑 50、100 个。 再下一层就是推论——那个数量本地机器跑不动，所以会迁到云端。于是她列了 Anthropic 正在造的一堆配套：你怎么知道哪些任务需要你介入？agent 怎么自我验证（让你在看到"done"时能相信"done”）？用户反馈怎么让系统从此以后不再犯同一个错？她把这层叫 self-improving，并承认这是最难的一块。
23. 给听众的两条忠告：冲到 100% 和别沉迷 setup
节目快到尾声时 Cat 给了两条具体建议，都带自我批评。 第一条：如果你做一个自动化，要么把它做到 100%，要么不要做。她说常见错误是做到 90-95% 就放手——“一个不是 100% 的自动化其实不是自动化”。最后 5-10% 的工程更累、更慢，但只有过了这条线，任务才真的从你日程里消失。她还承认自己栽过——她教 Cowork 帮她处理 Gmail 收件箱归零，“相当耗时、目前还没到 100%"。
如果一个自动化不是 100% 成功，它其实就不是自动化。而最后那 5% 到 10% 确实更费力——但你只有走过那一步，才能真的依赖它。——Cat Wu 第二条：别沉迷折腾 setup。她观察到两类人——一类从不做任何自动化，另一类过度定制，加无数 skills、MCPs、workflow，设置本身变成了目的。她说 Anthropic 内部也有这样的人，Twitter 上就更多了。她的判断是：简单的 setup 往往效果更好；过度配置的人花在 setup 上的时间已经大于花在 setup 本来要解决的问题上了。
Q&A 速览
问： Cat 和 Boris Cherny 的分工怎么算？ 答：Boris 负责 3-6 个月后的产品愿景，Cat 负责从现在到那个愿景的可执行路径和所有 cross-functional 协调；80% 事项两人默契自动对齐，剩下 20% 各管自己更在意的那块。 问： Anthropic 的快节奏是 Mythos 带来的吗？ 答：Cat 明确否认——节奏好几个季度前就这样了。真正的原因是低流程、research preview 品牌化、以及一个常驻的 launch room 让 engineering/docs/PMM/devrel 在一天内完成从发布到对外宣传的链条。 问： 源码泄露和 OpenClaw 两件事 Cat 给出的答复结构一样吗？ 答：几乎一样——都是"这是个难决定，原因 A/B/C，我们从中学习，加固流程”。两段回答用词工整、信息量克制、没给后续新细节。 问： Anthropic 的 PM 团队有多大？ 答：30-40 人，分成 Research PM、Claude Developer Platform、Claude Code & Cowork、企业、增长五个模块。 问： Cat 觉得 PM 最稀缺的能力是什么？ 答：定义"一个月后产品该长什么样”——不被过度 AGI pilled，也不低估模型两次迭代后的能力。 问： 新模型来了团队先做什么？ 答：删功能。把系统提示里原本用来"扶"模型的 scaffold 逐段检视，模型已经能自己做的部分直接清掉。
再说两句：Cat 绕开的两道题
首先是"那个发了 bug PR 的同事后来怎么样了"。Cat 只说了 “Yes. Yes."——人还在、岗位没变——紧接着把镜头从人移到 process。她没说的事是：两层 human review 具体漏掉了什么审核规则？修复后新的规则是什么？修复发布节奏有没有被放慢？如果一个开源项目因为类似漏洞出了 supply chain 级事故，社区会追问到字符级；但在 Anthropic 语境里，Cat 选择让"这是 process 问题"成为这段对话的最终答案。Lenny 没追。这是这场访谈里最明显被 绕开的一道题——Cat 答得熟练、Lenny 答得克制，两人都知道彼此在绕什么。 真正值得玩味的是 token 那段。Lenny 顺口说 “你们基本上 token 无限用对吧”，Cat 先说 “we can use a lot of tokens”——这是外交答复。接着她补了一句 “some people do run into limits”，Lenny 马上用玩笑化解 “Okay, Boris, shut it down”。
我们可以用很多 token——但确实有一些人会撞到上限。——Cat Wu（接在主持人"你们基本上 token 无限"之后的原话修正） 但这句修正里有信息：Anthropic 内部也有额度机制，而且 “有人会触发上限"不是罕见事故。她紧接着讲"我们也 trust 个人负责地使用 token，浪费 token 是 frowned upon 的”——这是一段典型的企业政策语言，而不是单纯的工具使用文化。把这三句拼在一起，可以推断出：内部对高成本 agent 行为（比如疯狂 parallel sub-agent、无脑 re-read context）并不是无为而治，而是靠一条没有明说的社会压力线在管。这比一条 hard limit 更软、也更能反映 Anthropic 文化里"低流程 + 高信任"的真实配平。
接下来值得观察的信号
- Cat 说的"self-improving harness”——下一代 Claude Code 是否会从 to-do list 级别的 scaffold 进一步后撤，把更多"让模型做对事"的逻辑推回模型本体；
- Cowork 在非工程岗的渗透——Cat 讲的"销售做客户定制 deck"这类内部 tool 爆炸，外部企业客户是否会出现同样的散点式应用爆发；
- OpenClaw 封堵后第三方 harness 社区的走向——Pro/Max 订阅不能绕路之后，开源项目会搬到 API credits 模式还是分化到其他模型家族。
