AI时代的产品经理角色正在经历深刻变革。Anthropic产品负责人Cat Wu揭示了一个关键趋势：当开发周期从6个月缩短到1天时，PM的核心价值已从排期管理转向目标设定、快速发布机制设计和跨职能协作优化。本文将深入解析AI时代PM必备的三项新技能，以及如何通过研究预览标签、Evals评测等工具在高速迭代中保持竞争力。
前几天看了 Lenny’s Podcast 这期访谈，嘉宾是 Anthropic Claude Code 和 Cowork 的产品负责人 Cat Wu。她有工程师背景，做过 VC，亲手带出了 Claude Code 这款产品，也一直在面试来自全行业的 PM 候选人。她给出了一个非常清醒的判断：AI 没有消灭 PM，但它彻底重写了 PM 的价值所在。这篇文章逐一拆解她的核心观点，并把每一个方法论都讲清楚。
Cat 在访谈中说了一个非常直白的数字：Anthropic 内部，很多产品功能的开发周期已经从以前的 6 个月压缩到了 1 个月，再到最短一天。她是这么说的：
“The timelines for a lot of our product features have gone down from 6 months to one month and sometimes to one week or even one day.” “我们很多产品功能的开发周期已经从 6 个月缩短到 1 个月，有时甚至缩短到 1 周或 1 天。”—— Cat Wu，访谈原文
这不是夸张。Anthropic 的工程师大量使用 Claude Code 来写代码、跑测试、修 bug，一个工程师有想法，一周之内就能推到用户手里。这种速度带来的直接结果是：传统 PM 那套”多季度路线图对齐”的工作方式已经失效。
在以前，代码贵，开发周期长，PM 的核心价值在于”多方对齐”——你要提前很久规划好路线图，协调好各个合作团队，避免研发浪费。但当功能本身可以一周甚至一天交付时，那套事先对齐机制就变成了阻力，而不是助力。
对 PM 来说，这不是坏消息，而是一次职能的重新定义。
很多人一听到”快速迭代”就以为 PM 被边缘化了。
Cat 的回答恰恰相反——她说在这种高速环境里，PM 的工作比以前更重要，只不过重心从”管理排期”彻底转向了另外三件事。
Cat 说，AI 模型天然是”通用的”，这反而带来一个大问题：如果不设边界，团队完全不知道在为谁服务、在解决什么问题。她举了一个很具体的例子：
“我们的关键用户是专业开发者，当前要解决的核心问题是权限弹窗太多让人很疲惫——我们的目标是帮助企业级专业开发者安全地把权限弹窗降到零。”—— Cat Wu，谈 PM 如何设定清晰目标
这句话看起来简单，但它的价值在于：它直接排除了大量错误方向。“降低权限弹窗”有几十种做法，明确”目标用户是企业级专业开发者、目标是零权限弹窗”之后，那些适合消费者产品、或者只能降到 50% 的方案都可以直接不看。目标越清晰，团队决策越快，迭代越快。
Cat 说，优秀的 PM 衡量自己的核心指标就一条：缩短从想法到产品落到用户手里的时间。
团队速度快了，但有一个隐性阻力常常被忽视：担心功能不够完善就发出去会砸口碑。这种顾虑会让工程师和 PM 迟迟不敢发布，把速度优势全部抵消掉。
Anthropic 用一个非常实用的机制来破解这个问题——Research Preview（研究预览标签）。
概念解释
Research Preview 是什么？ 研究预览是什么？
这是 Anthropic 给”未完成功能”打的一个公开标签。意思是：这个功能我们已经上线了，但它还处于探索阶段，可能会变化，也可能不会永久保留。
为什么有效？当用户看到”Research Preview”这个标签，预期会自动调低——他们理解这是”早期试探”，而不是正式产品，因此对粗糙的地方容忍度更高，也更愿意提供真实反馈。
对团队的好处是什么？Cat 原话：”它降低了发布的承诺感——我们可以一两周之内把东西推出去，而不需要等到完美。”团队不再因为”还不完美”而卡在发布门槛前，心理障碍解除了，速度自然就上来了。
类似机制你可能见过的：Beta 版、Early Access、Experimental 功能——本质上都是同一套逻辑：用命名来管理外部预期，用标签来给内部团队松绑。
Research Preview 不是一个技术决策，是一个产品发布机制。PM 的工作是在团队内部建立这套命名体系和发布规范，让每个工程师都知道：打上这个标签，我就可以在一周内发出去，而不需要等到完美。
Cat 说的第三件事，是 PM 最容易被忽视但最有杠杆的工作——把跨职能协作流程提前设计好，变成一条随时可以触发的通道。
她具体描述了 Anthropic 的做法：工程师有一个随时可以触发的”Evergreen 发布频道”。当功能完成内部测试（dog fooding），工程师直接在这个频道发一条消息，负责文档的 Sarah、负责市场推广的 Alex、负责开发者关系的 Taryn 和 Lydia，会在第二天就把对应的推广文案和文档准备好。
“因为有了这套紧密的流程，任何工程师发布功能的摩擦力都变得很低。而建立这套流程，正是 PM 应该做的事。”—— Cat Wu
这套机制的核心逻辑是：不要在每次发布时临时拉人开会对齐，而是提前把对齐固化成一套流程。PM 的价值，是设计出这套流程，让团队即使没有 PM 参与每一次决策，也能自主、快速地把东西推出去。
这是访谈里 Lenny 直接追问的问题，Cat 的回答分了两层：
Cat 说，Anthropic 团队维护两份文件来替代传统 PRD 的功能：替代PRD的两个工具
每周全团队 Metrics Readout（指标复盘）
每周，整个团队一起看一遍关键指标：核心目标在哪里、现在的趋势如何、影响指标的因子是什么。Cat 说这样做的目的是让团队里每个人都深度理解业务的每一个面向——而不只是 PM 知道目标，工程师只管执行。
当所有人都真正理解指标时，他们就能在没有 PM 拍板的情况下，自己判断一个决策是对还是错。这是 Anthropic 能够高速运转的关键基础之一。
Team Principles（团队原则文档）
这是一份写明”我们的核心用户是谁、为什么是他们、我们愿意为此放弃什么”的文档。Cat 强调，这份文档的价值不在于规定每个人怎么做，而在于让每个人理解决策背后的逻辑。
当工程师遇到一个 edge case 需要决策时，他不需要等 PM 来拍板——因为他看过 Team Principles，知道团队更在意哪些用户、更愿意做哪些权衡。这就是”去中心化决策”的底层设施。
这两个工具共同解决的是同一个问题：让团队不依赖PM也能做出正确决策。PRD 的本质是对齐工具，当指标和原则文档能够更高效地完成对齐时，PRD 就不再是必需品。
Cat 说，有两种情况依然会写：
功能特别模糊的时候：写一页纸，把目标、最理想的使用场景、当前的失败模式写清楚——这是”对齐用”的一页纸，不是 10 页的详细需求文档。
重大基础设施项目：开发周期本来就要好几个月的，写 PRD 的成本是合理的。
所以结论不是”不写 PRD 了”，而是：PRD 变成了一个工具，只在真正需要它的地方用，不再是默认流程。
Cat 说她在面试成百上千个 PM 候选人，反复发现同一个问题：大多数人还在用旧模式思考 PM 的价值。他们觉得 PM 的核心价值是”沟通协调”和”管理信息流”，但这恰恰是 AI 最容易辅助甚至替代的部分。
Cat 说：”As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.”（当代码越来越便宜，决定写什么变得越来越值钱。） Cat 说： “随着编写代码的成本变得越来越低，决定写什么就变得更有价值了。” （当代码越来越便宜时，决定写什么变得越来越值钱。）
产品品味，说白了就是”判断力”——在成千上万个 GitHub issue、用户反馈、内部提案面前，知道哪个值得做、哪个值得放弃，知道最合适的 UX 是什么样子、怎么做最让用户愉悦。
这种判断力无法通过”多看需求文档”训练出来。Cat 说，Anthropic 几乎所有的 PM 都有工程师背景，连设计师也曾经写过前端代码。这不是巧合，而是因为：只有真正理解“做某件事有多难”，才能做出好的优先级判断。
Cat 提到了一个更进阶、更被她看重的能力——在模型能力高度不确定的前提下，判断一个月后产品应该是什么样子。
“最难的技能是：在模型能力和用户行为都充满不确定性的情况下，能够设定一个一个月后的方向，并稳步执行，同时在模型能力超出或低于预期时灵活调整。”—— Cat Wu
为什么这很难？因为 AI 原生产品有一个独特的挑战：模型能力每隔几个月就会有一次跳跃，这意味着之前做不到的功能突然可以做了，而之前需要复杂交互的场景可能直接被一句话替代。
Cat 说，很多人犯的错误是”过度 AGI Pilled”——他们把产品设计到了一个假想中超强模型的能力水平，而忽略了当前模型的真实能力。正确的做法是：在当前模型的能力边界内，把它的潜力发挥到最大，同时保持足够的灵活性，随时迎接能力跳跃。
Cat 给出了三个非常具体的方法，不是大道理，是实操的。
Cat 说她特别喜欢做一件事：当她发现模型做了一个出乎意料的行为，她会直接问模型：”你为什么这样做？”
她举了一个例子：Claude Code 有时候会修改前端代码、跑完测试，但并没有实际用 UI 验证效果。她问模型，模型会说：”系统提示里有一些让我困惑的地方，我不确定 UI 验证是不是任务的一部分，所以就没做。”
这个反馈直接帮她锁定了系统提示的问题，可以立刻修复。问模型为什么，是发现产品 bug 最快的 debug 路径。这种使用方式，需要你对模型行为有足够深的理解，而这只能通过大量使用来积累。
Cat 说，用户反馈的质量差异非常大。大多数用户的反馈是”我觉得这个不好用”，但有少数人能精确地描述：”这个模型在遇到 X 类情况时会失去方向感，具体表现是……”
这种高质量反馈是产品迭代最宝贵的输入。她的做法是：从所有用户里找到那 5 个你最信任的人，把他们的判断当作方向性参考。不是忽视其他人，而是在需要快速决策时，优先听这几个人说什么。
这套逻辑对普通 PM 也适用：你的用户里，一定有那么几个人对你的产品有最清晰的认知。找到他们，建立稳定的沟通渠道，比做 100 份问卷更有价值。
这是 Cat 专门强调、也是整个访谈最让我眼前一亮的部分。
概念解释
Evals 是什么？
Eval（Evaluation）是 AI 产品里的”评测用例”——你写一组具体的测试场景，明确定义什么输出算”成功”，让模型跑一遍，看看哪些过了、哪些没过。
比如，你要测试”Claude Code 能不能正确处理有歧义的需求描述”，你可以写出 10 个不同类型的歧义 prompt，跑一遍，看成功率、看失败模式，从而精确知道这个能力目前在哪里。
为什么说它是 AIPM的基本功？传统 PM 靠”用户访谈 + A/B 测试”来验证产品方向。AI 产品经理需要多一个工具：evals。因为 AI 的输出质量是概率性的，你没有办法靠感觉判断”这个功能的模型表现到底好不好”——你需要数据，而 evals 就是产生这个数据的方式。
Cat 说了一个非常接地气的数字：不需要几百个，只要写出 10 个高质量的 evals，就足以帮团队厘清产品方向，量化目标，并知道距离目标还差多远。
“Evals 是一个被低估的东西，应该有更多 PM、更多工程师来做这件事。它帮助团队量化目标是什么，以及他们现在在哪里，还缺什么。”—— Cat Wu
她自己的做法是：当遇到一个功能方向不清晰的时候，她会先写 5 个 evals，跑一遍，把哪些成功、哪些失败、用什么 prompt 提升成功率——这些输出，直接成为团队讨论的起点，而不是空泛地讨论”方向对不对”。
Cat 和 Lenny 都直接讨论了这个问题：在 AI 能力快速增长的前提下，人类的价值边界在哪里？
Cat 的回答聚焦在两个方面：
理解 stakeholder 之间的关系和偏好。她说，一次产品发布有上千个小的移动零件，AI 模型目前没有很好地理解”谁需要什么信息、在什么场合沟通、怎么把他们都留在船上”。这种涉及人与人之间关系的、带有 EQ 的判断，仍然是人类的优势。
在信息不完整时拍板，并承担责任。很多决策没有标准答案，需要有人在不确定性中站出来说”我们就往这个方向”。这种判断的勇气和对结果的负责，是当前 AI 无法替代的。
她还说了一句很真实的话：她现在已经能接受”发布一个有 bug 的功能”了。以前这会让她睡不着觉，但现在她的心态是：只要 bug 不影响核心功能，快速收到反馈并在下一个版本修复，比等到完美再发布更有价值。
这是 Cat 在访谈结尾说的一段话，我觉得是整期最实用的建议之一，但也是最容易被跳过的。
“如果一个自动化流程不能 100% 工作，它其实不算是自动化。那最后的 5% 到 10% 确实需要更多时间，但我鼓励大家投入这个时间，真正把它做到 100%。只有到了那时候，你才能真正依赖它。”—— Cat Wu
她举了一个很生活化的例子：Lenny 说他在用 Cowork 帮自己处理 Gmail，把明显是骚扰邮件的归类到一个叫”spammy”的文件夹里，”差不多 95% 准确，但偶尔会漏掉一封重要的”。Cat 的反应是：那这就不算真正的自动化，因为你还是需要时不时检查那个文件夹。
这个道理对 AI 产品经理设计工作流时非常关键：不要满足于“差不多能用”，要追到“完全可以信任”。从 95% 到 100% 需要花更多时间，但只有到了 100%，这个自动化才真正帮你释放了认知资源。
Cat Wu 的访谈给出了一个清晰的信号：AI 没有让 PM 这个职位消失，但它把 PM 的价值锚点从”协调沟通”移到了”判断品味”。
而这些能力，都指向同一个底层素养：大量使用 AI 工具、深度理解模型能力边界、用数据而不是感觉来驱动产品决策。这是 AI 时代 PM 最值得投入的自我训练方向。
本文由 @于小鱼 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。