📚 AI产品经理课程 · 场景篇·第三篇

RAG / Function Calling / MCP

通过RAG、Function Calling和MCP链接知识库和外部系统，解决大模型如何连接外部知识库和业务系统的核心问题。

📅 2026年5月14日 ⏱ 约3小时 📖 10个核心概念

RAG Function Calling MCP 智能客服知识库 AI产品经理

1

课程概览

本课程聚焦AI核心技术与产品场景的深度融合，系统讲解了RAG（检索增强生成）、Function Calling（函数调用）、MCP（模型上下文协议） 三大核心技术，探讨如何将这些技术应用于智能客服、知识库问答、企业办公等真实场景。

🎯 学习目标

理解RAG、Function Calling、MCP的核心原理与适用场景
掌握智能客服系统的架构设计与实现思路
建立"AI+行业"的产品思维框架
学会判断何时使用RAG、Function Calling还是MCP

本课程是场景篇的第三篇，前序课程涵盖大模型基础、智能体概念、提示词工程和工作流搭建，本课承接上文，进一步解决大模型如何连接外部知识库和业务系统的核心问题。

2

核心名词解释

🔍

RAG（检索增强生成）

定义：Retrieval-Augmented Generation，即检索增强生成。是一种结合信息检索与大模型生成的AI技术架构，通过外挂知识库来增强大模型的回答质量。

核心原理：用户提问时，系统先从外部知识库（向量数据库）中检索与问题最相关的内容，再将检索结果作为上下文提供给大模型，由大模型基于真实知识生成答案。核心原理是"先检索、后生成"，本质是大模型外挂小模型。

💡 通俗比喻

就像一个人参加考试，大模型是"有学问但可能胡编乱造的学生"，RAG就是给他一本开卷考试参考资料，让他先翻书再回答。

与相关概念对比

对比项	RAG	纯大模型	知识图谱
知识来源	外挂知识库	预训练数据	结构化知识图谱
实时性	中等（非实时更新）	依赖训练数据	可实时更新
幻觉解决	部分解决	难以避免	较强

⚡

Function Calling（函数调用）

定义：OpenAI提出的协议标准，允许大模型调用外部API接口，执行具体业务操作或获取实时数据。

核心原理：当用户请求涉及具体业务操作（如查询订单、退换货）时，大模型识别用户意图，调用预定义的函数接口完成操作，返回结构化结果。核心作用是连接大模型与实时业务系统。

💡 通俗比喻

就像大模型从一个"只会聊天的人"变成了一个"能帮你做事的人"，它不只是回答问题，而是能真正执行任务。

与相关概念对比

对比项	Function Calling	RAG	MCP
主要功能	执行操作	检索知识	标准化接口
数据特点	实时业务数据	静态知识文档	多样化外部工具
典型场景	订单查询、订票	知识问答	天气查询、地图

🔌

MCP（模型上下文协议）

定义：Model Context Protocol，2024年10月底由Anthropic推出的开放标准协议，用于统一大模型与外部工具/数据源的交互接口。

核心原理：提供一套标准化的接口规范，让不同的大模型可以统一调用各种外部工具和数据源（如天气API、地图API、数据库等），避免重复开发接口适配器。核心价值是标准化与生态复用。

💡 通俗比喻

就像USB接口标准——无论什么品牌的电脑、什么型号的U盘，只要符合USB标准就能互联互通。MCP就是AI世界的"USB标准"。

与相关概念对比

对比项	MCP	Function Calling
提出者	Anthropic	OpenAI
标准化程度	行业开放标准	厂商私有协议
生态丰富度	生态丰富，可复用	需自行开发接口
适用场景	公开API调用	私有业务系统

🔢

Embedding（向量嵌入）

定义：将文本、图片等多模态内容转换为低维连续数值向量的技术，让计算机能理解语义并进行相似度计算。

核心原理：相同的语义内容会生成相似的向量（如"苹果是水果"和"苹果可以吃"向量接近），不同语义的向量则距离较远。向量是AI理解语义的核心方式，是RAG检索的基础。

💡 通俗比喻

把人类的语言"翻译"成数学语言，每个词、每句话都变成一串数字，语义相近的内容在这串数字上也"长得像"。

关键特点

支持语义级别的相似度比较
是向量数据库检索的核心技术
支持多模态内容（文本、图像、音频）

🗄️

向量数据库 vs SQL数据库

对比维度	向量数据库	SQL数据库
存储内容	非结构化数据的语义特征（向量）	结构化数据（表格、行列）
查询方式	相似度检索（余弦相似度）	精确匹配、条件查询
核心能力	语义理解、语义搜索	事务处理、精确查询
适用场景	知识库问答、语义检索	订单管理、用户信息、财务数据
典型产品	Milvus、Pinecone、Chroma	MySQL、PostgreSQL、MongoDB
数据更新	非实时，适合静态知识	实时更新，适合动态业务

核心区别：订单查询必须用SQL数据库（实时精确）；知识问答用向量数据库（语义匹配）。

💬

Prompt（提示词工程）

定义：Prompt是用户与大模型交互时输入的指令或问题；提示词工程是设计和优化Prompt的技术，让大模型更准确地理解需求并给出理想回答。

核心原理：大模型对Prompt的表述非常敏感，好的Prompt能让模型理解得更准确、回答得更专业。核心技能包括：角色设定、任务拆解、输出格式指定、上下文注入等。

关键技巧

✅ 好的Prompt示例：
"你是一位资深保险顾问，请为35岁、家庭年收入50万的客户，
设计一份包含重疾险和意外险的保险规划方案，输出Markdown格式。"

❌ 差的Prompt示例：
"帮我写个保险方案"

🤖

智能体（Agent）

定义：具有自主感知、思考、决策和执行能力的AI系统，能够完成复杂多步骤任务，而不只是单轮问答。

核心原理：智能体由大模型+规划+记忆+工具四部分组成，能将复杂任务分解为子步骤，按计划执行，并根据反馈调整策略。核心能力是自主行动和长期规划。

典型特征

自主规划：将大目标拆解为小步骤
长期记忆：跨对话记住关键信息
工具使用：调用外部API或RAG完成任务
自我反思：根据结果调整策略

👁️

大模型幻觉

定义：大语言模型生成的内容包含看似合理但实际错误或虚假的信息的现象。

核心原理：大模型的回答基于预训练数据统计规律生成，当遇到训练数据中不存在或模糊的问题时，会"自信地编造"看似合理但实际错误的答案。这是RAG技术产生的核心原因之一。

💡 通俗比喻

就像一个记忆力很好但不懂装懂的人，遇到不会的问题也能说得头头是道，但可能是瞎编的。

解决思路

RAG检索增强：让模型基于真实文档回答
Function Calling：调用实时API获取准确数据
提示词约束：要求模型不确定时回答"不知道"

📐

余弦相似度

定义：计算两个向量夹角余弦值的方法，用于判断两个内容的语义相似程度。

核心原理：余弦值范围是[-1, 1]，值越接近1表示两个向量方向越相似，即语义越相近。计算公式衡量的是向量的方向而非长度，对文本长度不敏感。

💡 通俗比喻

两个向量就像两个指向不同方向的箭头，余弦相似度就是看这两个箭头有多"指向同一个方向"。

应用场景

RAG检索时计算用户问题与文档片段的相似度
推荐系统中判断用户兴趣与内容的匹配度
文本分类、语义聚类的基础算法

🎯

SCOPE框架

定义：一个用于AI产品构建和实施的方法论框架。

核心原理：SCOPE代表以下五个步骤的闭环：

S - Setting Goal（设定目标）：明确产品要解决的核心问题
C - See Process（看到流程）：理解现有业务流程和各个环节
O - Operationalize（SOP化）：将流程标准化、操作步骤化
P - Prove（评测验证）：建立评估指标体系，验证效果
E - Enable（上线启用）：部署上线并持续优化

核心价值：「在你职场中做任何一件事情上，首先第一件事是要把目标设定清」。SCOPE框架帮助产品经理从"高维思考"到"落地执行"，避免技术思维主导而忽略商业目标。

3

核心技术对比

对比维度	RAG	Function Calling	MCP
核心作用	检索增强生成，解决幻觉问题	调用外部接口，执行具体操作	统一接口标准，生态复用
本质定位	大模型外挂知识库	大模型连接业务系统	接口标准化协议
适用场景	知识问答、文档检索、事实性任务	订单查询、退换货、实时业务	公开API调用（天气、地图等）
数据特点	静态文档知识	实时业务数据	多样化外部工具
实时性	中等（非实时更新）	强（实时操作）	依赖外部API
典型案例	企业知识库问答、运维智能体	电商订单查询、票务系统	12306车票查询、墨迹天气
局限性	不适合创意生成、非实时更新	需预先定义函数接口	生态尚在发展中
技术门槛	中等（需构建向量数据库）	中等（需定义接口规范）	较低（使用现成MCP服务）

✅ 选择建议

需要引用文档内容回答 → RAG
需要执行具体操作获取实时数据 → Function Calling
需要调用公开服务且追求复用 → MCP

4

案例分析

案例一：电商智能客服

场景描述

某电商平台构建AI客服系统，处理用户售前咨询（商品推荐）、售中咨询（订单查询）、售后处理（退换货）等全流程客服需求。

痛点分析

用户问题类型多样，70%为重复性问题，人工成本高
大模型存在幻觉，商品信息、价格、库存可能回答错误
客服历史数据未有效利用，无法提供个性化服务
中国智能客服60%仍需人工介入

技术方案

RAG层：接入商品知识库、FAQ文档库，用户咨询时先检索匹配
Function Calling层：订单查询、退换货、地址修改等实时操作通过Function Calling调用业务API
长期记忆：记录用户历史交互，提供个性化推荐

关键设计点

├── 售前咨询 → RAG（商品知识库） ├── 售中咨询 → Function Calling（实时订单API） ├── 售后客诉 → RAG + Function Calling（政策库+业务操作） └── 复杂问题 → Ask Human Help（转人工）

效果/价值

预计2027年智能客服市场规模达90亿
减少人工介入比例，提升客服效率
长期记忆让顾客感受「被看到、被关注到、被理解」

案例二：个人职场助理（带RAG知识库）

场景描述

为职场人士构建AI助理，能够回答公司制度、报销流程、会议安排等问题，并辅助撰写文档、生成报告。

痛点分析

公司制度文档分散在多个系统中，查询不便
不同城市的报销政策存在差异，容易出错
会议纪要整理耗时，需要自动化工具

技术方案

RAG知识库：接入公司制度文档、报销指南、会议纪要模板
Function Calling：调用日历API查询会议安排、邮件系统发送通知
文档生成：基于RAG检索结果，辅助撰写报告

关键设计点

非结构化数据切分是行业痛点，需要专业的文档解析和分块策略
知识库需要定期更新，但更新非实时
建立「职场金句库」：积累优质回复，提升回答质量

效果/价值

减少员工查找制度信息的时间
提升行政问题的回答一致性
释放行政人员精力，聚焦更高价值工作

案例三：企业行政问题小助手

场景描述

企业行政部构建AI小助手，处理员工日常咨询：请假流程、工位申请、物资领取、物业报修等。

痛点分析

行政问题重复性高，人工回答效率低
政策制度更新后，员工可能不了解最新规定
跨部门协作流程不透明，员工不清楚找谁处理

技术方案

RAG层：接入行政制度手册、流程文档、FAQ
Function Calling：对接OA系统，提交请假申请、工位申请
Ask Human Help：未识别意图或复杂问题时转人工

关键设计点

清晰的意图识别：判断是"问政策"还是"办业务"
政策时效性标注：明确告知政策的适用范围和更新时间
转人工机制：建立清晰的人工介入标准

效果/价值

行政咨询响应时间从小时级降至秒级
减少行政人员重复性工作
员工满意度提升

案例四：保险建议书高效生成

场景描述

保险公司为代理人构建AI工具，根据客户基本信息（年龄、家庭结构、收入）自动生成保险规划建议书。

痛点分析

保险建议书内容复杂，代理人撰写耗时
不同产品组合方案多，人工计算易出错
客户需求挖掘不充分，推荐方案不精准

技术方案

RAG层：接入保险产品条款、费率表、合规要求
Function Calling：调用客户信息API、产品数据API
文档生成：基于模板+个性化信息生成专业建议书

关键设计点

输入：客户年龄35岁、家庭年收入50万、有1个孩子 ↓ RAG检索：适合该家庭的险种类型、重疾险+意外险组合 ↓ Function Calling：获取最新产品费率、计算保费 ↓ 生成：结构化保险建议书（Markdown/PDF格式）

效果/价值

建议书生成时间从2小时缩短至10分钟
提升代理人展业效率
标准化输出确保合规性

案例五：政务智能问答（黑龙江案例）

场景描述

黑龙江省政务服务平台构建AI问答系统，处理市民政策咨询、办事指南查询等需求。

痛点分析

政务政策文件多且复杂，市民难以理解
不同部门政策分散，跨部门问题回答困难
政策更新频繁，坐席人员培训成本高

技术方案

RAG层：接入各厅局政策文件、办事指南、常见问答
Function Calling：对接政务服务系统，查询办事进度
多部门协同：建立跨部门知识共享机制

关键设计点

政策时效性管理：标注政策有效期，及时更新
来源可追溯：明确告知政策出处，增强可信度
容错机制：不确定时回复「建议咨询相关部门」

效果/价值

7×24小时智能问答，减少排队等待
提升政务服务可及性
释放人工坐席精力，处理复杂问题

案例六：心理类产品（Rothbard案例）

场景描述

心理类应用（如Rothbard）利用AI提供心理健康支持，提供情绪疏导、心理问答、危机干预等功能。

痛点分析

心理咨询师资源稀缺，预约等待时间长
用户存在「病耻感」，不愿面对面咨询
心理健康问题存在地域差异，优质资源分布不均

技术方案

RAG层：接入心理学知识库、情绪疏导话术库
长期记忆：记录用户情绪变化，提供持续关怀
危机识别：识别高风险内容，及时介入或转介

关键设计点

共情式对话：AI回复需要体现理解和关怀
隐私保护：严格保护用户倾诉内容
边界意识：AI不能替代专业诊疗，明确服务边界

效果/价值

广义客服概念：心理医生也是广义客服
7×24小时AI客服可缓解患者问题
缓解心理咨询师资源不足的困境
提供低门槛、隐私保护的心理健康支持

5

商业洞察与提升

智能客服市场价值

数据指标	数值
智能客服市场规模（2027年预测）	90亿元
中国智能客服人工介入比例	60%
行业痛点	效率低、成本高、体验差

商业机会：当前60%仍需人工介入，意味着自动化改造空间巨大。AI客服不只是降本工具，更是提升服务体验、增强用户粘性的战略投资。

大模型为客服行业带来的变革

降本增效之外的价值：

变革维度	具体表现
个性化服务	长期记忆让顾客「被看到、被关注到、被理解」
全天候服务	7×24小时在线，秒级响应
知识复用	优质客服经验可批量复制
主动服务	基于用户行为预测需求，主动服务
数据洞察	分析用户问题，驱动产品改进

广义客服场景的商业机会

领域	应用场景	价值
职场助理	行政问题、流程咨询、文档撰写	提升办公效率
医疗辅助	症状自查、就医指导、健康管理	缓解医疗资源紧张
心理支持	情绪疏导、危机干预、心理陪伴	填补心理咨询缺口
法律咨询	法规解读、案例参考、文书生成	降低法律服务门槛
教育辅导	作业解答、学习规划、知识讲解	个性化教育资源

政务领域的大模型商机

场景	具体应用	关键要求
智能问答	政策咨询、办事指南	来源可追溯、时效性管理
文档处理	公文撰写、报告生成	格式规范、内容准确
流程自动化	审批辅助、材料预审	合规性、透明度
数据分析	民情分析、舆情监控	实时性、准确性

关键成功因素

政策时效性管理（及时更新）
多部门数据协同
明确的容错和转人工机制

心理类产品的AI机会

🌟 AI在心理健康领域的独特优势

✅ 消除「病耻感」：匿名、无压力的倾诉环境
✅ 可及性：打破地域限制，24小时在线
✅ 隐私保护：严格数据保护，增加用户信任
✅ 初步干预：早期识别危机，及时转介专业资源
✅ 持续陪伴：长期记忆用户情绪，提供持续关怀

产品设计要点：

共情式对话能力
清晰的服务边界（AI不能替代专业诊疗）
完善的危机识别和转介机制

6

系统架构设计

智能客服系统架构（四层架构）

┌──────────────────────────────────────────────────────────────────┐ │ 【应用层】 │ │ 电商客服 | 企业行政助手 | 政务问答 | 职场助理 | 心理陪伴 │ └──────────────────────────────────────────────────────────────────┘ ↑ ┌──────────────────────────────────────────────────────────────────┐ │ 【服务层】 │ │ 意图识别 | 对话管理 | Ask Human Help | 响应生成 | 长期记忆 │ └──────────────────────────────────────────────────────────────────┘ ↑ ┌──────────────────────────────────────────────────────────────────┐ │ 【能力层】 │ │ RAG能力 │ Function Calling / MCP │ │ ┌─────────────────┐ │ ┌──────────────────────────────┐ │ │ │ 向量数据库 │ │ │ 业务API | 天气API | 地图API │ │ │ │ (知识库检索) │ │ │ 订单系统 | OA系统 | 日历API │ │ │ └─────────────────┘ │ └──────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘ ↑ ┌──────────────────────────────────────────────────────────────────┐ │ 【资源层】 │ │ 企业文档 | 产品知识库 | 业务数据库 | 公开API | 用户画像数据 │ └──────────────────────────────────────────────────────────────────┘

RAG工作流程（5个步骤）

步骤1：文档处理（离线） ┌────────────┐ ┌────────────┐ ┌────────────┐ │ 原始文档 │ → │ 文档解析 │ → │ 文本分块 │ │ (PDF等) │ │ (结构化) │ │ (Chunk) │ └────────────┘ └────────────┘ └────────────┘ ↓ 步骤2：向量编码（离线） ┌────────────┐ ┌────────────┐ │ Embedding │ → │ 向量数据库 │ │ 模型 │ │ (索引存储) │ └────────────┘ └────────────┘ 步骤3：用户查询 ┌────────────┐ │ 用户问题 │ │ "如何申请..│ └────────────┘ ↓ 步骤4：检索匹配（在线） ┌────────────┐ ┌────────────┐ │ 问题向量化 │ → │ 余弦相似度 │ │ (Embedding)│ │ 检索TopK │ └────────────┘ └────────────┘ ↓ 步骤5：生成回答 ┌────────────┐ ┌────────────┐ │ 上下文注入 │ → │ 大模型 │ │ (相关文档) │ │ 生成答案 │ └────────────┘ └────────────┘

RAG的两个核心作用

离线索引构建：文档解析→分块→向量化→存储
在线查询检索：问题向量化→相似度匹配→上下文注入→生成回答

Ask Human Help机制

┌────────────────────────────────────────────────────────────┐ │ Ask Human Help 机制 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 【触发条件】 │ │ ├── RAG检索置信度低于阈值 │ │ ├── 用户明确要求转人工 │ │ ├── 识别为高风险内容（心理危机、投诉升级） │ │ └── 系统无法识别的复杂问题 │ │ │ │ 【处理流程】 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ AI礼貌转接 │ → │ 记录上下文 │ → │ 人工接管 │ │ │ │ 告知用户 │ │ 传给坐席 │ │ 继续服务 │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ 【闭环优化】 │ │ └── 人工处理结果存入RAG知识库，持续学习 │ │ │ └────────────────────────────────────────────────────────────┘

意图识别分流逻辑

┌─────────────────┐ │ 用户Query │ └────────┬────────┘ ↓ ┌─────────────────┐ │ 意图识别 │ │ (LLM/NLP分类) │ └────────┬────────┘ │ ┌───────────────────┼───────────────────┐ ↓ ↓ ↓ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 知识问答 │ │ 业务操作 │ │ 闲聊/其他 │ │ (RAG) │ │(Func Call)│ │ (LLM) │ └────┬─────┘ └────┬─────┘ └──────────┘ ↓ ↓ ┌──────────┐ ┌──────────┐ │检索文档 │ │调用API │ │生成答案 │ │执行操作 │ └────┬─────┘ └────┬─────┘ │ │ └────────┬─────────┘ ↓ ┌─────────────────┐ │ 置信度判断 │ └────────┬────────┘ │ ┌──────────┴──────────┐ ↓ ↓ ┌──────────┐ ┌──────────┐ │ 高置信度 │ │ 低置信度 │ │ 直接回复 │ │Ask Human │ │ 给用户 │ │ Help │ └──────────┘ └──────────┘

7

实际应用场景指南

判断标准：金标准

是否使用RAG？回答以下三个问题：

问题	答案	结论
答案是否基于文档记录？	是	✅ 倾向RAG
知识是否常变且分散？	是	✅ 倾向RAG
是否需要引用可追溯？	是	✅ 倾向RAG

三个问题中有两个以上回答"是"，优先考虑RAG。

场景选择决策树

┌─────────────────────────────────────────────────────────────┐ │ 场景选择决策树 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 【Step 1】回答内容来自？ │ │ │ │ ├── 文档/知识库 → 【Step 2】 │ │ │ 问题是否需要实时数据？ │ │ │ ├── 是 → RAG + Function Calling组合 │ │ │ └── 否 → RAG │ │ │ │ │ ├── 业务系统 → Function Calling │ │ │ (订单、库存、用户信息) │ │ │ │ │ └── 公开服务 → MCP │ │ (天气、地图、新闻) │ │ │ └─────────────────────────────────────────────────────────────┘

场景对照表

场景	推荐技术	原因
公司制度问答	RAG	文档内容为主，无需实时
商品知识咨询	RAG	商品信息相对稳定
订单查询	Function Calling	必须实时准确
库存查询	Function Calling	实时数据要求高
退换货处理	Function Calling	涉及业务操作
天气查询	MCP	公开API，标准化调用
地图导航	MCP	公开API，生态成熟
12306火车票	MCP	公开API，标准化
保险产品咨询	RAG + Function Calling	条款用RAG，费率实时查
法律咨询辅助	RAG	法律条文+案例参考
运维问题排查	RAG	历史故障库检索
医疗辅助诊断	RAG + Function Calling	症状库+实时检查

RAG不适合的场景

不适合场景	原因	替代方案
创意性任务	RAG检索的是已有内容，不适合创新	纯大模型生成
小说/文案创作	需要创造性表达	纯大模型
项目代码库	代码有严格逻辑结构	专用代码搜索引擎
实时交易	订单必须精确，RAG非实时	Function Calling

8

思考与反思

核心思维框架

「做一个特别完整的产品，其实要考虑的不只是做出来，也要去考虑为什么做。」

产品完整度思考模型：

为什么做？ ↓ 用户真正需要什么？ ↓ 技术能解决什么问题？ ↓ 产品如何设计？ ↓ 如何验证效果？ ↓ 如何持续优化？

反思要点：

❌ 只关注"能不能做出来"
✅ 同时关注"为什么要做"、"给谁做"、"怎么验证价值"

大模型使用的两条铁律

铁律	说明
铁律一：明确边界	大模型不是万能的，明确它能做什么、不能做什么
铁律二：控制幻觉	幻觉是固有特性，必须通过RAG/Function Calling等机制约束

实践中的应用：

RAG的本质是解决幻觉 → 知识问答用RAG
Function Calling的本质是执行操作 → 业务操作用Function Calling
MCP的本质是标准化连接 → 公开服务用MCP

RAG整理的行业痛点与机会

痛点	机会
非结构化数据切分困难	专业文档解析服务/工具的机会
知识库更新非实时	增量更新机制、版本管理工具
检索精度不稳定	评测体系、效果优化服务
跨领域知识整合	行业知识图谱构建服务
企业知识资产盘点	知识管理咨询、培训服务

产品经理在AI时代需要转变的思维方式

传统思维	AI时代思维
功能堆砌	场景驱动，价值导向
规则引擎	AI能力+人工兜底
人工优先	AI优先，人工兜底
一次性开发	持续学习、迭代优化
确定性输出	概率性输出，需要容错
关注功能实现	关注效果评测

核心转变：从「功能导向」到「价值导向」，从「确定性」到「容错性」

从"高维思考"到"落地执行"的路径

┌────────────────────────────────────────────────────────────┐ │ 从高维思考到落地执行 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 【高维】Setting Goal → 为什么做？价值是什么？ │ │ ↓ │ │ 【流程】See Process → 现有流程是什么？有哪些环节？ │ │ ↓ │ │ 【执行】Operationalize → 如何SOP化？操作步骤是什么？ │ │ ↓ │ │ 【验证】Prove → 如何评测效果？指标是什么？ │ │ ↓ │ │ 【启用】Enable → 如何上线？如何推广？ │ │ │ └────────────────────────────────────────────────────────────┘

构建AI产品的标准步骤：

需求挖掘 → 价值评估 → 智能构建 → 产品架构 → 产品实施 → 商业策略 → 测试调优

9

金句集锦

「在你职场中做任何一件事情上，首先第一件事是要把目标设定清。」

解读：SCOPE框架的第一步是"设定目标"，很多产品失败的根本原因是目标不清晰。做AI产品前，先问自己：这个产品要解决什么问题？给谁用？怎么衡量成功？

「做一个特别完整的产品，其实要考虑的不只是做出来，也要去考虑为什么做。」

解读：产品思维的本质是"价值思维"，而不是"技术思维"。先理解用户需求和商业价值，再思考技术实现路径。技术是手段，不是目的。

「长期记忆能让顾客有『被看到、被关注到、被理解』的感受。」

解读：AI客服不只是回答问题，更重要的是让用户感受到被重视。长期记忆记录用户历史交互，提供个性化服务，这是AI客服超越传统客服的关键价值。

「RAG本质是大模型外挂小模型。」

解读：这句话精准概括了RAG的技术本质——大模型负责"思考和生成"，小模型（知识库+检索）负责"提供真实知识"，两者配合解决幻觉问题。

「判断是否用RAG的金标准：答案基于文档记录、知识常变且分散、需引用追溯。」

解读：这三个条件是判断是否使用RAG的核心标准。如果你的场景满足其中两个以上，RAG是首选技术方案。

10

课后行动清单

课程布置的作业

作业内容	要求
案例选择	从电商客服、企业行政、保险建议书、政务问答、心理类产品中选择一个
方案设计	设计该场景下的AI产品方案，包含： ① 核心痛点分析 ② 技术方案选择（RAG/Function Calling/MCP） ③ 系统架构设计（简要） ④ 预期价值
提交形式	Markdown文档，不少于1000字

下节课预告内容

内容	说明
主题	AI Agent（智能体）深度讲解
内容预告	智能体的规划、记忆、工具使用核心能力；多智能体协作；ReAct框架
预习建议	复习本节课的RAG、Function Calling、MCP技术，它们是智能体调用外部能力的基础

建议的延伸学习方向

方向	学习资源/路径
向量数据库深入	Milvus官方文档、Pinecone入门教程
Prompt工程	OpenAI官方Prompt Engineering指南
智能体(Agent)	LangChain文档、AutoGPT原理分析
知识图谱	Neo4j图数据库、知识图谱构建方法
行业报告	艾瑞咨询《中国智能客服行业报告》
开源项目	LlamaIndex（专注RAG的开源框架）

📚

附录：关键概念速查

缩写	全称	中文	核心功能
RAG	Retrieval-Augmented Generation	检索增强生成	解决大模型幻觉
FC	Function Calling	函数调用	执行具体业务操作
MCP	Model Context Protocol	模型上下文协议	统一外部调用标准
Embedding	-	向量嵌入	语义向量化
Agent	-	智能体	自主规划与执行
SCOPE	-	-	产品构建方法论

🎤

核心考点自测

以下为课程核心知识点的自测题，点击展开查看要点回顾。

Q1 RAG、Function Calling、MCP三者的核心区别是什么？如何选择？ ▼

核心区别：

RAG：检索增强生成，核心是解决幻觉问题，基于外挂知识库生成答案。适合知识问答、文档检索。
Function Calling：函数调用，核心是执行操作，调用外部API获取实时数据或执行业务动作。适合订单查询、退换货等实时操作。
MCP：模型上下文协议，核心是标准化接口，由Anthropic推出的开放标准，实现生态复用。适合公开API调用（天气、地图等）。

选择标准：

需要引用文档内容回答 → RAG
需要执行具体操作获取实时数据 → Function Calling
需要调用公开服务且追求复用 → MCP

Q2 什么是RAG？它的工作原理和核心价值是什么？ ▼

定义：Retrieval-Augmented Generation（检索增强生成），是一种结合信息检索与大模型生成的AI技术架构。

工作原理：用户提问时，先从外部知识库（向量数据库）中检索相关内容，再将检索结果作为上下文提供给大模型，由大模型基于真实知识生成答案。核心是"先检索、后生成"。

核心价值：

解决大模型幻觉问题，让回答有据可依
知识可随时增删改，时效性强
成本远低于模型微调
来源可追溯，增强可信度

金标准判断：答案是否基于文档记录？知识是否常变且分散？是否需要引用可追溯？三个问题中两个以上回答"是"，优先用RAG。

Q3 向量数据库和SQL数据库有什么区别？各适用于什么场景？ ▼

维度	向量数据库	SQL数据库
存储内容	非结构化数据的语义特征（向量）	结构化数据（表格、行列）
查询方式	相似度检索（余弦相似度）	精确匹配、条件查询
核心能力	语义理解、语义搜索	事务处理、精确查询
适用场景	知识库问答、语义检索	订单管理、用户信息、财务数据
数据更新	非实时，适合静态知识	实时更新，适合动态业务

简单判断：订单查询必须用SQL（实时精确）；知识问答用向量数据库（语义匹配）。

Q4 智能客服系统的四层架构是什么？各层的作用是什么？ ▼

四层架构模型：

应用层：电商客服、企业行政助手、政务问答、职场助理、心理陪伴等具体场景应用
服务层：意图识别、对话管理、Ask Human Help、响应生成、长期记忆
能力层：RAG能力（向量数据库/知识库检索）+ Function Calling/MCP（业务API、天气API、地图API等）
资源层：企业文档、产品知识库、业务数据库、公开API、用户画像数据

意图识别分流逻辑：知识问答走RAG，业务操作走Function Calling，低置信度转Ask Human Help。

Q5 什么是SCOPE框架？它对AI产品经理有什么指导意义？ ▼

SCOPE框架是一个AI产品构建和实施的方法论框架，包含五个步骤：

S - Setting Goal（设定目标）：明确产品要解决的核心问题
C - See Process（看到流程）：理解现有业务流程和各个环节
O - Operationalize（SOP化）：将流程标准化、操作步骤化
P - Prove（评测验证）：建立评估指标体系，验证效果
E - Enable（上线启用）：部署上线并持续优化

指导意义：帮助产品经理从"高维思考"到"落地执行"，避免技术思维主导而忽略商业目标。核心是先把目标设定清楚。

🔗

参考资源与延伸阅读

📚

官方文档与开源项目

资源	类型	链接
Milvus 向量数据库	开源向量数据库	milvus.io
Pinecone	向量数据库服务	pinecone.io
LlamaIndex	RAG 开源框架	llamaindex.ai
LangChain	Agent 开发框架	langchain.com
OpenAI Prompt Engineering Guide	提示词工程指南	platform.openai.com
Model Context Protocol (MCP)	Anthropic 官方标准	modelcontextprotocol.io

AI产品经理课程一站式学习空间站

课程标题

添加新课程

AI产品经理课程
一站式学习空间站