前兩天跟朋友討論了“在極客公園創新大會中，王小川認為在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 產品經理（與模型訓練有交集的）工作中必不可少的一個環節?？赡芡瑯I的你已經在或多或少的進行這一個環節的流程，但自己還沒有感知。

在AI 2.0 時代，“TPF”中的測試集定義能力，可能會逐步演變為：產品力的一個基礎能力要求，并且是一個極具競爭力的能力項。

3. 為什么說“TPF”中的測試集定義能力會是AI產品經理的核心競爭力呢？

“TPF”能力對于AI-Native場景的重要性就不再贅述了；

在Native＋AI場景中，產品人“通過TPF不斷優化評測集解決了一個場景需求”的經驗，就可以歸納總結為這個場景的AI產品能力的一個技能點（知識），當你解決的場景需求數量達到一個量級后，就變成了你的一項方法論（智慧，亦或者 神性）。

基于TPF的分享就到這里了，期待各位AI 2.0 的產品同行者提出自己看法。

參考文章

• 對話王小川：大模型創業核心，是想好技術如何匹配產品
• 李彥宏：卷 AI 原生應用才有價值，別卷大模型了！
• 線性觀點｜當我們說“灰科技”時，說的是用前沿科技解決產業升級中最痛的問題
• 楊植麟、王小川、李彥宏激辯：TPF vs PMF