为什么 Claude 还当不了你的 PM——Ami Vora、Mike Krieger(Anthropic)

▲ 片头名字卡：Ami Vora（Chief Product Officer, Anthropic）、Mike Krieger（Anthropic Labs Lead, Anthropic）、Dan Shipper（Co-founder & CEO, Every）；右侧写着 A CONVERSATION WITH ANTHROPIC，2026 年 9 月 10 日录于 Lenny & Friends Summit。

• 场合与人物：Lenny and Friends Summit 的现场对谈。主持人是 Dan Shipper（Every 联合创始人兼 CEO），台上两位嘉宾是 Ami Vora（Anthropic 首席产品官）与 Mike Krieger（Anthropic Labs 负责人）。同场峰会的其他几段见 ep238、ep240、ep243，以及同批 255、256、257。→ 详细
• Dan 的问题：一年前大家被告知 AI 可能让 PM（产品经理）过时，现在的风向却是人人都得变成 PM。他觉得两位天天和模型打交道，对各种岗位往哪走多少有点预感，于是直接问：在 Anthropic，出色的 PM 是什么样？这个角色是在消失，还是在变？怎么变？→ 详细

• 没变的与在变的：Ami 说产品这份工作一直是在人的真实问题和能解决它的技术之间搭桥，这点没变。变的是换代速度：过去技术每 10 年、每 5 年变一次，现在感觉每两个月变一次，她坦白「作为一个人」很难适应。→ 详细
• 她的应对：人这一侧变得没那么快，所以一门心思扑在人的问题上，同时对技术保持新鲜的眼睛，把「过去解决这个问题管用的办法」基本都扔掉，带着对问题本身的了解重来一遍。→ 详细
• 像把时钟往回拨：她入行时（自嘲「恐龙还在地球上」）这份工作没有定义，你就是个通用的问题解决者，撞了墙再去问人。现在又回到角色边界模糊的状态，区别是撞墙时手边有了各种脚手架。→ 详细

• 来龙去脉：Mike 今年年初转成了 IC（个人贡献者，不带团队、自己动手干活），现在主要在造东西。最近一个项目快上线时，一位和 Ami 共事的 PM 负责人（他叫她 Cat）把他拉到一边：「Mike，我知道你爱动手做东西，这个项目进展不错……但这个项目我们真的需要一个 PM。」他的第一反应是：「我们需要 PM 吗？有 Claude 顶着呢。」对方坚持：「不，我们真的需要。」→ 详细
• 前后对比：PM 一加入，所有那些「胶水」和「连接组织」（把各方粘到一起的琐碎协调）、所有眼看要掉地上的事，全被接住了。Mike 说这种前后对比让他大开眼界，一周后专门给她发消息：「Cat，你百分之百是对的。」→ 详细
• 他列的那串问题：① Anthropic 的客户从 prosumer（专业个人用户）一直到非常大的企业，这一整拨人你都带上了吗？② 问题实时冒出来时，客户成功团队能不能把这些变化讲清楚，有人想过吗？③ 有人把 Safeguards（Anthropic 的安全防护团队）拉进来了吗？他强调这「非常、非常重要」。④ 大家是不是都还在正轨上？→ 详细
• 他的结论：没有人有无限的精力，有工具帮忙也一样。得有一个人（「随你怎么叫」）确保一切接得上、始终把终端用户的需求放在心上，并且让埋头苦干、完全进入 Claude 模式的 builder（亲手把东西做出来的人）不必跳出来去做另一件很不一样的事。因为现在跑得更快，这个角色对「运营上做到卓越」的要求比以前更高；它「绝对没有消失」，招人时这顶帽子正变得越来越重要。同批 256 的 Tamar 从大公司一侧讲了 PM 什么时候自己动手、什么时候退回去掌舵。→ 详细

• Dan 的玩笑式追问：「你当时怎么不直接让 Fable 来干？」他还调侃 Mike 手上想必有个外面还用不上的「Fable 7」（台上玩笑，不是产品信息），然后认真问：那个人到底在做什么，是你没法直接交给模型的？→ 详细
• Claude 已经在做的部分：Mike 说 Anthropic 内部基本跑在 Claude Tag（字幕误作 cloud tag，按上下文判断）上，也有很多由 Claude 提供的连接组织。它确实能抓到事情，会主动提醒你「组织另一个部门正在发生另一件事，你应该知道一下」（他提到是通过 slash search 找到的）。常驻 AI 同事这种形态另见 ep205。→ 详细
• 还做不了的部分：Mike 的原话是「我觉得 Claude 还不是一个召集人」。几周前他做过一场演讲，讲超强 AI 出现之后人的角色是什么，想了一堆角色原型，其中一个就是召集人（convenor）：还是得有人把 Claude 们和人聚到一起，把活儿干成。Claude 目前没有那种组织上的号召力，也没有排日程的能力。→ 详细
• 他预想的那个时刻：总有一天 Claude 会替他约一个会，他纳闷「这会是谁约的」，Claude 回答「是我约的，我觉得你们俩该聊聊」。Mike 说这事还没发生过，并半开玩笑地暗示这未必是能力问题。→ 详细

• 判断力：Ami 接着说，工具好用、造得快，只是把「有可能造出来的东西」的范围扩大了；你仍要凭相当有限的信息判断造什么。→ 详细
• 锲而不舍：想清楚之后要更锲而不舍地把它做成，因为岔路太多。她要的状态是：有想法、和将来的用户之间有反馈回路、知道人的问题是什么，就放手去干。同批 257 的 Robby Stein 把「PM 的手艺归根到底是判断」讲成了一整场。→ 详细

▲ Ami Vora 讲到自己花了很多年练代入用户心态、讨论按钮放哪的本事，如今没人再问这类问题。

• Dan 的铺垫：每次新模型出来，都像站在海边想「地平线那边是什么」，快进过去一看是一整片全新的地貌，既不是乌托邦也不可怕。他转述 Ami 备场时说的话：她花了几十年学会回答某几类问题，而这些问题现在已经不需要回答了。于是问：哪些技能没那么有用了？现在更倚重什么？怎么传导到团队和招人上？→ 详细
• 贬值的那项技能：Ami 说她花了非常长的时间琢磨怎么把自己放进用户的心态里、一个东西会怎么融入他们的生活、到底该做什么，原因只有一个：「做出一个东西并把它发布出去，成本太高了。」那时候的评审会真的在讨论按钮该放哪儿、交互模式、手指会落在手机的哪个位置、用户是在什么情境下把手机从口袋里掏出来的。她很努力地去练这种产品和设计掺在一起的能力，然后说：「我觉得再也不会有人问我这个问题了。」Dan 顺势补了句玩笑：这是道 Fable 的题。→ 详细
• 现在的做法：Ami 的原话是「现在其实更快的做法是直接做出三个版本，拿来试一试」，看哪个管用就用哪个。她直说：「我曾经引以为傲的一件事，其实已经没那么有用了。」→ 详细
• 难在身份认同：她把公司层面的「创新者的窘境」（在一件事上太擅长，明知该试别的也放不下）搬到了个人身上，承认自己有时也会想「我知道自己擅长什么，我就接着干这个吧」，哪怕另一种做法将来可能更重要。所以她鼓励每个人想一想：技术每两个月变一次，意味着你得把对「用这项技术干这份工作的自己」的认识也一并扔掉，去试点不一样的。→ 详细
• 她自己也没底：大多数时候她并不知道自己能不能干好。她以前从没在模型公司工作过，这不是她有专长的地方，每隔几个月就得跟自己说一遍：「行吧，那就试试这另一件事，看我能不能弄明白。」→ 详细

• 三样特质：Dan 问什么样的人做得好、Ami 自己又培养了什么。Ami 答：抬高自己对变化的承受上限（适应力）、判断力、锲而不舍。她还主张把这些事对团队公开讲，不然人人都以为只有自己在不停适应，会很孤独。→ 详细
• 别画精确地图：不确定时人会忍不住把一切规划死（到底会发生什么、做哪些产品、职业生涯怎么走）。Ami 说这是抓控制权的办法，却会把你挡在所有新东西的门外。她的替代做法是给混乱加个框（frame the chaos）：拿出来聊、让它变得安全、承认背后有情绪，因为神奇的东西和生产力恰恰在那儿。→ 详细

• DRI 与 bet lead：Mike 接话说，混乱可以有，但得有清晰的 DRI（直接负责人）最终拍板一件事值不值得追。Anthropic Labs 把项目叫 bet（押注），bet lead 负责说「加倍下注」还是「该收掉了」，以及哪个团队加人、哪个减人。→ 详细
• 越快越需要：他的说法是「我们大家是一起迷路的」，但得有个人握着笔，定下一步最重要的事，靠它降低风险、弄明白状况、学到东西。→ 详细

▲ Mike Krieger 在讲 agent 原生软件的演进时间线，此刻说的是第一阶段：AI 放在侧边栏或小窗口里。

• Dan 的问题：软件正从只有人用，走向人和 agent 都在用，有时是把活儿委派出去，有时是完全协作。什么该放进产品，什么该交给 agent，两者重叠在哪？→ 详细
• 第一个时代：Mike 拉了一条时间线。最早是「太好了，我们有了 AI，也许它该放在侧边栏或者一个迷你窗口里，你可以问它问题」。它和别的东西有点脱节，也许能帮你解决一些客服问题。之后是更深的集成，有一整块一整块的功能由 AI 驱动。→ 详细
• agent 原生：再往后是 agent 原生。Mike 说 Every「真的是把这件事写成了教科书」，他琢磨 agent 原生架构的那一整年，做法就是把 Every 写的那篇东西喂给模型、据此做成一个 skill（可复用的技能包）。那篇东西的核心一句是：「凡是人能做的，agent 也应该都能做。」真正做对的产品非常少，他承认 Anthropic 自己的很多产品也还没完全做对。可一旦做到，就会解锁涌现行为（没人专门设计、自己冒出来的能力）：agent 能把以前没拼到一起的东西拼起来，或者主动提出不一样的做法。同一对主持与嘉宾半年前专门聊过这个题目，见 ep41。→ 详细
• 他在想的下一阶段：界面本身也变成 agent 可以塑造的东西。可塑软件（malleable software）已经聊了好多年，他觉得现在才算真正在变成现实。→ 详细

• 例子本身：Mike 团队正想上线一个相当复杂的东西，至少有四条相互独立的工作线。落地办法是让 Claude 一边盯着各条线的进展，一边把界面也做出来——先是 TPM（技术项目经理），然后是整个团队，都靠这个界面了解项目里正在发生什么。→ 详细
• 酷在哪：不喜欢那种展示方式，你不会被绑死在它当初被定下来的做法上（不管是内部提效团队定的还是第三方定的），可以直接和 Claude 一起改。Mike 说过去一年 Anthropic 工作方式上最大的变化之一，就是大家打交道的软件里有那么多是由 Claude 搭建、维护、迭代的，而且一直在变。→ 详细
• 随之而来的新问题：谁能更新数据？只有人点来点去才行，还是 Claude 也在后台更新？数据的来源出处怎么追溯？→ 详细
• 边界在哪：他最受启发的方向是让几乎所有软件都这样运转，但仍然要有积木块、可预期性和设计系统，要给混乱加个框（此处字幕作 frame the cats，按上下文推断），不至于彻底乱套；在框里再针对具体的任务、项目、甚至用户，让软件既有个人感又格外好用。→ 详细

• Dan 替台下问：假如你不在 Anthropic，手上是一个已经做出规模的 SaaS 应用，要不要往里放一个 agent？要不要做成开放的、agent 原生的，好让 Claude 能进来？哪些该自己操心，哪些留给模型公司来接入？→ 详细
• 先做底层，不是先做界面：Mike 认为很大程度上是把合适的基础原语（primitives，可复用的底层积木）做进产品里，差不多像一层基础设施。他每次用新产品都会「戳一戳」：让它去做一件人能做、但得有人事先把架构想清楚才做得到的事。判断标准是所有操作是不是都走同一套共享管道，agent 也好、你做的不管哪种 REST API（程序之间互相调用的标准接口）也好，都从那儿过。有没有照这个思路想过，他说「是看得出来的」。→ 详细
• 他很体谅老产品：如果一个应用你已经做了 20 年，硬把这个东西外挂上去是很难的，这是很多公司正在走的一段路。但一旦底层做对了，剩下的问题就变成「可以随着时间慢慢演进」。→ 详细
• 具体的起步顺序：一开始可以先多做点侧边栏那类东西。不必现在就把整个界面推倒重来，也不必现在就做完全生成式的界面；可以先试一个更可塑的个人落地页，用的还是同一套基础原语，底下不用另造一整套新的基础设施。→ 详细
• 唯一的警告：东西要是硬生生外挂上去的，用的人看得出来，会感觉它不是产品原生的一部分。→ 详细

• Dan 的问题：有人只想用 Claude 聊聊天，有的是大型企业合同，没法一天之内拆掉人家整个界面说「现在它可塑了」。怎么一边推前沿，一边给出连贯体验，还带上不会第一天就试新东西的人？→ 详细
• Ami 的做法：她承认这很难，原则是在每个人所在的地方接住他们。现在还太早，模型在变，人们使用产品的方式也在变；所以探索期试一大堆，搞清楚什么行得通后，再整理给想要稳定完整的人。她是在讲究简洁、可靠、完全可预期的产品世界里长大的（这能养成用户的肌肉记忆和直觉），如今却鼓励团队多起脚射门，重叠重复没关系，打中 PMF（产品市场契合，即真有人要）后再收回来。→ 详细
• 她眼里的失败状态：一开始就按一套理论把产品约束死。原话是：「我宁可有五个相互重叠、各有各做法的产品，也不要一个约束过头、我们连让它真正去见市场的机会都没给过的产品。」→ 详细

▲ 主持人 Dan Shipper 在问：并行跑很多实验、有信号再收拢，怎样才不让团队困惑或泄气。

• Dan 的问题：Every 也这么干，整个行业都在同时跑很多并行实验、拿到信号再收拢。怎么让它不显得混乱？如果我在第三个做同一件事的团队里，可能挺打击士气的。→ 详细
• 第一条，别硬造 B 队：Mike 说当天早上内部刚聊过一个例子：两个可能的产品方向，一个有一支信念特别强的团队在追，另一个没有。这时候硬说「我们也该探索一下另外那个想法」，又没人真的喊着要做，就是「B 队」的感觉。他的经验是，指派一支团队去接一个他们自己不兴奋的产品领域，他从来没成功过，走一遍下来「产品肯定很烂」。反过来，有两三支团队各自都有让人兴奋的方向，就放手让它们探索。→ 详细
• 第二条，先补共用的底座：他们盘点过一遍（他说感觉像 6 个月前，其实可能才三个月）：当时 chat 和 Cowork 用的是不同的记忆系统、不同的 MCP（让模型接外部工具和数据的统一接口）、不同的文件存储方式。谁想在上面做实验都特别费劲；做出第三个东西、又和前面哪个都不共享记忆，它就是割裂的，「几乎从一开始就处在劣势」。→ 详细
• foundations 团队：所以有一支 foundations（基础）团队专门琢磨「不管你在我们产品的哪个地方，都应该能拿到你的记忆」。听着简单，掀开盖子才发现「因为这八个原因，它很复杂」。Mike 认为这件事值得放在另一支团队里做，不交给偏 Labs 式的前沿产品团队；这样实验哪怕彼此重叠，也让人感觉是互补的。→ 详细
• 第三条，Ami 主张直接说破：明说同时有三个不同的赌注确实会让人泄气，或者感觉其中一个从一开始就没被放在能成功的位置上。「没关系，我们就活在这样一个世界里。」然后请大家一起走这段路：我们不知道答案，也不觉得有谁知道；大家在同一支队伍里，不管哪个跑通了都从里面学东西。她说把这类话大声说出来就很重要，因为每个人都在黑暗里摸索。→ 详细

• 五个老问题：Dan 问看什么信号。Ami 答其中很大一部分就是常规的产品市场契合：大家用不用？喜不喜欢？会不会回来？会不会跟别人聊起它？有没有从中得到价值？→ 详细
• 回到原点：产品的目标一直没变，就是解决问题。它是不是真的解决了一个问题，而且大家用得上、用得轻松、用着感觉也好。→ 详细

• Dan 提出的难处：有时候一个东西看着不行，新模型一出来它就真的好用了。你不想太早把它扔掉，可也不想超前太多，怎么办？→ 详细
• Mike 的例子：Labs 有时会把项目先搁着。2024 年他们做出了 Anthropic 内部第一个 computer use（让模型直接操作电脑）产品，「特别烂」，因为模型还没到那个水平。最初的设想是：做自动化不行，没准适合教学。于是你问它「这个特别复杂的操作在 Photoshop 里怎么做」，它确实能做到，但走的是很早期的路数：试一下，成了吗？没成，关掉重来。大概 20 分钟后它说「我做完了」，而你的反应是「我什么也没学到」。结论是它既不适合自动化，也不适合教学。→ 详细
• 搁着之后怎么办：他们没扔，而是让它一直跑在一个 eval harness（评测框架，一套能自动重跑并打分的测试环境）里，每出一个新模型就重试一遍。Mike 说他们之所以知道 3.7 在 computer use 上是一次飞跃，就是眼看着它突然起来了，再去翻 transcript（运行记录），发现「它成功的次数已经比失败的多了」，这才确认是个实打实的转折点。→ 详细
• 什么算赢：在 Labs，如果一个项目做到的全部事情只是证明了模型还没准备好，但你能把这一点外化成一个 eval，或者和研究团队建立起连接，就算一次胜利。因为再过两到六个月就能回头再看它。他补了一句：你得早点动手做，才有可能拥有那种直觉。→ 详细
• Dan 的命名：不这么做的后果，他叫能力盲区（capability blind）：你试过一样东西，之后再也不试，也没做个 eval，就认定「模型永远干不了这个」。结果过了 3 个月出个新模型，它进步的方式是你怎么也想不到的。他现场让用过 Fable 的人举手（很多），再问 Astra（少一些），然后说他常遇到有人讲「它干不了这个」，一问才知道对方用的是「Sonnet 4.5 还是什么的」，没用最新模型。→ 详细
• Ami 的呼应：这也是「愿意把一切都扔掉」这么重要的原因，虽然很难；不这样的话，你就会以为上一次发生的事会永远成立。→ 详细

• Dan 的问题：他看到 Anthropic 在解这道题，OpenAI 也在发生，Every 自己也碰到过：并行实验里有一个真跑通了，就得推回主产品。做成 tab，会有一堆运作方式略有不同的 tab，「挺难看的」；做成独立 app，又永远不合并。他觉得还没有谁得出标准答案。→ 详细
• Ami 的回答：她先开玩笑说「我不知道你在说什么」，随后承认还没完全想明白。方向是回到基础原语：用户期待走到一个东西跟前不用想太多，而现在很容易把认知负担转嫁给用户，说「这儿有几个工具，你自己挑吧」。所以要让系统了解你、界面随时触手可及，并且边看大家的反应边调整。→ 详细
• Mike 的 Instagram 经验：tab 的使用存在很强的幂律（少数入口占掉绝大部分使用量）。主 feed 大概占 80% 的使用量；把 Explore 做得更好，也许能从 10% 涨到 15%，但主 feed 才是用户落地的地方。所以永远先问主 tab 是什么、怎么把它做得很棒，再让它成为通往下游体验的入口。→ 详细
• 一半的工作是说不：对「侧边栏里再加一个东西」「再加一个 tab」说不，同时想清楚验证过后它能不能被并进来，又别太早把它砍掉。Mike 说事情变化这么快的时候，这就是「产品开发的全部艺术所在」。→ 详细

• Ami 的希望：大家觉得自己能做的事多得多：想怎么造就直接去造，想要答案随时能拿到，可以去创业；会有多得多的小团队和被赋能的单枪匹马的人。她的理由是 builder 会把影响力放大给更多人，那些人永远不会直接用这些工具，却能从动手造东西的人那里受益。→ 详细
• Mike 的希望：补上模型的能力和大多数人实际拿它们来做的事之间的那道差距。他强调这不是用户的错，「责任在我们」；这事在 24 年就很难，去年更难，现在越来越难。补上之后，不再只有最痴迷的那位软件工程师才有一套跑得起来的多 agent 配置，并行做一堆调研的人、想把自己生意打理好的人也有。难点是带着他们看懂那些活动部件、在对的节点上过问一下、做长周期的工作，却不让人觉得自己被架空。他说如果成功，一年后会离这个更近一些。→ 详细