刚刚，Anthropic Claude Code 产品负责人 Cat Wu 发了篇博客，聊了聊他们团队的产品经理现在到底怎么干活的。
一句话总结就是：
传统 PM 那套玩法，在模型能力指数级增长的时代，已经不够用了。
这倒也不是什么惊人之语。但 Anthropic 自己的 PM 负责人也拿出具体案例来说的时候，也就更值得我们关注了。
地基在动
Cat Wu 在文章里用了一个比喻：
你在一块正在上升的地面上盖房子。
传统产品管理有个隐含假设：项目开始时技术能做什么，结束时大体也差不多。路线图定好，团队按节奏推进，一切有条不紊。
但 AI 模型的进化速度，把这个假设给掀了。
Cat Wu 自己有个保留测试项目：让 Claude Code 给 Excalidraw 加一个表格工具。
2024 年 10 月用 Sonnet 3.5 试，基本做不出来。2025 年 6 月用 Opus 4 试，偶尔能成功，可以提前录好 demo 用。到了现在的 Opus 4.6，已经可以当场现场演示了。
METR 的模型任务数据展示：
Opus 4.6 能完成需要人类大约 12 小时的软件任务，而 16 个月前的 Sonnet 3.5 只能处理 21 分钟级别的任务。
41 倍的能力提升，16 个月。
在这种速度下，你花三个月写的路线图，等写完模型可能已经换了两代了。你精心设计的 workaround，下个模型可能原生就支持了。
这就是 Cat Wu 说的「地基在动」。
Side Quest 文化
那怎么办呢？
Anthropic Claude Code 团队的做法是：把长期路线图换成了短冲刺，外加一种叫「Side Quest」的机制。
Side Quest 就是团队里任何人（工程师、设计师、PM 都行）发起的自主实验。不在正式路线图上，可能就是某天下午冒出来的一个念头。
Claude Code 里好几个现在大家在用的功能，就是这么来的：
Claude Code on Desktop（桌面版集成）
AskUserQuestion 工具
Todo lists 功能
这些功能的共同点是：没有人写过 PRD，没有经过传统的评审流程。
有人觉得这个想法可能行，下午就做了个原型，内部用户试了觉得好用，然后就上线了。
从「想到」到「做到」之间的缝隙，几乎消失了。
原型吃掉文档
这是整篇文章里，最值得关注的一个变化。
Cat Wu 给团队的建议是：
写完 spec 之后，把它发给 Claude Code，看看能不能直接把东西做出来。
她举了个例子。团队成员 Noah 写了一份 plugins 的 spec，直接喂给 Claude Code，出来的原型质量高到成了最终上线版本的基础。
另一位成员 Conner 则手工写了一套 eval（评估测试），定义了什么情况下功能算「成功」，什么情况下算「失败」。这些 eval 成了团队后续迭代的锚点。
发现了吗？
PM 的产出物，变了。
以前的核心交付是文档：PRD、需求说明、流程图。
现在的核心交付变成了两样东西：可运行的原型和可衡量的 eval。
Prompt，正在成为新的 PRD。
模型升级即产品升级
Cat Wu 提到的第三个变化，其实才是最容易被忽略的。
每次新模型发布，团队会重新翻一遍之前「做不到」的功能清单，拿新模型再试一次。同时，还会清理掉旧模型时代堆上去的 workaround。
她举了个 Todo list 的例子。
早期模型不会主动把完成的任务勾掉，团队就在 system prompt 里加了提醒。后来新模型出了之后，这个行为变成了自带的，提醒也就删了。
整个 Opus 4.6 的 system prompt 和工具描述，比上一代精简了 20%。
这背后的逻辑是：今天的 hack，就是明天的技术债。 但在 AI 产品领域，这个「明天」来得特别快，可能就是两三个月后的事。
Cat Wu 在博客里还分享了一个 Chrome 集成的案例。团队观察到用户在用 Claude Code 写网页应用时，会手动切到浏览器去测试，然后再手动把报错信息复制回来。
如果用户在自己搭这种桥，那说明这个桥应该内置到产品里。
做简单的事
Anthropic 内部有个指导原则，Cat Wu 也反复提到：
Do the simple thing.（做简单的事。）
在 Agent 系统中，复杂度是指数级放大失败的。你多加一层 workaround，失败模式就多一类。
所以 Cat Wu 的建议是：先用最笨的方法做。
如果模型今天不够好，先别急着搭复杂的脚手架。等下一代模型出来，很可能这个问题就不存在了。
这个原则，说起来容易，做起来其实挺反直觉的。
工程师的本能是遇到问题就解决问题。但在 AI 产品的语境下，有些问题最好的解法是……等等看。
PM 还是 PM 吗
回过头看 Cat Wu 描述的这些变化，会发现一件正在发生的事：
她说的「PM 新活法」，其实已经不像传统意义上的产品经理了。
PRD 已死，原型万岁。
写代码、做原型、写 eval、跟模型较劲。这跟十年前写 PRD、开评审会、协调资源的 PM 相比，基本上是两个工种。
Anthropic 内部没说出来的情况，只会更加激进。
设计师在提交代码，工程师在做产品决策，PM 在写原型和评测。角色的边界……已经快看不见了。
不只是 Anthropic 这么干。
微软 CPO Aparna Chennapragada 最近也要求团队推进新项目时，不光要写文档，还要拿出原型和对应的提示词集合。她的原话是：
在当下这个时代，如果你在做一个东西，却没有原型验证、没有实际动手去试，那你就是走偏了。
Cat Wu 的说法是：这行得通，是因为团队有清晰的战略和目标。 每个人知道方向，所以可以自主决定怎么走。
而 PM 在这个体系里的角色变成了：在模型快速进化带来的混沌中，创造清晰度。
Decagon 的产品总监 Bihan Jiang 也验证了这个趋势：
Claude 提高了优秀产品团队的能力上限，也极大缩短了从想法到原型的距离。以前把一个可用的东西放到客户面前要几周，现在我在 Claude Cowork 里拉入 Slack、代码库和文档的上下文，再转到 Claude Code 里，几个小时就能做出来。
Datadog 的高级 PM Kai Xin Tai 从另一个角度称：
PM 的技艺已经从「提前定义确定性」转向了「加速发现」。
「建造鸿沟」
如果把视野拉远一点，Cat Wu 描述的变化其实指向一个更大的趋势。
Battery Ventures 最近有篇分析文章提到，AI 时代产品团队面临的核心张力是：执行速度在加快，但方向选择在变难。
以前的瓶颈是工程产能，PM 的核心价值是排优先级、分配资源。现在的瓶颈变成了：到底该建什么？
这让我想到一个概念，姑且叫它「建造鸿沟」。
以前，从想法到产品之间隔着一条宽宽的河：需要工程师、设计师、测试、排期、开发、联调。这条河就是实现成本。PM 的工作本质上是决定哪些想法值得付出过河的代价。
现在 Claude Code 这类工具把河水抽干了。
从想法到原型，一个下午就到。
河没了，但目的地变得更多了。
你可以快速抵达一百个方向，但只有两三个是对的。
判断哪几个方向值得走，这才是新时代 PM 最核心的能力。用 Cat Wu 的话说，就是在模型快速进化带来的不确定性中，给团队创造清晰度。
Figma CEO Dylan Field 的判断的：
我们都是产品建造者，只是各自在不同领域有所专长。
角色边界模糊了，但判断力的价值，反而更大了。
提效的悖论
说到这儿，想起最近面试一位产品经理候选人时聊到的一个细节。
我问他在上一家公司的 AI 应用情况。他说，产品团队用 AI 提效了，研发团队用 AI 也提效了，但整个产品线的交付效率……几乎没变。
为什么？
因为产品团队出原型更快了，研发团队写代码也更快了，但中间那个「到底该做什么」的决策环节，反而因为选项变多而变慢了。大家能更快地做出东西，但花了更多时间在争论该做哪个东西。
这也正是 Cat Wu 文章里那个核心问题的另一个切面：实现的鸿沟在缩小，但「该做什么」的鸿沟在变大。
从「能不能做」到「该不该做」
PM 的 spec 现在几乎成了「易腐品」。
六周前写的需求，到了今天……可能已经有完全不同的解法了。Meta 的 PM 团队也在朝同样的方向走：原型优先，时刻关注模型能力边界的变化。
PM 角色的价值锚点，正在迁移。
以前是「能不能做」的把关者。现在呢，什么都能做了，PM 变成了「该不该做」的判断者。
这个变化，对于只会写文档和画原型的 PM 来说，确实有点残酷。
但对于有产品直觉、懂用户、能在模糊中找到方向的 PM 来说……
反而是最好的时代。
