AI 时代，产品经理该如何进化
还是那句话，必须更加细分，产品经理才能在 AI 时代生存。
当 AI 和大模型带来的自然语言交互（LUI）成为主流，产品经理还有存在的价值吗？这大概是当下所有产品经理心中最大的疑问和恐惧。是不是 Prompt 做得好，就能做产品经理了？到底该怎么驯服 AI 这个「黑箱」，得到自己想要的结果？面对这些问题，资深产品专家根据自己的经验，总结了在 AI 时代中，产品经理可能需要的品质和特性。
传统的互联网业务或者游戏业务，产品或者业务输出需求，技术人员只需要指哪打哪就好了。而人工智能发展到当下这个阶段，仿佛它能干很多事，但是真把它往业务里搁就发现，这个叛逆的小东西不一定胜任得了这些有明确「规矩」的事情。
大部分 Prompt 工程师或者优化师都是从 ChatGPT 开始入手的。而作为目前地表最强的 LLM 之一，它能干得好的，别的模型不一定干得好。它能勉强干得了的，别的模型大概率勉强都干不了。尤其能对 ChatGPT 进行微调（Fine-Tuning）之后，这种差异变得更加明显。
国产模型厂商也突飞猛进，基本上几个主流大模型厂都能有至少一个还算勉强通用的大模型。虽然参差比较明显，但是都自称有几个国家级的或者 SP 级的厂商在后面为他们站台。而时至今日，这些厂商开始纷纷主动降维，希望可以面向实际行业应用去做垂类小模型。这些小模型训练快，价格低，更容易被在意成本的 B 端用户接受。
01. 技术即产品：需求与业务的摸索期
AI 服务提供商大多是由技术人员主导的，商务和销售虽然可以协助市场开拓，但并不能主导核心技术的倾向。这就导致了现在的 AI 产品主要集中在技术层面，技术即产品，产品即技术。而技术体现在每一款模型的通用能力上。至于是否可以解决业务需求，并不在模型训练师本来的考虑范围内。这就导致销售或者业务端越来越直观地感受到需求的断层：自己对模型能干什么并不了解，导致自己不知道该拿模型怎么办。
技术人员也发现自己仿佛不着地：自己往往不知道自己的模型能解决什么业务，举出来的例子并不能让业务端的人产生有用的联想。
最近几个月，随着我们的游戏业务不断趋于落地，我们和模型厂商的对接也越来越多。因为我们开始在追求效果的同时开始追求成本，合作伙伴也开始纷纷给出一些小模型希望我们尝试。这就导致原有的 Prompt 很可能无法直接在小模型上使用。因为 Prompt 在一定程度上属于商业机密，所以我们不会把业务的 Prompt 直接给到模型厂商。所以我们就会询问对方：请问这款模型擅长什么？不擅长什么？如果我们有一个这样这样的需求，你们希望我们如何组织 Prompt？这个问题往往会让对方措手不及。
反之，模型厂商直接面向业务的时候，大量的专业名词和与业务毫不相干的知识会让游戏研发团队的同学一头雾水，他们只想知道：我想要这个结果，有没有现成 Demo 吧？没有匹配的，那你就说需要我等多久吧，能不能保证效果？
而两边的老板也是一样的，业务的老板想知道这东西对 ROI 有多大增益，有多少各种成本？模型的老板想知道你们业务需要我们多少 QPS，日常使用量能有多大，我要为你们额外做多少定制开发？于是双方进入一种非常尴尬的博弈：如果模型不能为业务直接解决问题，业务就不愿意投入人力去做开发。如果垂类业务不愿意为模型研发买单，那么模型厂商就不愿意为定制需求做开发。这种情况最终会导致业务和技术进行「亲切而友好的交流，双方充分的交换了意见」之后，散场。散场之后互相埋怨。
突然想到之前看到的一张 AI 画的咖啡机。你说它是咖啡机吧，它好像有那么点儿意思。但是你说这东西是咖啡机吧，喝咖啡的人肯定觉得不对劲。这形象地说明了当前 AI 生成内容与真实业务需求之间的鸿沟。
02. 优化 AI 技术应用管线
于是，我们开始优化 AI 技术应用管线：游戏项目团队的策划与技术与我们的 Prompt 工程师、AI 技术策划对接；Prompt 工程师和模型产品经理对接；模型产品经理与模型厂商和模型训练团队对接，对前者提供的模型进行能力评测，对后者提出训练或微调需求。
这样，就对产品经理来说，他们可以将项目对 AI 模型的能力进行拆解，并且分难度梳理测试 Case。单项测试通过之后，可以将单项测试 Case 进行组合，面向项目可能的需求模拟复合测试 Case。
这些测试 Case 经过产品经理的梳理后，已经从游戏项目脱敏，可以提供给模型训练团队和第三方，并且可以接受不同模型提供方提供的解决方案。
逐渐的，就像前一段为场景美术搭建的 SD 管线一样：一个业务的流程可能会用到多个 Checkpoint 和多个 LoRA，而每个模型在什么时机生效由产品和实际应用者在逻辑里编辑好。SD 的定制化管线，每个项目的不同点有技术美术团队搞定。LLMs 的定制化方案由技术策划团队搞定。而通用能力和通用解决方案，交给产品经理来解决。
