AI没有取代PM,只是旧的工作方式已不适用

当系统已经加速向前，停在原地的人会先感受到位置错位。

想象一个场景。

用户在入驻系统里卡住了，想反馈，却找不到反馈入口。

一个传统 PM 通常不会马上动手去改。他会先把问题记下来，再去补访谈、看数据、拉人讨论，接着写需求、排优先级、等开发排期。等功能真的上线，可能已经过了几周。到那时候，团队才第一次知道这个问题到底是不是用户真的在意，还是只是在某个特定路径里显得刺眼。

这套流程以前没有问题。因为以前实现很贵，返工代价也很大。只要一动手，就是设计、开发、测试、发布整条链路一起动。PM 当然得尽量把判断压到前面。

但现在，这个前提已经开始变了。

很多团队里的 PM，不是不会用 AI，而是还在用旧的工作方式，面对一个已经快了很多的系统。

换句话说，不是 AI 取代了 PM，而是旧的 PM 工作方式已经不够了。

这个判断，是我看 Claude Code Product Cat Wu 在 Lenny’s Podcast 上访谈时想起来的。原视频在这里：https://m.youtube.com/watch?v=PplmzlgE0kg&pp=iggCQAE%3D

#传统 PM 为什么会长成现在这个样子

先说清楚一点，传统 PM 不是低效，也不是不专业。

过去那套工作方式，本来就是在一种很具体的环境里长出来的。开发实现成本高，返工成本高，上线慢，真实反馈回来得也慢。一个功能一旦做错，不只是方向偏了，而是会连着吃掉设计、开发、测试、发布整条链路的时间。PM 在这种环境里，当然会把大量判断前置。

所以才会有那么多看起来不直接产出的工作：写 PRD、跑访谈、看数据、画用户路径、过方案评审、排 roadmap、拉资源对齐。这些动作底下其实是同一个逻辑：执行太贵了，所以在动手之前，必须尽量把产品判断做对。

从这个角度看，传统 PM 不是在做繁琐工作，而是在过去那种“实现贵、返工代价大、反馈慢”的环境里做了合理的事。

问题不在过去那套方式错了，而在于今天做产品的条件已经变了。

#变的不是某个工具，而是产品循环的速度

很多人一谈 AI 对 PM 的影响，第一反应还是放在会不会写代码、能不能做原型、会不会用几个 AI 工具上。

但如果只停在这里，真正大的变化就看不见了。

Cat Wu 在访谈里提到，以前很多功能可能要按 6 到 12 个月去规划，现在一些功能从构想到交付，可能一个月、一周，甚至一天就能跑完。这个变化带来的，不只是“开发快了一点”，而是原型、实现、试验、发布这些动作都被压缩了。

一旦实现不再是产品循环里最慢、最贵、最不能试错的一环，PM 的重心就一定会跟着变。

以前，PM 的价值更多体现在上线前那次判断准不准。现在，更重要的问题变成：从想法到实现、从发布到反馈、从反馈到修正，这个回路能不能转得足够快。

很多 PM 现在真正没跟上的，不是工具，而是节奏。

变化最大的不是某个工具，而是整个产品循环的速度。

#旧的 PM 工作方式，为什么会开始不够用

如果顺着这个变化往下看，会发现很多过去默认成立的工作模式，其实都开始松动了。

过去，PM 的价值很大一部分在于上线前把那次判断做对。执行太贵，所以必须在前面把问题定义清楚，把方案想透，把需求写细，把风险提前拦下来。但现在，很多判断已经不需要全靠会议室里的推演来完成了。以前只能猜的问题，现在可以直接跑一个小实验去验证。以前要等半年 roadmap 的东西，现在可能一周内就能放到真实用户面前看反应。

过去，release 更像一个阶段性交付。一个版本做完，上线，收尾，再进入下一轮。现在 release 更像一个观察窗口。很多功能不是因为“已经完全做好了”才发布，而是因为团队想更快看到真实世界的反应，想知道这个方向值不值得继续走。

过去，开发和上线通常是最慢的一段，所以 PM 有相对充裕的时间慢慢判断。现在如果开发实现可以一天跑完，而 PM 还沿用过去那种层层前置、层层确认的节奏，那 PM 自己反而会变成整个循环里最慢的一环。

这些变化放在一起，最后都会收敛到一个问题上：很多 PM 还是把自己放在系统实现这一侧。

这也是我最在意的一点。

#把系统实现当黑盒，会把 PM 慢慢推出产品回路

很多 PM 现在的问题，不是不用 AI，也不是完全没有技术意识。更现实的情况是：他们知道迭代可以更快，知道原型可以更快做出来，知道很多需求不再像以前那样重。但在心里，他们还是把系统实现当成一个黑盒。

需求是我提的，优先级是我排的，方向是我定的。至于系统怎么跑、逻辑怎么变、上线后到底长成了什么样，很多时候还是要靠程序员转述。

这在旧节奏里勉强还能运转。因为系统变化没那么快，需求推进也没那么密。可一旦 AI 把实现和迭代速度拉起来，这种位置就会迅速出问题。

最直接的后果，是 PM 在做决策时会高估或低估开发成本。

因为系统对他来说是黑盒，所以他很难准确判断：这件事到底是一个当天能试的小改动，还是一个会牵动权限、数据、兼容性的复杂问题。结果就是，要么把小事看得过重，反复讨论；要么把复杂问题看得太轻，后面再由团队一起填坑。

再往后，需求迭代几轮之后，PM 会越来越不了解系统现在是怎么跑的。这里不是说 PM 变笨了，而是系统已经在持续演化，但 PM 的参与位置还停在旧地方。很多小需求、小修补、小实验，可能已经在更快的节奏下被做掉了。它们未必都经过了传统意义上那套完整的 PM 确认流程。结果是，PM 对系统的理解越来越滞后于它的实际演化。

于是客户一问细节，PM 只能回头问程序员。一个具体问题要想搞清楚，还得再拉上 PM、程序员、测试一起，把现状重新拼出来。

问题不只是沟通效率低了。

与此同时，PM 正在慢慢退化成一个只负责提需求的人，不再是产品回路的一部分。

一旦把系统当成黑盒，PM 就会慢慢离现实越来越远。

#PM 真正要补的，不是 coding，而是位置

说到这里，很容易得出一个经不起推敲的结论：PM 该去学编程。

我觉得不是。

至少不是“你得先变成一个开发”这个意思。

问题不在于 PM 要不要懂所有技术细节，而在于 PM 不能再把系统当黑盒。真正要补的，不只是工具能力，而是位置。PM 需要重新进入产品回路。

这个“重新进入”不是一句空话。它最实际的意思是：你不能只在前面提需求、做判断、排优先级。 你还要加快验证节奏，更直接观察系统实际是怎么跑的，更深入地参与从想法到反馈的完整链路。

更进一步说，PM 至少要具备一种新的基本能力：自己能独立跑通一个最小闭环。

不是所有大项目，不是所有复杂系统，而是一个足够小的闭环。你能不能把一个想法，用 AI 和现有工具推到一个可验证状态；能不能把它放到真实用户面前；能不能自己看到反馈；能不能根据反馈再修一轮。

如果这一点做不到，PM 就很难真正跟上 AI 之后的产品节奏。

#动手跑一遍，才能真正理解这个差距

还是回到前面那个例子：用户在入驻系统之后，想反馈，却没有反馈入口。

放在旧模式里，PM 很可能会这样处理：先把问题记下来，拉人讨论，看是不是共性问题，再补一些访谈和数据，写需求，排优先级，进入开发队列。上线前重点是把方案想清楚，上线后再等反馈回来。

这套方式当然没错。但它天然比较慢，而且大量判断都堆在前面。

如果是在新的节奏里，一个更好的做法可能是：先把问题缩成一个最小闭环。不是先讨论一个完整的反馈系统要怎么设计，而是先补一个最简单的反馈入口，哪怕只让一小部分用户看到，然后直接看真实提交率、反馈内容和后续行为。

这样一来，PM 不再只是提出问题的人，而变成了真正参与验证的人。

这里的关键不是“PM 自己写代码”，而是 PM 自己能把一个问题推到真实世界里，看它有没有被解决。

位置一变，PM 的价值也会跟着变。

#PM 还停在原地，但系统已经往前跑了

AI 时代对 PM 的真正挑战，不是会不会用 AI，而是 PM 的角色还停在原地，系统已经往前跑了。

过去，PM 的价值更像是在昂贵执行开始前，把那次产品判断做对。现在，实现越来越便宜，试错越来越快，真正稀缺的变成了另一种能力：你能不能让团队和系统进入一个更快的学习回路，能不能更快看到现实，能不能根据现实及时修正自己。

所以，旧的 PM 工作方式不是完全错了，而是不够了。

不是 AI 取代了 PM。

而是 PM 不能再把自己理解成站在回路外面的人。

如果要给一个最小的行动建议，我觉得不是“明天开始学会写多少代码”，而是自己亲手跑一次从 想法 -> 实现 -> 发布 -> 反馈 -> 修正 的小闭环。

真正有用的补位，不是多懂一点概念，而是亲手跑通一次最小闭环。

哪怕只是一件很小的事。

但只要你真的跑过一次，你对 PM 这个角色在 AI 时代该站在哪里，会有完全不一样的理解。

这件事其实也不只发生在 PM 身上。PM 只是一个更早暴露出来的角色。

当 AI 把实现、迭代、发布、反馈的速度都拉快之后，任何还停留在旧工作方式里的人，都可能慢慢被推出回路。尤其是那些离 AI 最近、最早开始用它的人，更容易误以为自己已经跟上了变化。

但很多时候，变的只是工具，没有变的是人理解系统、参与验证、修正判断的方式。

所以真正要补的，不只是某个岗位的新技能，而是每个人都要重新回答一遍：当系统已经往前跑了，我是不是还站在原来的位置上。