这几年大模型相关的产品岗位越来越多不少公司的 JD 里直接写着懂大模型基础、能设计 AI 功能。后台也经常收到类似问题不懂算法、没写过代码能不能转 AI 产品经理七天真的能从零基础到入门吗先说结论能入门但不能只靠看视频真正有效的方式是把学习拆成每天可执行的任务边学边做边输出。这篇文章就是围绕七天学习路线来写的会给出每天的学什么、做出什么、避开什么同时提供一套可以直接套用的提示词模板和最小验证 Demo适合零基础转岗、传统产品经理转型也适合已经在做 AI 功能但想补全方法论的人。1. AI 产品经理到底做什么和普通产品经理有什么不同进入学习路线之前先把概念讲清楚。AI 产品经理并不是一个全新的岗位它仍然是产品经理只不过产品形态从纯逻辑的软件界面变成了由模型能力驱动的智能应用。传统产品经理的核心工作是梳理用户需求、设计功能流程、规划页面交互、跟进研发上线。AI 产品经理的工作多了一个非常关键的部分判断模型能不能做、做到什么程度、效果怎么衡量。也就是说AI 产品经理不只要设计功能还要设计模型输入、数据来源、输出格式、兜底策略这条链路。我见过不少传统产品经理第一次接手 AI 项目时习惯性地写一版很完整的 PRD把按钮、页面、状态流转定义得清清楚楚但一说到如果模型答错了怎么办准确率目标定多少冷启动数据从哪里来就答不上来。这正是 AI 产品经理和普通产品经理的主要差异普通产品经理面对的是确定逻辑AI 产品经理面对的是概率结果。从行业现状来看企业里的 AI 产品岗位大致有几种方向面向 C 端的对话助手、面向 B 端的知识库问答、内容生成工具脚本、图片、视频、Agent 自动化流程工具等。虽然场景不同但底层能力是相通的理解大模型的能力边界、设计提示词、搭建知识库检索、规划模型评测、持续迭代数据。这也是七天学习路线会重点覆盖的内容。2. 零基础入门前的四个准备2.1 调整认知AI 产品是概率产品第一步不是学工具而是调整预期。传统软件只要测试用例通过了功能就是稳定的但大模型生成的内容具有随机性同一个问题问两次答案可能不一样甚至可能出错。AI 产品经理必须接受一个现实你的产品永远存在一定的错误率关键是把它压到可接受范围并设计兜底机制。所以学习过程中不要追求模型绝对正确而要学会量化正确到什么程度。这是 AI 产品经理和传统产品经理在思维方式上最大的分水岭。2.2 技术知识清单最少必要知识零基础不需要先啃机器学习公式但以下概念要有基本认知Token大模型处理文本的基本单位简单理解为字的切片中英文消耗不一样。上下文窗口模型一次能接收的最大输入加输出长度超出的内容会被截断或报错。Prompt你给模型的指令提示词工程就是研究如何写出更稳定的指令。幻觉模型生成看似合理但实际错误的内容是所有 AI 产品都必须面对的问题。RAG检索增强生成先从知识库中检索相关资料再把资料交给模型生成答案用来补充私有知识、降低幻觉。Agent让模型根据目标自动拆解任务、调用工具、迭代执行的过程。Fine-tuning微调用业务数据进一步训练模型通常比 RAG 重一般有大量高质量数据时才考虑。这些概念不用一次学透第七天之后你会发现它们都会落到具体场景里。2.3 工具与账号准备学习阶段最常用的工具是三家对话型大模型平台、API 调用平台、提示词测试工具。对话平台用于日常体验和 Prompt 练习建议至少选择两个不同风格的模型交替测试因为不同模型的指令理解能力差异较大API 平台用于跑最小 Demo例如调用大模型接口完成一次问答提示词测试工具可以简单用 Excel 或飞书文档管理测试用例不一定要花钱买专用工具。注册时要注意三点第一优先选择你所在网络环境下可以正常访问、合规使用的平台不要折腾任何非常规访问方式第二注意平台免费额度和速率限制学习阶段通常够用第三涉及真实企业数据时使用企业私有化部署或获得授权的云端环境不要用个人账号上传敏感信息。2.4 资料整理方法建议建一个AI 产品学习库文件夹里面放三类材料产品案例截图、Prompt 测试记录、行业文章链接。每周做一次整理把我看过变成我能讲清楚。这一步看起来简单但会在面试时发挥巨大作用因为面试官最常问的不是你背了多少概念而是你亲手做过什么、踩过什么坑。3. 七天学习路线从认知到项目落地下面按天拆解学习计划每天的内容大概需要 2 到 3 个小时。前三天以输入为主后四天以输出和实战为主。3.1 Day 1建立大模型的产品化认知第一天的目标是回答三个问题大模型能做什么、不能做什么、怎么做才赚钱。上午用一个小时集中体验 5 到 10 个主流 AI 产品包括通用对话助手、AI 写作、AI 绘图、AI 视频生成、智能客服等。体验时不要只当用户要带着问题这个产品解决了什么场景的什么问题如果模型效果变差用户会怎么感知产品经理在这个产品里做了哪些关键决策下午的任务是构建能力边界清单我建议用表格整理任务类型当前模型表现适合做产品吗风险点摘要总结较好适合长文档上下文可能溢出数学计算不稳定谨慎幻觉严重必须校验客服问答较好适合做辅助需要知识库支撑实时数据分析一般不适合直接生成接入数据工具后才有价值完成这张表你会比很多只看技术文章的人更理解 AI 产品化的机会在哪里。3.2 Day 2提示词工程入门提示词是 AI 产品经理最基础也最重要的技能。第二天的目标是写出稳定可用的系统提示词。先掌握提示词的四要素角色设定、任务说明、约束条件、输出格式。一个常见示例角色你是一名专业的客服助手服务于某电商平台的售后场景。 任务根据用户描述判断售后类型仅限退货、换货、退款、维修并说明所需材料。 约束 1. 只使用知识库中提供的信息不要自行编造。 2. 如果信息不足明确回答“需要补充订单号或商品信息”。 3. 语气友好简洁单次回复不超过100字。 输出格式 类型xxx 所需材料xxx 下一步操作指引xxx这一天至少要测试 10 个不同场景的 Prompt并记录每个模型的回复差异。改写 Prompt 时每次只改动一个变量这样你能清楚知道是哪个词影响了效果。这一步做完你会建立对模型随机性最直观的体感。3.3 Day 3AI 产品需求分析与 PRD 撰写第三天进入产品经理主战场。AI 产品的 PRD 和普通 PRD 不一样除了功能逻辑还要增加模型策略章节。建议使用如下结构1. 背景与目标 2. 用户场景含种子用户画像 3. 核心功能流程 4. 模型策略 - 所选模型及理由 - 系统提示词设计 - 输入校验与预处理 - 输出解析与后处理 - 降级方案模型不可用时怎么办 5. 数据需求 - 冷启动数据来源 - 知识库维护方式 6. 效果评估标准 - 目标指标 - 评测集设计 - 通过标准 7. 风险与合规你可以选一个熟悉的业务场景写一份简版 AI 产品 PRD。不求完美但要把模型策略和数据需求写清楚因为这是普通产品经理容易忽略、而 AI 产品面试官一定会追问的部分。3.4 Day 4RAG 与知识库产品第四天学习 RAG这对于企业知识库问答、客服助手、制度查询类产品来说几乎是必备能力。你需要理解 RAG 的四个环节知识切分、向量化、检索、生成。知识切分是把大文档切成小块向量化是把文本转成模型能计算的向量检索是找到与问题最相关的内容生成是把检索结果交给大模型让它基于这些内容作答。学习方式建议先用现成的 RAG 平台体验一遍文档上传、导入、测试的完整流程然后自己动手整理一份常见问题清单加入知识库观察模型回答是否更准确。你不需要手写向量检索算法但必须理解知识库质量决定回答质量这个结论——如果有 30% 的检索结果是无关内容模型再强也答不好。3.5 Day 5Agent 与工具调用Agent 是当前 AI 产品最有想象力的方向之一。第五天重点理解三个概念规划任务拆解、工具调用通过函数获取实时数据或执行动作、记忆多轮对话中保存关键信息。学习时找一个具体场景比如让 AI 根据用户预算推荐手机让它先问你几个问题然后调用商品查询工具再生成对比表格。作为产品经理你的核心任务不是写工具函数的代码而是画出Agent 的决策流程并思考它在什么条件下会失败。这里有一个重要的边界意识Agent 产品目前在复杂任务上仍然不够稳定产品设计时应加入人工确认环节而不是让 Agent 端到端全自动执行高风险操作。3.6 Day 6效果评估与迭代第六天学习评估。AI 产品的难点不是开发而是怎么证明它做得够好。你需要构建一个最小评测集至少 20 条覆盖典型场景、边界场景、易错场景的测试问题然后对每条回答打分正确1 分、部分正确0.5 分、错误0 分。早期也可以借助大模型自动评测但只能做初筛涉及关键业务必须人工抽检。评估之后要能制定迭代方向如果错误主要是知识不足优先扩充知识库如果错误是理解不了用户问题需要优化提示词或增加意图识别如果是输出格式混乱则要加后处理解析规则。要记住AI 产品的迭代不是靠拍脑袋感觉得出的而是靠每次改版前后跑同一套评测集的分数差值来证明。3.7 Day 7综合实战与作品输出最后一天把前六天的成果整合成一个小作品推荐选题是企业制度问答助手或商品评论总结工具。完成以下交付物一份 1 到 2 页的 AI 产品 PRD、一套系统提示词、一个可运行的最小 Demo哪怕只有命令行交互、一份包含 20 条测试用例的评测记录、一份迭代优化清单。这份作品是你接下来面试最好的敲门砖。它比任何我学过 XXX的表述都更有说服力因为它完整证明了你的思考、落地和复盘能力。4. 动手实战设计一个企业制度问答 AI 助手下面用一个完整案例演示从需求到验证的闭环零基础也可以照做。4.1 需求定义假设场景某公司员工日常有大量关于考勤、报销、年假的制度问题HR 团队反复回答同一类问题效率低。产品目标是做一个企业制度问答助手员工输入问题助手基于制度文档回答并附上原文出处链接。核心业务流程分三步员工提问 → 系统在制度库中检索相关内容 → 大模型生成答案。冷启动制度文档来自 HR 提供的 PDF 和 Word先转成 Markdown 或纯文本再按章节切分为知识片段。4.2 编写系统提示词系统提示词是对话助手的人设和规则我提供一个可复用的模板你是一个企业内部的制度问答助手只能基于下方的参考资料回答问题。 参考资料 {{knowledge}} 规则 1. 如果参考资料中包含答案用 2 到 3 句话简洁作答并在末尾注明引用片段编号。 2. 如果参考资料中没有答案明确说“制度库中暂未找到相关信息请联系 HR 确认”不要猜测。 3. 不要输出法律意见不要评价制度是否合理。 4. 回答使用简体中文不要使用 Markdown 表格除非用户明确要求。这里的 {{knowledge}} 是知识检索结果。你会发现这个提示词把边界和兜底写得很清楚模型不会因为诱导而强行编造。4.3 用 Python 搭建最小验证 Demo作为产品经理你不需要写很复杂的代码但至少要能读懂和运行一个最小 Demo。下面以通用的 OpenAI 兼容接口为例实际使用时替换成你所在平台的 API 地址和密钥。 文件路径demo_ai_qa.py 功能说明简化版制度问答助手使用请求库调用大模型接口配合本地知识片段完成问答。 使用方法设置好 API_KEY、API_URL、MODEL_NAME 后运行 python demo_ai_qa.py import requests API_KEY your_api_key API_URL https://your_api_endpoint/v1/chat/completions MODEL_NAME your_model_name # 模拟从知识库中检索到的片段 knowledge_base [ 【片段1】公司实行标准工时制工作时间为周一至周五 9:00-18:00。, 【片段2】入职满一年的员工每年享有 5 天法定年假司龄每增加一年增加 1 天上限 15 天。, 【片段3】报销申请应在费用发生后 30 天内提交逾期需提交书面说明。, ] def retrieve(query): 简化版检索通过关键词匹配返回最相关的两个片段。 matched [] for i, text in enumerate(knowledge_base, start1): for keyword in query: if keyword in text: matched.append(f【片段{i}】{text}) return matched[:2] def ask_llm(user_query, knowledge): system_prompt f你是一个企业内部的制度问答助手只能基于下方的参考资料回答问题。 参考资料 { .join(knowledge)} 规则 1. 如果参考资料中包含答案用2-3句话简洁作答并在末尾注明引用片段编号。 2. 如果参考资料中没有答案明确说“制度库中暂未找到相关信息请联系 HR 确认”不要猜测。 3. 不要输出制度合理性评价。 payload { model: MODEL_NAME, messages: [ {role: system, content: system_prompt}, {role: user, content: user_query}, ], temperature: 0.2, } resp requests.post(API_URL, headers{Authorization: fBearer {API_KEY}}, jsonpayload) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: query 新员工年假有几天 knowledge retrieve(query) if not knowledge: print(未检索到相关资料请确认问题或补充知识库。) else: answer ask_llm(query, knowledge) print(问题, query) print(回答, answer)这个 Demo 做了两个关键事情先检索再生成。它把知识缺失和模型幻觉分开处理让产品经理能清晰看到链路中哪个环节出了问题。实际项目中你还要做更多优化比如向量检索、切分策略、多路召回但思路是一致的。4.4 定义验收标准与评估集不要等产品做完了才想怎么评估第一版就要写清楚验收标准。我建议用三类标准回答准确率、知识覆盖率、兜底正确率。准确率指正确回答占评测问题总数的比例覆盖率指制度库中能回答的问题比例兜底正确率指当制度库确实没有答案时模型能正确拒绝回答的比例。20 条测试题中至少要包含 10 条正常问题、5 条信息缺失问题、3 条模糊表达问题、2 条诱导性问题。4.5 分析结果并形成迭代清单跑完测试后把每条错误归类到三个环节知识库问题没检索到、片段切分错误、提示词问题角色约束不够、驳回话术不清、模型问题理解偏差、格式错误。我通常会留下一份迭代优先级清单先解决高频且影响大的问题再解决低频边缘问题。例如如果 60% 的错误来自知识库缺失就不要急着换更大参数模型而是先补齐知识片段并优化切分方式。这个习惯能让产品快速收敛。5. 常见问题与排错指南新手做 AI 产品最容易遇到下面 6 类问题我整理成排查表建议收藏备用。问题现象常见原因解决思路答案频繁出错出现幻觉知识源缺失或模型被诱导接入 RAG增加知识片段调低 temperature回答风格时好时坏提示词约束不够加入角色、语气示例、固定输出格式上下文一长就报错超过模型最大 Token截断历史消息只保留关键上下文或摘要用户问题稍偏就答非所问缺少意图识别或关键词检索单一增加意图分类检索改为向量检索效果时好时坏无法判断没有固定评测集维护 20 条以上测试用例每次改版回归涉及敏感数据时不敢用合规边界不清晰先做数据脱敏确认加密和访问权限必要时私有化针对第一类幻觉问题还有一个很实用的技巧在提示词里强制模型引用来源编号当模型找不到可靠依据时它会倾向于拒绝回答而不是编造。你可以在测试时把 temperature 调整到 0 到 0.3 之间降低输出的随机性。6. 面试与求职准备6.1 简历怎么突出 AI 项目如果你没有专职 AI 产品经验可以用传统产品 AI 改造的思路写简历而不是只写熟悉大模型。例如你说负责客服工单产品梳理高频问题 50 类设计 RAG 知识库问答助手使人工回复时长缩短 30%就比了解 RAG 原理更有说服力。简历里建议包含以下要素业务场景、你做的关键决策、模型的输入输出链路、评测指标、迭代结果。哪怕数据是从 20 条测试题里得出的也比没有任何数据强。6.2 高频面试题梳理了几个高频问题你如何选择用 RAG 还是 Fine-tuning请设计一个基于大模型的智能客服产品你会怎么做如何评估一个 AI 产品的效果如果模型回答出现幻觉你怎么排查和解决模型输出延迟较高产品层面有什么缓解方案你的产品如何保障数据合规和用户隐私回答时不要只背概念要结合一个小案例把思路讲清楚。面试官更想看到的是你能把技术和业务连起来而不是你背熟了多少名词。6.3 笔试与作品集建议有些公司会让你现场设计一个 AI 功能。建议按四步走先写用户场景再画功能流程再说明模型策略和数据方案最后给评估指标。如果能当场演示一份你自己写的 PRD 或 Prompt 测试记录会显著加分。7. 零基础避坑少走 99% 弯路的 5 条原则第一条不要先学大而全的算法理论。机器学习基础可以以后补但如果你花两周推公式可能早就把学习热情消耗完了。先学产品化链路遇到问题再回头补技术细节。第二条不要只收集文章不产出实物。看 10 篇 RAG 教程不如自己搭一次 Demo。产出物可以是提示词记录、PRD、测试清单任何能证明你思考过的东西都算。第三条不要盲目追求复杂模型。很多场景用商用大模型 API 就够了不需要私有化训练。产品经理做技术选型时成本和维护成本也是重要指标。第四条不要把模型当确定性工具。所有 AI 产品都要有兜底方案人工接管、超时提示、二次确认、答案来源公示。这些兜底逻辑越早设计后期越省心。第五条不要忽略数据合规。涉及企业内部资料或个人隐私时先确认使用场景是否获得合法授权再谈产品效果。AI 产品的合规成本必须在方案评审阶段就纳入考量。8. 学习路线总结与下一步七天学习完成后你应该具备几个结果能独立拆解一个 AI 产品的模型策略能写出结构完整的 AI 产品 PRD能搭建最简单的检索 生成验证链路能构建评测集并有理有据地分析模型表现。这些能力已经足够支撑你参与真实项目或在面试中展示作品。下一步有两个方向如果你更偏产品业务可以深入研究某个垂直场景比如 AI 客服、AI 电商、AI 视频工具如果你希望补技术深度推荐继续学向量数据库、微调基础、Agent 工程实践。AI 领域变化很快但没有一种变化会绕过产品经理对真实需求和用户价值的判断持续做项目、留记录、复盘迭代永远是这个岗位最可靠的成长方式。