夜雨聆风
前言
很多产品经理一准备转 AI，第一反应都是：
“我是不是得先把 Python 学了？”
然后打开课程一看：
机器学习、深度学习、Transformer、神经网络、反向传播、向量数据库……
学了两天以后，开始怀疑人生。
甚至觉得：
“AI 产品经理是不是已经不是产品经理了？”
其实完全没必要。
AI 产品经理当然需要懂技术。
但这里有一个非常重要的区别：
你需要懂技术，不代表你需要会做技术。
就像传统互联网产品经理需要知道：
* 什么是接口； * 什么是数据库； * 什么是前端和后端； * 什么是缓存； * 什么是同步和异步；
但通常不会要求产品经理自己搭服务器、写后端接口。
AI 产品也是一样。
你真正需要掌握的，不是“怎么训练一个大模型”。
而是：
这个技术能解决什么问题？
它有什么限制？
放到产品里应该怎么设计？
研发告诉你做不了的时候，你能不能听懂为什么？
功能上线以后，你知不知道应该怎么验收？
这才是 AI 产品经理真正需要掌握的技术深度。
---
一、AI 产品经理最怕的，不是不懂代码
真正危险的，其实是另外一种情况。
业务说：
“我们想做一个 AI 智能助手。”
产品经理说：
“可以，接个大模型。”
业务又说：
“希望它能根据公司所有资料回答问题。”
产品经理说：
“那就接个知识库。”
业务继续说：
“最好还能自己查询订单、修改信息、通知销售。”
产品经理说：
“那就做 Agent。”
看起来每个 AI 名词都知道。
但真正开始做的时候，问题全来了：
知识库里的内容为什么搜不到？
为什么 AI 明明检索到了正确资料，最后还是回答错？
为什么模型知道用户要查订单，却不会真的去系统里查询？
为什么 Agent 有时候执行三步，有时候执行五步？
为什么同一个 Prompt，今天效果不错，明天换几个问题就不行？
这个时候你会发现：
知道几个 AI 名词，和真正懂 AI 产品，是两回事。
AI 产品经理需要的技术能力，不是背概念。
而是要理解：
这些技术在一个真实产品里，到底是怎么工作的。
---
二、第一层：必须懂大模型最基本的工作方式
这一层是所有 AI 产品经理的基础。
至少要理解几个事情。
1. 大模型不是数据库
很多人刚接触 AI，容易把大模型理解成：
一个知道很多知识的超级数据库。
其实不是。
数据库的逻辑更接近：
你存了什么，我就给你查什么。
大模型更接近：
根据当前输入和已有能力，生成一个最可能的答案。
这两个东西完全不同。
所以大模型会出现一个非常典型的问题：
幻觉。
它可能不知道答案。
但仍然给你生成一个看起来很合理的答案。
这就决定了：
如果你的产品涉及价格、规则、订单状态、合同条款这些准确性要求很高的信息，
不能直接让模型“凭自己知道的回答”。
而应该：
查真实数据 → 把结果交给模型 → 再组织语言返回用户。
这已经是一个产品设计问题了。
---
2. 大模型非常依赖上下文
同一个模型、你给它不同的信息、结果可能完全不同
比如让 AI 判断：
“客户现在为什么不买？”
如果你只给一句：
“我再考虑一下。”
AI 很难准确判断。
但如果同时给它：
* 用户画像； * 前面五分钟的谈话内容； * 已经讲过什么； * 客户之前提出过什么疑虑； * 当前正在谈什么产品；
它的判断能力会明显提升。
所以 AI 产品经理要有一个很重要的意识：
模型效果不好，不一定是模型不行，也可能是你给它的信息不够。
这也是为什么 AI 产品里会经常提到一个词：
上下文。
你不用研究 Transformer 内部每一层怎么算。
但你必须知道：
模型看见什么，会直接影响模型做出什么判断。
---
3. AI 输出不是绝对确定的
传统程序：
1 + 1 = 2
只要代码没问题，它不会突然变成 3。
但 AI 不一样。
同一个问题换一种问法，
答案可能变化。
甚至完全相同的输入，也可能出现措辞、判断上的差异。
这意味着产品经理必须接受一件事：
AI 产品很难通过几条测试用例证明“功能完全正确”。
所以 AI 产品要做：
* 测试集； * 效果评测； * Bad Case； * 持续优化。
如果这一点不理解，就会一直问研发：
“为什么不能保证百分之百准确？”
很多 AI 项目最后双方互相折磨，本质就是产品经理还在拿传统软件的确定性要求 AI。
---
三、第二层：必须看懂一套 AI 产品的基本结构
AI 产品经理不一定会搭架构。
但你至少要能看懂一张简单的 AI 产品架构图。
比如一个企业 AI 问答产品，可能是：
用户提问
↓
理解用户问题
↓
检索知识库
↓
获取相关资料
↓
组装上下文
↓
调用大模型
↓
生成答案
↓
返回用户
如果用户问的是：
“帮我查一下这个订单现在到哪了。”
流程可能又变成：
用户提问
↓
AI 判断用户意图
↓
调用订单查询接口
↓
系统返回订单数据
↓
AI整理结果
↓
回复用户
这时候你会发现：
真正的 AI 产品，
通常不是：
用户 → 大模型 → 答案
而是：
用户 + 模型 + 数据 + 知识 + 工具 + 业务流程。
所以 AI 产品经理至少需要理解下面这些基本技术角色。
---
四、这些 AI 技术概念，产品经理至少要懂到什么程度？
Prompt：懂到能设计任务
不用研究所谓的“万能提示词”。
你需要知道的是：
如何把业务目标、角色、上下文、规则、输出要求告诉模型。
比如不能只写：
“分析一下客户。”
而应该知道为什么需要告诉 AI：
* 你分析的目标是什么； * 可以使用哪些信息； * 判断标准是什么； * 不允许做什么； * 最终输出什么结构。
所以产品经理对 Prompt 的要求是：
能把业务规则翻译成 AI 能执行的任务说明。
---
RAG：懂到知道什么时候需要知识库
你不需要自己写向量检索算法。
但至少要知道：
如果产品要求 AI 回答公司的私有知识，
通常不能只依赖模型本身。
需要让系统：
先找到相关资料，再让模型基于资料回答。
你还应该理解一个非常现实的问题：
RAG 不等于“把文件上传进去”。
效果还会受到很多东西影响：
* 文档质量； * 文档切分； * 检索方式； * 用户问题； * 召回结果； * 上下文组织。
这样以后研发说：
“模型回答错是因为知识没召回来。”
你至少知道应该继续问：
“是知识库里没有，还是有但没检索出来？”
这就是产品经理应该具备的技术判断力。
---
Embedding：懂到知道它解决什么问题
Embedding 不需要你会算。
产品经理知道一句话基本就够了：
它可以把内容变成机器能够比较“语义相似度”的表示。
所以：
“汽车出了事故怎么办？”
和：
“撞车以后怎么处理？”
虽然字面差别很大，
系统仍然可能认为它们表达的是相近意思。
知道这一点，你就能理解为什么 AI 搜索和传统关键词搜索不一样。
---
Function Calling / Tool Use：懂到知道 AI 怎么真正操作系统
大模型本身不会真的：
* 查订单； * 发短信； * 创建工单； * 修改客户状态； * 查询数据库。
它只会“理解并生成”。
真正的操作还是系统完成。
所以常见流程是：
AI 判断用户想做什么
↓
选择需要调用的工具
↓
系统执行
↓
把结果返回 AI
↓
AI 再告诉用户
产品经理理解这件事以后，
就不会再写这种需求：
“AI 自动查一下订单。”
而会继续拆：
AI 如何识别查询意图？
需要什么参数？
参数不全怎么办？
用户有没有权限？
查询失败怎么办？
查询结果回来以后怎么展示？
这就是从“会说 AI”变成“会做 AI 产品”。
---
Agent：懂到知道什么时候不该用
很多项目现在特别喜欢 Agent。
只要流程复杂一点，就说：
“我们做个 Agent。”
但 Agent 最大的特点之一恰恰是：
它有一定自主决策能力。
所以如果你的业务流程非常固定：
第一步必须做 A
第二步必须做 B
第三步必须做 C
那很多时候普通工作流就够了。
不一定非要 Agent。
只有当任务需要 AI 根据当前情况动态判断：
下一步应该做什么；
应该调用哪个工具；
是否需要继续执行；
Agent 才更有价值。
所以产品经理不需要研究 Agent 框架源码。
但必须知道：
什么时候应该用，什么时候用了反而把系统搞复杂。
---
五、第三层：要懂一点传统技术，但不用从头学计算机
很多人学 AI 产品时，会忽略传统互联网技术。
实际上 AI 最后还是要落进软件系统。
所以这些基础概念依然要懂：
* API 是什么； * 前端和后端怎么协作； * 数据库是什么； * JSON 大概长什么样； * 接口参数是什么； * 同步和异步是什么； * 权限是什么； * 日志是什么。
不用会写、但是必须能沟通
比如研发告诉你：
“模型输出了客户 ID，我们再调 CRM 接口获取客户信息。”
如果你完全不知道“接口调用”是什么意思，
后面的 AI 产品流程其实很难真正设计下去。
所以 AI 产品经理的技术学习，不应该只学 AI。
而应该建立：
传统软件基础 + AI 基础
两部分能力。
---
六、哪些东西可以先不用学？
这可能反而是很多人最关心的。
如果你的目标是做好 AI 产品经理，
下面这些东西可以了解，但前期没必要钻得太深：
* 神经网络数学推导； * 反向传播公式； * Transformer 详细数学原理； * CUDA； * 模型训练代码； * 分布式训练； * GPU 底层原理； * 微调算法的数学细节； * 自己实现向量数据库。
当然，你感兴趣完全可以学。
但它们不是成为一个合格 AI 产品经理的前置条件。
否则很容易出现一种情况：
你花一个月研究 Transformer，
但真正让你设计一个 AI 客服时，
你连：
什么时候查知识库，什么时候调用系统接口，什么时候转人工
都没有设计清楚、那学习顺序就反了
---
七、判断自己“技术够不够”，看这四件事
不要用：
“我会不会 Python？”
来判断自己是不是懂 AI。
对于产品经理来说，可以换成四个问题。
第一，你能不能判断？
业务给你一个需求，
你能不能大概判断：
需不需要 AI？
用大模型还是普通规则？
需不需要知识库？
需不需要 Agent？
---
第二，你能不能设计？
确定使用 AI 以后，
你能不能设计清楚：
输入什么？
AI 做什么？
需要什么上下文？
查询什么数据？
调什么工具？
输出什么？
出错怎么办？
---
第三，你能不能和研发沟通？
研发告诉你：
“这个问题是召回导致的。”
“上下文太长了。”
“这个地方需要调用 Tool。”
“模型自己完成不了，需要业务接口。”
你能不能听懂，
并继续讨论产品方案。
---
第四，你能不能验收？
产品上线以后，
你能不能判断：
AI 到底做得好不好？
不是简单地点几下按钮。
而是知道怎么：
* 准备测试问题； * 定义评价标准； * 找 Bad Case； * 分类问题原因； * 判断下一步优化哪里。
如果这四件事你都能做，
技术能力对于 AI 产品经理来说基本就已经够用了。
---
八、AI 产品经理最合适的技术位置
我一直觉得，
AI 产品经理最理想的位置，不是在两个极端。
不是：
完全不懂技术，只负责写需求。
也不是：
把自己训练成半个算法工程师。
而是站在中间。
向业务一侧，你要听得懂：
用户的问题是什么。
向技术一侧，你要知道：
AI 能不能解决，以及应该怎么解决。
然后把两边连起来。
所以 AI 产品经理真正需要的能力，可以浓缩成一句话：
不一定会实现，但一定要知道它是怎么实现的。
你不需要知道 Transformer 每一个矩阵是怎么算的。
但你需要知道：
为什么模型会幻觉。
你不需要自己开发向量数据库。
但你需要知道：
为什么知识库明明有答案，AI 却没有找到。
你不需要自己写 Agent。
但你需要知道：
什么时候应该让 AI 自己决策，什么时候必须写死流程。
---
最后
如果你正在从普通产品经理转向 AI 产品经理，
不要一上来就掉进技术细节里。
更合理的学习顺序应该是：
先理解 AI 能做什么
>
↓
>
再理解它为什么会做错
>
↓
>
再理解 AI 产品由哪些部分组成
>
↓
>
最后再逐步补 Prompt、RAG、Embedding、Tool Use、Agent 等技术概念
你的目标不是：
“比算法工程师更懂模型。”
而是：
比普通产品经理更懂 AI，比算法工程师更懂产品。
这才是 AI 产品经理真正有价值的位置。
---
下一篇：
《AI 产品经理基础 03：做 AI 产品，为什么第一步不是选模型？》