AI时代的到来正在重塑产品经理的核心能力框架。本文深度剖析AI PM与传统PM的三大本质差异，解密AI产品从0到1的三线并行开发范式，并给出RAG与微调技术的实战选型指南，带你掌握AI产品设计的底层逻辑与关键决策点。

一、说说你对AI和AIGC的理解，以及AI PM和传统PM有哪些核心区别？

说说我对AI的理解，在这一波浪潮下，AI不再是人工智能，这一波改革更多是的用自然语言成为产品形态。在传统互联网时代，需要设计菜单、按钮、流程，需要用户是学习你的产品，而AI产品更多的是用户说一句话，AI就要理解用的真实意图，调用模型能力，做出反馈。

而AIGC是AI跑出来的一种产品形态，在当下AI时代更多关注的是Agent，它真正从“生成内容”到“任务完成”的跃迁。

下面说一下AI PM和PM的核心区别，我会从下面3个方面来讲一下：

第1个：你要为“不确定性”做设计，就像之前我在做小红书爆款营销文案生成这个工具的时候，在微调时候，你的温度值调得太低，导致文案不够活泼，不符合小红书的调性。后面上线之后，用户反馈很差，所以我们又调了温度值，之后就好了很多。

第2个：你要为“需求”考虑，现在我设计一个需求，首要考虑的不是说怎么做，由于大模型底层框架逻辑就是词语接龙，首先就要考虑大模型能不能实现，能做到什么程度，幻觉率怎么样、他的边界在哪、bad case是什么。而是传统PM只需要把需求体给开发人员就可以。

第3个：你要考虑和模型一起迭代，传统产品经理如果要改某个需求，他需要跟开发讲。而AI 产品经理如果需要迭代某个需求，可以考虑以下方式：

1. 换模型

2. 补数据

3. 改 Prompt

4. 哪怕是 RAG 或者是微调都是可以的

二、一个完整的AI产品从0到1的流程是怎样的，产品经理在每个节点做什么？

我觉得AI产品从0到1，最大的特点不是流程变长了，而是流程变成了三条线并行。传统产品只有一条产品线，AI产品有三条：产品线、数据线、模型线，PM要同时管这三条线的节奏。

第一条：产品线（PM主导） 这条线和传统产品类似——定义需求、设计交互、做PRD、跟进上线。但AI PM在这条线上多了一个核心动作：判断这个需求该不该用AI做。我的判断标准是看三件事——用户痛点是不是真痛点？非AI方案为什么不够？AI的边际成本能不能打平价值？三个都过才往下走。

第二条：数据线（PM深度参与） 这条线是传统PM完全没有的，也是AI PM真正的护城河。它包括三件事：训练数据从哪来、评估集怎么建、bad case怎么回流。这里PM最该亲自做的是评估集——评估集本质上是产品对模型的考卷，考卷出得不好，模型再强也白搭。我做评估集会刻意覆盖三类样本：典型场景、边界场景、对抗样本。

第三条：模型线（算法主导，PM验收） 这条线包括技术选型、模型训练、效果评估、迭代优化。PM不用懂训练，但要懂选型逻辑——Prompt → RAG → 微调 → 训练，能用前面的就别用后面的，成本是指数级的。PM最重要的动作是看bad case，把失败case按类型分类——知识缺失补RAG、理解错改Prompt、幻觉加约束。这个分类能力决定了你能不能推动模型往产品需要的方向走。

三条线怎么协同？ 产品线定义”做什么”，数据线决定”能做到多好”，模型线决定”怎么做出来”。PM的核心价值，是让这三条线的节奏对齐——产品定义不能超出数据能支撑的范围，数据准备不能落后于模型训练的节奏，模型效果要能反哺产品设计的调整。

所以如果让我用一句话总结：传统PM是项目经理，AI PM是三线指挥官。

三、RAG的原理、优劣势和应用场景，相比微调有什么区别？

我先用一句话讲清楚两个概念，然后讲一下作为PM真正在选型时的判断逻辑。

• RAG是让模型在回答前先去”查资料”——把知识库切片，按问题相关性检索，把检索到的内容塞进Prompt让模型生成答案。
• 微调是让模型把知识”内化”——用领域数据继续训练，让知识和能力固化到参数里。

通俗一点：RAG像让一个聪明的实习生带着工具书答题，微调像让他先去专门进修一年再回来答题。

作为PM，我在选型时不是问用哪个更好，而是按这个顺序问四个问题：

问题1：能不能用Prompt工程解决？ 80%的需求其实不需要RAG也不需要微调，调好Prompt就够了。我做[XX项目]时一开始就想上RAG，后来发现把Prompt里加几个few-shot example，效果就达标了。RAG和微调都是有成本的，能不上就不上。

问题2：核心瓶颈是知识，还是能力？ 这是RAG vs 微调最关键的分水岭。

• 如果用户问的是”我们公司的退货政策是什么”——这是知识问题，模型不知道你们公司的政策，RAG就够了。
• 如果用户问的是”帮我用我们品牌的口吻写一封道歉信”——这是能力问题，模型要学会的是”你们品牌的风格”，这种用RAG很难，微调更合适。

一个判断小技巧：“模型不知道” → RAG；”模型不会做” → 微调。

问题3：知识更新频率多高？ 如果知识是高频变动的（产品手册、政策法规、商品库存），微调几乎不可行——你不可能每次政策变了就重训一遍模型。这种场景RAG是唯一解。

问题4：能不能接受不可解释？ 如果是金融、医疗、法律这种合规敏感的场景，必须能告诉用户”这个答案的依据是哪份文档第几页”——这种场景RAG的可溯源是硬需求，微调做不到。

讲两个我踩过的坑：

坑1：RAG的效果80%取决于检索，不是生成。 我第一次做RAG项目时，所有精力都花在调Prompt、换模型上，结果效果一直不好。后来排查发现是切片策略有问题——我们按固定字数切，把一个完整的”操作步骤”切成了两半，检索时只检到前半，模型自然答不全。真正影响RAG效果的是切片、embedding模型选型、检索召回率，而不是生成模型本身。

坑2：微调不是”喂数据就能学会”。 很多人以为微调就是”给模型1000条数据让它学”。实际上，1000条质量参差的数据，效果可能不如100条精挑细选的数据。而且微调容易出现”灾难性遗忘”——学了新能力，丢了原有能力。所以微调前PM要想清楚：这个能力值不值得用一部分通用能力去换。

现实中的最佳实践，往往是组合拳：

我现在做需求会按这个顺序考虑：Prompt → Few-shot → RAG → RAG+微调 → 全参数微调。前面的方案能解决就别用后面的，因为成本和复杂度是指数级上涨的。

一个典型的组合是：用微调让模型固化”行业话术和输出格式”，用RAG让它能查到最新的业务数据。比如做一个法律助手，微调让它学会”法律文书的写作风格”，RAG让它能查到最新的判例和法条——这种组合既保证了专业度，又保证了时效性。