做了三年产品，投 AI 岗却石沉大海？问题可能不在经验多少，而在于简历还在证明“我做过产品”，而 HR 想确认的是“你能否在 AI 的不确定性里把问题做成可验证的产品”。本文拆解简历被拒的深层原因，给出 30 天个人项目补位方案，并教你如何精准投递，让三年经验真正成为转型优势。

最近有不少产品经理问我同一个问题：做了三年产品，业务也做过，项目也上线过，简历改了好几版，投 AI 岗却几乎没有回音。偶尔收到一封拒信，内容也很客气：经验不错，但与岗位要求不完全匹配。

这句话最让人难受的地方，是它既没有说你不行，也没有告诉你差在哪里。

我做产品十多年，见过很多次类似的转型。以前是运营转产品、C 端转 B 端、工具产品转商业化；现在大家把“AI”放在了岗位名称前面——换了一个词，招聘的要求也变了很多。

你投 AI 岗没有回音，不是因为经验太少，也不是因为你不懂AI，问题在于：你的简历还在证明“我做过产品”，而HR想确认的是“你是不是我们要的那个人”。

一、、简历为什么会石沉大海？

先看一份普通产品简历最常见的写法：负责用户需求分析，输出产品方案和 PRD，协调设计、研发完成版本上线，推动产品持续迭代。

话没问题，问题是：它太老，太普通了。

AI 产品的筛选，往往会继续追问四件事：为什么这个场景值得用 AI，模型具体承担哪一段工作，结果好不好怎么判断，失败以后怎么处理。如果简历只留下“负责”“推动”“协同”“上线”，这四个问题一个都没有回答。

很多人会在简历上补一行：熟悉大模型、Prompt、RAG、Agent，了解模型微调和向量数据库——看起来关键词齐了，筛选结果却没有明显变化。

原因也简单：关键词是自我声明，项目证据才是判断依据。

另一类误区是把传统项目里的大数字直接搬到 AI 简历上。“负责千万级用户产品”“推动 DAU 提升 20%”“主导多个复杂项目”，这些经历当然有价值，但它们不能自动证明你会做 AI 产品。AI 项目里的关键问题常常是：自动解决率是多少，召回是否可靠，模型响应慢不慢，调用成本能不能接受，用户什么时候需要人工接管。

你过去做增长，数字可能是转化率和留存；做 B 端，数字可能是签约、续费和交付周期。转向 AI 岗时，不是把这些数字删掉，而是要补上 AI 方案如何影响它们的中间过程。

还有一种简历，写得很努力，却把“参与”写成“主导”。例如，参与智能客服项目，负责 AI 能力接入；参与知识库建设，优化问答体验。面试官只要问一句“你具体改了哪一个环节”，就能知道你这段经历有没有掺水。

我宁愿看到一个规模不大的个人项目，写清楚数据怎么来、模型为什么这样选、失败样本是什么，也不愿看到一页充满“赋能业务、提升效率、驱动增长”的大词。

二、3 年经验真正能迁移的是什么

我见过不少产品经理，转 AI 时第一反应是重新从零学技术：学 Python，学 Transformer，背各种模型参数，收集几十个课程和教程。学了几个月，仍然说不清自己能解决哪个问题。

不是学习没用，而是顺序反了。

AI 产品经理最先要学习的，是你的判断力。你得判断一个场景到底适不适合、能不能用 AI。知道什么时候用，什么时候不用，往往比知道怎么把 AI 接进来更重要。

你过去做需求分析的能力，在这里仍然有用，只是问题要问得更细。用户说“我想要一个智能助手”，你不能马上画聊天框，而要继续追问：助手替用户完成哪一个动作，哪些信息必须准确，哪些错误可以被用户纠正，哪些决策必须由人做最后确认。

你过去做交互设计的经验也仍然有用。传统产品通常是用户点击，系统给出确定反馈；AI 产品增加了生成、等待、引用、修改、拒绝和人工接管。用户不知道模型下一次会说什么，产品就必须用界面告诉他哪里可信、哪里需要核对，以及出了错以后怎么退回去。

你过去推进项目的能力，更不能丢。AI 项目经常卡在数据不完整、业务方不愿意提供样本、工程实现和产品设想不一致这些地方。能不能把问题拆成一个小闭环，找出谁来提供数据，谁来定义标准，谁来验收结果，仍然是产品基本功。

真正需要增加的是一层“AI 结果意识”。你不能只说功能上线了，要说清楚什么叫做得好。对一个知识库问答产品来说，可能要看答案是否引用了正确资料，是否出现编造，用户能不能在十秒内找到证据；对一个内容生成工具来说，可能要看一次生成可用率、修改次数、输出成本和用户最终发布率。

有一份面向 AI PM 的公开评估框架，把能力拆成六类：动手构建、产品思维、AI/ML 理解、沟通表达、战略判断和快速交付。它反复强调，简历不能只写“管理团队做了什么”，还要能展示自己做过什么、如何验证、如何迭代。

这不是要求每个产品经理周末都做10个项目。真正的目的是：AI 岗的可信度，来自可检查的过程，而不是来自一个漂亮的自我介绍。

三年的产品经验，最有价值的是：你对某个行业或业务场景的理解，你把复杂问题拆开的能力，以及你推动一个东西真正被使用的经历。

三、没有 AI 项目，怎么补

没有正式 AI 项目，不等于没有办法。正式项目当然最好，但你不能把转型的主动权交给公司什么时候给你机会。

我建议用 30 天做一个小而完整的项目——选择一个你熟悉的业务场景（因为你要展示的是产品判断，不是工具拼装），然后认认真真地跑一遍：

第一周，找一个你真正理解的问题。

比如，销售团队每天要从大量客户资料里找答案；运营同事需要把用户反馈分成几类；客服需要从产品文档里找到对应条款。问题越具体越好，最好能找到真实材料和真实使用者。先写一页纸：谁遇到什么问题，现在怎么解决，哪里浪费时间，为什么规则或普通搜索解决不了。

第二周，画出第一版原型。

可以用 API，也可以用 Dify、Coze 之类的工具。工具不是重点，重点是你要自己决定输入格式、输出格式、错误提示和人工接管方式。第一版不需要漂亮，但必须能跑。把一次成功的演示录下来，也把失败的结果留下来。

第三周，找几个人真实试用。

不要只让朋友说“挺好用的”。给他们一组固定任务，记录完成时间、错误次数、需要修改几次、哪些回答被直接放弃。AI 产品最怕自我感觉良好，用户一用就露馅。失败样本比成功截图更能说明你有没有产品经验。

第四周，补齐评估和复盘。

你至少要回答五个问题：什么算正确，错误分哪几类，当前版本的通过率是多少，成本和响应时间能不能接受，下一版先改哪里。数字不必夸张，甚至可以很普通。比如 30 条测试样本中有 22 条达到标准，剩下 8 条主要错在资料召回；平均响应 8 秒，用户愿意等待，但对复杂问题仍然需要人工确认。这种写法比“准确率显著提升”可信得多。

项目最后整理成一页案例，不要写成课程作业。开头写问题，接着写方案和取舍，再写测试、失败和下一步。附上 Demo、流程图或代码仓库，面试官才有机会继续问下去。

可能有人会担心:个人项目不算正式工作经验。

是的，个人项目不能冒充生产项目；但它能证明：你不是只会看资料的功能型产品经理，你能把想法变成原型，知道 AI 产品如何判断好坏。

四、怎么投：别用海投掩盖定位问题

很多人简历没有回音，第一反应是扩大投递量。每天投二三十份，看起来很勤奋，实际上只是把同一份简历投了几十家公司，毫无意义。

最重要的是先缩小目标。

你做过电商，就先找 AI 推荐、智能客服、营销自动化、商品理解等岗位；做过内容，就关注内容生成、审核、搜索、创作者工具；做过企业服务，就看知识库、销售助手、流程自动化和行业解决方案。不要因为岗位名称里有“AI”就全部投。业务邻近，才能让过去的经验真正成为优势。

每次投递前，把 JD 拆成三列：岗位要解决什么业务问题，需要什么 AI 能力，要求什么证据。然后只保留与你求职的岗位最相关的几个项目。

如果 JD 写“熟悉 Agent”，不要写 Agent 熟悉度。你应该在项目经历里写：为某个具体场景设计了怎样的工作流，Agent 可以调用哪些工具，哪些节点必须人工确认，测试时出现过什么问题。这样HR才能判断你是不是用过，而不是搜到过这个词。

如果 JD 写“有业务落地经验”，不要写“推动项目上线”。补上业务方是谁、上线前后发生了什么、你负责的决策是什么。哪怕结果不大，也要让人看见你处理过真实约束。

投递渠道也要换。大厂 AI 平台岗可以投，但不要只盯着它。AI 创业公司、中型公司的 AI 应用团队、原有业务正在 AI 化的公司，都可以尝试。先尝试拿到面试机会进入公司，再考虑下一步。

还有一个经常被忽略的动作：找人内推时，不要只发“帮忙看下简历”。说几句好话，说清楚你现在做什么、想转什么、已经做了哪个 AI 项目，成功率会高很多。

五、总结一下

最后说一句可能不太好听的话：简历没消息，先不要急着说是年龄、市场的问题，我们改变不了已经确定的东西，只能改变自己。

你能改变的是：把过去三年的产品经验重新解释一遍，做出一个能展示判断和落地的 AI 项目，把简历从职责清单改成证据链，再把投递范围缩到真正匹配的岗位。

AI 岗位并不缺会说“AI 很重要”的产品经理。它缺的是能够面对一个不稳定的系统，定义问题，做出取舍，测出结果，然后在结果不好时承认方案需要重来的人。

三年经验够不够，不会由简历上的年限单独决定。HR最后要看的，是你有没有把这三年用来形成自己可以迁移的能力。