现在打开任何一个技术社区都能看到类似讨论AI能自动生成代码产品经理是不是没用了代码都不值钱了产品经理的壁垒还剩什么这个判断一半对一半错。AI确实把“从零编写代码初稿”这件事的边际成本压得很低但软件开发从来不只是代码生成。产品经理的核心工作——定义问题、组织需求、做取舍、设计验证、推动协作——恰恰是AI最难替代的部分。这篇文章不打算讲抽象的职业焦虑而是从产品经理日常真的会碰到的工作流出发拆解AI时代的技能变化并给出一套可以马上用起来的AI辅助产品工作方法。1. 先拆掉一个错误前提代码真的“不值钱”了吗在讨论产品经理处境之前要先对“代码不值钱”做一次语义拆解。很多讨论把“代码”理解成源代码本身但真实项目里代码只是最终软件交付物的一部分。生成代码的速度加快了不代表整个系统能更快地上线更不代表上线后能稳定运行。产品经理如果把这个前提当成事实很容易做出错误的职业判断。1.1 代码生成成本下降不等于软件交付成本下降软件交付是一整条链路从问题识别、需求定义、方案设计、代码实现到测试、发布、数据回收和迭代复盘。AI辅助编程工具例如GitHub Copilot、Cursor和国内多家厂商的AI编码助手明显降低了“代码初稿生成”的耗时但它没有降低需求澄清、跨团队协调、故障定责和业务结果验证的成本。可以用一张表看不同环节的变化软件开发环节没有AI时的主要成本有AI辅助后的变化产品经理需要掌握的能力需求澄清与问题定义访谈、场景观察、利益关系协调变化不大AI能整理访谈记录但无法替代现场感知提问、抽象、取舍PRD与方案设计撰写文档、梳理流程草稿生成明显加快但业务约束仍需人工补充约束建模、优先级判断原型与交互设计手工画图、标注逻辑AI可生成初稿但用户场景验证仍由人完成逻辑表达、可用性判断代码实现长时间编码初稿速度提升但代码审查、集成、调试成本仍在需求澄清到位降低返工测试与验收写测试用例、手工验证AI能补用例但验收标准必须产品经理定义定义可验收的完成标准上线与数据验证监控、查日志、分析数据部分查询和日志分析可AI辅助但口径需人把关数据口径、指标设计从这张表可以得出一个结论AI最擅长的是把“已经定义清楚的需求”快速翻译成代码、文档或测试用例。它并不擅长替产品经理回答“为什么做这个功能”“这个功能的目标指标是什么”“不做会怎样”。而这些没人回答清楚的问题最终都会变成开发阶段的返工成本。1.2 “AI会写代码”和“AI能交付软件”不是一回事为了把这个问题说得更具体这里用一个产品经理常见场景验证。假设需求是统计最近30天每个注册渠道的付费用户数。把这个问题交给AI编程工具或大模型它很可能快速生成一段SQLSELECT u.register_channel, COUNT(DISTINCT o.user_id) AS paying_users FROM users u JOIN orders o ON o.user_id u.id WHERE o.pay_time NOW() - INTERVAL 30 DAY GROUP BY u.register_channel;这段SQL看起来结构完整但它是否真的回答了业务问题取决于一长串假设“付费用户”是否指首次支付成功的用户还是只要支付成功就算退款用户要不要剔除退款时间是看当前状态还是看支付后30天内是否退款orders里会不会有测试账号、机器人流量、内部订单时间用的是支付时间还是下单时间时区取的是哪个users和orders做JOIN时一个人多条订单是否会导致用户重复计数如果没有产品经理事先定义口径这段SQL很可能产生一份“看起来正确、实际偏差很大”的报表。AI生成代码的能力越强这种偏差被发现的难度反而越大因为输出结果太工整容易让人停止追问。注意不要只验证AI生成的程序能跑通还要验证运行结果是否回答了原始业务问题。结果正确比语法正确重要得多。所以“代码不值钱了”这句话的正确理解是在教科书级、边界清晰的编码任务里代码初稿的生成成本确实在下降。但产品经理的壁垒不在“写代码”而在“把一个模糊问题变成一组有边界、有口径、能验收的明确需求”。这个能力在AI时代不仅没有贬值反而因为错误被放大而变得更加重要。2. 重新设计AI时代的产品研发工作流如果产品经理仍然按旧方式工作把大量时间花在整理文档、传递信息上确实容易被AI替代。更合适的方向是重新设计自己的工作流让AI承担草稿生成和重复整理把人解放出来做判断。2.1 产品经理从“需求传话筒”转向“问题定义者”传统流程里产品经理经常扮演“翻译器”把业务方提出的一句话愿望翻译成开发能理解的PRD。但这种角色的价值正在被压缩因为AI已经能基于输入生成非常完整的PRD初稿。若产品经理只是把老板的“做个会员体系”转成“设计会员等级、权益、积分规则”AI也能做到。真正难的是先回答几个前置问题会员体系要解决什么业务问题是提升复购、拉高客单还是降低流失目标用户是哪一类是价格敏感人群还是高净值用户本次要验证的核心假设是什么用什么指标判断成功有哪些业务约束不能突破例如财务结算方式、客服成本、法律合规。这些问题未定义清楚之前AI生成越详细团队就越容易把“完善但错误”的方案当成共识。因此产品经理在AI时代的第一职责是成为“问题定义者”而不是“文档生产者”。2.2 一套适合小型团队的AI辅助流程下面这套流程适合10人以内、正在磨合AI协作方式的小型产品团队也适合个人练习。它把产品经理的工作拆成七个环节收集输入把用户反馈、客服记录、数据报表、访谈纪要放在同一个文档里。定义问题用一句话写出“为谁解决什么问题为什么现在解决”。拆解需求将问题拆成用户故事并为每个用户故事写验收标准。AI生成PRD初稿使用结构化提示词让AI基于前三步内容生成完整文档。人工约束审查补充业务规则、合规要求、成本限制、数据口径。开发与测试评审让AI辅助生成测试用例产品经理参与评审。数据回收与复盘上线后用数据验证目标是否达成并把结论反馈到下一轮。这个流程的关键不是“多用AI”而是“在进入AI之前先完成问题定义”。如果前两步没做好后面所有AI生成的文档都会建立在错误地基上。每个环节都要留一个检查点例如第四步的检查点是“AI生成的文档是否所有假设都有来源”。2.3 个人实验和团队产出要分开用AI辅助工作时要区分“个人研究”和“团队生产”。个人研究允许快速试错哪怕AI给的信息过期、不准确也可以作为线索。团队生产则必须控制质量因为评审、开发、测试都会基于这份产出行动。维度个人学习与研究团队协作生产质量要求能帮助理解问题即可必须准确、完整、可执行验证流程可跳过或轻量验证必须有评审和版本记录风险控制错误影响范围小错误可能导致开发返工或线上事故工具选择只要能提升效率都可用要考虑权限、合规、数据安全协作方式单人独立完成需要标记AI草稿、人工修订和待确认项在团队场景里不要直接把AI生成的PRD或SQL丢到群里。建议在文档开头标注“AI生成初稿人工已修订有3个待确认问题”。这样既保留了AI的效率也不把AI的假设伪装成团队共识。3. 产品经理能立刻用起来的四种AI硬技能与其讨论“AI会不会取代产品经理”不如先掌握几项能在工作中立刻提升效率的技能。下面四个方向对产品经理门槛较低但都能形成技术颗粒度。3.1 用结构化提示词生成可评审的PRD很多人让AI写PRD时只给一句话“帮我写一个会员体系PRD”。这样生成的文档通常会有大量假设和空泛描述不适合评审。更好的做法是把已知信息和约束一并给到AI并用提示词限制它的行为。你是一名资深产品专家。请基于以下需求描述输出一份PRD初稿。 需求背景用户反馈下单流程中支付页跳转慢客服每天收到约30个相关投诉。 目标用户完成下单但未支付的用户。 核心场景用户提交订单后在支付页停留超过5秒部分用户直接退出。 业务约束 - 支付链路不能新增第三方依赖。 - 本次重点优化支付页加载速度和操作引导。 - 不支持修改支付方式。 请输出 1. 产品目标和成功指标。 2. 用户故事。 3. 功能清单和优先级P0/P1/P2。 4. 每个P0功能的验收标准要求可量化。 5. 如果信息不足列出需要补充的问题清单不要自行编造。 6. 不写具体技术实现除非技术方案影响产品行为。这段提示词的核心是“先给信息再给约束最后限制AI的默认行为”。其中“如果信息不足列出问题清单不要自行编造”特别重要。它能显著降低AI生成不实假设的概率也能让产品经理在评审前就意识到自己还缺哪些输入。3.2 用AI把需求转成接口描述或字段字典产品经理不需要写后端代码但必须能和技术团队对齐字段语义。AI可以帮助把一段需求描述转成字段字典或JSON Schema草稿。比如会员体系需求中“积分有效期”可以描述成下面这样{ pointsId: string积分流水号必填业务主键, userId: string用户ID必填, changeType: enum: EARN/REDEEM/EXPIRE/REFUND, changePoints: integer本次变动积分正数为增加负数为扣减, expireAt: string积分过期时间ISO 8601格式为空表示永久有效, sourceOrderId: string订单号变动来源可空, createdAt: string创建时间ISO 8601格式 }让AI生成这类描述后产品经理要负责审核字段是否满足业务规则例如“过期时间在哪一层计算”“退款时积分是否追回”。这一环节的价值在于它把模糊的“积分规则”变成了可评审的数据契约减少后续开发理解偏差。3.3 用AI辅助数据验证和取数产品经理经常需要取数验证功能效果。如果不会写SQL至少要学会用AI生成SQL并且会验证结果。一个更稳妥的提示词模板是要求AI先说明取数逻辑再写SQL帮我写一个SQL统计最近30天每个注册渠道的付费用户数。 业务口径 - 付费用户首次支付成功且当前退款状态不是“已退款”的用户。 - 注册渠道读取 users 表的 register_channel。 - 表结构users(id, register_channel, created_at)orders(user_id, pay_time, refund_status, finish_status)。 请先写出你的取数逻辑再给出SQL最后列出可能的数据质量问题。AI可能生成类似下面的SQLSELECT u.register_channel, COUNT(DISTINCT o.user_id) AS paying_users FROM users u JOIN orders o ON o.user_id u.id WHERE o.pay_time NOW() - INTERVAL 30 DAY AND o.finish_status SUCCESS AND IFNULL(o.refund_status, ) REFUNDED GROUP BY u.register_channel;这段代码仍需人工确认几个关键点JOIN会不会因为多笔订单导致重复时间边界是否按“最近30天”定义退款维度是否要剔除历史退款过但当前已恢复的用户。产品经理不一定逐行读SQL但必须能看懂这些关键条件并能提出疑问。这是“代码不值钱”时代最值钱的验证能力。3.4 用AI辅助竞品分析和方案对比产品经理还常用AI做竞品分析和方案对比。这类任务适合用表格输出但要注意AI的知识库存在时间截止竞品功能、定价、页面细节可能已经变化。所以AI输出只能作为初筛。可以要求AI按固定维度整理对比维度需要核对的信息功能范围是否有对应场景、流程、异常分支用户流程新用户如何完成核心任务需要几步定价策略免费版/付费版差异是否影响需求设计优势场景适合什么类型的用户和业务潜在风险合规、支付、客服等限制AI给出初稿后产品经理需要打开竞品页面或使用说明至少核对三条信息功能是否存在、流程是否符合当前版本、价格是否需要更新。不要直接把AI生成的竞品分析放进正式报告除非已经人工复核。4. 常见坑AI不会替代产品经理但会放大需求缺陷AI工具把内容生产速度提升后产品经理面临的不是“没有产出”而是“产出太多但质量失控”。下面四个坑在AI辅助产品工作中很常见需要提前设防。4.1 坑一把AI生成物当成评审依据现象是PRD由AI生成整体结构完整评审时大家觉得没什么问题开发完成后才发现缺少业务规则无法上线。原因是AI只能根据输入补全内容无法知道组织内部的合规要求、渠道限制和线下流程。它产出的“完整”是一种文本完整不等同于业务完整。处理方式是在评审前增加一道人工约束检查逐条确认这版需求在真实场景里是否会被用户拒绝、被运营拒绝、被财务拒绝。更直接的做法是在提示词里让AI把所有假设列在文档开头并把“已知信息”和“假设”分区展示强迫团队在评审时关注这些假设。4.2 坑二SQL和指标口径不一致产品给出的数据报表与运营口径经常不一致比如活跃用户数少了几千人。常见原因是“活跃”定义不同有人按登录算有人按有行为算还有人按订单算。AI生成的SQL通常只会按照用户输入的字面条件执行不会主动发现口径冲突。处理方式是在让AI生成SQL前先给出指标定义和口径SQL生成后再让AI输出“数据质量风险清单”例如空值、重复数据、时间边界。团队最好建立一份统一指标词典把“付费用户”“活跃用户”等关键词固定在词典里产品取数时必须引用该口径。4.3 坑三问题没定义清楚就急着让AI加速很多需求的原话只有“优化下单流程”没有说明是流程哪一步、优化目标是什么、优化到什么程度就算成功。在这种情况下让AI生成方案它会自动脑补一个平均的下单流程生成越详细越容易让人误以为方案已经被思考过。正确顺序是先写“背景-问题-目标-约束”再让AI辅助生成方案。AI不应该成为工作流的起点而应该在问题定义清楚之后介入。可以把“一句话需求”升级成“一页需求说明”包含目标用户、当前体验、期望指标、限制条件然后再交给AI。4.4 坑四把AI输出当作最终答案而不是候选有时候产品经理会让AI直接生成OKR、数据结论或方案然后复制到正式文档里。AI不是决策者它是概率模型输出可能包含过时信息、错误推理和凭空假设。重要结论必须经过人工判断。更好的协作方式是要求AI给出推理过程和依据再由人判断。对于关键数据结论可以拆分多个角度让AI交叉验证例如同一条指标用两种SQL写法验证或让同一个模型在不同提示词下分别回答再对比差异。这能显著降低“AI一本正经地给出错误答案”的影响。可以用一张表汇总排查思路错误现象可能原因检查方式解决思路AI生成的PRD评审通过但上线失败缺少隐含业务规则逐条核对真实业务约束在提示词中强制列出假设数据报表与运营口径不一致指标定义不统一检查SQL中的JOIN和时间条件建立指标词典固定口径需求看似完整但方向偏了问题定义模糊回到背景、目标、约束对照先写一页需求说明再让AI生成AI给出结论没有依据模型幻觉或知识过期要求AI给出推理过程和数据来源重要结论人工复核并交叉验证5. 产品经理构建核心壁垒的可复用清单文章最后一部分是实践清单。AI时代的产品经理不需要收藏很多理论而是需要一套能反复使用的检查工具。5.1 需求进入AI前的检查清单在使用AI生成PRD、方案或SQL之前先检查下面这些项目是否已经明确是否写清了目标用户和核心场景是否写清了当前痛点并且有数据或事实支撑是否写清了“这次不做什么”是否写清了业务约束包括合规、成本、线下流程是否写清了验收指标和指标口径是否列出了需要调研但尚未确认的问题是否说明AI生成内容中哪些是已知信息哪些是允许的假设这份清单可以放在项目的需求文档模板里。每次输入AI前先花十分钟补充缺失项比反复调整提示词更有效。5.2 AI生成内容的人工评审清单AI输出内容后不要直接进入评审先做一轮人工评审生成内容中哪些是事实哪些是假设事实信息是否能找到来源是否可能过时验收标准是否可量化有没有歧义是否擅自增加了需求范围是否遗漏了关键角色、异常分支、权限边界有没有把“也许”写成“必须”注意在AI辅助工作流里评审重点不是看文档是否完整而是看文档里的假设是否被显著标记出来。假设不可怕没有被识别的假设才可怕。5.3 用AI做“对照实验”的练习方法产品经理想快速建立对AI的感知可以做一个每周练习。找一份已经完成的旧PRD不要直接把原方案给AI。只提供当时的背景、目标用户和约束让AI生成一份新方案。然后把AI方案和原方案对照找出差距。这个练习有三个作用发现自己的惯性思维看到AI可能给出了不同路径。发现AI对业务上下文的无知从而理解为什么约束必须由人来补充。训练自己给AI“喂信息”的能力以后写提示词会更精准。第一次做这个练习可能很花时间但坚持几周后你对AI的边界会有更具体的感知远比看教程有效。5.4 扩展方向从会用AI到能构建AI产品如果不满足于“用AI辅助工作”产品经理还可以向“AI产品经理”方向延伸。以下学习路径适合从实践入手大模型核心概念Token、上下文窗口、幻觉、RAG、微调。提示词工程结构化提示词、角色设定、少样本示例、自动评估。产品评估方法建立评测集对比不同模型和不同提示词的效果。Agent工作流拆解任务、调用工具、检查中间结果、人工兜底。数据与安全数据权限、隐私合规、内容安全、日志审计。这些方向并不要求转岗做算法而是让你能和技术团队在同一个语言体系里讨论问题。越能看懂AI产品的基础机制越能在需求定义和效果验收时给出高质量判断。回到最开始的问题AI时代代码不值钱了产品经理的核心壁垒还剩什么答案是判断力。代码初稿可以由AI生成但“什么值得做、边界在哪里、结果如何验证”这三层没有AI能完全代劳至少现在不能。产品经理与其焦虑被替换不如先把数据口径、验收标准和约束检查练扎实。练一个月之后再看AI生成的内容你会发现自己能问出的问题就是别人抄不走的能力。 AI时代产品经理核心壁垒：从问题定义到结果验证
现在打开任何一个技术社区都能看到类似讨论AI能自动生成代码产品经理是不是没用了代码都不值钱了产品经理的壁垒还剩什么这个判断一半对一半错。AI确实把“从零编写代码初稿”这件事的边际成本压得很低但软件开发从来不只是代码生成。产品经理的核心工作——定义问题、组织需求、做取舍、设计验证、推动协作——恰恰是AI最难替代的部分。这篇文章不打算讲抽象的职业焦虑而是从产品经理日常真的会碰到的工作流出发拆解AI时代的技能变化并给出一套可以马上用起来的AI辅助产品工作方法。1. 先拆掉一个错误前提代码真的“不值钱”了吗在讨论产品经理处境之前要先对“代码不值钱”做一次语义拆解。很多讨论把“代码”理解成源代码本身但真实项目里代码只是最终软件交付物的一部分。生成代码的速度加快了不代表整个系统能更快地上线更不代表上线后能稳定运行。产品经理如果把这个前提当成事实很容易做出错误的职业判断。1.1 代码生成成本下降不等于软件交付成本下降软件交付是一整条链路从问题识别、需求定义、方案设计、代码实现到测试、发布、数据回收和迭代复盘。AI辅助编程工具例如GitHub Copilot、Cursor和国内多家厂商的AI编码助手明显降低了“代码初稿生成”的耗时但它没有降低需求澄清、跨团队协调、故障定责和业务结果验证的成本。可以用一张表看不同环节的变化软件开发环节没有AI时的主要成本有AI辅助后的变化产品经理需要掌握的能力需求澄清与问题定义访谈、场景观察、利益关系协调变化不大AI能整理访谈记录但无法替代现场感知提问、抽象、取舍PRD与方案设计撰写文档、梳理流程草稿生成明显加快但业务约束仍需人工补充约束建模、优先级判断原型与交互设计手工画图、标注逻辑AI可生成初稿但用户场景验证仍由人完成逻辑表达、可用性判断代码实现长时间编码初稿速度提升但代码审查、集成、调试成本仍在需求澄清到位降低返工测试与验收写测试用例、手工验证AI能补用例但验收标准必须产品经理定义定义可验收的完成标准上线与数据验证监控、查日志、分析数据部分查询和日志分析可AI辅助但口径需人把关数据口径、指标设计从这张表可以得出一个结论AI最擅长的是把“已经定义清楚的需求”快速翻译成代码、文档或测试用例。它并不擅长替产品经理回答“为什么做这个功能”“这个功能的目标指标是什么”“不做会怎样”。而这些没人回答清楚的问题最终都会变成开发阶段的返工成本。1.2 “AI会写代码”和“AI能交付软件”不是一回事为了把这个问题说得更具体这里用一个产品经理常见场景验证。假设需求是统计最近30天每个注册渠道的付费用户数。把这个问题交给AI编程工具或大模型它很可能快速生成一段SQLSELECT u.register_channel, COUNT(DISTINCT o.user_id) AS paying_users FROM users u JOIN orders o ON o.user_id u.id WHERE o.pay_time NOW() - INTERVAL 30 DAY GROUP BY u.register_channel;这段SQL看起来结构完整但它是否真的回答了业务问题取决于一长串假设“付费用户”是否指首次支付成功的用户还是只要支付成功就算退款用户要不要剔除退款时间是看当前状态还是看支付后30天内是否退款orders里会不会有测试账号、机器人流量、内部订单时间用的是支付时间还是下单时间时区取的是哪个users和orders做JOIN时一个人多条订单是否会导致用户重复计数如果没有产品经理事先定义口径这段SQL很可能产生一份“看起来正确、实际偏差很大”的报表。AI生成代码的能力越强这种偏差被发现的难度反而越大因为输出结果太工整容易让人停止追问。注意不要只验证AI生成的程序能跑通还要验证运行结果是否回答了原始业务问题。结果正确比语法正确重要得多。所以“代码不值钱了”这句话的正确理解是在教科书级、边界清晰的编码任务里代码初稿的生成成本确实在下降。但产品经理的壁垒不在“写代码”而在“把一个模糊问题变成一组有边界、有口径、能验收的明确需求”。这个能力在AI时代不仅没有贬值反而因为错误被放大而变得更加重要。2. 重新设计AI时代的产品研发工作流如果产品经理仍然按旧方式工作把大量时间花在整理文档、传递信息上确实容易被AI替代。更合适的方向是重新设计自己的工作流让AI承担草稿生成和重复整理把人解放出来做判断。2.1 产品经理从“需求传话筒”转向“问题定义者”传统流程里产品经理经常扮演“翻译器”把业务方提出的一句话愿望翻译成开发能理解的PRD。但这种角色的价值正在被压缩因为AI已经能基于输入生成非常完整的PRD初稿。若产品经理只是把老板的“做个会员体系”转成“设计会员等级、权益、积分规则”AI也能做到。真正难的是先回答几个前置问题会员体系要解决什么业务问题是提升复购、拉高客单还是降低流失目标用户是哪一类是价格敏感人群还是高净值用户本次要验证的核心假设是什么用什么指标判断成功有哪些业务约束不能突破例如财务结算方式、客服成本、法律合规。这些问题未定义清楚之前AI生成越详细团队就越容易把“完善但错误”的方案当成共识。因此产品经理在AI时代的第一职责是成为“问题定义者”而不是“文档生产者”。2.2 一套适合小型团队的AI辅助流程下面这套流程适合10人以内、正在磨合AI协作方式的小型产品团队也适合个人练习。它把产品经理的工作拆成七个环节收集输入把用户反馈、客服记录、数据报表、访谈纪要放在同一个文档里。定义问题用一句话写出“为谁解决什么问题为什么现在解决”。拆解需求将问题拆成用户故事并为每个用户故事写验收标准。AI生成PRD初稿使用结构化提示词让AI基于前三步内容生成完整文档。人工约束审查补充业务规则、合规要求、成本限制、数据口径。开发与测试评审让AI辅助生成测试用例产品经理参与评审。数据回收与复盘上线后用数据验证目标是否达成并把结论反馈到下一轮。这个流程的关键不是“多用AI”而是“在进入AI之前先完成问题定义”。如果前两步没做好后面所有AI生成的文档都会建立在错误地基上。每个环节都要留一个检查点例如第四步的检查点是“AI生成的文档是否所有假设都有来源”。2.3 个人实验和团队产出要分开用AI辅助工作时要区分“个人研究”和“团队生产”。个人研究允许快速试错哪怕AI给的信息过期、不准确也可以作为线索。团队生产则必须控制质量因为评审、开发、测试都会基于这份产出行动。维度个人学习与研究团队协作生产质量要求能帮助理解问题即可必须准确、完整、可执行验证流程可跳过或轻量验证必须有评审和版本记录风险控制错误影响范围小错误可能导致开发返工或线上事故工具选择只要能提升效率都可用要考虑权限、合规、数据安全协作方式单人独立完成需要标记AI草稿、人工修订和待确认项在团队场景里不要直接把AI生成的PRD或SQL丢到群里。建议在文档开头标注“AI生成初稿人工已修订有3个待确认问题”。这样既保留了AI的效率也不把AI的假设伪装成团队共识。3. 产品经理能立刻用起来的四种AI硬技能与其讨论“AI会不会取代产品经理”不如先掌握几项能在工作中立刻提升效率的技能。下面四个方向对产品经理门槛较低但都能形成技术颗粒度。3.1 用结构化提示词生成可评审的PRD很多人让AI写PRD时只给一句话“帮我写一个会员体系PRD”。这样生成的文档通常会有大量假设和空泛描述不适合评审。更好的做法是把已知信息和约束一并给到AI并用提示词限制它的行为。你是一名资深产品专家。请基于以下需求描述输出一份PRD初稿。 需求背景用户反馈下单流程中支付页跳转慢客服每天收到约30个相关投诉。 目标用户完成下单但未支付的用户。 核心场景用户提交订单后在支付页停留超过5秒部分用户直接退出。 业务约束 - 支付链路不能新增第三方依赖。 - 本次重点优化支付页加载速度和操作引导。 - 不支持修改支付方式。 请输出 1. 产品目标和成功指标。 2. 用户故事。 3. 功能清单和优先级P0/P1/P2。 4. 每个P0功能的验收标准要求可量化。 5. 如果信息不足列出需要补充的问题清单不要自行编造。 6. 不写具体技术实现除非技术方案影响产品行为。这段提示词的核心是“先给信息再给约束最后限制AI的默认行为”。其中“如果信息不足列出问题清单不要自行编造”特别重要。它能显著降低AI生成不实假设的概率也能让产品经理在评审前就意识到自己还缺哪些输入。3.2 用AI把需求转成接口描述或字段字典产品经理不需要写后端代码但必须能和技术团队对齐字段语义。AI可以帮助把一段需求描述转成字段字典或JSON Schema草稿。比如会员体系需求中“积分有效期”可以描述成下面这样{ pointsId: string积分流水号必填业务主键, userId: string用户ID必填, changeType: enum: EARN/REDEEM/EXPIRE/REFUND, changePoints: integer本次变动积分正数为增加负数为扣减, expireAt: string积分过期时间ISO 8601格式为空表示永久有效, sourceOrderId: string订单号变动来源可空, createdAt: string创建时间ISO 8601格式 }让AI生成这类描述后产品经理要负责审核字段是否满足业务规则例如“过期时间在哪一层计算”“退款时积分是否追回”。这一环节的价值在于它把模糊的“积分规则”变成了可评审的数据契约减少后续开发理解偏差。3.3 用AI辅助数据验证和取数产品经理经常需要取数验证功能效果。如果不会写SQL至少要学会用AI生成SQL并且会验证结果。一个更稳妥的提示词模板是要求AI先说明取数逻辑再写SQL帮我写一个SQL统计最近30天每个注册渠道的付费用户数。 业务口径 - 付费用户首次支付成功且当前退款状态不是“已退款”的用户。 - 注册渠道读取 users 表的 register_channel。 - 表结构users(id, register_channel, created_at)orders(user_id, pay_time, refund_status, finish_status)。 请先写出你的取数逻辑再给出SQL最后列出可能的数据质量问题。AI可能生成类似下面的SQLSELECT u.register_channel, COUNT(DISTINCT o.user_id) AS paying_users FROM users u JOIN orders o ON o.user_id u.id WHERE o.pay_time NOW() - INTERVAL 30 DAY AND o.finish_status SUCCESS AND IFNULL(o.refund_status, ) REFUNDED GROUP BY u.register_channel;这段代码仍需人工确认几个关键点JOIN会不会因为多笔订单导致重复时间边界是否按“最近30天”定义退款维度是否要剔除历史退款过但当前已恢复的用户。产品经理不一定逐行读SQL但必须能看懂这些关键条件并能提出疑问。这是“代码不值钱”时代最值钱的验证能力。3.4 用AI辅助竞品分析和方案对比产品经理还常用AI做竞品分析和方案对比。这类任务适合用表格输出但要注意AI的知识库存在时间截止竞品功能、定价、页面细节可能已经变化。所以AI输出只能作为初筛。可以要求AI按固定维度整理对比维度需要核对的信息功能范围是否有对应场景、流程、异常分支用户流程新用户如何完成核心任务需要几步定价策略免费版/付费版差异是否影响需求设计优势场景适合什么类型的用户和业务潜在风险合规、支付、客服等限制AI给出初稿后产品经理需要打开竞品页面或使用说明至少核对三条信息功能是否存在、流程是否符合当前版本、价格是否需要更新。不要直接把AI生成的竞品分析放进正式报告除非已经人工复核。4. 常见坑AI不会替代产品经理但会放大需求缺陷AI工具把内容生产速度提升后产品经理面临的不是“没有产出”而是“产出太多但质量失控”。下面四个坑在AI辅助产品工作中很常见需要提前设防。4.1 坑一把AI生成物当成评审依据现象是PRD由AI生成整体结构完整评审时大家觉得没什么问题开发完成后才发现缺少业务规则无法上线。原因是AI只能根据输入补全内容无法知道组织内部的合规要求、渠道限制和线下流程。它产出的“完整”是一种文本完整不等同于业务完整。处理方式是在评审前增加一道人工约束检查逐条确认这版需求在真实场景里是否会被用户拒绝、被运营拒绝、被财务拒绝。更直接的做法是在提示词里让AI把所有假设列在文档开头并把“已知信息”和“假设”分区展示强迫团队在评审时关注这些假设。4.2 坑二SQL和指标口径不一致产品给出的数据报表与运营口径经常不一致比如活跃用户数少了几千人。常见原因是“活跃”定义不同有人按登录算有人按有行为算还有人按订单算。AI生成的SQL通常只会按照用户输入的字面条件执行不会主动发现口径冲突。处理方式是在让AI生成SQL前先给出指标定义和口径SQL生成后再让AI输出“数据质量风险清单”例如空值、重复数据、时间边界。团队最好建立一份统一指标词典把“付费用户”“活跃用户”等关键词固定在词典里产品取数时必须引用该口径。4.3 坑三问题没定义清楚就急着让AI加速很多需求的原话只有“优化下单流程”没有说明是流程哪一步、优化目标是什么、优化到什么程度就算成功。在这种情况下让AI生成方案它会自动脑补一个平均的下单流程生成越详细越容易让人误以为方案已经被思考过。正确顺序是先写“背景-问题-目标-约束”再让AI辅助生成方案。AI不应该成为工作流的起点而应该在问题定义清楚之后介入。可以把“一句话需求”升级成“一页需求说明”包含目标用户、当前体验、期望指标、限制条件然后再交给AI。4.4 坑四把AI输出当作最终答案而不是候选有时候产品经理会让AI直接生成OKR、数据结论或方案然后复制到正式文档里。AI不是决策者它是概率模型输出可能包含过时信息、错误推理和凭空假设。重要结论必须经过人工判断。更好的协作方式是要求AI给出推理过程和依据再由人判断。对于关键数据结论可以拆分多个角度让AI交叉验证例如同一条指标用两种SQL写法验证或让同一个模型在不同提示词下分别回答再对比差异。这能显著降低“AI一本正经地给出错误答案”的影响。可以用一张表汇总排查思路错误现象可能原因检查方式解决思路AI生成的PRD评审通过但上线失败缺少隐含业务规则逐条核对真实业务约束在提示词中强制列出假设数据报表与运营口径不一致指标定义不统一检查SQL中的JOIN和时间条件建立指标词典固定口径需求看似完整但方向偏了问题定义模糊回到背景、目标、约束对照先写一页需求说明再让AI生成AI给出结论没有依据模型幻觉或知识过期要求AI给出推理过程和数据来源重要结论人工复核并交叉验证5. 产品经理构建核心壁垒的可复用清单文章最后一部分是实践清单。AI时代的产品经理不需要收藏很多理论而是需要一套能反复使用的检查工具。5.1 需求进入AI前的检查清单在使用AI生成PRD、方案或SQL之前先检查下面这些项目是否已经明确是否写清了目标用户和核心场景是否写清了当前痛点并且有数据或事实支撑是否写清了“这次不做什么”是否写清了业务约束包括合规、成本、线下流程是否写清了验收指标和指标口径是否列出了需要调研但尚未确认的问题是否说明AI生成内容中哪些是已知信息哪些是允许的假设这份清单可以放在项目的需求文档模板里。每次输入AI前先花十分钟补充缺失项比反复调整提示词更有效。5.2 AI生成内容的人工评审清单AI输出内容后不要直接进入评审先做一轮人工评审生成内容中哪些是事实哪些是假设事实信息是否能找到来源是否可能过时验收标准是否可量化有没有歧义是否擅自增加了需求范围是否遗漏了关键角色、异常分支、权限边界有没有把“也许”写成“必须”注意在AI辅助工作流里评审重点不是看文档是否完整而是看文档里的假设是否被显著标记出来。假设不可怕没有被识别的假设才可怕。5.3 用AI做“对照实验”的练习方法产品经理想快速建立对AI的感知可以做一个每周练习。找一份已经完成的旧PRD不要直接把原方案给AI。只提供当时的背景、目标用户和约束让AI生成一份新方案。然后把AI方案和原方案对照找出差距。这个练习有三个作用发现自己的惯性思维看到AI可能给出了不同路径。发现AI对业务上下文的无知从而理解为什么约束必须由人来补充。训练自己给AI“喂信息”的能力以后写提示词会更精准。第一次做这个练习可能很花时间但坚持几周后你对AI的边界会有更具体的感知远比看教程有效。5.4 扩展方向从会用AI到能构建AI产品如果不满足于“用AI辅助工作”产品经理还可以向“AI产品经理”方向延伸。以下学习路径适合从实践入手大模型核心概念Token、上下文窗口、幻觉、RAG、微调。提示词工程结构化提示词、角色设定、少样本示例、自动评估。产品评估方法建立评测集对比不同模型和不同提示词的效果。Agent工作流拆解任务、调用工具、检查中间结果、人工兜底。数据与安全数据权限、隐私合规、内容安全、日志审计。这些方向并不要求转岗做算法而是让你能和技术团队在同一个语言体系里讨论问题。越能看懂AI产品的基础机制越能在需求定义和效果验收时给出高质量判断。回到最开始的问题AI时代代码不值钱了产品经理的核心壁垒还剩什么答案是判断力。代码初稿可以由AI生成但“什么值得做、边界在哪里、结果如何验证”这三层没有AI能完全代劳至少现在不能。产品经理与其焦虑被替换不如先把数据口径、验收标准和约束检查练扎实。练一个月之后再看AI生成的内容你会发现自己能问出的问题就是别人抄不走的能力。