当Claude Code能在两小时内产出可交互原型时，传统PRD的权威性正在崩塌。本文通过Anthropic团队的实战案例，揭示AI如何重构产品验证流程——从20页文档的纸上谈兵，到用原型直接对话用户。更值得关注的是，PM正从需求传递者升级为原型构建者，这种角色进化将彻底改写产品开发规则。

我最近看到一句话，愣了好一会儿。”一个运营同事用 Claude Code 鼓捣了两个多小时，跑出来一个能点击的原型。拿着原型问了五个目标用户后，发现团队花了三周争论的『标签自定义 vs 系统预设』用户根本不在乎——用户真正想要的是『反馈提交后能看到处理进度』。这个需求在二十页 PRD 里只有半句话。”

二十页的 PRD，不如两小时的原型。这话不是我说的，是 Anthropic Claude Code 的产品负责人 Cat Wu 在一次分享里提到的真实案例。她所在的团队，正在用自己做的产品重新定义产品经理的工作方式。

问题来了：当 AI 工具以肉眼可见的速度进化，咱们 PM 的工作流，到底应该怎么变？

你的工具箱，该升级了

我们先聊一个基础问题：你现在怎么用 AI？

我猜大部分 PM 的状态是——偶尔打开 ChatGPT 或 Claude 官网，让它帮忙写个周报、改个文案、或者搜点竞品信息。用完就关，下次再用。

这没错，但有点浪费。

Cat Wu 自己的日常是这么分的：三个工具，三个角色。

1. Claude.ai（或者 ChatGPT、Codex 的对话界面）——当思考搭子用。讨论战略方向、理清思路、写文档草稿。这块是纯聊天，不涉及执行。
2. Claude Code（或者 Cursor、Codex 的编辑器模式）——当执行工具用。写原型、跑数据分析、搭脚本。只要是能输出代码的事，都扔给它。
3. 日常效率工具——清邮箱、做 PPT、搜历史决策、订差旅。这些琐事，也让 AI 帮手搞定。

说白了，不是把 AI 当成一个搜索引擎来用，而是让 AI 渗透到你工作的不同环节，扮演不同角色。

这一点，另一家公司的产品负责人 Jess Yan 也是这么干的。她给自己搭了一套 Managed Agents：一个专门跑用户数据分析、一个专门监控开发者社区情绪、一个专门搭 Demo。过去这些事需要跨部门协调、填各种表格、催各种排期。现在？几个 Agent 在后台 7×24 小时跑着。

PM 工作流的四大转变

光换工具不够，工作方式本身也得变。

Cat Wu 总结了四个转变，我觉得每一个都值得咱们 PM 想一想。

转变一：从长路线图到短冲刺

以前做产品规划，恨不得排满接下来两个季度的 roadmap，每个功能写十几页 PRD，然后等排期、等开发、等测试。

现在？鼓励做 “Side Quest”——支线任务。 上午有个想法，下午就用 Claude Code 把原型跑出来。能跑通的，再决定要不要投入资源。跑不通的，就当是一次快速的实验。

转变二：从”文档先行”到”Demo 先行”

我太理解这个转变了。以前写 PRD，花大量时间推敲每一个字段、每一个交互细节，生怕漏了什么。结果评审的时候，大家对着文档争论半天，谁也说不清”这东西做出来到底长什么样”。

现在流程反过来了：先让 Claude Code 把原型搭出来，再拿原型去和团队讨论。文档负责记录”被验证过的事实”，而不是”还没发生的假设”。

转变三：每次模型更新，重新审视旧功能

这个转变很有意思。过去我们总觉得功能做完了就完了，顶多修修 bug、加加小优化。

但现在的 AI 模型，16 个月能力提升了大概 41 倍（这不是夸张，是 METR 的实测数据）。你今天觉得”这个 AI 做不了”的事，半年后可能就轻轻松松了。所以 Cat Wu 团队的做法是：每次新模型发布，回头看一遍旧功能——有没有之前因为模型能力不够而做得不够好的？现在该升级了。

转变四：做简单有效的方案

这个我觉得是最高级的思考。很多团队为了绕开 AI 的局限，设计非常复杂的流程和工作区。

但 Cat Wu 的建议是：”Do the simple thing that works。” 做那个简单但有效的方案。因为模型能力在以肉眼可见的速度变强，你今天打的补丁，明天可能就不需要了。

后来她说了句话让我印象很深：”你要围绕的约束条件，可能在项目进行到一半时就消失了。你脚下的大地在上升。”

PM 的 6 个高价值 AI 工作流

聊完了理念，说点实际的。到底哪些工作流，是 AI 最能帮 PM 提效的？

结合业内实践，我觉得最值得投入的 6 个场景是这样的：

1. PRD → 原型 流水线

传统做法：PRD → 评审 → 排期 → 开发 → 至少两周才有第一个版本。

现在：Markdown 写 PRD → 扔给 Claude Code / Codex → 20 分钟出可运行原型。

拿给用户一测，方向对了继续，不对了改。迭代成本从”两周”降到”一顿午饭的时间”。

假设你要做一个”用户反馈中心”的功能。

用 AI Code 工具中，你只需要在项目目录下跑：

“`
/plan “为我们的 SaaS 产品搭建一个用户反馈中心，包含：
– 用户可以提交文字反馈 + 截图
– 反馈列表页按状态筛选（待处理/处理中/已完成）
– 后台回复功能
先出一版可交互的 HTML 原型”
“`

2. 代码库探索

非技术出身的 PM，最怕的就是”这个功能技术上能不能做”这个问题。以前得追着工程师问，问多了自己都不好意思。

现在？用 Claude Code 的 Plan Mode，直接在代码库里提问。只问不修改，没有任何风险。比如”帮我看一下这个页面的数据是从哪里来的”、”我们的支付流程是怎么校验的”。

你作为 PM，需要了解”用户邀请功能”的技术实现，好评估要不要改逻辑。

用 Claude Code 的话，在终端输入：

“`
/plan “帮我梳理用户邀请功能的完整流程：
1. 邀请功能的入口在哪个页面
2. 邀请链接是怎么生成的
3. 被邀请人点击后走了什么流程
4. 相关的数据库表和字段有哪些
不需要修改任何代码，只做分析”
“`

Claude Code 会读取相关代码文件，用流程图和文字说明完整的数据流向。你不需要打开一行代码，就能跟工程师说”我建议改一下邀请链接的过期逻辑”。

3. 数据分析

产品经理每天都在和数据打交道。漏斗分析、留存曲线、功能使用率……以前得找数据分析师帮忙，或者自己硬着头皮写 SQL。

现在直接把 CSV 扔给 Claude / Codex，用自然语言让它帮你分析。 比如”帮我看看这个月的用户流失主要发生在哪一步”、”按地区分组算一下付费转化率的差异”。

你这个月发现用户留存率掉了。你手头有一份 CSV，包含用户注册日期、最近登录日期、付费状态、地区。

用 Claude.ai 的话，直接把 CSV 拖进去，然后输入：

“`
分析这份用户数据，回答我：
1. 这个月的留存率跟前几个月比掉了多少
2. 流失用户主要集中哪一类（按注册时长/地区/付费与否分组）
3. 有没有哪个阶段的用户流失最严重
4. 用表格输出，按流失率从高到低排列
“`

Claude 会写 Python 代码分析数据，并直接生成表格和图表。你不用装任何数据分析工具。

4. 文档自动化

写周报、写发布说明、写 Jira ticket——这些事情占 PM 大量时间，但是创造性最低。

把原始素材扔给 AI，让它帮你生成初稿，你只需要审核和调整。

周四下午，你要写周报了。你手头有：这周写的 PRD 链接、几次评审的结论、几个数据指标的变化。

用 Claude.ai 的话，把这些素材整理一下贴进去：

“`
帮我生成这周的产品周报，包含：
– 本周完成事项（重点突出用户反馈中心 PRD 已完成评审）
– 关键数据（注册转化率从 3.2% 提升到 3.8%）
– 下周计划（反馈中心进入开发、开始调研搜索优化）
– 阻塞项（等待设计资源，缺一个前端支持）
语气正式一点，适合发给全团队。
“`

Claude 直接输出完整的周报，你改改措辞就能发。

5. 用户研究综合

做了 10 场用户访谈，积累了 50 页记录。以前得花一两天手动提取关键主题。现在把记录喂给 AI，让它帮你提取核心主题、痛点和机会点。

你刚做完 8 场用户访谈，记录了用户对新版 Dashboard 的反馈。一堆零碎笔记，不知道怎么提炼。

用 Claude.ai 的话，把所有访-谈笔记粘贴进去（或者上传录音转写的文字）：

“`
以下是 8 场用户访谈的笔记，帮我分析：
1. 用户提到最多的 Top 5 痛点是什么，各出现了几次
2. 用户对当前 Dashboard 最满意的 3 个点
3. 有没有矛盾的反馈（一部分人说好、一部分人说不好）
4. 最急需改进的 3 个机会点，并说明理由
用表格输出，按提及频率排序。
“`

Claude 会逐条阅读、计数、提炼，直接输出结构化的分析报告。原本一两天的工作，现在一小时搞定。

6. MCP 集成

这个对技术门槛稍微高一点点，但价值也最大。

通过 MCP（Model Context Protocol），让 AI 工具直接连接你的工作系统。Linear、Jira、Notion、Slack、PostHog……AI 可以读、可以写、可以查。

举个例子：你可以让 Claude Code “帮我把 PostHog 上这个功能的 7 日留存率拉出来，然后在 Linear 创建一个优化需求”，它自己就把事办了。

你发现最近用户反馈说”导出报表太慢”，你想排查一下这个问题在数据层面是否成立，然后直接创建优化任务。

用 Claude Code（已配置 PostHog MCP + Linear MCP）：

“`
/plan “帮我做两件事：
1. 去 PostHog 查一下「报表导出」功能最近 7 天和 30 天的平均耗时，跟之前两个月对比有没有明显上升
2. 如果确实变慢了，在 Linear 创建一个 Bug 任务，标题是「报表导出响应时间异常」，标签设为 performance，优先级 P1，指派给后端团队”
“`

Claude Code 先调 PostHog API 拉数据做对比，确认趋势后直接在 Linear 创建了 Ticket。全程不到 2 分钟，你不用离开终端。

这 6 个工作流，不是说都要立刻上手。选一个最有痛点的先试，跑通了再扩展。

有意思的是，你会发现这 6 个工作流覆盖了 PM 工作的大多数环节——从需求挖掘到原型验证，从数据分析到文档输出，从用户研究到系统集成。除了那些需要面对面沟通的事，AI 几乎都能帮你搭把手。

“80% 原型”：PM 的新交付物

最后聊一个我在调研时看到的案例，觉得特别有启发。

Luciq（一家移动可观测性公司）的产品经理，直接用 Claude Code 搭建了完整的产品原型。*不是 Figma 线框图，是能点、能交互、能跑通业务流程的那种。

有多夸张呢？一天迭代 50 次。

PM 在一个功能上从 v1 改到 v15，完全自己搞定。做到 80% 完成度——核心流程跑通了、交互逻辑对了、设计决策 80% 确定了——然后交给工程师收尾。工程师只需要处理认证、安全加固、feature flags 这些生产环境的事情。

实际交付的产品叫 Luciq Lens，一个自然语言仪表盘界面。这位 PM 用了 3 周，独立构建了完整界面——FastAPI proxy、3 个 UI 面、fuzzy matching、测试套件，全是一个人搞定的。

你想想，以前这个流程要多久？产品经理写 PRD，交互设计师出原型，UI 设计师出视觉稿，前端工程师写代码……光沟通成本就不止三周。而现在，一个 PM + 一个 AI 工具，三周从想法到可运行产品。

这意味着什么？PM 的角色在变。不再只是一个”提需求的人”，而是开始变成”第一个造原型的人”。你的交付物不再是几十页文档，而是一个能跑起来的、能拿去给用户验证的、能在 80% 程度上回答”要不要做”这个问题的原型。

当然，不是说 PRD 就不需要了。文档不应该出现在”验证之前”，而应该出现在”验证之后”。PRD 记录的不应该是假设，而是已经被原型和用户验证过的结论。

最后说两句

Meta 的产品经理 Zevi Arnovitz 在播客里说了句话，我觉得特别适合做结尾：”你不会被 AI 取代，你会被更会用 AI 的人取代。”

我挺认同的。AI 不会让 PM 失业，但 AI 会重新定义”什么样的人是一个好 PM”。

以前的好 PM，是能把需求写清楚的人。以后的好 PM，是能快速把想法变成原型、再用数据验证、最后用文档沉淀的人。