随着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的火爆，相信平台建设者都逐渐致力于形成自己平台的护城河，为企业提供更多元化，更有意思的能力。我作为建设者之一，也很希望看到中小厂利用核心能力建设开放平台，也希望本文能帮助到各位建设者。