企业官网建设流程全解析

这两年转做大模型方向的产品经理越来越多了，但说实话，我见过不少产品经理把这个岗位理解成“会聊几句AI的普通PM”，结果一上手就被技术术语、模型能力边界、评测指标这些事砸得晕头转向。也有朋友一开始就猛学深度学习数学推导，学了一个月发现自己离业务越来越远，完全不知道学的东西怎么转化成产品决策。

这篇文章不是给你列一个“知识点清单”，而是把一套我踩过不少坑之后总结出来的完整进阶路线讲清楚：从角色定位、技术底座，到提示词工程、RAG和Agent落地，再到评测体系、数据治理和成本控制。内容会偏实操，适合已经有一定产品经验、想真正把大模型能力落到业务里的PM，也适合刚入门但不想只停留在“调API然后拼流程”阶段的朋友。

1. 大模型产品经理和传统PM到底差在哪——想清楚再上车

1.1 大模型产品的四类主要形态

很多人觉得“大模型产品经理”就是做个聊天机器人，这是最容易产生的误解。实际拆开来看，市面上主流的大模型产品大致可以分成四类，每一类的产品设计重心都不一样。

第一类是纯粹的对话助手，比如通用的问答、写作、翻译类应用。这类产品的难点不在功能，而在模型能力调用、人格化设定、多轮对话管理、内容安全护栏这些相对“软”的地方。

第二类是Copilot形态，也就是辅助人在某个具体工作流里提高效率，典型的如客服辅助、代码辅助、文档协作等。产品经理需要格外关注上下文怎么抽取、结果怎么嵌入用户既有工作流程、以及“人机协作”时责任边界怎么划分。

第三类是RAG应用，也就是基于企业私有知识库做问答和检索增强生成。这类产品在当前落地场景里占了大头，但难点非常工程化：文档解析、切片策略、向量检索、重排、引用溯源、幻觉控制，每一个环节都会直接决定用户能不能信任这个产品。

第四类是Agent形态，也就是让模型能调用工具、规划步骤、执行多步任务。这类产品自由度最高，但也最不可控，产品经理需要解决的往往不是“能不能做出来”，而是“怎么保证它不跑偏、不乱花钱、不泄密”。

想清楚你做的产品属于哪类，学习路线才能不走偏。如果一上来就照着Agent框架猛学，结果手上项目只是知识库问答，那很多精力其实是白费的。

1.2 技术理解力为什么成了产品经理的新门票

传统产品经理可以不懂技术，靠的是用户洞察、需求梳理、交互设计、项目推动。但到了大模型产品里，情况有本质变化：模型的输出是概率性的，你没办法用传统的“if else”逻辑去预期每一次反馈，产品的体验边界、功能边界、风险边界，都需要你从模型能力、参数设置、上下文构造、评测数据这些技术维度去判断。

这不是说你要变成算法工程师，而是说你必须建立一种“技术翻译能力”：把业务需求翻译成模型能理解和执行的指令，把模型输出的异常翻译成可追溯的技术问题，把用户的体验反馈翻译成评测集里的测试用例。

举一个很具体的例子：用户反馈“问答助手回答不稳定，同一个问题两次回答不一样”。传统PM可能直接提需求“请让回答保持一致”。但懂大模型的PM会先去区分：是模型采样温度设置过高？是检索到的上下文片段有差异？是提示词里没有约束输出格式？还是模型本身在开放式问题上就不可能完全一致？这几种原因对应的解法完全不同，如果你没有一定的技术理解力，连排查方向都定不了。

这种差异决定了学习路线的核心设计原则：不要从数学原理开始啃，而要从“模型行为”开始建立直觉，再逐步向工程细节深入。

2. 学习路线第一段：把技术底座啃到能聊天、能判断、能沟通的程度

2.1 先搞懂五个绕不开的基础概念

对大模型产品经理来说，最该先掌握的不是线性代数，也不是反向传播，而是五个基础概念：Token、上下文窗口、温度、幻觉、模型参数规模。这几个概念是你日常和算法、研发沟通时的高频词汇，也是做产品决策的判断基石。

Token可以理解为模型读写文本的最小单位，简单说就是你输入的内容会被切分成一小块一小块的文本片段。产品经理需要形成一种“Token意识”，因为所有大模型产品都有成本，而成本几乎都是用Token计算的。一个产品功能如果每次调用都要塞进去几千Token的企业资料，日活一上来，成本会非常吓人。所以设计产品时就要想：每次请求到底需要多少上下文，能不能精简，能不能走缓存。

上下文窗口可以理解为模型一次能“看到”的文本总量。窗口越大，模型能利用的信息越多，但成本和响应速度也会上升。产品经理不需要记住每个模型的窗口具体多大，但必须清楚“超出窗口的内容会被截断或忽略”，这类错误在RAG产品里很常见，我们后面实战环节再细说。

温度是控制模型随机性的参数，一般0到2之间，数值越低回答越保守稳定，越高越发散有创造性。实战场上，产品经理要学会按场景定温度：知识类问答、信息抽取、代码生成，温度一定要低；创意写作、头脑风暴、营销文案，可以适当调高。很多产品体验不稳定，仔细查下来就是谁把温度设成了1.5没改回来。

2.2 三大核心机制：幻觉、RAG与微调

基础概念建立好之后，紧接着要去理解大模型产品里最核心的三个机制。

幻觉是模型一本正经地胡说八道。产品经理必须接受一个现实：只要是大模型，幻觉就不可能归零，能做的只是降低概率、增加拦截、加强溯源。这决定了产品设计中必须有“防幻觉”的机制设计，而不是幻想通过换一个更强的模型就一劳永逸。

RAG，也就是检索增强生成，是目前企业落地大模型最主流的技术路线。它的思路很简单：模型不知道的知识，你先把相关资料查出来，塞进上下文，让它基于上下文回答。产品经理要理解RAG的完整链路：知识导入、文档解析、切片、向量化、检索、重排、合成回答。每一个环节都有产品决策点，比如切片切多大、检索取多少个结果、要不要重排、回答要不要限制“只能基于引用内容”。

微调简单说就是在通用模型基础上用业务数据做二次训练，让模型更适应特定风格或特定任务。产品经理要建立“微调不是首选”的意识，因为大多数需求靠精心设计的提示词和RAG就能解决。只有在风格迁移、格式稳定、领域术语专业性这些方面，微调才有明显优势。而且微调需要准备大量高质量标注数据，周期长、成本高、迭代链路重，启动前必须想清楚。

需要特别提醒的是：这三者不是三选一的替代关系，实战中常常是组合使用。比如一个知识问答产品，主流方案就是“RAG加低温度加提示词护栏”，极少数冷门场景才会上微调。产品经理理解了这些机制，和算法团队聊方案时才不会鸡同鸭讲。

2.3 动手练一个最小闭环，别只看文档

很多PM学大模型技术，方式是每天刷资料、记笔记，结果纸上谈兵一个月，还是不知道模型返回的JSON怎么解析，也不知道提示词顺序对结果有多大影响。我的建议很直接：不管你的岗位是什么，第一周就要跑通一个最小闭环。

具体做法是找一个开源模型或者调用商用模型API，自己写几行代码，实现一个最简单的“输入问题、输出回答”的功能。不需要懂后端架构，甚至用本地脚本就能跑。然后逐步加上自己的提示词模板、加几段参考资料模拟RAG、加一个简单的流式输出，你就会对“上下文是怎么进入模型的”“回答质量受哪些因素影响”产生非常直观的感受。

这一步的作用不是把你变成工程师，而是打破黑盒恐惧。很多产品经理不敢碰技术，是因为心里没底，但一旦亲手调过几次API、亲手对比过不同提示词的效果，后续和研发沟通的底气会完全不一样。实测下来，这个过程快的两三天，慢的一周足够，性价比极高。

3. 提示词工程与流程编排——产品经理最容易上手的硬技能

3.1 提示词就是你的产品需求文档

我要提出一个观点：在大模型产品里，提示词本质上就是产品需求文档。传统PRD是写给研发看的，把功能逻辑定义清楚；提示词是写给模型看的，把任务目标、输入输出格式、约束条件、示例都交代清楚。如果你连提示词都写不好，那需求一定也没想透。

一个可复用的提示词结构，应该是五个部分的组合：角色设定、任务描述、输入数据、输出格式约束、示例和托底策略。角色设定不是为了让模型“好玩”，而是为了限定它用什么样的视角和语气处理问题；任务描述要具体到动词和边界，比如“抽取客户反馈中的问题类型、紧急程度、涉及系统，只返回JSON，不要附加解释”；示例是最有效的控制手段，给一个标准输入输出的配对，模型马上能模仿你的格式。

实操里我最常踩的坑是提示词越写越长。有些人觉得写得越详细越好，结果把几百行说明文塞进去，模型反而抓不住重点，回答开始跑偏。经验是：提示词要信息密度高、逻辑顺序清楚、关键约束前置，能用示例说清的不用大段描述。

3.2 从单轮提示词到工作流编排

单轮提示词解决的是“一问一答”，但真实业务场景几乎都是多步骤的。比如一个客服工单分类助手，表面是“把用户的问题分个类”，实际流程是：先判断用户意图，再抽取关键实体，再匹配知识库，再生成回答，最后还要判断要不要转人工。每一步都对应一段提示词或一个模型调用，这些步骤串起来就是一个工作流。

产品经理在这个阶段要学会“把业务流程画成模型可执行的状态图”。不需要你精通代码，但你得能画出：从哪里开始，每一步判断条件是什么，分支怎么走，异常情况怎么兜底。把结构想清楚之后，再用流程编排工具或者Agent框架去落地，你会发现整个项目的可维护性大幅提升。

这个阶段还要建立一种意识：不是所有节点都需要大模型。能用规则判断的就用规则，能用检索解决的就别让模型生成，大模型只用在最需要语义理解和生成的环节。这既是成本控制的需要，也是稳定性控制的需要。常见的新手错误是每个环节都强行套大模型，最后得到一个又慢又贵还不稳定的系统。

3.3 工具调用和Agent的设计边界

再往深一层就是Agent，也就是让模型自主决定调用什么工具、按什么顺序执行。产品经理要理解Agent的强大和危险是并存的。

强大在于它能完成开放任务：给它一个目标，它能自己规划步骤、调API、查数据库、写代码，最后给出结果。危险在于“自主”意味着失控概率上升：它可能调错工具、可能陷入死循环、可能在关键步骤上产生幻觉、可能调用工具的凭证泄露敏感信息。所以产品经理设计Agent产品时，核心思路不是放权，而是设边界。

我的建议是先从“受控的Agent”做起：限定工具列表，限定工具参数格式，设定最高执行步数，要求Agent每一步都输出理由，关键节点加人工确认。等系统足够稳定、评测数据足够丰富之后，再逐步放开自主度。这个思路在实战中非常管用，很多翻车案例都是因为一上来就追求“全自动”。

4. 实战复盘：从0到1做一个企业知识库问答助手

4.1 立项阶段的需求拆解，决定后面是省力还是返工

为了把上面的内容串起来，我用一个虚构的实战项目来做完整复盘。假设我们要为一个有大量内部制度文档、产品手册、常见问题文档的企业做内部知识库问答助手，人员规模大概几百人，文档数量上百份，格式混杂着PDF、Word、Excel和网页导出文件。

这个项目看上去很标准，但实际上手之后才发现，需求拆解阶段没做扎实的话，后面每个环节都在还债。当时我带着团队做了三轮关键确认。

第一轮是确认用户真正的问题是什么。去访谈一堆同事之后发现，他们日常最痛的不是“找不到文档”，而是“不知道哪份文档是最新版本、不知道自己该按哪条规定执行”。所以产品的核心价值并不是“检索”，而是“给出有权威依据的确定性答案”。这个定位直接影响后面要不要做引用溯源、要不要显示文档版本、要不要标注“此回答依据XXX制度第X条”。

第二轮是确认答错的代价。如果只是问“会议室怎么预约”，答错了用户重新查一下就行，损失很小。但如果是“报销标准”“年假计算规则”“信息安全红线”这类问题，答错了可能造成实际损失和合规风险。这个判断决定了产品必须在高风险问题上设置强兜底，比如答不出就明说不知道、给出人工咨询入口。最终我们定了一个很关键的产品规则：模型没有把握时，必须拒绝回答，不能硬编。

第三轮是确认验收标准。团队内部对齐了一个非常朴素的标准：用户提问题之后，助手给出的答案里，每条关键信息都必须能在某一份指定的源文档里找到依据。做不到这一条的答案，无论看起来多通顺，都视为不合格。后来所有的算法选型、切片策略、评测集设计，都是围绕这条标准展开的。

4.2 数据准备与评测体系：先于功能开发启动

这是这个项目里最值得展开的部分，因为绝大多数团队都会低估数据工程的比重。

文档解析是第一道坎。PDF里有扫描图片、有表格、有页眉页脚，Word里有各种层级标题，Excel里是密密麻麻的数据，如果统一按纯文本切分，信息结构就全丢了。我们当时的处理是把文档统一转成带结构标记的文本，表格尽量转成Markdown表格，再把页眉页脚这类干扰信息剔除掉。这个环节看起来不性感，但直接决定了后面检索质量的上限。

切片策略也是反复调出来的。一开始我们是按固定长度切片，每512个Token一刀切，结果问题来了：一个完整制度条款被拦腰切断，检索召回时只拿到半截，模型回答自然就缺上下文。后来改成“语义切片”，尽量按章节条款边界切，同时让相邻切片之间有少量重叠，避免信息断层。这属于很基础的工程细节，但效果差异非常明显。

评测体系是另一个重头戏。我们从真实用户问题里整理出了一份约200条问题的黄金测试集，覆盖高频问题、复杂问题、陷阱问题、无答案问题四类。每条问题都预先标注了理想答案和对应的依据文档路径。之后的每一次模型调整、提示词修改、切片改动，都用这套测试集跑一遍，记录三个核心指标：回答正确率、引用准确率、拒答率。没有这套评测，所有优化都会变成拍脑袋。

这里分享一个教训：评测不是算法团队自己的事，产品经理必须深度参与。因为“回答正确”这个标准本身就是产品定义。比如用户问“今年年假有几天”，理想答案要不要区分入职年限？要不要显示计算过程？这些判断产品经理不定，算法同学只能靠猜。

4.3 方案落地中的模型选型与提示词细节

模型选型上我们没有一味追求最强模型，而是综合考量了成本、响应速度、上下文长度和部署方式。因为这是企业内部系统，对响应速度敏感度中等，但成本是实打实的经营指标，最终选了一个主模型和备用模型的搭配，主模型负责复杂问题和最终生成，备用模型处理简单分类和抽取任务。

提示词实战里的一个关键细节是“回答必须基于引用”。我们在系统提示词里明确写了：你必须优先引用检索到的资料，如果资料里没有答案，直接说明不知道，禁止编造。同时要求每一条关键陈述后面带上文档编号和条款位置，用这种强约束来倒逼模型去引用真实资料。实测下来，加上这个约束之后，回答的幻觉率明显下降。

还有一个让研发同学一开始很嫌弃、但后来真香的做法：我们在提示词里加入了“如果用户问题属于XX类，请先询问更具体的信息再回答”。这是为了处理大量模糊问题。比如用户问“报销怎么弄”，直接回答会非常泛，但引导他补充“是差旅报销还是采购报销”，回答质量会高很多。这种对话策略本质上就是产品交互设计，只不过它落在了提示词里。

4.4 实测过程中的意外情况和排查思路

这个项目上线前集中测试时，出现过几个让人头大的问题，我觉得值得展开讲，因为很多团队都会遇到类似的。

第一个是上下文污染问题。用户连续问了好几个问题之后，模型开始把前面几轮对话里的信息混进后面的回答里，甚至出现张冠李戴。排查下来发现是多轮对话时我们把前面的问答历史全部塞进上下文，而这些历史内容干扰了模型对“当前问题”的判断。解决方法是：不是所有历史都对当前有用，而是做关键信息抽取，把历史里的用户核心诉求单独抽出来，而不是把原始对话一股脑丢给模型。

第二个是“高置信幻觉”问题。模型对某些超出知识库的问题给出的回答非常流畅，甚至还能编出条理清晰的流程步骤，让用户真假难辨。我们最后加了一道“相关性判定”步骤：先用模型判断“检索到的资料和用户问题是否相关”，相关度低于阈值就不生成回答，直接转给人工。虽然偶尔会误杀一些本可以回答的问题，但相比让用户看到编造的答案，这个代价完全可以接受。

第三个是成本超预期。一开始设计功能时很任性，每个请求都带上大量背景资料、历史记录、行业规范，结果单个请求的Token消耗量相当惊人。后来我们做了L1和L2两级路由：简单问题直接走轻量模型，只有复杂问题才走完整RAG链路，成本才回到了合理区间。这件事说明，大模型产品的成本优化一定是产品设计问题，不能只指望基础设施降价。

5. 进阶方向：从会做功能到能搭系统

5.1 评估治理与可观测性：大模型产品的隐形地基

很多产品经理做第一个大模型项目时会很爽，因为“功能上线了，效果看着不错”。但一旦用户量上来、问题类型变多，你就会发现原来的“差不多能用”远远不够。进阶和初阶分水岭，在于有没有把评估、治理、可观测性做成基础设施。

可观测性不是说记录几条日志，而是要把线上每一轮对话的关键信息都结构化管理：用户问了什么、检索到了哪些资料、模型生成了什么回答、用户有没有点踩、有没有复制转发、有没有转人工。这些数据是后续优化的命脉。没有可观测性，产品优化全靠猜。有了之后，你可以持续分析“哪些问题是高频但回答不准的”“哪些知识文档是检索不到但明明存在的”，评估和优化才开始有方向。

评估治理也是一样。不要指望一次评测集走天下，而是要建一套多维度评测体系：标准化测试集用于日常回归，竞品对比集用于看全市场水平，线上抽样集用于追踪真实效果，安全专项集用于排查风险内容。每一类评测都要有明确的责任人和触发机制。这个体系一旦建立起来，大模型产品团队才真正进入了工程化迭代节奏。

5.2 语料工程：大模型时代的产品经理新基本功

如果让我说一个“既重要又容易被忽略”的能力，我会选语料工程。传统产品经理画原型、写PRD，大模型时代的产品经理还要多一门功课：为模型准备高质量的输入样例和反馈数据。

举个例子：你希望模型把用户问题分类成“报障、咨询、投诉、建议”四类，光靠写一个分类规则是不够的。模型需要的是大量“用户原话-分类结果”的样例。这些样例从哪里来？怎么保证覆盖边界情况？怎么避免分类标准前后不一致？这是产品经理该干的活，而且是最核心的活之一。

同样的逻辑适用在评测集建设上：每条评测题都应该能追溯到某类真实用户需求，每条评测的“理想答案”都应该经过产品经理确认。这条基本功练好之后，你会发现“这个模型更强”往往不如“我们的数据更懂业务”带来的效果提升明显。

5.3 时间分配建议：什么值得深耕，什么可以先放一放

最后谈谈学习资源怎么分配，很多同行问过我。

我的建议是：大模型技术原理，也就是Transformer结构、训练流程、微调机制这些，知道关键概念和流程即可，暂时不用深入推导；提示词工程、RAG、Agent这些技术方向，必须结合项目实际动手练，这是日常工作真正要用的；评估体系、数据标注、语料建设、成本测算这些“相对无趣”的能力，决定你能不能向上走，值得长期投入；写代码的能力，能跑通脚本、看懂SDK文档即可，不需要追求独立开发系统。

投入比例我大致会按二、三、三、二来分配：两成时间补技术原理，三成时间练Prompt和RAG，三成时间搭评测和数据体系，两成时间写点小代码保持手感。这个比例当然可以按你的岗位和项目灵活调整，但大方向是明确的：不能只追最热的技术概念，而要把工程化、数据化的基本功打扎实。

我自己这两年最大的体会是：大模型产品经理真正的壁垒不是能说出多少新名词，而是能不能把模型能力转化成稳定的、可信的、可迭代的、成本可控的产品体验。这条路没有捷径，但要紧的是别走偏方向。希望这份路线能帮你少踩几个坑，把时间花在真正重要的事情上。