隨著ChatGPT和AI繪畫的爆火，市面上關于AI的工具型產品越來越多。作者從產品經理角度，并結合自身經驗，分享從0到1設計企業的開放平臺過程中，需要考慮哪些環節，如何設計并搭建開放平臺？希望對你有所啟發。

本篇文章介紹了從產品經理的角度，以作者親身經歷，在從0到1設計企業的開放平臺過程中，需要考慮哪些環節，搭建哪些基礎功能，技術接口設計，以及如何落地并推進開放平臺項目啟動。

寫在前面

隨著ChatGPT和AI繪畫的爆火，市面上越來越多的工具型產品繼而出現。

那么為這類產品開發以及設計者提供底層能力的OpenAI到底是什么公司？

實際上OpenAI是一家全球最著名的人工智能研究機構，發布了許多著名的人工智能技術和成果，而這次爆火的ChatGPT便是OpenAI所研發的InstructGPT模型，這是一個AI對話系統，也是OpenAI對外開放平臺收費的API能力之一。

一、企業為什么需要搭建開放平臺

什么是開放平臺？

在互聯網時代，把網站的服務封裝成一系列計算機易識別的數據接口開放出去，供第三方開發者使用，這種行為就叫做Open API。

而提供開放API的平臺本身就被稱為開放平臺。（狹義角度，本文后續將闡述當前各個企業開放平臺的定位區別）

企業為什么要搭建開放平臺？

最早嘗到開放平臺甜頭的公司是Facebook，扎克伯格所崇尚的開放思維、群體智慧和創新精神匯聚到一個平臺。

Facebook搭建的開放平臺，為網站源源不斷地注入群體開發者的智慧，開放戰略使得Facebook迅速脫穎而出，并且得以積聚人氣，為下一步的拓展、布局做好準備。

開放平臺的能力簡而概之，就是將Facebook擁有的海量社交用戶檔案和關系數據，通過API開放給第三方開發者。

一般大廠做開放平臺的目的：

• 平臺本身核心服務能力輸出（比如百度AI開放平臺，文字識別、圖像技術等一系列的技術能力，場景方案、部署方案）
• 平臺延展服務能力引入，吸引各種服務商（ISV）在上面創建應用，為客戶提供更豐富的解決方案（比如，拼多多的易掌柜、口碑的生態市場提供的各行業服務插件等等）。
• 形成平臺的生態圈以及影響力，為下一步布局做好準備。

二、開放平臺的分類以及服務形式

1. 開放平臺分類

一類是輸出自身海量的基礎數據，例如極速數據的API接口。

另外一類則是輸出自身業務能力，例如高德地圖、微信、支付寶開放平臺等。這種類型緊貼業務場景的開放平臺建設，按照業務能力形成一道護城河，也極大豐富了開放平臺這個大家庭的種類。本文也將重點闡述這種類型的開放平臺建設。

2. 服務形式

純API形式和H5形式：

如需引用請聯系作者

如需引用請聯系作者

兩種服務形式的優勢和劣勢：

兩種服務形式各有優劣勢，當然目前市面上也有變種，即某些部分H5形式 某些接口api輸出。具體哪種形式建設開放平臺，要依賴自身業務模式、團隊情況、業務發展階段、系統穩定性等諸多因素綜合考量。這也是開放平臺建設者需要第一步考慮的事情。

以我建設的開放平臺為例，最早在設計開放平臺之初，需求方來自于技術以及商務，需要一個可以便捷管理接口，支持讓異業接入方能快速接入并且投入使用。那么基于這些考慮，最早第一版本的開放平臺是只支持H5模式的輸出，一直迭代到2.0才支持API模式的輸出。業務方通常不會給太多的時間給到產品設計者，只有在保證業務模式清晰的基礎上，快速上線滿足業務方需求，才能有下次迭代。

三、開放平臺設計

1. 整體架構設計

如需引用請聯系作者

這里架構設計按照市面主流開放平臺的架構來繪制，包括門戶中心、開發者接入板塊、開放能力運營板塊、運維中心、API網關。

門戶中心：這里主要涉及到開放平臺的訪問入口，設計者需要考慮到有多少角色參與到開放平臺里。一般正常最基礎的角色是 平臺運營者、開發者，平臺提供api能力給開發者接入。再次基礎上，較大規模的開放平臺一般構建一個大生態體系，那么對于API接口服務能力的提供不僅僅需要依靠自有能力，更加重要的就是要依賴于開發商和合作伙伴的可共享能力接入。此時便有合作伙伴，也就是服務商的角色參與。

這里參考抖音的林客，本地服務商經營平臺：

開發者接入板塊：這個版塊的主要使用角色是開發者，此時眾多開發者就是直接用戶。產品經理在設計這個版塊的時候，需要考慮到各個類型的開發者。

用戶體驗里面最重要的一個原則就是把用戶當“傻子”，開發者接入板塊要做到盡可能簡明扼要，你面對的可能是剛從培訓班出來的小白，或者是接入過無數接口的大佬。

這里重點闡述一下接口文檔板塊，一直以來接口文檔的維護相較于產品說明文檔都會比較弱，強依賴于開發者的描述，需要注意的是產品經理可以適當介入接口文檔的撰寫，盡量做到文檔清晰易懂，重點注意事項需要標明。

之前在做實際對接過程中，常有錯誤返回的追述發現只是開發者看漏了部分文檔參數。

開放能力運營板塊：這里的用戶角色參與者較多，可能是平臺實際管理員、財務、客服、商務等。由于參與方較多，對該板塊的需求也會較為繁雜，產品經理需要梳理好必要的功能建設。

運維中心：運維中心承擔了推動開放平臺正常往前的齒輪角色，這里部分開放平臺會縮減部分，例如白名單管理、數據庫管理 這里在部分企業中，已經被其它系統所承擔，復用這個版塊即可，無需重新建設。

API網關：網關可以說是開放平臺的核心，承擔了整個開放平臺的流量入口，同時還要有足夠的系統容錯能力。如上圖所示，網關包含應用的校驗、能力權限校驗等功能。

市面上無論大廠還是中小廠的開放平臺，或多或少都會在其中有部分體現。中小廠在考量到開發能力，業務模式等因素，可以按照最基礎的板塊建設，但是涉及到安全中心這種必要板塊，產品經理在設計開放平臺之初就需要和公司安全部門進行協商。防止開放平臺被接口攻擊。

作為產品經理的角色，不管是哪個階段設計開放平臺，需要清晰自己業務開放平臺的最終形態是什么，反推目前必要板塊的建設。反推之后，下一步才是進行功能設計以及技術方案敲定。

2. 功能設計

由于我當前項目涉及到api形式和H5形式，這里兩塊形式都會做一定的介紹，其中有部分重疊的設計思路就不予贅述。

在正式介紹功能設計之前，產品經理需要明確一點開放平臺的服務對象是誰？

這里具體服務對象包括大型連鎖企業、中小企業、小微商家、有分銷能力商家、個人開發者、合作伙伴服務商。

根據不同的服務對象，主流開放平臺一般區分為，標準接入型開放平臺（例如微信、支付寶開放平臺）以及解決方案接入型開放平臺（例如高德開放平臺提供的解決方案）。

兩種開放平臺的整體架構不會有太大差別，但是具體對接流程、收費模式、服務形式會有差別，在這個基礎上延展出來運營設計也會有所不同。這里需要產品經理按照各自業務特性來進行設計。

根據使用角色，延展出來主流開放平臺主要解決以下幾個層面的需求：

• 開發者需求，開發者身份注冊、應用申請與數據權限授權、開發者獲取相關資料（接口文檔、使用說明、對接人聯系方式等）
• 平臺管理需求，平臺方內部管理，客戶管理，申請審核流程、服務配置、財務對賬管理、參數配置、角色分配等
• 業務需求，業務交易管理及統計看板、報表分析（涉及業務結算類型，例如預充值或者CPS返傭）
• 安全層面需求，數據加密、應用秘鑰、應用接口權限控制、系統角色權限、訪問黑白名單、字段脫敏等

如需引用請聯系作者

3. 功能設計說明

（1）運營管理后臺

開放平臺運營管理后臺主要是基于銷售、商務、運營者、財務的多端需求建成的管理后臺，其中功能需要能滿足接入申請審核、接入方管理、賬號管理、業務數據管理、文檔管理、工單管理。如果財務板塊有對賬以及開票需求，還需要融合進財務管理系統中的自動對賬中心以及自動開票中心。

（2）開發者門戶（接入方后臺）

開發者門戶的入口一般來說是網站為主，由于目前開發者大部分通過搜索引擎來查詢，網站的包裝也比較重要。門戶網站的主要功能職責就是幫助開發者用戶了解開放平臺的能力，幫助企業或者開發者做到什么，引導用戶進行注冊。

一般主流開放平臺會選擇云服務控制臺給到開發者進行應用的申請、賬戶充值等操作，控制臺一般需要承載能力簽約、賬戶充值、文檔下載檢索、業務數據查看等多項功能。

（3）后端安全中心

開放平臺的后端安全中心要解決的問題主要由兩個：由接口調用一定會碰到的數據安全以及相關鑒權。這里做安全的小伙伴一定比我更專業，產品經理需要和運維中心、安全部門同事協商考慮好開放平臺的后端安全中心建設。

四、技術接口設計

這里主要是基于目前項目的技術方案做的接口設計，當然市面上已經有很多技術大佬寫過的開放平臺技術設計方案，我這里不做過多的描述。產品經理了解大概的實現原理即可，這里更多需要關注的是接口在設計時候，作為開發者接入時候的開發成本，提高開發者的用戶體驗，我從這個角度來闡述下接口設計原則。

1. 接口簡潔性

這里要考慮到，由于不同業務輸出的復雜程度，會導致接口數量指數級飆升。如果是純API接入的開發者，在理解接口調用時序圖時會花更多時間。嘗嘗會在實際調用時卡在莫名其妙的節點，這里就需要只輸出必要接口，并且保證接口足夠簡介易懂。

由于開發平臺建設方，未必有足夠資源建設SDK中心，那么對于開發者來說就不是那么友好，因此純API接入文檔的接口和調用方式需要保證和主流接口有一定相似性，最大程度確保開發者能快速熟悉接口。

2. 接口兼容性

這里主要是考慮到，不同開發者應用的平臺不同。例如某些專門輸出給硬件廠商的開放平臺，此時就需要考慮到應用設備前端版本不同，對應參數范圍也會造成差異。這里可以考慮各自業務具體形式來設計。

五、運營設計

開放平臺的成功運行，離不開良好的平臺運營。那么這里需要對平臺運營的各個環節進行流程設計，確保每個環節都保證足夠高效。

這里我貼上一份目前項目開放平臺的對接流程示意圖

如需引用請聯系作者

大部分商業化的開放平臺項目可以基于上述流程做變更。

需要注意的是，業務輸出特性不同，會影響運營參與角色不同。比如我所在項目，實際運營人員還包括了客服，因為需要用到客服能力解決接入方平臺的客訴問題。那么次數處理流程里面就需要包含客服處理流程。以及產品需要針對業務，給內部客服部門做客服文檔，提供客服sop，優化處理流程。

六、落地細節

撰文過程中，考慮到開放平臺建設的通用性，沒有將建設的很多細節寫出來，這里我單獨加一個板塊來介紹，希望給平臺設計者避坑。

需要明確開放平臺的核心用戶是誰？大部分人的第一反應，核心用戶一定是開發者。其實這個答案可以說是也可以時候不是，由于B端商業化商品的特殊性，大部分產品設計出來是給到某一類角色用的（而非具體某個人），開放平臺的使用用戶角色大部分是開發者，這點沒錯。

然而，實際上為這個商業產品買單的用戶，大部分情況下是公司決策者，這里就代表，如果需要這個平臺持續被買單，需要滿足的核心用戶實際上是公司決策者。

舉個例子，只要是打過工的小伙伴大部分都過釘釘打卡這樣類似功能。這個產品本質上是B端產品，有簽到的功能，簽到的時候直接可以定位，對員工而言這簡直就是個反人性的功能，員工作為個體本身是很排斥打卡的，釘釘卻把打卡功能延展了各種反作弊的功能（比如定位、面容識別），可沒辦法誰讓釘釘是個B端產品。

所以B端產品就算體驗不好，甚至是反人性的，只要管理者覺得達成了管理目標，你就要必須使用系統，因為你不是你自己，你是企業的一份子。

企業決策者最關心的問題，實際上是開放平臺的能力是否能給企業降本增效，當然并不是說不需要關心開發者的用戶體驗，而是平臺設計者需要把更多的時間花在企業決策者的考慮角度上，要滿足為你付費的用戶的核心需求。

七、后記

感謝能堅持看到最后的各位，開放平臺的建設是一個長期的過程，中間會經歷多次迭代，甚至由于公司的業務的調整影響開放平臺的基礎能力的建設。

設計者除了要為功能負責之外，更多的是陪伴開放平臺的成長，開放平臺的概念最早形成于2010年左右，目前各大互聯網平臺都有自己的開放平臺生態，服務了無數開發者以及企業。隨著OpenAI的火爆，相信平臺建設者都逐漸致力于形成自己平臺的護城河，為企業提供更多元化，更有意思的能力。我作為建設者之一，也很希望看到中小廠利用核心能力建設開放平臺，也希望本文能幫助到各位建設者。