企业官网建设流程全解析

这两年，各大公司都在提“AI赋能业务”，但真正能把AI能力落进产品、跑出业务价值的，依然稀缺。我见过太多产品经理，要么把AI当魔法，提需求张口就是“做个智能客服”，要么完全不碰技术细节，被算法工程师一句“这个做不了”就打发回去，需求永远卡在评审会上。

问题出在哪？出在很多人还没完成角色切换。过去的产品经理，核心能力是画原型、写PRD、协调资源，本质上是“把需求翻译成功能”。现在，AI时代的产品经理，核心能力变成了“把业务问题拆解成AI可解的数学模型问题”——你要能听懂模型、懂数据、懂评估，甚至要能理解为什么一个AI功能上线后效果会“飘”。说得直白点，从今天起，产品经理的核心竞争力不再是提需求，而是定义AI的能力边界。

这篇文章不聊算法公式，不劝你去读源码，而是站在一个带过多个AI产品从0到1落地的从业者视角，把AI时代产品经理必须具备的技术认知、需求筛选方法、协作流程、避坑指南，一次性讲清楚，目标是让你看完能直接用在下一份PRD里。

1. AI时代产品经理的认知升级：从“提需求的人”到“定义能力边界的人”

先讲一个我印象很深的例子。某内容社区想做“智能审核”，业务方的原始需求只有一句话：“用AI把违规评论全自动干掉，省掉人工审核团队。”听起来对不对？特别对，但完全没法执行。全自动干掉，误杀率谁承担？广告评论和正常推荐内容的边界怎么画？评论里包含图片、表情、谐音梗怎么处理？模型要跑到多少准确率才能上线？没有一个人说得清。结果这个项目在需求评审阶段就被算法团队毙掉了，原因是“需求不可评估”。

这个例子暴露了很多产品经理的普遍认知误区：把AI当成一个具备通用理解能力的黑盒，觉得训练一下什么都能做。但真实的AI不是这么运作的。AI解决的是“有规律可循、有数据可学、有标准可判”的问题。你抛给它“自动干掉违规评论”，它需要你把“违规”拆解成辱骂、广告、涉政、色情等具体类别，每个类别还要提供样本、标注标准、可接受误差范围。这些东西定义不清楚，模型再好也白搭。

1.1 为什么“业务问题翻译成数学问题”是核心能力

算法工程师训练模型，本质是在做函数拟合：给一堆输入X，预测输出Y。你提的每一个需求，最终都要落到这个范式里。产品经理要做的，是把模糊的业务诉求翻译成清晰的X和Y。

拿“提升搜索转化率”来说。普通人看到的是“搜索体验变好”，但AI产品经理要往下拆：

• X是什么？用户输入的Query、点击过的商品、停留时长、历史订单。
• Y是什么？预测用户是否会点击某个商品，或者是否会下单。
• 用什么模型？排序模型、召回模型。
• 效果怎么评估？点击率、转化率、人均搜索深度。

只有拆到这个颗粒度，算法工程师才知道从哪入手，数据团队才知道要准备什么数据。

1.2 产品经理不需要看懂公式，但必须看懂这四个词

很多产品经理一听到“模型”两个字就发怵，觉得那是算法工程师的事。我负责任地说，你不需要懂公式，但下面这四个词，是所有AI产品沟通的底层语言，必须吃透：

特征。模型的输入。你把用户年龄、地域、点击序列喂给模型，它们就是特征。特征决定了模型能力的上限。产品经理最该介入的地方就是特征设计——你比算法工程师更懂业务，你知道哪些字段对业务是关键变量。

样本。模型的教材。模型是靠“看例子”学会做判断的。你要给它看一万条“违规评论”和一万条“正常评论”，它才能学会分辨。样本的质量直接决定模型效果，比算法本身还重要。

准确率与召回率。准不准确，和全不全。你抓了100个违规评论，其中80个真是违规，准确率就是80%；平台一共有200个违规评论，你抓到80个，召回率就是40%。这两个指标天然是对抗的，抓得越多，误伤越多。产品经理必须知道自己的业务到底更在意哪个，这是AI产品上线前最重要的取舍。

Bad Case。模型判断错的那些例子。这是AI产品迭代最重要的养料。产品经理日常要做的，就是把用户骂得最狠的那些反馈收集起来，变成新一轮的训练数据。

这四个词不需要任何数学基础，理解了它们，你就已经能跟算法工程师进行有效对话了。

2. 产品经理真正需要吃透的五大AI技术能力

AI技术栈这两年更新速度非常快，产品经理不需要追着论文跑，但下面五大类技术，会反复出现在你的需求文档里。每一类我都从“解决什么问题、典型应用场景、需要什么数据条件”三个角度讲，帮你建立一张可以随时查阅的能力地图。

2.1 大语言模型与生成式AI：泛化理解与内容生成

这是现在最火、也是产品经理最容易误解的一类技术。LLM擅长的是“用自然语言完成理解与生成任务”，典型场景包括：智能客服、会议纪要、文案生成、代码辅助、知识库问答。但很多PM把它当成了万能API，什么需求都往Prompt里塞。

实际落地中，LLM的强项是“泛化理解”，弱项是“高精度控制”。你让它写一篇小红书种草文案，它写得八九不离十；你让它从合同里精确抽取20个指定字段、错误率必须低于千分之一，纯靠Prompt根本做不到，必须搭配规则校验、字段拆解和人工兜底。

用LLM做产品，PM要盯住三个东西：模型选型（开源还是商用，本地部署还是API调用）、Prompt工程规范（谁来维护、怎么版本化）、输出质量评估（怎么量化生成结果的好坏，是人工抽评还是模型自动打分）。

2.2 机器学习分类与预测：让系统学会打标签和下判断

这是用得最广、套路最成熟的一类技术，常见场景包括：风险识别（反欺诈、信用评分）、用户画像（兴趣标签、流失预警）、内容推荐（猜你喜欢）、销量预测。

这类技术的核心逻辑是：从历史数据里学规律，然后用规律预测未来。产品经理在提需求时，最容易犯的错是直接丢一个目标，比如“做用户流失预警”，而不定义“流失”到底是什么——是30天不登录算流失，还是连续两个月没有购买行为算流失？定义不同，样本标签就不同，模型学出来的东西就完全不同。

2.3 搜索与推荐：排序逻辑重塑信息分发

凡是流量型产品，都躲不开搜索和推荐。它们的底层原理，一句话说就是“召回+排序”：先从海量内容里粗筛出几百条候选，再用模型给候选打分排序，把最可能打动用户的内容放到最前面。

产品经理介入搜索推荐，不是去调模型参数，而是要建立业务规则与模型排序的协同机制。比如促销商品要不要加权？新品要不要流量扶持？内容涉政要不要一票否决？这些策略必须产品来定，算法来执行。我见过最好的实践，是把搜索推荐的排序结果做成可解释的“分数构成”，每一项业务规则看得见、调得动，产品经理才能真正掌控信息分发。

2.4 计算机视觉与多模态识别：从看懂图像到理解世界

OCR识别、人脸核身、图片审核、视频拆条，都属于这一类。很多PM觉得CV是门槛最高的方向，但站在产品视角，更需要关注的反而是“识别出来了，然后呢”。

比如做“扫描文档自动归档”，技术难点从来不在“识别出文字”，而在识别之后的处理：表格结构要不要还原？手写体和印刷体混排怎么处理？识别置信度低于多少需要转人工？这些才是决定用户体感的关键问题。抠技术细节没有意义，把识别结果和后处理流程设计好才是产品经理的主战场。

2.5 语音交互：听清、听懂、应答的链路拆解

智能客服、语音助手、录音转写，核心链路都一样：语音识别、意图理解、对话管理、语音合成。产品经理在语音产品上最该投入精力的，是把链条本身拆开评估——用户说“太吵了听不见”，到底是识别环节没听清，还是理解环节没听懂？只有分环节定位问题，才能跟对应环节的工程师对话，不然永远在互相甩锅。

3. 需求筛选：怎么判断一个需求到底适不适合用AI解决

AI产品经理每天要面对各种“伪AI需求”。学会筛选，比学会实现更重要。我自己的判断框架很简单，就三步。我会拿三个真实场景来演示，这三个场景我都处理过。

3.1 标准化判断框架：问题本质、数据条件、价值评估

第一步，判断问题本质。AI擅长的是“高频率、有规律、量大到人处理不过来”的任务。如果一个任务，一个熟练员工一天能做200个，且标准非常统一，那大概率适合AI；如果一个任务，连资深专家都要讨论半天才能拍板，那就别碰。

第二步，看数据条件。AI是数据喂出来的。你需要确认两件事：历史数据有没有积累、能不能拿到合法合规的标注数据。没有数据，再聪明的模型也白搭。

第三步，估算ROI。AI项目的前期投入不只是开发成本，还有数据标注成本、模型调优成本、上线后的误判成本。如果这个功能一年也省不了几个人力，或者业务价值很小，那就值得重新考虑。

下面这个判断结果对照表，是我日常工作里直接用的一张表，分享出来：

3.2 第二个步骤：把模糊目标拆成可量化指标（用一个案例演示）

光有框架还不够，我想用案例把“怎么拆”这个过程完整走一遍。

曾经有个业务团队提了个需求：做AI智能外呼，用来做用户回访，目标“提升回访效率”。这个需求看着挺合理，但完全没法开工。“回访效率”是什么？是单位时间能打的电话数，还是回访后用户问题的解决率？方向不同，产品设计天差地别。

我们最后把它拆成了这样：回访时长控制在90秒以内；用户常见问题自助解决率达到60%；需要人工介入的复杂问题，准确转接率不低于95%。拆到这一步，需求才算落地——数据要采什么、模型要算什么、上线后要考核什么，全都有据可查。

3.3 第三个步骤：判断到底用“规则”还是用“模型”

这是很多PM没想过的维度：不是所有问题都需要上AI。有些问题，用传统规则处理更便宜、更稳定。

比如用户输入“我想退款”，用规则匹配关键词就能覆盖80%的情况，为什么还要训练一个意图识别模型？只有当输入表达千变万化、规则怎么写都覆盖不全时，才需要考虑用模型。

实操中，很多场景是“规则+模型”混合：模型做粗筛，规则做精调，最后再人工兜底。这种分层思路，既保证了效果，也控制了成本。产品经理一定要把这个意识刻在脑子里：AI只是工具，不是目的。

4. 和算法工程师高效协作的四个实操闭环

做AI产品，最耗内耗的不是技术难，而是“产品觉得很简单、算法觉得不可行、两边对着空气输出”。要解决这个问题，把协作流程拉成闭环，比任何沟通技巧都管用。下面这四个闭环是我实战下来最有效的，直接拿走就能用。

4.1 一个“数据-指标-样本-验收”四位一体的需求模板

普通PRD写功能描述，AI PRD必须写数据与验收标准。我在团队里推过一个极简模板，四个块：

• 业务目标：一句话说清要解决什么问题。
• 输入数据：模型需要哪些字段、数据从哪里来、存量数据量级多大。
• 效果指标：主指标是准确率还是召回率、容忍的误差是多少、和当前人工基线比要提升多少。
• 验收样例：至少准备50条典型输入，标注好预期输出，上线前先拿这些样例做模型测试。

我的经验是，能把第四块“验收样例”准备好的PM，算法工程师对他的信任度会直接拉满。因为这代表你不是来甩需求的，你是来一起解题的。

4.2 建立Bad Case回流机制：AI迭代的真实发动机

模型上线只是开始，后面的迭代才是真正的马拉松。AI迭代靠什么？靠源源不断的Bad Case。

我是怎么做的？每个AI功能上线第一天，就同时建立反馈通道。用户举报、客服标记、运营抽检，所有被判定为“模型做错”的例子，统一沉淀到样本库，经过清洗、去重、标注之后，定期补充进训练集。这个流程叫做数据闭环，是AI产品能否持续变好的生死线。

有些团队的技术能力很强，模型结构很先进，但产品效果越跑越差，原因就是样本不更新，外部环境变了模型还在用旧数据。产品经理一定要把Bad Case回流当成日常运营，而不是临时任务。

4.3 从离线评估到线上实验：AI上线必须走完的“最后一公里”

上过模型的人都知道，离线测试指标再漂亮，上线一跑就是另一个故事。原因在于离线用的是历史数据，线上面对的是实时、动态的真实流量。这里面有时间差，有各种连开发都想不到的边界情况。

所以AI功能上线，严格来说，必须走“离线评估→影子模式→小流量实验→全量上线”四步。影子模式是很多团队容易跳过的，就是让模型并行跑在实际流量里，但暂时不用它的结果，只做记录和评估。这一步能捕捉到大量离线测试发现不了的问题，也是PM最应该坚持的一步。

上线后，在评估实验结果时要特别留意线上指标是否符合业务预期，还要关注相关性指标，比如推荐功能上线后，人均停留时长有没有变化，点击率提升是否以伤害用户满意度为代价。

5. 从0到1落地一个AI功能的五步方法论

前面讲的都是认知和协作，这一部分我想给出一套真正“从0到1落地AI功能”的完整实操路径。这个方法我在多个项目里用过，节奏清晰，适合产品经理直接拿去排计划。

5.1 定位高价值场景：从“单点突破”而不是“宏大叙事”开始

第一件事永远不是讨论技术，而是从用户反馈、业务投诉、客服记录里找出“量大、痛深、人工重复”的具体场景。范围务必收窄，不贪大。

比如某电商平台要做智能化，第一个落地点选在“售前尺码推荐”而不是“全链路智能导购”。为什么？因为尺码问题占比高、规则相对清晰、效果可量化。一个成功的单点，比五个半死不活的宏大叙事有价值得多。

5.2 准备数据与定义样本：AI项目最耗时间的环节

一旦场景定了，立刻进入数据环节。你需要盘点有没有存量数据，数据质量如何，字段是否完整，还需要规划标注方案。要不要用外包标注？标注规范责任人是PM还是运营？这些都是劳动密集型工作，但决定了模型效果天花板。

这一步我特别想提醒的是，数据合规不能含糊。用户数据的采集和使用必须符合平台规则和相关法规，该脱敏的脱敏，该授权的授权，红线不能碰。

5.3 选择策略：自研模型、调用API还是购买方案

对大多数非AI公司来说，第一时间自研模型，性价比是最低的。我更建议的决策顺序是：先看有没有成熟的开源模型可以直接用，再看有没有商业API可以调，最后才考虑自研。

自研的前提是你的业务足够独特、数据量足够大、且长期成本真的能摊薄。否则，用成熟方案先把业务跑起来，比什么都重要。AI产品经理的使命是解决业务问题，不是证明自己的算法能力。

5.4 从小流量实验开始：不要挑战用户的第一次体验

哪怕内部测试全过，也不要直接全量上线。先放5%流量跑一周，观测核心业务指标有没有恶化，盯有没有被用户骂上热搜。模型对老用户的影响尤其要留意，他们习惯了原逻辑，AI突然改脾气，最容易流失的就是这批人。实验数据达标了，再逐步放开，直到全量。

5.5 持续监控效果并迭代：产品经理要把看数据变成肌肉记忆

上线不是终点。我的习惯是前两周每天看效果看板，每周做一次Bad Case复盘，每两周出一份迭代清单。AI产品没有“做完了”的状态，只有“当前还在持续优化”的状态。产品经理要把这套节奏内化成肌肉记忆，这个产品才算是真正在你手里活了。

6. AI产品的效果度量与数据闭环

很多AI项目失败，不是模型不好，而是从一开始就不知道“什么叫好”。没有效果度量体系，讨论永远停留在感受层面，A/B实验开了也是白开。

6.1 如何建立一套能够真实反映用户价值的指标体系

AI产品的指标体系，不能只看算法指标，必须业务和算法两层结合。算法指标告诉你模型聪明不聪明，但聪明不等于有用。

比如智能搜索，算法指标是Top 5点击率、无结果率；业务指标是搜索转化率、用户平均搜索次数、搜索后投诉量。模型召回做得再好，如果带来的都是不相关的商品，转化率不会骗你。

我的建议是每类指标都要挑出“北极星指标”和“护栏指标”两组。北极星指标是对齐业务目标的那个数，护栏指标是那些绝对不能变差的体验底线。推荐位商品更多了，但用户每次都要多滑很多屏才能找到想要的，这种体验伤害，靠一个点击率指标是发现不了的。

6.2 效果看板怎么搭、同比环比怎么算才不掉坑

AI效果看板，不用一步到位，但基础框架要稳定。我的极简版看板分四块：核心效果、体验监控、数据质量、成本消耗。

做同期比较的时候，特别容易掉坑。节假日、大促、算法策略调整都会导致数据剧烈变化。我自己的规矩是，凡是跑A/B实验的流量，必须和同期不参加实验的流量做对照，同时记录实验期内的所有策略变更，复盘的时候才不会一笔糊涂账。

6.3 A/B实验的正确姿势：不要拿实验组的短处比对照组的长处

A/B实验是AI产品上线前最后一道防线，但很多团队做实验的方法本身就错了。先说几个常见的坑：

• 样本量太小就跑统计检验，结果波动大，看不出真实差异。
• 实验周期太短，新功能的新鲜效应还没消退，结论完全失真。
• 不做分层，实验组里混着高价值用户和低活跃用户，结果被平均。

正确的做法是提前确定样本量、跑足够的周期、做流量分层。拿到实验结果后，还不能只看平均指标，要看细分人群的差异，尤其是弱势人群有没有被伤害。一个功能如果让90%的普通用户受益，却让10%的老用户体验崩塌，上不上线是需要认真权衡的。

7. AI产品经理最容易踩的五个坑

最后这一部分，聊聊我亲眼见过、亲身踩过的坑。每一条都是真金白银换来的经验。产品经理要是能绕开这五个坑，AI项目的成功率至少翻一倍。

7.1 迷信大模型万能论

ChatGPT火了以后，张口闭口“我们接一个大模型进来”成了很多团队的条件反射。但大模型不是万能插座，它有不低的调用成本、有控制不了时延、有一本正经胡说八道的风险。经常有团队花了大力气接入大模型，最后发现一个精确匹配的小模型加几条规则干得更好、更省、更可控。选型永远从业务问题出发，不是从技术热度出发。

7.2 被Demo骗了

很多算法供应商的Demo做得美轮美奂，一上真实数据就垮。我见过某团队选型时被某厂商的演示效果惊艳到，当场拍板合作，结果接进生产环境面对真实的脏数据、错别字、多音字，效果一落千丈。选型阶段一定要拿自己的业务数据去跑测试，真实环境半小时，比看十场PPT都管用。

7.3 低估数据成本

数据标注看起来便宜，但做起来是真的贵且慢。一个千级样本量的分类任务，看起来不难，标注加审核做两周很正常。很多项目的排期会在这里严重失控，是因为PM完全没有把数据准备周期算进项目计划。记住一条经验：数据准备的时间，永远比你想象的要长一倍。

7.4 忽略延迟与成本对体验的影响

线上模型每次推理都要花钱、都要花时间。推荐模块增加一个模型，响应时间多了200毫秒，用户可能感知不到，但算法和服务器成本翻倍是实实在在的。产品经理要在设计阶段就把成本拉进评估维度“这个模型调用一次多少钱、用户量级放大之后扛不扛得住”。

7.5 让AI裸奔上线，没有人工兜底

最危险的一件事，就是AI功能上线的时候没有任何人工处置通路。系统判断错了，用户连找谁投诉都不知道，体验崩塌只是一夜之间的事。哪怕自动化率低一点，也一定要让人工介入的入口保持畅通。AI是帮你干活的，不是帮你背锅的。

最后分享一点个人体会。我在AI产品这条路上最大的一个认知转变，是从“追着技术跑”变成“回到问题本身”。技术永远在变，今天的明星模型明年可能就是旧闻，但“用户的什么诉求没被满足、业务哪个环节效率最低、决策过程中哪里最痛”，这些问题的答案，才是产品经理真正的立足之本。AI产品经理不需要比算法工程师更懂模型，但一定要比任何人都懂业务要什么、数据有什么、边界在哪里。把这个基本功练扎实了，不管是做大模型产品，还是做传统AI功能，你都能稳稳握住方向。