想象一个场景：用户说导出报表不好用。
一个 PM 不会立刻去找工程师改代码。他会先约几个用户聊一聊，翻翻后台数据，把问题拆开来看——是导出太慢、字段少了、格式对不上，还是用户本来就不该在这个页面里手工导出。他还得想清楚：这个问题卡住了哪一类用户，现有产品哪里给了他们错误预期，下一版应该帮他们省掉哪一步，做完以后数据上会有什么变化。
这一套流程看起来很自然。但之所以顺，是因为在过去，功能写错了要付的代价太高。
一个改动要占掉两周工程资源，PM 就只能在开工之前尽量想透。等到上线才发现方向错了，整个团队要跟着返工。真实的用户反馈如果一个月以后才到，PM 就只能在发布之前多做访谈、多看数据、多推演几种方案。PRD、roadmap、方案评审这些东西并不是天生更重要，而是工程执行太慢、太花钱、太不能试错，所以 PM 不得不在前面堆判断。
AI 改变 PM 这件事，切入点就在这里。
AI 把写代码、搭原型、跑实验、上线早期功能的成本全往下拉了。工程执行不再是产品循环里最慢、最吃资源的那一步，而是可以随时调用的能力。这一下，PM 的重心也要跟着动：以前是开工之前的判断对不对，现在是从想法到实现到发布到反馈到修正这个圈，能不能转得够快。
Cat Wu 上 Lenny’s Podcast 这期访谈恰好给了一个前沿团队的样本。Cat 在 Anthropic 负责 Claude Code 和 Co-work 两个产品。她说，以前做产品可以按 6 到 12 个月来规划，现在很多功能的交付周期从 6 个月缩到 1 个月，有时是一周，甚至就一天。
这不只是快了一点。对 PM 来说，产品循环的节奏变了。过去 PM 的价值集中在上线之前的判断正确率，现在 PM 更像是在设计学习回路。
完整访谈的中文翻译在这里：Lenny’s Podcast × Anthropic Cat Wu：关于 Claude Code、PM 角色演变与 AI 原生产品构建。下面这篇文章不打算复述访谈，而是用 Cat 的材料去讨论 PM 这个职业在 AI 时代最根本的变化。
一个传统 PM 一天里有很多看起来不直接产出东西的工作：写 PRD、做用户访谈、看数据、画用户路径、过方案评审、排优先级、准备发布说明。做的时候容易觉得繁琐。但这些事放在传统软件公司的成本结构底下看，每一项都有它的道理。一个功能从想法到上线，要走用户研究、需求文档、设计方案、技术方案、开发、测试、灰度、发布，每一环都占人，每次返工都在消耗本来就很紧的工程资源。
PRD 负责在工程动手之前把问题定义、目标用户、关键体验和成功标准讲清楚。Roadmap 负责在资源有限的情况下决定先解决谁的问题。方案评审负责把产品、设计和工程拉到一个体验目标上。这些东西底下的逻辑是同一个：执行太花钱了，所以在动手之前必须把产品判断的确定性往上提。
这件事也反过来塑造了传统 PM 的能力模型。一个资深 PM 在工作里要做的事，本质上都是在信息不完备的时候做判断：从访谈里把需求抽出来，从数据里把问题推出来，从工程师的估算里理解这件事的成本，从销售和客服的反馈里判断优先级。PM 大多数时候站在工程系统外面，靠文档、原型、评审和用户证据来推动产品选择。
我在一次性软件与被压缩的现实里写过类似的判断：过去很多职业能力是信息获取成本太高时的压缩策略。对 PM 来说，工程系统很多时候就是一个看不见的运行现场。做可视化、原型、分析工具、中间态界面都很花钱，PM 只好学会在看不见的时候做决策。
所以说，传统 PM 不是在低效工作，而是在一套旧价格下做了合理的事情。只要工程还那么花钱，返工还那么疼，反馈还那么慢，前置的产品判断就有它不可替代的价值。
真正的转折发生在价格变了以后。
再回到导出报表那个例子。旧的节奏里，PM 发现问题以后要先访谈、写需求、画方案，然后排队等开发和上线，中间大量时间在等。不是 PM 不想更快看到结果，而是工程队列就排在那里，很多产品判断必须等上线才能验证。
到了新的节奏里，PM 或者工程师用 AI 半天搭出一个原型，当天放给一小部分用户试——整个判断方式就变了。很多以前要在会议室里猜的问题，现在可以直接跑一个小实验来回答。很多以前要写进半年 roadmap 的判断，现在可以先做一个 research preview 放到线上去看真实反应。
Cat 在访谈里说，Claude Code 团队想让任何人都有能力把一个想法推到世界上，周期不超过一周，有时候一天就够了。她还提到 concept corner，在产品矩阵里专门留出一块实验区，工程师或者 PM 有什么想法当周就能送到用户手里。
release 这个词的含义也会跟着变。以前 release 像是一个阶段的终点，漫长开发周期的交付仪式。现在 release 可以变成观察工具：把东西推到真实用户面前，一方面是交付价值，另一方面是用最快的速度拿到下一轮信号。
PM 的压力也在这里。以前工程慢，他有相对宽裕的时间做判断、写文档、拉齐共识。现在工程可以一天跑完，如果产品判断还沿用半年路线图的节奏，PM 自己就会变成整个循环里最慢的那一段。
所以 Cat 讲 light process、research preview、evergreen launch room，不是为了把流程搞轻而搞轻。这些东西真正带来的是同一样收益：缩短从想法到用户反馈的路程。
拿 research preview 来说就比较清楚。Claude Code 的很多功能上线时带着这个标签，明确告诉用户这是早期想法，团队想拿反馈来迭代，不一定长期维护。标签本身的成本很低，但它把上线的承诺成本降下来了——团队可以一两周就把东西推出去。
更重要的是，这个标签改写了产品和用户之间的默认契约。以前在 GA 语境下，用户一看到功能就默认它是完成品，团队要承担的稳定性承诺很重。research preview 把一部分预期切换到共同实验：用户知道自己正在参与一个产品判断过程，团队也因此能更早把功能放进真实环境里。
说到底是同一件事：PM 的工作从提高一次性判断的正确率，转向提高整个循环的学习速度。
一个团队如果每天只能做一个小改动，PM 最要紧的工作是判断这个改动值不值得做。如果一个团队每天能做十个小改动，问题就从”这个该不该做”变成”哪些该进入循环、每个改动看什么信号、看到信号以后谁来判断下一步”。
工程执行的成本下来了，PM 要回答的问题会换一套问法。
以前要问：这个用户问题值不值得排工期？
现在要问：这个产品假设是不是已经可以低成本试了？如果可以，试多小、试多快、看哪些指标？
以前要问：PRD 有没有把需求写清楚？
现在要问：团队能不能在没有 PM
逐项盯的情况下，自己做出方向一致的产品判断？
以前要问：上线前我们有没有把方案想透？
现在要问：上线以后我们能不能快速发现哪里错了，并且让下一次更好？
这也是 Cat 为什么花那么多时间讲团队原则和指标读数。Claude Code 团队每周做严格的 metrics readout，让每个人的脑子里都装着业务目标、趋势和驱动因素。同时团队会写清楚：核心用户是谁，为什么是他们，什么东西可以牺牲。这样每个工程师看到一条用户反馈，能自己判断它属于哪类用户；designer 做交互取舍的时候，知道哪些体验可以牺牲；PMM 和 docs 在功能快要上线时，知道应该怎么向用户讲这个功能。
这些东西表面上和文档没有区别，但它们真正的作用是回路基础设施。过去，目标定义主要用在上线前的团队对齐。现在，目标定义还要用来支撑高频的自主判断。因为如果团队里很多人都能端到端把东西做出来，PM 不可能站在每条路径上一个一个审批。PM 只能把用户画像、成功状态、失败模式、反馈通路提前铺在地上，让团队在很短的循环里自己跑。
这也解释了为什么 PM 这个角色不会消失。当工程师可以直接做产品了，只管传话的 PM 确实会越来越少。但产品循环变快以后，需要做判断的地方不是变少了，是变密了。团队每天有更多想法能执行，更多用户反馈能处理，更多实验能放上线。执行不再稀缺以后，真正稀缺的问题是：该把什么东西放进循环里，以及怎么判断循环有没有真正学到东西。
谈到 PM 未来最需要什么能力时，Cat 给了一个能把很多线索串起来的判断：当代码可以低成本生成以后，真正稀缺的是决定该写什么。
概括起来就是 product taste 重要。但 taste 这个词容易变成空话。放到具体工作里，它说的是一种成本判断的能力。
一个用户反馈说按钮位置不好。按以前的流程，PM 会先收更多反馈，等下个版本统一改——因为哪怕只是移一个按钮，也得走设计、工程、测试和上线的完整流程，占掉不少资源。到了现在的价格表下，如果这个改动真的小，工程师或者 PM 当天就能做一个版本放给内部用户或者一小部分外网用户试。这时候再开三轮会讨论这个按钮该不该移，就对不上成本了。但反过来，如果一个小功能牵动了权限、计费、企业安全和数据迁移，那它看起来简单，实际上需要的是严肃规划。
这就是 Cat 说工程背景能帮到 PM 的地方。她没有说 PM 都要去写代码。她说的是工程背景能让 PM 对一件事情的实际难度有感觉。容易的就花一小时做掉算了，不值得来回开会；会牵动长期基础设施的，就要更谨慎地投入团队时间。
所以 AI 时代 PM 的技术能力，首先是一层成本直觉。你要能分辨什么东西已经没有太高成本了，试了再说；什么东西看着简单但会拖慢整个系统；什么东西现在做不成但值得放在可行性的边缘上盯着看。
这一判断也跟超越 DRY那篇文章有交叉。AI 让一部分代码从长期资产变成了可以随时生成的临时材料。以前我们会本能地避免写一次性工具、避免为小问题专门搭软件、避免重复造轮子。现在呢？一次性原型、临时分析脚本、短周期实验这些东西全都变得合理了。PM 如果还是把所有工程投入都按长期资产来估价，就会看不见这些临时产出带来的学习价值。
Cat 举了 Claude Code 的 to-do list 做例子。早期 Claude Code 做大型重构，经常说要改 20 个调用点，改到 5 个就停下来。团队给它加了一个 to-do list，让它像人一样列清单、一项一项完成。后来的模型自己学会了这个行为，to-do list 对模型完成任务的帮助变小了，但对用户观察 Claude 在做什么仍然有价值。
这个例子说明了一件事：AI 产品里的功能经常背着两种身份，一种是补模型能力的短板，另一种是帮用户理解和信任模型。模型进步以后，前一种身份会淡化，后一种可能一直留着。PM 必须不断去重新判断：同一个功能现在在产品里到底在扮演什么角色。传统软件里，功能上线之后就进入漫长的维护期；AI 原生产品里，功能可能在模型更新一次之后就要重新定价。
这也跟 Cat 说的 AGI pill 有关系。她认为 AI 公司 PM 最难练的能力，是定义一个月后产品应该是什么样子。模型在变，用户行为也在变。为一个未来的超级模型做产品反而容易，因为那个世界里很多中间产品根本用不着存在。难的是对着当下的模型，既不过度相信未来会解决一切，又不被现在的限制绑得不敢往前走。
这里的产品判断全都发生在边界上。你要知道当前模型在哪些地方可靠、哪些地方要靠 harness 补、哪些地方能用产品设计把用户引到黄金路径上。你还要能看出来哪些能力下一代模型大概率会自己学会，不要为这些即将消失的短板搭太重的产品。
把 Cat 的访谈和这套成本结构放在一起，PM 在 AI 时代的职业道路上有三条比较确定的变化。
第一，需求管理能力会降权，目标定义能力会升权。写 PRD 仍然有价值，尤其是在模糊功能和底层基础设施项目上。Cat 自己也说他们有时候会写 PRD。但 PRD 不再是 PM 价值的核心载体了。真正决定分量的是你能不能定义清楚目标用户、成功状态、失败模式、什么可以放弃，让团队在高频行动里不偏离方向。
第二，工程理解会从加分项变成一个基础的判断能力。PM 不需要成为全职工程师，但必须读得懂 AI 之后的新价格表。一个功能到底应该开会讨论还是当天就做一个 research preview，一个问题到底是 prompt 层能接住还是需要 harness、eval、产品交互一起上，一个能力到底是模型马上自己会补上还是得要长期产品化——这些判断动不动就影响产品速度和资源配置。
第三，PM 会越来越像一个回路设计者。这个回路包括用户反馈怎么进到团队里，团队怎么把反馈变成实验，实验怎么快速推上线，用户怎么理解预期，团队怎么判断成功或失败，AI 怎么从这些反馈里改进下一次的产出。这里面有文档，有数据，有发布机制，有 evals，有组织协作。它们粘在一起，才是 AI 时代 PM 真正的新工作面。
这也解释了为什么 Cat 一边说角色在融合，一边又说 Anthropic 还有 30 到 40 个 PM。title 没有消失，但 title 下面的工作在变。过去 PM 很多时候是用户问题、产品方案和工程实现之间的翻译者。现在，在最前沿的 AI 团队里，PM 更像是在维护一个高速学习系统。
AI 对 PM 的影响，拿”会不会被替代”这个公式来算是算不准的。替代叙事太粗糙了——它先把 PM 的工作看成一组固定任务，再逐项问 AI 能不能做。现实里发生的变化比这个深：AI 把任务之间的相对价格改了，产品循环的节奏也跟着变了。
工程成本高的时候，PM 的价值是把上线前那一次产品判断做对。
工程成本低的时候，PM 的价值是把学习速度往上拉。
AI 能自己执行了，PM
的价值在定方向、给上下文、设计反馈、判断产出质量。
模型能力不停在变，PM
的价值在不停地重估：这里应该补模型、约束模型，还是放手让模型自己来。
Cat Wu 的访谈之所以能让人多看几遍，是因为 Claude Code 足够靠前。它给普通 PM 发的信号其实是一个：你们手里那张旧价格表快要不作数了。
未来两年，PM 这个职业会分叉。会有一批人继续做需求整理、路线图维护和跨团队协调，这些工作在大公司和传统行业里不会一下子消失。但在 AI 原生团队里，更缺的会是另一批 PM：他们看得懂模型能力，看得懂工程成本，能定义模糊目标，能让团队和 AI 一起在更短的回路里不停地学习。
最后这一种 PM 做的事情，是让一个团队更快地看见现实，然后更快地从现实里修正自己。