企业官网建设流程全解析

在技术去泡沫的周期里，AI产品经理是我见过最矛盾的岗位。招聘网站上这个Title满天飞，真去面试却发现，大部分候选人拿出来的还是“截图、录屏、prompt模板”三件套。企业端的反馈也很统一：我看不太懂这个AI到底怎么赚钱，怎么降本，怎么让用户真的留下来。

这个周期其实特别有意思：大模型的热度没有消失，但资本市场和业务方都开始问“ROI是多少”了。我在多个产品社群和就业实战营里做了很长时间的案例评审，最大的感受是——AI产品经理真正的分水岭，不是会不会用几个新工具，而是能不能把一个模型能力变成一段有用户、有指标、有迭代闭环的业务流程。这恰好也是那些“就业实战营”想要解决的题：与其教人收集更多参数和名词，不如逼着每个人亲手交付一个能跑、能测、能讲清楚的AI产品。

这篇文章，我想把这个“技术去泡沫”背景下的AI产品经理成长路径讲透：什么叫能落地，训练营到底在练什么，面试官真正会打勾的能力点又是什么。

1. 你首先要明白：什么叫“能落地”的AI产品

1.1 市场淘汰的从来不是“AI项目”，而是“演示型项目”

早些时候，一个AI产品经理的简历里出现“我做过一个智能客服”“我搭过一个知识库问答”是很有竞争力的。那时候只要录屏里机器人能流畅回答三四轮，大家就觉得技术很成熟了。但现在再看，这类项目的败因惊人地一致：能demo，不能上线。

我用一句话区分演示型项目和落地型项目：演示型项目只证明“模型能完成一次正确输出”，落地型项目要证明“系统能稳定地完成用户任务、控制成本、处理异常、并留下数据”。

举一个我评审时常说的例子：同样做“文档问答”。演示版会找一个格式干净的PDF，问“这份合同的总金额是多少”，模型答对了，录屏结束。但落地版本需要面对的是：用户上传的可能是扫描件、可能是手机随手拍、可能是表格里嵌着图片。问答只是最后一公里，前面还有文件解析、OCR质量、表格结构还原、权限控制、引用溯源、幻觉拦截。一旦把这些都算进去，这个项目就从“调用一下大模型接口”变成了一个真正的产品工程。

所以技术去泡沫，去的是什么？去的是那些“看不到真实约束条件”的纸面项目。投资人开始问留存，业务方开始问成本，用户开始问“你和原来的系统到底有什么本质区别”。这些问题，PPT里答不出来，只能靠产品里跑出来的数字回答。

1.2 技术去泡沫，反而抬高了AI产品经理的门槛

说到这里，很多人会以为AI产品经理的岗位变少了、要求变低了。我的观察正好相反：岗位变少了，但留存下来的岗位要求明显变高了。

以前会写prompt、会调几个参数就能自称“AI产品经理”，因为市场还在验证“这个技术到底能干嘛”，大家比的是谁更早讲故事。现在故事讲完了，到了买单和续费阶段，企业要的是能分析用户流程、能定义评估指标、能设计human-in-the-loop机制、能推动工程落地的产品经理。这几个能力，每一个都需要真实项目来喂养，光靠在文章里刷知识是喂不出来的。

就业实战营这种形式之所以在这个时间点变得有价值，本质原因就在这里：它能用6到10周的时间，强行把你推进一个“有限资源、真实约束”的项目环境里。你在里面犯的错、补的数据、调的指标，就是面试时最值钱的谈资。别人只会说“我知道要做RAG”，你能说“RAG在项目中因为召回太低导致意图误判，我增加了rerank和混合检索，最终让用户任务成功率从58%提高到79%”。这中间差的不是知识量，而是有没有真正被业务逼过一次。

2. 把实战营看成一场“90天产品交付实战”，而不是学习班

2.1 选题方法论：先找“坏掉的流程”，再找“模型能力”

在多个实战营做评审时，我最常看到的一个现象是：学员拿到训练营任务后，第一反应不是想用户，而是想“我该拿哪个大模型API做点什么”。这是典型的锤子找钉子。

一个能写进简历的AI产品项目，选题顺序必须是反过来的：

1. 找到一个真实场景里“效率低、错误多、体验差、且涉及非结构化信息”的环节。
2. 判断这个环节被AI改造后，能不能带来可量化的收益（省钱、增收、省时间）。
3. 再来决定用哪种模型、哪种成熟方案。

举个实际例子。某期训练营里有个学员做“会议纪要处理”。他最初的想法是做一个“会议纪要自动生成器”，因为这个功能最容易演示。后来我们逼他去访谈了5个使用会议纪要的人，发现真正的痛点不是“生成纪要”，而是“会议结束后的行动项没人跟踪”。于是他调整了产品方向：不只要纪要，还要自动抽取负责人、截止时间、风险项，并在截止日期前提醒。同样是用大模型，后者解决的是业务流程闭环，面试时讲出来完全不是一个量级。

在实战营里，选题本身就占30%的权重。因为一个真实的、有明确受益方的题目，会让后续所有环节都有了评判标准。你可以用一句话检验自己的选题好不好：“如果这个AI功能明天突然没了，有没有一个真实的用户会感到难受？”

2.2 项目管理：练习在资源有限的情况下保交付

实战营和自学最大的区别是它强行设置了Deadline、阶段评审和团队协作。这些在真实工作中就是日常。

我见过很多自学能力很强的产品朋友，一个人偷偷摸摸写了个完整产品，但你在面试时问他“中途遇到了什么问题、怎么取舍的”，他答不上来。因为一个人做项目没有被迫做决策的过程。训练营里的项目管理逼迫你做的其实就是这几件事：

• 定义阶段目标：第几周必须完成场景验证，第几周必须跑通端到端。
• 明确依赖关系：没有标注数据会影响评测，评测又会影响你后面选prompt策略还是微调策略。
• 定期做取舍：模型幻觉压不住时，是先优化prompt还是先限制用户输入，还是直接加一个人工审核节点。
• 保留决策记录：每个关键决策用一句话记录下来，后面面试就讲这个。

在训练营的项目设置里，一般会把6到10周切分成这么几个阶段：

把这个节奏跑完，你收获的不只是一个产品，而是一套“如何在有限资源下推进AI项目”的肌肉记忆。

2.3 交付物决定训练营效果：别只交“体验报告”

我评判一个实战营值不值得参加，有一个很硬的标准：它最后要求你交什么？

如果结营要求是写一篇文章、做一份PPT，那它本质上还是一个“知识付费课程”。真正的就业实战营，结营产出应该包含以下四类东西：

1. 可运行的产品：哪怕是一个Streamlit界面、一个API服务、一个机器人后台，至少是一个别人能体验到完整流程的东西。
2. 评测数据集（Golden Set）：有100条以上的典型问题、边界问题和错误答案标注。这是证明“我认真校验过模型能力”的最直观证据。
3. 关键指标对比表：基线数据、优化后数据、成本测算。比如：badcase率从多少降到多少，单次会话成本约多少元。
4. 完整的项目复盘：包括你做对了什么、哪里判断失误、如果再给你两周你会做什么。

这四个交付物对应的是真实AI产品开发里最核心的四个动作：做出来、测清楚、算明白、讲透彻。能把这四件事做完的人，即使不是技术出身，也能在团队里赢得话语权。

3. 核心技能与实操要点：训练营到底在练什么

3.1 场景与模型匹配：选型不是炫技

很多初入AI产品门槛的朋友有个误区，觉得什么都要用最新最强的模型。实际做项目时，模型选型完全是一个成本、效果、延迟、合规的综合题。

比如做客服场景，你的真实约束通常是：回答质量不能低于人工客服的底线，单次响应不能超过3秒，单次调用成本要低于多少元，所有回答必须能溯源到知识库文档。满足这些条件，很多时候市面上偏轻量的模型加一套结构化检索就够了。你非要用最强的模型，可能效果好一点，但成本直接翻5倍，在高频场景里根本扛不住。

产品经理在训练营里要练的“选型能力”，其实不是让你去读懂所有模型的技术报告，而是让你学会拆解“场景约束条件”。我会建议实战项目里做一张简单的选型表：

这就像你给公司配置电脑，没必要所有人都上最高配置；有的岗位需要高性能，有的岗位一台轻薄本就够了。能说出“为什么不用最强模型”这个理由，反而是面试官眼里的加分项。

3.2 指标体系建设：怎么证明你的AI产品“值这个钱”

训练营里最容易被忽视、但面试时最杀人的环节，是指标体系。

我看过太多“效果不错但说不出好在哪”的项目。学员会告诉我“准确率大概90%吧”，但你问他怎么算的准确率、测试集怎么建的、坏case长什么样、和原来的流程比少花了多少时间，他就开始模糊了。这不行。

一个合格的AI产品指标应该至少包含三层：

第一层：模型质量指标。准确率、召回率、F1、幻觉率、引用准确率等。这一层只回答“模型本身聪不聪明”。

第二层：用户体验指标。任务完成率、用户纠偏次数、平均对话轮数、问题解决时长。这一层回答“用户用得顺不顺手”。

第三层：业务价值指标。人力替代成本、客诉率变化、成单转化率、用户留存提升。这一层回答“这个AI有没有带来钱或省下钱”。

实战营里训练学员的核心动作，是在项目开始第一天就把三层指标写下来，然后每周回填一次数据。哪怕数据不好看，也比没有数据强。因为“数据不好看但我找到了原因并做了改进”这个叙事，恰恰是最能证明你是一个成熟产品经理的证据。

我印象很深的另一个案例，是一位做“售后工单分类”的学员。他第一次提交的指标只有“分类准确率89%”，看起来不错，但被追问后发现了问题：模型把“退款申请”和“退货申请”混淆率极高。因为业务上退款和退货需要走完全不同的流程，混淆一次就意味着一笔隐性损失。于是他基于badcase构建了新的标签体系，优化后光这一项错误率就降了一半。这个案例让我看到他确实在“做产品”，而不是“调模型”。

3.3 数据清洗与评测集：AI产品经理的基本功

还有一个被严重低估的能力，是处理数据。AI产品经理最好能亲自做一轮数据清洗和评测集构建，因为这是你理解模型行为边界的最好方式。

在实战营项目里，我要求学员必须干这么几件事：

• 从真实用户场景里收集至少100条输入数据，不要用网上现成的数据集。
• 自己先标注一遍“理想答案应该是什么样”，如果自己都说不清，说明你的产品需求没定义清楚。
• 把问题按难度分层：简单问题、多轮问题、边缘case、恶意输入、无答案问题。
• 每次改动prompt或模型版本，都要拿这套测试集做回归。

这个过程可能很枯燥，但价值非常大。因为你会第一次直观地看到：模型不是“聪明”或“笨”的问题，它是“在某几类输入上不稳定”。比如你可能发现它对口语化表述处理很好，但对表格类问题全部翻车。这种认知，是你看一万篇技术文章都得不到的。

对于非技术背景的产品经理，我的建议是先不学SQL，也不学Python，先学“数据感知力”——拿到100条对话记录，你能不能在半小时内归纳出高频问题类型、用户表达习惯和模型常见错误。这个能力不需要写代码，但价值极高。等到需要处理更大量数据时，再补工具技能也来得及。

3.4 从原型走向“上线”：部署与监控才是落地分水岭

训练营里能做出一版端到端原型的人不少，但能讲到“部署之后怎么办”的人很少。而这恰恰是“能落地”和“不能落地”的真正分水岭。

一个AI产品在上线后，产品经理至少要回答这几个问题：

• 模型输出被用户点了“有帮助/没帮助”，这些反馈有没有回流到底层？
• 发现某类问题总是回答错，你有没有一套流程能快速定位是检索的问题、prompt的问题还是模型的问题？
• 上游知识库更新了，产品能不能同步感知到？还是每次都要开发手动改？
• 有没有监控模型响应时间和成本异常的告警？

训练营里如果有条件，应该让学员至少接触一种监控工具，哪怕只是搭建一张简单的看板，用表格记录每周的调用量、错误率和badcase截图。我在一些实战营里见过很聪明的小组，直接在应用后台加了一个“用户反馈标记”按钮，让用户对回答点“有帮助/不满意+备注”。这一个小功能，就让他们后续迭代有了真实数据来源，也让他们在面试时能讲出“我有闭环意识”。

这个意识的本质是：AI产品不是一次交付就结束的静态工具，它需要反馈循环才能长期稳定。哪个候选人能讲出这个循环，哪个候选人的段位就明显不一样。

4. 就业环节：怎么让面试官相信你能“落地”

4.1 作品集不是“功能截图集”，而是“经营证据集”

很多人在实战营做完项目，最后却毁在作品集上。最遗憾的形态是：明明做了大量工作，最后却只交了一个录屏加五张截图。面试官看了只会觉得“你又调了个库”。

作品集应该是一个“证据链”，逻辑是这样的：

• 项目背景：一句话说清楚这是什么业务、为谁解决什么问题。
• 用户痛点：至少3条来自真实访谈或数据分析的洞察，而不是“用户觉得效率低”。
• 方案迭代过程：你尝试了什么，失败了什么，为什么放弃某种方案。
• 关键指标：包括基线、目标、最终结果。最好有优化前后的对比。
• 失败与复盘：不要让作品集看起来全程成功的，要主动暴露一个关键失误，再讲你怎么补救。

我在就业辅导里经常让学员遵守一个“10页法则”：个人作品集PPT最多10页，前3页讲背景和用户，中间5页讲方案和指标，最后2页讲失败复盘和未来规划。用这个框架讲下来的效果，会远好于“我做了一个网站，网址是这个”。

4.2 简历上真正被“打勾”的关键词

训练营结束后，另一件重要的事是把项目经验写进简历。但很多AI产品经理的简历，写出来的项目描述全是功能列表：实现了流式输出、接入了企业微信、做了知识库问答。这种写法是站在“做了什么”的角度，而不是“达成了什么”的角度。

面试官筛选简历时，快速打勾的几个点很有规律：

绕不开的专业术语，比如“RAG”“Agent”“向量检索”，该写还是要写，但必须确保它们出现在“用于解决什么问题”的上下文里。比如“通过构建RAG流程，将知识库问答的引用准确率从64%提升至87%”，就比“熟悉RAG技术”有说服力得多。

4.3 面试环节的“示范答题框架”

实战营除了做项目，还应该花一部分时间模拟面试。AI产品经理的面试问题其实高度同质化，无非这几类：

1. “请介绍一个你负责的AI项目。”（考察项目完整度）
2. “这个项目的指标为什么提升了？会不会是巧合？”（考察指标与实验设计）
3. “模型不听话/幻觉很多，你怎么办？”（考察工程思维和兜底策略）
4. “用户需求频次低，要不要做AI功能？”（考察商业判断，而不是技术迷恋）

我比较推荐一个答题框架，叫“背景-目标-行动-指标-复盘”：

• 背景：当时业务面临什么问题，约束是什么。
• 目标：这个项目成功与否的明确标准。
• 行动：你具体推动做了什么，强调你作为产品经理的决策。
• 指标：用数字说明结果，最好有对比。
• 复盘：如果重来一次，哪里会做得不一样。

这个框架最核心的动作是训练自己“把故事压缩成结论”。很多候选人在面试时输在话多但信息密度低。你练熟了这个框架，无论面试官怎么追问，你都能快速找到自己经验里对应的那块内容，而不是现场编造。

5. 常见踩坑记录与排查心得

5.1 第一个坑：拿到新模型就给自己“找场景”

我在各种实战营里看过无数个“因为模型厉害所以我要做这个产品”的项目。典型的是看到模型会画画，就做一个“AI海报生成器”；看到模型会写文案，就做一个“AI营销文案助手”。不能说完全不对，但这些方向都有一个共同问题：没有先验证“这个需求用户已经在用别的方案满足”。

正确的排查思路是这样的：如果你判断一个场景值得做，先去找一下市场上是不是已经有替代品。如果已经有三款同类产品，那你要做的不是再做一个，而是想清楚你有什么差异化资源。如果没有替代品，再问问自己：“是真的没有人解决，还是大家试过之后发现做不成？”大部分时候，答案都是后者。

5.2 第二个坑：拿“准确率”掩盖真实用户体验问题

训练营测评时，有学员给我看他的“意图识别准确率”从85%涨到92%，非常得意。但我实际去用了一下他的产品，感受很差。因为那92%的准确率是在他的封闭测试集上测的，而真实用户不会按你测试集的套路说话。用户可能问得很长、很口语、很杂，还会带着情绪，这些在干净测试集里都不存在。

后来我带他做了一件事：把产品发给10个人，每人自由使用20分钟，结果输出了大概200条真实问题。在这200条里，准确率掉到了76%。这才是产品真正要面对的“野生数据”。一个合格的产品经理，永远要怀疑你的测试集是不是太干净了。如果你没有用真实用户输入做过评测，那你的准确率只是一个假设。

5.3 第三个坑：只做“功能”，不做“体验回路”

AI产品有两个体验回路，很多人只做了一个。第一个回路是“用户输入-模型输出”，第二个回路是“模型输出-用户反馈-系统改进”。大多数实战项目都会做第一个，做得很漂亮，但第二个就没了。结果这个产品变成一个“单向喇叭”：它一直不停地说，但从不听用户到底怎么评价它。

排查你的产品有没有闭环，只需问三个问题：

1. 用户对回答不满的时候，有没有渠道表达？
2. 那些表达有没有被记录和归类？
3. 记录下来的badcase有没有变成下一次迭代的输入？

三个问题里只要有一个是“没有”，那这个产品的生命周期就注定很短。训练营里如果时间和预算实在有限，哪怕手工用Excel记录badcase也算是个起步。闭环这个意识本身，比工具值钱得多。

5.4 第四个坑：忽视护栏、合规与权限

这可能是训练营项目里最常被忽略、但实际工作中最致命的一环。很多学员做知识库助手时，只关注“回答得准不准”，完全没想过“什么内容不该回答”。比如一个企业内部助手，如果把某位员工的敏感薪酬信息暴露给另一个权限不足的同事，产品再好也会直接沦为事故。

做AI产品经理，必须至少在工作中问出这几个问题：

• 答案会展示哪些信息，权限边界是什么？
• 模型会不会输出带有偏见的表述，需不需要敏感内容过滤？
• 用户输入的数据存储在哪里，是否符合隐私要求？
• AI给出的建议涉及钱、健康、法律等高风险领域时，是否需要人工审核兜底？

不懂这些细节没关系，但面试或做项目时要展现出“我知道这里有问题，而且我有解决方案”。这会把你的段位从“功能设计师”拉到“系统设计者”的层面。

6. 聊聊“实战营”这种形式，以及你该如何榨干它的价值

这几天有很多朋友在问，想趁着AI产品经理窗口期报一个就业实战营，值不值。我的看法是，如果你属于下面三类人之一，这类以项目交付和就业导向为目标的实战营，性价比确实很高：

• 转岗产品经理不满一年，需要一个完整AI项目来敲开面试大门的人。
• 已经在做产品但偏传统软件，想尽快补齐大模型项目经验的人。
• 自驱力一般，需要外部Deadline和小组讨论氛围才能把项目推完的人。

但实战营也不是魔法。它给你的是一套刻意练习的路径和一个允许你犯错的环境。同一个训练营里，起点差不多的人，最终作品差距可能很大。差异来自几个点：选题时有没有真的去聊用户、迭代时有没有真的引入坏case、复盘时有没有真的承认自己判断错了。

我的个人建议是：如果你决定参加，就把它当作一份正式的“工作”来对待。固定时间，每周都做周报，每次都把决策和结果记录下来。结营不是结束，而是你的作品集正式诞生的第一天。用它去投简历、去面试、去跟同行交流，让这个项目持续产生价值。

再分享一个我在带训练营时的小技巧：给自己设定一个“结营后两周”的任务清单。通常包三件事：把作品集压缩成可以在三分钟讲完的版本；把项目中的核心指标做成一张图；把项目过程中遇到的问题整理成一个“面试问答库”。大部分人在训练营结束后精力会快速流失，能把这三个月沉淀下来的东西打包装好，你才能真正吃到这波AI产品经理红利。

技术去泡沫不是坏消息。它只是把那些“会讲故事但不会交付”的人筛了下去，让真正能解决问题的产品人浮上来。愿意把自己泡在真实项目里、亲手做完一个又一个闭环的人，不管周期怎么变，机会都会在。