企业官网建设流程全解析

最近两年，和“AI产品经理”相关的讨论非常多，但真正落到面试现场，情况往往很残酷。很多候选人能聊出“AIGC会改变行业”这类正确废话，可一旦被追问“这个需求要不要接大模型API”“幻觉怎么控制”“评测集怎么建”“Agent方案怎么评审”，就开始含糊其辞。

这其实暴露了一个关键问题：AI产品经理的真正门槛，不在传统产品方法论，而在技术理解力。

这篇文章不准备讨论“AI会不会取代产品经理”这种泛泛话题，而是分享一套可以照着执行的AI产品经理学习与实践框架。我会从能力模型、技术原理、完整项目流程、模型评测到一周学习路线逐一拆开讲。不堆砌概念，不讲宏大趋势，尽量让看完的人能直接上手验证自己的理解。

1. AI产品经理到底解决什么问题

很多团队在招AI产品经理时，并不清楚这个岗位和传统产品经理的边界。

传统产品经理面对的是确定性系统。页面有几个按钮、流程怎么走、异常状态怎么提示，都可以提前定义。即使出问题，逻辑漏洞往往是可复现、可定位的。

AI产品经理面对的是概率性系统。同一个Prompt，模型在不同时间可能给出不同回答；同一个问题，换个表达方式可能触发完全不同的内容；模型还可能出现幻觉、偏见、格式不稳定的情况。你没办法用“写清楚PRD”的方式，让模型100%按预期工作。

所以AI产品经理的核心职责，是把“不确定的模型能力”转化为“相对稳定的产品体验”。这个话听起来抽象，拆开就三条：

1. 判断模型能力边界：这个需求到底适不适合用大模型解决，还是规则引擎、传统算法更可靠。
2. 设计兜底与评测机制：模型出错时产品怎么表现，如何定义“答得好不好”。
3. 管理数据与成本：评测集从哪来、Token成本怎么控制、数据隐私怎么处理。

下面这个对比可以帮助理解差异。

举个例子。同样是做内容审核系统，传统产品经理会设计规则引擎：关键词列表、分类逻辑、人工审核队列。AI产品经理要考虑的是：用哪种模型做初审、置信度阈值设多少、低置信度内容怎么分流到人工、模型更新后审核标准会不会漂移、误判率和召回率怎么平衡。

这个例子说明一个判断：AI产品经理不是传统产品经理的“AI版”，而是不确定性产品的设计者。如果还用传统产品思路去做AI产品，大概率会在上线后被各种badcase打得措手不及。

2. 能力模型：AI产品经理的技术理解要到哪一层

经常有转岗的同学问：“我是不是得先学会训练模型，才有资格做AI产品经理？”

答案是否定的。但完全不学技术也不行。

我把AI产品经理的技术理解分成五层，可以对照自检：

多数AI产品经理岗位，真正要求的是“调用层 + 原理层 + 调优层”。你需要看得懂技术方案评审，能和技术团队争论“这个方案成本是否合理”“这个方案能不能满足业务要求”，但不一定要自己动手训练模型。

下面这些概念，建议产品经理至少了解它们解决什么问题、代价是什么：

这里真正的分水岭，不是你能不能画出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": f"Bearer {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, headers=headers, json=payload) 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字以内，使用简洁的列表或短句。 输出格式： - 直接答案 - 依据来源（引用知识库文档标题）

这个模板看起来简单，但实际能解决几个常见问题：减少幻觉（限制只依据知识库）、控制回复长度（成本与体验平衡）、保证可溯源（输出来源）。

提示词设计不是靠“文笔好”，而是靠“可验证”。正确的做法是：

1. 准备10个到20个典型用户问题。
2. 定义评分维度，比如准确性、完整性、格式合规性。
3. 分别用不同版本的提示词测试，记录通过率。
4. 选通过率最高的版本上线，后续持续迭代。

这里有个容易踩的坑：把提示词当成万能钥匙。如果业务场景很复杂，比如需要处理多轮对话、需要实时查询用户订单、需要控制风险级别，单靠提示词是不够的。这时候要考虑引入RAG、Agent、前后端逻辑配合，提示词只是整个系统里的一环。

还有一个需要提醒的点：提示词不是一次写好就一劳永逸。上游模型版本升级后，同样的提示词效果可能会变化。所以每次模型切换前，都要用评测集回归一遍，确认没有效果退化。

5. RAG与Agent：AI产品经理绕不开的两个技术框架

现在的AI产品，很少是“一个模型裸奔”的状态。两个技术框架出现频率最高：RAG和Agent。

5.1 RAG：给模型配一本可检索的参考手册

RAG的全称是Retrieval-Augmented Generation，检索增强生成。通俗讲，就是先从一个知识库里检索出相关内容，再把这些内容拼接进Prompt，让模型基于这些材料回答。

为什么要用RAG？三个核心原因：

• 知识实时性。大模型训练数据有截止时间，无法知道最新政策、最新价格、最新内部文档。
• 幻觉控制。模型凭空生成容易出错，但给它一段参考材料，出错概率会明显下降。
• 可溯源。用户问了“为什么”，你可以指出依据来自哪份文档。

RAG的核心流程大概是：

1. 把业务文档切分成片段。
2. 将这些片段向量化，存入向量数据库。
3. 用户提问后，把问题也向量化，检索出最相关的片段。
4. 把相关片段和用户问题一起拼进Prompt。
5. 模型基于这些片段生成最终回答。

产品经理做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产品的流程和传统产品有重合，但决策点完全不同。

一个典型流程可以拆成六步。

1. 需求定义：明确用户要完成什么任务，成功标准是什么。这个环节最容易出现的问题是“只描述功能，不定义效果指标”。
2. 技术选型：确定模型来源、模型规模、架构方案。
3. 数据准备：构建评测集，准备知识库，规划标注方案。
4. 原型与验证：用小样本验证核心链路是否走通。
5. 灰度上线：控制流量，准备兜底，快速回滚。
6. 监控迭代：回收badcase，持续优化，定期回归。

技术选型是产品经理参与最深的部分。下面这个决策表，可以用于内部评审讨论。

这套流程里，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产品实战中比较常见的问题。参考表格，也可以对照自己的项目逐条检查。

这里挑一个重点展开：成本和评测失控是最容易拖垮AI项目的问题。

先说成本。很多团队最初只验证了一个小Demo，没有计算全量用户、高频调用的情况。等上线后，Token账单超出预期，产品才被迫降级。正确做法是产品经理在评审阶段就要求提供单次回答的Token消耗估算，并按日活用户、平均调用次数算出月度成本区间，再决定是否要做缓存、限流或轻量化模型。

再说评测。如果模型升级了，Prompt优化了，知识库换了一批文档，但评测集还是原来那二三十条老问题，那就很难发现新引入的badcase。评测集应该跟着项目成长，每次升级前后都回归一遍。这个习惯一旦养成，项目越到后期，决策效率越高。

还有一点容易被忽略：不要所有事情都让模型做。很多场景，比如固定格式的校验、精确计算、权限判断，传统代码做得又快又准又便宜。AI产品经理要学会判断“这里到底需不需要模型”，而不是“哪里有模型往哪里塞”。

10. 总结与下一步行动

这篇内容想表达的核心观点，可以汇总成一句话：AI产品经理的核心竞争力，是把模型能力翻译成产品需求的能力，以及把产品需求翻译成技术评审问题的能力。

为了支撑这个能力，需要三条线并行修炼：

1. 技术理解线：会调API、理解Token、理解RAG和Agent的核心机制。
2. 产品设计线：定义能力边界、设计兜底方案、制定上线与灰度策略。
3. 评测迭代线：建评测集、跑回归、分析badcase、控制成本。

如果你刚准备转行，或者已经在做AI产品但感觉思路不清晰，建议从下面三个动作开始：

• 跑通一次真实模型调用，哪怕只是调用API打印一句话。
• 给手头产品整理出第一版评测集，不用多，20条就够。
• 找一个具体场景，把“需求→方案→评测→兜底”完整走一遍，然后整理成作品集。

市面上关于AI产品经理的教程和课程很多，数量不是关键，真正拉开差距的是你有没有动手验证过。与其囤一堆资料，不如先把自己手头的第一个小项目做完，把第一次评测跑出来。这个过程跑通了，后面的路会顺畅很多。