一个真实的对话
有个做产品的朋友找我聊，语气有点低落。
他说："现在我们团队用了Claude Code，工程师早上开会定方向，下午代码就出来了。我感觉我……好像不太重要了。他们甚至不等我的PRD，就开始做了。"
我问他："他们做出来的东西，方向对吗？"
他沉默了一会儿："有时候对，有时候……跑偏了，但等我发现的时候，已经做了一半了。"
这个对话说明了一件事：不是PM变得不重要了，是PM介入的方式需要彻底改变。
失落感从哪来
在传统研发模式里，PM有一种天然的"掌控感"：
需求是我定的，优先级是我排的，流程是我推的，上线节点是我盯的。整个研发过程里，PM是那个"持有信息"的人，别人需要来问你。
但AI辅助研发之后，这个格局变了：
工程师有了AI工具，自主能力大幅提升。他们可以自己快速出原型、自己理解业务逻辑、自己实现一些以前需要PM翻译的需求。PM原来靠"持有信息"建立的权威感，开始松动。
这就是失落感的来源：不是你的能力变差了，是你原来依赖的那套控制流程，已经不是这场游戏的规则了。
但"跑偏了才发现"，才是真正的问题
回到我朋友说的那句话——工程师用AI飞速开发，但有时候"跑偏了，等我发现已经做了一半"。
这不是工程师的问题，也不是AI的问题。这是PM介入节奏没跟上的问题。
在AI研发流程里，执行速度提升了5-10倍。这意味着：
- 以前跑偏了，两周后的sprint review能发现，损失是两周的工时
- 现在跑偏了，如果还等两周后才介入，损失可能是两个月的工时
方向错误的代价，被AI加速了。
而产品经理最核心的价值，恰恰是在这里——方向对不对，需要有人负责。工程师和AI可以执行得很快，但"这件事值不值得做、做给谁、做成什么样算成功"，这些判断不是AI能给出的。
PM的新角色：判断资源，而不是流程节点
这是最关键的认知转变。
以前PM是"流程上的关卡"：需求必须经过我评审，设计必须经过我确认，上线必须经过我验收。PM的价值通过"节点控制"来体现。
现在PM需要变成"随时可调用的判断资源"：
工程师有了一个粗糙版本，发过来"这个方向对吗"——你能不能在30分钟内给出清晰的反馈？
不是"功能有没有做完"，而是"这个东西解决了对的问题吗、用户会这么用吗、有没有遗漏的边界case"。
这种判断，是高密度的、实时的、有温度的——这正是AI做不到的事。
PM从"管流程"变成"供判断"，不是降级，是进化。
那PRD还要写吗
这是很多PM最实际的困惑。
答案是：写，但写的东西要变。
工程师不再需要你把每个交互细节都写清楚——他们用AI工具可以自己推导实现细节。但他们非常需要你把以下三件事写清楚：
一、用户真正的问题是什么（不是功能描述，是意图描述）
二、成功长什么样（可量化的验收标准，而不是"用户能用就行"）
三、不能做什么（边界约束，这个往往比"做什么"更重要）
一个好的上下文文档，是工程师喂给AI的最佳输入。你的工作从"写功能说明书"变成"提供高质量决策上下文"。
写好了，工程师和AI跑得更快更准；写不好，AI会帮他们快速跑向错误方向。
一件反直觉的事
AI研发流程让PM的"可替代感"增强了，但同时也让PM的"决策权重"提高了。
听起来矛盾，但逻辑是这样的：
以前开发慢，一个方向错了可以慢慢纠偏。现在开发快，一个方向错了会快速积累成大问题。所以"方向判断"这件事变得比以前贵重得多——只是它不再通过"写PRD、开评审会"来体现，而是通过"快速给出高质量判断"来体现。
如果你能做到这一点，你在AI研发团队里的价值是被放大的。
如果你还在等别人来找你开评审会，那确实会感觉自己越来越边缘。
找回主动感的三件事
第一件：主动缩短介入周期
不要等工程师来找你，主动每天同步一次进展。"你们现在做到哪了，我看一眼方向有没有偏。" 早介入一天，就少处理一天的跑偏成本。
第二件：把"上下文文档"做成你的标志性输出
不是传统PRD，而是一份包含用户意图、成功标准、失败模式、边界约束的文档。让工程师发现：有了这个文档，他们和AI协作的效率提升了一大截。这是你证明价值的最直接方式。
第三件：建立自己的"20%护城河清单"
认真列出来：你在这个产品、这个行业里，有哪些东西是AI替代不了的——哪些用户洞察是你通过真实访谈积累的，哪些商业判断是你踩过坑才有的感知，哪些跨团队信任是你多年建立的。
有了这份清单，失落感会小很多。因为你知道自己不可被替代的部分在哪里，剩下的问题只是"怎么更好地利用AI把其他部分做更好"。
最后说一句
工程师有了Claude Code，不是来替代PM的，是来挑战PM的工作方式的。
挑战不是坏事。那些真正被挑战清醒的PM，会在这个过程里找到自己更大的价值空间。
怕的不是被挑战，是被挑战了却选择视而不见。
（系列完结。五篇聊的是同一件事：AI时代，不是PM消失的时代，是PM必须找到自己真正价值的时代。）