第1章 AI 行业认知与首个 MVP 实战

做了3年产品经理，我依然分不清"大模型"和"深度学习"的区别，直到有一天老板甩来一句话："下周给我们出一个AI产品方案。"

那一刻我才意识到——AI时代的产品经理，不懂技术底层，连需求都写不明白。

我是怕浪猫，一个从传统互联网转行AI产品的人。这个系列帮你从0到1建立AI产品经理的全链路能力。第1章，我们先解决最根本的问题：认知和动手。

1.1 产品观与岗位认知

建立正确的产品观

很多人对AI产品有一种"玄学感"——觉得AI什么都能做，又觉得AI什么都做不好。这两种极端都不对。

正确的AI产品观只有一条：AI是工具，不是目的。用户不关心你用了什么模型，用户只关心问题有没有被解决。

产品经理的第一性原理：用户要的不是AI，用户要的是答案。

传统产品经理的核心能力是"定义问题"和"设计解决方案"。AI产品经理的核心能力没变，只是解决方案的空间变大了——你有了更强大的工具，但也有了更复杂的不确定性。

具体来说，AI产品经理和传统产品经理的关键差异：

维度	传统产品经理	AI产品经理
解决方案确定性	高，功能逻辑清晰	低，模型输出有随机性
迭代方式	需求→开发→测试→上线	数据→训练→评测→部署
质量标准	功能可用、体验流畅	准确率、召回率、幻觉率
用户预期管理	明确承诺功能边界	需要管理AI的"不确定性预期"
核心技能	交互设计、项目管理	提示词工程、RAG、评测体系

这种差异带来一个根本性的变化：传统产品的质量是"确定性"的——按钮点了就有反应。AI产品的质量是"概率性"的——同一个问题可能得到不同的回答。这意味着AI产品经理需要建立一种新的质量观：不是追求100%正确，而是追求"可接受的正确率 + 优秀的错误处理"。

举个例子。一个翻译产品，如果10次翻译有9次准确，1次有偏差但用户可以快速修改——这是好的AI产品体验。但如果是9次准确，1次完全胡说八道且没有任何提示——这就是差的体验。差距不在准确率，在于对"那1次错误"的处理。

AI产品经理岗位职责与能力模型

AI产品经理的岗位在国内2023年爆发，到现在已经形成了比较清晰的职责边界。核心职责分4块：

1. 需求分析与场景定义

不是所有场景都适合用AI解决。你需要判断：这个问题的输入是什么？期望输出是什么？容错空间有多大？如果一个场景要求100%准确（比如医疗诊断的最终判断），那就不适合用大模型直接做最终决策，但可以用来做辅助分析。

场景选择的5个评估维度：

评估维度	适合AI	不适合AI
容错空间	有一定容错（推荐、建议类）	零容错（金融交易、医疗确诊）
数据基础	有结构化或半结构化数据	数据极度稀缺或极度敏感
重复性	高频重复任务	低频一次性任务
人类评估	人类能快速判断对错	人类也难以判断对错
价值密度	AI替代后显著提效	AI替代后提升有限

2. 技术方案设计与评估

你不需要写代码，但你需要知道RAG和微调的区别，知道什么时候用Agent，什么时候用简单的工作流。你需要在技术方案评审中提出有质量的问题，而不是被开发牵着鼻子走。

常见的技术选型决策：

场景	推荐方案	理由
企业知识问答	RAG + 向量数据库	数据更新快，无需重新训练
特定风格写作	提示词工程 + Few-shot	比微调灵活，成本更低
多步骤复杂任务	Agent + 工具调用	需要自主决策和外部能力
特定领域高精度	微调	需要大量领域数据，但精度要求高

3. 数据策略与评测体系

AI产品的质量70%取决于数据。你需要定义什么数据是好的，怎么评测模型的表现，怎么发现badcase并系统化地修复。

数据策略的3个层次：

第一层：基础数据——知识库文档、FAQ、产品手册。这是RAG的输入。 第二层：评测数据——标准问答对、边界case、对抗性样本。这是质量保障。 第三层：运营数据——用户对话日志、满意度评分、badcase标注。这是持续优化的输入。

AI产品经理最核心的能力不是懂技术，而是懂边界——知道AI能做什么，更知道AI不能做什么。

4. 用户预期管理

AI产品天然有不确定性。用户问一个问题，可能得到完美答案，也可能得到一本正经的胡说八道。你怎么设计产品来管理这种不确定性？

常见的预期管理策略：

• 置信度提示：让AI在回答时标注自己的信心水平（"我比较确定/不太确定"）
• 来源引用：让AI标注信息来源，方便用户验证
• Fallback机制：当AI无法回答时，优雅地引导转人工或给出替代方案
• 用户纠错反馈：允许用户标记AI的回答是否正确，形成闭环
• 渐进式展示：先给简短回答，用户追问时再展开细节

AI产品经理市场需求分析

看几组数据。2024年国内AI产品经理岗位的招聘量同比增长超过200%，薪资中位数比传统产品经理高出30%-50%。但市场供需是错配的——企业需要的是既懂AI又懂产品的人，而大多数候选人只占一头。

目前市场上AI产品经理的来源主要有三条路径：

路径一：传统产品经理转型 最常见，优势是产品基本功扎实，劣势是技术理解需要补课。转型周期3-6个月，关键是快速建立对大模型能力边界的直觉。

路径二：技术人员转产品 优势是懂技术，劣势是容易"技术驱动"而非"用户驱动"。最大挑战是从"我能实现什么"切换到"用户需要什么"。

路径三：应届生直接入行 优势是学习能力强，劣势是既缺产品经验又缺技术深度。需要系统化培养，建议从特定行业切入。

市场需求的地域分布也有特点：北京和深圳的需求最大（AI公司密集），其次是上海和杭州。二三线城市的AI产品经理岗位主要集中在传统企业的AI转型项目上。

技术专家为什么需要AI产品设计能力

如果你是工程师、算法研究员，你可能会想：我把模型做好不就行了，为什么要学产品设计？

因为AI时代，技术价值要通过产品来兑现。一个99%准确率的模型，如果产品交互设计得差，用户体验依然很差。反过来，一个90%准确率的模型，配合好的产品交互（比如让用户确认AI的输出、提供修改建议），用户满意度可能反而更高。

具体来说，技术专家学产品设计有3个好处：

1. 避免"技术自嗨" 很多技术团队做了一个很酷的Demo，但用户不用，因为没有解决真实痛点
2. 提升技术决策质量 懂产品后，你知道哪些技术投入的ROI最高
3. 扩大职业天花板 技术专家的终极竞争力是"技术+商业"的双重视角

技术决定上限，产品决定下限。大多数用户感知到的是下限。

AI Native明星产品初步感知

在深入学习之前，先感受一下当前做得好的AI Native产品是什么样的。所谓AI Native，不是"在原有产品上加一个AI功能"，而是"以AI为核心重新设计产品"。

ChatGPT 对话式交互的开创者。核心洞察：用户不需要学习复杂的界面，只需要自然语言对话。但它的问题也很明显——对话式交互对复杂任务效率低，用户需要反复描述上下文。

Perplexity AI搜索的开创者。核心洞察：搜索的本质是"获取答案"，不是"获取链接"。把搜索结果直接变成结构化的答案，附上引用来源。产品设计上的亮点：每个回答都有来源标注，降低了用户验证成本。

Cursor AI编程工具。核心洞察：程序员最大的痛点不是写代码，而是理解代码和调试。把AI嵌入到编辑器的工作流中，而不是做成独立的聊天窗口。关键设计决策：Tab键接受建议——把AI输出变成了零阻力操作。

Notion AI 文档+AI的融合。核心洞察：用户不是"找AI聊天"，而是在工作过程中需要AI辅助。AI功能嵌入在文档编辑的上下文中，用户不需要切换界面。

这些产品的共同特征：不是把AI当插件，而是用AI重新定义交互方式。这也是AI Native产品设计的核心原则——AI不是功能，AI是交互本身。

1.2 AI 技术发展脉络

人工智能发展简史

了解历史不是为了考试，而是为了理解：为什么今天的大模型能做到这些事，以及哪些事它依然做不到。

AI发展经历了三次浪潮：

第一次浪潮（1956-1974） 符号主义时代。核心思路是用规则和逻辑来模拟智能。代表成果：专家系统——把领域专家的知识编码成if-then规则。早期在医疗诊断、化学分析领域取得了不错的成果。局限：规则无法穷举现实世界的复杂性，维护成本随规则数量指数级增长。这个时代的教训：智能不能靠人工编写规则来实现。

第二次浪潮（1980-1995） 连接主义复兴。核心思路是模拟人脑的神经网络，通过数据学习模式。代表成果：反向传播算法——让多层神经网络的训练成为可能。但这个时期算力不足，数据不够，网络只能做得很浅。这个时代的教训：好的算法需要好的硬件和数据来支撑。

第三次浪潮（2012-至今） 深度学习时代。核心突破：算力（GPU）、数据（互联网）、算法（深度网络）三要素齐备。关键里程碑：

年份	事件	意义
2012	AlexNet赢得ImageNet	深度学习在计算机视觉领域突破
2016	AlphaGo战胜李世石	深度学习在决策领域突破
2017	Transformer论文发表	大模型的基础架构诞生
2020	GPT-3发布	涌现能力首次被大规模验证
2022	ChatGPT发布	大模型走向大众

每一次AI浪潮的退潮，都不是因为技术不行，而是因为期望过高。这次也一样，我们需要理性看待大模型的能力边界。

大模型时代的到来

2017年，Google发表了《Attention Is All You Need》，提出了Transformer架构。这是大模型时代的基础。Transformer的核心创新是自注意力机制（Self-Attention），它让模型能够同时关注输入序列中的所有位置，而不是像RNN那样逐个处理。

2020年，OpenAI发布GPT-3，参数量1750亿。这是大模型时代的起点——人们第一次发现，模型大到一定程度，会涌现出小模型不具备的能力。

2022年底，ChatGPT发布，两个月用户破亿。这是大模型走向大众的起点。ChatGPT的成功不只因为模型强，更因为产品交互设计得好——对话框简洁、流式输出、会话历史、这些产品设计决策让普通用户也能轻松使用。

2023-2025年，模型能力持续提升，成本持续下降。GPT-4、Claude、Gemini、Llama、DeepSeek等模型百花齐放。应用层爆发：RAG、Agent、工作流成为主流技术栈。这个阶段最大的变化是：AI从"技术圈的话题"变成了"所有行业都在讨论的战略方向"。

大模型与Scaling Law

Scaling Law是大模型时代的核心规律，由OpenAI在2020年提出。简单说就是：

模型性能随着三个因素的增大而提升：

1. 模型参数量（Params）——模型越大，能记住的模式越多
2. 训练数据量（Data）——数据越多，模式的覆盖面越广
3. 训练计算量（Compute）——算力越多，训练越充分

三者中任何一个增加，模型性能都会提升。但提升不是线性的——存在一个"涌现"的临界点。当模型参数量超过一定阈值（大约在几百亿参数），模型会突然获得一些小模型不具备的能力，比如：

• 上下文学习（In-Context Learning）：不需要微调，直接在prompt中给几个例子就能学会新任务
• 思维链推理（Chain-of-Thought）：能把复杂问题分解成多步推理
• 指令遵循（Instruction Following）：能理解并执行自然语言指令

但Scaling Law也意味着：模型的提升越来越贵。从GPT-3到GPT-4，训练成本增长了数十倍，但性能提升并没有数十倍。这也是为什么行业开始探索"小模型+RAG"和"小模型+Agent"的路线——用更聪明的架构和工具来弥补参数量的不足。

Scaling Law告诉我们：量大出奇迹。但它没告诉我们，量要到多大才能解决你的具体问题。

对产品经理来说，理解Scaling Law的实际意义是：不要盲目追求最大的模型。很多时候，一个中等大小的模型配合好的RAG和工作流设计，效果比单纯用大模型更好，成本还低一个数量级。

AI训练范式与大模型的训练过程

大模型的训练分为三个阶段：

阶段一：预训练（Pre-training）

用海量文本数据（互联网网页、书籍、论文等）训练模型预测下一个token。这个阶段模型学会了语言的统计规律，但不一定遵循人类意图。成本最高，通常需要数千块GPU训练数周甚至数月。

预训练的数据量级：GPT-3用了约570GB的文本数据，GPT-4估计用了13万亿token。数据的来源和质量直接决定模型的知识范围和能力上限。

阶段二：监督微调（SFT, Supervised Fine-Tuning）

用人工标注的"指令-回复"对训练模型学会遵循指令。比如：

指令：请用简洁的语言解释什么是机器学习
回复：机器学习是一种让计算机从数据中自动学习规律并做出预测的技术，无需人工编写规则。

SFT的数据量级远小于预训练——通常只有几万到几十万条，但每条都是精心标注的。SFT让模型从"能说话"变成"听指挥"。

阶段三：RLHF（人类反馈强化学习）

让人类对模型的多个回复进行排序，训练一个奖励模型，再用强化学习优化大模型，使其输出更符合人类偏好。这个阶段让模型学会"说什么好"而不只是"说什么对"。

对产品经理来说，理解这三个阶段的意义在于：

训练阶段	能力	局限	产品经理的关注点
预训练	语言理解和生成	不听指令	模型的知识范围和时效性
SFT	遵循指令	可能产生有害内容	指令遵循的稳定性和边界
RLHF	对齐人类偏好	可能过度安全（拒绝正常问题）	拒答率和安全性校准

一个常见的误区：以为微调就能解决一切问题。实际上，微调需要大量高质量数据，且容易过拟合。对大多数企业来说，RAG + 提示词工程的ROI远高于微调。

LLM核心运作机制

大模型的核心机制其实很简单：预测下一个token。

你给模型一段文字，它预测下一个最可能出现的token（可以理解为一个字或词）。然后把你给的文字加上预测的token，再预测下一个。如此循环，直到预测出结束符。

这个机制意味着几个关键点：

1. 模型没有真正的"理解" 它只是在统计意义上知道什么token最可能出现在什么位置。但统计规律足够强大时，看起来就像"理解"了。这就是所谓的"中文房间"问题——模型看起来懂了，但它只是在进行统计匹配。

2. 模型的输出是概率性的 同一个输入，每次运行可能得到不同的输出。这就是为什么需要控制温度参数（Temperature）——温度越高，输出越随机；温度越低，输出越确定。产品经理需要根据场景选择合适的温度：创意场景用高温度，精确场景用低温度。

3. 模型有上下文窗口限制 模型一次能处理的token数量有限（GPT-4o是128K，Claude 3.5是200K）。超出窗口的内容模型"看不见"。这对产品设计有直接影响——如果你的产品需要处理长文档，就需要设计分段和检索策略。

4. 模型的"注意力"不是均匀分布的 研究发现，模型对上下文开头和结尾的信息关注更多，中间部分容易被忽略。这就是"Lost in the Middle"问题。在设计RAG系统时，关键信息应该放在开头或结尾。

大模型的本质是概率预测器，不是知识库。它"记住"的是概率，不是事实。这就是幻觉的根源。

大模型的特性、挑战与能力边界

特性：

• 强大的语言理解和生成能力
• 上下文学习能力（Few-shot Learning）
• 多任务泛化能力——一个模型做N件事
• 一定的推理能力（特别是思维链推理）
• 多语言能力——训练数据覆盖的语言都能处理

挑战：

• 幻觉（Hallucination）：自信地说错话，这是当前最大的问题
• 时效性：训练数据有截止日期，不知道最新发生的事
• 一致性：同一问题多次回答可能不同
• 长上下文理解：信息在上下文中间时容易被忽略
• 私有知识缺乏：不知道你公司的内部信息
• 计算成本：大模型的API调用费用不低

能力边界（当前模型做不好的事）：

• 精确计算（大模型不擅长数学运算，需要代码解释器）
• 实时信息获取（需要联网工具）
• 长程规划（需要Agent框架来拆解和跟踪）
• 高可靠性决策（不能替用户做最终决定，只能辅助）
• 多模态深度理解（图片理解能力在提升，但还不够可靠）

产品经理的关键能力：准确判断一个需求是否在大模型的能力边界内。如果在边界外，需要通过产品设计来弥补——RAG弥补知识缺失，工具调用弥补能力不足，人机协作弥补可靠性问题。

1.3 首个 MVP 实战

AI产品的MVP之道

传统产品的MVP强调"最小可行产品"——核心功能能用就行。AI产品的MVP多了一个维度：质量的最低可接受线。

一个聊天机器人，如果10次对话有3次答非所问，用户就跑了。所以AI产品的MVP不是"功能最小化"，而是"在可接受质量下做到功能最小化"。

AI产品MVP的3个关键原则：

原则一：缩小场景，不要缩小功能

与其做一个什么都能聊但什么都聊不好的通用机器人，不如做一个只能回答公司FAQ但回答准确的专用机器人。场景越小，质量越容易控制。

比如：

• 不好的MVP：一个万能AI助手（什么都能问，但什么都不准）
• 好的MVP：一个退货政策查询助手（只能回答退货相关问题，但100%准确）

原则二：用RAG，不要用微调

微调需要数据、算力、时间。RAG只需要文档和向量数据库。MVP阶段，RAG的ROI远高于微调。更重要的是，RAG的数据可以随时更新，微调的模型更新一次就要重新训练。

原则三：先跑通再优化

第一次做不要追求完美的检索策略和提示词。先用最简单的方案跑通，再根据badcase迭代。常见的优化顺序：

第一版：基础RAG + 简单提示词
第二版：优化分段策略 + 增加rerank
第三版：Query优化 + 混合检索
第四版：语义路由 + 多轮对话记忆

MVP不是偷懒的借口，是验证假设的工具。你的假设是"用户需要这个AI解决这个特定问题"，MVP就是用最低成本验证这个假设。

实战：零代码搭建你的首个MVP

我们用Coze（扣子）来搭建一个最简单的AI客服MVP。不需要写一行代码，30分钟搞定。

步骤一：创建Bot

登录Coze（coze.cn），点击"创建Bot"，填写基本信息：

• 名称：公司客服助手
• 描述：基于公司FAQ自动回答客户咨询

步骤二：编写提示词

提示词是AI产品的灵魂。一个基础的客服提示词模板：

你是一个专业的客服助手。你的职责是基于提供的知识库回答客户问题。

规则：
1. 只回答知识库中有的信息，不要编造
2. 如果知识库中没有相关信息，回复"抱歉，我暂时无法回答这个问题，请转人工客服"
3. 回答要简洁明了，不要啰嗦
4. 对每个回答，标注信息来源（引用知识库中的具体条目）
5. 如果用户的问题模糊，主动追问澄清

语气：专业、友好、耐心

提示词编写的3个要点：

• 角色定义要明确（你是谁、你的职责是什么）
• 规则要具体（能做和不能做的都要写清楚）
• 语气要定义（专业/友好/简洁/详细，根据场景选择）

步骤三：上传知识库

把公司的FAQ文档上传到Coze的知识库。支持的格式包括：TXT、PDF、DOCX、CSV。建议使用结构化的CSV格式：

问题,答案,分类
如何退货?,自收到商品7天内可申请退货，请在"我的订单"中发起退货申请,售后
运费怎么算?,满99元包邮，不满99元收8元运费，偏远地区另计,物流
支持哪些支付方式?,支持微信支付、支付宝、银行卡,支付

为什么用CSV？因为结构化的数据检索效果远好于非结构化文档。Coze会自动将CSV的每一行作为一个知识片段，检索精度更高。

步骤四：测试和调试

在Coze的预览窗口中测试几个典型问题：

• 知识库覆盖的问题 → 应该准确回答并标注来源
• 知识库没有的问题 → 应该引导转人工，不编造答案
• 模糊的问题 → 应该追问澄清，而不是猜一个答案
• 对抗性问题 → 用户故意问刁钻问题时，应该保持规则约束

步骤五：发布

Coze支持多渠道发布：网页、微信、飞书等。选择你需要的渠道，一键发布。

这样一个最基础的AI客服MVP就完成了。当然，它还很粗糙，但足以验证核心假设：用户是否愿意用AI来解决客服问题。

实战：手把手本地部署Dify

如果你的需求更复杂（比如需要自定义工作流、需要接入自己的数据库、需要更精细的控制），Coze的自由度可能不够。这时候Dify是更好的选择。

Dify是一个开源的LLM应用开发平台，支持本地部署，适合有定制化需求的团队。

步骤一：环境准备

# 确保已安装Docker和Docker Compose
# 安装文档：https://docs.docker.com/get-docker/

# 克隆Dify仓库
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境变量文件
cp .env.example .env

步骤二：启动服务

docker compose up -d

# 查看服务状态（应该看到多个容器在运行）
docker compose ps

启动后访问 http://localhost/install 完成初始化设置，创建管理员账号。

步骤三：创建应用

Dify支持4种应用类型：

应用类型	适用场景	交互方式	复杂度
聊天助手	客服、问答、陪伴	对话式	低
文本生成	写作、翻译、摘要	单轮输入输出	低
Agent	复杂任务、工具调用	自主决策	中
工作流	流程化任务、多步骤	预定义流程	高

MVP阶段建议从"聊天助手"开始，后续再升级为工作流或Agent。不要一上来就做最复杂的Agent——先验证场景有价值，再投入更多技术资源。

步骤四：配置知识库

在Dify中创建知识库，上传文档，选择分段策略：

• 自动分段：适合格式规范的文档（FAQ、产品手册）
• 自定义分段：适合需要精确控制的场景（法律法规、合同条款）

分段策略的选择直接影响检索效果。建议初始用自动分段（段落模式，每段最大500 token，重叠50 token），上线后根据badcase调整。

步骤五：配置模型

Dify支持接入多种大模型。在"设置-模型供应商"中配置API Key：

# 以OpenAI为例
# 填入OpenAI API Key
# 选择默认模型：gpt-4o-mini（性价比最优，MVP够用）

模型选择建议：

场景	推荐模型	理由
MVP验证	gpt-4o-mini	成本低，速度快，质量够用
生产环境	gpt-4o / Claude 3.5	质量更高，适合对外服务
中文场景	DeepSeek / Qwen	中文能力更强，成本更低
隐私敏感	本地部署Llama 3	数据不出服务器

步骤六：调试和发布

在Dify的调试界面测试各种场景，确认效果满足要求后发布。

Dify提供多种发布方式：

• Web应用：生成一个可访问的网页，直接分享链接
• API接口：供前端或其他系统调用，适合集成到现有产品
• 嵌入式组件：嵌入到现有网页中，一行代码搞定

部署Dify不是目的，跑通MVP才是。别在部署上花太多时间，20分钟搞不定就看官方文档。

两个MVP方案对比

维度	Coze	Dify
部署方式	云端SaaS	本地/云端
代码要求	零代码	需要Docker基础
自定义程度	中等	高
数据安全	数据在Coze服务器	数据在自己服务器
适合阶段	快速验证	需要深度定制
成本	免费额度够用	需要服务器成本

建议：先用Coze快速验证，确认场景有价值后再迁移到Dify做深度定制。

本章小结

主题	核心要点
产品观	AI是工具不是目的，用户要的是答案
岗位认知	场景定义、技术评估、数据策略、预期管理
技术脉络	三次AI浪潮，Scaling Law，预训练/SFT/RLHF三阶段
能力边界	幻觉、时效性、一致性是核心挑战
MVP原则	缩小场景、用RAG不用微调、先跑通再优化
零代码MVP	Coze 30分钟搭建AI客服
Dify部署	Docker一键部署，从聊天助手开始
方案选择	先Coze验证，后Dify定制

觉得有用？收藏起来，下次直接照抄。

你做过AI产品的MVP吗？用的什么工具？评论区聊聊。

关注怕浪猫，下期我们讲提示词工程——这是AI产品经理最重要的基本功，没有之一。

系列进度 1/13

下章预告： 第2章高级提示词工程 + AI产品评测，从思维链到自洽性推理，从过拟合到数据漂移，掌握驾驭大模型和评估AI产品的核心能力。