如何体系化构建复杂的B端系统（一）

Sponsor

为什么B端产品总是容易“失控”？B端产品设计与C端有何差异？如何在不断复杂的系统中，权衡效率、成本、体验之间的关系？

本文将带你从B端产品的本质出发，了解产品发展过程中容易出现的问题，并从复杂系统的角度去探讨设计体系的构建方式。

目录

一、「 困局 」容易“失控”的B端产品

A .「 关注重点的差异性 」

B .「 微小差异的不断叠加 」

C .「 产品发展进入恶性循环 」

D .「 进入效率拐点，产品失控 」

二、「 启发 」从复杂科学的角度思考设计

A.「 自然算法 」

B.「 物质的构成原理 」

三、「 探究 」什么是产品设计体系？

A.「 定义 」

B .「 组成部分 」

C .「团队能力要求 」

D .「 构建方向 」

四、「 剖析 」B端产品的生命周期

「 产品生命周期概述 」

A .「 初创期 」解决核心问题，产生价值

B .「 成长期 」能力完善，产品扩张

C .「 成熟期 」效率提升，快速增长

D .「 暮年期 」商业价值降低，发展逐渐停滞

NEXT、「 下期预告 」设计体系的构建法则

前言

随着产业互联网时代的到来，市场对B端产品的重视程度逐渐提升。然而，谈及B端产品，特别是SaaS产品，大多数设计师对此并不是特别感兴趣。一来，SaaS更注重功能层面，似乎本身对设计的要求并不高；二来，SaaS产品的最终实现效果总是不尽人意，就算设计得再好看，实现出来也难以出彩。

确实，若设计师仅仅只是关注视觉层面本身，那么B端产品确实不像C端那么吸引人。但是，若你能以整个产品构建的角度去思考B端产品设计，那么设计师能够在其中发挥的空间是巨大的。

假如把C端产品比作精致的小房子，那B端产品就是一幢巨大的高层建筑。建造小房子，你可以尽情地发挥创意，追逐潮流，大不了推倒重来。而建造大房子，则需要设计师考虑更多的维度，因为这是一个长期而复杂的工程。

建筑的外观不仅需要好看，更需要足够耐看、稳定；为了适应更多人的需求，你不仅要考虑房子的软装，还要考虑户型的合理性、通用性；而为了降低成本，你还需要考虑家具、硬装的标准化、房间的兼容性等等…

“你是否有信心建造一个宏伟的高楼大厦？” 

这是我在B端设计中，反复强调体系化思维的原因之一。想要建造一个大型建筑，没有体系化思维、没有更完善的多职能协作流程，那么这座高楼一定会在建设过程中埋下隐患。而当问题一旦出现，涉及到的沉没成本也将会非常巨大。

当然，对于C端产品来说，体系化也愈发重要了。随着互联网时代的持续发展，一些C端产品的复杂性也堪比B端。我在之前的文章中提到过一个观点：“C端B化，B端C化”。在未来的数字产品设计中，B端产品将会逐渐开始重视产品的外观与体验，因为触达的人群更年轻化、对体验要求更高了。而C端产品也会更注重体系化建设，因为产品体量越来越大，需要寻求效率与成本之间的平衡点。

产品设计体系，本质上是一套更科学的复杂性数字产品的设计方法与工作流程。因此，不管是B端产品还是C端产品，设计体系能够在提升设计品质的同时，让产品更“可控”，提升效能，降低成本。

这套设计方法论，是我在工作中不断实践与完善的一些经验与方法。希望能借此分享一些自己浅薄的经验，也探讨一下数字产品设计未来的形态。

一、「 困局 」容易“失控”的B端产品

–

作为较为复杂的数字产品，B端产品在快速发展的过程中，总是容易出现一些问题。特别是当产品体量到达一定阶段后，问题就会逐渐暴露出来，比如：

1. 产品丑、设计质量低；

2. 组件样式繁多，操作习惯不一致；

3. 新老系统差异大，不同模块体验差异大；

4. 页面结构混乱。

等等…

很多问题大家都能明显地意识到，但往往因为“不影响售卖”、“价值不高”、“新功能优先”等理由被搁置。

随着问题逐渐积累，产品的优化成本也变得越来越高，最终使整个产品已经积重难返。若只是多部分页面/组件进行优化，小修小补，虽然成本低，但成效甚微；若是进行大修大补，那么优化成本将远大于研发新功能的成本。

这种普遍的B端产品现象，被称为“产品失控”，即——团队已经对整个产品的形态失去控制力。

那么，为什么B端产品特别容易出现这种问题呢？

A.「 关注重点的差异性 」

首先，产品的本质决定了其关注重点的差异性。

与C端产品不同的是，B端产品往往更看重“能力”（为企业用户解决问题），而产品的销售方式与付费模式，也决定了产品体验并非首要关注的对象。由于B端产品通常针对企业用户，需要更长的研发过程，产品的体量和复杂性也相对较高。因此，除了产品解决问题的“能力”之外，产品还需要关注研发的效率及成本。

因此，在产品的发展初期，企业通常对效率最为关注，其次是成本，最后才是体验（能用就行）。绝大多数B端企业，只有在产品跑通商业逻辑，并具备一定用户与盈利预期之后，才会对产品的体验逐渐重视起来。

B.「 微小差异的不断叠加 」

任何微小的差异，在无数次的叠加之后，都会被快速放大。特别是当团队的人员逐渐增多后，放大速度将会呈指数级上升。

为了配合产品的快速发展，产品往往会采用“堆量”的研发模式。增加研发效率，最简单直接的方法便是投入更多的资源。随着产品不断增加模块、功能、页面，团队人员也在不断地扩充。

但是，人类不是机器，并非简单的1+1=2。团队数量的上升虽然会带来效率的短期提升，但同样也会增加团队的管理成本。不同的产品经理、设计师、研发人员，对于产品的认知是不同的。随着团队人员的不断增加，“个体差异性”将会被不断地叠加与放大。

就像“传话筒”的游戏一样，同一个事物，不同的人理解总是不同的，经过多次的“传话”以后，往往与原本的意思已经大相径庭了。

这种情况表现在产品设计中，则会出现：当相同的组件由不同的人做时，总是会在基本样式、实现原理、交互细节等不同的维度出现差异。比如上图中的导航菜单组件，不同的模块在开发时总是会存在差异，最后差异越来越大，形成了五花八门的导航菜单形式。

C.「 产品发展进入恶性循环 」

令人遗憾的是，虽然问题很明显。但是在不断的“成本考量”中，产品团队往往优先关注新功能的开发，而忽略底层问题的优化。

随着产品的快速发展，产品的优化/迭代成本将会逐渐大于研发新功能的成本。要么背负巨大的成本进行整体重构；要么降低标准，继续以这种模式不断叠加新功能。

在这种情况下，大部分B端产品往往会选择后者。于是，产品的发展将会进入一个“恶性循环”：

产品快速发展，功能不断叠加；

各模块由不同的产品、不同的开发研发，导致各模块之间差异增加；

产品丑、体验不统一，但老系统优化成本过高。综合衡量，优先进行新功能研发；

所有模块标准不统一，产品迭代效率持续降低，维护成本持续增加。

…

D.「 进入效率拐点，产品失控 」

产品的发展犹如一辆快速奔驰的巨型列车，一旦加速便难以停止。

随着问题的反复出现，以及在一次次的“利益权衡”中选择性的忽略，产品的恶性循环不断重复，而问题也逐渐叠加、沉积下来。

当这个问题已经大到我们无法回避时，我们才发现：产品的单位迭代/优化成本，已经远远大于新功能的研发成本。而新功能带来的增量，已经无法抵消现有模块的迭代成本——产品迎来了效率拐点。

就像一个庞大而复杂的机器，虽然依旧可以运行，但整体效率已经很低了，而与之对应的维修成本则非常巨大。小修小补根本无法解决问题，而大修大补则很有可能会带来更大的亏损。

最终，产品逐渐在“失控”中难以自拔，竞争力逐渐降低，但整个团队对此却无能为力，严重影响了企业的发展。

那么，在产品发展中，我们应该如何避免这种情况呢？换而言之，一个高度复杂的数字产品，我们应该如何设计，才能避免其逐步走向混乱？

二、「 启发 」从复杂科学的角度思考设计

–

如果我们将B端产品看作是一个复杂系统，那么产品“失控”的本质即——在不断复杂化的形态中，缺乏有效的控制机制，最终导致整个系统失去控制。 

但是，在大自然面前，B端产品这种复杂程度显然不值得一提。

像大自然这样的复杂系统，是如何构成的？所有的物体都由原子所构成，为什么简单的一百多种原子，能够构成如此复杂的世界？生命又是如何在无机物的世界中诞生，并逐步进化成如此复杂的个体的？

A.「自然算法 」

道生一、一生二、二生三、三生万物…无论是老子的《道德经》，还是《深奥的简洁》、《万物皆数》、《复杂》这些现代的书籍中都阐述了这样一个观点：

任何看似复杂而又可控的系统，一定存在着精简的“算法”，通过不断的叠加从而形成复杂系统。

就像爱因斯坦说的：“宇宙最不可理解之处，就是它居然是可以被理解。”

在大自然中，有很多的花纹与图案的形状都存在相同的规律。比如上图中的羊齿草分形图案，这种图案在森林当中到处可见，我们看到很多树的形状跟叶子的形状是一致的，这就是一种分形图案。而这种分形的图案本质上是一个公式，通过不断地自我引用进行迭代，这便是分形。

科赫曲线（Koch curve）就是一种分形。其形态似雪花，又称科赫雪花（Koch snowflake）、科赫星（Koch star）、科赫岛（Koch island）或雪花曲线（Snowflake curve）。

它最早出现在瑞典数学家海里格·冯·科赫的论文中。我们将一根直线分成四段，然后向中间挤压形成等边的倒V形状；接着再将每个倒V的边进行相同的操作，不断地重复之后，我们发现：第一步是倒V型、第二步变成了大卫星，第三部变成了枫叶，第四步… 经过无数步以后，最终成了越来越复杂的“雪花”形态。

科赫曲线便是“自然算法”的一种。海岸线虽然很复杂，但是却有一个重要的特性——自相似性。从不同比例尺的地形图上，我们可以看出海岸线的形状大体相同，其曲折、复杂程度也很相似，换句话说，任意一段海岸线就像是整个海岸线按比例缩小的结果。而海岸线的构成原理就是这种科赫曲线，它是通过天然的演化，不断折叠最终形成了这种形状。

可以发现，他们都是由基础物质 x 简单算法 x 随机变量，经过无数次叠加后，最终形成了一个复杂而多变的整体。

B.「 物质的构成原理 」

宇宙中还有其他各种惊人的“巧合”。爱因斯坦的相对论揭示了宏观世界的规律性，普朗克和海森堡的量子力学揭示了微观物质世界的规律。当我们从微观世界到天文学会发现——原子核的构成方式居然与天体的构成非常相似。粒子围绕原子核的运动方式，就好像行星围绕太阳运动一样。

不管是整个宇宙，还是生命体，将其置于复杂科学的研究框架中，那些基本定律最终也会变得极其简单。

在宇宙中所知最为复杂的形态，便是如同我们自身的生物。这些复杂体由已知存在于银河系中最普通的物质所构成。但是，通过氨基酸的形态，这些基本原料竟能自然地将自己组合成一个自组织系统。

混沌中隐藏的算法，使宇宙成为极有秩序的地方。而在秩序中隐藏的随机数，又使得宇宙成为极为丰富的世界。

也正是因为算法的精简，一切物质的创造才能具备复制性、延续性、进化性。

那么，我们反过来思考——想要使复杂的系统简单可控，是否就需要一套简洁、有效的“算法”？通过“算法”，将基础的“物质”不断地“有序叠加”，形成一个可控的复杂体系。

因此，对于复杂的SaaS系统设计，我开始引入“设计体系”这一概念，希望能够找到未来SaaS产品设计的发展方向。只有设计体系的建立，才能保证产品可控性，才能在不断复杂系统中，保证效率、成本、体验之间的平衡。

三、「 探究 」什么是产品设计体系？

–

产品设计体系，在国内仍旧是较为陌生的词汇。什么是设计体系？

A.「 定义 」

一个成熟的数字产品，需要有一个稳定、且持续迭代的形态。创造这个形态的过程，我们称之为广义上的产品设计（这里指产品的整个策划和设计过程，包含策划、交互、视觉及部分前端开发）。而负责控制和维护这个形态的这套系统，便是产品设计体系。

我们接触到的更多是设计系统（Design System），比如平台级的设计体系，Apple、Google、Microsoft等系统级的设计系统，及其设计开发套件、应用生态。公司级的设计系统，如Airbnb设计系统、IBM的Carbon设计系统、蚂蚁金服的Alipay Design等。

但是，在一个企业内部，想要Design System能够系统性地运转，还需要基于这套标准建立的团队协作机制。只有设计标准与团队协作标准完美融合，才能建立真正的设计体系。

B.「 组成部分 」

如果将数字产品比作复杂的“生命体”，产品的发展比作竞争中“自我进化”，那么设计体系便是产品的DNA。它既是产品形态的控制源，又是不断自我迭代的进化源，它的作用是：

控制产品外观——感知性模型（视觉风格/规范）

制造基础构件——功能性模型（基础/复合组件）

模块的构建规则——模式语言（产品框架规范）

产品标准定义、生产方式制定——协作模型（高度协同的工作流程）

它不仅能控制产品的“生产结果”，提升产品质量；还能规范产品的“生产过程”，形成一套完整的多职能协作流程，提升产品的生产、迭代和维护效率。

从宏观来看，设计体系像是一个“规范的复合体”，它是各职能之间规范的有效整合，产品框架、交互规范、视觉规范、前端规则，同时也是基于整合规范所创造的一套创新的工作模式。

C.「团队能力要求 」

设计体系的建立，需要整个产品团队拥有一致的目标，并为之通力协作才能完成。这就需要整个团队拥有较高的平均素质与契合度。

同时，体系化的建立和推动，也需要团队中有人牵头去推动。设计师作为“产品-开发”的中间环节，是非常有条件成为推动者的角色的。

当然，这就要求设计师拥有更丰富的横向能力。

一方面，设计师需要将自身的能力边界进行拓展，与上下游的职能保持密切的沟通，并解他们的诉求。只有当设计体系满足各方利益时，体系化才有推动的空间。

另一方面，对于产品侧与开发侧人员，设计团队也可以通过培训来提升他们的能力边界。比如针对产品的交互培训、针对开发人员的基础审美培训等。这样才能提升产品的下限与上限，增强产品的综合竞争力。

D.「 构建方向 」

设计体系并非超脱于产品之上，而是根植于产品的成长过程中。

想要推动体系化的建立，必须充分了解产品发展的基本规律。产品处于不同的生命周期，所要解决的问题是不同的。在正确的时间做正确的事情，并对未来的形态进行规划，才能逐步让设计体系根植于产品、融合于产品。

因此，在下一章，我们首先来了解一下B端产品的生命周期。

四、「 剖析 」B端产品的生命周期

–

对于设计师来说，首先要更宏观地了解产品所处的生命阶段，才能知道设计需要解决的问题是什么，并以此有针对性制定不同的设计策略，最终帮助产品构建完善设计体系。

本章更多的是对B端产品的发展阶段做一个剖析，而不同阶段具体的实施策略，会在后面讲解。

「 产品生命周期概述 」

类似于人的成长历程，一个新的B端产品从诞生到逐步扩大，通常都会经历几个不同的生命阶段。

B端产品研发是一个漫长而系统化的过程。这个过程通常伴随着商业业务发展与商业战略模式的不断调整。

B端产品从立项到下线，产品会处于几个典型的不同状态中，这就是产品的生命周期。通常来看，大多数产品都会经历以下几个生命周期。初创期-成长期-成熟期，直至最终进入暮年期。

而产品的商业价值，也会伴随着产品的发展而变化。在通常情况下，伴随着产品的逐渐成长，其商业价值也会随之增长，并在成熟期进入黄金的商业价值期。而当商业价值出现大幅、持续性的降低时，则基本算是进入了暮年期。

那么，不同的生命周期中，产品将会遇到哪些问题？而为了保证产品的持续发展，产品团队又需要做哪些事情呢？

A.「 初创期 」解决核心问题，产生价值

初创期，即产品已经从构思到研发，并成为了初步的产品。这个时期，产品虽然还不能覆盖完整业务，但已经能够顺利运行。

从构思到创意，再到实践落地。B端产品的诞生，通常源于在行业内深耕多年的资深玩家。在不断地实践中，通过创意与实践，找到了一条能够帮助行业解决问题、提升效率的路径。

在这个时期，产品需要解决以下几个问题：

1）用户是谁？

B端业务的本质，就是“向组织销售服务来获得盈利”。哪些企业最需要你的产品？哪一类用户的问题最需要通过这种方式得到解决的？这些都是需要在早期非常明确的。

站在普罗大众的角度去规划产品固然是好的，但成功的产品都始于一小部分早期用户；B端产品的用户通常来自某一垂直领域，首先让他们喜欢上你的产品，然后慢慢向外拓展至更大的人群当中。

想想看，最初一千名喜欢你产品的种子用户可能是哪些人？

2）产品能够解决什么问题？

我们要为用户解决什么问题？“用户的问题”可能是一个需求、一个困扰或是一个机遇。他们的需求是否真的是痛点？

这个时期，团队需要拜访大量的目标用户，通过交流获取痛点。我们必须验证这个需求的真实性，以及我们的解决方案是否具备一定的可实施性。

我们可以通过更具象的UI或流程，初步展示想法，不断优化。最终形成一个可验证的初步产品Demo，并通过Demo进一步与潜在用户进行沟通。

3）这个问题是否普遍？是否具备标准化的可能？

不同企业的需求是有差异的，如何将个性化的需求抽象成共性的解决方案？如何权衡范围与成本之间的关系？我们要将不同企业的需求进行抽象，形成标准化的解决路径。

这个阶段，我们需要为种子用户创建方向聚焦的MVP。MVP必须是名副其实的最小化可行产品，要为种子用户带来端到端的精准体验。如果他们不理解产品功能，不知道如何或为什么使用，或是发现其性能低劣、bug 太多，无法达到“可行”的程度，那么你的假设就难以得到有效验证。

4）是否能够形成完整的商业闭环？

用户是否真的会为这个产品买单？换句话说，产品是否能赚钱并且养活整个团队？

B端产品在初创期，最重要的是快速验证产品与业务的亲密性，能否完成既定的商业战略。产品团队需要通过磨合业务，快速调整业务解决方案和产品架构。

不仅是产品的打磨，整个团队也要形成完整的闭环。工作流程、产品的商业运转机制也要初步跑起来。产品的售前、解决方案、产品研发、实施、客户成功，我们需要真实地完成这一套闭环的操作，并基于此做团队毛利模型的测算。

解决问题，带来价值，并且能够将价值转化为收益，这才是产品可持续发展的关键。只有跑通完整的商业模式，拥有长期的盈利预期，产品才能顺利进入下一个阶段。

B.「 成长期 」能力完善，产品扩张

成长期，即产品形态初具完善，并具备完整商业闭环之后，处于快速成长的时期。这个时期，产品将进行快速的迭代，覆盖的业务一天比一天完整，能满足的业务需求越来越多，而产品为业务带来的价值越来越大。

与新生期的区别在于，新生期时的迭代方向还未完全明确，迭代更多的是尝试，磨合业务与产品。而在成长期时，产品的迭代方向已经是非常清晰了的。

1）更多用户，更多真实需求

产品在真正投入运营之后，所遇到的情况一定与MVP时期有所区别。随着产品的不断售卖，我们将会接触到越来越多的真实用户，以及更多的真实需求。而这些用户与他们的诉求，将会成为产品发展的指引。

2）解决更多问题，业务范围扩张

经过长期的打磨，产品的形态和可用性已经初步成熟了，商业模式也已经初步跑通。随着更多的真实需求，产品将会选择有价值的方向扩张业务范围，从“解决一个问题”逐渐走向“解决一系列问题”。

3）功能完善，产品体量快速增加

伴随产品的快速迭代，产品的基础功能会逐渐完善，同时也会基于核心功能去搭建更为丰富的功能矩阵。更多的能力、产品模块、页面，最终逐渐叠加为一个完整的大型产品。

4）组织逐渐完善，人员专业化

随着业务扩张，组织架构逐渐完善。为了提高专业性与效率，团队人员从“多面手”逐渐转化为专业化方向。与之对应的是，团队成员的数量也会在这个时期快速增加。售前、解决方案、产品研发、实施、客户成功，这一套完整的团队模型在各模块中不断地复制。

C.「 成熟期 」效率提升，快速增长

成熟期，即产品的形态已经稳定，并能够创造持续的商业价值。处于成熟期的产品，肯定是已经进行商业化运行的。反之，没有达到预期的商业价值的产品，不能算成熟期。

进入这个阶段时，产品已经实现了产品-市场匹配。但是，我们需要对整个产品、以及团队进行一系列的调和与优化，才能让整个产品的形态与运作方式更加合理，以便将产品推向更广阔的市场。

1）产品效率、组织效能提升

经过一系列的快速发展，产品体量通常都会比较大，而团队成员也快速扩张。随着一致性成本、沟通成本增加，势必会造成研发效率、组织效能会下降。因此，如何降低产品的单位研发成本？如何让整个团队的组织效能达到最佳状态？是需要解决的问题。特别是当产品具备一定的客户数量以后，单位研发成本的降低将会极大提升产品整体的利润率。

2）产品设计-研发标准化，构建完整链路

通过产品设计-研发标准化、数据架构标准化，打通不同模块的壁垒，提升模块化与灵活性。将单点之间的竞争力相互配合，形成“场域”竞争力。

产品的单点也许不能保证都有最佳的竞争力，但如果我们能够提供一系列的、高质量、无缝衔接的配套服务形成闭环，将会形成强大的整体竞争优势。同时，产品设计-研发标准化，能够增加产品售卖的灵活性，通过灵活的组合方式吸引不同的用户，提升销售灵活性与成单率。

3）提供高质量的用户体验

产品最终是给人用的，用户体验也会在将来逐渐成为B端产品的核心竞争力。随着竞争的加剧，以及用户群体的逐渐年轻化，用户体验将成为企业在选择产品时的重要考量因素，也是口碑传播的重要途径。

由于在“产品-市场匹配”阶段需要尽快地推出产品，所以在设计开发过程中可能遗留诸多问题，需要进一步打磨优化。产品设计需要与开发具备高度的一致性，视觉交互是否合理，前端代码是否准确合理，操作反馈是否高效等问题，都需要这个阶段来进行调和。

4）教育市场，卖给更多的人

当产品逐渐成熟并具备一定体量之后，单靠销售跑单是远远达不到发展要求。这个阶段，需要市场部人员对市场进行教育，聚焦不同的行业领域，从“点式营销”转变为“面式营销”，并配合销售人员进行产品的售卖。因此，在这个阶段，产品的品牌力、核心能力的传播将至关重要。

D.「 暮年期 」商业价值降低，发展逐渐停滞

暮年期，即产品发展停滞甚至倒退，逐渐失去商业价值的产品。

B端产品进入暮年期的原因，主要有两个。一是，伴随着业务的发展，产品已经很难满足业务需求。且翻新产品的投入产出比较低。二是，伴随产品的使用时长，产品将变得臃肿和迟钝，逐渐难以敏捷地满足业务需求。

很多时候，商业环境的快速发展、技术的更新迭代都有可能成为产品进入暮年期的原因。对于暮年期的产品，根据商业战略，产品经理既有可能要延长产品的寿命，也有可能持续保障产品完成顺利换代。当然，更多暮年期的B端产品，由于业务的调整，最终迎来生命的终结。

需要注意的是，很多产品因为在成长期、发展期无法建立有效的产品控制机制，导致产品过早的进入臃肿阶段。也就是前文中所讲的“产品失控”，非常有可能加速产品暮年期的到来。

因此，是否能在前三个阶段建立健康、完善的设计体系，是产品能够获得更长生命力、更多价值的关键。

NEXT

「 下期预告 」设计体系的构建法则

–

你的B端产品处于什么生命周期？在这个阶段产品要解决的问题是什么？而在这些过程中设计体系又应该如何构建？

设计体系的建设并非一蹴而就，通常是伴随着产品的而发展逐步建立的。在下一篇文章中，我们将基于B端产品的发展阶段，带你详细了解设计体系的正确构建方式。

感谢大家的阅读，我们下期再见～

推荐阅读书籍/文章：

《智能商业》—— 曾鸣；《设计体系》—— [英] 阿拉·霍尔马托娃；《深奥的简洁》—— [英] 约翰·格里宾；《机械宇宙》—— [美] 爱德华·多尼克；《万物皆数》—— 米尔埃卡·洛奈；《产品从0到1的4个发展阶段》；《B端产品生命周期》；《复杂》——梅拉尼·米歇尔

作者 | Jady13_剑杰
来源 | 站酷(jady13.zcool.com.cn)

赞助商链接

喜欢这篇文章吗？欢迎分享到你的微博、QQ群，并关注我们的微博，谢谢支持。
版权：除非注明，本站文章均为原创文章，转载请联系我们授权，否则禁止转载。