一位9年B端产品经理，面对AI浪潮也曾迷茫，却从业务痛点出发，用AI工具解决配置交付难题，半年内将效率提升数倍，并成功内部转岗AI产品经理。本文复盘了他的实战路径、踩坑经历与转型心法，告诉你业务经验才是AI产品经理的真正壁垒。

我是一个做了9年B端产品经理的人，业务方向一直是工程建设招投标方向。这个业务是解决方案类的业务，业务本身非常复杂，客户属于G端客户，各地区的客户还有自己的特性业务要做，要求私有化部署，所以我们的项目交付成本都非常高。

最开始我们为解决多个项目重复交付相同业务的问题，做了低代码的可配置业务中台。可是交付两年后，我们发现业务中台有带来了新的问题：二开工作量降下来了，但是配置和验证的工作量占比极高，而且业务中台配置对业务人员的能力要求非常高。

所以，我们产生了一个新的课题：做 AI 配置交付提效。

我当时的情况，是把各种AI工具当搜索引擎用，deepseek、豆包、元宝、千文等等，我都当生活百宝箱，有问题语音问问，然后看看答案。也在一些学习群看到分享的 “提示词工程” 的文章，我也仔细学习了，但是说实话，没看明白，看完了也就是看完了，依然不会用。AI相关的专业概念，RAG、Agent 、Skill 是什么？我一个都不懂。

但我组织有需要，那我就上，想办法解决问题。

一、我是怎么上手的：先别管名词，先拆业务

用AI做配置交付提效，看起来是AI的事，但是实际上还是要解决我们配置难度大，效率低的问题，所以根还是在业务上。

所以，我做的第一件事，是把整个配置交付流程从头到尾梳理一遍，根据自己配置范本的工作经验，访谈范本交付过程中涉及到的各个角色，看整个流程中的痛点或者卡点在哪里，然后综合整理成一份完整的范本配置交付用户旅程图。

接下来，还是对业务的深入分析：在整个范本配置交付的过程中，哪个环节必须有人的参与，例如跟客户沟通确认才能有定论；哪个环节的输出是客观标准化的，只需要范本和产品经理就能够直接出结论；把业务环节按照这两个标准筛选一遍，把客观标准还的环节作为AI配置提效的备选环节。结合AI最擅长的文本解析能力，挑选出来最适合做的两个流程节点： “文本识别和自动配置” 。

方向定了之后，我跟技术团队先根据任务的情况进行了拆分，业务相关的经验和内容，技术团队帮不上忙，就由我自己先来。技术团队则先去做底层的框架建设。

我自己拿AI工具试的时候，按照我们人工配置范本的方法，先让AI识别范本内容，再找需要配置的地方，最后再配置成我想要的样子。我让AI识别范本内容的时候，我以为很简单，就是把范本文件扔给AI，然后告诉他我要识别就可以了，结果发现光是内容产出格式这一方面就跟我想的不一样，我又先跟AI定义了我要产出的格式，直到识别的内容调整到符合我的预期之后，才开始开展后面的环节。当然了，每一个环节都有意料之外的情况发生，就这样一遍遍地跟AI聊我的预期和我在实际工作做会怎么处理这些问题的规则，它最后都变成了我想要的样子。

二、踩过的坑：照搬大模型术语，差点定义不了自己的产品

一般做业务功能的时候，都会定义客户成功指标，这都是基于客户的业务产生的指标。在做AI的时候，我一开始就犯了一个错误，不清楚AI产品的指标是如何定义的，就直接参照普通大模型项目的做法 —— 只定义了范本识别的召回率、准确率来了个指标。

等研发交付第一版给我的时候，我一验证，发现仅仅靠识别的召回率和准确率这两个指标，根本定义不了我们的业务。因为我们的流程不是一个简单的 “识别完就完了”，它还有后面的变量识别和配置完成环节，每个环节要完成，定义的维度和准确率要求完全不一样。

所以在验证的过程中，我就按照业务的三个环节，分别拆解出来了对应的业务指标和准确率等要求，范本识别阶段，确实需要用召回率和识别准确率这个指标来定义；后面的变量识别也需要有变量识别的召回率和准确率，配置环节也得有一个配置的召回率和准确率，同时因为配置的组件不同，它复杂度不一样，还可以再细拆出组件级别的不同指标。

这个事让我意识到：AI产品经理不是把大模型的术语搬过来用就行，你得用业务语言重新定义问题。

三、最大的坑：做完演示，没人用

产品迭代了一个版本之后，我们做了内部验证，给团队做了交底和演示。

当时期望大家能够在实际项目交付中使用这个提效工具，确实提升大家的工作效率，另外我们的正好完成产品的指标验证，结果大家都不用，我当时挺受挫的。

大家不用我不能硬让大家用，但是我自己可以用。就这样我默默跑了数十套真实范本，一套一套验证。

在这个过程中，我发现了问题：之前默认一个结论”数据正确性人工检查是没问题的”。这个结论在人工时代完全成立，因为人工配置的时候，配置完非常清楚我都配置了什么内容，验证的时候直接看数据就可以了。但换成 AI 之后，它不成立了。因为 AI 做不到 100% 准确，一旦准确率不是 100%，配置人员就得全量检查；而全量检查跟自己从头做一遍差别不大，那谁还用你的工具？

因此，我做了一个决定：把原来排在后面的 “校验环节” 提前，跟前面的识别、配置拼成一个完整闭环。一方面是做好识别和配置的准确率提升，能明确告诉大家哪里准确率特别高不用检查，哪里准确率不高需要注意；另一方面是配完之后用业务数据做自动校验、业务数据错误的直接标注出来，配置人员只需要核对标红的部分。这样才真正省人力。

调整之后，效果才真正出来，原来配一套范本要一周多，现在一两天就能搞定，效率提升非常明显，已经在数十套范本上跑通了。

四、做完半年，我依然不懂 RAG

项目开始到现在，已经半年多了。我到现在依然说不太清楚RAG的完整技术架构，不知道Skill到底怎么实现的，对Agent的理解也还停留在概念层。”prompt” 这个词，我是做了好几个月之后才去查英文，才反应过来 —— 哦，原来大家天天说的提示词，就是这个东西。

但有意思的是，我在跟AI反复对话、反复调试的过程中发现：这些所谓的 “专有名词” 背后的事情，我早就在做了，只是不知道它叫这个名字而已。

所以我特别想跟同样在观望、在犹豫要不要转AI的B端产品经理说一句话：很多时候不是你不懂、不会，而是你不知道那个东西的专有名词叫啥。

五、我怎么转岗的

前不久，我看到内部竞聘公告，AI产品经理要求两个核心能力：需求抽象和AI产品化。

我仔细看了岗位要求，需求抽象，这事我干了9年了，从招投标业务里获取需求、拆业务、建模型，这件事情已经熟悉的不能再熟悉了。那AI产品化呢，说实话我也不知道具体要做啥。

但是前面那个项目给了我底气，我认为我已经接触过AI了，对这个东西有了自己的了解，而且我已经做出来一个真东西了，效率提了、数据摆在那。

不过投简历之前我还是做了一些准备。

首先，我用AI对自己进行了一次模拟面试，在这个过程中，帮助自己更深刻地梳理了自己原来的B端产品经理的能力，另一方面也是AI工具帮助我提供很多AI方面的知识，让我对AI的理解更深刻了。

另外一件事，我觉得也给了我很大的帮助。我特意去查了新部门领导的讲话，看完心里踏实了很多：领导讲AI产品方向，核心思想也是 “以业务为主，AI 技术是放大器”。我自己做项目悟出来的东西，跟新部门要走的方向是一回事。

提交了简历，新部门业务负责人要跟我面试的时候，我还是挺紧张的，虽然我认为这个岗位的要求我大部分都符合，唯一比较短缺的就是AI的技术理解，幸亏新部门也认为重要的是需求抽象能力，AI的理解可以到岗之后再加深培养。

写在最后

现在再回过头来看这一年的经历，我最大的体会是AI 不是什么神秘的东西，它就是个加速器和放大器。业务才是根，没有业务，AI也没有落地点。

你在一个行业做了五年十年，那些 “这个客户到底痛在哪”” 哪个环节最该优化 “”这个数据准不准我一眼能看出来” 的判断力，才是做 AI 产品经理的真正壁垒。再会 AI 是加分项，业务经验才是基本盘。

如果你也是一个想转 AI 的 B 端产品经理，我的建议就三条：

1. 有机会接就接，别等 “我学完了再上”，做比学得来的经验更可靠，也更能让你深入AI，了解AI，使用AI。
2. 别被名词吓住，AI是帮你解决业务问题的工具，业务问题的根本就是我们日积月累留存在身上的经验。
3. 优先争取内部转岗，内部业务整体方向不变，人员信任度更高，你拿已有的项目结果去谈，比空口说 “我想做 AI” 管用一百倍。