AI产品经理必懂的60个核心概念

写在最前​

💡 LLM 大语言模型​

所有人都在说大模型多厉害，但很少有人告诉你，它的本质就是一个文字接龙机器。给它一段话，它预测下一个最可能出现的词，然后拿预测出的词再继续预测下一个，循环往复直到结束。​

​

💪

Step 1它不是在思考，是在做概率计算。所以涉及严密逻辑推理的场景，它经常出错，不是偶尔，是经常。​

Step 2它的知识有截止日期，训练数据截止到某个时间点，之后发生的事情它不知道，问了只会编。​

Step 3同样的输入每次输出可能不同，因为它在多个高概率词之间随机选择，要想输出稳定就得调低温度参数。​

​

我带过的 AI 项目里，最贵的教训就是一开始没想清楚模型做不了什么。做 AI 产品的第一步不是想 AI 能做什么，而是想清楚 AI 做不了什么，把做不了的部分用规则、人工、兜底策略补上。想反了，项目必翻。​

​

​

​

02​

PART​

💡 Prompt 提示词​

❓你花了两周调一个 AI 客服，换了三个模型效果都不好，最后一个实习生把 Prompt 重写了一遍，效果直接提升了一个档。不是模型不行，是指令写得太糊。​

很多 PM 觉得 Prompt 就是随便写句话让模型干活。错！同一个模型，Prompt 写得好和写得差，输出质量能差十倍。Prompt 不是聊天，是下达精确指令。​

​

好 Prompt 四要素：​

角色设定，你是谁；​

任务描述，做什么；​

输出约束，格式和长度；​

上下文信息，参考资料。​

​

💡这四个要素缺一个，模型输出就会发散。角色设定不明确，模型不知道用什么口吻回答。输出约束不写，模型可能给你返回一篇论文也可能给你返回一句话。​

​

💪

为什么 Prompt 效果这么敏感？底层原因是大模型靠概率预测下一个 Token，Prompt 里的每一个词都在影响后续 Token 的概率分布。你多写一句请用 JSON 格式输出，模型后续生成 JSON 的概率就会被大幅提升。反过来，你的指令含糊不清，模型在多个方向上概率都差不多，输出就飘了。​

​

我经手的 AI 项目里，至少一半的效果问题最后都是优化 Prompt 解决的，不是换模型，不是加数据，就是把指令写得更精确。这是 AI PM 性价比最高的技能，零成本，立刻见效。​

​

​

​

03​

PART​

💡 Token 计费单位​

❓你的 AI 产品做完 Demo 老板很满意，结果上线第一个月账单来了，模型调用费直接干到六位数。不是产品设计有问题，是你从来没算过 Token 这笔账。​

所有人都在关注模型效果好不好，但真正杀死 AI 项目的往往是成本。而成本的最小计量单位就是 Token。​

💡Token 是大模型处理文本的最小单位。英文里一个词大约 1-1.5 个 Token，中文更贵，一个汉字大约 1.5-2 个 Token。API 按照输入 Token 和输出 Token 分别计费，输出通常比输入贵 2-4 倍。​

​

💪

为什么 PM 必须理解 Token？​

因为它直接关联两个产品决策。​

第一个是成本，你的 System Prompt 有 2000 字，大约消耗 3000-4000 Token，每次调用都要发一遍。日均 10 万次调用，光 System Prompt 一个月就烧几千到上万块。乘以输出 Token 的消耗，总成本很容易超出预期。​

第二个是上下文窗口，模型能处理的 Token 总数是有上限的。16K 窗口听着很多，减去 System Prompt、工具定义、对话历史，真正留给业务内容的空间比你想象少得多。​

​

需求评审时让算法同事估算一个公式，单次 Token 消耗 × 日均调用量 × 单价 = 月成本。这个数字写进 PRD 里，不算这笔账的 AI 项目，十个死九个。​

​

​

​

04​

PART​

💡 RAG 检索增强生成​

❓老板让你做一个内部知识问答系统，你找了个大模型接上就上线了。用户一问公司报销政策，模型一本正经地编了一套完全不存在的规定。你被投诉了，才知道大模型不是万能的。​

大多数人以为大模型什么都知道。错。大模型的知识在训练完那一刻就冻住了，你们公司的退款政策、产品文档、内部规范，它一个字都不知道。问到了它不会说不知道，它会编一个听起来合理的答案骗你。​

​

💪

RAG 就是解决这个问题的，核心思路四个字，开卷考试。每次用户提问时，系统先从你的知识库里搜出最相关的文档片段，塞进 Prompt 里，让模型基于这些真实资料来回答。模型自己不知道的东西，你帮它找到原文让它照着答就行了。​

​

​

😀

核心流程四步，文档切段做 Embedding 存入向量数据库 → 用户问题也转成 Embedding → 在向量库中检索语义最相似的文档段 → 把检索到的段落拼进 Prompt 让模型生成回答。​

​

这里有个很多 PM 踩过的坑。RAG 效果不好，80%的问题不在模型上，在检索上。搜出来的文档片段不对，模型拿着错误的资料回答，当然答不到点上。我经手的 RAG 项目里，花在优化文档切分策略、Embedding 模型选型、Reranking 精排上的时间，远超花在调模型上的时间。检索质量是 RAG 的生死线。​

​

​

​

05​

PART​

💡 Fine-tuning 微调​

❓你用 Prompt+RAG 搞了两个月，客服机器人的回复风格始终不像真人客服，怎么调 Prompt 都约束不住。算法同事说试试微调吧。你一脸懵，微调和 RAG 到底什么区别？什么时候该用哪个？​

很多人把 RAG 和微调搞混。一句话讲清楚，RAG 是给模型开卷考试，它本身没变，只是看着你的资料回答。微调是真的让模型学会了，模型参数被改了，行为模式会发生变化。​

​

👀

什么时候该用微调？三种情况。​

1️⃣你需要特定的输出风格或语气，Prompt 怎么写都约束不住。比如你们客服有一套独特的话术风格，AI 怎么写都不像。​

2️⃣你需要模型学会你自己定义的分类体系，标准和通用标准不一样。​

​

​

微调的成本比 RAG 高一个量级。贵在三个地方：​

数据准备需要人工整理和质检高质量的问答对，几千到几万条；​

训练需要 GPU 算力，一次训练费用几千到几万；​

业务规则变了得重新训练，不像 RAG 更新文档就行。​

​

LoRA 是省钱方案，只训练原始模型 0.1%-1%的参数，效果接近全参微调但成本降 90%。​

​

做 AI 产品有个决策路径我一直在用，先试 Prompt Engineering，效果不够加 RAG，RAG 到顶了再上微调。这个路径能帮你省掉 90%不必要的成本。别上来就想微调，大部分场景用不着。​

​

​

​

06​

PART​

💡 Agent 智能体​

❓你做了一个 AI 聊天助手，用户说帮我订明天从北京到上海的高铁票，你的 AI 回了一段怎么在 12306 订票的教程。用户骂骂咧咧走了。不是模型不行，是你的产品只有嘴没有手。​

所有人都在说 Agent 是下一个风口，但大部分人理解的 Agent 还停留在更聪明的聊天机器人。错。Agent 和聊天机器人的本质区别不是更聪明，而是它能动手干活。​

​

聊天机器人只能生成文字。Agent 能自己拆解复杂任务、规划步骤、调用外部工具执行操作、拿到结果后判断下一步怎么做。核心能力三件套，规划，把用户需求拆成可执行的步骤；工具调用，调 API 去执行每一步操作；观察调整，看到执行结果后决定继续还是换路。​

​

​

👀

这意味着产品设计的范式变了。以前你设计的是对话流，用户说什么 AI 回什么。现在你设计的是任务流，用户说一个目标，Agent 自己规划怎么做。对话流有标准答案，任务流没有，每次执行路径可能都不一样。​

​

Agent 目前最大的问题是可靠性。每一步都有出错概率，多步串联后错误会累积。我带过的 Agent 项目里，核心流程的设计时间和兜底策略的设计时间比例大概是 3：7。没错，兜底比正常流程重要得多。Agent 失败了用户可以接受，Agent 失败了还不告诉用户，用户绝对不能接受。​

​

​

​

​

07​

PART​

💡 Function Calling 函数调用​

你给 Agent 注册了十几个工具，结果它动不动就选错工具，该查天气的去查了日历，该下单的去查了库存。不是 Agent 笨，是你工具定义没写好。​

Agent 能干活靠的底层机制就是 Function Calling。但很多 PM 把它理解成模型自己调 API，这是错的。模型自己不执行任何操作，它只做两件事，判断该调哪个函数，生成调用参数的 JSON。真正执行操作的是你的后端代码。​

运作流程，你提前告诉模型有哪些工具函数可用，每个需要什么参数。用户发自然语言请求后，模型从工具列表里选一个最合适的，输出结构化的调用请求。后端拿到这个请求去真正执行，把执行结果返回给模型，模型再基于结果生成最终回复。​

PM 在这里的核心工作不是写代码，而是定义四件事。Step 一工具集，你的 Agent 能用哪些工具，每个工具的功能描述要写到模型能理解的程度。Step 二使用条件，什么情况调什么工具，边界要清晰。Step 三优先级，多个工具都能用时先用哪个。Step 四错误处理，工具调用失败了怎么办，超时了怎么办，返回空结果怎么办。​

一个实操经验，工具描述的质量直接决定模型选对工具的概率。描述写得模糊，模型就会选错。把工具描述当 API 文档写，名称、功能、参数、返回值、使用场景都要写清楚。​

​

​

​

08​

PART​

💡 Embedding 向量嵌入​

你做了一个知识问答系统，用户搜苹果手机卡顿怎么办，系统返回了一堆苹果种植技术的文档。关键词搜索搞不定语义理解，同一个词在不同语境下的意思完全不同。​

传统搜索靠关键词匹配，有就有没就没，不理解意思。Embedding 把文字变成一串数字，也就是向量，用数学方式表示语义。意思相近的文字向量距离近，意思不同的距离远。​

妙处在哪？苹果手机很好用和 iPhone 性能不错的向量距离很近，因为它们意思接近。但苹果手机很好用和今天吃了一个苹果的向量距离很远，虽然都有苹果二字。Embedding 模型能根据上下文理解同一个词的不同含义，这是关键词搜索永远做不到的。​

底层原理，Embedding 模型在大规模语料上预训练，学会了把语义相似的文本映射到高维空间中相近的位置。输出是一个固定长度的浮点数数组，比如 1536 维，每个维度代表一个语义特征。两个文本的语义相似度就是它们向量的余弦相似度。​

PM 做 RAG 项目要关注三件事。Step 一Embedding 模型对中文的支持度，有些模型英文效果好中文效果差。Step 二向量维度，越高越精确但存储和检索成本也越高。Step 三向量数据库选型，不同数据库在检索速度、支持规模、运维成本上差异很大。Embedding 是 RAG 的基础设施，选错了后面全是坑。​

​

​

09​

PART​

💡 Hallucination 幻觉​

你的 AI 客服对用户说您的订单可以在 7 天内无理由退款，但你们公司的退款政策是 15 天。用户按 7 天投诉，客服团队一头雾水。一查发现是 AI 自己编的。​

所有人都怕 AI 犯错，但很多 PM 不知道这种编造不是 Bug，是大模型概率预测机制的必然结果。它不知道什么是事实，只知道什么词经常一起出现。当训练数据里没有你们公司退款政策时，它不会说我不知道，而是根据统计规律编一个听起来合理的答案。​

主流模型在事实性问答场景下的幻觉率大概在 10%-30%之间。就是说每三到十个回答里就可能有一个是编的。这个比例在没有 RAG 接地的场景下会更高。​

为什么幻觉无法根治？因为模型的生成机制就是预测最可能的下一个 Token。什么叫最可能？基于训练数据中的统计规律。如果训练数据里退款这个词后面经常跟 7 天，模型就会倾向于输出 7 天。它不关心这对你的业务是不是正确的。​

产品防范三条路。Step 一RAG 接地，让模型基于真实文档回答而不是凭记忆编。Step 二输出校验，模型输出后做二次检查，比如数字和规则是否匹配。Step 三信任度设计，标注信息来源，低置信度转人工，让用户知道哪些是有依据的哪些是不确定的。​

上线前必须做大规模 Bad Case 测试。别拿 Demo 效果当真，Demo 里你问的都是模型擅长的问题，线上用户会问各种你想不到的东西。​

​

​

​

10​

PART​

💡 多轮对话与上下文管理​

❓你的 AI 助手聊了五轮之后突然开始答非所问，前面说的条件全忘了，用户说就按刚才那个方案，AI 问什么方案？用户直接卸载。​

很多 PM 以为大模型天然会记住对话历史。错，完全错。大模型没有记忆，每次 API 调用它都是从零开始。你在产品里看到的多轮对话效果，是你的后端每次把 System Prompt 加上所有历史对话消息打包一起发给模型的结果。模型自己不存任何状态。​

​

👀

​

​

👀

三种上下文保留策略：​

1️⃣滑动窗口，只保留最近 N 轮对话，简单直接但会忘掉早期重要信息。​

2️⃣摘要压缩，让模型把早期对话总结成一段摘要放在前面，省 Token 但会丢失细节。​

3️⃣关键信息提取，把对话中的关键实体和决策单独提取存储，占 Token 最少但实现复杂。​

​

​

​

实际项目通常混合使用。我一般建议的方案，最近 3-5 轮完整保留，更早的对话做摘要压缩，关键信息，用户姓名、订单号、已确认需求，单独提取到 System Prompt 里。这块设计直接决定用户觉得你的 AI 聪明还是健忘，做不好用户留存会很难看。​

​

11​

PART​

💡 Streaming 流式输出​

你的 AI 产品上线了，用户发一个问题然后盯着空白页面等了 12 秒才看到回答。后台数据显示首日留存只有 15%，用户反馈最多的一条是太慢了。​

很多 PM 以为流式输出是锦上添花的体验优化。错，对生成类 AI 产品它是基本生存线。GPT-4 生成一段 500 字回答需要 10-15 秒，如果等全部生成完再一次性展示，用户只会看到一个转圈动画。超过 3 秒用户开始烦躁，超过 8 秒直接关页面。但如果每生成一个词就立刻推给用户，用户看到文字一个个蹦出来，感知等待时间从 15 秒降到不到 1 秒。​

技术上通过 SSE 协议实现，全称 Server-Sent Events。后端和模型之间建立一个持久连接，模型每预测出一个 Token 就实时推送到前端，不等全部生成完。​

PM 需要盯三个指标，直接写进需求文档。Step 一TTFT，首 Token 延迟，用户发请求到看见第一个字的时间，这是用户感知快慢的关键。Step 二TPS，每秒输出 Token 数，决定文字蹦出来的速度。Step 三断流重连，网络波动时连接断了怎么续上，这个不提前设计上线后必出问题。​

​

​

​

12​

PART​

💡 MCP 模型上下文协议​

❓你的 Agent 需要连日历、查数据库、读文件、发邮件，每接一个工具都要写一套对接代码。换个模型供应商，所有对接代码又得重写一遍。对接三个工具花了两周，还有十七个在排期。​

所有人都在说 Agent 时代来了，但工具对接的效率如果不解决，Agent 产品的迭代速度就上不去。MCP 就是来解决这个问题的。全称 Model Context Protocol，模型上下文协议。​

核心思路一句话，把模型怎么用工具这件事标准化。就像 USB 协议统一了外设接口，不管你插鼠标还是 U 盘，协议层面都是一样的。MCP 定义了统一的通信格式，模型发出工具调用请求，MCP Server 接收并执行，结果按标准格式返回。​

​

✍️

三个核心角色：​

MCP Host 是大模型所在的应用，​

MCP Client 负责协议通信的中间层，​

MCP Server 是具体工具的服务端封装。​

只要你的工具包装成 MCP Server，任何支持 MCP 的模型和应用都能直接调用，不用单独写对接代码。​

​

PM 需要重点关注工具注册和权限管理。你的产品能连哪些工具、用户有没有权限调用某个工具、调用失败怎么兜底，这些在产品层面必须设计清楚。不能全扔给开发，因为这些直接影响用户体验和安全性。​

​

​

​

13​

PART​

💡 Temperature 温度参数​

技术评审时算法同事说把 Temperature 调低一点试试，你点了个头但完全不知道调低意味着什么，也不知道它该对你的产品方案产生什么影响。​

所有人都以为 Temperature 设为 0 就不会出错。这是一个非常危险的误解。​

Temperature 本质上是对模型输出概率分布的缩放系数。模型预测下一个 Token 时，会算出每个候选词的概率。Temperature 设为 0 时，模型永远选概率最高的那个词，输出几乎完全一样，非常确定。设为 1 或更高时，低概率的词也有机会被选中，输出变得多样但同时不确定性变大。​

为什么说设 0 不代表不出错？因为 Temperature 控制的是概率采样的随机性，不是事实准确性。如果模型对一个错误答案的概率预测本身就是最高的，Temperature 设 0 反而会让它每次都选那个错误答案。Temperature 管的是稳不稳定，不管对不对。​

实际产品中的经验，客服场景设 0.1-0.3，你需要回答一致稳定；创意写作场景设 0.7-0.9，你需要多样性；数据提取和格式化场景设 0，你需要结果完全可预测。​

我一般建议 PM 在 PRD 里明确写 Temperature 取值和原因，不要让开发自己猜。不同场景的最优值差很多，猜错了效果差距很大。​

​

​

​

14​

PART​

💡 System Prompt 系统提示词​

❓你调了两周 Prompt 效果还是不稳定，有时候输出很好有时候完全跑偏。看了一堆 Prompt Engineering 教程，技巧学了一大堆效果还是忽好忽差。问题可能根本不在用户 Prompt 上，而在 System Prompt 的设计上。​

很多 PM 不区分 System Prompt 和用户 Prompt。System Prompt 是对话开始前预设给模型的人设说明书，用户看不到，但它决定了 AI 的行为模式和能力边界。每次 API 调用它都会被发送一遍。​

​

✍️

System Prompt 决定三件事：​

1️⃣角色一致性，多轮对话中 AI 人设不会跑偏；​

2️⃣行为边界，哪些问题拒答、哪些格式强制遵守；​

3️⃣输出质量，给模型足够的上下文约束减少发散。​

​

写 System Prompt 有个核心原则，我跟团队反复强调的，像写岗位 JD 一样写。​

职责明确，边界清晰，有具体的行为示例。​

不要写你是一个专业的客服这种废话，要写你是 XX 公司的在线客服，只回答产品使用和售后问题，遇到投诉类问题先安抚再提供工单链接，遇到不确定的问题说我帮您转接人工客服。​

还有一个成本细节 PM 必须知道，System Prompt 每次调用都要发送。2000 字的 System Prompt 大约消耗 3000-4000 Token，日均 10 万次调用，光 System Prompt 一个月就烧几千到上万块。所以 System Prompt 的长度是效果和成本的平衡点，不是越长越好。​

​

​

15​

PART​

💡 15. Few-shot Learning 少样本学习​

你让模型做情感分类，直接下指令效果只有 60%准确率。加了三个示例进去，准确率直接跳到 85%。不需要训练不需要微调，就加了三句话。​

很多 PM 不知道 Prompt 里放几个示例和不放示例的效果差距有多大。Zero-shot 是直接下指令零示例，Few-shot 是在 Prompt 里塞 2-5 个示例让模型照着学。​

运作机制，模型根据你给的示例，在推理时就地学习输入和输出之间的映射规则。不改模型参数，不需要训练数据，只是把示例塞进 Prompt 里。它为什么有效？因为大模型在预训练阶段已经学会了根据上下文模式进行推导这个能力，你给它示例就是在激活这个能力。​

关键实操经验，示例数量 2-5 个最优，太少模型抓不住规律，太多浪费 Token 且容易引入噪声。示例质量比数量重要十倍，放进去的示例必须是你最满意的标杆输出。​

PM 日常用得最多的三个场景。Step 一统一输出格式，给几个 JSON 示例模型就会照着输出。Step 二定义分类标准，给几个分类结果的示例模型就会按你的标准分。Step 三风格对齐，给几个风格范文模型就会学着写。​

决策路径，先试 Zero-shot，效果不够加 Few-shot，Few-shot 还不行再考虑微调。反过来走就是浪费钱。​

​

​

​