前两天跟朋友讨论了“在极客公园创新大会中，王小川认为在AI 2.0 时代，PM应该具备 TPF 能力”这一话题
TPF：Technology - Product - Fit，即：技术产品契合度
本文小编将对以下三个话题进行较为详细的观点阐述，同时也欢迎更多有思考的业内朋友给小编提出宝贵建议
在AI 2.0 时代，为什么大模型厂重提 TPF ？在AI 2.0 时代，大模型厂的TPF模式是怎样进行的？在AI 2.0 时代，AI应用厂的PM应该具备“TPF”能力吗？一、在AI 2.0 时代，为什么大模型厂会提 TPF ？小编作为一个产品人在遇到新鲜事物时，通常会在历史中寻找它的影子
AI 2.0的开启是由于OpenAI发布的chatGPT3.5 对中国的互联网生态产生了巨大冲击而导致的
而最近一次类似的场景是产业互联网爆发（2019年）
在当时，王淮（线性资本）也提出了一个相似的概念：Technology-Problem Fit（技术与行业现存问题相契合度）1. 创业就是从一开始的Technology – Problem – Fit转换为最后能够变革到有效Product – Market – Fit的过程
2. 当创业公司提供的不再是一款消费品或是 App，而是依托于新兴技术的一项解决方案或企业服务
这个时候，Technology – Problem – Fit 可能会比 Product – Market – Fit 更适合当作突破口，来指导技术创业项目的冷启动
3.这样的产业变化对人才提出了什么要求？第一个是懂技术，原来搞技术或者做有技术 Sense的产品经理，都要是非常好的人才，这是一个必要条件；我们可以发现这两个场景有非常多的相似之处：都是依托于新兴技术，提供一项解决方案或企业服务；都认为项目创业初期，应从技术角度出发，而非市场角度出发；都认为产品经理需要懂技术，或具备技术Sense
从王淮和王小川的分享中，小编得到的结论是：以技术驱动增长的团队在创业初期，团队需结合自身的技术特点能力和市场需求，不断打磨平衡两者之间的契合点，从而解决用户痛点，形成市场规模
那为何两位行业KOL大佬，都是站在以技术为核心的角度，但却提出两个不同的观点呢？因在 “产业互联网” 爆发时：5G等技术是相对成熟的，技术能力领先于市场痛点
大多数产品人对5G、大数据、云计算等非全新技术的能力优势和缺陷都有足够的认知能力；而在 “AI 2.0 时代” 爆发时：大模型技术不够成熟的，大模型技术能力落后于市场痛点
大多数产品人对大模型的能力优势和缺陷都没有足够的认知能力；如果让小编用大白话说差异：Technology – Problem – Fit：典型的锤子找钉子；我（技术）是高富帅，你（PM）按我的标准帮我找个白富美吧~~Technology – Product – Fit：我（技术）就是只青蛙，你（PM）就说怎么穿搭，能让我吃到天鹅肉吧~通过这样的复盘，就不难理解在AI 2.0时代，作为国内模型厂赛道KOL的王小川为什么会对AI产品人提出在“PMF”之前要具备“Technology – Product – Fit”能力要求，而非“Technology – Problem – Fit”能力要求
二、在AI 2.0 时代，大模型厂的 TPF 模式是怎样进行的？王小川：TPF 首先对产品经理有要求
第一，一定能把需求转化成测试集，测试集能让技术工程师在满足需求时发现「手感」在进步
以及把 Demo 往外推出的时候，用户提的需求分布正好和产品经理提的评测集分布一致，评测集里的结果能满足用户需求
第二，推产品的时候会提到 PMF，看市面上的 Marketing Fit（市场契合度）分布是否一致，用户是否满意
首先小编先基于王小川的描述，对在大模型厂工作的产品经理的“TPF”环节进行流程梳理
在上述的流程图中，涉及到模型训练的术语，这里小编就请Kimi Chat进行名词解释：在王小川的分享中，多次提到了“评测集”这个名词
评测集（即：测试集）对于传统产品经理的需求设计流程中其实就是“需求实现的效果评估标准”的含义
那王小川为什么如此在意产品经理对“评测集”定义的能力呢？因为王小川是站在如何设计一款用得爽的AI-Native角度来思考这个事情，而非如何设计一款用得好的Native＋AI的角度
这里你可能又有疑问什么是用得爽的 AI-Native？什么是用得好的Native＋AI ？小编举个例子：AI-Native：ChatGPT、Claude、Midjourney；Native＋AI：Adobe-Firefly、通义听悟；在小编理解，AI-Native 解决的是一个多维度的领域需求，而Native＋AI解决更多是一个单维度的场景需求
可能这样的描述比较抽象，那小编用一个类比的方式：AI-Native 是在构建一个小说的世界观，而Native＋AI是构建小说中的某个章节或场景；当作为产品经理的我们，面对一个单维度的场景需求时，定义痛点解决的效果评估标准相对较为轻松
而当面对一个多维度的领域需求，定义痛点解决的效果评估标准就变现不那么轻松了
由于目前的大模型的不完美性，在生成过程中缺乏可解释性；在结果输出方面的诸多缺陷（如：幻觉、灾难性遗忘、局部最优解困局等）
评测集的合理性定义是作为产品经理，在当下为数不多可以控制大模型输出效果的解决方案
王小川提到在需求推向市场进行验证时，期望产品经理定义的评测集可以覆盖用户的需求场景
同时也印证了小编的观点
到这里，不知道小编是否表达清楚：为什么大模型厂会重视“TPF”，以及在大模型厂的产品同学如何运用“TPF”完成需求设计呢？三、在AI 2.0 时代，AI应用厂的 PM 应该具备TPF能力吗？1. 有大模型自研能力的互联网大厂前两天跟@Super黄讨论这个话题时，Super黄引用了李彦宏分享的一段内容：张鹏：这个也引发一个话题，你看过去移动互联网的时候，我们要做一个开发，大概知道是个什么流程——要有产品经理画出原型，前端、后端实现
在 AI 时代，基于大模型做 AI-Native 的开发，我们到底开发的是什么？李彦宏：我觉得从应用的角度来讲，倒没有什么特别的，就是你要解决什么问题、给别人带来什么样的价值，这个跟过去时代的开发相比是一样的
但是使用的方法确实不一样，对产品经理的要求，对于研发人员的要求，对于一个公司的组织能力，可能都是跟以前不太一样的
今儿小编在写这篇分享前，仔细阅读了李彦宏的全部发言后，对这个@Super黄的论点有一些不太一样的思考
首先我们先看一下上文中的后半段内容：但是使用的方法确实不一样，对产品经理的要求，对于研发人员的要求，对于一个公司的组织能力，可能都是跟以前不太一样的
今天在百度的话，PM（产品经理）和 R&D（研究与开发）的比例是发生变化的
过去我们一个PM要对很多 R&D，今天可能是 1:1 了
或者说很多做法在前期进行测试的时候不太需要 R&D 介入，PM 自己攒一个东西就可以做到，这是跟以前比较不一样的地方
李彦宏虽然没有提到“TPF”这个概念，但字里行间内又表示，在很多idea（需求）的前期测试阶段：不太需要 R&D 介入，PM自己“攒”一个东西就可以做到
作为产品人，咱们都知道在MVP阶段，PM自身具备开发能力，且能够独立完成需求测试的人是少数的
所以小编理解，这个“攒”就是PM自己完成的了“TPF”阶段
李彦宏的另一句话 “过去我们一个PM要对很多 R&D，今天可能是 1:1 了
”在小编看来也有可能在一定程度上印证了小编的猜想
2. 有大模型微调能力的垂类头部公司在小编的上一篇《如何跨界成为AI 2.0 PM？》中提到AI 2.0领域可以分为以下四类公司：大模型厂和有模型自研能力的互联网大厂，小编都已经聊过了
接下来还有一类公司（有大模型微调能力的垂类头部公司）也涉及到模型训练工作
那在这类公司里，“TPF”模式对产品经理有帮助吗？答案是有的
从业务层面考虑，在上文中小编已经阐述了“TPF”模式的作用及价值
虽然垂类头部公司大多发力于Native＋AI方向，评测集定义的难度远小于另外大模型厂
但不可否认的是，好的评测集定义对需求的最终输出效果的将产生了质的提升
从个人层面考虑，“TPF”模式似乎已经成为 AI2.0 产品经理（与模型训练有交集的）工作中必不可少的一个环节
可能同业的你已经在或多或少的进行这一个环节的流程，但自己还没有感知
在AI 2.0 时代，“TPF”中的测试集定义能力，可能会逐步演变为：产品力的一个基础能力要求，并且是一个极具竞争力的能力项
3. 为什么说“TPF”中的测试集定义能力会是AI产品经理的核心竞争力呢？“TPF”能力对于AI-Native场景的重要性就不再赘述了；在Native＋AI场景中，产品人“通过TPF不断优化评测集解决了一个场景需求”的经验，就可以归纳总结为这个场景的AI产品能力的一个技能点（知识），当你解决的场景需求数量达到一个量级后，就变成了你的一项方法论（智慧，亦或者 神性）
基于TPF的分享就到这里了，期待各位AI 2.0 的产品同行者提出自己看法
参考文章对话王小川：大模型创业核心，是想好技术如何匹配产品李彦宏：卷 AI 原生应用才有价值，别卷大模型了
线性观点｜当我们说“灰科技”时，说的是用前沿科技解决产业升级中最痛的问题杨植麟、王小川、李彦宏激辩：TPF vs PMF专栏作家杨三季，微信公众号：杨三季，人人都是产品经理专栏作家
7年互联网经验的高级产品官，深耕内容电商，互联网保险领域，擅长产品增长、数据分析、中台架构等内容
本文原创发布于人人都是产品经理
未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

（图片来源网络，侵删）