Anthropic产品团队

Boris（tech lead）管远期愿景，定义"产品 3-6 个月后长什么样"（Cat 说的 AGI pilled 版本），每天从手机 ship 一堆 PR；Lenny 点出 Boris 那期是整个播客最受欢迎的一期，半开玩笑说"no pressure"。Cat 负责从今天到那个愿景之间的路径设计 + 跨职能粘合，确保 marketing/sales/finance/capacity 都 bought in，"一旦功能准备好了，没有任何 blocker 能挡住发布"。两人协作"大概 80% 是 mind-meld，20% 谁更在乎谁推"，边界"remarkably blurry"。Lenny 替她抱不平：人们没充分认可她对 Claude Code、Cowork 的贡献。→ 详细 旧世界（代码贵、变化慢）可按 6-12 个月规划，重头戏是和合作团队协调多季度路线图——"因为当时 code 生成成本非常高"。现在 AI 把工程大大加速、模型能力快速提升，时间线从 6 个月压到 1 个月、有时一周甚至一天。Cat 说她一直在面试数百个 PM，发现"很多人对成为成功 AI PM 的理解 approaching it very incorrectly（做法完全不对）"。她给出新 PM 最重要的三件事：

• 设清晰目标（set clear goals）：因为"LLM 太通用，反而在'为谁构建、解决什么问题、最重要的用例是什么'上制造了大量歧义"。她的具体例子：关键用户是"企业里的专业开发者"，主问题是"权限提示太多、用户 fatigue（疲劳）"，于是目标定为"让企业级专业开发者安全地达到 zero permission prompts（零权限提示）"。为什么这个目标好用："它 rules out（排除）了一大堆替代方案"——光说"减少提示"可走一百条路，但锚定到"安全归零、一个 prompt 干更多事"，团队立刻收敛到正确路径。
• 建可重复的发布流程（repeatable process）：几乎所有功能都用 research preview 上线，"我们 clearly brand 这是早期产品、只是个 idea、想拿来收反馈迭代、可能不会永远被支持"。核心作用是"降低我们对发布的 commitment（承诺/包袱），一两周就能把新东西推出去"。
• 造跨职能 flow：让团队知道"什么时候该拉跨职能伙伴进来、那些伙伴的预期是什么"。机制：工程师觉得 ready 且 dogfood 过了就贴进 evergreen launch room；Sarah（Docs）、Alex（PMM）、Tar 和 Lydia（DevRel）"jump in，第二天就把营销公告 turn around"。Cat 强调："因为有这套紧密流程，任何工程师发布东西的摩擦都很低，而搭建这套流程正是 PM 的角色。" → 详细
• 仍写 PRD 的两种情况：(a) 特别**模糊（ambiguous）**的功能——写一页纸说清"目标是什么、令人愉悦的 use case 长什么样、当前要修的 failure modes 是什么"；(b) 重基础设施、动辄几个月的项目。Cat 明确纠正："哦，我们有时候是会写 PRD 的"——没完全废掉。
• 取代 PRD 的两个机制：
  • 每周 metrics readout（指标通读）——"我们有非常 rigorous（严格）的指标，每周和整个团队过一遍。目的是让每个人都深刻理解业务的方方面面：关键目标是什么、怎么发展的、什么在驱动它们。"
  • 团队原则列表（team principles）——"包括我们的关键用户是谁、为什么是他们……之所以把这一切 articulate（明确写出来），是为了让团队里每个人都觉得自己懂业务怎么运转、什么对我们重要、我们愿意 trade off（取舍）什么。"
• 两样的共同目的，用 Cat 的话：让人们"by themselves（自己）就能做决定，而不会觉得被 PM 或任何 stakeholder 卡住"。Lenny 借此点题："这么多内容其实都在说——将来我们仍然需要 PM；外面那么多'为什么还要 PM、工程师直接 ship 不就行'的论调站不住脚。" → 详细 不是因为新模型——Cat 直接泼冷水："我们已经 fast 了好几个季度……（最强内部模型）确实让我们 ship 快了一点点，但它解释不了增量的大头。"真正原因是三件事叠加：流程极少 + 团队共识 + 默认无障碍——"我们想 remove every single barrier to shipping，让每个人都感到 empowered，能把想法在不到一周、有时一天内，从 idea 变成 out in the world。"数字佐证（Lenny 引述）：起步落后一大截，"OpenAI 遥遥领先，看起来 Anthropic no way 长期竞争"；如今增长达 「$11 billion ARR 一个月的增长」 量级（Lenny 补充到本期发布时可能更高）。→ 详细
• Claude Code 源码泄漏：Cat 复盘是 human error——"有人和 Claude 一起写一个 PR（只是更新发包流程的改动），它实际上走过了两层 human review"。态度："这是 process failure，最重要的是学习、加 safeguards，绝大多数加固已经 ship 了。"Lenny 追问"这人还在 Anthropic 吗"，言下是没被开除。→ 详细 · → 详细
• Open Code（第三方开源客户端）限制订阅用量：社区很气、觉得在"伤害开源社区"。Cat 解释需求太大、一直在 scale 基础设施并让 harness 更 token efficient；关键原因"它本来就不是为第三方设计的，第三方使用模式和一方产品很不一样"。最后给所有订户附赠 credits 补偿，但仍不得不"做艰难决定——优先保 first party products 和 API"。根因归到使命："对 Anthropic 最重要的是增加 Claude 能 reach 的用户数，一方订阅是途径之一，但有时以第三方为代价。"→ 详细 · → 详细 Cat 给"大概 30 到 40 个 PM"，分五条线：Research PM（Diane 带，把客户反馈喂给 research 落地、护送模型发布全程）；Cloud Developer Platform（维护 Claude Code 赖以运行的 API，还发 managed agents——"让你构建自己的 agent、由我们托管"）；Claude Code & Cowork（Cat 负责）；Enterprise（cost controls、RBAC、security controls，让企业放心用）；Growth（横跨产品矩阵 + Claude API 增长）。配套观点（Lenny 引 Amole 上一期）：业界总说"未来需要更少 PM"，但 Amole 反过来——正因工程师跑太快、每天都有 feature 发布，PM 和设计师被挤压、很难跟上，所以他需要更多 PM。→ 详细
• Cat 对"角色融合"的判断："所有角色都在 merge——PM 在做工程活、工程师在做 PM 的事、设计师在做 PM 同时还在 land code。"
• 由此团队面临选择："要么招更多有强 product taste 的工程师，要么工程招聘维持现状、改招更多 PM 去 guide 他们。"Cat 团队选前者——专注招 product taste 强的工程师。原因："这样能 reduce ship 任何产品的 overhead。我们很多工程师能完全 end to end——从在 Twitter 看到反馈，到周末就把产品 ship 出去，几乎不需要 product 介入；这其实是最高效的 ship 方式。"
• 互补性："engineer 和 PM 是 overlapping 的，多招哪种都受益很大。但 product taste 仍是非常稀缺的技能，谁强烈展现出这点，我们基本上会招。"
• 工程背景"未来几个月"特别有用的理由："如果你有工程背景，你对一件事该有多难的 sense 更好——很容易做的，与其 debate，不如花一小时直接做掉；比较难做的，你提前就知道对团队 cost a lot more，所以它对 prioritization 有帮助。"
• 设计师同理（"我们的设计师其实也都曾经是 front-end engineers"）；Cat 自己的路径是"做了好多年工程师，然后 very briefly 做过 VC，才加入 Anthropic"。 → 详细 · → 详细 · → 详细
• 牺牲的是 product consistency（产品一致性）。旧世界"code 贵时你会精心规划整个产品套件——每个产品怎么相关、各自 use case、怎么整合，基本一个 use case 对应一个产品"；现在 AI 太快、要测的想法太多，"我们有时就会做出互相重叠的功能。很多时候是因为我们内部同时喜欢两种 form factor（产品形态），想让外部用户告诉我们哪个更好"。代价是新用户"不知道完成 X 任务的 best path 是什么，需要做更多 education"。
• 用户的"跟不上"焦虑：对比传统 SaaS"一个月 check 一次、半年不看也没 missing out 的失落"；但"对这些 agentic 工具（不只 Claude Code 和 Cowork，是整个生态），人们觉得必须每天刷 Twitter 看绝对最新的东西"。她的愿望很具体："我真心希望人们直接打开工具，工具本身会教他们想知道的，让他们感到被带着走（bought along）而不是被一台越来越快的 treadmill（跑步机）追赶"。
• /powerup 命令：这是上述矛盾的产物。Cat 坦言团队背离了原有原则——"以前我们不想做 PowerUp，因为觉得产品应该 intuitive 到不需要 tutorial。但功能太多、太多用户想知道'有 100 个功能，我绝对必须用的那 10 个是哪些'，所以我们就做了"。 → 详细 · → 详细
• 最难的技能，Cat 原话："能够定义产品在一个月后该长什么样。这个时间线里，模型能力会怎样、用户行为会怎么变，有大量不确定性。"Boris 管 3-6 个月远景，Cat 这条是更近的"到那个未来的路径"。
• 能力来源："最好的 PM 能从用户如何 abusing the limits（滥用/突破现有产品边界）里看到模式，据此 set 一个方向、steadily 朝它执行，并在模型能力比预期好很多或差很多时迅速 change the path。"
• 「AGI 信仰」校准的两端（本期金句之一）："很难拿捏恰到好处的 AGI pilled 程度。每个人都看得见那个未来——模型极其聪明、几乎无所不能，那时你根本不需要复杂产品，一个 text box 就够：你告诉它要什么，它聪明到能自己加任何工具、任何集成把活干完，知道自己何时 uncertain、还会反问澄清。为这个超级 AGI 造产品其实非常容易。"真正难的是反过来——"为当前的模型搞清楚：怎么 elicit 最大能力？怎么帮用户走上 golden path（黄金路径）？怎么引导用户利用模型的强项、同时 patch 它的弱点？这个技能相当稀有。" → 详细 总纲是"花大量时间和模型对话、使用它"，落地为三招：
• 让模型反思自己（introspect）——经典案例：模型做了前端改动、跑了测试，但实际上没打开 UI 去验证。Cat 说"问它'你为什么这么做'其实很有用"，常暴露三类 gap：(a) "system prompt 里有让它困惑的地方"；(b) "它没意识到前端验证是这个任务的一部分"；(c) "它把验证 delegate 给了一个 subagent，subagent 没测、主 agent 也没 check 它的工作"。方法论："对模型每个决定的原因保持很强的好奇心，就能看出是什么 misled 了它，从而修 harness 来 close the gap（补上缺口）。"
• 找 5 个高质量反馈用户——"通常有 a handful of people 远比其他人更善于 articulate'什么样的模型 / 模型-harness 组合才算好用'。很多人会给你反馈，但不是每个人的反馈都一样 qualified。所以找到 5 个你信任的人组成的小群体，对快速拿反馈特别重要。"实战做法："每次测新模型，我们最快的取反馈方式之一就是在 team lunch 上挨个问每个人'你对这个模型的 vibe 怎么样'。"常冒出非常具体的 vibe，例如"模型没充分解释思考、太 abrupt（生硬）"、"它爱写一大堆 memories，但我们不确定质量高不高"、"它自我测试得不够 / 它爱自己测自己（这很好）"。这些再变成数据假设去验证——"我们有海量数据但很难直接 extract insights，这组人的反馈帮我们确定该测哪些假设，然后去捞数据验证"。
• 写 evals（评测集）——"你不需要造几百个 eval，造 10 个好的就足以帮团队量化'目标是什么、进展到哪、还缺什么'。"她说"eval 是个被 underappreciated（低估） 的东西，更多 PM、更多工程师都应该投入"。她的 workflow："当某功能我觉得需要更多 product definition 时我才跳进 evals，产出通常是——'这是我做的 5 个 eval、怎么跑、这些通过了这些没通过、这是我用来提升通过率的 prompt'"。她点名"memory 这类功能从 eval 里受益特别大"；团队有个小 pod 和 research 紧密协作，更精确度量 Claude Code 的行为和最大改进空间。 → 详细 · → 详细 · → 详细 Cat 点名 Amanda——她 molds Claude's character："这是个极难的角色，因为任务太 ambiguous——连编码都更容易，因为编码至少能 verify 成功"，塑造性格需要对"Claude 应该是谁"有极强 conviction。Cat 佩服她"不仅能塑造，还能清晰 articulate 什么样的性格算成功、什么不算"。来源补充：Lenny 提联合创始人 Ben Mann 上过本播客谈 Constitution（价值准则）对 Claude 的核心性，并领悟"正是 character 让 Claude 在那么多事上做得这么好，表面看'有趣'像无关紧要的 side thing，其实是 Claude 成功的核心"。用户最常提的 Claude vibe：lighthearted and fun、任务上极其 competent、low ego（你说它错了它真诚道歉"哦 shoot，谢谢你告诉我，我们一起修"）、非常 positive（你觉得任务 insurmountable 时它说"没事，要我帮你开个头吗"）、给 earnest feedback 而非无脑同意——"这是 great co-worker 的特质，我们刻意 imbue 进 Claude"。→ 详细 · → 详细 团队全是 lean into the chaos 的人，"尽量笑着面对每个挑战，因为总有那么多 risk，你要是对任何事太 stressed，就会 burn out"。想要的人："看着难题说'这会很难，但我 excited 去解决，我会尽全力，我知道不会完美，但我能安心睡觉，因为我尽力了'。"招聘偏好：在行业里 sediment 过、经历过很多 ups and downs、很清楚什么给自己 energy、怎么长期维持 energy 的人。Lenny 的画面比喻：每个 Anthropic 人都"so chill、so optimistic"，像《加勒比海盗》里那个人悠闲走下沉船楼梯、整艘船在他周围崩塌却超级淡定。现实例子（Lenny 讲）："周日晚来个 P0、周一又一个、周一下午变 P0000"，Cat 的应对哲学："承认能力有限、需要睡好觉、狠心 brutally prioritize、be okay letting things go——有些产品没我希望的那么 polished，但只要没挡住 core use case 就 okay，下版就修"；"发布一个 buggy feature 以前会让我 kept me up at night，现在我能 live with 了"。引 Ben Mann："this is the most normal the world will ever be（往后只会更剧变）"。→ 详细 · → 详细 Cat 把"从落后逆袭"归因为两件事，并区分了细微差别：

1. 使命统一（unifying mission）：「把 safe AGI 带给全人类」。"很难形容这有多重要——我们招的是最在乎这件事的人，而且这是我们在'整个产品该专注 ship 什么'的决策里频繁 reference 的东西。因为把使命放在任何单一产品线之上，能做出横跨整个 org 的极快决策、并统一执行——这是我在同规模公司从没见过的。"机制："两个 competing priorities 时，讨论'哪个对 Anthropic 的使命更重要'，决策就快多了，然后所有人都站在那个决定后面。"Lenny 的解读很关键："对比另一家**'rhymes with bopen-bi'（暗指 OpenAI）**的公司——他们做了很多很多不同的事；而 Anthropic 不做社交网络、不做资讯 feed，因为那不符合使命，这让它保持 focused，似乎正是成功配方。"
2. 聚焦（focus）：Cat 特意和"使命"区分——"mission 对我来说是：团队愿意做出 hurt their own goals and KRs（伤害自己目标和 KR）的牺牲，去服务 Anthropic 的目标，而人们很乐意做这种 trade-off。一个极端例子：如果 Claude Code 失败了但 Anthropic 成功了，我会 extremely happy——整个团队都愿意顺这条逻辑链做决定。"Lenny 顺势确认 Open Code 那个决定也是这套逻辑（"不符合使命就停掉"），Cat 默认并补"对 Anthropic 最重要的是扩大触达用户数"。 → 详细 · → 详细 · → 详细 清晰的"该用哪个"心智模型，核心判据是输出是不是代码：Claude Code（终端 CLI）——"一次性 kick off coding 任务、想要全部最新功能时"用它，"CLI 是最初的产品 surface，新功能往往最先 land 在这里，所以最强大"。Claude Desktop——特别适合需要前端工作的场景（"做 web app 时把 preview 面板开右侧，一边聊一边实时看"）、适合不熟终端的非技术人，还是 one-stop control plane（在 desktop 里看到 CLI 会话、其它 desktop 会话、web/mobile 起的会话）。Web/Mobile——价值是"on the go 随手起任务"，吐槽名场面"数不清见过多少人在外面举着开着的笔记本 tether 到手机上"。Cowork——"填补的是：很多人每天的工作输出根本不是代码（清空 Slack、inbox zero、做 slide deck、写功能目标文档）"，一句话心智模型"输出是代码就用 Claude Code/desktop/mobile；输出是非代码就用 Cowork"。关键经验：用 Cowork 前必须先连数据源（Google Calendar、Slack、Gmail、Google Drive），"只有拿到全部 context 才能为你 curate 输出"。→ 详细 · → 详细 Cat 给的最完整实操案例（为 Code with Claude 大会做演讲幻灯片）：

• 背景：一场演讲讲"Claude Code 从 assistant 到 full-on agent 的过渡"，想"展示所有使这过渡成为可能的产品，并找出内部哪些 success story 可当 demo"。
• 她喂给 Cowork 的东西：连好的 Google Drive、Slack；PMM Alex 草拟的"该覆盖的要点 draft"；以及她想讲的 narrative。
• Cowork 实际干了什么："它自己干了一个小时——walk through Twitter 看我们发布了什么、翻 evergreen launch room、翻 Claude Code announce 频道（团队在那贴'怎么从 Claude Code 拿到最大价值'的 demo），synthesize 成一份 20 页 deck，我早上醒来就看到了。"评价："读完觉得相当不错，只需要一轮 feedback——我喜欢幻灯片 extremely minimal words，它有点太啰嗦；但远比我自己产出的快。因为它能访问我们整个 design system，看起来就像一个 Anthropic 设计师做的、incredibly polished。"
• 她的 prompt 关键要素（近乎原话）："为 Code with Claude 大会做一份 deck。这是 PMM 建议它该覆盖的内容。这是我之前做的初稿，我不喜欢。这是我手动做的一版，我也不喜欢，但我把它链接了。能否先创建一个带细节的 proposed outline？另外确保别和 keynote 重叠太多，那个更重要。"
• PM 角色的体现：Cat 强调这正说明 PM 今天的角色——"Claude 是很棒的 brainstorming partner，能极快 synthesize 海量信息、把所有 possibility 呈现给你；但 PM 的角色仍是做最终决定：最终产品里该放什么"。她亲手拍板的主线："从'让本地任务成功'→'让每个 PR 变绿（green）'→'帮工程师 land 更多 PR'"，并为每阶段选最有说服力的 demo——定完这个 outline，Cowork 才 went off for a few hours 把整份 deck 建出来。
• 设计系统怎么接入：两种办法——(a) "我们已有一套标准化的 deck 用在所有外部 engagement，我就把它的访问权给 Claude，它能看到我们用什么颜色、字体，还有大约 20 个 example slide 格式"；(b) "也可以连你的 Figma MCP——如果你在 Figma 里存了幻灯片格式，它能直接拉过来"。 → 详细 · → 详细 Cat 的 stack 基本"heavily 是 Claude Code + Cowork，Anthropic 主要跑在 Slack 上，我觉得它像我们公司的 core OS"。习惯："约 30% 时间在 push Cowork 的边界，这样我对'我们哪里不擅长'有很强 sense；也花很多时间和模型对话理解它为什么犯那些错。"Claude Code 解锁的内部现象："大大降低了'做任何自定义 app'的门槛，我们看到一波 personalized work software 的浪潮"。完整案例——销售同事做的内部 web app：他发现自己一遍遍做重复 deck，于是建个 web app 存三种核心模板（101、20-in-1、Mastering Claude Code），输入客户 context 后从 Salesforce、Gong、笔记拉数据自动定制——会提取客户用的是 Bedrock / Claude for Enterprise / Console、客户关心 code review 阶段就加一张、需要 HIPAA 合规就加一两张、用 Vertex/Bedrock 不想用 Enterprise 就删掉"仅限 Enterprise"幻灯片；"通常这是 20-30 分钟手工活，现在几秒钟出一份 tailored deck"。关于 Slack（Lenny 观察"没人想造自己的 Slack，它就是一直在赢"）：Cat 认同"人们 hate on Slack，但它在自己要做的事上真的非常优秀，最 cutting-edge 的团队都离不开它"，并感谢其 hackability（"我们超爱做 Slack bot"），半开玩笑补一句"是时候买点 CRM 的股票了"（Salesforce 是 Slack 母公司）。→ 详细 · → 详细 Cat 形容为"a very technical go-to-market person"，Lenny 补充像 forward deploy engineering / customer success，本质是"帮客户在他们公司里采用最新 API 和模型功能——既为客户产品赋能，也帮客户内部加速"。工作强度："很多人一个人覆盖多个客户，普通工作日 5 到 10 个客户 engagement，高峰更多"；token 消耗排第二（仅次于工程团队）。用 Claude Code"为客户做 prototype，比以前快得多"。用 Cowork（很具体）："经常前一晚让 Cowork 总结明天每一个客户会议——这客户问过我什么、什么最 top of mind、过去的 action item，整合成一份 dossier/brief；还能 research 开放问题——客户问'功能 X 什么时候发布'，它能通过 Slack 查到最新 ETA 塞进笔记，进会就有 absolute latest 信息"——这些都是"人们为自己造、再分享给团队的 workflow"。→ 详细 · → 详细 核心规律："很明显——模型越好，人们 delegate 给它的任务越多、花的小时数越多，所以每次模型 jump 或产品实质提升，每个工程师（或任何 knowledge worker）的 token 成本就上涨一次"；"它仍远低于平均工程师薪资，但这个百分比随时间逐步上升"（呼应当下热议的"token 花费超过工资"现象）。内部 token 政策："我们能用很多 token，但有些人确实会撞到 limit"——Lenny 调侃"okay 还是有 limit 的。Boris，shut it down。"Cat 解释逻辑："信赖赋权内部团队尽可能快地构建，也信任每个人都理解 serving 模型要烧多少 capacity、会负责任地用 token；所以浪费 token 很被 frown upon，但我们信任个人能做那个判断"。Lenny 总结这是"拥有最先进模型的又一优势——一个开始转起来的 flywheel"。→ 详细 · → 详细
• 主线工作："我们随新模型做的很多改动是移除不再需要的功能。很多时候给产品加功能，是作为模型的 crutch（拐杖）——因为它本身不会自发那样做。"
• 经典案例 1：to-do list（待办清单）。"早期 Claude Code，人们让它做大型重构，它说'好，我需要改这 20 个 call site'，然后改了 5 个就停了。我们想'怎么强制它记住把 20 个全做完'？我们团队的 Sid 说——想想人类会怎么做？人类会列一张清单。于是他加了 to-do list，Claude 就真能把这 20 个全修了。"但转折："到了 Opus 4 和之后的模型，我们意识到不需要再强制它用了——它会自然地用。早期得不停提醒'你 to-do list 上的都做完了吗'；后期不用提示就自然想着做完。如今 to-do list 作为'用户能看到 Claude 在做什么'的功能仍 nice-to-have，但对模型已 deemphasized 到可用可不用。"
• 经典案例 2：code review（代码审查）——"新模型解锁全新功能"的代表："我们试过几次造 code review 产品，过去发过更简单的版本——就是 /code review 命令；直到最近的模型才觉得'这 code review 好到——工程团队现在依赖它通过、才 merge PR'。我们一直 dream of Claude 能成为可靠的 code reviewer、能 confidently 抓住绝大多数 bug；直到 Opus 4.5、4.6 和 Sonnet 4.6，才觉得现在能同时跑多个 code review agent、遍历整个代码库、综合出工程师 merge 前必须处理的 real issue。"
• 金句："the model will eat your harness for breakfast"——Lenny 引用，Cat 认同含义："模型每变聪明一次，我们就能移除很多 prompting intervention"。固化的流程："我们每次发布模型，都通读整个 system prompt，逐段反思'这一节模型还真的需要这个提醒吗？'不需要就删"。
• 配套理念（刻意造跑不动的原型）："造现在还不一定 work 的产品相当重要——这样你才知道'要让它 work 还缺什么'；然后新模型一到，直接把它 swap 进你已做好的原型，看新模型有没有 close 那个 gap"。Lenny 概括成本播客常见主题："造一个 6 个月后才可能成立的东西、卡在能力边缘，等模型追上，它就成爆款、你领先所有人"。 → 详细 · → 详细 Cat 用 building blocks 框架描述演进路线：① 单 task 可靠完成——"核心 building block 是让单个任务成功：给一个清晰 prompt，它能持续产出你能 merge 或分享的输出，模型越聪明成功率越高"；② 多 task 并发——"multi-coding 是 2025 年末的一件大事，之后只增不减，现在你能一次跑 6 个任务"；③ 大规模远程 + 自改进——外推是"接下来也许一次跑 50 个、上百个 Claude，那时 RAM 都不够，所以很可能远程运行"，于是问题变成"怎么建界面让你知道哪些任务该看？怎么确保 agent 完全 verify 工作、你看到'done'就能很快验证完全信任？怎么让过程 self-improving——给反馈后模型以后每次运行都 incorporate、永不再犯？"（已发布 mobile app 上"从手机 dispatch 控制"就是这方向的探索。）→ 详细 面对 PM/创始人/跨职能岗位对职业未来的焦虑，Cat 的建议很实在：
• 看到自己重复做某事 → 先想能不能让 AI 替你做。"AI 给每个人比以前多得多的 leverage。大多数人的工作都有自己 absolutely love 的创意部分和真心讨厌的 tedious 部分；AI 的美妙就在于它能学你每次做那个手动任务的方式、generalize、然后自动跑，把繁琐部分接走，你就空出来专注创意部分"——"如果 AI 帮你 take care of grunt work，你现在就多出过去没有的 20% 时间"，可去做那个"一直觉得公司该做、却从没 bandwidth 做的 pet project"。→ 详细
• 把自动化做到 100%，别停在 95%（她反复强调）："如果一个自动化不是 100% 都 work，它就不算真正的自动化——因为你还得每次去 check。我常看到用户把某事自动化到 90-95% 准确度就放弃了；那最后的 5-10% 确实更费时间，而且 build 自动化往往比你自己做还慢得多；但你得投入那份 elbow grease（下苦功），scope 出一个你真想做到 100% 的自动化，把 preference 教给 Claude、给反馈让它改进，直到 100%，那时才能真正 rely on 它。95% 的自动化没多少价值。"她自爆反例："我一直在教 Cowork 帮我把 Gmail 弄到 inbox zero，但它 very time-consuming、绝对还没做到。"Lenny 也自爆：他把"能不能上播客"这类邮件自动归到一个叫 spammy 的文件夹，"95% 很棒，但偶尔'哇我漏了一封'"——这条也戳中了他。→ 详细 · → 详细
• 真正天天用上自己造的东西，才学得到东西。"我看到很多人玩 AI、做 prototype app；我真心想 push 大家去造那种你每天真在用的 app——因为只有通过 usage 你才真正拿到价值。如果你 one-shot 出一个东西、觉得'哦酷'、再也不回来用，你学不到多少、也得不到多少 leverage。"
• 简单设置 > 过度自定义。两个极端："一端是从不定制、从不 build 自动化的人；另一极端是对定制工具走火入魔的人——狂加一堆 skill、MCP、各种 workflow 改进，有时甚至 distract 了'发布产品/构建功能'的核心目标；有一群人甚至花太多时间定制到不睡觉、连最初要做的核心任务都没做。"断言："我觉得 simple setups actually work better。"Lenny 接梗："Twitter 上一堆'看我的 setup 多 optimized'——那你到底在 build 什么？"Cat 也承认自己是这种过度优化的"罪犯"，正在改。→ 详细 · → 详细 背景：Lenny 提 Karpathy 前一天的推文，谈一个有趣的分裂——当年试过 ChatGPT/Claude、觉得"也就那样、挺糟"的人，有些就此放弃、对 AI 变得非常 cynical，坚信"不可能有那么大不了"；而真正用它写代码的人看到了它全部的巨大威力，两边互不理解。Cat 的解读："最大转变是——2024 那一代产品是 chat-based，而 Claude Code 这一代是 action-based。人们的那个大 aha 时刻，就是当 Claude 能代表你做事（do things on your behalf）的时候——知道这个 agent 能做的远超'告诉你该做什么'、它能自己把事干了，那感觉太棒了。"具体例子：Lenny 点名 Claude 的 Chrome extension——"你就看着它替你做事：'帮我填这个表单'，'好的，我去了'"，亲眼看它执行最能制造 aha。→ 详细 · → 详细
• Q1 最常推荐的书 → 详细
  • How Asia Works（《亚洲如何运作》）——"关于经济发展：哪些政策和政府能造就长期成功的经济"。
  • The Technology Trap（《技术陷阱》）——"过去几次技术革命（工业革命、计算机革命）如何影响工人。喜欢它是因为：我觉得我们能从历史里学到很多，以确保这次转变（AI）进展顺利"。
  • The Paper Menagerie（《折纸动物园》，趣味推荐）——"一本关于成长（coming of age）、AI 和自我发现的短篇故事集"。
• Q2 最爱纪录片/影视 → 详细 · → 详细
  • Drive to Survive（F1 纪录片）——"没什么 deeper meaning，就是看人们对某个 singular engineering goal 如此着迷、那种追求的 purity，很 satisfying"。
  • Free Solo（《徒手攀岩》，Alex Honnold 无绳爬 El Capitan）——Cat 本人就是 rock climber，讲得最动情："第一次看是在我开始爬岩之前，只觉得 impressive，但没真懂它多 impressive。这是少有的那种电影——你对它了解越多，越被它有多疯狂震撼到。他在岩壁上那些动作，我觉得这辈子都做不到——哪怕搬到体育馆、离地一英尺、带着绳子，我也做不到。"还提到"那个上冰山的、更年轻的人的纪录片很 sad"。
• Q3 最爱新产品（非 Claude） → 详细
  • Waymo（自动驾驶出租）——"除 Claude 外最改变我生活的产品，diehard 用户，一天用两次、上下班都坐"。喜欢两点：(1)"如果 Waymo 在等我，我不会觉得不好意思"；(2)"它让我更有生产力——和人类司机同车时不好意思打工作电话；在 Waymo 里可以接——不担心被偷听、不担心太吵，等于每天给我 back 30 分钟"。Lenny 补充"本以为 Waymo 必须比 Uber/Lyft 便宜，但其实我很乐意付 2× 溢价"。它甚至改了内部用词："以前说'叫个 ride-share app'；现在大家直接说'是 Waymo 来吗？'"
• Q4 人生信条："Just do things" → 详细 · → 详细
  • Cat 展开："first-principles thinking 很有价值——如果你知道在 optimize 什么、有扎实第一性原理，通常能推导出正确路线、向所有 stakeholder 讲清楚，然后就该直接去做。我觉得 jobs are fake（工作的很多定义是虚构的）——只要理解了 constraint，就能找出能做什么，然后快速去试、从错误里学、错了就道歉或修正"。为什么解放：公司里"角色和团队范围常被定死——这块代码我们碰、那块不能碰"，而"就去做事"让人敢做决定、敢跨团队边界。同义词：agency、bias towards action——本质是别等别人批准。Lenny 共鸣（在 20 人创业公司学到这点）；Cat 接："很多人从小被教'做别人让你做的事就能拿好成绩'，你得 unlearn，改成'我认为对就做'"。
  • Bonus：最爱的 Claude thinking word："manifesting" → 详细——这些"thinking words"（Claude 思考时显示的词）"都在源码泄漏里泄出来了"；Cat 还"在我最喜欢的地方贴了个这个词的 sticker"。
• Q5 AGI 之后做什么 → 详细
  • "AGI 在社会里 diffuse 需要很长时间，所以最 immediate 的事其实是帮世界 bring along（跟上）"。non-serious 回答："之后大概会狂攀岩——搬到 Fontainebleau（枫丹白露，抱石圣地），住在一万块 boulder 中间爬"；读积压书单"目标一周一两本，现在大概只有 0.5 本"；学不懂的领域"对物理、机器人、硬件、航空航天一无所知，即使知道 AI 已经懂了，我还是 excited 去学"。 找她：Twitter @Catwu——"欢迎 tag、欢迎 DM，我会读我的所有 DM，不一定回每条，但我会全读"。最有用的反馈（反复强调）："告诉我们 Claude Code 和 Cowork 在哪里对你 not working well。我们感激大量正面反馈，但真正让我们 thrive 的是 edge case、error、那些我们能 reproduce 的具体任务——只要你能分享、我们能复现，这就是我们能在下一代模型、下一代 harness 里积极改进的东西。"近乎恳求："Please please share the problems you're having with us。"内部反馈管道（证明反馈真被处理）：有一个 'user love' 频道（贴 success story）和一个 'feedback' 频道（放问题，让更 broader 的团队 act on）；Cat 强调团队在 Twitter 上活跃响应"给团队带来很多 energy"，这些反馈真的进了内部流程。→ 详细 · → 详细