一名 AI 产品经理，从需求到上线经历什么

中型企业内部场景：客服每日处理大量重复问题，新人培训成本高，常被问及功能操作、X003 报错，希望 AI 产品经理落地员工智能助手。

这就是需求的起点。

第一步：发现需求，判断是否适合AI

拿到需求后，第一件事不是写PRD，而是判断这件事是否真的适合用AI来解决。

你需要回答几个问题：用户的核心痛点是什么？（知识查找效率低、重复咨询多）这个场景是否有足够的数据支撑？（历史工单、产品文档、FAQ）如果做错了，后果有多严重？（知识库问答答错了顶多是误导，但如果是医疗诊断或金融风控，AI可能根本不适合介入）

对于“企业AI知识库助手”这个场景，答案是清晰的：有数据、有痛点、容错空间可接受——AI可以上。

第二步：选择技术方案

接下来是技术选型。你要回答：大模型、RAG、还是微调？

知识库助手的核心是“从已有知识中检索并生成答案”，而不是让模型凭空创造新内容。RAG（检索增强生成）是当下主流且有效的方案——先从知识库里检索相关信息，再让模型基于这些信息生成回答。相比微调，RAG成本更低、更新更快、幻觉风险也更可控。

你决定采用RAG架构：向量数据库存知识文档，用户提问后先检索相关内容，再交给大模型生成答案。

第三步：Prompt与RAG设计

方案定了，开始细化设计。

Prompt层面，你要设计System Prompt——告诉模型“你是谁、能做什么、不能做什么”。比如约束它“只能基于检索到的知识回答，超出知识范围请明确说不知道”，避免它自由发挥。

RAG层面，你要决定知识文档怎么切分（文本块多大、重叠率多少），检索阈值设多高，召回多少条相关文档送给模型。这些细节直接决定回答质量。

第四步：原型与测试

用LangChain或Flowise等工具快速搭建一个可交互的原型，让真实用户提一些问题，观察回答质量。你会发现：有些问题检索不到相关内容，模型开始“编”；有些问题检索到了，但模型回答得不够精准。

原型阶段的核心任务是验证，而不是追求完美。

第五步：幻觉处理

这是AI产品经理最绕不开的环节。幻觉是大模型的底层概率属性，永远无法彻底根除。AI产品经理的职责不是消灭幻觉，而是通过产品机制控制幻觉的影响范围。

针对知识库助手，你可以做几件事：

RAG兜底：确保回答都基于检索到的知识，降低模型自由发挥的空间

置信度阈值：设置检索相似度门槛，低于阈值直接告诉用户“未找到相关信息”

引用溯源：在回答中标注信息来源，用户可以点进去核实

免责声明：在UI上明确提示“内容由AI生成，请核实关键信息”

第六步：效果评估与上线

上线前，你要定义清楚什么叫“好”。

评估指标包括：回答准确率、知识命中率、用户满意度、转人工率。设定好基线——比如“准确率目标85%以上才能全量上线”——然后用A/B测试或灰度发布逐步放量。

上线不是终点。通过用户行为日志和负反馈数据，持续优化检索策略和Prompt。AI产品从来不是一个“造功能”的过程，而是将不确定的模型能力转化为可控的用户体验。

为什么AI产品经理不能只学产品，也不能只学大模型概念

回顾整个流程你会发现：发现需求需要产品思维，判断AI适配需要技术判断力，设计Prompt和RAG需要工程理解，处理幻觉需要风险意识，评估上线需要数据思维——每一个环节都在调用不同领域的能力。

只会产品方法论的人，做不了技术选型和幻觉兜底；只会大模型概念的人，做不了需求判断和用户体验设计。AI产品经理的价值，往往在于把这两套知识体系放到同一个产品场景里协同运作。

这也是 AIPM 认证在设计上比较值得关注的一点。 AIPM 认证的考核内容覆盖用户洞察与商业战略、AI产品设计、技术可行性判断、多智能体架构、提示工程、产品评估和数据迭代等多个维度，不是让学习者孤立地学产品理论或大模型概念，而是把这些知识放回真实的产品场景和实操项目中。

从发现需求、判断AI适配性，到设计Prompt、处理幻觉、推动上线—— AIPM 认证试图构建的，是贯穿这个完整链路的能力框架。

对于想要系统进入AI产品领域的人来说，这也许比碎片化地学几个Prompt技巧或读几篇大模型科普，更接近真实的工作需要。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～