企业官网建设流程全解析

1. 为什么AI产品经理突然成了香饽饽

这两年跟不少做产品的朋友聊天，话题绕来绕去最后总会落到同一个点上：传统产品经理的活儿越来越难干了。倒不是说能力不行，而是整个行业的底层逻辑在变。以前做一个功能，画完原型写完PRD，剩下的交给开发和测试就行，现在呢？老板跑过来说“咱们这个模块加个AI能力吧”，你第一反应可能是懵的——加什么？怎么加？加了之后怎么衡量效果？这一连串问题背后，其实暴露的是传统产品经理知识体系里缺了一块。

AI产品经理这个岗位，说白了就是在这波技术浪潮里被硬生生催生出来的。它不是一个全新的职业，而是产品经理这个角色在AI时代的自然延伸。你依然要懂用户、懂业务、懂数据，但除此之外，你还得理解模型的能力边界在哪里、训练数据从哪来、效果评估怎么做、上线之后模型会不会退化。这些事以前不需要你操心，现在却成了日常。

我写这份入门手册的初衷很简单：市面上讲AI技术的资料很多，讲传统产品方法论的书也很多，但把这两者结合起来、告诉一个普通产品经理该怎么上手AI项目的材料，少得可怜。很多刚转岗的朋友跟我吐槽，说看了一堆机器学习教程，公式推导能看懂，但回到工位上还是不知道第一步该干嘛。这份手册就是解决这个问题的——它不教你写代码，也不教你调参，它教的是：当你接到一个AI产品需求时，从哪开始想、按什么顺序做、每个环节的关键决策点在哪里。

适合看这份手册的人，我大致分了三类。第一类是从传统产品岗转AI方向的，你可能已经做了三五年产品，对业务很熟，但对AI那套东西只有模糊认知。第二类是技术背景转产品的，比如算法工程师或者数据开发想往产品方向走，你的技术底子够，但缺的是产品思维和落地经验。第三类是在校生或者刚入行的新人，你想提前布局这个方向，但不知道从哪学起。不管你是哪一类，这份手册的目标都是让你读完能有一个清晰的行动框架，而不是一堆零散的知识点。

2. 先搞清楚AI产品经理到底在管什么

2.1 和传统产品经理的核心差异在哪

很多人以为AI产品经理就是“懂点AI的产品经理”，这个理解太浅了。两者的差异不是知识面的宽窄，而是工作对象发生了根本变化。传统产品经理的工作对象是确定性的功能逻辑——你点击一个按钮，系统执行一个操作，结果是可以预期的。AI产品经理的工作对象是不确定性的模型行为——你输入一段文本，模型输出什么，取决于训练数据、模型结构、解码策略等一大堆变量，结果是有概率分布的。

这个差异带来了一系列连锁反应。传统产品里，你写完PRD基本就定型了，开发按文档实现就行。AI产品里，PRD只是起点，后面还有数据准备、模型选型、训练调优、效果评估、上线监控、迭代优化，每一个环节都可能推翻你之前的假设。我见过太多项目，产品经理兴冲冲地写完需求文档，结果数据团队说“这个场景没有标注数据”，或者算法团队说“当前模型架构做不到这个精度”，整个方案就得推倒重来。

还有一个容易被忽略的差异是效果衡量的方式。传统产品看DAU、留存率、转化率这些指标就够了，AI产品除了这些业务指标，还得看模型层面的指标——准确率、召回率、F1值、响应延迟、推理成本。而且这两层指标之间往往不是线性关系。模型准确率从85%提到90%，业务转化率可能纹丝不动；但从90%提到95%，转化率可能突然翻倍。这种非线性关系，是AI产品经理必须习惯的思维方式。

2.2 一个AI产品从想法到上线的完整链路

我把AI产品的落地链路拆成六个阶段，每个阶段产品经理的参与深度不同，但都不能当甩手掌柜。

第一阶段是场景定义。这个阶段的核心问题是：这个场景到底适不适合用AI解决？很多需求其实用规则引擎就能搞定，硬上AI反而增加成本和不确定性。判断标准我后面会详细讲，这里先记住一个原则——AI擅长处理模糊的、高维的、难以用规则穷举的问题，如果你的场景可以用if-else写清楚，那就别碰AI。

第二阶段是数据盘点。这是最容易被低估的环节。你需要搞清楚：有没有现成的标注数据？数据质量怎么样？标注成本大概多少？如果要从零开始标注，周期是多久？这些问题不搞清楚，后面的方案都是空中楼阁。我见过一个团队，模型都选好了，代码也写完了，最后发现训练数据只有几百条，根本训不出效果，整个项目延期了三个月。

第三阶段是方案设计。这里要确定的是技术路线——是用现成的API，还是自己训练模型？是用大模型做微调，还是用小模型做蒸馏？不同的选择对应不同的成本结构、开发周期和效果上限。产品经理不需要自己做技术决策，但必须理解每个选项的trade-off，才能在资源有限的情况下做出合理取舍。

第四阶段是开发与调优。这个阶段产品经理的角色更像是“翻译”——把业务需求翻译成算法团队能理解的技术指标，同时把技术限制翻译成业务方和老板能理解的语言。很多项目死在这个阶段，不是因为技术做不到，而是因为双方对“做到什么程度算好”没有达成共识。

第五阶段是评估与验收。AI产品的验收标准和传统产品完全不同。传统产品是“功能有没有实现”，AI产品是“效果有没有达到预期”。这个预期怎么定？定高了团队压力大，定低了上线被用户骂。我的经验是，在项目启动时就定一个“最低可接受线”和一个“理想目标线”，验收时看是否过了最低线，而不是纠结有没有达到理想线。

第六阶段是上线与迭代。AI产品上线不是终点，而是起点。模型会随着数据分布的变化而退化，用户行为会随着模型的表现而改变，这些都是传统产品不会遇到的问题。你需要建立一套监控机制，定期看模型指标和业务指标的变化，及时触发重新训练或策略调整。

2.3 能力模型：技术理解力、数据敏感度、业务判断力

AI产品经理的能力模型，我总结成三个维度，缺一不可。

技术理解力不是要求你会写代码，而是要求你能和算法工程师顺畅对话。你知道Transformer的基本结构，知道BERT和GPT的区别，知道什么是过拟合、什么是欠拟合，知道模型推理的延迟大概在什么量级。这些知识不需要你亲手实现，但需要你理解它们的含义和影响。举个例子，算法团队说“这个模型推理延迟200毫秒”，你得立刻反应过来：这个延迟对用户体验意味着什么？如果是搜索场景，200毫秒可以接受；如果是实时对话场景，200毫秒可能就太慢了。

数据敏感度是AI产品经理最核心的竞争力。传统产品经理看数据看的是业务指标，AI产品经理看数据看的是数据本身——数据量够不够、分布均不均衡、标注质量高不高、有没有偏差。我见过一个案例，一个情感分析模型在测试集上准确率95%，上线后用户投诉不断。排查发现，测试集的数据分布和真实用户输入完全不同——测试集都是完整的句子，真实用户输入大量是短文本、错别字、网络用语。这就是数据敏感度不够导致的翻车。

业务判断力是产品经理的老本行，但在AI场景下有了新的含义。你需要判断的是：这个AI功能对业务的价值到底是什么？是提升效率、降低成本，还是创造新的用户体验？不同的价值定位对应不同的投入策略。如果只是降本，那ROI算得过来就行；如果是创造新体验，那可能需要容忍前期的不完美，快速迭代。

3. 入门第一步：搞懂AI产品的几种常见形态

3.1 判别式与生成式，到底怎么区分

AI产品按输出类型分，可以粗暴地分成两大类：判别式和生成式。判别式模型做的是“分类”或“预测”的活儿——给你一张图片，判断是不是猫；给你一段文本，判断情感是正面还是负面；给你一个用户行为序列，预测他会不会流失。生成式模型做的是“创造”的活儿——给你一段提示词，生成一篇文章；给你一张草图，生成一张完整的设计图；给你一段旋律，续写后面的部分。

这个区分为什么重要？因为两类产品的设计逻辑完全不同。判别式产品的核心是“准确率”，你需要关注的是模型在各类样本上的表现是否均衡，有没有在某些类别上特别差。生成式产品的核心是“可控性”和“多样性”，你需要关注的是模型输出是否符合预期、有没有创意、会不会产生有害内容。

我刚开始接触的时候也搞混过，觉得都是AI，能有多大区别。后来做了一个文本分类的项目，又做了一个文案生成的项目，才发现完全是两码事。分类项目里，模型输出一个标签就完事了，产品经理的工作重点是定义标签体系和评估标准。生成项目里，模型输出一段文本，产品经理要定义的是“什么样的输出算好”——是流畅？是有信息量？是符合品牌调性？这些标准很难量化，但又必须量化，否则没法迭代。

3.2 从API调用到自训练，成本差在哪

AI产品的技术实现路径，从轻到重大致分三档。

最轻的是调用现成的API。比如你要做一个文本摘要功能，直接调用某个大模型平台的摘要接口就行。优点是开发周期短、成本低、不需要维护模型。缺点是效果受限于API提供方的能力，定制化空间小，而且长期来看调用成本会随着用量增长而累积。

中间档是微调现成模型。你拿一个开源的基础模型，用自己的数据做微调，让它在你的特定场景下表现更好。优点是效果比通用API好，成本比从头训练低。缺点是你需要准备标注数据，需要一定的算法能力来做微调，而且微调后的模型需要自己部署和维护。

最重的是从头训练模型。这通常只在你有海量数据、有明确的差异化需求、有充足的算法团队时才考虑。优点是效果上限最高，完全自主可控。缺点是成本极高、周期极长、风险极大。我个人的建议是，除非你是做底层技术平台的公司，否则绝大多数业务场景都不需要走到这一步。

成本差异有多大？我拿一个实际项目举例。调用API的方案，开发周期两周，每月调用成本几千块。微调方案的开发周期两个月，需要标注五千条数据，标注成本大概两万，加上GPU训练成本和部署成本，前期投入大概五到八万。从头训练方案的开发周期至少半年，需要十万条以上的标注数据，算法团队至少三人，前期投入轻松过百万。所以选哪条路，本质上是在效果、成本、周期之间做权衡。

3.3 不同形态对应的产品设计要点

判别式产品的设计要点是“定义清楚分类体系”和“处理边界情况”。分类体系要互斥且完备，不能出现“既属于A又属于B”或者“哪个都不属于”的情况。边界情况要提前想好——模型置信度低的时候怎么办？是返回“无法判断”还是走人工审核？这些决策直接影响用户体验。

生成式产品的设计要点是“控制输出质量”和“管理用户预期”。输出质量控制包括长度控制、格式控制、内容安全控制。用户预期管理包括告诉用户这个功能能做什么、不能做什么，以及在模型输出不理想时提供反馈渠道。我见过一个生成式产品，用户输入一个问题，模型有时候回答得很好，有时候胡言乱语，用户很快就失去信任了。后来加了一个“置信度提示”，低置信度的回答会标注“此回答可能不准确”，用户投诉率立刻降了一半。

还有一种混合形态，比如“检索增强生成”——先从知识库里检索相关内容，再让模型基于检索结果生成回答。这种形态在产品设计上要同时考虑检索质量和生成质量，复杂度更高，但效果也更可控。适合知识问答、客服助手这类场景。

4. 数据这件事，比你想的复杂得多

4.1 训练数据从哪来：自有、采购、标注

训练数据的来源无非三种：自有数据、采购数据、标注数据。

自有数据是你业务运转过程中自然积累的。比如电商平台有用户评论、客服对话记录、商品描述文本。这些数据的优点是真实、贴合业务场景，缺点是往往没有标注，而且可能存在偏差。比如你的用户主要是年轻人，那评论数据就不能代表全年龄段用户的表达习惯。

采购数据是从第三方数据服务商那里买来的。优点是省时省力，缺点是质量参差不齐，而且可能和你的业务场景不匹配。我买过几次数据，踩过的坑包括：标注标准不统一、数据格式混乱、样本重复率高。后来学乖了，采购之前一定要先要样本试标，确认质量再批量买。

标注数据是自己组织人力标注的。这是最可控的方式，但成本也最高。标注成本取决于任务复杂度——简单的分类标注，一条可能几毛钱；复杂的实体识别或者情感细粒度标注，一条可能要几块钱。而且标注质量的管理是个大问题，你需要制定详细的标注规范，做标注一致性检验，还要处理标注员之间的分歧。

我的经验是，能用自有数据就用自有数据，自有数据不够再考虑采购，采购的数据也要做质量筛查。标注数据是最后的选择，但也是最可靠的选择。如果决定自己标注，一定要先小批量试标，算清楚标注效率和一致性，再决定要不要扩大规模。

4.2 标注质量怎么控：规范、培训、抽检

标注质量直接决定模型效果的上限。垃圾数据训出来的模型，再好的算法也救不回来。控制标注质量，我总结了三步法。

第一步是制定标注规范。规范要细到什么程度？我举个例子，做一个情感分类任务，规范里不能只写“正面、负面、中性”三个标签，还要写清楚：带有讽刺意味的文本怎么标？包含正面和负面混合情感的文本怎么标？只有标点符号没有实际内容的文本怎么标？这些边界情况不写清楚，不同标注员的理解就会不一致。

第二步是标注员培训。培训不是把规范发下去就完事了，要组织试标，让每个标注员标同一批数据，然后对比结果，找出分歧点，统一理解。这个过程通常要反复两三轮，直到标注员之间的一致性达到可接受的水平。一致性怎么衡量？常用的是Kappa系数，一般要求达到0.8以上才算合格。

第三步是抽检。标注过程中要持续抽检，发现质量下降及时纠正。抽检比例我一般建议10%到20%，太低了发现不了问题，太高了成本吃不消。抽检发现错误的样本，要反馈给标注员，让他们知道错在哪、为什么错。如果某个标注员的错误率持续偏高，可能需要重新培训或者调整任务分配。

4.3 数据偏差：那些让模型翻车的隐形陷阱

数据偏差是AI产品最隐蔽的杀手。它不会在测试集上暴露出来，但会在真实场景中给你致命一击。

常见的偏差类型有几种。样本选择偏差——你的训练数据只覆盖了部分用户群体，模型对其他群体表现很差。比如你的人脸识别模型训练数据主要是浅色皮肤的人，那对深色皮肤的人识别率就会明显下降。标注偏差——标注员的个人倾向影响了标签质量。比如标注员普遍对某个品牌有好感，那包含这个品牌的文本就更容易被标成正面。时间偏差——训练数据是某个时间段采集的，但真实场景的数据分布随时间变化。比如疫情期间的电商评论和疫情后的评论，情感分布完全不同。

怎么发现偏差？最直接的方法是做分层评估。不要只看整体准确率，要把测试集按不同维度切分——按用户年龄切、按地域切、按时间切——看模型在每个子集上的表现是否均衡。如果某个子集的表现明显低于平均水平，那就是偏差的信号。

发现偏差之后怎么处理？如果是数据层面的偏差，可以通过补充采样来平衡。如果是标注层面的偏差，需要重新审视标注规范，或者引入多个标注员做交叉验证。如果是时间层面的偏差，需要建立定期更新训练数据的机制。偏差不可能完全消除，但可以通过持续监控和迭代把它控制在可接受范围内。

5. 模型选型：不选最贵的，选最合适的

5.1 开源模型和商业API的取舍

开源模型和商业API的选择，本质上是在可控性和便利性之间做权衡。

商业API的优势是开箱即用、效果稳定、不需要维护。你不需要关心模型架构、不需要准备GPU、不需要处理并发和扩容。缺点是定制化空间有限、数据隐私有顾虑、长期成本可能更高。而且商业API的效果是“黑盒”，你只能通过输入输出来推测它的能力边界，没法深入优化。

开源模型的优势是可控性强、可以深度定制、数据不出自己的服务器。缺点是部署和维护成本高、需要算法团队支持、效果可能不如头部商业API。而且开源模型的选择本身就是一个坑——不同模型在不同任务上的表现差异很大，你需要做大量的对比实验才能找到最适合的那个。

我的建议是分阶段选择。项目初期，用商业API快速验证场景可行性，确认有需求之后再考虑迁移到开源模型。迁移的时机取决于两个因素：调用成本是否已经超过自建成本，以及定制化需求是否商业API无法满足。不要一上来就自建，也不要永远依赖API。

5.2 模型评估的四个核心指标

模型评估不能只看准确率，那是最容易骗人的指标。我通常看四个维度。

准确率是最直观的，但也是最容易误导的。如果数据分布不均衡，准确率会虚高。比如一个二分类任务，正样本占95%，负样本占5%，模型把所有样本都预测成正类，准确率也有95%，但这个模型毫无价值。所以看准确率的同时一定要看召回率和精确率。

召回率衡量的是“该找出来的有没有找出来”，精确率衡量的是“找出来的对不对”。这两个指标往往此消彼长，需要根据业务场景做取舍。比如垃圾邮件过滤，你希望召回率高——宁可错杀不可放过；但如果是法律文书检索，你希望精确率高——不能把不相关的文书推给律师。

F1值是精确率和召回率的调和平均，适合需要平衡两者的场景。但F1值也有局限，它假设精确率和召回率同等重要，实际业务中未必如此。

除了这三个统计指标，还要看推理延迟和成本。一个准确率95%但延迟2秒的模型，和一个准确率90%但延迟200毫秒的模型，选哪个？取决于你的场景。搜索场景可能选后者，离线分析场景可能选前者。成本也是同理，准确率提升5%但成本翻三倍，值不值得？算ROI。

5.3 小模型+好数据 vs 大模型+少数据

这是一个经典的选择题。我的经验是：数据质量比模型大小更重要。

小模型加高质量数据，往往能打败大模型加低质量数据。原因很简单——模型再大，如果训练数据噪声太多，它学到的就是噪声。而一个结构简单的小模型，如果训练数据干净、标注准确、覆盖全面，它能在特定任务上表现得非常好。

我做过一个对比实验。同一个文本分类任务，用大模型加五千条低质量标注数据，准确率82%；用小模型加两千条高质量标注数据，准确率87%。而且小模型的推理速度快了五倍，部署成本只有大模型的十分之一。

当然，这不是说大模型没用。大模型的优势在于泛化能力和少样本学习能力。如果你的任务很复杂、数据很难获取、需要模型具备一定的推理能力，那大模型是更好的选择。但如果你的任务定义清晰、数据可以批量标注，那小模型加好数据是性价比更高的方案。

选择的关键在于：先问自己“我的任务到底有多复杂”，再问“我能拿到多少高质量数据”，最后才问“我该用多大的模型”。顺序不能反。

6. 从需求到方案：AI产品经理的日常决策

6.1 怎么判断一个需求该不该用AI做

不是所有需求都适合用AI。我有一套简单的判断流程。

先问：这个问题的规则能不能穷举？如果能，就别用AI。比如“如果用户年龄大于18岁且所在地区是A，就展示内容B”，这种逻辑用规则引擎实现，稳定可靠，成本低。用AI反而引入不确定性。

再问：这个问题的输入是不是高维的、模糊的？AI擅长处理的是那些难以用规则描述的输入——图片、语音、自然语言文本。如果你的输入是结构化的表格数据，传统机器学习方法可能就够了，不需要上深度学习。

再问：这个问题的容错率有多高？AI产品不可能100%准确，你需要评估错误带来的后果。推荐系统推错了，用户划走就行；医疗诊断系统判断错了，后果可能是致命的。容错率低的场景，AI只能做辅助，不能做决策。

最后问：有没有足够的数据？没有数据就没有AI。如果数据量不够，要么先积累数据，要么用规则方案过渡，要么调整需求范围。

6.2 需求文档里必须写清楚的五件事

AI产品的需求文档和传统PRD有重叠，但多了几个必须写清楚的部分。

第一是场景描述。要具体到用户是谁、在什么情况下使用、期望得到什么结果。不要写“用户输入文本，系统返回分类结果”，要写“客服人员在处理用户投诉时，将投诉内容粘贴到输入框，系统自动判断投诉类型并推荐对应的处理流程”。

第二是数据要求。训练数据从哪来、需要多少条、标注标准是什么、什么时候能准备好。这部分不写清楚，后面全是扯皮。

第三是效果指标。除了业务指标，还要定义模型指标。准确率最低要求是多少？召回率最低要求是多少？推理延迟上限是多少？这些指标要在项目启动时就达成共识。

第四是边界情况处理。模型置信度低的时候怎么办？输入超出模型能力范围时怎么办？模型输出有害内容时怎么办？这些都要有明确的处理策略。

第五是迭代计划。上线之后多久评估一次？什么条件下触发重新训练？迭代的负责人是谁？没有迭代计划的AI产品，上线即巅峰，然后一路下滑。

6.3 和算法团队协作的正确姿势

和算法团队协作，最怕的是两种极端：一种是产品经理什么都不懂，算法说什么就是什么；另一种是产品经理瞎指挥，强行要求算法实现做不到的事情。

正确的姿势是：产品经理负责定义“做什么”和“做到什么程度”，算法团队负责定义“怎么做”和“能不能做到”。双方在“效果指标”和“资源投入”上达成共识，然后各自在自己的领域内做决策。

具体来说，产品经理要能回答：这个功能对业务的价值是什么？用户能接受的最低效果是多少？如果效果不达标，备选方案是什么？算法团队要能回答：当前方案的效果上限大概在哪？需要多少数据和算力？主要的技术风险是什么？

沟通的时候，产品经理要避免说“这个模型不够聪明，再调调”，而要说“当前准确率是85%，业务要求至少90%，我们看看是数据问题还是模型问题”。前者是外行话，后者是专业对话。

还有一个实用技巧：定期和算法团队一起看bad case。不要只看指标，要看具体哪些样本预测错了、为什么错。bad case分析往往比指标更能发现问题——是数据标注错了？是场景覆盖不全？还是模型本身的能力边界？这些问题看指标看不出来，看具体案例一目了然。

7. 上线只是开始：AI产品的持续运营

7.1 模型退化：一个容易被忽视的定时炸弹

模型退化是AI产品特有的问题。传统软件上线后，只要代码不改，行为就是稳定的。AI模型不一样，它的表现会随着外部环境的变化而下降。

退化的原因主要有三个。数据分布漂移——用户行为变了，输入数据的统计特征和训练时不一样了。比如一个商品推荐模型，训练时用户主要浏览服装，上线后用户开始大量浏览电子产品，推荐效果就会下降。概念漂移——同样的输入，正确的输出变了。比如一个新闻分类模型，训练时“元宇宙”属于科技类，后来这个词被大量用于地产营销，分类边界就模糊了。反馈循环——模型推荐什么，用户就消费什么，导致训练数据被模型自身的行为污染。

监控模型退化，需要建立一套指标体系。我通常监控三个层面：输入层面看数据分布的变化，比如文本长度分布、关键词频率分布；输出层面看预测结果的分布变化，比如各类别的预测比例；业务层面看核心业务指标的变化。三个层面结合起来，能比较早地发现退化信号。

7.2 用户反馈怎么收集和利用

用户反馈是模型迭代的宝贵数据源，但收集和利用都有讲究。

收集反馈的方式要尽量降低用户成本。让用户填问卷是最差的，没人愿意填。好的方式是嵌入使用流程——比如在模型输出旁边放一个“有帮助/没帮助”的按钮，或者在用户修改模型输出时自动记录修改前后的内容。后者尤其有价值，因为用户修改后的版本就是“正确答案”。

利用反馈数据要注意清洗。用户反馈里噪声很大——有人随手点“没帮助”，有人恶意刷反馈，有人反馈的内容和模型输出无关。我一般会先做一轮人工筛查，把明显无效的反馈剔除，再用剩下的数据做分析。

反馈数据的用途有两个：一是发现bad case，找到模型的薄弱环节；二是作为增量训练数据，持续优化模型。但增量训练要谨慎，因为用户反馈的数据分布和真实分布可能有偏差——愿意反馈的用户往往是比较极端的，要么特别满意，要么特别不满，中间沉默的大多数没有发声。

7.3 迭代节奏：什么时候该重新训练

重新训练的时机，不能拍脑袋决定，要有数据支撑。

我通常设三个触发条件。第一是模型指标下降到阈值以下，比如准确率从90%掉到85%以下。第二是业务指标出现异常，比如推荐点击率连续一周下降超过10%。第三是积累了足够的新标注数据，比如新增标注数据达到训练集规模的20%以上。

三个条件满足任意一个，就启动重新训练评估。但重新训练不是无脑跑一遍就完事，要先分析退化原因——是数据问题就补数据，是标注问题就修标注，是模型问题才调模型。不分析原因就重新训练，往往解决不了根本问题。

迭代频率取决于业务变化速度。变化快的场景，比如新闻推荐、热点追踪，可能需要每周甚至每天更新。变化慢的场景，比如法律文书分类，可能半年更新一次就够了。关键是建立监控机制，让数据告诉你什么时候该迭代，而不是凭感觉。

8. 新手最容易踩的五个坑

8.1 追求完美效果，迟迟不上线

这是新手AI产品经理最常见的毛病。总觉得模型还不够好，再调调，再等等。结果竞品上线了，用户被抢走了，自己还在实验室里调参。

AI产品的正确心态是“先上线，再迭代”。一个70分的模型上线，收集真实用户反馈，可能两周就能迭代到80分。而在实验室里闭门造车，从70分调到80分可能要两个月，而且调出来的80分在真实场景中可能只有60分——因为实验室数据和真实数据分布不一样。

我的建议是设定一个“最低可接受线”，达到就上线。上线之后快速迭代，用真实数据驱动优化。当然，前提是错误不会造成严重后果。如果场景容错率极低，那确实需要更谨慎。

8.2 忽视数据标注的工期和成本

很多项目延期，不是算法做不出来，而是数据没准备好。标注数据看起来简单——找几个人标一下就行——实际上工期和成本都容易失控。

标注工期取决于三个因素：数据量、任务复杂度、标注员熟练度。一个中等复杂度的分类任务，一个熟练标注员一天大概能标500到1000条。如果你需要五万条数据，那至少需要50到100人天。这还不包括标注规范制定、标注员培训、质量抽检的时间。

成本方面，简单任务一条几毛钱，复杂任务一条几块钱。五万条数据，成本可能从一两万到十几万不等。这些都要在项目启动时就估算清楚，写进项目计划。

8.3 把AI当万能药，什么场景都往上套

AI不是万能的。有些场景用规则引擎更合适，有些场景用传统统计方法更合适，有些场景根本不需要自动化。

我见过一个项目，做一个简单的表单校验功能，非要上AI。结果模型训练了两周，准确率还不如正则表达式。这就是典型的“拿着锤子找钉子”。

判断标准很简单：如果这个问题的规则可以穷举，或者用简单的统计方法就能解决，那就别用AI。AI应该用在那些规则难以描述、传统方法效果不好的场景。

8.4 不重视bad case分析

只看指标不看bad case，是AI产品经理的大忌。指标是宏观的，bad case是微观的。宏观指标告诉你“有问题”，微观案例告诉你“问题在哪”。

我养成了一个习惯：每周抽半天时间，和算法团队一起看bad case。随机抽100条预测错误的样本，一条一条分析——是标注错了？是场景没覆盖？是模型能力不够？还是需求定义本身有问题？这个过程往往能发现指标上看不到的问题。

比如有一次，我们发现模型在短文本上的准确率特别低。看指标只看到整体准确率下降了2%，看bad case才发现，下降主要来自长度小于10个字的输入。进一步排查发现，训练数据里短文本占比不到5%，模型根本没学好。后来补充了短文本数据，问题就解决了。

8.5 上线后不管了，等出问题再救火

AI产品上线不是终点，而是起点。模型会退化，用户行为会变化，竞品会迭代。如果你上线后就不管了，三个月后模型效果可能下降20%。

建立监控机制是必须的。至少要有：模型指标周报、业务指标日报、异常告警。发现异常及时排查，不要等到用户投诉了才反应过来。

还有一点：保留人工兜底方案。AI产品不可能100%可靠，关键场景一定要有人工审核或人工客服兜底。这不是对AI没信心，而是对用户体验负责。

9. 上手路径：从今天开始你能做什么

9.1 第一周：建立认知框架

如果你刚接触AI产品，第一周不要急着学技术细节。先建立认知框架——搞清楚AI产品有哪些类型、每种类型的产品逻辑是什么、AI产品经理的日常工作是什么。

具体行动：找三五个AI产品的案例分析，最好是不同形态的——一个判别式的、一个生成式的、一个混合式的。分析它们的场景定义、数据策略、模型选型、效果指标、迭代方式。不用深入技术细节，重点是理解产品逻辑。

同时，把这份手册里提到的概念过一遍——判别式、生成式、准确率、召回率、F1值、数据偏差、模型退化。不需要深入理解，但要知道这些词是什么意思、在什么场景下用。

9.2 第二周：找一个真实场景练手

光看不动手，永远学不会。第二周找一个真实场景练手——可以是你当前工作中的一个小需求，也可以是你自己感兴趣的一个小项目。

练手的重点不是做出一个完美的AI产品，而是走一遍完整流程：定义场景、盘点数据、设计方案、评估效果。哪怕数据只有几百条，模型效果很差，这个过程中你学到的东西比看十篇文章都多。

我建议从判别式任务开始，比如文本分类、情感分析。这类任务定义清晰、评估简单、数据标注成本低，适合新手。生成式任务的不确定性太高，容易打击信心。

9.3 第三周：深入一个技术点

第三周选一个技术点深入。不要贪多，选一个就好。比如你选了“数据标注”，那就把标注规范怎么定、标注质量怎么控、标注成本怎么算搞清楚。或者你选了“模型评估”，那就把准确率、召回率、F1值、AUC、混淆矩阵这些指标的含义和适用场景搞清楚。

深入的方式可以是看资料、做实验、找人聊。我个人的经验是，做实验最有效。比如你想理解准确率和召回率的区别，就自己造一批数据，手动算一遍，看看不同阈值下两个指标怎么变化。这种亲手算过的知识，比看十遍书都记得牢。

9.4 第四周：输出一份完整的方案文档

第四周把前三周的积累整合起来，输出一份完整的AI产品方案文档。文档不需要很长，但要把关键部分写清楚：场景描述、数据计划、技术路线、效果指标、迭代计划、风险预案。

写完之后找有经验的人帮你看一遍，听听反馈。如果没有这样的人，就自己对照这份手册检查——场景定义清楚了吗？数据来源明确了吗？效果指标可衡量吗？边界情况考虑了吗？迭代计划有吗？

这份文档就是你入门的证明。拿着它去面试或者申请转岗，比说“我对AI很感兴趣”有说服力得多。

10. 一些掏心窝子的经验

做AI产品这几年，踩过的坑比做成的事多。有几个体会特别深。

第一个体会是：AI产品的核心竞争力不在技术，在场景理解。技术是通用的，谁都能用；但场景理解是独特的，只有深入业务的人才能做好。我见过太多技术很强的团队，做出来的AI产品没人用，就是因为场景选错了。也见过技术一般的团队，因为对场景理解深刻，做出来的产品用户很喜欢。

第二个体会是：数据工作占AI产品70%的时间，但只有30%的讨论。大家都在聊模型架构、聊算法创新，但真正决定效果的是数据质量。我现在的习惯是，项目启动先花两周时间盘数据，数据盘不清楚，后面都是白搭。

第三个体会是：AI产品经理要懂技术，但不能沉迷技术。你的价值在于连接业务和技术，而不是替代算法工程师。你可以不懂Transformer的每一层结构，但你要知道Transformer适合什么场景、不适合什么场景。你可以不会写训练代码，但你要能判断模型效果好不好、为什么不好。

第四个体会是：接受不完美。AI产品永远有bad case，永远有提升空间。追求完美会导致项目永远上不了线。正确的做法是定义“足够好”的标准，达到就上线，然后在真实环境中持续迭代。上线后的真实反馈，比实验室里的完美指标有价值得多。

第五个体会是：保持学习。AI领域变化太快了，去年好用的方法今年可能就过时了。但底层的东西变化没那么快——场景定义、数据管理、效果评估、迭代优化，这些核心能力是稳定的。把精力放在这些不变的东西上，比追每一个新模型、新框架更有价值。

这份手册的上篇到这里就差不多了。下篇我会展开讲几个具体的实战案例——文本分类、推荐系统、对话机器人，每个案例都会拆解从需求到上线的完整过程，包括踩过的坑和解决方案。如果你正在做或者准备做AI产品，希望这些内容能帮你少走点弯路。