最近团队里来了两个新人入职第一周就找我要 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 之后这个答案比任何时候都更清晰。