最近团队里来了两个新人，入职第一周就找我要 PRD 模板。我把之前的文档模板发过去，顺手补了一句：“模板不重要，关键是动手之前想清楚要做什么。”他们愣了一下，反问：“现在 AI 工具都能一键生成 PRD 了，为什么还要自己想？”
这个问题问得特别好，它正好戳中了 AI 时代 PM 这个岗位最核心的焦虑：当写 PRD 这件曾经最耗时的活，被 AI 以“秒级”速度完成，我们这些靠 PRD 吃饭的人，剩下的价值到底是什么？
这三年我一直在做 B 端产品，从需求分析到版本落地全流程都自己跟。AI 写 PRD 这件事我不是没试过，恰恰是因为认真试过、踩过坑、也重建过工作流，才敢说一句：PRD 一键生成是真的，但这反而把 PM 的核心竞争力逼到了更上游的地方——定义问题、做决策、推动系统落地。
下面把我的实测结果、工作流重建过程、以及我对“PM 核心竞争力”的完整思考，从头到尾写清楚。这篇内容不教你怎么写 prompt 咒语，也不是什么高深理论，就是一个一线从业者被 AI 逼着重新审视自己岗位后的真实复盘。
1. 先说结论：AI 一键生成的 PRD，我上手实测了
1.1 它能做到什么程度
我这两年陆续用过几款主流的 AI 文档工具，也试过直接用大模型对话来生成 PRD。客观讲，它们生成“看起来合格的 PRD”确实没有难度。
我做过一个实验：让 AI 生成一份“B 端客户管理系统的客户标签功能 PRD”。输入一句话需求之后，30 秒内它给了一份结构完整的文档，包含背景说明、目标、用户故事、功能清单、非功能需求、验收标准，甚至还有风险分析和数据埋点建议。格式工整，章节齐全，拿去给外行看绝对挑不出毛病。
这个能力在 2022 年之前是不可想象的。以前写一份像样的 PRD，从梳理需求到出稿，至少要大半天。现在 AI 把“把信息整理成文档”这件事的成本直接打到了趋近于零。
1.2 但它经不起追问三句
我接着问了 AI 三个问题，它就露馅了。
第一个问题：“这个标签功能的核心用户是谁，他们在什么场景下使用？”AI 的回答是：“核心用户是企业销售和运营人员，他们在客户管理过程中需要更方便地对客户进行分类和筛选。”听起来没错，但等于没说。它不知道我们的客户规模是多少、用户每天处理多少条客户记录、现有分组功能为什么不够用。
第二个问题：“这个标签功能和现有的客户分组功能，在业务上到底是什么区别？”AI 开始含糊了，它分不清“分组是互斥的、标签是叠加的”这类业务语义，更不知道我们现有的分组逻辑是改还是不动。
第三个问题：“为什么每个客户最多打 5 个标签？这个数字怎么来的？”AI 给了一个非常标准的回答：“5 个标签是业界常用的上限，既能保证信息维度，又不会给用户带来操作负担。”这句话看起来专业，但完全是编的。真实答案可能是：我们查过竞品，发现多数工具支持 10 个标签，但和销售聊下来发现他们实际能用上 3 个就谢天谢地了，所以我们先定了 5 个。这个决策背后的业务调研，AI 根本不可能知道。
这三问三答让我彻底清楚了一件事：AI 生成的是“文本”，不是“方案”。它擅长把已有的信息组织成符合人类阅读习惯的文档，但它不拥有“你的”业务信息。你脑子里那些从访谈、数据、争论里攒出来的判断，它一个都没有。
1.3 类比一下你就懂了
AI 写 PRD，很像一个没见过你家户型的装修公司，给你出了一套“标准三居室装修方案”。图纸非常漂亮、工艺说明很完整、材料清单很齐全，但它不知道你家实际朝向不好、你有两个学龄前小孩需要大活动区、预算只有 15 万。你拿着这套方案直接开工，后果可想而知。
PRD 的本质是什么？它真的不是需求文档，它是“一系列经过权衡的决策的书面表达”。每一个需求条目背后，都藏着为什么做、为什么不做、为什么这么做、为什么现在做。AI 能写出这些条文的“壳”，但壳里面的“核”必须在真实业务土壤里长出来。
所以，“PRD 可以一键生成”这件事，对 PM 来说不是末日，反而像一面照妖镜：如果你过去的价值主要体现在“把想法写成文档”，那确实会被替代。但如果你真正的价值在“把模糊变成清晰、把选择变成决策”，AI 只会让你更值钱。
2. 核心壁垒一：问题定义能力——AI 只负责答题，不负责出题
2.1 你提的问题，决定了 AI 答案的质量
我发现很多被 AI 写 PRD 热潮吓到的 PM，忽略了一个最基本的逻辑：AI 是一个答案引擎，不是一个问题引擎。它能做的，是在你提出的框架内生成内容。而你提出什么问题、怎么定义这件事，它完全无法帮你。
举个真实例子。我去年接手一个老客户系统的优化项目，第一次访谈时客户提了一个非常明确的需求：“我们想要一个报表导出功能，把客户数据导成 Excel，格式要能自定义。”当时团队里的小朋友很开心：这个需求多清晰，直接让 AI 生成一份报表导出的 PRD，分分钟搞定。
我去客户现场蹲了半天，发现他们真正的痛点根本不是“导不出数据”。他们每周要写一份周报给管理层，每次都要从系统里手动抄几十个数字、截图拼表格，重复劳动至少两三个小时。所谓的“报表导出”，只是他们能想到的解决方案之一，背后真正的需求是“能不能让周报自动生成，别再让我抄数据了”。
如果直接按“报表导出”写 PRD，大概率会做一个复杂的自定义导出功能，用户依然要自己整理数据。而如果定义的问题是“减少管理层周报制作时间”，方案就可能完全不同——可能是一个固定的周报模板，甚至是一个自动推送的数据摘要。这两个方案的开发成本、用户价值完全不在一个量级。
这就是问题定义能力的价值：用户永远在表达“解决方案”，你需要去挖掘“真实问题”。AI 可以帮你把“报表导出功能”的 PRD 写得很漂亮，但它不会帮你想明白“这个导出功能到底是不是用户真正该走的路”。
2.2 实操方法：三层追问法
我在团队里带人时，教过一个特别简单但极其好用的方法，叫“三层追问法”。
第一层：用户说要什么。这一步是听——用户说要报表导出、要客服机器人、要消息提醒，记下来就好。
第二层：他为什么要这个。这一步是问——为什么要导出报表？因为要写周报。为什么要客服机器人？因为咨询太多回复不过来。
第三层：这个为什么背后的场景和动机是什么。这一步是挖——写周报为什么要手动抄数据？因为系统没有汇总页，因为领导要固定格式。咨询太多为什么回复不过来？是人力不够，还是新手用户找不到设置入口导致重复咨询？如果是后者，做一个优化引导流程的方案，比做一个客服机器人便宜 10 倍，见效还更快。
三层追问法的核心逻辑是：当你追到第三层，往往会发现用户最初提的需求根本不是问题的答案。而 AI 能工作的前提，恰恰是你已经拿到了第三层的信息。换句话说，AI 把你从“打字员”的角色里解放出来后，你需要把更多时间花在“跑到现场挖第三层”上面。
2.3 问题定义能力会越来越值钱
现在这个时代，信息获取成本趋近于零。任何一个需求方向，你都能在网上找到大量资料、竞品案例、行业分析。AI 可以在几秒钟内帮你汇总 50 个竞品的功能对比。但这恰恰让“定义值得解决的问题”这件事变得空前稀缺。
因为信息越丰富，噪声越多，方向选择的风险越大。你在错误的问题上投入资源，AI 只会加速这个错误。你想清楚了一个正确的问题，AI 能帮你更快地把它落地成文档、方案、代码。所以 AI 时代 PM 的第一核心竞争力，不是会写文档，而是会提问题。
提问题的对象也不只是用户。你要向数据提问题——为什么这个页面流失率异常高？向业务方提问题——你们说“操作效率低”，是指哪条链路、哪类操作？也要向自己提问题——我做的这个功能，上线后用户行为到底会发生什么实质变化？如果答不上来，这个功能大概率不值得做。
这个能力没法外包给 AI，因为它依赖的是你对行业、用户、业务的长期浸泡和直觉积累。
3. 核心壁垒二：决策与取舍——PRD 不是文档，是一本决策簿
3.1 让 AI 排优先级，它只会给你一堆 P0
真正让我坚定“AI 替代不了 PM”信念的，是一次优先级排序的实战。
当时我们要做数据看板 2.0 的升级，需求池里躺着 20 多个功能点，从“自定义图表”到“看板分享”到“数据预警”到“导出周报”，五花八门。我刻意做了个测试：把需求池丢给 AI，让它排一个优先级。
AI 给出的结果非常标准：按 P0/P1/P2 分类，P0 放了 9 个功能，每个功能下面配了一段“重要性说明”。乍一看没毛病，但你仔细品，它排 P0 的逻辑是“这个功能很常用”“这是用户高频需求”“市面上的竞品都有”。它没有任何资源概念——不知道我们后端只有 1 个人，不知道其中 3 个功能依赖一个还没建好的数据仓库，不知道老板说这个季度只做“能提升付费转化率”的事。
真正的优先级排序是一场多约束条件下的决策博弈。你要同时考虑业务目标、用户价值、开发成本、技术依赖、阶段策略、甚至团队士气。我最后把 P0 砍到了 4 个，砍掉了 5 个“看起来合理但现阶段没有明确收益”的功能，还把 2 个依赖项提前到后端的排期里。这个决策过程 AI 帮不了，因为每个“砍”和“留”背后的理由，都是一次对业务理解的综合判断。
3.2 优先级排序的正确姿势：先定权重，再打分
我带团队做优先级，从来不用“我感觉”，也不直接听 AI 的分类。我用的是一套改良版的 RICE 打分框架：Reach（影响范围）、Impact（影响程度）、Confidence（信心指数）、Effort（开发成本）。
RICE 的公式很简单：分数 = (影响人数 × 影响程度 × 信心指数) ÷ 开发成本。看着像一个纯数学的过程，但这里面最关键的一步是：每个维度的输入值，必须由人来定。
“影响人数”是 100 还是 5000？需要看数据。 “影响程度”是 0.5 还是 2？需要业务判断。 “信心指数”是 50% 还是 90%？需要看调研深度。 “开发成本”是 1 周还是 1 个月？需要和技术聊。
AI 可以在你给出所有输入值之后，帮你算分数、做排序、生成对比表。但它永远不可能替你去定义这些输入值。而这些输入值的定义过程，恰恰是 PM 最核心的脑力劳动。
更关键的是，RICE 打分的结果从来不是直接采纳的。它只是一个决策辅助工具。我经常在打分之后调整：某个功能分数很高，但和我们本季度的阶段目标不一致，我会把它往后放。这种“跳出模型做判断”的能力，是任何算法都给不了的。
3.3 敢于砍需求，才是真本事
我发现一个特别有意思的现象：AI 生成需求清单时，永远是做加法的。你让它列功能，它会尽量列全；你让它列异常场景，它会列满屏；你让它排优先级，它也舍不得砍。因为 AI 没有“成本”的概念，它觉得多写一行字不需要付出任何代价，所以多列一个功能毫无压力。
但真实世界不是这样的。每一个功能都是成本：开发的时间、测试的精力、后续的维护、用户的学习成本、产品复杂度的提升——这些都是隐性的代价。所以 PM 最重要的一项能力，其实是“砍需求的能力”。
怎么判断一个需求该不该砍？我自己的检验标准很简单：如果这个功能上线了，用户的某个行为概率会发生可感知的变化吗？会改变一个核心指标吗？如果答不上来，说明我们对这个功能的价值根本没有想清楚，与其勉强做，不如先砍掉。
我举一个真实的砍需求案例。上个季度我们做“列表页增强”，需求池里有“支持多字段组合筛选”“保存筛选条件”“自定义列表字段展示”“列表列宽拖拽调整”“表格行内快捷编辑”等七八个功能。团队都很兴奋，觉得每一个都有人提过。评审时我挨个问“用户行为会发生什么可感知变化”：保存筛选条件——高频用户减少重复操作，有明确价值，保留；列宽拖拽——纯粹是体验细节，用户不会因此更频繁使用产品，砍；行内快捷编辑——需要改动底层数据交互逻辑，风险高，而且用户编辑错误后没有二次确认入口，现阶段不做。
最后这期只做了 3 个功能，上线后核心指标还提升了。这就是砍需求带来的价值：少做一件事，往往比多做一件事更能让产品变好。
4. 核心壁垒三：系统推演与跨团队翻译——PRD 之后的半场更关键
4.1 PRD 只是起点，不是终点
很多 PM 有一个根深蒂固的误解，觉得写完 PRD 就等于完成了 80% 的工作。以前 AI 还没普及的时候，写 PRD 确实要花很多时间，所以人们容易产生一种“写完 PRD 已经耗尽心力”的错觉。但真相是，PRD 只是整个产品落地过程中的一个中间产物。
一份 PRD 交出去之后，真正的硬仗才刚刚开始：开发会在实现细节里提出十几二十个边界问题；设计要理解目标用户的心智模型才能画出可用的界面；测试要根据验收标准推演各种异常路径；上线后还要结合数据和用户反馈判断当初的假设是否成立。
这一整段“从 PRD 到上线”的路，AI 目前跑不了。因为这段路上需要的不是文档能力，而是系统推演能力和跨团队协调能力。
4.2 在脑子里跑一遍全链路：订单状态改动案例
我讲一个特别典型的例子。当时我们电商系统要增加一个“部分发货”状态，需求很简单——买多个商品时，仓库先发了一部分，订单需要显示成“部分发货”而不是一直卡在“待发货”。
拿到这个需求后，我没有立刻写 PRD，而是在脑子里把整个系统跑了一遍：
订单状态机——新增一个状态节点，意味着要定义状态流转规则：哪些状态可以进入“部分发货”？从“部分发货”又能流转到哪些状态？
库存体系——部分发货后，剩余商品的库存怎么扣减？如果用户退货了已发货的部分，库存怎么回补？
支付逻辑——如果订单支持分批支付，用户还需要补尾款吗？“部分发货”状态下用户的支付入口该怎么显示？
售后流程——用户要对已发货商品发起“仅退款”，但订单里还有未发货商品，这个售后单怎么处理？
消息通知——每一次状态变化，用户是否需要收到通知？通知文案怎么写才能让人不困惑？
数据报表——现有订单统计口径是按状态过滤的，“部分发货”这个新状态会不会让某些统计数字失真？
这一圈推演下来，我梳理出了 16 个需要明确的问题，然后拿着这些问题去找技术负责人逐条对齐，最终落地成补充方案写到 PRD 里。这部分工作，AI 一丁点忙都帮不上——它不知道我们的订单系统有哪些状态、库存怎么扣、支付回调怎么走、历史数据长什么样。它只知道“部分发货”这四个字在很多电商文档里的标准写法。
这就是系统推演能力的价值：你必须在头脑里建立一个关于自己产品的动态模型，知道改一个地方会牵动哪些地方。这个模型只能来自长期的业务浸泡和对系统设计的敏感度，任何通用的大模型都不可能替你建立你这个产品特有的“关系网”。
4.3 跨团队翻译官：同一个 PRD，说给不同的人听
系统推演解决的是“这件事会牵动什么”，跨团队翻译解决的是“如何让每个角色理解自己该做什么”。同样一份 PRD，给不同的人讲，重点完全不一样。
跟开发讲，重点是约束和异常：状态流转规则是什么、边界条件有哪些、哪些旧的逻辑不能动。跟设计讲，重点是用户心智：目标用户在使用这个功能时处于什么情绪状态、他期望看到什么反馈。跟测试讲，重点是校验路径：正常流程、异常流程、极端情况，每种情况下的预期结果。跟老板讲，重点是业务贡献：这个状态新增后，能解决多少用户投诉、能减少多少售后咨询。
这些“翻译”工作看似只是沟通技巧，背后其实要求 PM 对业务的每一层都有足够理解。你没法给开发讲清楚状态流转，说明你没想清楚系统；你没法给设计讲清楚用户心境，说明你没做过用户研究；你没法给老板讲清楚业务价值，说明你没想清楚目标。
AI 能帮你整理一份漂亮的 PRD，但它没法替你在评审会上回答开发提出的“如果用户在下单过程中改了地址怎么办”这种问题——因为那个具体问题的答案，只存在于你这个产品经理对系统现状的理解里。顺带说一句，我每次写 PRD 之前都有一个小习惯：先自己画一张系统模块关系图，把自己产品里和本次改动相关的模块列出来，标出数据流向。这张图不一定要给别人看，它是帮我自己把系统推演做扎实的。
5. 我的实操工作流：AI 辅助写 PRD 的正确姿势
5.1 总原则：AI 做扩写和检查，人做定义和删减
我很清楚，完全不用 AI 写 PRD，是在把自己退化成打字机；完全让 AI 写 PRD，是在把产品方案的质量交给概率。我现在的做法是分工协作：AI 做“从 1 到 100”的扩写和“从 100 到 1”的检查，人做“从 0 到 1”的定义和“从 100 到 1”的删减。
用一句话概括：定义和决策我来，扩写和审查交给 AI。这套流程我用了大半年，效果非常稳定，写一份中等复杂度的 PRD，从原来的两天缩短到半天，而且质量反而更高了。
5.2 四步工作流：决策卡 → AI 扩写 → 人工删减 → AI 审查
第一步，我先写一张“决策卡”，大概 30 分钟。这张卡不需要长，但必须包含五个要素：功能名称、目标用户、业务目标、关键约束、明确不做。这五要素其实就是我在第二部分和第三部分讲的问题定义和决策取舍的浓缩版。
第二步，把决策卡丢给 AI 扩写。我会告诉它我的角色定位、功能背景、目标用户、业务目标和约束条件，然后让它生成一份结构完整的 PRD 草稿。这一步 15 分钟就能完成，AI 会帮我把背景、目标、功能清单、非功能需求、异常场景、验收标准这些章节都补全。
第三步，我花 45 分钟做删减和精修。AI 生成的草稿里至少有 30% 的内容是空话和泛泛之谈，比如“提升用户体验”“保证系统稳定性”这种正确的废话。我会把这类内容删掉或改成有具体衡量的描述。同时我会把我在系统推演阶段想到的边界问题、异常流程、业务细节补齐进去。这一步是整个工作流里最不能省的部分。
第四步，让 AI 做一致性审查。我会把它当成一个“挑刺的评审人”，让它检查需求条目之间有没有矛盾、字段名称和状态定义是否一致、有没有遗漏重要的异常场景。这一招特别好用，AI 在逻辑一致性检查上比人细致得多。
5.3 一份可以直接参考的决策卡示例
为了让你能直接上手，我把之前“客户标签功能”的决策卡示例贴出来。
你是一位有 10 年经验的 B 端产品经理，请根据下面的决策信息，撰写一份结构完整的 PRD 草稿。 决策信息： - 功能定位：客户管理列表中的轻量标签功能 - 目标用户：销售运营人员，每天大约处理 50 条客户记录 - 业务目标：让用户对客户的分类和筛选效率提升 30% - 关键约束：标签上限 20 个；现阶段不做权限改造；需兼容现有导出逻辑 - 明确不做：不做自动打标签，不做标签推荐 - 上线节奏：MVP 版本只支持人工打标签和按标签筛选 请包含以下章节：需求背景、业务目标、用户场景、功能清单、功能详细说明、非功能需求、异常场景、数据埋点建议、验收标准。注意，这里最关键的不是最后的“请包含以下章节”，而是中间那六条决策信息。这些信息才是 AI 生成内容质量的决定性因素。你给的信息越具体、越有业务判断，AI 生成的东西就越像你自己的方案。你如果只丢一句“帮我写个客户标签功能的 PRD”，那 AI 就只能从全网文章里拼一个通用版本给你——你拿到的当然不落地。
5.4 PM 日常任务：哪些可以交给 AI，哪些必须自己做
我把 PM 日常工作中常见的任务分成三类，列成一个表，方便你对照参考。
| 任务 | 是否建议交给 AI | 原因 |
|---|---|---|
| PRD 初稿扩写 | 建议 | AI 能把决策卡扩展成完整文档，节省大量时间 |
| 竞品功能整理 | 建议 | AI 擅长从公开信息里提炼竞品共性能力 |
| 异常场景列举 | 建议 | AI 可以列出你没想到的边缘场景，是很好的补充 |
| 需求背景推导 | 部分建议 | AI 可以帮你完善表达，但真实背景必须由你调研 |
| 用户访谈 | 不建议 | 你需要听到用户的语言、语气、犹豫，这是信息密度最高的部分 |
| 优先级排序 | 不建议 | 权重设定依赖资源、目标、技术约束，AI 没有这些输入 |
| 系统推演 | 不建议 | AI 不了解你系统的模块、数据流和历史包袱 |
| 评审纪要与待办跟踪 | 建议 | AI 能快速整理会议要点，提高工作效率 |
这个表是我实践下来的判断。核心逻辑就一条：AI 适合处理“有明确输入的信息整理”，不适合处理“没有明确输入的价值判断”。
6. 避坑清单与我的真实体会
6.1 常见问题速查：你有没有踩过这些坑
问题一：“AI 写的 PRD 看起来挺全的，为什么评审时还是被开发问得哑口无言？”
因为 AI 生成的内容是“全面”而不是“正确”。它把背景写得头头是道，但这些背景是它编出来的，你一问细节就露馅。我的建议是：AI 生成的文档在评审前必须经过你的“业务真实性检查”——背景里的每个数据都有来源吗？功能逻辑在真实场景里站得住脚吗？如果站不住，不要拿去评审。
问题二：“是不是以后 PM 这个岗位会消失？”
我的看法是：会消失的是“写文档的 PM”，消失不了的是“做决策的 PM”。你如果每天的工作主要是把别人的想法整理成文档，那你确实危险。你如果每天的工作是搞清楚用户要什么、判断这个需求该不该做、协调团队把它落地，那 AI 反而是你的杠杆。
问题三：“我用 AI 生成的东西总是不落地，是我 prompt 写得不好吗？”
多数时候不是 prompt 的问题，是你没有给它足够的决策信息。你把需求背景、目标用户、业务约束、明确不做的事项都给它，它生成的方案立刻就不一样了。与其花时间学各种提示词技巧，不如把时间花在把你想做的方案想清楚。方案想清楚了，哪怕你提示词写得粗糙，结果也不会差。
问题四：“我现在写 PRD 是不是彻底不用管格式了？”
恰恰相反。格式还是要管，但不用你亲自管了。以前调格式、排版、维护版本，占了很多时间。现在 AI 能把这些琐事做好，你可以把精力放在格式背后的逻辑一致性上。比如字段定义是否统一、需求之间是否矛盾、边界场景是否覆盖——这些“内容的格式”问题，才是 PM 要盯的。
6.2 三个危险信号，中一个就要警惕
第一个信号：拿到 AI 生成的 PRD 直接发评审。这说明你已经把文档当成了目的，而不是手段。你连这些需求到底解决什么问题都说不清楚，评审会大概率变成车祸现场。
第二个信号：你发现自己很久没有见过用户了。AI 时代最大的诱惑是，你觉得什么都能在对话里完成，不用再跑现场。但长期不见用户的 PM，会逐渐失去对真实场景的感知，最后做出来的方案会越来越悬浮。我现在强制自己每周至少和用户聊两次，哪怕就是翻翻客服工单和用户反馈，也比整天对着对话框强。
第三个信号：团队开始讨论“这份 PRD 是 AI 写的”而不是“我们应该做什么”。这说明产品决策过程已经被工具带偏了。工具应该是无声的助手，不应该成为讨论的中心。如果你发现大家开始比拼“谁用 AI 写得快”，而不是“谁想得更清楚”，就该停下来反思团队的产品文化了。
6.3 我实际用下来最大的变化
最后说点个人体会。AI 大规模介入我的工作流之后，我最直观的感受是：我比以前更敢于去做那些“慢”的事情。
以前一份 PRD 要写两天，我没时间也没勇气去客户现场泡半天、去抠一个需求背后的真实动机。现在 AI 把写文档的时间压缩到了半小时，我多出来的时间，全投在了用户访谈、业务调研、系统推演、跨团队对齐上。这些事情的回报率，远高于把文档写得一字不差。
我越来越觉得，PRD 一键生成这件事，真正改变的不是 PM 这个岗位的存亡，而是它逼着所有 PM 回答一个本来就应该回答的问题：你到底是在做文档的搬运工，还是在做产品决策的掌舵人？
我自己的答案是后者。而且有了 AI 之后，这个答案比任何时候都更清晰。
