我們說了很久：現在最稀缺的是AI技術產品經理。隨著業務越發深入，這種痛點越明顯。而將這些痛點細化，發現“AI技術產品經理“也需要面向業務做很多多個細分。一切的根源在於AI模型是個不穩定的黑盒，而這個叫做模型的東西，需要專門的人進行孵化和馴養。而需要有人對孵化和馴養的方式和成果做驗收。
傳統的互聯網業務或者遊戲業務，產品或者業務輸出需求，技術人員只需要指哪打哪就好了。而人工智能發展到當下這個尷尬的階段，彷彿它能幹很多事，但是真把它往業務裡擱就發現，這個叛逆的小東西不一定勝任的了這些有明確“規矩“的事情。
大部分Prompt工程師或者優化師都是從ChatGPT開始入手的。而作為目前地表最強的LLM之一，它能幹的好的，別的模型不一定幹得好。它能勉強幹得了的，別的模型大概率勉強都幹不了。尤其能對ChatGPT進行FT之後，這種差異變得更加明顯。
國產模型廠商也突飛猛進，基本上幾個主流大模型廠都能有至少一個還算勉強通用的大模型。雖然參差比較明顯，但是都自稱有幾個國家級的或者SP級的廠商在後面為他們站臺。而時至今日，這些廠商開始開始紛紛主動降維，希望可以面向實際行業應用去做垂類小模型。這些小模型訓練快，價格低，更容易被在意成本的B端用戶接受。
此時此刻，問題出現了：
AI服務提供商大多是由技術人員主導的，商務和銷售雖然可以協助市場開拓，但並不能主導核心技術的傾向。這就導致了現在的AI產品主要集中在技術層面，技術即產品，產品即技術。而技術體現在每一款模型的通用能力上。至於是否可以解決業務需求，並不在模型訓練師本來的考慮範圍內。這就導致銷售或者業務端越來越直觀的感受到需求的斷層：自己對模型能幹什麼並不瞭解，導致自己不知道該拿模型怎麼辦。技術人員也發現自己彷彿不著地：自己往往不知道自己的模型能解決什麼業務，舉出來的例子並不能讓業務端的人產生有用的聯想。 最近幾個月，隨著我們的遊戲業務不斷趨於落地，我們和模型廠商的對接也越來越多。因為我們開始在追求效果的同時開始追求成本，合作伙伴也開始紛紛給出一些小模型希望我們嘗試。這就導致原有的Prompt很可能無法直接在小模型上使用。因為Prompt在一定程度上屬於商業機密，所以我們不會把業務的Prompt直接給到模型廠商。所以我們就會詢問對方：請問這款模型擅長什麼？不擅長什麼？如果我們有一個這樣這樣的需求，你們希望我們如何組織Prompt？這個問題往往會讓對方措手不及。
反之，模型廠商直接面向業務的時候，大量的專業名詞和與業務毫不相干的知識會讓遊戲研發團隊的同學一頭霧水，他們只想知道：我想要這個結果，有沒有現成Demo吧？沒有匹配的，那你就說需要我等奪久吧，能不能保證效果？
而兩邊的老闆也是一樣的，業務的老闆想知道這東西對ROI有多大增益，有多少各種成本？模型的老闆想知道你們業務需要我們多少QPS，日常使用量能有多大，我要為你們額外做多少定製開發？於是雙方進入一種非常尷尬的博弈：如果模型不能為業務直接解決問題，業務就不願意投入人力去做開發。如果垂類業務不願意為模型研發買單，那麼模型廠商就不願意為定製需求做開發。這種情況最終會導致業務和技術進行“親切而友好的交流，雙方充分的交換了意見”之後，散場。散場之後互相埋怨。
突然想到之前看到的一張AI畫的咖啡機。你說它是咖啡機吧，它好像有那麼點兒意思。但是你說這東西是咖啡機吧，喝咖啡的人肯定覺得不對勁。
於是，我們開始優化AI技術應用管線：遊戲項目團隊的策劃與技術與我們的Prompt工程師、AI技術策劃對接；Prompt工程師和模型產品經理對接；模型產品經理與模型廠商和模型訓練團隊對接，對前者提供的模型進行能力評測，對後者提出訓練或微調需求。
這樣，就對產品經理來說，他們可以將項目對AI模型的能力進行拆解，並且分難度梳理測試Case。單項測試通過之後，可以將單項測試Case進行組合，面向項目可能的需求模擬複合測試Case。
這些測試Case經過產品經理的梳理後，已經從遊戲項目脫敏，可以提供給模型訓練團隊和第三方，並且可以接受不同模型提供方提供的解決方案。
逐漸的，就像前一段為場景美術搭建的SD管線一樣：一個業務的流程可能會用到多個Ckpt和多個LoRA，而每個模型在什麼時機生效由產品和實際應用者在邏輯裡編輯好。SD的定製化管線，每個項目的不同點有技術美術團隊搞定。LLMs的定製化方案由技術策劃團隊搞定。而通用能力和通用解決方案，交給產品經理來解決。產品經理團隊一方面負責尋找契合業務能力需求的模型及模型用法，一方面探索用更低的成本和更高的效率滿足項目需求。
這裡就衍生出對於產品經理能力與工作範圍邊界的重新制定：
1、 重新明確自己的用戶是誰。AI技術本身的用戶很可能不是ToC也不是傳統意義上的ToB，而是成為一個已經成型的產品中第一個零件。這個零件可大可小，可核心可週邊。所以狹義的AI技術產品經理必須明確每一個AI技術的“用戶”到底是誰。以及對這個AI技術的要求到底是什麼。當然，現在面臨的情況可能是原來業務的產品經理需要從產品商業化與體驗設計層下沉，直面AI能力的應用策略設計。
2、 Prompt能力。比如說：我們希望模型根據所給的條件進行推理，並給出答案。如果產品經理本身的Prompt能力不夠，那麼可能在他眼裡，某些模型就是無法使用的。而眾所周知，Prompt優化能力是一定要面向業務才能得到提高的。所以產品經理必須參與實際業務落地，而不能完全脫離業務。
3、 功能邊界的判斷能力。一個需求，到底用邏輯做好，還是用AI來處理好？同一個AI能力的需求，是需要Chat能力，還是用Embedding能力就夠了？有邏輯加入是否會更省？如果邏輯和AI同時參與，那麼我們對AI的能力需求是否會發生改變？這同樣需要產品經理瞭解業務需求，並且面向業務需求做多種嘗試。
4、 迭代、溝通和抗壓能力。一個訴求實現之後，還要不斷迭代。這種迭代有可能是因為業務提高標準，導致的需求變更，也有可能是ROI的壓力導致需要對現在的實現方案做優化。這需要產品經理時刻保持對各種測試Case的拓展和測試，還需要讓產品經理有能力推動業務裡的設計師、程序員以及內部的訓練師、優化師配合自己進行嘗試。這一定會帶來額外的工作量，甚至有可能在測試開發週期內會導致效果的不穩定，甚至產生負優化。
5、 抽象與間接需求提取能力。與產品功能開發不同，對“模型訓練”提需求是一件有點“抽象”的事情。讓一個模型擁有一個專項能力是一種訓練需求，而讓一個模型擁有“理解一類專項指令”的訓練需求就不那麼好提。而每一種訓練，都要和訓練師一起設計訓練集。而訓練集的質量直接導致了訓練結果的好壞。雖然訓練集的設計本身不一定要由產品經理來做，但是我想說的是從需求的產生，到訓練成果的呈現，都是沒有太多可借鑑的。
6、 程序知識、服務結構設計能力和更高的協調能力。與傳統產品功能開發不同，AI+的應用，如果將AI能力放在整個業務流程中間，那麼上游業務的輸出和下游業務的輸入都與AI的部分關聯。那麼此時，產品經理需要統合上下游和AI部分的數據結構，根據業務需求和模型能力調整上下游的接口。
7、 在浪漫的戰略與謹慎的戰術之間，把腳放在剎車上時刻準備來一腳的認慫能力。這一點，需要產品經理時刻保持清醒：產品是給人用的；功能開發是開發任務；模型訓練是科研任務。什麼意思？如果一個科研任務的結果無法預估，那麼就不要著急決定把這個科研任務的結果放進產品中的時間。如果一個科研任務產生的成本（不管是金錢成本、人力成本還是時間成本）已經超過了這個產品本身的ROI限度，那麼就要及時止損。
現在，只盼望各個行業（尤其是類似遊戲、小說這種內容直接變現的領域），都能做出新的有價值的革新產品，可以體現AI對營收與利潤擴大的直接作用。