AI基础小测

3.1 真正要建立的能力#

表面上讲了很多技术词，但产品经理真正要掌握的是判断能力。AI 项目失败通常不是因为团队不知道模型名字，而是因为一开始就把问题定义错了。

常见错误包括：

• 把规则问题交给大模型判断。

• 把知识库问答做成没有引用的聊天框。

• 把长文档全部塞进上下文，导致成本和质量同时失控。

• 把模型输出当成事实，不设计拒答和人工兜底。

• 把用户截图、语音、表格里的关键信息忽略，只让用户手动输入文字。

• 只看 Demo 效果，不设计上线后的评估集、日志和灰度策略。

所以目标不是“懂 AI”，而是形成一套初筛公式：

1
一个 AI 需求是否值得做 =
2
  用户任务是否高频
3
× 当前人工成本是否明显
4
× 数据和知识是否可得
5
× 错误是否可控
6
× 成本是否可承受
7
× 指标是否可衡量
8
× 组织是否能持续维护

这套公式比单纯问“模型能不能做”更重要。模型能做 Demo，不代表产品能上线；产品能上线，不代表业务能持续获得收益。

3.2 AI 知识地图的复盘#

最重要的结论是：AI 不是一个单点技术。产品经理要区分规则系统、传统机器学习、大模型、RAG 和 Agent。

一个典型业务需求往往不是只用一种技术。例如智能客服：

1
用户自然语言输入 -> LLM 理解意图
2
订单状态查询 -> 业务系统
3
退款资格判断 -> 规则系统
4
政策解释 -> RAG + LLM
5
高风险投诉 -> 人工客服
6
会话质检 -> ML/LLM

如果产品方案写成“用户问问题，AI 自动回答”，就是把复杂业务压扁成了聊天框。真正的产品设计应该拆清楚：

• 哪一步是理解。

• 哪一步是检索。

• 哪一步是确定性判断。

• 哪一步是生成。

• 哪一步必须人工确认。

• 哪一步需要记录反馈。

产品经理要避免“AI 化冲动”。不是所有功能都因为加入 AI 变得更好。库存扣减、优惠券核销、价格计算、审批通过这类确定性环节，优先应该由规则系统或业务系统处理。

3.3 Token 与成本意识的复盘#

关键不是记住 Token 定义，而是理解 AI 产品存在单位经济模型。

很多 AI 功能 Demo 只有几十次调用，成本不明显；一旦进入生产环境，调用量、上下文、输出长度、多轮对话、重试、日志、人工审核都会形成持续成本。

产品经理要会拆成本：

1
单次功能成本 =
2
  输入 Token 成本
3
+ 输出 Token 成本
4
+ 检索/Embedding/重排成本
5
+ 存储与日志成本
6
+ 人工审核成本
7
+ 错误带来的业务损失

例如商品文案生成，模型单次调用可能很便宜，但如果每个商品生成 5 个版本、重试 2 次、还要人工审核和平台驳回处理，总成本会明显上升。

Token 意识还会影响体验：

• 上下文越长，响应通常越慢。

• 输出越长，用户等待越久。

• 历史对话不裁剪，多轮成本会持续上升。

• RAG 片段太多，模型不一定更准，反而可能被干扰。

所以成本优化不是简单压缩 Prompt，而是任务路由、缓存、上下文裁剪、结构化输入、结果复用、小模型和强模型分层。

3.4 Transformer 直觉的复盘#

讲 Transformer，不是为了让产品经理写模型代码，而是建立模型能力边界的直觉。

Transformer 的关键优势是自注意力：它能在上下文中计算 Token 之间的关系。这解释了为什么大模型擅长：

• 总结长文本。

• 理解复杂问法。

• 抽取关键信息。

• 改写和生成。

• 多语言转换。

• 跨模态理解。

但这也带来一个重要限制：模型是在上下文中生成最可能的内容，不是天然验证事实。

因此产品设计上要形成分工：

1
模型负责理解和表达
2
检索负责提供事实
3
规则负责确定判断
4
权限负责控制边界
5
人工负责高风险确认
6
日志负责复盘和改进

只要这个分工不清，AI 功能就容易从“智能辅助”滑向“不可控承诺”。

3.5 幻觉的复盘#

核心结论是：幻觉不是一个可通过“请准确回答”彻底解决的小问题，而是 AI 产品可靠性问题。

幻觉常见来源包括：

• 模型按概率生成，不天然查证事实。

• 训练数据过时或错误。

• 上下文缺少关键资料。

• 检索找错资料。

• Prompt 指令冲突。

• 用户诱导模型编造。

• 模型引用了资料，但结论超出资料。

产品经理要把幻觉风险分级：

衡量幻觉不能只靠“用户觉得好不好”。必须建立测试集，监控准确率、引用准确率、引用支持率、无依据回答率、拒答正确率和高风险拦截率。

3.6 Embedding 与语义检索的复盘#

关键是理解 RAG 的前半段：系统如何找到资料。

用户的自然语言问法通常和文档写法不一致。例如用户问“酒店超标能报吗”，制度写的是“住宿费用超过城市标准需事前提交例外审批”。关键词检索可能搜不到，但语义检索能通过 Embedding 找到意思相近的片段。

Embedding 的产品价值包括：

• 企业制度问答。

• 客服知识库。

• 商品搜索和推荐召回。

• 合同问答。

• 用户反馈归类。

• 研发文档助手。

但要明确：语义相似不等于答案正确。RAG 仍然需要：

• 文档清洗。

• 合理分块。

• 版本管理。

• 权限过滤。

• 召回和重排。

• 引用展示。

• 拒答机制。

• 评估集。

一个知识库问答项目，不应从“接大模型”开始，而应从“真实用户问题 + 标准资料片段”的样本集开始。

3.7 多模态 AI 的复盘#

把 AI 输入从文本扩展到图片、语音、视频、表格和屏幕。

多模态的核心价值是：业务现场的信息往往不在文字里。商品图、票据、用户截图、会议录音、PPT、白板、录屏都可能是关键输入。

典型场景包括：

• 商品图识别生成卖点。

• 发票识别生成报销单草稿。

• 客服读取用户截图和语音。

• 会议录音 + PPT 生成纪要和待办。

• 用户录屏生成 Bug 报告。

• 门店巡检图片识别缺货和陈列问题。

多模态产品要特别注意两点：

第一，识别不是最终目标。识别结果必须进入业务流程，例如生成工单、填表、审核、推荐、提醒或任务分配。

第二，多模态输入增加风险。图片可能模糊，语音可能转写错，视频成本高，截图可能包含隐私，模型可能把视觉判断当成事实承诺。

所以多模态流程同样需要质量检测、结构化输出、规则校验、人工确认和日志复盘。

3.8 串成一个 AI 功能评审框架#

看到一个 AI 需求，先问：

1. 用户任务是什么？ 用户不是为了聊天，而是为了完成什么事？

2. 技术路径是什么？ 规则、ML、LLM、RAG、Agent、人工分别负责哪一步？

3. 数据来源是什么？ 知识、样本、业务系统、图片、语音、表格是否可得？

4. 成本结构是什么？ 输入、输出、检索、多轮、重试、审核成本如何估算？

5. 事实边界是什么？ 哪些回答必须引用，哪些必须拒答？

6. 错误后果是什么？ 错了是文案不好，还是形成赔付、合规、财务风险？

7. 权限怎么控制？ 用户能看哪些资料，模型能调用哪些工具？

8. 如何评估？ 准确率、召回率、引用支持率、成本、满意度、业务指标是什么？

9. 如何上线？ 灰度范围、人工接管、回滚条件是什么？

10. 如何持续迭代？ 日志、反馈、评估集、知识更新由谁负责？

如果这 10 个问题答不清楚，项目不应该直接进入研发。

3.9 浅层聊天机器人 vs 真正 AI 工作流#

很多企业第一版 AI 项目失败，是因为只做了浅层聊天入口。

浅层聊天机器人：

1
用户输入
2
-> 模型回答

真正 AI 工作流：

1
用户输入
2
-> 意图识别
3
-> 权限校验
4
-> 检索知识或查询系统
5
-> 规则判断
6
-> 模型生成
7
-> 引用和置信度
8
-> 风险分级
9
-> 用户确认或人工接管
10
-> 日志记录
11
-> 反馈进入评估集

两者差别不在界面，而在责任链路。聊天机器人只负责“说话”，AI 工作流负责“把任务做对”。

业务背景#

一个电商平台希望降低人工客服压力，最初想做一个 AI 客服入口，用户输入问题，模型自动回答。

高频问题包括：

• 物流延迟。

• 退款退货。

• 优惠券退回。

• 发票修改。

• 价保申请。

• 投诉和赔付。

浅层方案#

1
用户问题
2
-> 大模型生成回复

这个方案 Demo 很快，但上线风险很高：

• 不知道用户订单状态。

• 不知道商品类目和售后政策。

• 不知道活动规则和优惠券状态。

• 不知道用户是否高风险投诉。

• 不知道哪些问题必须转人工。

结果可能是 AI 用流畅语言给出错误承诺。

AI 工作流方案#

1
用户消息
2
-> 意图识别：物流/退款/发票/价保/投诉
3
-> 身份与订单校验
4
-> 查询订单、物流、支付、优惠券
5
-> 检索售后政策
6
-> 规则系统判断是否符合条件
7
-> 模型生成解释
8
-> 高风险问题转人工
9
-> 用户反馈和质检

数据与系统依赖#

• 订单系统。

• 物流系统。

• 售后政策知识库。

• 优惠券系统。

• 工单系统。

• 客服质检系统。

• 用户画像和风险标签。

关键指标#

• 自助解决率。

• 人工接管率。

• 错误承诺率。

• 高风险识别率。

• 平均响应时间。

• 用户满意度。

• 单会话成本。

• 投诉升级率。

复盘结论#

这个案例说明：大模型适合理解和表达，不适合独自承担售后决策。产品价值来自“模型 + 业务系统 + 规则 + 人工”的组合，而不是一个聊天框。

业务背景#

一家企业希望做内部制度助手，让员工问报销、请假、采购、合同审批等问题。

用户问：

1
我去上海出差，酒店超标了，但部门负责人同意了，能报销吗？

Demo 方案#

1
上传制度文档
2
-> 接入大模型
3
-> 用户提问
4
-> AI 回答

Demo 看起来有效，但上线后会遇到问题：

• 制度新旧版本冲突。

• 表格和附件没有正确解析。

• 员工权限不同。

• 用户问题需要审批记录。

• AI 把制度解释说成报销承诺。

• 引用内容不支持结论。

可上线方案#

1
制度治理
2
-> 文档清洗和版本管理
3
-> 按章节条款分块
4
-> 添加权限、部门、生效日期
5
-> Embedding 入库
6
-> 用户提问
7
-> 权限过滤
8
-> 语义召回和重排
9
-> 模型基于引用回答
10
-> 资料不足时追问或拒答
11
-> 高风险问题转财务/HR
12
-> 反馈进入评估集

数据与系统依赖#

• 制度文档源。

• 组织架构和权限。

• 审批系统。

• 财务/HR 工单。

• 历史咨询问题。

• 标准答案样本集。

关键指标#

• Top K 召回率。

• 引用准确率。

• 引用支持率。

• 无依据回答率。

• 自助解决率。

• 人工咨询量下降。

• 转人工准确率。

• 旧版本误召回率。

复盘结论#

企业知识库问答不是纯模型项目，而是知识治理项目。产品经理必须把资料版本、权限、分块、召回、引用、拒答和人工兜底写进方案，否则 Demo 越流畅，上线风险越隐蔽。

任务：完成学习复盘#

请用 60-90 分钟完成下面 3 个产出。

产出 1：AI 基础能力自测表#

产出 2：浅层聊天机器人 vs AI 工作流对比#

选择一个业务场景，画出两版流程：

1
浅层聊天机器人：
2
用户输入 -> AI 回复
3

4
真正 AI 工作流：
5
用户输入 -> 意图识别 -> 权限/数据/检索/规则 -> 生成 -> 校验 -> 兜底 -> 反馈

产出 3：本周最模糊的 3 个概念#

按下面模板写：

验收标准#

合格：

1. 自测表至少填写 6 个能力项。

2. 至少完成一个业务场景的两版流程对比。

3. 写出 3 个最模糊概念。

4. 每个模糊概念都要对应一个补强动作。

优秀：

1. 能把一个 AI 需求拆成模型、数据、规则、人工、指标五层。

2. 能识别出至少一个“不该用 AI 直接判断”的环节。

3. 能把复盘结果转成团队内训或需求评审清单。

理解题#

1. 为什么 AI 不是一个单点技术？ 参考答案：AI 包括规则系统、传统机器学习、大模型、RAG、Agent、多模态等不同能力。真实业务通常需要组合使用，不能把所有问题都交给大模型。

2. Token 对产品经理为什么重要？ 参考答案：Token 决定调用成本、响应延迟、上下文设计和商业模型。上线后调用量、多轮对话、长输入、长输出都会影响单位经济模型。

3. Transformer 为什么适合语言理解和生成？ 参考答案：Transformer 通过自注意力机制在上下文中计算 Token 关系，能捕捉长距离依赖并并行训练，因此适合大规模语言建模和多模态扩展。

4. 大模型幻觉为什么不能只靠 Prompt 解决？ 参考答案：Prompt 只能约束模型行为，不能提供事实、权限、规则和业务状态。幻觉控制需要检索、引用、拒答、规则校验、人工兜底和评估集。

5. Embedding 解决了什么问题？ 参考答案：Embedding 把文本、图片等对象转成向量表示，让系统能按语义相似度检索内容，解决用户问法和资料写法不一致的问题。

6. 语义检索为什么不等于答案正确？ 参考答案：语义相似只说明资料可能相关，不保证资料适用、版本正确、权限允许，也不保证模型生成的结论忠实于资料。

7. 多模态 AI 的产品价值是什么？ 参考答案：多模态 AI 能直接处理图片、语音、视频、表格和屏幕，让 AI 理解业务现场信息，并把识别结果进入业务流程。

8. 为什么浅层聊天机器人通常不够？ 参考答案：用户不是为了聊天，而是为了完成任务。真实任务需要意图识别、系统查询、规则判断、检索、生成、校验、人工兜底和反馈。

9. 一个 AI 功能上线前至少要有哪些评估指标？ 参考答案：根据场景至少包括准确率、引用准确率、引用支持率、拒答正确率、人工接管率、成本、响应时间、用户满意度和业务指标。

10. 哪些场景不应该让大模型做最终决策？ 参考答案：库存扣减、优惠券核销、退款审批、赔付承诺、金融风控、医疗建议、法律判断、财务报销通过等高风险或确定性决策。

应用题#

11. 设计一个“AI 报销制度助手”的最小可用方案。 参考答案：接入当前有效制度，按条款分块并添加版本和权限；员工提问后先做权限校验，再语义召回和重排；模型基于引用回答；资料不足时追问或拒答；涉及是否最终可报销的问题转财务或审批系统判断；监控引用支持率、无依据回答率和人工咨询量下降。

12. 一个商品图生成文案功能如何避免描述不符？ 参考答案：先做图片质量检测和视觉识别，输出结构化属性并标注置信度；高风险字段如材质、功效、品牌必须人工确认；生成文案后做平台规则和禁词校验；上线后监控人工修改率、平台驳回率和退货原因。

13. 如果老板说“做一个 AI 助手帮客服自动处理所有问题”，你如何回应？ 参考答案：先拆分客服问题类型：低风险 FAQ 可自动回答，订单状态需查询系统，退款赔付需规则系统和人工确认，投诉需高风险识别和接管。建议先做高频低风险场景灰度，用自助解决率、错误承诺率、接管率、满意度和成本评估，而不是一次性自动处理所有问题。

8.1 学习复盘表#

8.2 AI 功能评审清单#

1
业务目标：
2
目标用户：
3
用户任务：
4
当前流程：
5
AI 介入环节：
6
技术路径：规则 / ML / LLM / RAG / Agent / 多模态
7
输入数据：
8
输出结果：
9
事实来源：
10
权限边界：
11
成本估算：
12
错误风险：
13
人工兜底：
14
核心指标：
15
灰度范围：
16
回滚条件：

8.3 浅层聊天机器人 vs AI 工作流对比表#