简介这是一份面向互联网产品经理转型需求的AI产品经理入门手册上篇系统梳理AI产业结构的行业AI、AI行业与基础平台三类公司并区分狭义与广义AI产品经理的职责边界覆盖语义、语音、计算机视觉、机器学习四大技术领域及对话、人脸识别、智能客服等典型落地场景。压缩包共1个文件为PDF电子书整体大小445KB以思维导图和分类说明为主便于快速通读、回看和检索。目前已有623人学习。除了宏观AI全景图文中还提出了AI产品经理的能力模型结合资本寒冬下商业变现模式的选择、产品需求把控方式以及安防、金融、企业服务等行业的落地案例帮助读者从行业认知落到岗位能力。通过学习可明确不同类型产品经理的能力侧重点判断自身适合切入的方向为后续转型或继续学习下篇内容打下扎实基础。1. AI产品经理入门手册一份让转岗少走半年弯路的地图第一次带AI功能的需求评审我被算法同事连续问了八个“然后呢”用户意图怎么定义、badcase怎么判定、答错了算谁的、超时降级策略是什么……传统PM那套PRD打法在AI产品面前几乎失效。后来翻完《AI产品经理入门手册上》我才想明白问题不在需求本身而在做需求的人对模型的边界缺乏体感。这份手册不是算法教材它把大模型能力边界、模型选型、Prompt调试、RAG知识库、评估指标这些AI PM天天要打交道的活儿按产品视角重新组织了一遍。适合两类人一类是正从传统PM转向AI方向的从业者另一类是手上已经接了AI功能但总被技术问题卡住的产品经理。它能帮你在动手写PRD之前先建立正确的模型直觉。2. 先看懂AI产品的底层约束大模型的能力边界与三个可行性判断2.1 生成式模型的三个底层约束所有AI产品的翻车现场几乎都能归到三个约束上概率生成、上下文窗口、工具依赖的不确定性。大模型的输出是逐个token采样出来的不是查表查出来的这意味着同样的输入在temperature不为0时可能给出不同答案。这个特性决定了AI产品天然不适合做高确定性业务比如金额计算、权限校验、设备控制这类场景要么加规则兜底要么干脆别用生成式模型。上下文窗口也有硬边界。手册“上”册里反复强调一个概念模型能看到的上下文上限不等于有效理解上限。你在API里传了20k tokens的资料模型能“看到”不代表它能在回答时准确引用其中三处细节。实际经验是长文本里的关键信息被稀释得非常严重。我做客服机器人的时候塞进500页产品手册之后模型开始混淆不同型号的保修政策后来把上下文砍到只保留当前会话相关片段准确率才拉回来。第三个约束是工具调用的不确定性。现在的模型虽然能调函数、查数据库、发请求但模型自己并不知道工具返回的结果是不是合理它只会依据返回内容继续往下编。所以引入工具类的AI功能必须在模型和工具之间加一层“结果校验”否则模型会把接口报错信息包装成一本正经的答案。2.2 判断“能不能用AI做”三个维度的可行性质检手册给出了一套很实用的判断框架我后来几乎每个需求都先过一遍。第一维度是“确定性要求”。这个功能如果答错一次用户流失还是财产损失答错无所谓的场景比如文案润色、头脑风暴AI放开跑没问题答错要命的场景比如医疗建议、法律结论AI只能做辅助草稿必须有回归规则。第二个维度是“输出是否结构化”。文本摘要、标题生成这类自由文本输出评估成本高但模型容易上手而“抽取客户名称金额日期”这类结构化抽取模型也能做但要靠清晰的输出格式约束和校验逻辑配合。手册在这里给了一个很实际的建议凡是输出要进入下游系统的功能一律让模型先输出JSON再用代码校验字段完整性和类型不要直接拿模型文本入库。第三个维度是“失败代价与兜底路径”。AI答错之后用户有没有第二条路可走一个AI问答框如果答错了用户还能转人工失败代价可控。但一个AI自动审批工具答错了后面没有复核机制这就是事故。判断能不能用AI先看失败之后有没有兜底。没有兜底的高代价场景再强的Prompt也救不回来。2.3 手册里那张能力映射表当工作底稿用不是当科普看手册里有一张“模型能力—业务需求”的映射表把常见的AI产品功能文本分类、信息抽取、问答、摘要、对话、代码生成、Agent和对应的模型能力要求、数据要求、评估难点列在了一起。我当时读完第一遍直接跳过后来做需求拆解时才后悔没早点用它。现在我的习惯是把这张表当成底稿复制到项目文档里每个新需求来临都先填一遍这属于哪类功能、对模型准确率的要求大概在多少、需要准备多少条评测样本、badcase的容忍底线是什么。填完这张表很多伪需求自己就暴露了。比如“做一个AI审批助手”填到“失败代价”一栏时就发现兜底路径完全没设计项目被直接砍掉。提醒一下这张映射表在“上”册里属于基础框架配合“下”册的使用案例看会更有体感但只读“上”册也足够建立判断骨架。3. 从传统PM转向AI PM能力模型、学习路径与六周自检计划3.1 转岗不是补算法知识缺的是“模型认知”和“评估设计”很多传统PM转AI方向第一反应是去看机器学习课程结果被数学公式劝退。手册给我的一个很重要观点是AI产品经理的核心技能不是能推导模型结构而是能在业务需求和技术可行性之间做翻译。翻译能力包含两部分一是知道模型能做什么、不能做什么边界在哪二是能把业务目标翻译成可量化的模型效果指标也就是评估设计。算法团队关心模型指标老板和用户关心业务结果AI PM的价值是让这两者对齐。我见过太多需求文档里写着“提升回答准确率”但准确率怎么算、谁来标注、样本量多少、达标线定多少全都没定义。这种需求交到算法手里算法也只能按自己的理解去标数据集最终结果跟业务预期脱节几乎是必然的。评估设计这件事是AI PM区别于传统PM最核心的能力也是“上”册里花了大篇幅在讲的部分。3.2 六周自检计划把手册读成行动清单手册本身是按章节组织的但如果只按顺序读很容易读完就忘。我的建议是把“上”册拆成一个六周的行动计划。每周一个小主题每个主题配一个交付物用输出倒逼输入。周数主题交付物第1周读手册第1~2章拆解3个热门AI产品每个产品写一页“技术边界分析”第2周模型能力边界与选型常识画一张“需求—模型能力”对照表第3周Prompt基础与迭代方法针对同一问题迭代5版Prompt并记录差异第4周评估指标与评测集设计给自己选的一类功能写20条评测样本第5周RAG与知识库基础用一个公开文档做一次最小知识库搭建第6周PRD改写与方案评审把传统功能PRD改写成AI版PRD并模拟评审第1周的“拆解产品”是最容易卡住的一步因为大多数人会写成功能清单而不是技术边界分析。正确做法是反向推测这个产品的问答如果答错了会怎样、它背后的知识库大概是怎么组织的、它的Prompt里会做哪些限制。推测错了没关系关键是养成从“模型约束”角度观察产品的习惯。3.3 每周输出物比读书笔记重要三个检验标准按这套计划执行时我给自己定了三个检验标准。第一个标准是“讲得清”能不能用一个比喻把大模型的概率生成特性讲给不懂技术的同事听。讲不清楚就是没理解手册里的术语只是纸面上的。第二个标准是“写得明”Prompt迭代时每次修改的变量是什么、预期改善什么、实际效果如何。写得明的意思是不靠感觉调Prompt。第三个标准是“测得准”评测样本不能只选好回答的要包含用户真实可能会问的刁钻问题。20条样本里至少有5条是边界情况否则评测集就是摆设。这三条做到后“上”册就有参考价值了。我到现在偶尔遇到接不了手的AI需求还要回翻手册里关于指标设计的章节。六周做完再去看“下”册的Agent实战案例理解速度跟直接硬读完全不一样因为脑子里已经建立了一套“模型能力边界”的坐标系后面所有具体技术都是往这个坐标系对应位置挂靠。4. 动手跑通第一个AI功能Prompt调试、RAG构建与上线评估的完整路径4.1 Prompt调试把玄学变成可复现的结构化迭代手册“上”册里对Prompt调试有一节非常务实核心可以浓缩成一句我的总结先定结构再调细节。很多人调Prompt是靠“再加一句试试”这本质上是在碰运气。结构化的写法分为五个部分角色设定、任务目标、输入格式、输出约束、例子。其中“输出约束”和“例子”是最容易被忽略但对效果影响最大的两块。system_prompt # 角色 你是智能客服负责解答XX产品的售后问题。 # 任务目标 根据【参考文档】回答用户提问。只允许回答文档中出现的内容。 如果文档中没有答案明确回复“该问题暂未收录请转人工处理”不要自行推断。 # 输入格式 用户提问{{user_question}} # 参考文档 {{retrieved_chunks}} # 输出要求 - 回答限制在100字以内 - 每个结论后面加[文档编号]没有编号视为无效回答 user_question 我买的设备连不上Wi-Fi怎么办这段代码的逻辑是先给模型一个明确的角色天花板再限定答案来源最后用“文档编号”要求模型把回答锚定到具体内容上。参数上要注意两点{{retrieved_chunks}}里不要塞过长的文本控制在2000~3000字以内对多数模型比较稳妥[文档编号]这个约束是强制模型“引用来源”的廉价替代方案比让它自由发挥再事后校验成本低得多。调试Prompt的节奏也有讲究。每改一版只动一个变量要么改角色描述要么加一条输出约束要么换一个例子。然后准备一组固定评测问题每次改完跑全部问题记录真假阳性和失败模式变化。从第一版到稳定版本我一般要迭代5~8轮前两轮都在斧正结构后几轮才是在细抠措辞。注意如果前两轮结构定完之后效果依然不稳定需要考虑的不是继续改Prompt而是数据问题。4.2 RAG知识库嵌入切分参数设好了才是AI产品的加速器RAG是AI问答类产品绕不开的模块。手册里把它讲得很直白把资料切块、向量化、检索、把检索结果喂给模型。听起来简单实际落地的坑集中在两个参数上chunk_size切块大小和检索返回条数。切块太大检索召回的片段里混入无关内容模型容易“看花眼”切块太小语义信息不完整召回的内容又不足以支撑完整回答。我在一个项目里把产品说明书切成300字的chunkoverlap设50字检索topk取4相似度阈值0.45。这套参数跑出来的效果比一股脑切500字、不设阈值要稳得多。但参数值是随文档类型浮动的技术文档适合中小chunk制度类长文适合更大的chunk。关键是记录每一组参数下的召回示例并把召回的坏case标注出来而不是只看“看起来差不多”。# 使用bge-m3做向量化的示例配置 # embedding_model: BAAI/bge-m3 # chunk_size: 300 # chunk_overlap: 50 # search_topk: 4 # similarity_threshold: 0.45这条命令行的核心是embedding模型选型。bge-m3对中文支持友好在常识性问答场景效果好如果是英文技术文档OpenAI的text-embedding-3-small也能用。需要理解的是embedding模型的“语义敏感度”是整体效果的上限检索参数调得再精细embedding模型选错效果也上不去。迭代RAG时要同时看两个东西检索结果本身对不对以及模型基于检索结果生成的回答对不对。很多团队只测最终问答效果检索环节错的一塌糊涂却被Prompt强行纠正但这个“纠正能力”不可控换个问题就露馅。所以建一个检索评估记录把“检索到的chunk是否相关”作为独立指标去卡。切分、召回、阈值这几点调明白AI问答类功能就成功了一大半。4.3 上线前评估用数字说话不靠“感觉还行”AI产品最容易翻车的地方就是没有量化评估。手册里给出了一个基础评估框架我在每次上线前都会填一张指标表。这个表不需要多复杂能说明两件事就行当前模型效果是优还是劣下一版要重点涨哪个指标。指标计算方式评估数据来源本版目标回答正确率人工评测Correct数 / 样本总数200条含边界case的评测集≥80%幻觉率评测中无文档依据内容的占比同上≤5%无效响应率拒绝或转人工的回复占比同上≤15%检索命中率正确chunk在前4条返回的占比检索日志抽样≥85%兜底触发率触发兜底逻辑的会话数 / 总会话数线上日志按场景定义表里的数据不是说天天刷这套而是每一版模型或参数变更后必须过一遍。尤其在Prompt改动之后不要只看一两个例子“变好了”就确认必须跑满全部评测集。别小看这个操作很多“好像变强了”的新版Prompt全量测试之后准确率反而掉3个点原因是模型被新约束带偏了某些用例。上线前不跑这套数据上线后在用户那里翻车进退两难的是你。5. 避坑篇AI产品从PRD到交付路上最常见的五个坑5.1 坑一把ChatGPT的演示效果直接当成产品预期现象需求评审时拿网上的对话截图当效果示例算法按这个目标做最后线上效果远不如演示那么“聪明”。原因演示场景通常经过了精心构造的Prompt和单轮问题测试真实用户输入的多样性和模糊性远超演示集。解决从第一天就建立自己的评测集明确告诉团队“以上传截图只是目标方向不是验收标准”一切效果判断以评测集结果为准。5.2 坑二评测集和真实用户输入严重脱节现象上线前评测准确率85%上线后用户反馈“答非所问”复盘时发现评测集里的问题都是规范长句真实用户输入全是口语简写。原因评测样本的分布和线上真实分布不一致样本覆盖不到短句、错字、方言口语等噪声。解决从灰度日志里抽300条真实用户输入补充到评测集中每次迭代都用“真实输入人工标注”双轨跑分。5.3 坑三文档和PDF解析没做清洗知识库直接失效现象RAG知识库搭建完成模型回答经常引用不存在的内容检索命中率跌破一半。原因PDF文档直接切块向量化没有做文本清洗。扫描版PDF切出来的是一堆乱码表格和复杂排版被拆得语义破碎多栏文档把跨栏内容切进同一个chunk检索结果自然惨不忍睹。解决先做PDF解析——区分文字版和扫描版扫描版先过OCR层表格转成markdown格式普通文本做分栏重组后再切chunk。这一步别省否则后面的参数调优全是在垃圾数据上做无用功。5.4 坑四盲目加大上下文长度想让模型“记住更多”反而变笨现象给模型的上下文从3k提到8k想引导它回答得全面一些结果关键信息反而答错。原因长上下文会稀释模型对局部重点的关注度加上RAG召回的内容本来就有相关性排序硬把所有内容塞进上下文等于放弃了排序。解决控制topk和chunk长度优先让检索环节把“最相关”的内容选出来而不是在生成环节做二次蒙题。上线前统计单次请求实际消费的token数守住成本底线。5.5 坑五AI产品的PRD还按传统软件逻辑走评审被问住现象PRD里画了完整状态机但AI功能不存在“确定路径”输入不同、输出就不同评审时被追问“用户骂人时回什么”懵住。原因传统PRD把路径穷举当作文档骨架AI产品需要的是“范围约束兜底”加上处理不确定性的设计原则。解决AI版PRD按四段式写——模型能力边界说明、输入允许范围、输出约束规范、失败兜底链路。把“模型可能答非所问”作为设计假设写进文档后续的容错方案就有依据了。6. 把手册用到工作里一张验收清单和一个Prompt版本表6.1 模型能力与业务需求的验收清单这是我从手册的映射表里衍生产出的工具现在每个AI功能启动前必填。清单一共五项第一这个功能的核心输出是否允许“近似正确”不允许的话AI做不了主决策第二输入侧的自由度有多大越小越可控第三有没有可以参考的文档或数据支撑没有数据的AI功能是空中楼阁第四错误发生时是否可回退、可转人工、可降级第五评测指标是否能量化不能量化的功能先补评测集再谈上线。这五项只要有一项是“否”或“不确定”项目就要停下来补齐或者砍掉。用这份清单的好处是需求的负责人可以在算法介入前先自我过滤掉一批明显不可行的项目减小沟通成本。6.2 Prompt版本表给自己的效果留后悔药调Prompt时一定要留版本记录别依赖对话历史里的草稿。我自己维护一张表格列为版本号、修改的变量、预期目标、实际效果、评测集得分、备注。每次改完Prompt全量评测集跑一遍得分记录在案。有这张表在手发现某版效果变差时可以随时回滚到上一版用数据说服团队而不是相互扯皮。| 版本号 | 修改内容 | 预期目标 | 评测得分 | 生效时间 | |---------|-----------|------------|------------|-----------| | v1.0 | 基础结构 | 建立基线 | 正确率62% | 2025-11-01 | | v1.1 | 增加角色限定 | 降低跑题率 | 正确率68% | 2025-11-03 | | v1.2 | 增加输出约束 | 提升格式合规 | 正确率67%幻觉上升 | 2025-11-05 | | v1.3 | 回滚输出约束换示例 | 兼顾效果 | 正确率74% | 2025-11-08 |从那以后我每个AI功能都强制把验收清单和Prompt版本表走一遍哪怕是很小的改动也照填不误。差一个数字不填上线后出问题就少一条排查线索。这套习惯是我从手册里拿到的最值得坚持的东西希望帮到你。本文还有配套的精品资源点击获取