人艰仍“拆”！万字长文拆解电商系统框架

产品小球

在我们刚刚入行开始工作的时候，上级或导师通常会给我们提供一份所接手系统的框架架构图，告诉我们这个系统现在是这样、这样的，哪里存在这个、那个问题，所以需要我们做这个、做那个。
过了一段时间，你成为了一个有一定工作经验的产品经理，上级安排你负责另一个系统模块，当前业务反馈了很多问题或者需求，希望产品有所规划。这时候，你需要梳理当前系统的框架架构图，知道当前业务为什么会反馈这么多问题，这些问题根源何在，然后一个一个对症下药，药到病除。
又过了几年，你成为了一个能独当一面的产品专家，上级希望你规划一个新的系统模块，来支持新的业务发展，你需要思考用最快、最简单、最通用的方法，满足业务的过去、现在、以及将来的诉求。所以，你需要绘制一个新系统的框架架构图，保证他的迭代和发展是可持续的，而不是两三年后就得重构。
当我们能说我们是所负责的业务模块的专家时，其中一个标准应该是能清晰、完整、准确的绘制出系统的框架图。因为当我们可以绘制出系统框架图时，意味着我们已经达到了以下能力标准：

• 熟悉各种业务场景，因为你的系统框架一定是在满足各种业务流程而搭建的。
  
• 熟悉各种系统能力，因为你的系统框架一定是涵盖了全部的功能及能力的。
  
• 具有足够的概括和抽象能力，系统框架一定不是简单的堆砌，而是通用性原子加上灵活性组装。
  
• 具有足够的高瞻远瞩性，当你接到重构系统的需求而重新设计一套系统时，你就应该想到，如果你设计的系统无法可持续支撑业务，那它的下场就在眼前。
  

因此，我们常常会鼓励各个产品经理去拆解、去分析、去思考、去搭建系统框架，但是，这项工作是很需要时间和经验的积累的。
一个毕业生小白，如果对业务没有足够的理解，如果对系统能力没有清晰的掌握，如果没有抽象和前瞻性思考，那么这项工作将是毫无意义的。因为其梳理的框架架构只是一个能看不能用的图。
这篇文章，我想向大家讲述，如何从业务流程的视角出发，一步步搭建一个完善的电商业务系统架构流程。

一、一个自营手机商品的购买之路
1、业务场景当前你想开设一个电商平台，你采购了商品，并想将商品销售给消费者。
消费者来到这个电商平台，选购商品完成购买，并可收到货品，或者申请售后。
2、业务特点这个场景在业务流程上是相对简单的，主要核心在于采销+履约售后。像天猫自营、京东自营，都是这样的自营模式。
对于这样的业务流程，其起点一定是供应商的入驻，平台完成货品采购，并负责货品的上架、销售、运营。
3、业务流程

核心业务流程包括：
1）自营采购
平台招商团队找到供应商完成平台入驻，与平台签订采购合同，为平台供货。在供应商入驻后，平台即可确认货品的信息、库存、采购价等，这些是销售的成本及基础信息。
2）销售运营
平台运营会基于供应商确认的商品基础信息，完成商品的发布，也就是包括商品的名称、图片、价格、详细介绍等，商品上架后，用户即可在平台查看到该商品的详细信息。
在商品发布后，为了帮助商品销售，平台运营人员还会进行一定的运营动作。包括：

• 促销运营：将商品报名到促销优惠活动中，通过商品优惠刺激用户下单，帮助商品销售
  
• 流量运营：搭建活动页，并将该商品和活动进行精准投放，帮助用户更方便的查看及了解到该商品
  
• 用户运营：针对指定用户，通过APP push、短信等方式精准的触达用户，营销用户至平台交易
  

3）用户购物
用户来到平台后，首先需完成注册、登录，这是为了确认用户在平台的对应身份。
接着，用户可通过首页、推荐、搜索等各种流量场景，查找到该商品，在商品详情页了解商品的详细信息后，可选择加入购物车，或者直接下单，下单前需确认收货地址和优惠信息。
下单后，即可进入收银台，选择对应的支付方式。如果选择微信/支付宝支付，则唤起指定的APP完成支付。如果选择绑定在平台的银行卡支付，则在交易鉴权后即可完成交易。
支付成功后，该订单对应的商品库存将被锁定。
4）平台履约
库存被锁定后，订单需进行履约，也就是商品发货。
对于自营模式，常见的履约方式有两种，一种是入仓模式、一种是代发模式。
对于入仓模式，平台有自己的仓库，从供应商采购的商品会存入自己的仓库中。在订单履约时，也就是将订单下发至仓库，仓库人员进行分拣、出库、配送。这种模式下，物流效率更高，但也会有更高的仓储成本。
对于代发模式，供应商的货品不会存到平台的仓库中，而是在用户支付成功后，需要将订单推送至供应商平台，由供应商进行发货处理。这种模式下，无需多余的仓储成本，但物流时效依赖供应商，比较不可控。
5）平台售后
订单支付成功后，用户也可以申请售后，常见的售后类型有退款、退货、换货。
未发货情况下，支持用户退款，平台审核通过后，则售后成功，订单关闭，不再发货。
已发货情况下，支持用户退货、换货，需用户寄回货品，平台验货通过后，才能售后成功。当然，现在一些平台也推出了仅退款功能，也就是即使收到货了，也可以不申请退货，而是申请仅退款。
4、系统框架

为了支撑这一自营实物交易的基础流程，最基础的系统搭建，需包含以下11大系统模块。
首先，系统模块之间也有着分层、依赖关系。所以，我们可以先对基础框架进行拆分。
大家对电商的常见理解就是人、货、场。按照这三大类型进行拆分，中间还需要有一层人货匹配逻辑，简单来说，人和货需通过匹配逻辑，才能在场中得到很好的应用和转化。除此之外，还有很重要的底层支撑驱动系统，一般必不可少的就是风控和数据系统。
1）场
（1）营销系统
营销系统包括流量营销、互动营销、用户触达。

• 流量营销是指流量如何分发，包括各个核心页面的搭建管理、核心资源位的分配和管理，例如APP首页，活动页面，首页弹窗，开屏广告等。大部分电商平台都会有自己的CMS系统，核心能力是积木式的页面搭建系统，即通过拖拉拽组件，实现页面的快速搭建和发布。
  
• 互动营销是指用户的互动玩法，包括各类任务体系、抽奖、签到玩法等，系统需包含触发规则的管理、任务事件管理以及营销奖励。简单来说，就是用户在什么情况下，完成什么事情，可获得什么奖励。
  
• 用户触达则是平台如何主动去触达营销用户，主要包括触达渠道接入、触达信息模板、触达任务触发、触达数据回收。比如说用户已经90天未交易，此时通过短信营销用户，告诉用户有限时五折优惠，引导用户看到短信后，回到APP完成交易。
  

（2）黄金流程

• 黄金流程是指用户在平台产生交易的必经路径，这是用户转化的唯一、最关键、最核心的部分。
  
• 商详和购物车主要是商品介绍、呈现，包括各类商品内容、营销信息如何组装告知用户
  
• 下单除了地址、优惠、试算等模块，还有非常重要的订单体系，包括订单管理、订单状态、订单同步、订单信息记录等
  
• 支付系统主要处理支付渠道的接入、支付路由、支付信息、支付状态同步等，同时还包含支付鉴权，比如每次交易都需要我们验证密码或者人脸。如果订单发起售后，资金的回退也依赖支付系统的支持，也就是逆向交易。
  
• 履约售后模块主要是订单支付成功后如何发货以及物流同步，同时还要支持用户发起售后、申请发票等。
  

（3）促销系统

• 促销系统主要是支持用户购买商品享受对应的金额优惠，促销是一个看起来很简单，但是复杂度相当高的系统。
  
• 促销基础包括基本促销活动的全流程，包括创建、规则填写、商品提报、审核、促销失效等
  
• 促销类型包括单商品类型（单品直降、预售），多商品类型（满减、满折），支付类型（支付立减），优惠券类型（店铺券、平台券、新人券），组合类型（搭售套餐、赠品）。不同促销类型在活动配置、活动生效、下单试算都有不同的逻辑
  
• 计费核心是促销系统的关键，包括计费类型（直降、折扣）、促销优先级、促销互斥、促销叠加、促销试算到手价、促销优惠分摊。简单来说，就是如何准确配置出促销优惠金额、准确为用户计算出最优优惠、准确计算促销优惠金额的成本。
  

2）人货匹配
人货匹配是指通过算法或者人工规则，让用户可以看到、购买指定的商品。
（1）算法匹配

• 算法匹配主要集中在搜索和推荐场景。
  
• 搜索产品主要包括基础的搜索逻辑、暗纹词、热搜词、关联词等。同时还可以支持搜索意图识别纠正、搜索结果广告投放等。
  
• 推荐更侧重算法，基于商品评分、用户特征，进行粗排、精排、重排或召回。并可支持对算法进行实验。
  

（2）策略规则决策

• 策略规则决策是指由人工配置具体的策略规则，支持限制在指定场景下，什么样的用户和什么样的商品进行对应的决策。例如，在首页弹窗中，只有新用户才可以看到新用户限时五折的活动素材和入口。策略规则决策系统是精细化运营的基础和关键。
  
• 场景实例是指对决接入规则引擎的场景如何管理，包括接入方式（API、嵌入式）、场景权限、决策管理、版本管理等。
  
• 策略则是对全部策略的管理，包括支持的规则类型、 执行优先级，以及在策略上的ABtest能力。
  
• 规则包括规则生成、规则类型、规则测试、规则应用范围等。规则其实就是应用标签，通过计算表达式（包含、等于）进行组装而成。
  
• 标签是规则的基础，包括标签分类、应用范围、数据来源（接口、透传、数据、其他系统等），主要的标签类型包括用户标签、商品标签、订单标签、透传标签
  

3）人
人主要是指对用户数据的管理和应用
（1）用户基础

• 用户生命周期管理，包括用户注册、用户登录、用户注销等
  
• 用户数据管理，包括用户ID、手机号、身份证、银行卡等
  

（2）用户标签

• 用户标签是对用户数据的加工，形成对用户的基本认知，并可进行应用。用户标签本身也有生命周期管理，例如标签创建、更新机制、失效下线等
  
• 用户基础属性标签，包括性别、年龄、收入、地区、婚姻等
  
• 用户行为数据标签，包括活跃、交易、偏好等
  

4）货
货是指对商品的管理和应用，包括货品中台和供应链
（1）货品中台

• 货品中台包括货品基础信息及货品应用管理
  
• 货品基础信息包括商品的基础信息、商品定价、商品标签、商品内容、商品类目、商品品牌、商品规格等
  
• 货品应用管理包括选品、榜单、投放、治理、商品维度的销售限制及利润管控等
  

（2）供应链

• 供应链包含供应商、仓储、履约、售后。
  
• 供应商模块包括供应商的类型、入驻流程、合同管理、采购和结算管理
  
• 仓储模块包括仓库管理、地址管理、库存管理等。库存既和仓库地址相关（距离仓库太远的地方不配送），也和仓库中入库商品数量相关
  
• 履约模块包括配货路由、发货管理、物流信息等
  
• 售后模块包括售后类型、售后审核、发票管理等
  

5）支撑
基本上每个平台都离不开风控系统和数据系统对业务系统的支持，风控和数据的专业性较高，和业务系统互相独立。
（1）风控系统

• 风控系统主要是基于安全性考虑，对业务进行管控，避免出现洗钱、黑产、刷单、系统攻击等情况。
  
• 用户管控主要是对用户的识别，并在注册、登录、注销等环节对用户进行拦截管理。
  
• 交易管控主要是对每笔订单交易进行实时判断，包括防洗钱、防刷单、防薅羊毛等，同时交易鉴权也由风控决策，例如该笔交易验证本人的方式是验证密码、验证短信还是人脸/指纹识别。
  
• 系统管理则是基于系统的安全性，避免公司系统受到攻击，并有相关权限管控。
  

（2）数据系统

• 数据既是业务的上游，又是业务的下游。所有业务的开展都依赖于数据进行决策，业务的效果验证也依赖于数据的分析。
  
• 数据管理包括数据采集、数据处理、数据入仓。数据仓库是每个平台的核心资产，相当于所有数据经过一套标准化采集录入流程后，都存储在一个仓库中，并有对应的规范流程支持数据更新和提取。
  
• 数据应用包括数据报表、业务分析、监控告警。数据报表主要是对数据的呈现，业务分析则支持业务基于数据现状，进行异动归因，验证策略效果。监控告警则包括数据异常识别、告警规则配置、异常告警处理。通常监控告警都是由人为分析设置逐步转向系统智能识别。
  

二、一个店铺衣服商品的购买之路
1、业务场景当前你想开设一个电商平台，不一定都是你自己进行自营业务，也可能是其他商家来入驻。
商家入驻后，可以自己发布商品、运营、销售，并负责履约发货。
商家和平台的关系是，以扣点形式进行结算，也就是说商家在平台上每卖出一件商品，需给平台多少佣金。
2、业务特点这个场景在业务流程多了商家、发货、结算三大模块。像淘宝、拼多多，都是这样的平台+商家模式。
对于这样的业务流程，会增加一个起点，就是商家的入驻，同时，需要以商家的结算作为终点。
3、业务流程

核心业务流程主要新增以下三大模块：
1）商家入驻
商家需通过入驻流程，提交入驻资料，例如资质审核等，确认所要销售的商品范围，开设账户，缴纳保证金，经平台审核完成后，即可开店。
开店后则可正常运营，包括发布商品、创建活动等，与平台运营工作流程类似。
2）履约售后
在用户完成购物后，平台将订单推送至商家，商家需进行履约发货。一般商家发货后，只需将物流单号上传至平台，由平台根据物流单信息，向用户同步物流进度。
如果用户申请售后，也需要商家进行审核和处理。
3）清结算
在订单完成后，依据结算周期、结算规则等，平台需要将货款结算给商家。在结算时，平台会将所收扣点佣金减去，把订单剩余的应结货款打款至商家账号，商家可进行提现。
为避免“二清”不合规问题，当前清结算都需在合规的清分体系下，由清分机构提供服务。
4、系统框架

为支撑商家业务流程，系统框架上需新增——商家系统。
商家系统主要包含商户管理和清结算两大模块。
1）商户管理主要是包括平台对商户的管理以及平台为商户提供的运营能力。

• 平台对商户的管理包括商户类型、入驻流程、生命周期管理、评分机制等
  
• 平台为商户提供的运营能力，与平台自营业务运营能力类似，但一般存在一定的阉割，因为平台本身的部分数据资产属于核心机密，不会为商户开放，主要包括营销系统（页面搭建、广告投放、用户触达）、促销系统（商家自建、报名平台）、商品系统（商品发布、商品管理）、订单系统（订单管理、履约发货、售后服务）、数据系统（商家数据统计查看）
  

2）清结算主要包含平台和商户之间如何进行货款结算。

• 账户管理，主要是平台和商户的账户体系和功能，包括账户充值、提现，且账户需在清分体系中开户。
  
• 结算管理，包括结算周期、结算规则、结算佣金等，一般情况下不同店铺结算周期可不一致，不同商品的结算佣金也会不一样。
  
• 结算流程，主要是指清结算体系的资金流和信息流，以及各类结算子流程，例如货款结算、退款结算、补差结算、预结算等。
  

其他系统模块，与原系统框架设计保持一致，可能部分模块能力会有扩展，例如履约售后需兼容商家订单、促销系统需兼容商家商品报名和促销分摊计算，但整体系统框架依然保持稳定。

三、一个话费的充值之路
1、业务场景我们在电商平台，除了购物商品，其实还会有很多虚拟商品的消费需求，例如充话费、买视频会员、买游戏卡等。
一般情况下，我们选购一个商品，话费100元，输入手机号，支付100元，然后话费即到账。
2、业务特点虚拟商品的购买流程，有以下几个特点：

• 交易流程：无需填写收货地址，但需要填写账号信息，例如手机号、邮箱账号等
  
• 履约流程：无需实物发货，一般都是支付成功即到账，履约流程非常快
  
• 售后流程：虚拟商品购买一般不支持售后流程
  

3、业务流程

和实物商品业务流程相比，虚拟商品的业务流程主要体现在以下两大差异：

• 履约流程：在订单发货时，需要和供应商实时采购，采购完成后，供应商向用户实时充值，充值到账即为收货成功。对于虚拟商品，极少采用提前采购的流程，因为你并不知道用户会向什么账号充值，采购对该类商品销售是无意义的，所以他不会有前置采购流程，取而代之的是履约时实时采购流程。
  
• 售后流程：对于虚拟订单，不支持售后流程。原先的售后流程，只存在于实物订单中。
  

4、系统框架其实对到虚拟商品销售，其业务流程与之前只有轻微差异，其系统架构与之前则是毫无差异。
那为啥要单独说这一业务？
这就更加验证了文章开头说的，系统搭建是否足够抽象化、是否足够有前瞻性。
我们可以看到，对到虚拟商品业务，只需在供应链系统，针对供应商类型、供应商入驻模块支持多类型，比如该供应商是实时采购机制、入驻可能是API模式等；在黄金流程下单模块，针对虚拟商品订单，支持充值账号填写；在履约模块中，支持支付成功后实时充值……
因此，当系统框架足够原子化、抽象化，新业务的接入，自然就不用“伤筋动骨”。

四、一个自营手机商品分3期支付的购买之路
1、业务场景这几年在电商平台，常见的一个购物方式是——分期支付。
当你看到一部手机3000元时，平台告诉你，可以先使用额度完成支付，选择分多少期还款，支付完成后，即可坐等收货。后续每个月按时还款即可。常见的淘宝花呗支付、京东白条支付都属于该类场景。
也就是说用户无需先付钱，而是先享受到货品，后续每月按月还款。当然，每月还款金额，除了商品金额，还需要包含于一定的利息服务费。
2、业务特点对到分期支付场景，最大的特点是涉及到了“信贷”，而信贷的基础是“信用”，也就是说平台风控系统会对用户进行信用评估。
这个信用评估涉及到了用户购物全流程。首先，风控会基于用户提交的信息，判断可以给用户多少额度。其次，风控会在用户尝试下单时，决策用户购买该商品可用的额度值、分期数、息费等。接着，风控会在用户真正支付时，实时决策该笔订单是否可以分期支付，也就是风控审核是否通过。
如果风控判定用户分期支付成功，那么后续流程中还有一个关键角色——资金。
订单需要先进行融资，也就是说存在一个资方，先帮用户把商品货款支付给平台。融资完成后，用户就会生成账单，意思就是生成一个用户向资方借款的凭证，后续每个月用户需向资方进行还款。当全部账单还完后，则该笔交易才最终结束。
3、业务流程

和正常支付的流程相对，分期支付购物在流程上，主要有以下几大差异点：
1）额度授信
用户进入到平台，需要先提交资料信息，经过风控审核，申请获得购物额度。只有获取了购物额度，才能在平台使用分期支付。
正常情况下，购物类型的消费额度，多为循环额度，也就是说授信了10000元额度，如果使用了4000元，剩余6000元依然可用。等到4000元还款完成，则可用额度又恢复成10000元。
2）分期支付调控
当用户实际购买某个商品时，风控会调控是否允许用户使用分期支付，可使用的分期范围是多少，每个分期的息费是多少。
3）分期支付审核
当用户选定好某个商品，提交订单支付时，风控需要实时判断，该笔订单是否允许分期支付。
之所以有该审核环节，是因为授信的额度属于循环额度，授信和交易之间必然存在时间差。授信时是基于用户当时的风控表现，授予用户额度；不代表交易时，用户的风险表现未发生变化，因此需要在交易时再进行实时审核判断。
4）额度扣减
当用户支付成功后，首先会进行额度更新，也就是额度扣减。用户的可用额度随之变少。
5）订单融资
用户确认收货后，需要将该笔订单进行融资，也就是寻找到资方，承担该笔信贷单。当然，也可以先进行融资再发货，从流程上二者皆可行，取决于业务实际决策。
在进行融资匹配时，常见的有直贷、信托、保理、自持等多种资产承接方式。融资成功，代表有资方替用户将订单货款先付给平台，此时可生成账单，后续由用户进行还款。
一般情况下，消金平台都会有自持资金，也就是在其他方式融资失败的情况下，可使用自持资金兜底。
如果是先融资后发货，也可以在融资失败的情况下，将订单关闭，不进行发货履约。
6）账单处理
当到了账单还款日，用户按月进行还款，所有账单还款完成，则意味着账单完成。
如果用户申请售后，订单关单后，需要同步将账单关闭。
如果此时账单还未有还款，则关闭用户账单，额度回退即可。
如果此时账单已有还款，那么除了关闭账单，额度回退以外，还需要将用户已还款的金额也退回，该部分金额一般叫做溢缴款，顾名思义就是用户溢出来的缴款额。
4、系统框架

为支撑分期支付购物流程，整个电商系统框架需在以下几大系统模块进行兼容处理：
1）营销系统：新增金融营销模块
金融营销模块主要负责金融元素的营销，包括：

• 授信营销：引导用户授信，完成额度申请
  
• 提额营销：如果额度提升，需营销用户，促进转化
  
• 息费优惠营销：如果用户的金融定价降低，需营销用户，促销交易转化
  
• 专项额度营销：如果在某些特殊场景下，为用户提供了专属额度，也需要及时营销用户，促进用户交易
  

2）黄金流程：新增金融额度模块
黄金流程中的金融额度模块，主要承接用户端全流程中涉及分期金融元素的展示和使用

• 授信流程：支持用户填写资料，完成授信申请
  
• 授信额度：维护用户当前的可用授信额度
  
• 可用分期：基于用户风险表现、实际可用额度等，决策用户购买商品时对应的可用分期
  
• 金融定价：基于用户风险表现，决策用户购买商品时选择分期对应的金融定价，并基于此试算用户分期支付所需付的息费、月供还款额等
  
• 账单还款：当用户支付成功后，需生成账单，并支持用户按月还款
  

3）用户基础：新增用户金融信息
在用户基础中，需增加用户金融信息维护，一方面用户流程强依赖于用户的基础数据；另一方面业务分析也需要用户金融相关的画像。
主要信息包括授信状态、授信额度值、用户风险表现等。一般情况下风控系统会维护用户风险相关的各类信息，例如芝麻信用分、微信支付分等都属于该类信息。
4）资金系统：新增融资系统模块
在支撑系统中，除了风控系统需支持用户风险识别，应用于授信、交易环节外，还需新增资金系统的支持。
资金系统需要确保分期支付订单可以融资成功，只有生成账单，才意味着订单的真正支付成功。因此，资金系统需至少支持以下模块内容：

• 资方管理：引入并维护可提供资金的来源，并对每个来源的基本情况、可用资金、对于资产的要求，要清晰的管理
  
• 资产路由：当一笔订单走到融资环节，意味着这笔订单转化为了资产，这个资产需要有对应的资方进行承接。资方承接也意味着资方账单生成。
  
• 资产回购：一般情况下，如果账单，用户正常还款，那么账单则正常完成即可。如果生成账单后，因用户申请售后等各种情况，账单又关闭了，这部分资产则需要平台进行回购。简单来说，可以理解为这笔钱是资方借给用户，现在用户不要了，平台把它接下来，变成资方借给平台了。
  
• 资产处置：当用户一直没有按期还款时，实际上平台会进行催收处理。对于一些很难催收的资产，通常情况下平台会将资产打包，进行销售。这些都属于资产处置流程。
  

回到最开始讨论的话题，我们对于系统框架的拆解和设计，主要基于两方面考虑：
一是作为产品，我们需要对系统有清晰的认识，这样可以保证我们在新业务来临时，快速响应和解决。
二是作为产品，我们需要有基本的拆解能力、抽象能力、规划能力，这对个人能力和认知的提升有很大帮助。
但是我们经常在市场上看到很多课程和广告宣传，通过跟老师学习，可以掌握如何设计电商系统。我觉得这个是绝对不成立的。
首先，每个公司的价值一定具有独特性，他一定是满足了不一样的需求，这样公司才有生存的可能性。
那么，公司的价值需要靠业务实现，业务也就一定具有独特性。
最后，业务的落地靠系统承接，因此，每个公司的系统也一定具有其独特性。
我们不存在一套系统框架设计，能满足市场上全部公司的应用。
所以，当我们拆解和设计系统时，一定要按照公司业务的实际情况，基于现状和业务诉求进行处理。不是设计出来一套“高大上”，“全世界通用”的系统才是最好的。能解决业务问题，满足当前公司发展的系统，就是最好的。
上文的系统拆解及设计，也仅仅是一个参考，任何脱离了业务存在的系统，都是“废品”。
专栏作家
产品小球，微信公众号：产品小球，人人都是产品经理专栏作家。95后的产品经理，潜心专研互联网产品C端和B端设计，洞察用户需求，探索商业模式。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。