当技术边界以月为单位重构,PRD还没写完就已经过时--这不是危言耸听,而是Anthropic产品负责人Cat Wu正在经历的日常。
传统产品管理的隐形契约:"启动时的技术边界 ≈ 交付时的技术可能性"
这个假设在AI时代彻底失效。Claude团队的实测案例极具说服力:
| 时间节点 | 模型版本 | 同一任务的表现 |
|---|---|---|
| 2024年10月 | Sonnet 3.5 | 完全无法实现 |
| 2025年6月 | Opus 4 | 偶尔完成,仅够录播 |
| 2026年 | Opus 4.6 | 稳定一次性实现,支持数千人实时演示 |
16个月,41倍能力跃升--这意味着什么?
你花三个月写的技术约束分析,可能在第四个月变成废纸。你精心设计的"绕过AI局限"的复杂方案,可能在新模型上线当天变得毫无必要。
| 传统PM | AI原生PM |
|---|---|
| 追求前期确定性 | 拥抱持续不确定性 |
| 详尽的长期路线图 | 快速实验、持续交付 |
| 控制全流程 | 在模糊中创造清晰 |
| 按计划执行 | 在变化中把握方向 |
Cat Wu的实践揭示了一个反直觉的真相:过度规划本身就是最大的风险。
最令我震撼的不是模型能力,而是PM工作流的根本性转变:
Cat Wu的日常工作(无需手写代码):
Anthropic的PM工具三角:
结果: 原本需要跨团队、数周完成的任务,单人高效闭环。
我的观察: 最优秀的AI产品经理已经开始实践"动态规划"--不是放弃规划,而是把规划本身变成持续迭代的产品。
你所在团队是如何应对技术指数级变化的?欢迎分享具体场景下的取舍与挣扎。
加入讨论
冲浪者这个比喻太对了!我之前做AI功能规划,花两周写的技术限制清单,Claude 3.5一更新直接作废一半。现在学乖了,PRD只写骨架,细节边做边填😂 就是老板还没习惯这种”不确定感”,总觉得我在摸鱼…
Cowork这个工具三角有点意思,但我更好奇的是——PM现在连代码都不用写了,那和真正工程师的边界到底在哪?不会最后变成”谁prompt写得好谁说了算”吧😅 我们组已经在扯皮这个了
第三点真的扎心了…我上周刚跟技术负责人拍胸脯说”这个功能AI肯定做不来”,结果周末Gemini更新直接打脸😅 现在开会都不敢把话说死,先扔个demo出去探路再说。
说实话看到”41倍能力跃升”这个数字有点焦虑😂 我们团队还在用季度OKR,但模型迭代速度明显快于这个节奏。想问问大家:你们是怎么对齐内部节奏和外部技术变化的?直接取消长期规划还是分层处理?
“动态规划”这个词用得太妙了,以前学算法的时候完全没想到能用来形容产品工作😂 不过说实话,我最头疼的不是规划本身,而是怎么跟非技术背景的老板解释”为什么这个月的需求和上个月说的不一样”——他们真的会觉得是我在拍脑袋改方案。
看到Cat Wu用自然语言跑评估脚本那段,突然意识到我们组还在用Jira拉表格做埋点分析是不是太原始了😂 想问问有没有试过Claude Code的PM,实际写复杂逻辑的时候真的不用看代码吗?还是说要懂点基础才能描述清楚需求?
“建筑师变冲浪者”这个比喻让我想到,以前我们组做产品评审,老板最爱问”三个月后的DAU预测是多少”,现在根本不敢这么问了😂 不过说真的,PM不用写代码但得懂训练逻辑,这算门槛变高还是变低了?有点懵
好家伙,16个月41倍…这让我想起去年信誓旦旦跟团队说”AI做不了多轮对话状态管理”,结果现在Claude自己都能写状态机了😅 现在我的生存法则:任何技术判断前面都自动加”目前”两个字,有效期30天。
笑死,看到”PRD还没写完就已经过时”突然想到我司的PRD文档库,里面躺着十几个”因模型更新而废弃”的文件夹,堪称AI考古现场😂 现在学聪明了,直接写”待模型能力确认后补充”,反正谁也不知道下个月会发生什么