前两天跟朋友讨论了“在极客公园创新大会中，王小川认为在AI 2.0 时代，PM应该具备 TPF 能力”这一话题。TPF：Technology - Product - Fit，即：技术产品契合度。
本文小编将对以下三个话题进行较为详细的观点阐述，同时也欢迎更多有思考的业内朋友给小编提出宝贵建议。
小编作为一个产品人在遇到新鲜事物时，通常会在历史中寻找它的影子。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的产品经理，都要是非常好的人才，这是一个必要条件；
我们可以发现这两个场景有非常多的相似之处：
从王淮和王小川的分享中，小编得到的结论是：
以技术驱动增长的团队在创业初期，团队需结合自身的技术特点能力和市场需求，不断打磨平衡两者之间的契合点，从而解决用户痛点，形成市场规模。
那为何两位行业KOL大佬，都是站在以技术为核心的角度，但却提出两个不同的观点呢？
因在 “产业互联网” 爆发时：
而在 “AI 2.0 时代” 爆发时：
如果让小编用大白话说差异：
通过这样的复盘，就不难理解在AI 2.0时代，作为国内模型厂赛道KOL的王小川为什么会对AI产品人提出在“PMF”之前要具备“Technology – Product – Fit”能力要求，而非“Technology – Problem – Fit”能力要求。
王小川：TPF 首先对产品经理有要求。
第一，一定能把需求转化成测试集，测试集能让技术工程师在满足需求时发现「手感」在进步。以及把 Demo 往外推出的时候，用户提的需求分布正好和产品经理提的评测集分布一致，评测集里的结果能满足用户需求。
第二，推产品的时候会提到 PMF，看市面上的 Marketing Fit（市场契合度）分布是否一致，用户是否满意。
首先小编先基于王小川的描述，对在大模型厂工作的产品经理的“TPF”环节进行流程梳理。
在上述的流程图中，涉及到模型训练的术语，这里小编就请Kimi Chat进行名词解释：
在王小川的分享中，多次提到了“评测集”这个名词。评测集（即：测试集）对于传统产品经理的需求设计流程中其实就是“需求实现的效果评估标准”的含义。
那王小川为什么如此在意产品经理对“评测集”定义的能力呢？因为王小川是站在如何设计一款用得爽的AI-Native角度来思考这个事情，而非如何设计一款用得好的Native＋AI的角度。
这里你可能又有疑问什么是用得爽的 AI-Native？什么是用得好的Native＋AI ？
小编举个例子：
在小编理解，AI-Native 解决的是一个多维度的领域需求，而Native＋AI解决更多是一个单维度的场景需求。
可能这样的描述比较抽象，那小编用一个类比的方式：AI-Native 是在构建一个小说的世界观，而Native＋AI是构建小说中的某个章节或场景；
当作为产品经理的我们，面对一个单维度的场景需求时，定义痛点解决的效果评估标准相对较为轻松。而当面对一个多维度的领域需求，定义痛点解决的效果评估标准就变现不那么轻松了。
由于目前的大模型的不完美性，在生成过程中缺乏可解释性；在结果输出方面的诸多缺陷（如：幻觉、灾难性遗忘、局部最优解困局等）。
评测集的合理性定义是作为产品经理，在当下为数不多可以控制大模型输出效果的解决方案。
王小川提到在需求推向市场进行验证时，期望产品经理定义的评测集可以覆盖用户的需求场景。同时也印证了小编的观点。
到这里，不知道小编是否表达清楚：为什么大模型厂会重视“TPF”，以及在大模型厂的产品同学如何运用“TPF”完成需求设计呢？
前两天跟@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 了。”在小编看来也有可能在一定程度上印证了小编的猜想。
在小编的上一篇《如何跨界成为AI 2.0 PM？》中提到AI 2.0领域可以分为以下四类公司：
大模型厂和有模型自研能力的互联网大厂，小编都已经聊过了。接下来还有一类公司（有大模型微调能力的垂类头部公司）也涉及到模型训练工作。
那在这类公司里，“TPF”模式对产品经理有帮助吗？
答案是有的！
从业务层面考虑，在上文中小编已经阐述了“TPF”模式的作用及价值。虽然垂类头部公司大多发力于Native＋AI方向，评测集定义的难度远小于另外大模型厂。但不可否认的是，好的评测集定义对需求的最终输出效果的将产生了质的提升。
从个人层面考虑，“TPF”模式似乎已经成为 AI2.0 产品经理（与模型训练有交集的）工作中必不可少的一个环节。可能同业的你已经在或多或少的进行这一个环节的流程，但自己还没有感知。
在AI 2.0 时代，“TPF”中的测试集定义能力，可能会逐步演变为：产品力的一个基础能力要求，并且是一个极具竞争力的能力项。
“TPF”能力对于AI-Native场景的重要性就不再赘述了；
在Native＋AI场景中，产品人“通过TPF不断优化评测集解决了一个场景需求”的经验，就可以归纳总结为这个场景的AI产品能力的一个技能点（知识），当你解决的场景需求数量达到一个量级后，就变成了你的一项方法论（智慧，亦或者 神性）。
基于TPF的分享就到这里了，期待各位AI 2.0 的产品同行者提出自己看法。
专栏作家
杨三季，微信公众号：杨三季，人人都是产品经理专栏作家。7年互联网经验的高级产品官，深耕内容电商，互联网保险领域，擅长产品增长、数据分析、中台架构等内容。
本文原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。