Anthropic 产品负责人 Kat Woo 的深度访谈揭示了 AI 时代产品管理的全新法则。从「缩短出货周期」取代路线图规划，到「Product Taste」成为稀缺技能，再到如何用「团队原则+每周指标」替代传统 PRD，24 条实战经验直击 AI 产品经理的核心痛点。本文提炼的不仅是方法论，更是对当下产品思维的一次彻底重构。

上周末刷到 Lenny’s Podcast 更新了一期新访谈，嘉宾是 Anthropic 的 Claude Coding 产品负责人 Kat Woo

我本来只想随便听两分钟就去忙别的，结果一个半小时听完了，中间暂停了七八次做笔记

这期含金量太高了

Kat 不是那种站在台上讲「我们的愿景是让世界更美好」的产品经理。她分享的几乎全是实操层面的东西

Anthropic 内部怎么做到隔一天就发一个新功能、PM 角色到底在发生什么变化、她面了上百个 PM 候选人之后为什么觉得大部分人方向都搞错了

我听完把笔记整理了一遍，发现里面的内容对这3类人特别有价值。一类是正在做 AI 产品的产品经理，不管是在职的、待业的还是准备转行的。一类是 AI Native 方向的创业者。还有一类是自己动手搞产品的个人开发者

可能有些想法还不成熟，但我已经尽量把最有信息量的部分一条条拎出来了，总共 24 条

坦率的讲这篇更像是我的学习笔记，如果刚好对你有启发，那就赚到了

1. PM 最值钱的工作，从「对齐路线图」变成了「缩短出货周期」

Kat 说了一个数据，让我印象特别深。Anthropic 很多产品功能的交付周期，已经从六个月缩到一个月，有时候缩到一周，甚至一天

以前 PM 的核心工作是规划 6 到 12 个月的路线图，跟各种合作伙伴团队对齐节奏，确保大家划水的频率一致。但现在模型能力几个月就跃迁一次，你辛辛苦苦对齐了半年的路线图，可能下个月模型一升级全作废了

所以 Kat 的判断是，现在 PM 最大的价值就一件事，怎么把「从有一个想法到产品到用户手里」这段时间压到最短

2. Product Taste 是当下最稀缺的技能

这个观点 Kat 反复提了好几次，代码越来越便宜，决定「写什么」比「怎么写」值钱一百倍

Anthropic 招 PM 几乎只看一件事，你有没有 product taste。具体表现是什么呢，能不能从成千上万个 GitHub issue 里判断出哪些值得做、用什么方式做，能不能定义出一个功能最让人愉悦的体验方式

这个能力跟你有没有技术背景关系不大，跟你有没有长期泡在产品里、反复琢磨过「好的产品到底好在哪」关系很大

我自己的感受是，product taste 这个东西没法速成。它是长期使用好产品、拆解好产品之后，慢慢在脑子里长出来的一种直觉

3. PM 需要有工程背景，但这个优势窗口可能只剩几个月

Kat 自己是工程师出身，她团队里几乎所有 PM 都写过代码或者正在写代码。她的设计师以前也是前端工程师

原因很实际，有工程背景你才能判断一个功能「应该有多难」，这直接影响你的优先级决策。如果一个东西很简单，花一小时就做了，那就别讨论了直接做。如果很难，你得提前知道这个成本

但 Kat 很诚实地加了一句，这个优势可能只持续几个月。因为模型能力跃迁太快，每过几个月有价值的技能组合就会发生变化，她不确定工程背景还能保持多久的竞争优势

我觉得这个判断反而让她更可信，至少她不是在卖「学编程就能逆袭」的焦虑

4. 她面了上百个 PM，觉得大部分人的方向是错的

这个点让我挺震惊的。Kat 说她面了上百个 PM 候选人，发现大部分人还在用传统 PM 的思维方式去准备面试和做事，强调跨团队对齐、写详细 PRD、做长期规划

但 AI Native 产品需要的完全不是这些

她觉得真正重要的能力是，你能不能快速迭代，你能不能容忍不完美先上线再说，你会不会做 eval，你能不能快速拿到用户反馈然后修正方向

如果你正在找 AI PM 的工作，或者正在做 AI 产品的 PM，这一条值得认真想想。你现在每天花时间最多的工作，是在缩短出货周期，还是在写没人看的 PRD？？？

说到出货速度，顺着这个话题聊聊 Anthropic 内部到底是怎么做到那么快的

5. 支撑极速发货的三件事

我总结了一下，Kat 提到了三个关键机制

PM 锁定清晰目标，不是「我们来做一个更好的功能」这种废话，而是非常具体的「我们的关键用户是专业开发者，要解决的问题是权限提示太多导致疲劳，目标是让企业开发者安全地做到零权限提示」。这种精确度直接排除掉了一大堆不该做的方案

Research Preview 机制，几乎所有功能先以「研究预览」形式上线，明确告诉用户这是早期产品、这只是一个想法、可能不会永久支持。这一招大幅降低了发布门槛，不用等到完美才敢发

紧密的跨职能流水线，工程师觉得功能 ready 了发到内部 launch room，文档团队、PMM、DevRel 第二天就能把市场推广素材搞定。PM 的工作是搭建这条流水线，不是自己跑每一环

我觉得这三件事里面，Research Preview 那个对很多团队来说是最容易抄的。你不需要等到产品完美才发，先用「Beta」或者「实验性功能」的标签上线，让真实用户帮你验证

6. 用「团队原则 + 每周指标」替代传统 PRD

Anthropic 不怎么写 PRD。对你没听错

Kat 说只有特别模糊或者需要大量基础设施投入的项目才会写 PRD，日常功能开发基本不写

取而代之的是两件事。每周全团队做 metrics readout，让每个人都深度理解业务全貌，知道关键目标是什么、趋势怎么样、驱动因素是什么。然后维护一份团队原则清单，写明关键用户是谁、为什么是他们、我们愿意做哪些取舍

目的只有一个，让每个工程师都能自主决策，不需要等 PM 来拍板

想想这个逻辑。。。如果团队里每个人都清楚地知道「我们到底在为谁做产品」以及「什么事比什么事更重要」，那大部分决策根本不需要开会

7. 容忍不完美，但要能在混乱中保持微笑

Kat 说了一句话让我印象很深，她说以前上线一个有 bug 的功能会让她整夜睡不着，但现在她能接受了

不是因为她不在乎了，是因为她知道反馈来得很快，下个版本就能修

她说 Anthropic 招人的时候特别看重一种气质，就是那种「看到一个很难的挑战，先笑一下，然后说我来搞定它」的人。经历过行业起伏、知道怎么管理自己能量、能残酷地做优先级排序的人

这个观点我是真的被打动了。在 AI 这个领域，如果你对每一个不完美都感到焦虑，你确实会 burn out。这不是粗心，是战略层面的取舍

8. 统一使命是决策加速器，不是墙上的口号

Anthropic 的使命是「为全人类带来安全的 AGI」

听起来像每家科技公司都会写的东西对吧。但 Kat 说了一个细节让我觉得他们是真的在用这个东西做决策

当两个优先级冲突的时候，团队会问「哪个对 Anthropic 的使命更重要」，然后全员站到决策背后，没有扯皮

Kat 举了一个极端的例子，如果 Claude Code 失败了但 Anthropic 作为公司成功了，她说她会非常高兴。整个团队都愿意做出这种取舍

你敢信？？？一个产品负责人说自己的产品失败了她也开心，只要公司的使命达成了

我觉得这才是使命真正起作用的样子。它不是挂在会议室墙上的装饰，是每天都在影响优先级排序的决策工具

9. 聚焦比什么都重要

这一条跟上一条是配套的。Kat 隐晦地对比了一下竞争对手，有些公司既做社交网络又做信息流又做这做那，Anthropic 明确不做偏离使命的产品

这种聚焦让他们可以把所有资源集中在最重要的事上。包括那个让很多开发者不高兴的 Open Claw 决定，限制第三方用订阅额度调用 Claude，也是因为要优先保障第一方产品和 API 的体验

聚焦总是意味着某些人会不满意，但不聚焦意味着所有人都会不满意

顺着这个聊，当你选择极速迭代和聚焦的时候，你必然要付出一些代价。Kat 也很坦诚地聊了这些

10. 快速发布的代价是产品一致性

Kat 直接承认了，快速发布功能的成本是产品一致性下降

有时候团队内部喜欢两种形态的功能，他们就两个都上线，让用户投票选哪个好。结果就是新用户进来完全懵了，不知道该用哪个功能完成什么任务

这也是他们后来做了 /power up 这个内建教学功能的原因。一开始他们觉得产品应该足够直观不需要教程，后来发现不行，100 个功能里用户至少得知道最重要的 10 个是哪些

我觉得这对个人开发者特别有参考价值。你发了很多功能没关系，但你得帮用户做减法，告诉他们「你只需要关注这几个就够了」

11. 模型会吃掉你的产品 harness

这一条是整个访谈里我觉得最精彩的产品洞察之一

Kat 说每次新模型发布，团队会做一件事，把整个 system prompt 从头到尾读一遍，然后问「这个部分模型还需要我们提醒吗」，不需要就删掉

她举了一个经典案例。早期 Claude Code 做大重构时会漏改 call site，比如要改 20 个地方它改了 5 个就停了。团队就给它加了一个 to-do list 功能，强制它逐一完成，还加了提示说「你不能在完成 to-do list 所有项目之前结束任务」

到了 Opus 4 之后呢？模型自己就会完整执行了，根本不需要强制提醒。那个 to-do list 从「必须有的功能」变成了「可选的 UI 展示」

这意味着什么。。。做 AI 产品不是只做加法的，你还得持续做减法。你今天加的每一个 feature 都有可能在下一代模型面前变成多余的东西

这个思路跟传统产品开发完全不一样。传统产品的功能上了就不太会撤，但 AI 产品的很多功能天然就是「拐杖」，模型聪明了就不需要了

12. 提前为还做不到的事建产品

这一条跟上一条是一体两面

Kat 的建议是，提前构建当前模型还做不好的功能原型，这样新模型一出来就能直接换进去测试

她们的 Code Review 功能就是这么做的。试了好几代模型都觉得不够好、没敢正式发。但因为一直有原型在跑，到了 Opus 4.5 和 4.6 的时候，一测发现准确率已经高到团队可以依赖它来审 PR 了，于是迅速上线

「超前半步建原型，等模型追上来」这个策略我觉得非常适合资源有限的小团队。你不需要等模型完美了再动手，你可以先把产品框架搭好，等着模型能力填进去

13. 不要过度 AGI pilled

这一条 Kat 用了一个特别有意思的说法，她说「很难做到恰到好处的 AGI pilled」

什么意思呢。每个做 AI 产品的人都能想象一个未来，模型超级聪明，产品只需要一个文本框，用户说一句话模型就全搞定了。为那个未来做产品很容易，因为你不需要设计什么复杂交互

但难的是当下

当下这一代模型有很多能力，也有很多短板。PM 最值钱的技能就是搞清楚，在当前模型的能力边界下，怎么设计产品才能引出模型的最大能力，怎么帮用户走上 golden path，怎么让用户利用模型的长处同时绕开它的弱点

Kat 说这个能力非常稀缺。我觉得她说的是事实，因为大部分人要么在为当下已经过时的能力做产品，要么在为还没到来的超级模型做产品，很少有人真的在「当前模型能力的边界上」做精确设计

说到怎么理解模型的能力边界，Kat 聊了很多关于 eval 和模型感知的方法

14. Eval 是被严重低估的 PM 技能

Kat 说你不需要写几百个 eval，10 个好的 eval 就能帮团队量化目标和进展

她自己在功能定义比较模糊的时候会亲自跳进去写 eval，产出的东西大概是「这 5 个 eval 怎么跑、哪些过了哪些没过、什么 prompt 调整提升了成功率」

如果产品管理的未来真的是定义「成功长什么样」，那 eval 就是把这个定义变成可量化标准的工具。它不是工程师的事，是 PM 的事

15. 找到你最信任的 5 个用户，他们是你的「人肉 eval」

Kat 说了一个很实际的观点，不是所有用户反馈都同等有价值

有一小群人特别擅长表达「是什么让某个模型或者某个 model + harness 的组合好用」，他们给的反馈比大多数人精准得多

Kat 的做法是找到这样的 5 个人，建立信任关系，每次有新模型或者新功能就第一时间找他们测，快速拿到高质量反馈

这个方法不需要你是 Anthropic 才能用。任何做产品的人都可以在自己的用户里找到那几个「特别会表达感受」的核心测试者，然后把他们当成最重要的信号源

16. 让模型反思自己的行为，是一种被低估的 debug 方法

这个技巧我觉得特别有意思

Kat 说当她发现模型做了意外的事情，比如改了前端代码但没有真正去看 UI 效果，她会直接问模型「你为什么这样做」

模型有时候会说「system prompt 里有个地方让我困惑了」，或者「我把验证工作委托给了子 agent 但没检查它有没有做」，甚至会说「我没意识到前端验证是这个任务的一部分」

这种对话能暴露出 harness 设计的漏洞。你以为是模型笨，其实可能是你的指令写得有歧义

我觉得这对任何在写 prompt 或者搭 agent 的人都有用。下次模型的输出不符合预期，别急着改 prompt，先问它「你为什么这么做」，答案可能会让你意外

17. Cowork 的定位，所有输出不是代码的工作

Kat 对几个产品的定位划分得非常清晰。如果你的输出是代码，用 Claude Code。如果你的输出不是代码，用 Cowork

Cowork 覆盖的场景包括做 PPT、写文档、处理邮件、管理客户 brief、从 Slack 0 到 inbox 0 这些事

但她强调了一个前提，你必须先把所有相关数据源连上。比如你的知识库，公司项目背景，个人背景，Cowork 有了完整上下文才能真正发挥作用。如果你不给它上下文，它就只是一个比较聪明的聊天机器人

18. Cowork 实战，一小时生成 20 页会议演讲 PPT

Kat 自己的一个使用案例让我印象深刻

她要为一个会议准备演讲 PPT，把叙事主线、PMM 的建议稿、自己不满意的旧草稿全丢给了 Cowork。Cowork 跑了大概一个小时，自己去翻 Twitter 看团队发了什么、翻内部找发布记录、翻 demo 频道看成功案例，然后综合出了一个 20 页的 deck

因为 Cowork 有 Anthropic 内部设计系统的权限，出来的东西视觉上看起来就像设计师做的

但这不意味着 PM 就不需要了。Kat 的角色是做最终的内容取舍，决定每个板块讲什么、用哪个 demo 最有说服力

她说了一句我觉得很精准的话，Claude 是一个很好的头脑风暴伙伴，它能快速综合大量信息并呈现所有可能性，但 PM 的角色仍然是做最终决定

说到这个，Kat 还给了几条特别实在的职业建议，我觉得不管你是什么角色都值得听听

19. 别做 demo，做你每天真正在用的东西

Kat 观察到很多人在「玩」AI，做原型、搞 demo、one-shot 一些花哨的东西，然后发到社交媒体上秀一下就结束了

但她觉得这样学不到深层经验

她的建议是，把精力放在构建你每天真正在用的应用上。只有持续使用，你才能发现模型的真正边界在哪，才能积累那种「到底什么 work 什么不 work」的体感

想想也是，一个你用了一次就丢掉的原型 app，和一个你连续用了三个月的自动化工具，给你的认知积累完全不在一个量级

20. 自动化做到 95% 等于没做

这一条 Kat 说得很直接，如果一个自动化不是 100% 可靠的，那它就不是真正的自动化

她观察到大量用户把某个自动化做到 90-95% 的准确率就放弃了，因为最后那 5-10% 太难搞了，花的时间比手动做还多

但 Kat 的观点是，你应该投入那个时间。给它喂反馈、教它你的偏好、让它学习改进，一直到 100%。只有到了 100%，你才能真正信任它、真正放手

95% 的可靠度意味着你每 20 次里有一次要自己去收拾残局。那你到底是在用工具还是在伺候工具？

21. 定制化有个陷阱，别掉进去

Kat 观察到有两种极端的人

一种是从来不定制、从来不搞自动化的，拿到工具原封不动地用。另一种是沉迷于定制，疯狂加 skill、加 MCP、优化 workflow，搞了一大堆东西，反而偏离了核心目标

她的判断是，简单的 setup 往往效果更好

我在社媒上上也经常看到这类帖子，有人秀自己多么复杂的开发环境配置，但你问他实际用这些东西做了什么产品，他说不出来。。。

工具是为了做事的，不是为了搭着好看的

22. 常识、情商和利益相关者管理，模型还差得远

Kat 承认模型现在还不擅长判断谁是利益相关者、他们之间关系怎么样、用什么方式沟通能让他们买单

任何一个产品发布都有上千个细节要处理，其中很多不是技术问题，是人的问题。谁需要提前知会、用什么语气说、在什么场合沟通，这些隐性的 EQ 类知识目前还是人类的领地

当然 Kat 也说了，她希望模型在这方面变得更好，她觉得未来会的。但至少现在，这是 PM 不可替代的价值

23. 2024 是 Chat，2025 是 Action，这是一个分水岭

Kat 用了一个很清晰的框架来描述产品范式的转变

2024 年那一代 AI 产品是聊天型的，你跟模型对话，它给你建议或者生成内容

Claude Code 这一代产品是行动型的，模型不只是告诉你怎么做，它替你做了

Kat 说用户真正的 aha moment 就是在这个切换发生的时候。当你发现 agent 可以代替你执行任务、而不只是给你出主意，那种感觉是完全不同的

这个判断如果是对的，那对所有做 AI 产品的人来说，方向就很明确了。不要只做「建议者」，要做「执行者」

24. 产品演进的终局路径，从单任务到 50-100 个 agent 同时跑

最后这一条是关于未来的

Kat 描述了一条很清晰的演进路线。先是单个任务做到可靠，然后是多任务并行（用户同时开 6 个 session），最终是同时跑 50 甚至 100 个 agent

到了那个阶段，任务肯定不是在本地跑的了，会是远程执行。产品要解决的问题变成了，你作为一个人，怎么知道该看哪个任务的结果？agent 怎么自验证自己的工作？怎么从你的反馈中学习，确保同样的错误不犯第二次？

这不是科幻，这是 Anthropic 正在建的东西

如果你是创业者或者产品经理，值得认真想一下，当用户可以同时指挥 100 个 agent 工作的时候，你的产品应该长什么样

说了 24 条，回头看其实有一条暗线贯穿始终

这个暗线就是，AI 产品的一切都在加速，模型能力在加速，用户预期在加速，功能的发布和淘汰都在加速。在这种环境里，以前那些让产品经理安身立命的东西，写详尽的 PRD、做精美的路线图、跨团队对齐半年的排期，都在变得越来越不值钱

值钱的变成了另外一些东西。product taste、快速出货的能力、理解当下模型能力边界的直觉、容忍不完美的心态、以及最根本的，决定「我们到底该做什么」的判断力

我也不知道这些建议能帮到多少人，但我看完这个访谈确实觉得学到了不少。至少它让我重新想了一下，自己每天花最多时间做的事情，到底是在缩短出货周期，还是在做一些让自己看起来很忙但其实不创造价值的工作

这个问题，可能值得每个做产品的人，隔一段时间就问自己一次

愿我们永远对世界保持好奇