2026年AI产品经理转行指南：6周掌握大模型、RAG与Agent-平芜编程栈

如果你正准备转行 AI 产品经理，或者在普通产品经理岗位上想往 AI 方向靠拢，那么这篇文章值得认真看完。2026 年的招聘市场里，AI 产品经理已经不是一个笼统的岗位概念，而是被拆分成了多个细分方向：大模型应用产品经理、AI Agent 产品经理、多模态产品经理、AI 中台产品经理、以及面向具体行业的 AI 解决方案产品经理。岗位需求增长快，但门槛也比传统产品经理高了不少。

我在学习和面试这个方向的过程中，最大的感受是：AI 产品经理并不是“懂一点 AI 术语”就能胜任的岗位，它要求你同时具备产品基本功、技术理解力、数据评估能力和项目管理能力。网上关于 AI 产品经理的资料非常零散，很多文章只讲概念，不讲落地方法；还有一部分课程把 AI 产品经理包装成“只要会聊天就能做”的岗位，这其实严重误导了新人。

这篇文章想做的事情很明确：围绕 2026 年 AI 产品经理的核心要求，给你整理一份可执行的 6 周学习路线，拆解能力模型，梳理必须掌握的技术知识，并结合实际行业案例说明 AI 产品经理到底在做什么。无论你是零基础转行，还是已经在产品岗位想升级，都可以跟着这份路线走一遍。

1. 背景与核心概念

1.1 什么是 AI 产品经理

AI 产品经理，本质上是“以人工智能技术为核心能力来设计产品”的产品经理。和传统产品经理相比，AI 产品经理需要思考的问题更复杂：模型能力边界在哪里、数据从哪里来、效果如何评估、失败如何兜底、成本如何控制。

用一个例子来说明。

传统电商搜索产品经理，只需要关注关键词匹配、排序策略、点击率、转化率。但如果你做一个基于大模型的智能导购，你要考虑的是：用户提问如何被理解、模型有没有幻觉、推荐的商品是否合规、回答延迟是否能控制在 2 秒内、如果模型给出错误信息应该怎么处理。这些问题的复杂度，远超传统“输入关键词-返回结果”的逻辑。

所以 AI 产品经理的核心能力，可以概括成一句话：把 AI 技术能力转化为用户可感知的产品价值。这句话听起来简单，但做起来很难。

1.2 AI 产品经理与传统产品经理的区别

为了更直观地理解，我整理了一个对比表格：

维度	传统产品经理	AI 产品经理
核心技能	需求分析、原型设计、项目管理	需求分析 + 模型评估 + 数据分析 + 技术理解
技术关注点	接口、数据库、前后端逻辑	模型选型、Prompt、RAG、Agent、微调、幻觉控制
产品形态	确定性逻辑	概率性输出，需要兜底策略
迭代方式	版本迭代	数据反馈驱动 + 模型版本更新
成功标准	功能上线、用户量、转化率	输出准确率、任务完成率、成本控制、用户满意度

这里最核心的差异是“确定性”和“概率性”。传统软件产品的逻辑是确定的：用户点击 A 按钮，必然触发 B 事件。但 AI 产品不同，模型输出是概率性的，同一个问题在不同时间可能给出不同答案。这就要求 AI 产品经理在设计产品时，必须考虑“模型出错怎么办”，而不是假设模型永远正确。

1.3 AI 产品经理的常见应用场景

2026 年，AI 产品经理的工作场景已经渗透到很多领域：

智能客服与对话系统：自动回答用户问题、处理售后工单、辅助人工客服。
AI 内容创作工具：文案生成、图片生成、视频脚本生成、社媒运营辅助。
企业知识库问答：基于内部文档的智能检索、员工培训、合规查询。
AI Agent 自动化流程：自动写周报、自动整理邮件、自动填报系统数据。
智能数据分析：自然语言查数、报表自动生成、异常数据预警。
行业垂直应用：医疗辅助问诊、金融风控报告、法律文书审查。

每一个场景背后，AI 产品经理都需要深入理解业务痛点，再结合大模型能力设计解决方案。这也意味着，AI 产品经理不能只懂产品方法论，还必须具备快速理解行业业务的能力。

2. 环境准备与学习计划制定

2.1 转行 AI 产品经理需要什么基础

很多人关心：我没有技术背景，能做 AI 产品经理吗？

我的回答是：可以，但前提是你要补齐足够的技术常识和数据分析能力。AI 产品经理不需要像算法工程师那样能手写 Transformer 模型，但你必须能在技术评审会上听懂对方在说什么，能自己调试一个 API，能看懂模型评估指标。

以下是 2026 年 AI 产品经理需要具备的基础能力清单：

产品基本功：需求调研、用户分析、竞品分析、PRD 撰写、原型设计、项目管理。
技术理解力：大模型基础原理、API 调用方式、Prompt 工程、RAG 原理、Agent 工作流、模型微调的基本概念。
数据能力：数据分析基础、埋点设计、A/B 测试、模型评估指标（准确率、召回率、人工评估）。
AI 工具使用：ChatGPT、Claude、Kimi、百度文心一言、通义千问等大模型产品的日常使用能力。
行业理解：至少选择一个垂直行业深入理解业务逻辑，比如电商、教育、金融、医疗。

2.2 2026 版 6 周学习计划

接下来是本文的核心内容之一：6 周学习计划。这份计划是我根据自己的学习经历和实践项目总结而来的，适合每天投入 2 到 3 小时的人，如果时间充足可以压缩到 4 周。

周次	学习主题	核心内容	产出物
第 1 周	AI 产品经理认知与行业梳理	了解 AI 产品经理岗位职责、能力要求、行业赛道，梳理目标岗位	一张岗位能力差距分析表
第 2 周	大模型技术基础	大模型原理、API 调用、Prompt 基础、模型能力边界	一个能调用大模型 API 的小脚本
第 3 周	Prompt 工程与对话设计	Prompt 设计方法、上下文管理、系统提示词、对话流程设计	一个完整 Prompt 模板库
第 4 周	RAG 与知识库应用	向量化、召回、重排、知识库问答原理、评估方法	一个知识库问答产品方案
第 5 周	Agent 与自动化流程	Agent 能力拆解、工具调用、工作流设计、应用场景	一个 Agent 产品设计文档
第 6 周	行业实践与作品集打造	选择一个垂直行业，完成一个 AI 产品方案并整理成作品集	一份可展示的 AI 产品方案

这份学习计划最大的特点，是从认知到实践层层递进。前两周解决“是什么”，中间两周解决“怎么做”，最后两周解决“如何证明你能做”。

2.3 学习工具与资源准备

在正式开始学习之前，建议提前准备好以下工具和账号：

一个大模型 API 账号（OpenAI、通义千问、智谱、百度千帆等，选一个即可）
一个支持 Python 的本地环境，推荐 Anaconda + Jupyter Notebook
一个文档笔记工具，用于沉淀自己的 Prompt 模板和产品想法
飞书文档（用于整理学习记录和作品集）
GitHub 账号（用于存储代码示例）

如果你对 Python 完全陌生，不用慌。AI 产品经理需要达到的 Python 水平是“能读懂、能改参数、调用 API 不报错”，不是让你写复杂算法。

3. 核心知识拆解：AI 产品经理必须掌握的技术概念

3.1 大模型的基本原理与能力边界

大语言模型（LLM）本质上是一个基于海量文本数据训练出来的概率模型。它的工作方式是：根据你输入的文本，预测下一个最可能出现的词，然后不断重复这个过程，生成完整回答。

AI 产品经理不需要深究 Transformer 的数学原理，但必须理解以下三个关键点：

第一，模型是一个“续写器”而不是“数据库”。它并不像搜索引擎那样查到你需要的答案，然后原样返回。它是根据训练时学到的语言规律“编造”一个合理的回答。这就解释了为什么模型会产生幻觉——当它不理解某个问题时，它依然会给出一个听起来合理的答案。

第二，模型的上下文窗口是有限的。无论模型支持多长的上下文，产品设计时都要考虑 token 成本和使用体验。一个产品如果每次都把 10 万字文档塞进 Prompt，不仅速度慢，成本也会爆炸。

第三，模型的输出质量依赖 Prompt 质量。同一个模型，用不同的提示词，输出结果可能是天壤之别。这既是挑战，也是 AI 产品经理最大的发挥空间。

下面是一个最基础的 API 调用示例，后续学习中的很多产品原型都从这里开始。

# 文件路径：demo/llm_basic_call.py # 使用 openai 库调用大模型 API，key 请替换为你的真实 key from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://api.openai.com/v1" ) response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一位专业的产品经理助理，回答要简洁、准确、结构化。"}, {"role": "user", "content": "请列出 AI 产品经理需要具备的 5 项核心能力，每项用一句话解释。"} ], temperature=0.7 ) print(response.choices[0].message.content)

这个示例演示了三件事：

如何通过 API 与大模型交互。
如何通过 system prompt 设定模型角色。
如何通过 user message 传递用户问题。

AI 产品经理在做原型验证时，经常会写类似的脚本。所以即使你不是程序员，也建议亲手跑通这段代码。

3.2 Prompt 工程：AI 产品经理的基本功

Prompt 工程是设计输入给大模型的提示词，以引导模型输出符合预期结果的方法。对于 AI 产品经理来说，Prompt 不只是“写提示词”，而是产品交互设计的延伸。

一个高质量的 Prompt 通常包含以下要素：

角色设定：告诉模型“你是谁”。
任务描述：告诉模型“要做什么”。
上下文信息：给模型提供需要的背景材料。
输出格式要求：规定模型以什么格式输出。
示例（Few-shot）：给模型演示一个输入输出例子。

来看一个对比示例。假设我们要做一个招聘 JD 生成工具。

低质量 Prompt：

帮我写一个产品经理的招聘JD。

高质量 Prompt：

你是一位专业的 HR 顾问。请根据以下要求撰写一份产品经理招聘 JD： 1. 岗位方向：B 端 AI 产品经理，负责企业知识库产品的规划与落地。 2. 要求：3 年以上产品经验，熟悉大模型应用、RAG 原理，有智能客服项目经验者优先。 3. 输出格式：包含岗位职责（5条）、任职要求（5条）、加分项（3条）。 4. 语气：专业、有吸引力，不要使用夸张形容词。

可以看到，高质量的 Prompt 提供了角色、任务、限制条件和格式要求，得到的输出质量会明显更高。

这里也辟谣一个常见误区：很多教程说 Prompt 工程会被 AI 自动优化取代，产品经理不需要学。这个观点在纯对话场景下有一定道理，但在复杂产品中，Prompt 的稳定性、上下文管理、多轮对话记忆、成本控制，依然需要产品经理认真设计。

3.3 RAG：让模型基于你的知识库回答问题

RAG 全称是 Retrieval-Augmented Generation，检索增强生成。简单来说，它的思路是：当用户提问时，先从知识库中检索相关文档片段，再把检索到的内容和大模型的生成能力结合起来，最终输出答案。

RAG 为什么重要？因为大模型的知识只停留在训练时点，无法知道你的企业内部资料、最新政策、私有产品文档。RAG 是当前让大模型“私有化”“实时化”的最主流方案，也是 AI 产品经理面试的高频考察点。

RAG 系统的工作流程可以分成四步：

离线建库：把文档切分成小块，用 Embedding 模型转成向量，存入向量数据库。
在线召回：用户提问时，把问题也转成向量，在向量数据库中找出最相关的 Top K 文档片段。
内容注入：把检索到的文档片段注入到 Prompt 中，让模型基于这些内容生成回答。
答案生成与引用：模型输出答案，并附上引用来源。

一个完整的 RAG 产品方案中，AI 产品经理至少需要关注以下指标：

检索召回率：正确的知识有没有被检索到。
回答准确性：模型有没有忠实于检索到的文档。
幻觉率：模型有没有编造知识库之外的内容。
响应延迟：从提问到返回答案需要多长时间。

下面是一个简化的 RAG 流程伪代码，用于理解产品逻辑：

# 文件路径：demo/rag_flow_demo.py # 说明：这是一个 RAG 流程的概念示意，真实项目需配合向量数据库和 Embedding 服务 def rag_answer(question, vector_db, llm_client): # step 1: 用户问题向量化 question_embedding = embed_text(question) # step 2: 从向量数据库检索相关文档片段 retrieved_chunks = vector_db.search(question_embedding, top_k=3) # step 3: 拼接上下文和 prompt context = "\n---\n".join([chunk.text for chunk in retrieved_chunks]) prompt = f""" 请基于以下知识库内容回答问题。 如果知识库中没有相关信息，请直接说“根据现有资料无法回答”，不要编造。 【知识库内容】 {context} 【用户问题】 {question} """ # step 4: 调用大模型生成回答 response = llm_client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}] ) return response.choices[0].message.content

这个伪代码展示了 RAG 的核心逻辑。AI 产品经理不需要自己实现向量检索算法，但必须理解每一环节的输入输出，以及每个环节可能出现的失败点。

3.4 Agent：AI 产品经理的未来方向

如果说大模型是“大脑”，RAG 是“记忆”，那么 Agent 就是“手和脚”。Agent 的核心能力是让模型自主规划任务、调用外部工具、完成多步操作。

一个 AI Agent 的基本工作流程是：

接收用户目标。
拆解任务为多个步骤。
对每一个步骤，决定是调用工具（如搜索、API、代码执行）还是直接使用模型回答。
汇总各步骤结果，输出最终答案。

举一个 AI Agent 的典型场景：智能周报助手。

用户只需要说“帮我生成本周工作周报”，Agent 会自动完成以下操作：

调用日历 API，查看本周日程。
调用项目管理系统 API，查看本周完成的任务。
调用文档工具，整理关键产出。
使用大模型生成结构化周报草稿。
推送到企业微信/飞书供用户确认。

对于 AI 产品经理来说，设计 Agent 产品时要重点思考：

用户的目标是什么，Agent 需要拆成几步。
每一步需要调用什么工具，工具失败怎么办。
中间结果是否需要用户确认。
如果 Agent 偏离目标，如何兜底。

Agent 产品设计最大的挑战，是不可控性。因为 Agent 的执行路径是模型自主决策的，同一个请求可能产生不同的行为路径。产品经理需要通过设计约束条件，把这种不可控性控制在可接受范围内。

4. 完整实战案例：设计一个企业知识库问答助手

这一节我们把前面学到的内容串起来，完成一个完整的 AI 产品实战案例。案例背景是：某公司每天产生大量内部通知、产品文档、培训资料，员工经常找不到相关信息，HR 部门每天要重复回答大量问题。我们需要设计一个企业知识库问答助手。

4.1 需求分析

在写任何代码之前，先做需求分析。AI 产品经理与普通产品经理的区别体现在这里：不仅要描述用户需求，还要评估 AI 能力是否匹配。

核心用户需求清单：

员工输入问题，能快速找到公司内部制度和操作手册。
回答需要附上引用来源，方便员工核对原文。
对于不确定的问题，系统要明确说“不知道”，不能编造。
支持上班时间内的快速响应。

4.2 技术方案选择

基于需求，可以确定技术方案：

文档预处理：PDF、Word、Markdown 文档统一转为文本。
文档切分：按标题或固定长度切块，添加 metadata 记录来源路径。
向量化：使用 Embedding 模型将文本块转为向量。
向量存储：使用 Chroma 或 Qdrant 作为向量数据库。
召回：用户问题向量化后检索 Top 5 文本块。
生成：将检索结果注入 Prompt，调用大模型生成回答。
UI 界面：可先用 Streamlit 搭建原型。

下面是知识库问答助手的完整技术流程图（文字版）：

用户提问 → 问题向量化 → 向量数据库检索 → 检索 Top 5 文档块 → 注入 Prompt → 调用大模型 → 输出答案 + 引用来源

4.3 编写核心代码

实际项目中，AI 产品经理通常不需要从头写完整代码，但需要具备“能用代码跑通原型验证”的能力。下面是一个基于 Streamlit + Chroma 的知识库问答原型。

# 文件路径：qa_assistant/app.py # 说明：企业知识库问答助手原型，使用 Streamlit 搭建界面 import os import streamlit as st from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA st.title("📚 企业知识库问答助手") st.write("上传你的公司文档，然后开始提问。") # 上传文件 uploaded_file = st.file_uploader("上传文档", type=["txt", "md"]) # 初始化向量存储 if uploaded_file is not None: # 保存临时文件 with open("temp_doc.md", "wb") as f: f.write(uploaded_file.getbuffer()) # 加载文档 loader = TextLoader("temp_doc.md", encoding="utf-8") docs = loader.load() # 切分文档 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 ) chunks = text_splitter.split_documents(docs) # 创建向量存储 embeddings = OpenAIEmbeddings() vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" ) # 创建问答链 llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.1) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), return_source_documents=True ) st.success("文档处理完成，可以开始提问。") # 问答交互 question = st.text_input("请输入你的问题：") if question: result = qa_chain({"query": question}) st.write("**回答：**", result["result"]) st.write("**引用来源：**") for source in result["source_documents"]: st.caption(source.page_content[:200])

这段代码需要安装的依赖如下：

pip install streamlit langchain langchain-openai langchain-community chromadb openai

4.4 运行与验证

在终端中执行以下命令启动原型：

cd qa_assistant streamlit run app.py

打开浏览器访问http://localhost:8501，上传一个文档，然后输入问题。预期效果是：系统能基于文档内容回答，并附上引用来源。

4.5 结果说明与产品化扩展

这个原型验证了三个关键点：文档切分是否有效、检索结果是否相关、模型回答是否忠实于资料。产品化时还需要考虑：

文档更新机制：文档变更后，向量库如何同步更新。
权限控制：不同角色能看到哪些文档，涉及合法授权问题。
成本控制：Embedding 调用量和 token 消耗的监控。
多轮对话：上下文管理机制，避免用户追问时丢失历史信息。
反馈收集：在回答下方增加“有帮助/没帮助”按钮，用于持续优化。

这里要特别强调：在真实企业场景中，知识库问答涉及大量内部资料，必须经过合规审批和权限隔离，不能随意上传到第三方大模型服务。早期最好采用私有化部署或和安全团队确认数据合规边界。

5. 常见问题与排查思路

在学习 AI 产品经理的过程中，我整理了一些高频问题和对应解决方案。

问题现象	常见原因	解决思路
模型回答经常编造内容	没有加限制性 Prompt，或 RAG 没有兜底机制	在 Prompt 中明确“没有资料就回答不知道”
API 调用报错	API Key 错误、余额不足、网络限制	检查 key 是否正确，确认服务是否可用
知识库检索结果不准确	文档切分不合理，或 Embedding 模型选择不合适	调整切分长度和 overlap，尝试不同 Embedding 模型
模型响应太慢	Prompt 太长、模型过大、检索环节耗时长	减少上下文长度、选择更快的小模型
用户连续追问时回答变差	没有管理多轮上下文	设计上下文清理和摘要机制
领导问“为什么这个回答错了”	缺少可解释性和日志记录	建立回答日志，记录问题、检索结果、生成结果

5.1 零基础转行最常见的心态误区

我发现很多转行 AI 产品经理的人，卡住的原因不是能力不够，而是策略不对。

第一个误区是“上来就学算法”。我一直认为，AI 产品经理不需要先学机器学习算法。你更应该先从“用”开始，把大模型产品用熟练，然后学 API 调用，再了解 RAG 和 Agent。如果你困在算法里，三个月后可能还在学数学，离产品岗位越来越远。

第二个误区是“只学技术不练产品”。很多人看完本文前面几节，可能会觉得“懂了”，但实际上不会写 PRD 里关于模型能力的限制说明。最好的学习方式是边学边做一个 Demo，并把它整理成作品集。

第三个误区是“追求新词，不追体系”。今天学 Agent，明天学多模态，后天学数字人。看起来在进步，但知识是碎片化的。建议大家照着第 2 节的 6 周学习计划走，先建立整体框架，再深入细节。

6. 最佳实践与工程建议

6.1 需求阶段就要想清楚模型是否必要

不是所有场景都需要大模型。有些需求用规则引擎、关键词匹配或者传统分类模型就能解决，强行上大模型会带来成本高、延迟高、不可控的问题。AI 产品经理的职责是选择最合适的技术方案，而不是为了“AI 而 AI”。

判断标准很简单：

业务是否需要理解复杂的自然语言。
业务是否需要生成非结构化内容。
业务是否允许概率性的输出结果。
成本预算是否支撑模型 API 调用。

如果四个问题的答案都是否，那就不适合用大模型。

6.2 建立模型评估体系

这是 AI 产品经理最不同于传统产品经理的地方。传统产品经理上线功能后，看用户数据和漏斗转化；AI 产品经理还要评估“模型效果”。

建议至少建立三层评估体系：

技术指标层：回答准确率、召回率、幻觉率、延迟。
用户行为层：任务完成率、使用次数、平均会话时长。
业务结果层：客服转人工率、用户自助解决率、满意度评分。

6.3 考虑成本与效率的平衡

大模型 API 的成本和学习成本是很多人忽略的。建议在产品初期做两件事：

第一，设置 token 用量预警。在调用日志中记录每次请求的输入输出 token 数量，分析哪些场景消耗最大。

第二，区分模型等级。简单任务使用小模型，复杂任务使用大模型。比如简单的分类和抽取可以用 gpt-4o-mini 或更轻量模型，复杂的方案生成再用高端模型。

我之前看到一个项目，把每个用户问题都发给最高配模型，结果单用户日均成本高出预期 10 倍。优化策略很简单：先做意图分类，再按不同的意图路由到不同模型。

6.4 规范化 Prompt 管理

在团队协作中，Prompt 也是代码资产，不能只存在于某个人聊天记录的草稿箱里。建议用版本管理来管理 Prompt：

每个 Prompt 有独立的命名和版本号。
记录 Prompt 的修改时间、修改人和修改原因。
维护一份 Prompt 评测集，每次修改后跑一遍回归测试。

以下是一个 Prompt 版本管理表格示例：

版本	修改时间	修改人	修改原因	评测结果
v1.0	2026-02-01	张三	初始版本	准确率 82%
v1.1	2026-02-05	李四	增加输出格式限制	准确率 87%
v1.2	2026-02-12	王五	增加“不知道”兜底	准确率 89%，幻觉率下降

6.5 数据安全与合法合规

做 AI 产品，尤其是企业级产品，数据安全是底线。AI 产品经理至少要关注：

用户输入的数据是否会被第三方模型服务留存。
知识库文档是否包含敏感个人信息或商业机密。
系统是否具备权限隔离，不同角色是否能访问不同的知识范围。
模型的输出内容是否符合行业监管要求。

这些问题不是技术问题，是产品问题。AI 产品经理必须在需求阶段和技术团队、法务团队、安全团队一起确认边界。

7. 总结与下一步学习路线

到这里，我们完成了从 AI 产品经理岗位认知、6 周学习计划、技术知识，到完整实战案例的梳理。回顾整篇文章，核心内容可以概括为以下几点：

AI 产品经理不等于“会用 AI 工具的产品经理”，它需要把技术能力和产品能力结合起来。
技术知识方面，大模型基础、Prompt 工程、RAG、Agent 是 2026 年的四块核心拼图。
学习路径上，先建立认知框架，再做原型验证，最后整理成可展示的作品集。
面试和工作中，模型评估、成本控制、数据合规是加分项，也是拉开差距的地方。

下一步你可以做两件事：

第一，按第 2 节的学习计划，完成前 3 周的基础学习，先跑通一个调用大模型 API 的小脚本。

第二，选定一个自己熟悉的行业场景，比如电商客服、教育问答、法律咨询、招聘助手，用第 4 节的案例作为模板，完成一份完整的 AI 产品方案，并尽量把 Demo 跑起来。

做 AI 产品经理，重要的是先做起来，再逐步完善。任何一份作品集、任何一个 Demo，都比 100 份收藏的干货资料更有说服力。希望这份 6 周路线能帮你少走弯路，更快进入 AI 产品经理这条赛道。如果文章内容对你有帮助，可以收藏备用，动手跑一下代码，你会比只看不练的人收获更多。

2026年AI产品经理转行指南：6周掌握大模型、RAG与Agent