有些思考攒了半年，总算梳理了一些线条可以写下来了。
这篇文章的起点，是 Anthropic Claude Code 产品经理最近写的一篇文章 —— Product Management on the AI Exponential。他在文章里讲了一个很有意思的细节：从 2024 年 10 月的 Sonnet 3.5 到 2026 年 3 月的 Opus 4.6，METR 的测评数据显示，AI 完成软件工程任务的时间跨度从大约 21 分钟提升到了接近 12 小时。16 个月，大约 41 倍的跃迁。
这个数字让我坐不住。不是因为数字本身有多大，而是因为它直接击穿了一个我从入行以来就当作理所当然的前提。
被击穿的前提
传统的 PD 工作流，建立在一个隐含假设之上：项目启动时技术上能做到的事，和项目结束时技术上能做到的事，大致在同一水平线上。
所以我们会做详尽的竞品调研，写 PRD，排 Roadmap，评估技术可行性，然后把方案交给研发团队去执行。整个周期以月为单位。这套方法在过去十几年是有效的，因为技术演进的速度是线性的、可预期的。
但指数级进步的模型把这个假设打碎了。
当围绕某个技术约束精心设计的产品方案，可能在项目中途，那个约束就不存在了。你在下沉的地面上建造，但地面在你脚下不断上升。
坦白讲，这对 PD 来说是一种近乎”存在主义”的焦虑。如果你的核心能力之一是判断”什么是可行的”、”什么是值得投入的”，而当可行性的边界每隔几周就被重写一次的时候，你的判断锚点在哪里？AI 生产力计划让我焦虑，让我不断的尝试和解构产品经理的核心。
困局一：规划还是实验？
在传统的产品方法论里，探索和调研发生在 Roadmap 锁定之前。调研、分析、写文档、评审、立项、执行。这是一条清晰的流水线。
但当技术可能性和生产力在不断变化时，”锁定 Roadmap”这件事本身就变得可疑。你锁定的那一刻，可能已经过时了。
Cat Wu 在文章里提到了一个概念叫”side quest” —— 鼓励团队里的每个人（不只是 PD）在正式 Roadmap 之外，去做短期的、自驱的小实验。一个下午的原型，一次对模型能力的压力测试。Anthropic 的一些最受欢迎的功能 —— Claude Code on Desktop、AskUserQuestion、todo list —— 都来自这种 side quest。
这种思路的转变本质上是：从”先定义确定性再执行”，转向”通过持续实验来加速发现”。
听起来很好。但落到一个具体的 PD 身上，困局就来了：
- 如果我不做详尽规划，怎么向上级汇报？怎么跟研发对齐？怎么保证资源投入的合理性？
- 如果我做详尽规划，规划写完就已经过时了，那我做规划的意义是什么？
- 如果我把规划变成实验，实验失败的成本谁来承担？
这是第一个困局。方法论的迭代速度远赶不上模型能力的迭代速度。
困局二：角色的消解与重构
第二个困局更个人化一些。
过去 PD 的核心竞争力，一部分来自”我能把需求清晰地翻译给研发”，来自 PRD 的质量，来自对技术可行性的判断力。
但当 Claude Code 这样的工具让 PD 可以一个下午从想法到可演示原型的时候，那条”翻译链”变短了。甚至不需要翻译了。
Cat Wu 提到她的团队角色边界在模糊：设计师在写代码，工程师在做产品决策，PD 在写原型和 eval。
这当然不是第一次有人喊”PD 要死了”。从低代码到 AI 写代码，类似的论调每隔一段时间就会出现。但这次的性质不太一样。之前的技术替代的是”执行层”的能力，而这次替代的是”翻译层”的能力 —— PD 作为需求与技术之间的桥梁，这个桥梁本身的价值在被压缩。
那 PD 还能做什么？
从 Cat Wu 的描述和一些行业 PM 的反馈里，我提取出一个正在浮现的答案：
PD 的核心价值从”定义确定性”转移到了”制造清晰度”。
在快速变化的技术环境中，团队最需要的是有人能在模糊中识别出方向，在噪音中提炼出信号，在可能性太多时做出优先级判断。这不是 PRD 能解决的问题，这是一种判断力。
但这种判断力，远比写 PRD 难。因为它没有标准格式，没有评审流程，没有确定的对错。
困局三：”做简单的事”的反直觉
Cat Wu 在文章里提到 Anthropic 的一个原则：do the simple thing that works。
理由很直接：如果你精心设计了一个 workaround 来绕过模型的某个限制，当新模型发布、那个限制消失时，你的 workaround 就变成了不必要的复杂度。越简单的实现，越容易在新能力到来时替换。
他们举了一个 todo list 的例子：最初模型不会自动勾选完成的条目，所以他们加了系统提醒来周期性 nudging agent 更新列表。下个模型发布后，这个行为自动就来了，提醒被整个删掉。他们的 system prompt 和 tool descriptions 也随之缩减了 20%。
这对 PD 来说是一个反直觉的要求。
我们这行的训练是”考虑周全”、”处理边界情况”、”设计健壮的方案”。但当技术地基在指数级移动时，”周全”可能意味着”过度设计”，”健壮”可能意味着”难以替换”。
换句话说，你的专业经验在某些情况下反而成了负债。这个论证会随着模型的不断强大，辐射到每一个和大模型相关的产品功能上。
这是最让人不安的一个困局。
困局四：控制与速度的张力
最后一个困局，关于控制感。
很多 PD 习惯了对完整产品体验的精细控制。但在 AI 产品的构建中，你必须学会放手 —— 否则就快不起来。
Cat Wu 说：”As a perfectionist, this was the hardest shift for me to get comfortable with.” 这句话我读了好几遍。
PD 需要在两种事物之间做取舍：少数真正不可妥协的 non-negotiables，和可以放手的 everything else。
但问题在于，在指数级变化的环境中，你很难提前知道哪些是 non-negotiables。那些你现在认为不可妥协的体验细节，可能在下一个极速开发的版本里被自动解决了。而那些你放手的部分，可能恰好是用户最在意的。
这种不确定性，是对 PD 控制欲的系统性打击。
那我们该怎么办？
我不想给出一个”五个步骤做好 AI 时代 PD”的清单，因为那恰恰是旧思维方式的产物。
但我想分享几个我自己正在尝试的转变：
- 缩短决策周期。 不再做半年以上的详细 Roadmap，而是按周或双周做方向性判断。方向不变，路径可以调整。
- 先验证能力，再优化成本。 Cat Wu 提到一个细节：在原型阶段，用比你觉得需要更多的 token。先搞清楚一件事是不是真的能做，再去考虑成本。很多团队反过来做，过早优化产品成本和产品的健壮性，结果做出的东西能力不够，根本无法判断价值。
- 承认不知道。 这可能是最难的一条。在 AI 时代，不知道不是缺陷，而是诚实。承认不知道，才能保持对新可能性的开放。
写在最后
我最近一直在想一个问题：当 AI 的能力曲线持续指数级上升时，人类的专业能力曲线是什么形状？
如果答案是线性的，那差距会越来越大。如果答案也是指数的，那我们需要找到那个杠杆。
对 PD 来说，那个杠杆可能不再是写更好的 PRD，做更详尽的竞品分析，或者排更精细的 Roadmap。可能是更快地识别”什么变了”，然后更快地调整方向。
就像 Cat Wu 说的：”Do that well, and you stop being surprised when the table tool finally works. You’re the one who saw it coming.”
不再被动惊讶，而是主动预见。
这大概就是 AI 时代 PD 还仅能做的事情。
参考资料：
- Product management on the AI exponential — Cat Wu, Head of Product for Claude Code at Anthropic
- Task-Completion Time Horizons of Frontier AI Models — METR, March 2026
- Context Engineering for Agents — LangChain Blog
- Context Engineering for AI Agents: Lessons from Building Manus — Manus Blog