推荐语

当技术迭代快过文档更新，Anthropic产品团队用原型取代PRD，重新定义敏捷开发。

核心内容：
1. 技术迭代速度颠覆传统产品开发流程
2. Anthropic的Side Quest创新验证机制
3. 从文档驱动到原型驱动的范式转变

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

PRD 已死，原型万岁：Anthropic 产品经理的新活法

当模型每几个月就换一代，PM 还在写 PRD 就像在沙滩上盖城堡——潮水一来，全白搭。Anthropic 的做法值得每个产品团队琢磨。

说实话，看完 Cat Wu 这篇博客，我最大的感受是：幸亏我不是 PM，不然真不知道该咋混了。

Anthropic Claude Code 的产品负责人，把他们团队现在的工作方式摊开来讲了讲。核心就一句话：传统那套玩法，彻底不够用了。

不是那种"哎呀技术变化好快啊"的感叹，而是实打实的：PM 的产出物，从文档变成了代码。

Cat Wu 打了个特别形象的比方：你在一块正在上升的地面上盖房子。

以前做产品，有一个默认前提——项目开始时技术能干嘛，结束的时候差不多还能干嘛。三个月前定的技术边界，三个月后还是那个边界。

现在呢？这前提不存在了。

她举了个自己的例子，我觉得特别能说明问题：

让 Claude Code 给 Excalidraw 加个表格功能。每隔一段时间，新模型出来了，她就测一次。

不到两年，从"不可能"到"能现场演示"。

METR 的数据更吓人：16 个月，模型能处理的任务时长从 21 分钟涨到 12 小时，41 倍的提升。

这种速度下，你精心写的三个月路线图，还没执行完，模型可能已经换了两代。你费尽心思设计的 workaround，下个版本原生就支持了。

这哪是地基在动，这是整个大陆板块在漂移。

那咋整？Anthropic 的做法挺有意思。

他们把长期路线图拆成了短冲刺，还搞了个「Side Quest」机制——就是任何人（工程师、设计师、PM 都行）有想法，可以自己花时间验证，不用走正式评审流程。

Claude Code 有几个挺受欢迎的功能，都是这么来的：

• 桌面版集成——有人觉得应该能直接在终端里用
• AskUserQuestion 工具——有人觉得模型应该能主动问用户
• Todo lists——有人觉得任务管理应该内置

这几个功能的共同点是：没人写过 PRD，没走传统评审流程。就是某天下午有人想试试，做了个原型，同事们觉得好用，就上线了。

从「想到」到「做到」，中间那条缝，快被抹平了。

这是我觉得最关键的变化。

Cat Wu 给团队的建议很直接：写完 spec，直接扔给 Claude Code，看能不能跑通。

有个团队成员 Noah，写了份 plugins 的规范，喂给模型，出来的原型质量不错，直接成了上线版本的基础。

另一个成员 Conner，手工写了一套 eval——定义什么算成功、什么算失败。这套标准成了后续迭代的锚点。

你看出来没？PM 的核心产出物，变了。

这个观点我特别喜欢。

每次新模型发布，Anthropic 会干两件事：

• 翻一遍之前的「做不到清单」，用新模型再试一次
• 删掉旧模型时代堆的 workaround

举个例子。早期模型不会主动把完成的任务勾掉，团队就在 system prompt 里加了提醒。后来新模型出了，这个行为变成原生的了，提醒就删了。

Opus 4.6 的 system prompt，比上一代精简了 20%。

今天的 hack，就是明天的技术债。但在 AI 产品领域，这个「明天」来得特别快——可能就两三个月。

Anthropic 内部有个原则，Cat Wu 反复提到：Do the simple thing。

所以她的建议是：先用最笨的方法做。如果模型今天不够好，先别急着搭复杂的脚手架。等下一代模型出来，可能这个问题就不存在了。

这话听起来有点反直觉。工程师的本能是遇到问题就解决。但在 AI 产品里，有时候最好的解法是——等等看。

写到这，你有没有发现一个问题？

Cat Wu 描述的这个「PM 新活法」，跟十年前写 PRD、开评审会、协调资源的 PM，基本上是两个职业。

写代码、做原型、写 eval、跟模型较劲——这更像是一个「能写代码的产品设计师」。

Anthropic 内部，设计师在提交代码，工程师在做产品决策，PM 在写原型和评测。角色边界，已经快看不见了。

微软 CPO Aparna Chennapragada 也要求团队：新项目不光要写文档，还得拿出原型和对应的 Prompt 集合。原话是——

Decagon 的产品总监说得更直白：以前把一个可用的东西放到客户面前要几周，现在几个小时就能做出来。

Datadog 的高级 PM 说得好：PM 的技艺，从「提前定义确定性」转向了「加速发现」。

我最近在琢磨一个概念，叫「建造鸿沟」。

以前，从想法到产品之间隔着一条河：工程师、设计师、测试、排期、开发、联调。这条河就是实现成本。PM 的核心价值是判断哪些想法值得过河。

现在，Claude Code 这类工具把河水抽干了。

从想法到原型，一个下午就能到。河没了，但目的地变得更多了——你可以快速抵达一百个方向，但只有两三个是对的。

判断哪几个方向值得走，这才是新时代 PM 最核心的能力。

写到这，我想起前几天面试一个 PM 候选人，他提到一个有趣的现象：

产品团队用 AI 提效了，研发团队用 AI 也提效了，但整个产品线的交付效率——几乎没变。

为什么？因为大家做东西更快了，但「到底该做什么」这个决策，反而变慢了。

选项变多了，争论也变多了。

这其实触及了一个核心问题：实现的鸿沟在缩小，但「该做什么」的鸿沟在变大。

PM 的核心价值，正在从「能不能做」的把关者，变成「该不该做」的判断者。

对于只会写文档、画流程图的 PM，这确实有点残酷。

但对于有产品直觉、懂用户、能在模糊中找到方向的人……这反而是最好的时代。