起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何設計并搭建開放平臺？
隨著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的火爆，相信平臺建設者都逐漸致力于形成自己平臺的護城河，為企業提供更多元化，更有意思的能力。我作為建設者之一，也很希望看到中小廠利用核心能力建設開放平臺，也希望本文能幫助到各位建設者。
本文由 @不知柯 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
你好，文章很有啟發，可以針對平臺架構設計，再深度講解一下嗎，例如圖示的API網關的每一項是起什么作用的，十分感謝
感謝分享，請問筆者有上線的門戶網址可以查閱學習嗎
目前項目上線的開放平臺主要面向B端企業，需要簽約后創建應用。建議可以先體驗百度、微信、支付寶、高德這種可以對個人開發者的開放平臺，整體設計理念是一致的。
好的，還想問一下這些接口是沿用已有的直接開發給商戶調用，還是說是重新出接口給商戶調用的呢【重新出的接口實際輸出內容跟原因的一樣】
可以根據自身業務依賴接口的復雜程度來決定。就我項目的接口設計來說是沿用部分已有的接口做封裝給到開發者調用，因為業務本身邏輯已經比較復雜且關鍵節點接口數量較多，如果全部重新出接口開發成本過大，測試端的壓力也會比較大。