最近两年和“AI产品经理”相关的讨论非常多但真正落到面试现场情况往往很残酷。很多候选人能聊出“AIGC会改变行业”这类正确废话可一旦被追问“这个需求要不要接大模型API”“幻觉怎么控制”“评测集怎么建”“Agent方案怎么评审”就开始含糊其辞。这其实暴露了一个关键问题AI产品经理的真正门槛不在传统产品方法论而在技术理解力。这篇文章不准备讨论“AI会不会取代产品经理”这种泛泛话题而是分享一套可以照着执行的AI产品经理学习与实践框架。我会从能力模型、技术原理、完整项目流程、模型评测到一周学习路线逐一拆开讲。不堆砌概念不讲宏大趋势尽量让看完的人能直接上手验证自己的理解。1. AI产品经理到底解决什么问题很多团队在招AI产品经理时并不清楚这个岗位和传统产品经理的边界。传统产品经理面对的是确定性系统。页面有几个按钮、流程怎么走、异常状态怎么提示都可以提前定义。即使出问题逻辑漏洞往往是可复现、可定位的。AI产品经理面对的是概率性系统。同一个Prompt模型在不同时间可能给出不同回答同一个问题换个表达方式可能触发完全不同的内容模型还可能出现幻觉、偏见、格式不稳定的情况。你没办法用“写清楚PRD”的方式让模型100%按预期工作。所以AI产品经理的核心职责是把“不确定的模型能力”转化为“相对稳定的产品体验”。这个话听起来抽象拆开就三条判断模型能力边界这个需求到底适不适合用大模型解决还是规则引擎、传统算法更可靠。设计兜底与评测机制模型出错时产品怎么表现如何定义“答得好不好”。管理数据与成本评测集从哪来、Token成本怎么控制、数据隐私怎么处理。下面这个对比可以帮助理解差异。维度传统产品经理AI产品经理产品核心确定性的功能逻辑概率性的模型输出需求定义功能清单、页面流程能力边界 评测指标主要风险流程漏洞、交互缺陷幻觉、偏见、隐私、成本失控交付物PRD、原型图PRD、评测集、效果报告、灰度方案关键工具Figma、Axure、流程图API调试、Prompt平台、评测脚本、标注平台举个例子。同样是做内容审核系统传统产品经理会设计规则引擎关键词列表、分类逻辑、人工审核队列。AI产品经理要考虑的是用哪种模型做初审、置信度阈值设多少、低置信度内容怎么分流到人工、模型更新后审核标准会不会漂移、误判率和召回率怎么平衡。这个例子说明一个判断AI产品经理不是传统产品经理的“AI版”而是不确定性产品的设计者。如果还用传统产品思路去做AI产品大概率会在上线后被各种badcase打得措手不及。2. 能力模型AI产品经理的技术理解要到哪一层经常有转岗的同学问“我是不是得先学会训练模型才有资格做AI产品经理”答案是否定的。但完全不学技术也不行。我把AI产品经理的技术理解分成五层可以对照自检层级能力描述是否需要术语层知道大模型、Prompt、Token、RAG这些词必须调用层能自己调API改参数看返回结果必须原理层理解Transformer基本思想、RAG流程、Agent机制强烈建议调优层能做Prompt迭代、评测集设计、badcase分析强烈建议研发层能训练模型、微调、部署服务非必须多数AI产品经理岗位真正要求的是“调用层 原理层 调优层”。你需要看得懂技术方案评审能和技术团队争论“这个方案成本是否合理”“这个方案能不能满足业务要求”但不一定要自己动手训练模型。下面这些概念建议产品经理至少了解它们解决什么问题、代价是什么概念需要理解到什么程度为什么产品经理需要Token计费单位也是上下文长度单位估算成本、判断模型记忆上限上下文窗口模型一次能“看到”的文本长度设计对话产品时决定策略幻觉模型生成看似合理但错误的内容设计兜底、防误导机制Prompt输入给模型的指令它是AI产品的“交互界面”之一RAG检索增强生成知识类产品的核心方案之一Agent让模型调用工具完成任务任务型产品的主要架构微调用业务数据调整模型行为判断技术选型时避免过度设计模型部署API调用与本地部署的差异决定成本、延迟、数据合规边界这里真正的分水岭不是你能不能画出PRD而是面对技术方案时能不能提出高质量问题。比如“这个RAG方案的召回率是多少评测集怎么建”“Agent工具调用失败后用户会被卡住吗有没有人工接管路径”“模型API的延迟是几百毫秒还是几秒用户能接受吗”“如果上游模型升级了我们的评测集能发现效果回退吗”能问出这些问题说明你不是只会堆砌AI名词。3. 技术底座看懂一次真实的模型调用很多产品经理觉得写代码是研发的事自己不用碰。但在AI产品领域我强烈建议至少自己写一次模型调用。不亲自动手你很难理解为什么技术团队说“上下文太长”“Token成本太高”的时候是认真的。一次真实的API调用会帮你把很多抽象概念变成体感。下面是一个最基础的模型调用示例用Python的requests库直接请求Chat Completions接口不依赖特定SDK方便理解本质。import requests import json import os # 推荐从环境变量读取密钥不要硬编码在代码里 api_key os.environ.get(LLM_API_KEY, your-api-key) url https://api.openai.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: gpt-4o-mini, messages: [ {role: system, content: 你是一名AI产品经理导师回答要简洁、结构化。}, {role: user, content: 请用三句话解释RAG为什么能减少大模型幻觉。} ], temperature: 0.3, max_tokens: 500 } resp requests.post(url, headersheaders, jsonpayload) if resp.status_code 200: result resp.json() reply result[choices][0][message][content] print(reply) # 查看Token消耗 print(prompt_tokens:, result.get(usage, {}).get(prompt_tokens)) print(completion_tokens:, result.get(usage, {}).get(completion_tokens)) else: print(请求失败:, resp.status_code, resp.text)这段代码虽然简单但已经包含了产品经理需要掌握的几个核心概念。model参数决定效果和成本。不同模型的能力、速度、价格差别很大选型是产品决策而不是纯技术决策。messages数组包含角色信息。system角色定义模型的身份和行为准则user角色代表用户输入。有些产品会把历史对话也塞进messages这就直接影响上下文长度和Token消耗。temperature控制随机性。值越低回答越稳定适合客服、审核等需要一致性场景值越高更有创造性适合文案生成类场景。在需要可控性的产品里我通常会建议使用0.2到0.4之间的值。max_tokens限制返回长度也直接影响成本。产品经理要能估算出一次对话平均消耗多少Token乘上用户量判断成本是否可接受。调用成功后返回结果大致是下面这种结构{ choices: [ { message: { role: assistant, content: RAG通过检索外部知识库为模型提供事实依据降低凭空生成概率。 } } ], usage: { prompt_tokens: 30, completion_tokens: 80, total_tokens: 110 } }判断调用成功不只看HTTP状态码是200还要看choices数组是否为空、content是否为空。如果返回了错误信息最常见的原因包括密钥无效、请求格式不对、触发了内容安全策略、账户额度不足。安全提醒API密钥绝对不能写进前端代码也不能硬编码提交到Git仓库。企业环境里一般通过网关或后端服务转发模型请求产品经理在上线前要确认数据链路里没有敏感信息泄露风险。能自己调通一次API后续做技术方案评审会从容很多。因为你对成本、延迟、参数、错误处理都有了真实体感不再停留在概念层面。4. 提示词设计AI产品的交互界面很多团队把提示词当成“写一段话让模型干活”但在实际产品里提示词就是产品逻辑的一部分。你设计页面时会定义按钮文案、流程分支、空状态设计提示词时同样要定义角色、任务、限制、输出格式。它们是同一个工种把产品需求翻译成可执行的指令。一个相对完整的提示词模板通常包含这些要素角色你是【产品名称】的智能客服助手。 任务根据【知识库内容】回答用户问题。 限制 1. 只使用知识库提供的信息作答不要编造。 2. 如果知识库没有答案明确回复“暂无相关信息”不要强行猜测。 3. 回答控制在150字以内使用简洁的列表或短句。 输出格式 - 直接答案 - 依据来源引用知识库文档标题这个模板看起来简单但实际能解决几个常见问题减少幻觉限制只依据知识库、控制回复长度成本与体验平衡、保证可溯源输出来源。提示词设计不是靠“文笔好”而是靠“可验证”。正确的做法是准备10个到20个典型用户问题。定义评分维度比如准确性、完整性、格式合规性。分别用不同版本的提示词测试记录通过率。选通过率最高的版本上线后续持续迭代。这里有个容易踩的坑把提示词当成万能钥匙。如果业务场景很复杂比如需要处理多轮对话、需要实时查询用户订单、需要控制风险级别单靠提示词是不够的。这时候要考虑引入RAG、Agent、前后端逻辑配合提示词只是整个系统里的一环。还有一个需要提醒的点提示词不是一次写好就一劳永逸。上游模型版本升级后同样的提示词效果可能会变化。所以每次模型切换前都要用评测集回归一遍确认没有效果退化。5. RAG与AgentAI产品经理绕不开的两个技术框架现在的AI产品很少是“一个模型裸奔”的状态。两个技术框架出现频率最高RAG和Agent。5.1 RAG给模型配一本可检索的参考手册RAG的全称是Retrieval-Augmented Generation检索增强生成。通俗讲就是先从一个知识库里检索出相关内容再把这些内容拼接进Prompt让模型基于这些材料回答。为什么要用RAG三个核心原因知识实时性。大模型训练数据有截止时间无法知道最新政策、最新价格、最新内部文档。幻觉控制。模型凭空生成容易出错但给它一段参考材料出错概率会明显下降。可溯源。用户问了“为什么”你可以指出依据来自哪份文档。RAG的核心流程大概是把业务文档切分成片段。将这些片段向量化存入向量数据库。用户提问后把问题也向量化检索出最相关的片段。把相关片段和用户问题一起拼进Prompt。模型基于这些片段生成最终回答。产品经理做RAG方案评审时最该关注这几个指标检索召回了多少相关内容、召回内容是否相关、最终回答是否准确、一次回答消耗多少Token、知识库更新后多久能生效。不考虑这些方案做出来很容易“看起来合理用起来抓狂”。5.2 Agent从“回答问题”到“完成任务”Agent和RAG解决的是不同问题。RAG解决知识缺失Agent解决行动能力。在没有Agent之前大模型是一个“知识问答工具”。你问它问题它回答你。但很多场景需要模型去调用工具查天气、订机票、更新数据库、发送消息。Agent的核心机制就是让模型能自动决定“要不要调用某个工具”“调用哪个工具”“参数是什么”然后根据工具返回结果继续决策直到完成任务。产品经理设计Agent产品时需要额外考虑任务边界Agent能在多大范围内自主行动超过边界必须转人工。工具权限它能调用的工具和系统是否遵循最小权限原则。失败回退工具调用超时、参数错误、结果异常时系统怎么处理。人工接管什么时候强制结束Agent循环避免无限重试。5.3 RAG和Agent是什么关系它们不是替代关系很多产品是组合使用。Agent负责规划任务和调用工具RAG负责提供知识材料。比如一个企业服务助手RAG保证回答有依据Agent负责查询工单状态、更新任务记录。产品经理在方案设计阶段要分清哪部分用RAG支撑哪部分用Agent执行哪部分还要保留传统规则逻辑。我见过一些团队在需求还没理清时就急着上“Agent自动化”结果Agent在真实环境中反复调用错误工具、消耗大量Token最后不得不回退到人工处理。真正稳妥的做法是先明确任务闭环再决定要不要Agent化。6. 从0到1做AI产品流程与关键决策AI产品的流程和传统产品有重合但决策点完全不同。一个典型流程可以拆成六步。需求定义明确用户要完成什么任务成功标准是什么。这个环节最容易出现的问题是“只描述功能不定义效果指标”。技术选型确定模型来源、模型规模、架构方案。数据准备构建评测集准备知识库规划标注方案。原型与验证用小样本验证核心链路是否走通。灰度上线控制流量准备兜底快速回滚。监控迭代回收badcase持续优化定期回归。技术选型是产品经理参与最深的部分。下面这个决策表可以用于内部评审讨论。决策点可选方向判断依据模型来源API调用 / 开源部署数据合规、成本、延迟、团队能力模型规格大模型 / 小模型效果要求、成本、终端部署条件是否使用RAG是 / 否知识是否动态变化、是否需要溯源是否微调是 / 否是否需要特定格式、领域术语、品牌风格是否使用Agent是 / 否是否需要调用外部工具完成任务交互方式对话框 / 表单 / 嵌入流程用户习惯、任务复杂度、容错成本这套流程里AI产品经理的核心产出物包括PRD、评测集、效果评估报告、上线checklist。其中评测集最容易被忽视但它恰恰决定了整个产品能否可持续迭代。说一个真实的工作体感很多AI项目失败不是模型选错了而是上线前没有评测集、没有明确的badcase回收机制。结果是模型一升版没人知道效果是变好还是变差用户反馈了问题团队只能凭感觉修。所以评测不是“最后补的文档”而是项目一开始就要搭建的基础设施。7. 模型评测AI产品经理最该补的硬技能如果只能从这篇文章里挑一个技能去补我会选“模型评测”。因为它同时连接了技术理解、产品判断和数据能力。7.1 评测集怎么建评测集不需要一开始就做几千条。小规模验证期20到50条足够发现问题进入正式迭代期再逐步扩充到几百条甚至上千条。评测集要覆盖几类样本正常场景用户最常见的提问方式要占大多数。边界场景问题很长、很模糊、包含错别字等。恶意输入尝试越狱、诱导模型输出不安全内容。建评测集时要注意不要用生产环境的真实用户数据直接做测试。涉及个人信息时必须脱敏遵循最小必要原则。7.2 评测维度怎么定义不同产品评测维度不同。通用的几个维度包括准确性回答是否和标准答案一致是否有事实错误。完整性有没有遗漏关键信息。格式合规性是否遵守输出格式要求。延迟和成本一次请求耗时多少、消耗多少Token。准确性可以人工标注也可以让一个更强的模型做自动评估。下面是一个自动评测的简化脚本def evaluate_answer(question, reference, candidate, api_key): prompt f 请判断以下回答是否准确。 问题 {question} 标准答案 {reference} 模型回答 {candidate} 请按三个维度打分0-5 1. 准确性是否与标准答案一致有无事实错误 2. 完整性是否遗漏关键点 3. 格式友好度是否清晰、易读符合要求 只输出JSON格式如下 {{accuracy: 5, completeness: 4, format: 4}} # 调用模型API将prompt发送给评估模型 # 返回后解析JSON即可得到各维度分数 # 注意自动评估可辅助决策关键badcase仍需人工复核 pass自动评测的核心价值是“可重复”。跑一次得到一份分数把结果存档。下次模型升级或Prompt调整后用同一份评测集再跑一遍对比分数变化。7.3 线上指标怎么订评测集是离线验证上线后还要关注线上指标。不同产品关注点不同对话类产品转人工率、用户二次提问率、满意度评分。内容生成类产品采纳率、修改率、违规率。审核类产品误判率、召回率、人工处理时长。线上指标要和离线评测结合看。有时候离线评测分数很高但线上用户就是不买账说明评测集没有覆盖真实用户场景需要持续从线上回收badcase补充进评测集。另外Token成本要纳入评测体系。一个回答效果好但贵5倍的方案不一定是好方案一个稍微便宜但效果明显下降的方案同样不值得上线。产品经理要会算这笔账。8. 一周学习路线快速建立体系化认知经常看到“一周小白变大神”的宣传。这里给出一个更现实的一周学习路线它不是让你一周变成资深专家而是帮你在一周内建立体系化认知后面再逐步深化。8.1 第1天建立认知框架任务搞懂大模型的基本原理和行业版图。阅读2到3篇高质量大模型科普文章不需要啃论文。建立一个术语表记录Token、幻觉、上下文窗口、RAG、Agent、微调、模型部署等概念。梳理AI产品的主要赛道对话助手、知识库问答、内容生成、审核、数据分析等。产出物自己的术语表能用自己的话解释每一个词。8.2 第2天动手调API任务完成一次真实的模型调用。按照本文第3章的示例跑通一次Chat Completions接口。修改temperature、max_tokens观察返回变化。记录不同参数下消耗的Token差异建立成本体感。产出物一个能运行的调用脚本一份参数观察笔记。8.3 第3天跑通RAG任务做一个最小可用的知识库问答。准备一份几十页的业务文档或者公开的说明文档。使用现成的RAG框架或平台实现“上传文档→提问→带依据回答”。测试不同提问方式记录哪些问题答得好哪些答不好。产出物一个最小RAG问答原型一份效果观察记录。8.4 第4天理解Agent任务理解Agent的运行机制和边界。阅读Agent相关技术文章或案例。在Agent平台上搭一个最简单的自动化流程比如“接收输入→调用工具→返回结果”。分析一个真实Agent案例中任务规划、工具调用、失败回退分别是怎么设计的。产出物一个Agent流程Demo一份边界分析笔记。8.5 第5天学习评测任务给第3天的RAG产品做一次评测。整理20条评测问题覆盖正常、边界、恶意输入。设计3个评价维度人工打分。尝试用自动评测脚本辅助打分。产出物一份包含20条样本、3个维度的评测表。8.6 第6天完成模拟项目任务选一个真实场景完成“需求方案评测”闭环。场景可以选择企业知识库助手、客服智能辅助、内容摘要、审核辅助等。写一份简版PRD内容包括用户任务、模型方案、评测方案、兜底设计。结合前几天的实践给出技术选型理由。产出物一份模拟项目的PRD和评测方案。8.7 第7天整理作品集任务把一周成果整理成可展示的材料。写一篇项目复盘文章把背景、方案、效果、问题放进去。准备面试中可能被追问的问题尤其是“为什么这样设计”“这个方案的成本和风险是什么”。产出物一份项目案例一套面试问答清单。这个路线看起来任务量不轻但每天的核心不是“看很多内容”而是“动手完成一个具体产出”。如果你已经有项目经验可以把第6天和第7天的时间合并重心放在整理和输出上。需要提醒的是一周只能帮你建立框架真正从“懂概念”到“能做产品决策”至少需要完整参与一两个真实项目。所谓“一周变大神”在技术岗位里不现实也不值得追求。9. 常见误区与避坑清单下面这些误区和避坑建议来自AI产品实战中比较常见的问题。参考表格也可以对照自己的项目逐条检查。常见误区实际影响正确做法把提示词当万能钥匙业务一复杂提示词撑不住结合RAG、Agent、人工兜底只关注模型选型忽略数据模型能力再好也难适配业务优先搭建评测集和知识库把Agent当完全自动化工具调用失败时风险难以控制设计人工介入、限流、回退机制忽略Token成本上线后成本失控无法收敛上线前估算单次成本预设监控阈值不做灰度直接全量模型效果波动直接影响用户体验小流量灰度准备快速回滚方案用生产数据直接测试存在数据安全与合规风险评测数据脱敏遵循最小权限原则评测集一成不变模型迭代后回归盲区持续回收badcase定期扩充评测集忽略了模型升级的影响上游模型升级后效果回退每次切换前跑评测集回归这里挑一个重点展开成本和评测失控是最容易拖垮AI项目的问题。先说成本。很多团队最初只验证了一个小Demo没有计算全量用户、高频调用的情况。等上线后Token账单超出预期产品才被迫降级。正确做法是产品经理在评审阶段就要求提供单次回答的Token消耗估算并按日活用户、平均调用次数算出月度成本区间再决定是否要做缓存、限流或轻量化模型。再说评测。如果模型升级了Prompt优化了知识库换了一批文档但评测集还是原来那二三十条老问题那就很难发现新引入的badcase。评测集应该跟着项目成长每次升级前后都回归一遍。这个习惯一旦养成项目越到后期决策效率越高。还有一点容易被忽略不要所有事情都让模型做。很多场景比如固定格式的校验、精确计算、权限判断传统代码做得又快又准又便宜。AI产品经理要学会判断“这里到底需不需要模型”而不是“哪里有模型往哪里塞”。10. 总结与下一步行动这篇内容想表达的核心观点可以汇总成一句话AI产品经理的核心竞争力是把模型能力翻译成产品需求的能力以及把产品需求翻译成技术评审问题的能力。为了支撑这个能力需要三条线并行修炼技术理解线会调API、理解Token、理解RAG和Agent的核心机制。产品设计线定义能力边界、设计兜底方案、制定上线与灰度策略。评测迭代线建评测集、跑回归、分析badcase、控制成本。如果你刚准备转行或者已经在做AI产品但感觉思路不清晰建议从下面三个动作开始跑通一次真实模型调用哪怕只是调用API打印一句话。给手头产品整理出第一版评测集不用多20条就够。找一个具体场景把“需求→方案→评测→兜底”完整走一遍然后整理成作品集。市面上关于AI产品经理的教程和课程很多数量不是关键真正拉开差距的是你有没有动手验证过。与其囤一堆资料不如先把自己手头的第一个小项目做完把第一次评测跑出来。这个过程跑通了后面的路会顺畅很多。 AI产品经理技术必修：从模型调用到评测与Agent实战框架
最近两年和“AI产品经理”相关的讨论非常多但真正落到面试现场情况往往很残酷。很多候选人能聊出“AIGC会改变行业”这类正确废话可一旦被追问“这个需求要不要接大模型API”“幻觉怎么控制”“评测集怎么建”“Agent方案怎么评审”就开始含糊其辞。这其实暴露了一个关键问题AI产品经理的真正门槛不在传统产品方法论而在技术理解力。这篇文章不准备讨论“AI会不会取代产品经理”这种泛泛话题而是分享一套可以照着执行的AI产品经理学习与实践框架。我会从能力模型、技术原理、完整项目流程、模型评测到一周学习路线逐一拆开讲。不堆砌概念不讲宏大趋势尽量让看完的人能直接上手验证自己的理解。1. AI产品经理到底解决什么问题很多团队在招AI产品经理时并不清楚这个岗位和传统产品经理的边界。传统产品经理面对的是确定性系统。页面有几个按钮、流程怎么走、异常状态怎么提示都可以提前定义。即使出问题逻辑漏洞往往是可复现、可定位的。AI产品经理面对的是概率性系统。同一个Prompt模型在不同时间可能给出不同回答同一个问题换个表达方式可能触发完全不同的内容模型还可能出现幻觉、偏见、格式不稳定的情况。你没办法用“写清楚PRD”的方式让模型100%按预期工作。所以AI产品经理的核心职责是把“不确定的模型能力”转化为“相对稳定的产品体验”。这个话听起来抽象拆开就三条判断模型能力边界这个需求到底适不适合用大模型解决还是规则引擎、传统算法更可靠。设计兜底与评测机制模型出错时产品怎么表现如何定义“答得好不好”。管理数据与成本评测集从哪来、Token成本怎么控制、数据隐私怎么处理。下面这个对比可以帮助理解差异。维度传统产品经理AI产品经理产品核心确定性的功能逻辑概率性的模型输出需求定义功能清单、页面流程能力边界 评测指标主要风险流程漏洞、交互缺陷幻觉、偏见、隐私、成本失控交付物PRD、原型图PRD、评测集、效果报告、灰度方案关键工具Figma、Axure、流程图API调试、Prompt平台、评测脚本、标注平台举个例子。同样是做内容审核系统传统产品经理会设计规则引擎关键词列表、分类逻辑、人工审核队列。AI产品经理要考虑的是用哪种模型做初审、置信度阈值设多少、低置信度内容怎么分流到人工、模型更新后审核标准会不会漂移、误判率和召回率怎么平衡。这个例子说明一个判断AI产品经理不是传统产品经理的“AI版”而是不确定性产品的设计者。如果还用传统产品思路去做AI产品大概率会在上线后被各种badcase打得措手不及。2. 能力模型AI产品经理的技术理解要到哪一层经常有转岗的同学问“我是不是得先学会训练模型才有资格做AI产品经理”答案是否定的。但完全不学技术也不行。我把AI产品经理的技术理解分成五层可以对照自检层级能力描述是否需要术语层知道大模型、Prompt、Token、RAG这些词必须调用层能自己调API改参数看返回结果必须原理层理解Transformer基本思想、RAG流程、Agent机制强烈建议调优层能做Prompt迭代、评测集设计、badcase分析强烈建议研发层能训练模型、微调、部署服务非必须多数AI产品经理岗位真正要求的是“调用层 原理层 调优层”。你需要看得懂技术方案评审能和技术团队争论“这个方案成本是否合理”“这个方案能不能满足业务要求”但不一定要自己动手训练模型。下面这些概念建议产品经理至少了解它们解决什么问题、代价是什么概念需要理解到什么程度为什么产品经理需要Token计费单位也是上下文长度单位估算成本、判断模型记忆上限上下文窗口模型一次能“看到”的文本长度设计对话产品时决定策略幻觉模型生成看似合理但错误的内容设计兜底、防误导机制Prompt输入给模型的指令它是AI产品的“交互界面”之一RAG检索增强生成知识类产品的核心方案之一Agent让模型调用工具完成任务任务型产品的主要架构微调用业务数据调整模型行为判断技术选型时避免过度设计模型部署API调用与本地部署的差异决定成本、延迟、数据合规边界这里真正的分水岭不是你能不能画出PRD而是面对技术方案时能不能提出高质量问题。比如“这个RAG方案的召回率是多少评测集怎么建”“Agent工具调用失败后用户会被卡住吗有没有人工接管路径”“模型API的延迟是几百毫秒还是几秒用户能接受吗”“如果上游模型升级了我们的评测集能发现效果回退吗”能问出这些问题说明你不是只会堆砌AI名词。3. 技术底座看懂一次真实的模型调用很多产品经理觉得写代码是研发的事自己不用碰。但在AI产品领域我强烈建议至少自己写一次模型调用。不亲自动手你很难理解为什么技术团队说“上下文太长”“Token成本太高”的时候是认真的。一次真实的API调用会帮你把很多抽象概念变成体感。下面是一个最基础的模型调用示例用Python的requests库直接请求Chat Completions接口不依赖特定SDK方便理解本质。import requests import json import os # 推荐从环境变量读取密钥不要硬编码在代码里 api_key os.environ.get(LLM_API_KEY, your-api-key) url https://api.openai.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: gpt-4o-mini, messages: [ {role: system, content: 你是一名AI产品经理导师回答要简洁、结构化。}, {role: user, content: 请用三句话解释RAG为什么能减少大模型幻觉。} ], temperature: 0.3, max_tokens: 500 } resp requests.post(url, headersheaders, jsonpayload) if resp.status_code 200: result resp.json() reply result[choices][0][message][content] print(reply) # 查看Token消耗 print(prompt_tokens:, result.get(usage, {}).get(prompt_tokens)) print(completion_tokens:, result.get(usage, {}).get(completion_tokens)) else: print(请求失败:, resp.status_code, resp.text)这段代码虽然简单但已经包含了产品经理需要掌握的几个核心概念。model参数决定效果和成本。不同模型的能力、速度、价格差别很大选型是产品决策而不是纯技术决策。messages数组包含角色信息。system角色定义模型的身份和行为准则user角色代表用户输入。有些产品会把历史对话也塞进messages这就直接影响上下文长度和Token消耗。temperature控制随机性。值越低回答越稳定适合客服、审核等需要一致性场景值越高更有创造性适合文案生成类场景。在需要可控性的产品里我通常会建议使用0.2到0.4之间的值。max_tokens限制返回长度也直接影响成本。产品经理要能估算出一次对话平均消耗多少Token乘上用户量判断成本是否可接受。调用成功后返回结果大致是下面这种结构{ choices: [ { message: { role: assistant, content: RAG通过检索外部知识库为模型提供事实依据降低凭空生成概率。 } } ], usage: { prompt_tokens: 30, completion_tokens: 80, total_tokens: 110 } }判断调用成功不只看HTTP状态码是200还要看choices数组是否为空、content是否为空。如果返回了错误信息最常见的原因包括密钥无效、请求格式不对、触发了内容安全策略、账户额度不足。安全提醒API密钥绝对不能写进前端代码也不能硬编码提交到Git仓库。企业环境里一般通过网关或后端服务转发模型请求产品经理在上线前要确认数据链路里没有敏感信息泄露风险。能自己调通一次API后续做技术方案评审会从容很多。因为你对成本、延迟、参数、错误处理都有了真实体感不再停留在概念层面。4. 提示词设计AI产品的交互界面很多团队把提示词当成“写一段话让模型干活”但在实际产品里提示词就是产品逻辑的一部分。你设计页面时会定义按钮文案、流程分支、空状态设计提示词时同样要定义角色、任务、限制、输出格式。它们是同一个工种把产品需求翻译成可执行的指令。一个相对完整的提示词模板通常包含这些要素角色你是【产品名称】的智能客服助手。 任务根据【知识库内容】回答用户问题。 限制 1. 只使用知识库提供的信息作答不要编造。 2. 如果知识库没有答案明确回复“暂无相关信息”不要强行猜测。 3. 回答控制在150字以内使用简洁的列表或短句。 输出格式 - 直接答案 - 依据来源引用知识库文档标题这个模板看起来简单但实际能解决几个常见问题减少幻觉限制只依据知识库、控制回复长度成本与体验平衡、保证可溯源输出来源。提示词设计不是靠“文笔好”而是靠“可验证”。正确的做法是准备10个到20个典型用户问题。定义评分维度比如准确性、完整性、格式合规性。分别用不同版本的提示词测试记录通过率。选通过率最高的版本上线后续持续迭代。这里有个容易踩的坑把提示词当成万能钥匙。如果业务场景很复杂比如需要处理多轮对话、需要实时查询用户订单、需要控制风险级别单靠提示词是不够的。这时候要考虑引入RAG、Agent、前后端逻辑配合提示词只是整个系统里的一环。还有一个需要提醒的点提示词不是一次写好就一劳永逸。上游模型版本升级后同样的提示词效果可能会变化。所以每次模型切换前都要用评测集回归一遍确认没有效果退化。5. RAG与AgentAI产品经理绕不开的两个技术框架现在的AI产品很少是“一个模型裸奔”的状态。两个技术框架出现频率最高RAG和Agent。5.1 RAG给模型配一本可检索的参考手册RAG的全称是Retrieval-Augmented Generation检索增强生成。通俗讲就是先从一个知识库里检索出相关内容再把这些内容拼接进Prompt让模型基于这些材料回答。为什么要用RAG三个核心原因知识实时性。大模型训练数据有截止时间无法知道最新政策、最新价格、最新内部文档。幻觉控制。模型凭空生成容易出错但给它一段参考材料出错概率会明显下降。可溯源。用户问了“为什么”你可以指出依据来自哪份文档。RAG的核心流程大概是把业务文档切分成片段。将这些片段向量化存入向量数据库。用户提问后把问题也向量化检索出最相关的片段。把相关片段和用户问题一起拼进Prompt。模型基于这些片段生成最终回答。产品经理做RAG方案评审时最该关注这几个指标检索召回了多少相关内容、召回内容是否相关、最终回答是否准确、一次回答消耗多少Token、知识库更新后多久能生效。不考虑这些方案做出来很容易“看起来合理用起来抓狂”。5.2 Agent从“回答问题”到“完成任务”Agent和RAG解决的是不同问题。RAG解决知识缺失Agent解决行动能力。在没有Agent之前大模型是一个“知识问答工具”。你问它问题它回答你。但很多场景需要模型去调用工具查天气、订机票、更新数据库、发送消息。Agent的核心机制就是让模型能自动决定“要不要调用某个工具”“调用哪个工具”“参数是什么”然后根据工具返回结果继续决策直到完成任务。产品经理设计Agent产品时需要额外考虑任务边界Agent能在多大范围内自主行动超过边界必须转人工。工具权限它能调用的工具和系统是否遵循最小权限原则。失败回退工具调用超时、参数错误、结果异常时系统怎么处理。人工接管什么时候强制结束Agent循环避免无限重试。5.3 RAG和Agent是什么关系它们不是替代关系很多产品是组合使用。Agent负责规划任务和调用工具RAG负责提供知识材料。比如一个企业服务助手RAG保证回答有依据Agent负责查询工单状态、更新任务记录。产品经理在方案设计阶段要分清哪部分用RAG支撑哪部分用Agent执行哪部分还要保留传统规则逻辑。我见过一些团队在需求还没理清时就急着上“Agent自动化”结果Agent在真实环境中反复调用错误工具、消耗大量Token最后不得不回退到人工处理。真正稳妥的做法是先明确任务闭环再决定要不要Agent化。6. 从0到1做AI产品流程与关键决策AI产品的流程和传统产品有重合但决策点完全不同。一个典型流程可以拆成六步。需求定义明确用户要完成什么任务成功标准是什么。这个环节最容易出现的问题是“只描述功能不定义效果指标”。技术选型确定模型来源、模型规模、架构方案。数据准备构建评测集准备知识库规划标注方案。原型与验证用小样本验证核心链路是否走通。灰度上线控制流量准备兜底快速回滚。监控迭代回收badcase持续优化定期回归。技术选型是产品经理参与最深的部分。下面这个决策表可以用于内部评审讨论。决策点可选方向判断依据模型来源API调用 / 开源部署数据合规、成本、延迟、团队能力模型规格大模型 / 小模型效果要求、成本、终端部署条件是否使用RAG是 / 否知识是否动态变化、是否需要溯源是否微调是 / 否是否需要特定格式、领域术语、品牌风格是否使用Agent是 / 否是否需要调用外部工具完成任务交互方式对话框 / 表单 / 嵌入流程用户习惯、任务复杂度、容错成本这套流程里AI产品经理的核心产出物包括PRD、评测集、效果评估报告、上线checklist。其中评测集最容易被忽视但它恰恰决定了整个产品能否可持续迭代。说一个真实的工作体感很多AI项目失败不是模型选错了而是上线前没有评测集、没有明确的badcase回收机制。结果是模型一升版没人知道效果是变好还是变差用户反馈了问题团队只能凭感觉修。所以评测不是“最后补的文档”而是项目一开始就要搭建的基础设施。7. 模型评测AI产品经理最该补的硬技能如果只能从这篇文章里挑一个技能去补我会选“模型评测”。因为它同时连接了技术理解、产品判断和数据能力。7.1 评测集怎么建评测集不需要一开始就做几千条。小规模验证期20到50条足够发现问题进入正式迭代期再逐步扩充到几百条甚至上千条。评测集要覆盖几类样本正常场景用户最常见的提问方式要占大多数。边界场景问题很长、很模糊、包含错别字等。恶意输入尝试越狱、诱导模型输出不安全内容。建评测集时要注意不要用生产环境的真实用户数据直接做测试。涉及个人信息时必须脱敏遵循最小必要原则。7.2 评测维度怎么定义不同产品评测维度不同。通用的几个维度包括准确性回答是否和标准答案一致是否有事实错误。完整性有没有遗漏关键信息。格式合规性是否遵守输出格式要求。延迟和成本一次请求耗时多少、消耗多少Token。准确性可以人工标注也可以让一个更强的模型做自动评估。下面是一个自动评测的简化脚本def evaluate_answer(question, reference, candidate, api_key): prompt f 请判断以下回答是否准确。 问题 {question} 标准答案 {reference} 模型回答 {candidate} 请按三个维度打分0-5 1. 准确性是否与标准答案一致有无事实错误 2. 完整性是否遗漏关键点 3. 格式友好度是否清晰、易读符合要求 只输出JSON格式如下 {{accuracy: 5, completeness: 4, format: 4}} # 调用模型API将prompt发送给评估模型 # 返回后解析JSON即可得到各维度分数 # 注意自动评估可辅助决策关键badcase仍需人工复核 pass自动评测的核心价值是“可重复”。跑一次得到一份分数把结果存档。下次模型升级或Prompt调整后用同一份评测集再跑一遍对比分数变化。7.3 线上指标怎么订评测集是离线验证上线后还要关注线上指标。不同产品关注点不同对话类产品转人工率、用户二次提问率、满意度评分。内容生成类产品采纳率、修改率、违规率。审核类产品误判率、召回率、人工处理时长。线上指标要和离线评测结合看。有时候离线评测分数很高但线上用户就是不买账说明评测集没有覆盖真实用户场景需要持续从线上回收badcase补充进评测集。另外Token成本要纳入评测体系。一个回答效果好但贵5倍的方案不一定是好方案一个稍微便宜但效果明显下降的方案同样不值得上线。产品经理要会算这笔账。8. 一周学习路线快速建立体系化认知经常看到“一周小白变大神”的宣传。这里给出一个更现实的一周学习路线它不是让你一周变成资深专家而是帮你在一周内建立体系化认知后面再逐步深化。8.1 第1天建立认知框架任务搞懂大模型的基本原理和行业版图。阅读2到3篇高质量大模型科普文章不需要啃论文。建立一个术语表记录Token、幻觉、上下文窗口、RAG、Agent、微调、模型部署等概念。梳理AI产品的主要赛道对话助手、知识库问答、内容生成、审核、数据分析等。产出物自己的术语表能用自己的话解释每一个词。8.2 第2天动手调API任务完成一次真实的模型调用。按照本文第3章的示例跑通一次Chat Completions接口。修改temperature、max_tokens观察返回变化。记录不同参数下消耗的Token差异建立成本体感。产出物一个能运行的调用脚本一份参数观察笔记。8.3 第3天跑通RAG任务做一个最小可用的知识库问答。准备一份几十页的业务文档或者公开的说明文档。使用现成的RAG框架或平台实现“上传文档→提问→带依据回答”。测试不同提问方式记录哪些问题答得好哪些答不好。产出物一个最小RAG问答原型一份效果观察记录。8.4 第4天理解Agent任务理解Agent的运行机制和边界。阅读Agent相关技术文章或案例。在Agent平台上搭一个最简单的自动化流程比如“接收输入→调用工具→返回结果”。分析一个真实Agent案例中任务规划、工具调用、失败回退分别是怎么设计的。产出物一个Agent流程Demo一份边界分析笔记。8.5 第5天学习评测任务给第3天的RAG产品做一次评测。整理20条评测问题覆盖正常、边界、恶意输入。设计3个评价维度人工打分。尝试用自动评测脚本辅助打分。产出物一份包含20条样本、3个维度的评测表。8.6 第6天完成模拟项目任务选一个真实场景完成“需求方案评测”闭环。场景可以选择企业知识库助手、客服智能辅助、内容摘要、审核辅助等。写一份简版PRD内容包括用户任务、模型方案、评测方案、兜底设计。结合前几天的实践给出技术选型理由。产出物一份模拟项目的PRD和评测方案。8.7 第7天整理作品集任务把一周成果整理成可展示的材料。写一篇项目复盘文章把背景、方案、效果、问题放进去。准备面试中可能被追问的问题尤其是“为什么这样设计”“这个方案的成本和风险是什么”。产出物一份项目案例一套面试问答清单。这个路线看起来任务量不轻但每天的核心不是“看很多内容”而是“动手完成一个具体产出”。如果你已经有项目经验可以把第6天和第7天的时间合并重心放在整理和输出上。需要提醒的是一周只能帮你建立框架真正从“懂概念”到“能做产品决策”至少需要完整参与一两个真实项目。所谓“一周变大神”在技术岗位里不现实也不值得追求。9. 常见误区与避坑清单下面这些误区和避坑建议来自AI产品实战中比较常见的问题。参考表格也可以对照自己的项目逐条检查。常见误区实际影响正确做法把提示词当万能钥匙业务一复杂提示词撑不住结合RAG、Agent、人工兜底只关注模型选型忽略数据模型能力再好也难适配业务优先搭建评测集和知识库把Agent当完全自动化工具调用失败时风险难以控制设计人工介入、限流、回退机制忽略Token成本上线后成本失控无法收敛上线前估算单次成本预设监控阈值不做灰度直接全量模型效果波动直接影响用户体验小流量灰度准备快速回滚方案用生产数据直接测试存在数据安全与合规风险评测数据脱敏遵循最小权限原则评测集一成不变模型迭代后回归盲区持续回收badcase定期扩充评测集忽略了模型升级的影响上游模型升级后效果回退每次切换前跑评测集回归这里挑一个重点展开成本和评测失控是最容易拖垮AI项目的问题。先说成本。很多团队最初只验证了一个小Demo没有计算全量用户、高频调用的情况。等上线后Token账单超出预期产品才被迫降级。正确做法是产品经理在评审阶段就要求提供单次回答的Token消耗估算并按日活用户、平均调用次数算出月度成本区间再决定是否要做缓存、限流或轻量化模型。再说评测。如果模型升级了Prompt优化了知识库换了一批文档但评测集还是原来那二三十条老问题那就很难发现新引入的badcase。评测集应该跟着项目成长每次升级前后都回归一遍。这个习惯一旦养成项目越到后期决策效率越高。还有一点容易被忽略不要所有事情都让模型做。很多场景比如固定格式的校验、精确计算、权限判断传统代码做得又快又准又便宜。AI产品经理要学会判断“这里到底需不需要模型”而不是“哪里有模型往哪里塞”。10. 总结与下一步行动这篇内容想表达的核心观点可以汇总成一句话AI产品经理的核心竞争力是把模型能力翻译成产品需求的能力以及把产品需求翻译成技术评审问题的能力。为了支撑这个能力需要三条线并行修炼技术理解线会调API、理解Token、理解RAG和Agent的核心机制。产品设计线定义能力边界、设计兜底方案、制定上线与灰度策略。评测迭代线建评测集、跑回归、分析badcase、控制成本。如果你刚准备转行或者已经在做AI产品但感觉思路不清晰建议从下面三个动作开始跑通一次真实模型调用哪怕只是调用API打印一句话。给手头产品整理出第一版评测集不用多20条就够。找一个具体场景把“需求→方案→评测→兜底”完整走一遍然后整理成作品集。市面上关于AI产品经理的教程和课程很多数量不是关键真正拉开差距的是你有没有动手验证过。与其囤一堆资料不如先把自己手头的第一个小项目做完把第一次评测跑出来。这个过程跑通了后面的路会顺畅很多。