企业官网建设流程全解析

AI时代产品经理转型攻略：大模型学习路径与实践

2024年的产品经理圈子，几乎每个群里都在聊同一个话题：不学大模型，是不是就要被淘汰了？我见过太多同行，白天被老板追问“这个需求能不能用AI做”，晚上又打开视频教程从Attention开始补起，乱学一个月，结果Prompt写了一堆，真到做产品方案的时候还是两眼一抹黑。说实话，这种焦虑我太理解了。但我想先给一句话：大模型时代的PM，并不需要把自己逼成算法工程师，但一定要重新建立一套技术认知和工具实战能力。

这篇内容就是写给正在或打算转型的产品经理。我会把我这一年多来实际摸索出来的学习路径、踩坑经历、落地实践的方法论，一次讲透。这里没有晦涩的数学公式，没有让你啃源码的鸡血任务，只有一套兼顾“认知升级”和“可落地”的转型攻略。无论你是还在犹豫阶段、刚刚跑通几个Demo，还是已经在负责带大模型功能的产品，这篇文章都值得你对照着看一遍。

1. 为什么时代变了：产品经理的新门槛与旧经验的价值边界

1.1 老板们问的不是“用不用AI”，而是“你懂不懂”

我身边不少产品经理，最开始是被迫学习的。老板把一个“智能助手”的项目丢过来，要求在三个月内上线，转头又补充一句“你们要用大模型来做”。产品经理连大模型能干什么、不能干什么都没摸清，就直接画原型、写PRD，等到开发排期的时候才发现，很多想当然的功能，技术上不是做不到，而是又慢又贵，完全不适合真实用户场景。

这里面真正的变化是：过去PM的知识盲区，可以被研发同学兜住；现在AI项目里的需求设计和交互设计，从源头就和模型能力强绑定。你写出去的每一条需求，本质上是在调用大模型的某种能力边界，如果你不了解这条边界，你连PRD的第一章都写不踏实。

但请注意，这不等于说PM要重新学一遍CS。我的观点很直接：大模型产品经理的核心竞争力，不是会写代码、不是会训练模型，而是能够判断“哪些问题值得用大模型解决，以及怎么把它变成可用的、稳定的、能赚钱的产品”。旧经验里对用户的理解、对场景的洞察、对商业价值的判断，在这一轮不但没有失效，反而因为稀缺而更有价值。

1.2 旧能力迁移：把“需求分析能力”转化为“模型能力分析”

我们过去做需求分析，会问：用户在这个流程里卡在哪里？我们希望用户以什么状态完成目标？到了AI产品里，同样的逻辑没有变，只是多了一个关键动作：判断用户需求属于哪一类模型任务，以及这一类任务目前的能力水位在哪里。

举一个非常典型的例子。某团队想做一个“合同智能审查”功能，产品经理一开始列了一长串需求：自动提取合同金额、关键日期，判断条款是否公平，识别隐藏风险，最后还要生成修改建议。如果按老思路，这就是一个需求清单，扔给研发就行。但懂大模型的PM会进一步拆解：提取金额和日期属于结构化信息抽取，用大模型加正则校验就能做得又准又可靠；判断条款公平性和识别隐藏风险属于语义理解与领域推理，模型能力有，但可靠性达不到法务直接使用的要求；生成修改建议属于开放性文本生成，模型很擅长，但要输出稳定、风格统一，必须做严格的Prompt管理和输出模板约束。

你看，同一个需求，经过这样的拆解，才变成一套可落地、可评估、能分阶段上线方案。这个过程，老一代PM称之为“需求澄清”，到了AI产品里，我更喜欢把它叫“能力澄清”。本质没变，但一个不懂模型能力边界的PM，根本无法完成这个动作。

1.3 转型最怕走错方向：学什么、不学什么，先要画清楚

经常有刚想入行的朋友问我，是不是该去学Python、学机器学习、学Transformer原理才能转型？我的回答一般是很现实的：如果你下一份工作不是算法岗，那花三个月去啃李航的《统计学习方法》，边际收益非常低。

我给PM画的学习边界是这样的：

• 不需要精通：模型内部的数学原理、训练细节、反向传播、损失函数。
• 必须要会用：ChatGPT/Claude等工具、主流API调用、函数调用（Function Calling）、RAG（检索增强生成）的基本搭建、Prompt工程。
• 必须能理解：大模型的能力边界、Token与成本计算、幻觉的成因与控制、评测指标的含义、Agent的基本构成逻辑。
• 必须能实操：独立把一个小功能从前到后做成Demo，并能说清楚每个节点的作用。

说白了，PM转型学大模型，与其说是“学技术”，不如说是在建立一种“技术的产品化嗅觉”。你不需要知道发动机的活塞怎么运动，但你得知道什么车型适合跑城市、什么车型适合越野，还得懂得看油耗表和保养周期。

2. 转型前的认知地图：大模型技术栈里，PM真正要懂什么

2.1 从最基础的“说法”开始：Token、上下文窗口和模型参数

很多PM去听技术分享，听到Token就犯迷糊。我打个比方你立刻就懂了：Token就是大模型读取文本的“最小认字单位”，一个汉字通常算1到2个Token，1000个Token大概相当于700到1000个字。模型的上下文窗口，可以理解成它“一次性能够看到的文本长度”。比如一个上下文窗口为128K的模型，大概可以一次读完一本十几万字的书，但注意，“能看到”和“能记住”是两回事。

如果你负责的产品要基于长文档做问答，那你就必须关注两个指标：模型实际生效的上下文长度有多长、在长上下文下是否会出现“中间遗忘”的情况。这些都是模型能力水位问题，直接决定了你的产品设计。比如要把“100页PDF问答”做稳定，光靠一个大模型是不够的，往往要配合文档切块、检索召回来做RAG方案。

再比如“模型参数数量”，70B和7B的差异，可以粗略类比成“一个经验丰富的专家和一个刚入行的实习生”。但在产品层面，参数大不等于适合你：更大的模型推理更慢、成本更高，有时候一个7B的模型配合好的Prompt和检索，反而比直接用70B模型更划算、更可控。

2.2 哪些技术名词是PM的“必修课”

我梳理了一张“PM必需认知清单”，把那些你必须在方案里和研发对话时听得懂、接得上话的名词列出来。学习的目标不是背定义，而是能自然地说出它们在产品决策中的作用：

这张表建议你存下来，每遇到一个陌生概念，先把它放到这张表的“PM视角的理解”里试一试：你能不能一句话说清楚它在产品上改变什么？如果说不清，说明你还没真正理解。

2.3 “知道原理”和“会用产品”之间，还差一个东西：动手做

认知地图画得再好，也替代不了动手。但很多PM动手的第一步就卡死在环境上，装Python、配环境、申请API Key、看英文文档，一连串折腾下来热情耗尽。这里我给一个降低门槛的建议：先别碰代码，从一个“配置型”工具开始。

比如你完全可以用国内外的对话式AI产品，去完成一次“角色扮演”：设定你是某公司的客服主管，让模型扮演一个愤怒的用户，你来尝试用设定好的客服话术应对，反复调Prompt，观察哪种说法让模型输出的回答最符合你的预期。这种做法不需要一行代码，却能让你快速建立对“指令-输出”关系的直觉。等这种直觉建立了，再进入API层面，阻力就会小很多。

3. 分阶段学习路径：从提示工程到Agent方案设计的四个台阶

3.1 第一台阶（两周）：提示工程入门到扎实

我把Prompt工程放在第一台阶，不是因为Prompt是包打天下的技能，而是因为它是最便宜、最快建立“模型交互直觉”的训练场。很多PM觉得Prompt不就是写段话吗，有什么好学的？真到了实战，你写得不好，模型输出就是七零八落；你用同样的句式换个场景，效果就天差地别。

我建议你给自己设定一个两周的小目标：不写代码，仅在一个对话产品里，完成三次完整的“提示词调优闭环”。什么叫闭环？就是你有一个产品目标、有一组输入样例、有一份期望输出标准；你设计第一版Prompt，跑一批测试输入，把失败案例汇总，分析失败原因（是缺示例、缺约束、还是格式说明不清），再改Prompt，再跑。这个过程，和做产品迭代一模一样，只是“产品”是一个Prompt。

这里我总结出三个最值得练的Prompt技巧，不管什么场景都用得上：

• 角色设定+目标说明+约束清单+输出格式的四段式结构。只要把模型当做一个新来的实习生，你就知道指令该怎么写了：说清你是谁、要做什么、边界在哪、交什么格式的活。
• 少量示例比抽象描述更有用。想让模型输出“专业感”的文案，与其写“请用专业语气”，不如贴两条专业文案让它参考。
• 多轮追问优于一次到位。在不确定需求时，先让模型给出初稿，再逐条指正，比第一次就把所有条件全塞进Prompt更稳定。

3.2 第二台阶（三周）：跑通API，理解产品化的必经之路

能调API，是PM从“玩玩具”到“做产品”的分水岭。你不需要掌握Python编程，但你最少要知道怎么把一段文本发给模型、拿回结果，并且能把成本算清楚。现在很多平台提供API调试页面或低代码工作流，不需要自己搭服务器就能跑通最简单的调用。

这三周你要做什么？第一，注册你选定的模型服务商的平台，找到API文档，把“对话补全”这一节读明白；第二，把一个典型的客服场景写成Python脚本，哪怕照着示例代码改也行，让它运行成功；第三，重点体会三个参数的作用：temperature、max_tokens、system消息。强迫自己做一个实验：固定同样的问题，只改system里的角色描述，看输出变化多大；再固定角色描述，只改temperature，看输出的随机性。

我会反复提醒每一个学员：做这个阶段的实验时，一定要自己准备一个小的评测输入集，至少10个真实问题。不要用一两个例子就下结论。这一阶段最大的收获不是“能调API”这个动作本身，而是你开始意识到模型的输出是概率性的：同一个Prompt，换了输入顺序、换了措辞，结果都会不一样。接受这种概率性，是设计稳定产品的心理前提。

3.3 第三台阶（四周）：用RAG把一个真实场景做深

RAG是现阶段最值得PM认真学的应用架构，没有之一。原因很简单：大模型本身的实时知识不可控，私有数据又不允许随便发送训练，而RAG能让你用一套“检索+生成”的框架，把企业自己的知识库变成模型可回答的内容。

这四周的学习目标，不是理解RAG的每个算法细节，而是搭建一个完整可跑的RAG Demo，并回答三个关键问题：召回什么？拼装什么？生成什么？我见过最朴素的合格Demo是：把5篇公司内部制度文档转成向量库，用户问“年假怎么休”，系统先从向量库检索出相关的段落，再把段落塞进Prompt，让模型根据段落回答，并标出引用的原文位置。

在这个过程中，PM一定要亲自去体验“检索不准”的挫败感。你会发现，有时候不是模型不会回答，而是前面的检索环节根本没找到关键句子。这时候你才真正理解，为什么RAG项目的优化要“先召回、后生成”。你会接触到切块大小、向量模型、相似度阈值这些名词，不用怕，用实验去感受它们的影响就行。

有意思的是，很多PM在第三台阶会发现自己开始能参与研发讨论了。当开发说“这个场景需要提高召回率”时，你已经能顺着他的思路追问：“召回不齐是因为切块太小导致语义割裂，还是因为向量模型不够匹配？”这就是技术产品化嗅觉渐渐成型的样子。

3.4 第四台阶（四周起）：Agent方案设计与多步任务编排

到第四台阶，你已经具备了“单次问答”的产品化能力。但真实的复杂业务，通常不是一次问答能搞定的。比如“帮我订一家适合团建的餐厅”：你要调用地图API搜索餐厅，要看用户的口味偏好，要对比评分，还要把结果整理成推荐卡。拆成多个步骤，每个步骤都有不同的决策逻辑，这就是Agent的用武之地。

成年人的学习不能靠看，还是要靠做。第四台阶的项目，我建议找一个身边真实存在的痛点，比如“自动整理客户咨询记录并生成周报”。它至少涉及：接收原始对话记录、抽取关键字段、按模板生成段落、输出周报文件。用Function Calling让模型识别该调用哪个工具、提取哪些参数，是一个完整的Agent训练项目。

到了这个阶段，你的关注点会自然转向：任务拆解的结构、工具调用的成功率和容错、步骤多了之后延迟和成本的增加。你会发现“Agent不是模型，而是用模型写的一套流程控制系统”。这种理解，比单纯会调接口的价值高一个量级，因为在产品设计上，你已经有能力去评估“这个流程自动化到底值不值得做”。

4. 落地实践关键动作：一个AI产品从需求到上线的PM视角

4.1 先找一个足够小的场景，画出流程和决策点

学完前面四个台阶，你已经具备了理论知识，但距离能在一家公司里独立负责一个AI功能，还差一个环节：从0到1走完一个AI产品的完整闭环。

我建议所有转型者，不要一上来就搞那种“智能中台”级别的宏大项目，先找一个非常小、但真实存在的场景。比如我们一个曾经辅导过的案例——某团队想解决“客服重复回答常规问题”的痛点。需求方一开始说“要不把整个客服知识库都做成智能问答”，这听起来很大，但真正动手时，我们从高频提问里挑了三个问题类型先做试点：查账单、改地址、查营业时间。这种小切口的好处很多：评测集容易构造、知识范围可控、上线后效果容易衡量、出问题也方便定位。

选定场景以后的做法和老产品设计一样：画流程图。把“用户提问→意图识别→检索→生成→兜底转人工”每一个节点都列出来。然后对着每个节点问一句话：这个节点需要模型吗？需要哪种模型能力？如果模型失败了，降级方案是什么？你会发现，真正需要大模型的地方，其实远比你想象得少；很多环节用传统关键词匹配、正则表达式反而更稳更便宜。能做出这种判断的PM，已经比那些“什么都想塞给AI”的同行走在了前面。

4.2 从写Prompt到建评测集：PM手上最重要的资产

AI产品的评测，是整个行业转型期最稀缺的能力。传统软件有明确的功能测试用例，只要功能实现了就通过；AI产品没有这种确定性。同一个输入，今天答得好，明天换了模型版本可能就答得差。所以，PM做AI产品，一定要把“评测集”当成和PRD一样重要的交付物。

什么是评测集？就是你准备的一批“问题-期望答复”黄金对。至少准备50条覆盖典型用户意图的输入，每条都要有明确的通过标准。这个标准不一定是逐字相同，可以定义成“是否包含关键信息、是否拒绝了敏感问题、是否给出了正确答案”。有了评测集，你的Prompt迭代才有依据，模型选型对比才能量化，上线回归测试才有抓手。

别小看这个动作，我见过太多团队，开发完功能就上线，问体验如何全靠“我感觉还行”，结果一到真实用户手上就翻车。为什么翻车？因为“我感觉还行”没有标准。一份好的评测集，能让AI功能像传统功能一样，具备“可验收”的边界。这是PM在AI项目里建立话语权最关键的动作。

4.3 模型选型和成本估算：PM既要会算账，也要会选型

很多PM以为模型选型是算法工程师的事情，这是大错特错。选型本质上是一个产品决策：要在效果、速度、成本、合规之间做权衡。你直接面对的问题包括：业务数据的敏感性允不允许调用非本地化部署的模型？用户对响应速度的忍耐阈值是多少？这笔功能产生的增量收益，能不能覆盖模型部署和调用的成本？

我建议在项目早期，你就让研发提供几个候选模型的基准数据，包括每次请求的平均Token消耗、单位Token价格、响应延迟、并发上限。你自己要会算一个最基础的账：假设每日请求量1万次，每次平均消耗2000个Token，如果每千Token的价格是0.03元，那一天的成本就是600元，再乘上30天，就是一个月1.8万元。很多PM看到这个数字，就知道为什么有些功能不应该让大模型来承担了：如果这是一个低成本需求，用传统规则就能解决，那大模型方案在目前就是不经济的。

选型上，我的实用建议是：能用小模型不用大模型，能少传Token就少传Token，能本地化就不用云端。大模型不是越贵越好，而是越合适越好。一个FAQ问答，用轻量模型加精准检索往往比用顶级大模型更稳健。这些权衡看起来是技术问题，本质却是最典型的产品成本管理。

4.4 上线不是终点：建立监控、回流和迭代的循环

AI功能上线以后，工作才真正开始。你要盯的数据，除了传统产品的DAU、留存，还有AI特有的指标：回答采纳率、用户纠偏率、兜底转人工率、平均响应时长、单次会话成本。

我认识的很多团队，在AI功能上线第一周就被用户“教育”了：用户提的问题千奇百怪，评测集里根本没想到；有的回答看着专业，实际是模型幻觉编出来的；还有用户根本不想和机器人聊天，直接输入“转人工”。这些问题都不可怕，可怕的是团队没有一套机制把它们回收、归类，并形成优化优先级。

我给的建议是，每次迭代都带着“三个一”：一份新增的真实失败样例，一份更新后的评测集，一份Prompt或检索策略的变更说明。这样每两周一次的迭代复盘，就变成了数据驱动的优化会，而不是“凭感觉调一调”。产品经理在这个循环里扮演的角色，是那个把用户端的模糊反馈，翻译成评测集里具体判定标准的人，这个翻译能力，就是AI产品经理真正的护城河。

5. 常见转型误区与避坑经验：我用真金白银换来的教训

5.1 误区一：沉溺于模型参数和榜单，忘了用户价值

说实话，产品经理圈子也有一股“性能攀比风”。有些人一说大模型，就爱讨论哪个模型在榜单上又多了几分、哪个模型的中文能力更强。这些东西不是不重要，但对于PM而言，它们应该是最后才考虑的变量。我遇到过某团队花了两个月时间比较多个模型的代码生成质量，最后却发现自己产品的目标用户根本不会用代码生成功能。

正确的顺序是：先从用户需求倒推出任务类型和能力要求，再缩小到两三个候选模型，用你自己的评测集快速验证效果，最后再决定。那些排行榜上的分数，和你真实场景里的表现往往差得远。只有用你自己的数据、你自己的Prompt、你自己的判断标准跑过，才有意义。

5.2 误区二：把大模型当数据库，什么都要它“直接答”

这是新手PM最常犯的错误。看到模型能答很多问题，就觉得什么都可以让它直接回答。但现实是，模型并不知道你公司内部的流程、你产品的私有数据、你最近更新的政策。如果你不做检索增强，不做知识库接入，你得到的回答就是一本“百科全书式”的泛泛之谈，而不是你用户真正需要的答案。

做知识类AI产品，我有一条铁律：凡是涉及事实性内容，必须从权威知识源里检索后生成，不能依赖模型内部记忆。用户问“退货政策是什么”，如果答案不是来自你上传到知识库的最新政策文件，那这个答案就不应该被展示。这不是技术洁癖，而是产品责任。用户在你这儿得到的错误政策说明，后果可能是投诉，甚至更严重。

5.3 误区三：Prompt是万能的，先写了再说

有些PM学会了Prompt，就把所有问题都归结为“Prompt写得不好”。模型答错了，改Prompt；输出不稳定，再改Prompt；知识错了，还改Prompt。到最后Prompt写了三页纸，覆盖了几十条示例，结果换个输入还是翻车。

我以前也这么干过。后来我明白了一个分层决策顺序：知识不对，先查知识源要不要更新；能力不够，先想模型要不要换；格式不对，先看输出要不要约束；最后才是Prompt的调优。把Prompt当成最后一个变量去动，而不是第一个救火工具。前面提到的RAG、检索质量、评测集，都比Prompt更能决定一个AI产品的上限。

5.4 误区四：忽视隐私与合规风险，上线了再补救

大模型产品最容易被忽视的是安全合规问题。用户输入的内容会发给第三方模型服务商，哪些数据能出域？哪些数据必须在私有化环境处理？模型输出的内容出了问题，责任归属怎么算？这些都不是技术细节，而是产品经理要在需求阶段就回答的问题。

我见过有团队上线了智能写作助手，结果用户输入了含有个人手机号的文档，信息被发送到云端处理，虽然没有出事，但把团队吓出一身冷汗。教训就是，以后凡是用户可能输入敏感信息的功能，要么在输入环节做脱敏处理，要么选用本地化部署的模型方案，要么在协议里明确告知用户数据处理方式。这些事情宁可早做，不要事后补救，因为一旦发生数据泄漏，整个产品都保不住。

这方面我的另一个心得是：一定要在公司制度层面提前和法务、安全团队对齐，搞清楚你们公司对“数据出域”“模型输出内容审核”的要求是什么，把这些要求直接写进PRD的功能特性里。大模型功能上线前，也建议做一个专项的“安全回归测试”：输入各类诱导、越狱、隐私探测类内容，确认模型的过滤与降级机制有效。这在我们以前做传统产品的时候几乎不用考虑，但AI产品必须考虑。

5.5 最后提醒：别一个人硬扛，找个同行互相改作业

转型这件事，最容易死在“闭门造车”上。一个人闷头学，遇到问题没有人讨论，特别容易放弃或者走偏。我的实际建议是，找一个同样在转型的同行，每两周互相看一次对方新写的Prompt、新的评测集、新的产品方案。这种互相“改作业”的机制，比我一个人闷头看书有用得多。

不用怕被指出问题，那是进步最快的方式。一个人写Prompt，你只会越写越自洽；两个人互相看，才会发现自己的盲区。尤其是在评测集的设计上，对方的一句“你的通过标准是不是太宽松了”，往往就能点醒你：你自己设计的问题，自己判分，当然会觉得效果好。有了旁观者的视角，你才真正站在用户和验收方的立场上，重新审视产品的质量。

我现在回头看这一年多的转型路程，最大的体会并不是掌握了多少技术名词，而是学会了一种“不确定中找确定”的思维方式。大模型的输出是概率，产品的体验要求是稳定，这两者之间的缝隙，就是产品经理的价值空间。你不需要成为技术大牛，但一定要成为那个能把技术能力翻译成用户价值、把模型不确定性关进产品流程里的人。这条路，值得每一个认真对待产品的人走下去。