本文探讨了 AI 时代产品经理的进化方向。文章指出，随着自然语言交互成为主流，传统产品经理面临巨大挑战。AI 产品存在技术与业务需求断层的问题，需要通过优化应用管线来解决，如建立标准化评估体系、数据闭环等。AI 产品经理需具备七大核心能力：明确 AI 用户定位、掌握 Prompt 工程、判断功能边界、强化迭代沟通、提升抽象需求提取能力、具备程序知识与服务结构设计能力、以及在战略与战术间保持理性。未来产品经理需转型为懂技术、懂数据、懂人性的复合型人才，企业也应建立复合型团队以释放 AI 生产力。
还是那句话，必须更加细分，产品经理才能在 AI 时代生存。
当 AI 和大模型带来的自然语言交互（LUI）成为主流，产品经理还有存在的价值吗？这大概是当下所有产品经理心中最大的疑问和恐惧。是不是 Prompt 做得好，就能做产品经理了？到底该怎么驯服 AI 这个「黑箱」，得到自己想要的结果？面对这些问题，资深产品专家根据自己的经验，总结了在 AI 时代中，产品经理可能需要的品质和特性。
传统的互联网业务或者游戏业务，产品或者业务输出需求，技术人员只需要指哪打哪就好了。而人工智能发展到当下这个阶段，仿佛它能干很多事，但是真把它往业务里搁就发现，这个叛逆的小东西不一定胜任得了这些有明确「规矩」的事情。
大部分 Prompt 工程师或者优化师都是从 ChatGPT 开始入手的。而作为目前地表最强的 LLM 之一，它能干得好的，别的模型不一定干得好。它能勉强干得了的，别的模型大概率勉强都干不了。尤其能对 ChatGPT 进行微调（Fine-Tuning）之后，这种差异变得更加明显。
国产模型厂商也突飞猛进，基本上几个主流大模型厂都能有至少一个还算勉强通用的大模型。虽然参差比较明显，但是都自称有几个国家级的或者 SP 级的厂商在后面为他们站台。而时至今日，这些厂商开始纷纷主动降维，希望可以面向实际行业应用去做垂类小模型。这些小模型训练快，价格低，更容易被在意成本的 B 端用户接受。
AI 服务提供商大多是由技术人员主导的，商务和销售虽然可以协助市场开拓，但并不能主导核心技术的倾向。这就导致了现在的 AI 产品主要集中在技术层面，技术即产品，产品即技术。而技术体现在每一款模型的通用能力上。至于是否可以解决业务需求，并不在模型训练师本来的考虑范围内。这就导致销售或者业务端越来越直观地感受到需求的断层：自己对模型能干什么并不了解，导致自己不知道该拿模型怎么办。
技术人员也发现自己仿佛不着地：自己往往不知道自己的模型能解决什么业务，举出来的例子并不能让业务端的人产生有用的联想。
最近几个月，随着我们的游戏业务不断趋于落地，我们和模型厂商的对接也越来越多。因为我们开始在追求效果的同时开始追求成本，合作伙伴也开始纷纷给出一些小模型希望我们尝试。这就导致原有的 Prompt 很可能无法直接在小模型上使用。因为 Prompt 在一定程度上属于商业机密，所以我们不会把业务的 Prompt 直接给到模型厂商。所以我们就会询问对方：请问这款模型擅长什么？不擅长什么？如果我们有一个这样这样的需求，你们希望我们如何组织 Prompt？这个问题往往会让对方措手不及。
反之，模型厂商直接面向业务的时候，大量的专业名词和与业务毫不相干的知识会让游戏研发团队的同学一头雾水，他们只想知道：我想要这个结果，有没有现成 Demo 吧？没有匹配的，那你就说需要我等多久吧，能不能保证效果？
而两边的老板也是一样的，业务的老板想知道这东西对 ROI 有多大增益，有多少各种成本？模型的老板想知道你们业务需要我们多少 QPS，日常使用量能有多大，我要为你们额外做多少定制开发？于是双方进入一种非常尴尬的博弈：如果模型不能为业务直接解决问题，业务就不愿意投入人力去做开发。如果垂类业务不愿意为模型研发买单，那么模型厂商就不愿意为定制需求做开发。这种情况最终会导致业务和技术进行「亲切而友好的交流，双方充分的交换了意见」之后，散场。散场之后互相埋怨。
突然想到之前看到的一张 AI 画的咖啡机。你说它是咖啡机吧，它好像有那么点儿意思。但是你说这东西是咖啡机吧，喝咖啡的人肯定觉得不对劲。这形象地说明了当前 AI 生成内容与真实业务需求之间的鸿沟。
于是，我们开始优化 AI 技术应用管线：游戏项目团队的策划与技术与我们的 Prompt 工程师、AI 技术策划对接；Prompt 工程师和模型产品经理对接；模型产品经理与模型厂商和模型训练团队对接，对前者提供的模型进行能力评测，对后者提出训练或微调需求。
这样，就对产品经理来说，他们可以将项目对 AI 模型的能力进行拆解，并且分难度梳理测试 Case。单项测试通过之后，可以将单项测试 Case 进行组合，面向项目可能的需求模拟复合测试 Case。
这些测试 Case 经过产品经理的梳理后，已经从游戏项目脱敏，可以提供给模型训练团队和第三方，并且可以接受不同模型提供方提供的解决方案。
逐渐的，就像前一段为场景美术搭建的 SD 管线一样：一个业务的流程可能会用到多个 Checkpoint 和多个 LoRA，而每个模型在什么时机生效由产品和实际应用者在逻辑里编辑好。SD 的定制化管线，每个项目的不同点有技术美术团队搞定。LLMs 的定制化方案由技术策划团队搞定。而通用能力和通用解决方案，交给产品经理来解决。
产品经理团队一方面负责寻找契合业务能力需求的模型及模型用法，一方面探索用更低的成本和更高的效率满足项目需求。这意味着产品经理不再仅仅是画原型图的人，而是成为了连接算法能力与业务价值的桥梁。
在实际操作中，建立标准化的评估体系至关重要。例如，对于文本生成任务，需要定义清晰的评分维度，包括准确性、流畅度、风格一致性等。对于图像生成任务，则需要关注构图、色彩、细节还原度等指标。产品经理需要制定这些标准，并推动技术团队落实自动化测试脚本，减少人工评估的主观性和耗时。
此外，数据闭环也是优化管线的重要一环。产品经理需要设计机制，收集线上用户的反馈数据，特别是那些模型处理失败或效果不佳的案例。这些数据经过清洗和标注后，可以作为微调模型的优质素材，从而形成'使用 - 反馈 - 优化'的正向循环。
在 AI 浪潮下，产品经理的角色正在发生深刻的变化，工作范围边界也被重新定义。以下是 AI 时代产品经理必须具备的七大核心能力：
AI 技术本身的用户很可能不是 ToC 也不是传统意义上的 ToB，而是成为一个已经成型的产品中第一个零件。这个零件可大可小，可核心可周边。所以狭义的 AI 技术产品经理必须明确每一个 AI 技术的「用户」到底是谁。以及对这个 AI 技术的要求到底是什么。当然，现在面临的情况可能是原来业务的产品经理需要从产品商业化与体验设计层下沉，直面 AI 能力的应用策略设计。
这意味着产品经理需要深入理解算法的输入输出特性，知道在哪个环节介入 AI 最合适。是在用户输入阶段做意图识别？还是在后端处理阶段做内容生成？亦或是在前端展示阶段做个性化推荐？不同的定位决定了完全不同的产品设计思路。
比如说：我们希望模型根据所给的条件进行推理，并给出答案。如果产品经理本身的 Prompt 能力不够，那么可能在他眼里，某些模型就是无法使用的。而众所周知，Prompt 优化能力是一定要面向业务才能得到提高的。所以产品经理必须参与实际业务落地，而不能完全脱离业务。
产品经理不仅要会写 Prompt，还要懂得如何构建 Prompt 模板库，如何管理版本，以及如何将复杂的业务逻辑转化为模型能理解的指令结构。这需要一定的逻辑思维能力和对自然语言处理的直觉。
一个需求，到底用逻辑做好，还是用 AI 来处理好？同一个 AI 能力的需求，是需要 Chat 能力，还是用 Embedding 能力就够了？有逻辑加入是否会更省？如果逻辑和 AI 同时参与，那么我们对 AI 的能力需求是否会发生改变？这同样需要产品经理了解业务需求，并且面向业务需求做多种尝试。
例如，一个简单的分类任务，用规则引擎可能比用大模型更快更准且成本更低。产品经理需要具备成本意识，在效果、速度和成本之间找到最佳平衡点，而不是盲目追求最新最贵的模型。
一个诉求实现之后，还要不断迭代。这种迭代有可能是因为业务提高标准，导致的需求变更，也有可能是 ROI 的压力导致需要对现在的实现方案做优化。这需要产品经理时刻保持对各种测试 Case 的拓展和测试，还需要让产品经理有能力推动业务里的设计师、程序员以及内部的训练师、优化师配合自己进行尝试。这一定会带来额外的工作量，甚至有可能在测试开发周期内会导致效果的不稳定，甚至产生负优化。
AI 项目的不确定性远高于传统软件项目。产品经理需要有强大的心理承受能力，面对模型输出的随机性，能够冷静分析原因，是数据问题、参数问题还是架构问题，并协调各方资源快速调整。
与产品功能开发不同，对「模型训练」提需求是一件有点「抽象」的事情。让一个模型拥有一个专项能力是一种训练需求，而让一个模型拥有「理解一类专项指令」的训练需求就不那么好提。而每一种训练，都要和训练师一起设计训练集。而训练集的质量直接导致了训练结果的好坏。虽然训练集的设计本身不一定要由产品经理来做，但是我想说的是从需求的产生，到训练成果的呈现，都是没有太多可借鉴的。
产品经理需要将模糊的业务痛点转化为具体的数据特征。比如，业务方说'想要文案更有吸引力'，产品经理需要将其拆解为'情感正向度提升'、'关键词密度增加'、'句式多样性丰富'等可量化的指标，以便指导数据标注和模型训练。
与传统产品功能开发不同，AI+ 的应用，如果将 AI 能力放在整个业务流程中间，那么上游业务的输出和下游业务的输入都与 AI 的部分关联。那么此时，产品经理需要统合上下游和 AI 部分的数据结构，根据业务需求和模型能力调整上下游的接口。
产品经理需要懂基本的 API 设计、数据结构转换、异步处理等概念。这样才能确保 AI 模块能够无缝嵌入现有的系统架构中，不会因为数据格式不兼容或响应超时等问题影响整体用户体验。
这一点，需要产品经理时刻保持清醒：产品是给人用的；功能开发是开发任务；模型训练是科研任务。什么意思？如果一个科研任务的结果无法预估，那么就不要着急决定把这个科研任务的结果放进产品中的时间。如果一个科研任务产生的成本（不管是金钱成本、人力成本还是时间成本）已经超过了这个产品本身的 ROI 限度，那么就要及时止损。
AI 技术日新月异，但商业落地需要稳健。产品经理要敢于在技术狂热时保持冷静，拒绝为了炫技而引入不必要的复杂性。当技术风险大于商业收益时，果断放弃或降级使用，是成熟产品经理的标志。
现在，只盼望各个行业（尤其是类似游戏、小说这种内容直接变现的领域），都能做出新的有价值的革新产品，可以体现 AI 对营收与利润扩大的直接作用。
AI 时代的到来并非要取代产品经理，而是对产品经理提出了更高的要求。未来的产品经理，必须是懂技术的业务专家，是懂数据的策略制定者，也是懂人性的体验设计师。只有不断进化，掌握上述核心能力，才能在 AI 的浪潮中找到属于自己的位置，引领产品走向成功。
对于企业而言，建立完善的 AI 人才培养体系和协作流程同样重要。不要指望单个英雄主义式的 PM 能解决所有问题，而是要打造一支包含产品、技术、运营在内的复合型团队，共同探索 AI 应用的无限可能。只有这样，才能真正释放 AI 的生产力，推动行业的数字化转型。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
