企业官网建设流程全解析

1. 先搞清楚一件事：AI产品经理到底在做什么

最近两年我身边越来越多做传统产品经理的朋友问我同一个问题：现在转型AI产品经理还来得及吗？每次我都会反问一句：你先说说看，你觉得AI产品经理和普通产品经理最大的区别是什么？十个人里有八个会回答“要懂技术”，还有一两个会说“要会写提示词”。说实话，这两个答案都不太对。

这个岗位的底层逻辑，和过去二十年互联网产品经理完全不同。传统产品经理做的是确定性产品：用户点这个按钮，页面就跳到那里；提交订单，系统就扣款。每一步都是可控的、可预期的。而AI产品经理做的产品，核心是概率系统：同一个问题，模型今天回答的和明天回答的不一样，同一个Prompt在不同参数下输出的质量天差地别。你没法像传统PM那样写一个“按钮点击后跳转A页面”的确定性需求，你得学会和不确定性共事。

所以我要把话说在前面：如果你打算转行，先别急着学Prompt技巧，也别急着刷大模型API文档。你得先建立一套从需求洞察到产品落地的全链路能力框架，知道每个环节要做什么、会踩什么坑、怎么判断做得好不好。这套框架，就是我在一线做了几十个AI项目后沉淀下来的核心方法论，今天完整拆给你。

这个岗位适合谁？两类人特别合适：一是有过至少一两年B端或C端产品经验、想往AI方向升级的PM，二是有技术背景但不想写代码、想往产品方向转的工程师。刚毕业完全没做过产品的人直接上手会有点吃力，因为你缺少对“用户真实场景”的判断力，而这个东西在AI产品里比技术本身更致命。

1.1 AI产品经理的能力全景图

我习惯把AI产品经理的核心能力拆成四层，很多人只看到最上面那一层，其实真正决定成败的是下面三层。

第一层是需求洞察能力。这一步不是普通用户访谈和竞品分析，而是要学会判断“这事该不该用AI做”。我见过太多团队花三个月做了一个“AI智能助手”，最后用户根本不用——因为原本搜索引擎三秒钟就能解决的事，你非要让他打开对话框输入问题再等五秒响应，这不是提升效率，是降低效率。

第二层是技术理解能力。不需要你会写模型训练代码，但你得知道模型的能力边界在哪里，知道什么是幻觉、什么是上下文窗口、什么是RAG，知道同样的需求用提示词工程能解决还是必须微调。这些概念不是用来在面试时背的，是你做方案取舍时的决策依据。

第三层是方案设计与落地能力。AI产品从来不是一个模型就完事的，它背后是数据链路、评估体系、兜底策略、灰度机制、成本控制一整套工程。这层能力决定了你做的“AI产品”是停留在技术Demo阶段，还是能真正稳定跑在生产环境里。

第四层是商业价值判断能力。团队找你做AI产品，不是让你来玩大模型的，是要看到业务指标的提升。你做的是智能客服，那就得多算算人工客服成本降了多少；你做的是内容生成工具，那得看看用户生成内容的采纳率。没有商业价值的AI项目，在公司里活不过两个季度。

1.2 这类岗位每天都在解决什么问题

给你一个真实的工作场景。我做过一个智能工单系统，用户提交问题后自动分单给对应部门。传统做法是规则引擎，写几百条关键字规则来匹配，覆盖率做到90%就到头了。老板说，用AI来分单吧。

这时候需求洞察的问题来了：AI分单到底解决的是什么问题？表面看是“替代规则引擎”，实际上是“处理那些规则覆盖不了的长尾问题”。所以方案不是直接上一套大模型接口就完事，而是要做成两层架构：高置信度的、常见的问题继续走规则引擎，低置信度的、长尾的问题走AI模型。最后模型负责兜底，把覆盖率从90%拉升到97%。

这个案例里有几个关键决策点：技术选型（规则+AI混合）、评估标准（分单准确率、覆盖率）、成本控制（只对模型低置信度的样本才调用大模型API，因为API按Token计费，全量调用成本受不了）。这就是AI产品经理的日常——不是在写Prompt调参，而是在一堆约束条件下做系统性决策。

我特别强调一句：AI产品经理不是“会写提示词的产品经理”，提示词只是你工具箱里最基础的一个工具。真正的挑战在于，你得同时理解用户痛点、业务目标、技术边界、数据条件、成本约束，并且在这几个维度之间找到最优解。这才是“全链路”这三个字的真正含义。

2. 需求洞察：怎么找到“真需求”而不是“伪需求”

说句得罪人的话，我在行业里看到的AI项目，至少一半是在做伪需求。什么叫伪需求？就是“为了让产品看起来有AI能力而做的功能”，而不是“用户真的有这个痛点需要AI来解决”。

有个特别典型的例子。我认识一个做HR SaaS的团队，看竞品都上了“AI简历解析”，也赶紧接了一个大模型接口做简历解析功能。结果呢？上线三个月，功能使用率不到1%。为什么？因为他们的核心用户是企业HR，HR招人的时候确实需要看简历，但他们想看的是PDF原文件里的版式和信息，AI解析出来的结构化文本反而看不太习惯，而且解析错误率高的时候，HR要花时间去核对，比直接用眼睛看还慢。这就把一个效率工具做成了增添负担的功能。

2.1 真需求要过三层过滤器

我自己的团队做需求评估，每个AI功能都必须过三层过滤器，缺一不可。

第一层是场景必要性：这个场景里用户当前是怎么做的？他当前的方案有什么痛点？AI介入后是让整个过程更快了、更便宜了、还是质量更高了？注意，至少得占一项，而且这个提升要让用户有明显感知。不是你跟他说“我们用了大模型所以很酷”，而是他自己用了之后觉得“哎，比以前快多了”。如果AI替代后用户的体验只是原地打转甚至更差，那就是伪需求。

第二层是数据可行性：做AI产品，光有场景还不够，你得有数据。我问几个问题：这个场景能不能拿到足够的用户数据？数据是结构化的还是非结构化的？数据质量怎么样，能不能用来做评估和迭代？很多产品经理忽略这一步，导致项目做到一半发现没有标注数据、没有反馈数据，模型效果无法验证，整个项目卡死。我见过最夸张的项目，连“用户是否满意这个回答”的记录埋点都没有，那这个AI产品的迭代根本没法做。

第三层是容错边界：这个场景里的AI出错，造成的代价有多大？举个例子，AI做商品文案生成，出错了改一下就行，容错高；AI做医疗诊断建议，出错了可能引发医疗事故，容错极低。容错边界直接决定了你要在多复杂的方案上投入资源——容错高的先做，容错低的要么不做、要么必须配上严格的人工审核流程。

2.2 用ROI公式给需求排优先级

很多团队做需求评审，全靠拍脑袋：“这个功能听起来很AI，先做吧。”后来成本账单出来的时候，所有人都不说话了。我的习惯是，每个候选需求都先算一笔账：AI投入的ROI是多少。

算ROI没那么玄乎，就是拿“做这个AI功能后节省的人力成本或提升的商业收入”除以“做这个AI功能投入的全部成本”。我举个真实算过账的例子。

我之前做电商平台的商品标题自动生成功能。人工写一个标题平均花8分钟，以一位运营月薪1万计算，每分钟人力成本约0.9元，一个标题的人工成本约7.2元。平台每天上新500个商品，如果AI能覆盖80%，也就是400个标题，一天节省成本就是2880元，一个月按22个工作日算能省63360元。

再看投入端：调用大模型API生成一个标题，假设输入输出加起来约1000 Token，成本约0.01元，400个标题一天成本4元，一个月88元。再加上产品经理、前后端工程师一个月的人工投入约5万元、评估标注费用5000元，一次性成本约5.5万元。这账一算就清楚了：一个月就能回本，而且以后每个月净省6万多，这个需求马上推进。

你可能会说，有些需求算不出这么精确的数字。确实，To B内部效率工具相对好算，To C产品的ROI往往要靠预估和类比。但即使算不准，你也得算一个大概，因为“算不出来”和“不去算”完全是两回事。老板问你为什么要做这个AI功能，你不能只说“这是趋势”，你得能说出“预计带来多少收益、投入多少成本、风险在哪”。这就是产品经理的专业性。

2.3 需求评审清单：拿来就能用

最后给你一份我自己在用的需求评估清单。每个AI功能上线前，我都会拿着六个问题过一遍，任何一个答不上来，这个需求就先别动工。

1. 用户当前是怎么完成这个任务的？哪里痛了？AI能解决哪一部分？——如果AI解决的只是最次要的那部分痛点，放弃。
2. 数据从哪里来？有多少？能不能支撑模型迭代？——没有数据就没有迭代，AI产品不能“上线即终点”。
3. AI出错会造成什么后果？出错率容忍上限是多少？——把“概率性错误”变成“可控的风险”才敢上线。
4. 效果怎么评估？用自动化指标还是人工评估？基线是什么？——没有基线的优化都是自欺欺人。
5. 一次性开发成本和持续性调用成本是多少？——每聊一次AI方案，就要问一次成本。
6. 不做这个功能，会损失什么？——这个问题能过滤掉90%的跟风需求。

顺便说一句，很多同学把“用户调研”理解为发问卷、做访谈，这些肯定要做，但在AI产品里，我强烈建议你在调研时直接拿一个粗糙的Demo给用户试。你把一个用大模型做的原型放到用户面前，他们的反馈会比抽象访谈真实得多。用户嘴上说“想要一个智能助手”，等他看到智能助手每次要等三秒才回复、偶尔还答非所问的时候，他可能会说“算了，还是我自己搜吧”。这就是Demo验证的价值——让用户体验具体的东西，而不是让他们想象一个抽象的功能。

3. 技术底子：不用写代码，但必须建立“模型感知”

很多想转AI产品的朋友看到大模型技术文档就头大，觉得自己得先学会Python才能上岗。我跟你说个实话：做AI产品经理，真正让你脱颖而出的不是代码能力，而是模型感知能力——也就是你能不能用产品语言描述一个AI技术问题，同时能理解技术决策对产品的影响。

什么是模型感知？举个例子。非AI背景的产品经理看到用户反馈“AI有时候回答不对”，第一反应是“那就优化模型呗”。有模型感知的产品经理会继续追问：是召回错了还是生成错了？是所有问题都错还是特定类型错？错误比例是多少？上下文窗口有没有截断？这些追问决定了你给算法工程师提的是一个模糊的吐槽，还是一个有明确方向的优化指令。算法工程师最怕的就是产品经理丢过来一句“效果不好，你调调”，这句话没有任何信息量。

3.1 必须搞懂的能力边界：模型能做到什么，做不到什么

大模型很强，但不是全能。我总结了一套能力边界图，你至少要清楚以下几个方面。

语言理解与生成：文本分类、信息抽取、摘要生成、内容改写、对话回复，这类任务是模型最擅长的，只要数据够、指令清晰，效果通常不会差。

推理与计算：逻辑推理、数学计算，模型能做但容易出错。尤其是多步推理，步骤一多就翻车。产品上如果涉及复杂计算，别裸用模型，给它配个计算器工具或者让它分步输出，你人工校验每一步。

专业知识：通用领域的知识模型基本都有，但细分行业知识的准确性堪忧。医学、法律、金融这些领域，模型的回答可能看起来很专业，但细节上经常出错，而且这种错误特别隐蔽，普通用户根本察觉不到，一旦出问题就是大问题。

多模态能力：识图、生图、语音交互，这些能力现在发展很快，但产品应用时要特别注意：视觉任务（比如OCR识别、图像分类）可以做得不错，但涉及空间关系理解（比如“图里第三个人和车的距离是多少”）就非常不可靠。

你要做的不是把这些边界背下来，而是在每个具体的产品需求里，先判断“这事模型靠不靠谱”，再决定“用模型做还是用传统方案做，或者混合做”。这就是需求洞察和技术判断的结合点。

3.2 提示词、RAG、微调：三种技术手段怎么选

这是AI产品经理最常被问到的问题之一。我直接给你一个决策路径，遇到需求时按这个顺序往下走就行。

第一步：先试提示词工程。成本最低、迭代最快。通过精心设计的指令、示例和上下文，把模型的行为约束到你要的方向上。80%的产品需求在这一步就能解决。你只需要准备好优质的示例、清晰的指令模板和必要的背景信息。

第二步：提示词不够了，再上RAG（检索增强生成）。什么时候用RAG？当模型需要回答的内容涉及你独有的业务数据、私有知识库，或者知识会频繁更新的场景。比如智能客服需要查询你公司最新的退款政策——大模型训练时没见过这份政策文档，你就要先检索到对应政策内容，再和问题一起塞进Prompt让模型基于这些内容回答。RAG的核心不只在模型本身，还在于检索质量。检索不到正确文档，模型再强也只能“一本正经地胡说八道”。

第三步：微调是最后的手段。什么情况才需要微调？当模型的输出风格、格式、能力与你期望的差距太大，且无法通过提示词纠正的时候。比如你要模型按你定义的一套严格JSON格式输出，且所有输出都要符合企业特定的语气规范，提示词做不到100%遵守，这时候微调一个7B或13B的小模型，往往能取得更好的效果和更低的推理成本。

我把这三个手段整理成一个决策表，方便你日常参考：

你可能会觉得这表格有点抽象，我用场景给你串一遍：有个功能要让AI根据公司产品信息生成推广文案，先写提示词（喂几个好样例），效果还行但引用不了最新产品数据，那就加RAG（接上产品数据库）；后来发现生成的文案语气总是“太通用”，跟品牌调性不匹配，提示词怎么调整都差口气，这时候才考虑微调。不要一上来就微调，那是把简单问题复杂化。

3.3 评估指标：你得有一套“AI效果标尺”

传统产品经理看转化率、留存率、DAU，AI产品经理还要多看一层：模型效果指标。没有这套指标，你和技术团队沟通就是鸡同鸭讲，你说“效果差”，他说“哪里差”，谁都说不清楚。

我把AI效果的评估方式分成三类，实际项目中三种往往混用。

第一类是自动化指标。分类任务看准确率、召回率、F1值；生成任务看ROUGE、BLEU；检索任务看命中率、MRR。这些指标的好处是可量化、可自动计算、可做回归对比，坏处是很多生成类任务指标和真实感受不一致——你算出来BLEU分数挺高，用户还是觉得AI说话像机器人。

第二类是人工评估。找一批标注人员按预设的标准给模型输出打分。评估这个环节最容易被产品经理忽略，但恰恰最重要的。引一句我个人经验：没有人工评估的生成式AI产品，上线前就是裸奔。因为你根本不知道模型在真实输入下的表现。实操上，每次迭代前抽300-500条代表性样本，找3个人背靠背打分，不一致的地方再讨论仲裁，这一套流程下来，模型效果基本心里有数了。

第三类是线上行为指标。用户有没有采纳AI生成的内容？用户有没有在AI回答后点“继续追问”还是直接放弃？用户对AI答案的点赞/点踩比例是多少？这些是产品层面的最终验证，因为你内部评估再准，也比不上用户真实行为数据说话。

我见过不少AI项目倒在这件事上：产品上线了，效果评估体系没建，只知道“大概不错”，等运营反馈“错误很多”的时候，连一个能定位问题严重程度的数据都拿不出来。所以我的建议是：先定评估方案，再写PRD。没有评估方案就等于没有验收标准，后面的迭代全凭感觉。

4. 从PRD到上线：全链路落地实操

很多刚做AI产品的PM，PRD写得跟传统产品一模一样：功能列表、页面路径、交互逻辑。交到研发手里，算法工程师直接迷了。AI产品PRD核心要回答一个问题：你期望的智能行为是什么样的？靠什么保障这个行为稳定可控？这三个关键词贯穿整个PRD：输入、输出、兜底。

4.1 AI产品PRD的正确写法

我拆解一份标准AI产品PRD的核心章节和要点。

背景与目标：这个功能解决什么问题？当前方案为什么不满足？怎么量化评估成功与否？注意，我强烈建议你在这里写清楚“基线数据”——当前没有AI时的准确率、人工处理时长、用户满意度等。没有基线，上线后你没法证明AI到底带来了什么改变。

用户场景与输入输出：写清楚用户会怎么使用这个功能、会输入什么内容、期望得到什么输出。这块要特别标注输入边界：哪些输入是AI必须处理好的，哪些输入可以拒答。举个例子，如果你做的是一个法律咨询AI，你得明确“涉及具体案情的建议”是拒答还是给出通用提示，这个模糊地带是AI产品最大的风险源。

模型行为规范：这是AI产品PRD独有的章节。你要写清楚模型在什么情况下应该怎么回应；不能输出什么内容；风格是什么；遇到敏感话题如何处理。我的建议是这部分不写抽象描述，直接写正例和反例，每个行为规范配两个正例、两个反例。算法工程师看到这些示例就能快速理解你的预期，比你写一千字“要专业”有用得多。

评估标准：明确自动化指标阈值（比如分类准确率不低于95%）、人工评估标准（比如答案可接受率不低于90%）、线上行为指标（比如内容采纳率提升20%）。这些指标必须可测量、可反馈、有数据来源。

兜底方案：这是最考验产品经理功力的一章。AI出错怎么办？检测出“低置信度”怎么处理？超时怎么办？转人工流程是什么？我见过的优秀AI产品，一半的研发精力在解决“AI不出错”和“AI出错时怎么接住”这两件事上。你把兜底方案写得越细，线上事故就越少。

灰度与回归计划：新模型版本怎么上线？先放多少流量？怎么对比新旧版本效果？发现效果下降怎么回滚？这个问题放到4.3节展开。

你可能会觉得PRD要求太多，但AI产品和软件产品本质不同：软件的逻辑是确定的，测试完基本没问题；AI的行为是分布的，你只能保证“大概率对”，不可能保证“一定对”。所以AI产品PRD的核心就是要为这种不确定性设计好护栏。

4.2 模型选型与成本测算

进入开发阶段后，你会面临一个关键决策：用商用API还是开源模型自部署？这个选择直接决定了你的产品成本上限。我给几条决策依据。

用商用API（比如市面上主流的大模型接口）：优势是接入快、模型强、不用养算法团队；劣势是成本不透明、数据出域有合规风险、对模型的掌控力弱。适合产品验证阶段、数据不敏感、需要快速上线的场景。

开源模型自部署：优势是数据不外传、长期成本可控、可以按自己需求微调；劣势是要有算法团队支撑、要买GPU服务器或云资源、运维成本高。适合数据敏感的To B产品、调用量大到API费用难以承受的场景、以及对模型行为有深度定制需求的场景。

我不建议你在这个决策上拍脑袋，我给你一套成本测算公式。假设日调用量是Q，单次调用Token数平均值是T（输入+输出），商用API单价是P元/千Token，那一个月的API成本是：Q × T × P × 30 / 1000。你拿这个数和自部署方案的成本（服务器租用+算法人力分摊）做对比，如果API成本显著低于自部署总成本且数据合规没问题，那就先API；反过来，当月调用量很大（比如几千甚至上万次/天）的时候，商用API成本往往指数上升，自部署的性价比就开始凸显了。

还有几个成本优化的细节是我踩过坑才总结出来的：

• 设置缓存：相同或近似输入，先查缓存，命中就直接返回结果，不调模型。
• 分级路由：简单问题走小模型，复杂问题才走大模型。大模型比小模型贵好几倍，你要把预算花在刀刃上。
• Prompt精简：每次调用都是要花Token的，你的Prompt越长，成本越高。很多人写Prompt喜欢堆一大堆系统指令，你要定期审查，把无用的指令删掉。
• 设置上限和熔断：单用户单日调用次数上限、全站调用并发上限，否则一出热点活动，你一天的API费用可能顶一个月。

4.3 灰度发布与效果回归

AI模型上线，最忌讳的就是一次性全量替换。因为你本地测试再充分，真实用户输入的分布永远超出你预期。我标准的上线流程分三步走。

第一步，影子模式。模型不直接面向用户，而是把真实流量复制一份喂给新模型，看它在真实输入下的表现。这个阶段主要验证两件事：模型在真实数据下的效果如何、推理耗时长不长。如果影子模式下效果都不达标，连灰度都不用谈，回去迭代。

第二步，小流量灰度。比如先放5%的流量到新模型，同时设置一条“人工抽检”流程，每天抽样看AI回答的质量。灰度期间要盯三样东西：核心效果指标是否下降、用户负面反馈是否增加、系统稳定性是否异常（比如响应时间、错误率、成本）。灰度周期一般建议至少一周，覆盖不同日期、不同业务高峰。

第三步，全量+持续监控。全量上线后也不是万事大吉，你要搭一个badcase收集机制——这是AI产品迭代的命脉。从用户反馈、人工抽检、业务投诉等多个渠道收集失败的案例，定期归因分析，推送进下一轮的优化Pipeline。没有这个机制，你的AI产品会快速过时，因为用户问答的分布是持续变化的。

说一句踩坑经验：灰度期间最怕的是没人看数据。很多团队灰度了一周，日志攒了一大堆，但既没人分析也没人跟进，等于白灰度。我会在灰度计划里直接写清楚“每个灰度日期的数据负责人、分析交付物和复盘时间点”，把这些变成硬性交付，而不是“有空看看”。

4.4 上线后的持续优化节奏

AI产品跟传统产品一个巨大差异是：上线只是开始，迭代永无止境。传统功能上线后只要代码不出Bug，就能稳定跑很久；AI功能上线后，效果会因用户输入分布偏移、业务变化、社会知识更新而逐渐退化。所以你得设计一个持续优化的机制。

我推荐一个“一月一迭代”的节奏。每个月末做一次全量效果回归：拿上个月的badcase和新收集的数据跑一遍模型，看效果指标有没有退化；抽出当前的典型case，人工评估一轮；结合业务方反馈，定下一轮迭代的目标。一个季度做一次大版本升级：换更强的基座模型、微调新版本、升级RAG知识库结构。

这里有个容易被忽视的细节：每一次模型升级都要回归历史badcase。很多团队升级模型后只看当前效果提升了多少，结果把以前已经修好的问题又重新引入了。你得维护一个“历史回归集”——把过去解决过的所有问题汇总成测试集，每次新版本上线前先跑一遍，确认以前修好的问题没有回退。

5. 避坑指南：真实项目里踩过的五个大坑

做AI产品这几年，我总结了不少教训。很多坑看起来是“技术问题”，本质上都是“决策和管理问题”。这一节我挑五个最典型的展开说，都是能让项目翻车的级别。

5.1 “AI效果不行”往往是期望管理失败

我接过一个项目，客户要做智能合同审核，签约前演示效果惊艳，大家都说“太厉害了，以后审核不用人工了”。结果真上线后，客户法务团队试用一周，投诉一大堆：“这审得什么玩意儿！这里面的风险条款识别错了好几处！”项目差点被砍。

问题出在哪？出在所有人对AI的预期都是100分，但AI只能做到85分。事前没有人明确告诉客户：AI能帮你把重复性的条款比对工作做了，但高风险合同仍然需要法务人工复核。管理层以为AI替代了人工，法务以为AI要背锅，两头都落空。

后来我们做了三件事改变局面：第一，重新定义价值主张，不叫“智能审核”，叫“审核提效助手”，明确定位是辅助人工；第二，把成功率数据公开透明地摆出来，让客户知道AI审出了多少问题、漏了多少问题、人工复核成本降低了多少，用数据对齐认知；第三，重点场景设置“AI建议+人工确认”的工作流，让法务人员逐渐建立信任。

这个案例的经验，后来变成我做任何AI产品的第一原则：明确设定用户的合理预期，比追求技术效果更优先。AI产品经理最重要的能力之一，就是管理好老板、业务方、用户三方对AI能力的预期，把它拉到一个现实的水平线上。

5.2 幻觉问题：你必须设计兜底和护栏

大模型最著名的翻车现场就是“一本正经地胡说八道”——幻觉。用户问一个公司政策问题，模型回答得头头是道，但其实根本没有这条政策，或者把旧政策说成新政策。这种问题在To B场景里是要命的。

我在设计AI产品时会强制自己做几件事。第一，限定知识来源：凡是涉及事实性回答，必须走RAG检索公司知识库，并要求模型“只基于提供的资料回答”，资料里没有的内容明确说“未知”。第二，置信度阈值：对模型的输出做一个置信度判断，低置信度的回答自动触发“转人工”或“标准话术”流程。第三，敏感话题护栏：涉及政策、法律、个人隐私的内容，模型一律给标准文本并建议人工咨询，不生成自由回答。

我知道有产品经理会觉得为了防幻觉限制太多，AI的“聪明劲儿”都没了。但你换个角度想：用户不是被AI偶尔的聪明惊艳到了才留下的，而是被AI持续稳定的靠谱留住的。在可靠性和惊喜感之间，AI产品无脑选可靠性。

5.3 成本失控：一夜烧掉一个月的预算

这个事情我亲眼见过。一个团队做了一个智能客服机器人，本来预估每天调用量2000次，但上线后用户热情高涨，一天调用量冲到15万次。月初定的预算第三天就烧完了，服务直接停摆。

成本失控的核心原因是：做预算的时候只按“预期用量”算，没有按“峰值用量”算。正确的成本设计要考虑三层：常态预算、峰值预算、熔断预算。常态就是平均日用量，峰值是活动或推广期可能出现的用量，熔断是超过多少就启动降级策略（比如从大模型降级到检索回复或标准话术）。你要提前设计好降级方案，而不是余额不够了才临时调。

还有一点：大模型调用的成本要在PRD阶段就算清楚，而不是上线后才复盘。我前面给的公式：Q × T × P × 30 / 1000，你完全可以预估出一个范围。如果预估成本已经超出产品预期ROI，那要么调整方案（比如用小模型、减少Prompt长度），要么重新论证需求的必要性。

5.4 数据合规：一票否决的底线

做AI产品，数据合规不是“法务部门的事”，是你的事。因为你是需求定义者，你最清楚产品会收集哪些用户数据、这些数据会传给谁、模型训练会不会用到。

具体来说，我在每个AI功能方案里都会做一次“数据链路自查”：用户输入的数据会发送到第三方API还是内部自部署模型？如果走API，数据中是否包含手机号、身份证号、住址、聊天内容等个人信息？数据是否用于模型训练？训练完的数据怎么处理？

合规这件事没有侥幸空间。你不能为了追求效果，把用户手机号塞到Prompt上下文里送到第三方模型处理，一旦数据泄露，就是安全事故级别的问题。安全的做法是：数据脱敏后送模型、内部自部署敏感数据、重要日志做加密存储和访问控制。而且这些要在方案设计阶段就定好，不要等法务发现了才补。

5.5 技术团队和产品团队的“翻译”难题

AI项目里，产品经理和算法工程师的矛盾，往往是全公司最多的。最常见的一幕是：产品经理说“这个效果太差了”，算法工程师问“哪里差？”，产品经理说“就是差，用户反馈不好”，然后沟通结束，问题悬而未决。

问题出在产品经理用产品语言描述了一个技术问题。要让协作变顺，你得学会“翻译”——把模糊的效果问题拆解成算法工程师能执行的具体信号。几个实用的翻译句式：

• “效果差”翻译成：“在最近的500条用户问题里，有120条被判定为低置信度，其中80条和物流查询相关，这部分的命中率只有60%，是什么原因？”
• “用户不满意”翻译成：“人工评估这100条回答，打分低于3分的有32条，集中表现为语气太敷衍，没有解释退货原因。”
• “给我调好”翻译成：“我整理了一份40条的badcase清单，分布在5个类型里，建议下一步优先优化A类型，因为占了一半。”

这套翻译能力，本质上是把产品的模糊反馈变成数据化的、可定位的、有优先级的任务描述。你多练几次，和技术团队的默契会提升不止一个档次。

6. 简历、面试与职业成长：从入门到拿Offer的实战路径

聊完了硬技能，最后说一说很多朋友关心的问题：简历怎么写、面试怎么过。我把这部分放进全链路手册里，因为对转型期的人来说，能不能进入这个行业，和能不能做好这个行业，一样重要。

6.1 AI产品经理简历怎么写

我筛选过不少AI产品经理简历，最大的问题是：写得太“产品经理”了。满屏都是“负责XX产品规划”“协同XX团队推动上线”，但完全看不出你做过AI，或者看不出你做的AI有什么结果。

简历要突出三点。第一是AI项目经历：哪怕你只是在之前的项目里做过一个AI功能模块，也要单独拆出来写。关键要写清楚：用了什么技术方案（调用大模型API/RAG/微调）、解决了什么问题、效果怎么量化（准确率从85%提到92%、人工工作量降低30%、用户采纳率提升18%）。记住，数据是最有说服力的。

第二是技术理解：不一定写“熟悉Python”，但一定要写你能听懂技术语言。比如“了解Prompt工程、RAG、Fine-tuning的基本原理及适用场景”“有模型效果评估的实践经验”“能独立搭建badcase归因分析流程”。这些描述会让面试官一眼知道你不需要被科普。

第三是结果导向的项目描述。我推荐用这个结构：项目背景（解决什么问题）→ 你的角色（不是“参与”而是“负责”）→ 技术方案（为什么选这个方案）→ 量化结果（带来了什么可衡量的提升）→ 复盘总结（踩了什么坑、沉淀了什么方法）。

还有个小技巧：简历里一定要有一个讲得完整、有细节、有取舍过程的AI项目。面试官其实不指望你做过十个AI项目，他指望的是你对亲手做过的那件事有深度思考。你在一个项目里展现出的判断力和复盘能力，比十个“参与过大模型应用”的项目都有用。

6.2 面试常见问题与答题思路

结合我内部面试和同行交流的信息，AI产品经理岗位的面试题基本绕不开这几类。

第一类是技术理解题。比如“RAG和微调的区别？什么场景用RAG、什么场景用微调？”“大模型幻觉怎么解决？”“模型上线后效果变差怎么排查？”这类题不考你背诵名词解释，考的是你有没有真实的项目经验。答题思路是：先答概念区别，再举自己做过的案例说明决策过程，最后总结一套方法论。比如“我发现知识更新频繁的场景用RAG效果好，因为这不需要重新训练；固定格式要求特别高的场景微调更合适，比如我们那边的合同模板生成……”。

第二类是场景设计题。比如“如果让你给办公楼做一套会议室预订AI助手，你怎么设计需求？”“给一个电商场景设计AI导购，怎么评估效果？”这类题考你的需求洞察和方案设计能力。答题思路是：先澄清目标用户和核心痛点（会议室预订最大的痛点不是“智能找会议室”而是“临时变更的沟通效率”），再选合适的技术方案（有结构化数据用规则+API就行，不一定要大模型），然后定义评估指标，最后说兜底方案。你的完整思路比答案本身更有价值。

第三类是项目复盘题。比如“讲一个你在AI项目中最失败的事”“一个效果不达预期的功能，你怎么排查和改善的？”这类题千万别只讲“成功了、数据涨了”，面试官要看的是你的反思能力和方法论沉淀。你讲讲当时的决策依据、哪里判断失误、事后怎么补救、沉淀了什么规则，这个故事讲完整了，比说十个成功案例都有说服力。

还有一类高频题是“你平时怎么跟进AI领域的最新进展？”这类问题没有标准答案，关键是让面试官看到你有一套自己的信息获取和方法论落地流程。比如你每周跟进哪些信息源、看到新产品会从哪些角度拆解、会不会动手测试Demo。展示你可迁移的学习能力，而不是靠死记硬背。

6.3 从入门到进阶的学习路线

最后分享一份可以立刻执行的学习路线。我不推荐一上来就看论文，那是算法工程师的路，不是产品经理的路。产品经理走的是“场景驱动学习”，从做“小而真的AI应用”快速建立手感。

阶段一：建立基础认知（1-2周）。搞清楚大模型的基本原理（不要深究数学，理解概念就行）、知道什么是Token、上下文窗口、温度参数；把主流的AI产品都体验一遍（对话助手、绘图工具、代码工具、搜索工具）；记录每个产品的优秀体验和糟糕体验，思考原因。这一步的目标是让你形成对AI能力的“体感”。

阶段二：动手做项目（3-6周）。选一个自己有兴趣、有数据、有明确场景的小项目，直接用商用API搭一个原型。比如做一个“网盘文件智能整理助手”“个人知识库问答工具”“简历信息抽取器”。重点不是技术难度，而是完整走一遍：需求定义→方案选型→提示词编写→效果评估→badcase优化。我强烈建议你记录整个过程的决策和踩坑，这是你面试时最宝贵的素材。

阶段三：形成方法论（2-3个月）。把阶段二的野路子逐步规范化：学习RAG和微调的适用场景，给已有项目升级方案；搭建自己的效果评估标准；写几篇复盘文章，把经验沉淀成可复用的方法。到这个阶段，你已经有能力以“AI产品经理”的Title投放简历，并且在面试时讲出有深度的项目故事。

有一条很朴素的道理：AI产品经理的门槛，不在于你掌握的知识，而在于你做过的事。你哪怕只是用API做了一个小工具，也比读了十本书有用，因为你在做的过程中才真正理解了“大模型的不确定性意味着什么”“数据不够是什么样的体验”“成本翻车是怎么发生的”。这些，书里都不会告诉你，只有亲手踩过才知道。

最后分享一点个人的体会

做了这么多AI项目，带过团队，也面试过不少候选人，最大的感悟是：这行缺的不是懂AI概念的人，而是能把AI能力落到具体场景、并持续交付价值的人。概念更新太快，今天的新模型明天就过时了，但你判断需求的能力、设计产品的能力、管理项目的能力、衡量结果的能力，这些是全链路中真正能跨周期沉淀的东西。

还有一个小技巧，我每次带新人都会先讲这个比喻，这里也送给你：把大模型想象成一个能力很强但需要明确指令和严格监督的“实习生”。你交代任务要说清楚背景和边界（提示词），给他参考资料避免他胡编（RAG），发现他做事风格不对就给他培训（微调），他做完的事你得检查质量（评估体系），发现不对得有备选方案（兜底流程）。你管理好这个“实习生”，AI产品就成了；你放任他自由发挥，翻车只是时间问题。把这句话想透了，你就已经跑赢了大多数还在研究“哪个模型更聪明”的人。