当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 自己的日常是这么分的：三个工具，三个角色。
说白了，不是把 AI 当成一个搜索引擎来用，而是让 AI 渗透到你工作的不同环节，扮演不同角色。
这一点，另一家公司的产品负责人 Jess Yan 也是这么干的。她给自己搭了一套 Managed Agents：一个专门跑用户数据分析、一个专门监控开发者社区情绪、一个专门搭 Demo。过去这些事需要跨部门协调、填各种表格、催各种排期。现在？几个 Agent 在后台 7×24 小时跑着。
光换工具不够，工作方式本身也得变。
Cat Wu 总结了四个转变，我觉得每一个都值得咱们 PM 想一想。
以前做产品规划，恨不得排满接下来两个季度的 roadmap，每个功能写十几页 PRD，然后等排期、等开发、等测试。
现在？鼓励做 “Side Quest”——支线任务。 上午有个想法，下午就用 Claude Code 把原型跑出来。能跑通的，再决定要不要投入资源。跑不通的，就当是一次快速的实验。
我太理解这个转变了。以前写 PRD，花大量时间推敲每一个字段、每一个交互细节，生怕漏了什么。结果评审的时候，大家对着文档争论半天，谁也说不清”这东西做出来到底长什么样”。
现在流程反过来了：先让 Claude Code 把原型搭出来，再拿原型去和团队讨论。文档负责记录”被验证过的事实”，而不是”还没发生的假设”。
这个转变很有意思。过去我们总觉得功能做完了就完了，顶多修修 bug、加加小优化。
但现在的 AI 模型，16 个月能力提升了大概 41 倍（这不是夸张，是 METR 的实测数据）。你今天觉得”这个 AI 做不了”的事，半年后可能就轻轻松松了。所以 Cat Wu 团队的做法是：每次新模型发布，回头看一遍旧功能——有没有之前因为模型能力不够而做得不够好的？现在该升级了。
这个我觉得是最高级的思考。很多团队为了绕开 AI 的局限，设计非常复杂的流程和工作区。
但 Cat Wu 的建议是：”Do the simple thing that works。” 做那个简单但有效的方案。因为模型能力在以肉眼可见的速度变强，你今天打的补丁，明天可能就不需要了。
后来她说了句话让我印象很深：”你要围绕的约束条件，可能在项目进行到一半时就消失了。你脚下的大地在上升。”
聊完了理念，说点实际的。到底哪些工作流，是 AI 最能帮 PM 提效的？
结合业内实践，我觉得最值得投入的 6 个场景是这样的：
传统做法：PRD → 评审 → 排期 → 开发 → 至少两周才有第一个版本。
现在：Markdown 写 PRD → 扔给 Claude Code / Codex → 20 分钟出可运行原型。
拿给用户一测，方向对了继续，不对了改。迭代成本从”两周”降到”一顿午饭的时间”。
假设你要做一个”用户反馈中心”的功能。
用 AI Code 工具中，你只需要在项目目录下跑：
“`
/plan “为我们的 SaaS 产品搭建一个用户反馈中心，包含：
– 用户可以提交文字反馈 + 截图
– 反馈列表页按状态筛选（待处理/处理中/已完成）
– 后台回复功能
先出一版可交互的 HTML 原型”
“`
非技术出身的 PM，最怕的就是”这个功能技术上能不能做”这个问题。以前得追着工程师问，问多了自己都不好意思。
现在？用 Claude Code 的 Plan Mode，直接在代码库里提问。只问不修改，没有任何风险。比如”帮我看一下这个页面的数据是从哪里来的”、”我们的支付流程是怎么校验的”。
你作为 PM，需要了解”用户邀请功能”的技术实现，好评估要不要改逻辑。
用 Claude Code 的话，在终端输入：
“`
/plan “帮我梳理用户邀请功能的完整流程：
1. 邀请功能的入口在哪个页面
2. 邀请链接是怎么生成的
3. 被邀请人点击后走了什么流程
4. 相关的数据库表和字段有哪些
不需要修改任何代码，只做分析”
“`
Claude Code 会读取相关代码文件，用流程图和文字说明完整的数据流向。你不需要打开一行代码，就能跟工程师说”我建议改一下邀请链接的过期逻辑”。
产品经理每天都在和数据打交道。漏斗分析、留存曲线、功能使用率……以前得找数据分析师帮忙，或者自己硬着头皮写 SQL。
现在直接把 CSV 扔给 Claude / Codex，用自然语言让它帮你分析。 比如”帮我看看这个月的用户流失主要发生在哪一步”、”按地区分组算一下付费转化率的差异”。
你这个月发现用户留存率掉了。你手头有一份 CSV，包含用户注册日期、最近登录日期、付费状态、地区。
用 Claude.ai 的话，直接把 CSV 拖进去，然后输入：
“`
分析这份用户数据，回答我：
1. 这个月的留存率跟前几个月比掉了多少
2. 流失用户主要集中哪一类（按注册时长/地区/付费与否分组）
3. 有没有哪个阶段的用户流失最严重
4. 用表格输出，按流失率从高到低排列
“`
Claude 会写 Python 代码分析数据，并直接生成表格和图表。你不用装任何数据分析工具。
写周报、写发布说明、写 Jira ticket——这些事情占 PM 大量时间，但是创造性最低。
把原始素材扔给 AI，让它帮你生成初稿，你只需要审核和调整。
周四下午，你要写周报了。你手头有：这周写的 PRD 链接、几次评审的结论、几个数据指标的变化。
用 Claude.ai 的话，把这些素材整理一下贴进去：
“`
帮我生成这周的产品周报，包含：
– 本周完成事项（重点突出用户反馈中心 PRD 已完成评审）
– 关键数据（注册转化率从 3.2% 提升到 3.8%）
– 下周计划（反馈中心进入开发、开始调研搜索优化）
– 阻塞项（等待设计资源，缺一个前端支持）
语气正式一点，适合发给全团队。
“`
Claude 直接输出完整的周报，你改改措辞就能发。
做了 10 场用户访谈，积累了 50 页记录。以前得花一两天手动提取关键主题。现在把记录喂给 AI，让它帮你提取核心主题、痛点和机会点。
你刚做完 8 场用户访谈，记录了用户对新版 Dashboard 的反馈。一堆零碎笔记，不知道怎么提炼。
用 Claude.ai 的话，把所有访-谈笔记粘贴进去（或者上传录音转写的文字）：
“`
以下是 8 场用户访谈的笔记，帮我分析：
1. 用户提到最多的 Top 5 痛点是什么，各出现了几次
2. 用户对当前 Dashboard 最满意的 3 个点
3. 有没有矛盾的反馈（一部分人说好、一部分人说不好）
4. 最急需改进的 3 个机会点，并说明理由
用表格输出，按提及频率排序。
“`
Claude 会逐条阅读、计数、提炼，直接输出结构化的分析报告。原本一两天的工作，现在一小时搞定。
这个对技术门槛稍微高一点点，但价值也最大。
通过 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 几乎都能帮你搭把手。
最后聊一个我在调研时看到的案例，觉得特别有启发。
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，是能快速把想法变成原型、再用数据验证、最后用文档沉淀的人。
本文由人人都是产品经理作者【王耑】，微信公众号：【职场产品人】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。