平台建設的7大問題：螞蟻AI平台實踐深度總結

情感導師 2024-02-01 5120

添加導師LINE：jaqg

獲取更多愛情挽回攻略婚姻修復技巧戀愛脫單幹貨

簡介：在支持螞蟻幾乎所有核心業務運行和發展的過程中，我們在平台建設、業務支持、平台運營、AI創新以及AI整體運營等各個方面做了很多嘗試，有了不少的收穫和感悟，在此分享給大家。

過去幾年，我和團隊一直在負責螞蟻集團內部相關平台產品的設計和運營工作。

這些平台產品包括人工智能部的A/B測試平台、機器學習平台、金融知識圖譜平台、NLP平台、智能文案平台、金融視覺(CV)平台、搜索平台、機器人平台、標註平台等，以及風控團隊的相關平台產品。這些平台產品，在背後支持了螞蟻幾乎所有核心業務的運行和發展。

整個過程當中，我們在平台建設、業務支持、平台運營、AI創新以及AI整體運營等各個方面做了很多嘗試，有了不少的收穫和感悟。

最近，我花了一些時間，將其初步梳理出來，寫成了這篇文章。

文章的內容涵蓋了「需求管理、平台設計、產品驗證、平台協同、人性對抗、跨界思維、挑戰/成長」等7個方面，既有一些抽象的、方法層面的總結，也有很多真實的、有體感的案例。

篇幅比較長，約1.5萬字。感興趣的話，可以收藏下後面慢慢看。

希望本文對你有所啟發，更期待能拋磚引玉，跟大家做深入的探討和交流。

一、需求管理：「角色錯位」與「無我境界」

1 、挖掘需求，警惕「角色錯位」，杜絕「閉門造車」。

做好產品的第一步，就是把握好需求，必須搞清楚每一個產品和功能的真正用戶是誰。

對於C端產品，這個問題比較好解決，因為設計者和使用者往往是重合的。但對於技術平台類產品、B端產品，這兩者經常是錯位的，即設計者可能並不是真正的用戶。

舉個例子，支付寶的產品經理在日常生活當中天天用支付寶付款、理財，他就是個典型的支付寶用戶，所以設計者與使用者就是同一個人。而在技術平台、B端產品當中，產品的設計者可以用自己的產品，但基本上僅限於做測試、做驗證，真正的用戶卻是其他的人。

因此，設計者對於產品需求的一些推理判斷，可能會與真實情況有差別，即使他用了，那個以測試為目的的使用和真實的使用，還是有區別的。

由此可見，正是由於技術平台類產品中這種角色的錯位，就容易導致需求把控出問題。

下面，先從我們標註平台的一個小故事開始講起。

去年12月的一天，我們標註平台的相關同學開會，進行產品設計評審。

其間，針對一個標註頁面的產品設計細節問題，在坐的產品經理、UED、前端、後端各個崗位的同學各抒己見、爭論得不可開交。

突然間，我意識到一個嚴重的問題——那就是會議室的所有同學，並不是這個feature的用戶。

因為具體的標註工作，都是外包公司的數百個標註人員做的，他們才是標註頁面的真正用戶。

不是真正的用戶、沒有處在那個場景，就很難了解真實的情況。於是，大家就只能根據自己的經驗和專業能力，進行判斷和推演。

做產品不能閉門造車。於是，我們就隨即安排相關同學去了標註外包公司做現場調研。

一開始，我們與幾個標註團隊的小組長進行小範圍的初步溝通。當時，隨口問了下產品使用情況，他們一致反饋「沒什麼問題，挺好用的」。

這樣的回答很正常，畢竟這麼簡單、直接的問法，是很難獲取到有價值的信息、了解到用戶的需求。

在產品經理的行業，我們經常說的一句話是，在汽車被發明之前，如果你直接問用戶要什麼，他只能說「我要一匹更快的馬」。釘釘原負責人無招同學來螞蟻做「釘釘創業之路」的分享時，也談到這個問題。他的觀點是，見到用戶不能只是「就事論事」，只問產品使用相關的淺層次的問題。（即使問這樣的問題，也不能問「你有什麼需求」之類很難獲得真實需求的直白的問題）。正確的方式是，先把具體的產品拋下，多了解客戶的背景、業務、狀態等整體的、背景的、來龍去脈的信息，要表現出對客戶「感興趣」，要想成為客戶的朋友。只有這樣，客戶才願意跟你多聊、深聊，只有這樣，你才能捕獲到有價值的信息。再加上，觀察客戶的具體行為和操作，就能捕捉到真實的需求，才能做到有所洞察。

於是，結束會議後，我們要求上樓到標註員工的辦公區，具體看看情況。

當我們站在標註人員身後，仔細觀察他們的操作、與他們深入交談後，就有了新的發現。

很多原來沒有想象到的使用方法和場景、產品設計的細節問題，在標註人員的不斷操作中，就顯現出來了。之前產品評審會上大家爭論的問題，自然就有了答案。

半天下來，我們總共記錄下數十個有價值的反饋和發現，並在後續工作中，一一做了處理和跟進。

可見，如果你不是真正的用戶，你沒有親眼觀察真正用戶的操作，很多問題你是無法預料到的。

大家IQ都不差，遇到問題，我們往往習慣於談方法、講邏輯，經常在會議室裡面唇槍舌戰甚至拍桌子瞪眼睛，最後誰也說服不了誰，得不到有效的結論。

在這時，不妨先問下自己「真正的用戶是誰？」，再試試「笨辦法」，走出辦公室，走到客戶那裡，去問問他們、跟他們聊聊天，看看他們怎麼用我們的產品。

那時候，很多問題便豁然開朗了。

2 、滿足需求，不斷「由淺入深」，修煉「無我境界」。

接着，讓我們的思考再深入一些。

現在，假設你已經明確了用戶是誰、摸到了需求的大概脈絡，那也要考量「對需求理解是否深入」的問題，即淺層需求和深層需求的問題。

換句話，也是手段和目的的問題——「淺層需求」往往只是手段，而「深層需求」才是目的。

舉個例子，對於我們負責的金融視覺平台，有用戶反饋「我需要模型報告」，即模型訓練出來後，將一些「準確率、召回率、AUC之類」的指標，用圖表的方式展示出來。

如果你只是將這個需求做了，那是不夠的。

為什麼呢？因為用戶要的模型報告，只是「淺層需求」——他的確需要看各種指標，但他最想要的是，在新模型訓練出來後，他要對不同版本的模型效果進行對比——不僅要知道指標是多少，更想知道指標的具體變化，哪些升了、哪些降了以及具體數值是多少。

只有這樣，才算是滿足了深層需求。

道理是相通的，類似問題在C端產品中也會碰到。

如果你留意的話，你會發現很多電商網站、汽車導購產品的產品經理已經摸到了深層需求。

比如，汽車網站裡面基本都有一個「車型對比」功能：不僅能將不同車型的各項配置、參數，用表格逐項列出來，而且還提供了「高亮不同配置、隱藏相同配置」等貼心功能。這就是深層次地滿足了用戶的需求。

因此，對於一個需求，多問幾個為什麼，多問自己「這是用戶的真實目的嗎？他用這個功能到底想幹什麼」等。只有這樣，才有可能觸及到用戶深層次的需求，才有可能做出讓用戶感到很貼心的功能。

對於深入滿足用戶需求，除了做淺層、深層的分析之外，還可以採用「分而治之」的思路，將產品從模塊和功能上分層，即分出「N級火箭」，每一級「火箭」用來滿足不同類型的用戶需求，或者同一用戶在不同階段的需求。

舉個例子，儘管我們的圖譜、NLP、CV、搜索、機器人、標註等幾個平台產品的功能各不相同，但我們還是找到了共性，即抽象出了需求分級和業務賦能的「五級火箭」，包括「功能嵌入、API調用、數據訓練、模型定製、算法開發」等五級。業務方可以根據具體情況，來選擇不同的接入方式。

第一級，功能嵌入：通過iframe等實現成本最低的手段，將平台的某個功能模塊嵌入到自己的系統當中。第二級，API調用：直接調用平台提供的成熟API，比如調用身份證、駕駛證之類的OCR識別的API。第三級，數據訓練：平台的模型符合需求，但需要提供自己的訓練數據或者字典數據等，來解決具體場景需求。第四級，模型定製：平台的現場模型不太符合要求，所以要對算法參數進行配置，然後訓練出符合自己需求的新模型。第五級，算法開發：最高級的情況，就是業務方懂算法、要開發新算法。平台則提供「算法開發、數據管理、模型訓練、模型測試和發布」等一系列深層次的能力，來提升算法研發的效率。上述「五級火箭」，由淺入深地滿足了不同類型用戶，以及同一個用戶不同階段的需求。

記得多年前，我參加了一個管理方面的高級培訓班。培訓有好幾天，內容很多，不過幾乎所有的培訓內容我都忘記了——除了一位老師無意中介紹的一個「萬能四步法」。所謂四步法，就是「分類-排序-找規律-應用」這四個步驟。無論在學習新的領域知識、接手新的工作，還是來到新的環境時，都可以嘗試這個萬能四步法，相信再複雜的問題都能迎刃而解。用戶分層、五級火箭，就是「分類-排序」的一個應用。

談完「需求/用戶分層、五級火箭」了，那是否就是對用戶需求360度、無死角地滿足了呢？

答案是否定的，因為我們還沒有做到「無我境界」。

所謂「無我」的境界，就是滿足用戶需求的時候，不能只考慮「我是誰、我有什麼」，而要忘掉自己，去看用戶需要什麼，什麼東西對用戶最有用。

比如，雖然你是做AI技術平台產品經理，但你眼裡不能只有AI、算法、模型——要做到「無我」，就是要做到：如果有一種非算法、非AI的產品策略，若能切實幫到業務，那也應該去做。

在業務同學的眼裡，有沒有算法沒關係，是不是高科技不重要——而有沒有業務效果才關鍵。正所謂，不管白貓黑貓，抓到老鼠才是好貓。

比如，我們的智能文案平台，能夠智能生成千人千面的營銷文案。過去，一直在迭代產品、提升算法能力，力圖生成更加智能、精準和個性化的文案。

然而，大家知道，算法的提升不可能一蹴而就，算法效果都是慢慢地打磨和優化的。

在這個過程中，產品經理同學不能幹等。

於是，我們就在思考，不管多麼高深的算法、多麼智能的平台，我們生產的仍然是文案。而文案這個崗位，隨着廣告行業的發展已經存在了數百年，那麼，一定有成熟的方法論和模式。

作為互聯網從業者，我們崇尚創新和顛覆，但我們還必須對行業保留敬畏之心。

於是，我們的產品經理同學就去把一些市場營銷、廣告文案經典書籍研讀了一番，總結出了所謂「18種優質文案句式/模板」，這裡面既有文案從業者的經驗總結，也有廣告學、心理學等領域的科學原理。

將這些「優質句式」、「文案法則」產品化之後，配合算法和技術，就能給業務輸出更有效果的文案。

我們相信，機器不能完全代替人，機器智能和行業知識、專家經驗等人類智慧，一定會相得益彰、交相輝映。

二、平台設計：平台產品，也必須「秒懂」

講完需求，再來說說設計。

在互聯網行業，面向C端用戶的產品不僅供給充裕、極大豐富，而且普遍都免費，獲取成本基本為0。

沒有付出，就不會「珍惜」。

所以，對用戶來說，產品必須容易上手，即必須「秒懂」。如果用戶幾分鐘甚至幾十秒看不懂、不會用，那他基本就放棄了，產品就沒有機會了。

對於中台、平台產品來說，其實也是這樣的，只不過用戶遇到不爽的體驗只能忍忍，因為使用你的產品來解決他的業務需求，這是他的本質工作。

但是，這並不意味着產品隨便搞搞就行，因為他還可以有別的選擇。你要知道，公司內部往往也有類似的產品，更不用談外部的、免費開源或者收費的解決方案了。

所以，你在平台設計上，也要下功夫，必須能快速抓住用戶，讓用戶迅速上手、接入、上線，幫助業務拿到業務結果。

如何才能做到「秒懂」呢？可以從「產品框架、術語體系、幫助指引、產品demo、統一交互」等幾個方面來考慮。

1、有清晰明了的產品框架

用戶一打開平台的頁面，就應該清晰地感知到平台能做什麼，產品框架是什麼樣的，包含什麼功能模塊，模塊之間的關係（包含、先後等），第一步做什麼、第二步做什麼，等等。

這一點看起來沒什麼深奧的，但常見的問題是，產品經理在產品設計前期，對框架的思考不夠充分。經常是到了PRD、視覺評審階段，才發現模塊設計不合理、流程不清晰等等。這時，再返工、改動，成本就大了。

更為糟糕的是，頻繁的返工和變更，會讓產品經理個人的專業性和權威性喪失殆盡。以後，還怎麼向技術提需求、磨資源？

為了避免這樣悲慘的事情發生，產品經理要在台下多下功夫。

一個好的習慣，是先在腦中重建，再動筆繪製。很多產品經理習慣一上來就畫demo，這是不對的——大腦的認知和計算資源是有限的，顧「此」就會失「彼」，當你陷入種種細節後，就不可能從根本上、框架上思考問題了。

那怎麼辦呢？可以用充分使用腦圖這種工具。具體來說，你先不要考慮任何demo圖，而是先把整個平台產品層級結構全部理出來，包括各級導航和模塊、每個模塊包含的頁面及核心功能板塊。畫好腦圖之後，站在用戶的角度，反覆梳理和模擬，直到橫向、縱向的邏輯和流程都沒有問題了，再動手做具體的demo、PRD。

2、有顧名思義的術語體系

產品的整體框架梳理清楚之後，還要重視「術語/概念體系」，即產品中的核心概念命名以及概念之間邏輯關係的設計。

這個之所以重要，那是因為，概念和術語體系是每一個領域知識沉澱的結果，也是人們學習新事物、進行溝通交流的介質。

概念複雜，產品必然複雜；概念簡單，產品才能簡單。

比如，同樣是人機交互的指令和方式，微信的「搖一搖」就能讓用戶「顧名思義」，並立馬有體感地照做，而我們支付寶的「咻一咻」，就比較難理解和付諸行動了。

又如，當年喬布斯發布iPod的時候，並沒有直接抽象地說「存儲空間高達4.8G」，而是說「把1000首歌裝進口袋」。

可見，產品中的新概念命名不合理，或者將晦澀難懂的底層術語直接暴露出來，都會對用戶造成很大的困擾。

再比如，在A/B實驗平台中，最初的概念體系自頂而下分別是「業務域-業務線-產品-實驗」。

我們發現，用戶很難分清「業務域」與「業務線」的區別，裡面的「產品」也不是大家所理解的「支付、借唄、花唄、餘額寶」這樣的產品，所以存在很多困擾。

後來，我們藉助大家熟知的「物理實驗室、化學實驗室」這些事物，將概念體系改造成這樣：達爾文是一個「實驗平台」，裡面可以創建「xxxx實驗室」「yyyy實驗室」，在每一個實驗室當中，可以做各種各樣的「實驗」。這樣，就好理解多了。

除此之外，我們還對實驗室中的角色命名進行了修改。

之前實驗權限管理裡面，有「管理員」、「成員」這兩種常見的角色設置，我們同樣參照現實生活中實驗室工作人員的崗位名稱，將其改成了「實驗室主任」和「研究員」。

有趣的是，「研究員」在阿里體系有「高P/組織部」的層級含義，這樣小小的一個文案的修改，也包含着平台設計者的「人文關懷」——對那些用A/B實驗來踐行數據驅動創新的、追求科學嚴謹做事方式的同學們，給予一點點溫情和榮耀。

而且，日後的運營活動也好做了，比如可以評比「十大研究員、十佳實驗室」等等。

總之，在設計產品的術語體系，首先是「如無必要，勿增實體」，其次，要儘量藉助大家腦海中已有的概念，而不是直接照搬技術實現，或者生造新的概念。

3 、有恰到好處的幫助指引

即使你在概念設計上下了功夫，也不能保證用戶不會產生任何疑問。

因此，就需要設計「幫助體系」，做進一步的解釋和闡述。

這裡，並不是說讓你寫一份冗長的產品文檔。文檔應該寫，但它不是重點，因為大部分人並不會仔細把產品文檔讀完才動手操作——他只有遇到問題，才有可能去查查手冊。

這裡說的「幫助體系」，指的是產品化的幫助體系，即「文檔產品化」。具體來說，就是把幫助文檔中的要點儘量嵌入到產品頁面當中，讓產品實現「自解釋」，而不是放到產品體外、僅僅存到幫助文檔中。

「文檔產品化」，具體的措施包括如下幾個方面：

頁面上有輔助說明

常見的情況，是我們的頁面太乾淨、太空了，捨不得放一句解釋的話，當用戶遇到問題，就不知所措了。所以，可以在標題下面做小字解釋、在概念上面出tip氣泡提示。對於複雜的情況，在幫助文字後面還可以加上「了解更多」鏈接——直接跳轉到幫助文檔的相應地方，而不是要用戶從頭查找。

新功能上線，有提示和告知

平台不斷做迭代改進，但經常發現用戶並不知道上了新功能。所以，可以對此做適度的提示和告知：大迭代可以蒙層彈窗、小的改動可以出小紅點，等等。

4、有簡單直觀的全流程demo

只看教學視頻學不會游泳，光學「科目一」是學不會開車的。

天花亂墜說半天，不如動手玩一遍。

現狀是，很多技術平台完全沒有demo和體驗能力。那麼，用戶就很難上手。

因此，平台一定要搭建一套「全流程、有體感、簡便易行」的demo，讓用戶親手體驗一下。

全流程，指的是你的demo要涵蓋平台的全部環節和步驟。有體感，指的是要有直觀的結果（而不是只顯示抽象的數值、json代碼輸出之類）。簡便易行，指的是要足夠簡單、幾分鐘就能完成（因此你需要內置幾組demo的語料、圖譜、數據集等等）。

舉個例子，在NLP平台和金融視覺平台當中，用戶可以很便捷地在線體驗金融NER/文本分類、身份證/銀行卡OCR的效果。

也可以全流程地完成「項目創建、數據上傳、數據打標、模型訓練、模型測試」等環節。

值得指出的是，對於平台的demo，一定要越簡單越好，千萬不要高估了人的耐心。

記得在金融視覺平台第一版全流程demo上線後，當項目組成員在具體體驗時，才發現還是很繁瑣，甚至要放棄。

要完成demo，你仍然需要寫一堆表單，比如項目名稱/簡介、模型名稱/簡介、數據集名稱/簡介，而且，還要自己準備訓練數據，不得不去網上搜索、下載幾十/上百張圖片……

後來，我們就對此做了大幅度的簡化，能點鼠標的就不要讓用戶輸字，比如自動填充各種名稱和簡介。此外，平台還內置一些測試數據集供用戶使用等等。

經過一番簡化之後，用戶才能在幾分鐘之內，完成全流程、非常有體感的demo了。

5 、有標準/統一的交互體驗

在做好每一個平台的設計之外，還需要考慮不同平台的體驗一致性，即平台的統一。

做好這件事情，既能讓用戶降低學習成本、在不同平台之間平滑切換，也能減少UED、產品經理、技術同學們的重複勞動。

首先，可以將平台通用的框架和模塊，抽象出來、統一起來，包括Portal頁、項目管理、權限管理、數據管理、任務管理、發布管理等等。

其次，將細節的體驗也統一一下，具體到組件的設計、命名、顏色、位置等等。

當我們沉澱出一套經典的產品框架和交互標準，那產品迭代速度和用戶體驗，都會大幅提升。

三、產品驗證：用不「深」，就做不好

1、要深度驗證，而不是蜻蜓點水

產品經理要真正做好一個產品，必須要自己多用。

這個道理很簡單，但這裡要談的是使用的「深度」——隨便點點、看看，跟深度使用的差別是很大的。

舉個例子，如果讓你設計導航產品中的路口轉彎提示語，你可能覺得設計成類似「前方500米路口右轉」這樣就沒問題了。

你看，既包含距離，又說清了方向，感覺已經很完美了吧。然而，當你深入使用產品時、當你自己駕車的時候，才會發現情況並非如此——你很難精確地把握是否到了500米處，很可能在300米處的一個路口就錯誤地提前右轉了。

所以，現在的導航提示不僅會說「前方500米第N個路口右轉」，並且會在不該右轉的路口提示「正在經過第N-1個路口」，只有做到這樣精細，才能保證用戶不會走錯路。

對於我們的標註平台來說，深度使用體現在做數據標註的次數——標註幾次與幾十、幾百次，你的感知是完全不同的。

標註頁面中的一些設計的細節問題，在你做一兩次標註的時候感覺不明顯，當你做上幾十次、上百次之後，再小的問題也都會暴露出來、被放大了。

比如，有一種圖像分類任務，你只需要標註「對」還是「錯」。

之前的設計，是每頁展示一張大圖，答完題後就切換到下一頁。當我們自己親自標註了幾十張之後，就感覺這樣的效率很低。

於是，我們就改成了一頁展示一二十張圖片，標註人員只需要掃一眼，把其中「對」或者「錯」的勾選出來，然後整體提交就好了（同時也減少了每一頁刷新頁面、加載圖片的等待時間）。這樣簡單的一個改動，其實並沒有什麼技術難度，但標註效率直接提升了好多倍。

2 、自己「做業務」，結果大不同

真正要把一個平台做好，不僅要像上面說的，自己多當「標註員」，更應該做做「業務方」。支持業務、賦能業務，跟自己做業務，還是有很大差別的。

下面，用我們做的垃圾智能分類的項目「分類寶」這個案例來說明下。

在2019年7月份，全國很多城市開始推行垃圾分類。

我們的同學基於沉澱的圖像、NLP和圖譜等AI技術能力，迅速開發出了智能垃圾分類的技術和產品，項目命名為「分類寶」。用戶可以通過「拍照片、語音搜索」等便捷的交互方式，在支付寶小程序以及智能垃圾回收箱IoT設備上，來體驗AI垃圾分類了。

這個項目，並不是各個業務BU給我們提需求而開始做的。這一次，我們有了雙重身份，我們自己既是平台方，也第一次做了「業務方」。

做起業務方之後，我們才發現，垃圾分類這個事情看似簡單，實際上卻包含很多複雜的環節，從「訓練數據的獲取、物品類目的整理、垃圾分類標準的維護、線上回流數據的訂正」，到「物品類目權重和優先級的調整、標註結果的確認」，再到與內部各個部門的協同、與外包ISV的對接、節假日與特殊物品的應對，等等。

經過一番手忙腳亂的折騰，總算是把項目磕磕絆絆地做了起來。

在這個過程中，我們遇到了很多之前不知道的問題，其中既有平台設計不合理的產品問題，也有訓練時間過長之類的技術問題。

更重要的是，讓我們看到了不同流程、不同系統以及不同團隊之間銜接的「真空地帶」——這正是大公司由於分工、邊界帶來的，常說的「三不管、踢皮球」的問題。而這些銜接上的問題，正是隱蔽的、極大影響效率的問題，需要被發現，通過產品和流程等機制進行解決。

「自己做業務」的這一次實踐，讓我們平台同學換了一個視角，深刻體會到了業務同學的不易，也直接推動了平台的迭代改進，以及團隊配合、流程設置的完善。

四、平台協同：連接，產生價值

前面講了很多，但大部分還是聚焦在某一個平台的個體上。

孤立存在的平台，就可能會降級成一個工具，其價值和能量就變得非常有限。

因此，要做好、做大平台，需要跳出平台本身，以連接、全局、生態的思維來看。

如果讓不同平台產生協同和連接，會產生「1+1>2」的效果。如果把封閉在平台內的「控制流、數據流」延伸出去，變成閉環，就會迸發出很多創新。

下面，介紹幾個方法和案例。

交叉鏈接，帶曝光帶流量

這是最簡單的一種平台協同的方法。每一個平台不僅要完成自己的使命，還應該考慮為兄弟平台做點什麼，比如帶帶曝光、帶帶流量什麼的。所以，我們在每個平台產品的導航欄都增加一個「AI產品矩陣」的菜單，把七八個產品的logo、名稱、鏈接都列了上去。數據表明，這個小小的菜單，每天都能為其他平台帶來可觀的曝光和轉化，做這個菜單的ROI非常高。

平台能力復用，杜絕浪費

平台在不斷迭代升級的過程中，對於一個新需求，不要一上來就自己做，而要先看看其他平台有沒有可以復用的現成的能力，哪怕是「曲線救國」或者「權宜之計」。

比如，知識圖譜平台的知識更新和智能文案平台的文案發布，都需要走打標和確認流程，我們發現標註平台的標註能力就夠用了。所以，我們就沒有重新開發，而是在平台之間打通連接，快速解決了這個問題。

反哺和閉環，實現共同發展

如果一個平台只是單向的輸出能力，而沒有從下游獲得反哺，沒有形成閉環，那也不是個完善的系統和平台。

舉個例子，我們的標註平台已經累計對上億條數據進行了打標，這些標註數據使得各類模型的訓練變成了可能。正所謂，沒有人工，就沒有智能。

在這個過程中，標註平台只是輸出價值、為智能化助力，自己並沒有從智能化中獲益。

後來，我們就考慮把這個鏈條形成閉環，即讓打標數據訓練出的模型反哺回標註平台，從而實現「智能輔助標註」。

這樣，將整個平台從「純人工標註」，轉變為了「智能輔助標註」，大大提升了標註效率、降低了標註成本。

沉澱數據資產，創造更大的價值

如果一個平台有數據的沉澱，那麼這些數據就需要深度挖掘，從而產生更多、更大的價值。

比如，每個業務最開始接入知識圖譜平台，為了解決自己的業務問題，就得從頭建Schema、導數據。但隨着平台的發展，沉澱的知識越來越豐富。那麼，後續的平台就能直接受益於之前沉澱的知識，而不一定要自己重新建設了。這就是，平台數據沉澱出的價值。

再比如，標註平台里的標註數據，在完成模型訓練之後，生命周期就終結了，躺在那裡沒有人管了，這是很可惜的。

現在我們計劃將這些數據沉澱下來、開放出去，讓數據產生更大的價值。

首先，標註數據對內開放。在業務剛接入AI平台，存在一個冷啟動的階段，最缺的是打標的數據。所以，可以將標註平台中海量標註數據梳理和開放出來，讓業務可以先到平台裡面搜索下，看看有沒有已有的數據，有的話，就可以復用。如果沒有，再考慮重新建數據。

其次，標註數據對外開放。我們可以把一些不涉及隱私、不牽扯我們核心技術能力的部分數據開放出去，為社會創造更大的價值。

比如，在智能垃圾分類「分類寶」項目中，沉澱了數十萬打標的垃圾圖像數據。在我們開放了相關模型API之外，再把其中一部分數據開放出去，就會對整個社會的垃圾智能化處理，貢獻螞蟻的一份力量。

接入開放平台，實現強強聯合

這裡，再說說開放的具體做法。如果自己直接對外開放，做起來就比較麻煩，有很多對接和維護的事情。應該考慮將自己的能力接入到現成的、大的平台，比如支付寶小程序平台/開放平台、阿里雲平台等等。藉助這些大的平台，很多獲客、對接、運維的事情，就有兜底了。

這裡，再分享一個考慮平台協同創新的思路，那就是「圖解法和窮舉法」。

一開始，平台協同創新都是散點發生的，想到一個就做一個，很不系統和體系化。後來，為了把所有「連接」和「協同」的可能性都窮盡，我們就畫了一張系統協同大圖和矩陣圖，把所有的平台都放進去，全方位地思考平台之間有什麼沒有打通的，有什麼協同創新的可能性。

這個方法，大家在做其他工作時也可以參考。

五、平台中的人性對抗

大家常說，有人的地方就有江湖。一個平台，也是一個江湖。

不同角色、訴求的人參與其中，人性就展示出來了。

因此，就需要思考人的事情，就需要對平台進行運營和治理。

1 、平台的誤用

首先，要糾正平台上出現的不正確的用法。

為什麼會存在這種情況呢？

原因在於，儘管產品經理在產品設計的時候，本身就會盡力杜絕大部分錯誤的發生，在平台的玩法中也有相應的規則告知到用戶，但大家並不會像你想象的那樣「守規矩」，他們會有意無意地「妙用」、「錯用」甚至「濫用」。

比如，在我去年負責A/B實驗平台的時候，我們曾經對平台中所有實驗進行深入分析，結果就發現了很多驚人的現象。

數百個實驗只有一個版本：正常來說，需要兩個或者更多的版本來進行對照實驗，但很多實驗竟然只有一個版本，其中一個很大的「妙用」或者「誤用」，是用戶僅僅把平台當作灰度平台來使用了。數百個實驗內流量為0：有的用戶並沒有使用平台的分流能力，而是自己做分流，這也是我們沒有料想到的。數百個實驗運行時間小於3天或者大於30天：正常來講，實驗需要運行一周左右。但很多同學將實驗運行一兩天，一看到數據有變化就把實驗推全或者下線了，這其實是不科學的。有的實驗運行了好幾十天，原因竟然是有人忘記處理了，可能實驗場景都不存在了。……可見，大家對A/B實驗的了解還是很不夠的，導致在平台上出現了各種「奇特」的用法。那麼，需要在平台培訓和產品設計等方面，做更多的工作。

除了A/B實驗這樣的平台，在我們的金融知識圖譜等平台上，也發現很多問題。

我們知道，在知識圖譜的Schema規範當中，同樣一種實體只能有一種類型。

比如，對於「公司」這個金融領域最常見的實體類型來說，全局定義一個名為「Company」之類的類型就可以了。不同的業務域，可以有不同的業務場景，但類型應該共享一個。

然而，現實情況是，業務同學為了簡單、好把控，往往都想自己創建一個類型。於是，在平台上就出現了類似Company1、Company2這樣重複的類型。

在圖譜平台上，除了Schema重複，數據也存在重複、不一致的情況，這些都需要一個一個進行治理。

然而，平台治理這件事，既是科學也是藝術——既不能放任自由，也不能卡的太嚴。尤其是在平台建設的初期，如果限制得太死，業務方是很難理解和配合的，甚至會丟掉客戶。

所以，要把握好力度。

2 、「濫用」與「違規」

上面提到的這些平台治理的問題，其實還不算太糟糕。

接下來，給大家介紹一些需要高度重視和嚴肅處理的「濫用、違規」的行為。

分別是標註平台中的兩個真實案例：「任務釋放」和「串通磨洋工」。

先說第一個，「任務釋放」功能的濫用。

考慮到外包標註人員變更比較多，所以產品經理在標註頁面上設計了一個「任務釋放」的按鈕，用於防止任務卡在一個人手中。

然而，後來標註小組長們反饋「希望取消這個按鈕」，說這個按鈕被不少標註人員用來「挑活」：當遇到難度較大的標註題目，他們就點擊「任務釋放」給跳過了。

於是，我們就把這個功能從一線的標註人員那裡收回，只給小組長開放了（這個問題也是去外包公司實地調研時發現的，之前團隊同學們都沒有料想到）。

第二個是違規行為，說的是人員串通起來「磨洋工」。

有一段時間，算法同學反饋標註速度下降了。我們分析了下報表，發現個別小組的多個標註人員的標註速度都降低了，包括之前做的比較快的人員。

經過調查發現，原來是有個別害群之馬不光自己偷懶，還教唆、串通其他人，一起降低標註速度，來集體「磨洋工」。

當然，「串通磨洋工」這個問題最根本的原因，在這些標註人員的績效管理方案上——之前採用的是月薪制而非計件制，有績效獎金但微乎其微。

最近，我們在專項建立任務難度分級標準，並在完善外包人員的整體管理方案。

3 、「太智能」了，也不行

最後，再說一個非常有趣的事情。

我們知道，如果一個產品不夠貼心，不夠聰明和智能，那用戶肯定不喜歡，但反過來，如果「太智能」了，那有時候也不行。

人是不安的、焦慮的，如果讓他感到「太過於神奇、不知道裡面發生了很麼」，他就不敢用。

舉個例子，在模型服務平台的產品當中，有同學設計了「模型一鍵部署」功能，即把離線模型部署到在線過程中的複雜、繁瑣的特徵處理等工作自動化了。

然而，當大家花幾個月開發出來後，卻發現根本找不到一個業務方，因為大家都說不敢用。最後，這個「智能」的一鍵部署功能只能無奈地下線了。

（要說明的是，並不是說「簡化模型部署」這個產品方向有問題，而是上述「黑盒的、讓用戶心裡沒有底」的方案，需要多斟酌，要多站在用戶的角度來思考）

六、跨界、跨界、跨界

所謂跨界，就是突破原有行業慣例和常規，通過嫁接其他行業的理念和技術，從而實現創新和突破的行為。

世界著名投資家、沃倫·巴菲特的黃金搭檔查理芒格，是一個極具智慧的人，他非常推崇跨界的思考方式，他指出：

你必須以跨學科的方式思考。你必須經常使用所有可以從各個學科的大一課程中學到的概念。如果能夠熟練地掌握這些基本概念，你解決問題的方法將不會受到限制。要做好技術平台的設計、運營和推廣工作，你也需要跨界的思維和打法——比如，你可以把營銷思維與產品、技術跨界地結合起來。

所謂營銷思維，簡單來說，包含「認知規律、品牌體系、素材載體、傳播路徑」等幾個關鍵點：首先，要服從人們對新事物的認識規律（簡單、直觀），搭建起一套品牌識別和記憶的體系（logo、命名），不斷策劃出有創意的活動和素材，並在合適的地方進行曝光和傳播。

那麼，對於技術平台的運營和推廣，也可以跨界地使用上述營銷領域的理論和方法。

具體來說，可以從以下幾個方面着手：

平台產品需要品牌

我們對所有的平台的品牌識別體系進行了梳理，參照「阿里動物園」的慣例，分別命名為知蛛金融知識圖譜平台、鯨語NLP平台、圖鷹金融視覺平台、千鱘搜索平台、靈犀機器人平台，每種動物的選擇都儘量體現了該平台產品的特點（畢加索智能文案平台、AlphaQ智能標註平台的名稱已經有一定認知度，就未做修改）。

除了名稱之外，我們給力的UED同學們還設計出了非常有區隔度、記憶度，異常精美的logo。有了名稱和logo，交流、傳播和推廣的時候，就好辦多了。

產品體系需要品牌

不光要給予每一個平台以記憶度和識別度，還要考慮多個平台作為一個整體，如何記憶和傳播。同樣是考慮到阿里的武俠文化，我們就包裝出了「AI中台天龍八部」的整體品牌概念，來傳播八大AI技術平台產品。後來發現，這個「天龍八部」的在內部的影響力很高，很多人都用「天龍八部」來整體指代AI技術平台家族。

運營活動需要品牌

做運營、做推廣，也需要有一個品牌的體系。所以，我們構造出了一個「AI特派員」的形象。對於我們對內發布的所有文章、視頻和海報，都納入到這個體系當中。比如，所有的內網文章標題、文章的首尾都統一格式，加入「AI特派員」的名稱和形象，這樣既方便形成統一認知，也方便大家日後檢索信息。

此外，在運營活動和物料的設計中，也有品牌營銷思維，技術和平台再高深，傳播的時候也必須考慮互動、創意和趣味。

為此，我們定製了印有平台名稱和slogan的有趣的可樂瓶，為標註產品體驗的同學頒發「聘書」等等。

由此可見，將營銷與技術、產品跨界融合，站在用戶角度進行產品品牌體系和運營活動、素材的設計，就會收到較好的效果。

七、平台產品經理的挑戰和成長

讀到這裡，你可能覺得做平台挺有趣、挺容易。

其實不然，大家都難。

對於技術平台的產品經理來說，會面臨「心、腦、體」全方位的挑戰。

在專業技能方面，除了要有產品經理崗位必須的「需求管理、產品設計、項目推動」等能力之外，還需要「懂技術」。要懂研發流程，要懂各種算法、模型的術語和原理，因為你不僅要與平台的開發團隊對話，你還要跟平台的用戶進行對話——這些用戶大部分也是技術同學。

這並不是要求你比技術同學更懂技術、代替技術同學去做技術的事情，而是要求你要理解技術點的本質，要知道這個技術能做什麼、不能做什麼，這項技術與其他技術的區別是什麼，這個技術大的發展脈絡是什麼。

當你下功夫搞清楚了這些問題之後，才不至於處於太過被動的局面。

但是，「缺乏主動權、成就感不強」，還是困擾着技術平台的產品經理同學。

要解決這個問題，可以從如下幾個方面來考慮。

深入了解業務需求，提升業務sense

平台最終是為業務服務的，平台再牛逼，對業務沒有幫助，也是不能立足的。因此，當你對業務需求有十足的把握，就能有理有據地規劃平台建設的方向，就有成就感。

考慮自己能為團隊帶來什麼獨特價值

一個項目的成功、一個平台的成功，除了專業能力之外，還需要有足夠溝通、協調、推動、BD、銷售的能力。毫不誇張地說，要做好產品，產品經理不只是產品經理，更要有產品的「小CEO」的角色。當你通過自己的多方努力，把一件事情做成，自己就會很開心，也會贏得團隊的認可。

任何一件事情，都有創新和提升的空間

對於標註平台，你可以沿着「人工標註」的老路子去做，也可以朝着「智能輔助標註」的方向去創新。對於智能文案平台，你可以只依賴算法提升的路徑，也可以主動創新，把領域知識和行業經驗產品化，來實現產品經理驅動。對於用戶反饋的獲取和產品的迭代進化，你可以使用「當面交談、問卷調查」的傳統方式，也可以嘗試「分析用戶日誌，使用大數據+AI」的新手段。要相信，只要以終為始，從業務出發，從用戶出發，就能找到產品創新的機會。

時刻敬畏產品、敬畏用戶，認真做每一件事

我們曾經用這樣一句話，來鼓勵自己團隊的同學：我們要用做幾億DAU產品的心態，來打磨幾百、幾千DAU的技術平台。認真的人不會吃虧，你今天的每一個付出，都會產生價值，都會提高自己。人生沒有白走的路，每一個「需求」都算數。

八、結語

總算到結尾了，在這裡，再對文章的內容做一個小結：

需求管理：「角色錯位」與「無我境界」

越基本、越簡單的問題，卻越難回答，也越容易被有意、無意地忽略。做產品第一步，就是要回答這些基本問題：搞清用戶是誰，搞清楚用戶的真實需求是什麼。要深度滿足用戶需求，要多問為什麼，了解用戶真實的目的。還要忘掉自己，多從用戶角度去思考。

產品設計：平台產品，也必須「秒懂」

如果一個產品一眼看過去，都亂七八糟的，搞不清楚怎麼回事，那基本上就很失敗了。因此，要從「產品框架、概念體系、幫助體系、demo體驗、交互統一」等多個方面着手，來實現「秒懂」。

產品驗證：用不「深」，就做不好

想做好產品，就要做好產品驗證，產品經理要想方設法去高頻、深度地使用自己的產品。有機會的話，還要自己「做點小業務」，你才會驚嘆「啊，原來還有這麼多問題」。在這個過程中，你自己還會有很多意想不到的收穫。

平台協同：連接，產生價值

單個平台的價值和能量是有限的，當你突破平台的界限，創造更多的連接和閉環，你就會打造出一個欣欣向榮的系統和生態。