在一场普通的周会上某位同事把一段写得有点零散的需求描述粘进对话式AI工具三分钟后屏幕上出现了一版结构完整、格式规范、甚至带着用户故事和验收标准的PRD。会议室安静了几秒钟然后有人低声问了一句“那我们以后还写文档吗”这个问题我先后在不止一个团队里听到过。当“PRD可以一键生成”从噱头变成一个随手可用的默认选项时产品经理的“核心竞争力在哪”已经从哲学问题变成了生存问题。这篇文章想结合这段时间我和几位做PM的朋友一起做的对照实验、以及在团队里推行AI辅助需求文档写作的实际过程聊聊我的观察和答案。1. 一键生成PRD实测AI写得快但它真的会做产品吗1.1 对照实验的背景与设计先别急着下结论我们做点实际的。我找了几位在不同行业做产品经理的朋友有做电商中台的有做在线教育工具的也有做企业内部系统的让他们用同一个真实需求分别写一版PRD再用AI工具各生成一版。需求本身不算复杂某企业内部的会员积分体系要做一次改造现状是积分获取和消耗渠道都比较单一用户感知弱业务方希望提升会员活跃度和积分参与率。我特地选了一个“看起来简单、实际上坑不少”的需求因为只有这样才能看出人和AI在处理模糊信息时的差异。实验条件也做了约束AI生成时要求把需求背景、现状描述、已知限制和希望达成的目标输入进去尽量给它完整的信息人写的时候则允许翻阅历史资料、找业务方追问、看后台数据。这样对比的就不是“谁打字快”而是“谁能把需求做实”。1.2 同一份需求我和AI交出两份答案AI生成的那份PRD确实让人眼前一亮。它的格式非常专业从背景、目标、用户故事到功能清单、优先级、甚至验收标准一应俱全。语言通顺结构清爽拿出去给研发看完全像一份正经的需求文档。如果是一个刚入行的助理PM可能写得还没它好。但仔细抠下去问题就出来了。AI列出的积分获取方式基本是“消费积分、签到积分、评价积分”消耗方式也停留在“兑换优惠券、兑换礼品”这类常识性方案。它没有问过一个问题这个企业的用户画像是谁积分过期规则和财务合规怎么衔接现有的积分系统有哪些技术债客服团队收到过哪些和积分相关的投诉这些信息不在输入里AI就无法自行补齐。我让那几位朋友把两边版本差异列了个表整理下来大概是这样的对比比较维度AI生成版本人工撰写的版本文档格式完整性很完整章节齐全按团队习惯组织略显松散对业务现状的还原度基本依赖输入描述无新增信息补充了数据、历史决策、客服反馈异常与边界情况覆盖覆盖常见的边界情况挖出了几个隐藏很深的流程漏洞对限制条件的敏感度不会主动追问知道哪些方案在现有架构下不可行商业判断与取舍几乎不会权衡会提醒某些功能投入产出比不高这个结果其实完全符合预期。AI本质上是一个“格式化已知信息”的引擎它能在几秒钟内把你喂给它的信息组织成一份体面的文档但它无法替你发现“你根本没想到要问的问题”。1.3 差异背后AI并不真正“理解”业务很多人误会AI能“理解”业务其实它做的是语义关联和概率生成。你给它一个功能描述它会调动训练数据里所有和这个功能相关的常见写法然后拼接成一段看起来合理的文字。但这段文字是否适合你当前的产品阶段、你的用户群体、你的技术约束它根本不知道。打个比方这就像请了一个特别会写汇报材料的实习生他能把你的材料写得工工整整但他不了解项目的前因后果不知道哪些领导在乎什么也不知道哪些话该说哪些话不该说。你让他独立负责一整份方案他用他的经验和常识硬凑出来的东西往往“正确但没有灵魂”。真正危险的就在这里。AI写出来的PRD越规范、越完整就越容易让人放松警惕误以为“这份文档已经经过充分思考了”。而实际上一份问题没有被定义清楚的需求文档无论排版多美观都只是把不确定性包装成了确定性。2. 需求文档的真正价值从来不在“写”这个动作上2.1 PRD首先是决策载体其次才是文档要回答“AI能不能替代PM写PRD”核心在于搞清楚PRD的本质是什么。很多人把PRD理解成“一份说明文档”仿佛它的价值在于把需求写清楚。但做了这几年产品我的体会是PRD首先是一个决策的载体其次才是一份文档。一份好的PRD承载的是一连串已经做出的决定我们为什么做这个功能而不是那个功能我们优先满足哪些用户、暂时牺牲哪些用户我们用这种方案而不是另一种方案是因为什么约束条件。这些决定如果做得足够扎实写文档只是水到渠成的事。反过来说如果一个PM拿起模板就开始填没有经过调研、分析、比较、取舍那么他往模板里填充的每一个字都是在制造假象。AI生成PRD之所以轻松正是因为它跳过了所有决策过程直接从“已知描述”跳到了“输出文档”。它很流畅但流畅恰恰是问题所在。2.2 “换个按钮颜色”的伪需求和它背后的真实问题我印象很深的一次经历是几年前在某电商团队处理过一个“登录页按钮颜色改版”的需求。业务方提得很简单把登录按钮改成更亮的颜色觉得现在的颜色不够醒目。如果把这个需求直接丢给AI它大概率会帮你分析出几种配色方案再贴几个心理学上关于色彩对比度的理论最后产出一份漂亮的PRD。看起来没什么问题对吧但我们做了几步额外的工作查了最近一个月的登录页漏斗数据发现颜色不是关键问题真正的流失拐点出现在“输入验证码后点击确认”的环节又翻了客服记录发现大量用户说“不知道验证码失效了还能不能重新获取”随后找了几位用户做可用性测试发现按钮文案“立即登录”在验证码错误不提示的场景下加剧了挫败感。需求和方案完全变了。真正的机会点根本不在颜色而在验证失败后的反馈机制和文案引导。如果只停留在“换个颜色”这个表面需求整个版本上线之后对转化率几乎不会有任何改善。这个例子说明了一个很残酷的现实用户和业务方提出的大多数需求本质上都只是“他们能想到的解决方案”而不是“他们真正的问题”。PM的核心工作之一是从这些表面方案背后把真问题挖出来。这件事AI帮不上忙因为AI只能基于你给它的表面需求继续做文章。2.3 信息链断裂为什么不能把前期调研外包给AI有人可能会说“那我先把调研工作做完再让AI帮我写文档不就行了吗”理论上可以但现实中的问题是很多PM恰恰跳过了调研这一步因为他们发现AI可以让“跳过”看起来不那么明显。以前写PRD需要面对面访谈、整理录音、看数据看板、翻客服工单这些动作本身就倒逼着你必须深入真实信息。而AI降低了文档生产的门槛也让很多PM产生了“差不多就行了”的错觉。信息链一旦断裂AI能做的只有两件事要么把你给的正确信息整理得更清晰要么把你给的模糊信息编写得更像真的。我并不是反对用AI。恰恰相反我觉得AI是这些年对产品经理效率提升最明显的工具之一。但它的正确用法是“在信息完整的前提下加速表达”而不是“替代信息获取和问题定义”。用一句话概括AI负责把话说清楚人负责把事想明白。3. 三条护城河问题定义、决策取舍和跨角色共识3.1 护城河一在模糊信息中定义真问题AI最擅长的是处理“已经有明确答案边界”的问题但真实的产品工作里绝大多数问题都处在模糊状态。业务方说“我们想提升复购”用户说“你们的东西有点贵”老板说“下季度要做到多少万日活”。这些表述离“问题定义”还有十万八千里。我在团队里带人的时候最看重的就是一个人面对模糊需求时会不会追问。拿到“提升复购”这个需求至少要往下拆复购率目前是多少主要流失在哪个环节是首单体验不好还是后续触发机制缺失竞品在同样位置做了什么用户嘴上说的是“贵”真实的决策阻碍是价格本身还是价值感知这不是什么高深的技术但它需要人浸泡在真实业务里把用户说的、数据显示的、业务方期待的三份信息放在一起交叉验证。AI没有“浸泡”这回事它只能根据你给的信息做出最可能的推测。你要学的是识别真问题的方法比如用问题树逐层下钻比如先看数据再访谈比如对每个需求问一句“用户想要的是这个还是这个结果背后的那个结果”。我在某内容社区项目上当产品顾问时团队想做一个“创作者涨粉工具包”说是用户在后台反复反馈涨粉难。听起来需求很清晰对不对但我们把反馈记录翻出来发现真正说得清“怎么涨粉”的用户其实很少大部分只是表达焦虑希望平台“帮我涨粉”。真正的问题不是没有工具而是新作者的冷启动阶段缺少曝光机制发出去的内容根本没人看到。做一百个涨粉技巧海报都不如调整信息流里的新作者推荐策略来得有效。AI在那个项目里能干什么它能帮你把“涨粉工具包”的功能清单列齐但它永远不能告诉你这个方向本身可能就错了。定义正确的问题就是PM的第一条护城河。3.2 护城河二有限资源下的决策与承担后果需求是永远做不完的资源永远是有限的。每个版本开始前PM最重要的事就是决定“这个版本不做什么”。但这个决定的难点不在于排列组合的复杂度而在于你必须为它承担后果。举个例子。某在线教育团队当时有两个备选需求一个是优化作业批改流程能显著提升老师的使用体验和续费率一个是做一套复杂的班级PK玩法预期能带来短期活跃度。研发资源只够做其中一个。从数据和用户访谈来看批改流程的优化明显更符合长期价值但班级PK玩法是运营部门强烈想要的也是老板在周会上点名过的。我的一位PM朋友最后选择先做批改流程优化同时给运营设计了一个低成本的活动方案来弥补短期活跃需求。他花了两周时间做数据说服、开各种对齐会、反复解释为什么这个优先级是合理的。AI能帮他做什么能帮他把两个方案的价值分析、排期预估、风险评估列得清清楚楚。但AI没法替他在老板面前表态没法替他承受“如果活跃数据没达标这就是我的决策”的压力。这个能力叫“决策勇气”。它不是一个技术问题而是一个职业素养问题。AI可以无限提供选项但选择之后的代价只能由人来承担。3.3 护城河三跨角色沟通与共识构建PRD写完了真正的工作才刚刚开始。研发会说“这个技术实现成本太高”设计会说“这个交互不符合用户习惯”运营会说“这个功能对活动运营不友好”老板会说“上线时间太晚了”。每一句都需要PM去倾听、去权衡、去协调。有一次我和研发负责人谈一个优先级很高的需求他第一反应是“这个排期做不了我们手上还有两个技术债项目”。我没有直接反驳而是先问了他技术债的现状和影响面发现其中一项的确有风险另一项其实可以往后推。然后我把需求背后的商业背景摊开——这个功能如果不在某个时间点上线会影响下季度的续约合作损失远大于技术债延期带来的影响。谈完之后他主动调整了内部安排。这类沟通之所以重要是因为它建立的是“信任”。研发信任你懂技术边界设计信任你有审美判断运营信任你理解增长压力老板信任你能交付结果。信任的构建需要一次一次的信息对齐和承诺兑现它和时间绑定和具体的人和事绑定AI无法替代。从另一个角度看AI还能帮上忙的地方是减少很多低层面的信息同步成本。过去PM要花大量时间在文档里把每个细节写清楚现在可以让AI先起草你再来做关键信息的确认。但跨角色的共识构建、冲突调和、决策推动这些依然只能靠人。4. 人机协作的工作流把“写文档”外包把“想清楚”留下4.1 四步工作流从“2天写完PRD”到“4小时定稿”我把自己在团队里验证过的四步工作流分享出来结构是定义问题人→ 信息准备人和AI合作→ 文档生成AI主导→ 评审迭代人。第一步人先做问题定义。明确解决的是谁的问题、在什么场景下发生、当前最大的瓶颈是什么。第二步信息准备阶段人可以借助AI快速整理已知信息但前提是信息来源清晰数据、访谈记录、历史文档都要有出处。第三步让AI基于整理好的信息生成PRD初稿包括功能清单、用户故事、验收标准等结构化内容。第四步进入人工评审逐条审视AI输出的每个功能点、每个验收标准补充业务上下文砍掉不正确的内容。用这个流程我实测处理过一个中等复杂度的后台功能需求从接到需求到评审定稿大概花了4小时。过去同样类型的需求按部就班地写文档、拉通、修改至少需要2天。省下来的时间我用来做了两件AI替代不了的事约了三位真实用户做访谈把需求文档里的核心假设重新验证了一遍以及和研发负责人提前对齐了技术方案避免后面评审时才发现实现成本过高。4.2 用好AI的三种姿势穷举边界、生成初稿、整理竞品和AI配合了一段时间我总结出三种最实用的用法。第一种是让AI穷举边界场景。做法很简单把核心业务流程描述给它让它列出你能想到的所有异常情况再让它基于这些异常情况生成处理方案。举一个例子在设计一个优惠券分享功能时我把基本流程写进去“用户领取优惠券后可以分享给好友好友领取后双方各得一张券。”AI用了几十秒就把边界场景列了一大堆好友已领取过、优惠券库存不足、分享链接过期、同一用户领取上限、好友在领取时网络中断、分享者和领取者是同一个人。这里面有三四条是我一开始根本没注意到的它帮我把盲区补上了。第二种是让AI生成初稿再由人来做“逐条质问”。AI生成的用户故事和验收标准只是素材你要做的不是照单全收而是对每一条问“为什么”。这一条背后的用户场景是什么这条验收标准真的能度量目标吗这个功能做了有什么风险不做会怎样经过追问之后保留下来的内容才有资格进入正式文档。第三种用法是让AI整理竞品信息。过去做竞品分析要把各个竞品的截图、功能点、流程存下来逐项对比非常耗时。现在可以让AI先做初步归纳你只需要验证关键信息、补充对业务有价值的判断。但这里一定要注意AI对竞品信息的准确性没有保证它可能会把不同版本的功能混在一起甚至会编造一些不存在的能力。所以用AI做竞品分析一定要把它当“初稿”最终确认必须由人去核实尤其涉及竞品的关键功能时最好去看一手资料。4.3 AI生成结果的安全复核与质量把关把AI的输出直接作为最终交付物是对团队的不负责。AI的生成是基于概率的它会在事实准确和表达流畅之间自动取舍哪怕证据不足它也会硬着头皮往下编。所以我自己养成了一个习惯所有AI起草的文档都强制要求标注信息源头。我会在文档里把所有AI生成的内容单独标记出来然后在评审前逐条做真实性校验。数据必须回到数据看板复核用户反馈必须回到原始访谈记录复核竞品功能必须回到实际产品页面复核。这个过程听起来费时间但真正形成习惯后很快而且它能帮你在团队里建立一种信任你拿出来的东西每一个数字都有出处。还有一个质量把关的办法是提前给AI“立规矩”。在提问时明确告诉它不确定的信息用“待确认”标注不要自行推测只能基于我提供的输入生成内容涉及风险判断的段落要求生成多个选项而不是一个绝对结论。这样能大幅减少模棱两可的输出。5. 警惕被AI淘汰的信号会用AI不等于会做产品5.1 三个危险信号说明你正在变成“文档工人”这段时间我对身边的产品经理做了一些观察发现有三类行为模式特别容易被AI替代。第一种是“只会写文档”的PM。他的核心技能就是文档写得漂亮格式严谨、用词讲究、逻辑通顺但文档里的内容很少经过他真正的独立思考。这样的人过去还能靠“比其他人写得好”立足现在AI写得又快又好他的优势瞬间就被抹平了。第二种是“只会接需求”的PM。别人说什么他做什么业务方提一个需求他传一个需求像一个需求中转站。AI现在可以更好地承担“中转站”的职责甚至还能给出更规范的拆解如果PM的价值仅在于此那确实危险。第三种是“只会催进度”的PM。每天盯着研发问进度、写周报、发会议纪要把“管理”理解为“跟进”。这些事务性工作恰恰是最容易被自动化工具覆盖的领域。当团队里有了更高效的信息同步工具这类角色的存在感会越来越稀薄。5.2 一个自测方法让AI写你来挑错想判断你自己在AI时代是否还有竞争力我推荐一个简单有效的自测方法。拿一个你最近负责的功能需求把背景信息交给AI让它生成一版完整的PRD。然后你来做评审人看你能挑出多少处问题并且这些问题是否触及需求底层。如果你挑出来的都是格式问题、错别字、语句不够通顺那说明你对抗不了AI的替代。如果你能挑出“这里的用户场景描述错了我们真正的用户不是这样的”“这条验收标准无法衡量目标达成需要重新定义指标”“这个功能优先级不合理应该先用更低成本的方案验证”那说明你的核心竞争力还在而且非常扎实。做这个测试的意义不在于验证AI写得有多好而在于检验一个PM在拿到一份“看似完整”的方案时能不能发现其中的认知偏差。我试过让团队里一位新同学做这个练习他花了半小时挑出七八处问题其中有三处连我都没注意到。那说明他不是靠记忆力在工作而是靠对业务的理解。5.3 新人如何培养AI无法替代的能力对想进入产品行业的新人来说我的建议比较简单直接别把你的学习重心放在“如何使用AI写文档”上而是要刻意训练信息获取密度。所谓信息获取密度就是同样一小时的用户访谈你能从对方的话里捕捉到多少有效信息同样一份数据报表你能从中读出多少业务事实。这种能力的培养需要刻意练习要强迫自己不发散、不跳跃先学会观察再学会判断。另一个建议是在团队里多参与那些“文档之外”的工作。研发讨论技术方案时你旁听了解技术边界运营做活动复盘时你看数据理解增长逻辑客服处理工单时你翻记录感知用户痛苦。这些东西没有一个能直接写进PRD但它们会沉淀成你做判断的依据。AI再怎么强大也没法替你去经历这些事情。我在带新人的时候会特别强调一个习惯每次接到新需求先不要打开文档工具或AI工具先拿出纸笔把你自己对这个问题的理解写下来然后列出你还不知道的信息清单。等这些清单被全部消灭之后再开始动笔。这个习惯看起来笨却是效率最高的一条路。说到底AI带来的不是“岗位消失潮”而是一轮“能力分层潮”。以前靠信息差和文字能力掩盖判断力不足的PM会被迅速抛下去而那些真正理解业务、敢于决策、能够推动共识的人会因为工具的加持而变得更加稀缺。我在实际项目中反复验证过这个判断AI写得越熟练的团队反而越依赖有洞察力的产品经理来把关方向。最后分享一个小技巧。如果你不知道从哪开始提升自己可以试着在每个需求评审会之前让AI生成一版PRD然后要求自己必须先找出三个AI想不到的问题再去开会。这个习惯坚持一段时间你会发现自己的问题定义能力会有一个明显的跃升。工具可以帮你把文档写得更好但它定义不了你对用户和业务的理解深度——那些东西仍然只存在于你的脑子里。