从电线到积木：腾讯的产业互联网之路

“一个被认为没有B端基因的互联网平台，为何能交出一张很不错的产业互联网答卷？其原因就在于，腾讯在不经意之间，选择了一条模块化的产业互联网道路。”

本文选自《产业互联网的中国路径》一书。

2018腾讯全球合作伙伴大会前夕，腾讯董事会主席兼首席执行官马化腾发表了一封公开信。在公开信中，他提出了一个重要的判断：互联网的上半场已经接近尾声，下半场的序幕正在拉开。而互联网的主战场，正在从消费互联网向产业互联网转移。

马化腾的这一判断一出，就如一石激起千层浪。无论是互联网巨头，还是传统企业，都纷纷表示要积极参与产业互联网，推进互联网与产业的深度融合。一时之间，千帆齐发，百舸争流，好不热闹！

有趣的是，尽管所有人都在提产业互联网，都在做产业互联网，但是关于产业互联网究竟是什么，却一直没有一个共识。至于产业互联网究竟应该怎么做，则更是各有各的说法，各有各的套路。

那么，产业互联网究竟是什么？产业互联网蕴含着哪些机遇，又有哪些挑战？要进一步推进产业互联网的发展，我们需要怎么做？我想，在马化腾的公开信发表两年多后的今天，对于这些根本问题进行反思将是大有必要的。

何谓产业互联网？

从思想渊源上看，“产业互联网”其实有一“土”一“洋”两个源头。

从本土来源看，“产业互联网”一词最早见于我国互联网实践者的一些论述。几年前，国内一些从事B2B电子商务的实践者认识到，通过向上游供货企业提供下游市场的信息和资讯，可以帮助上游企业有效改善生产、提升效率，于是就开始应用互联网的技术践行这一构想。为了将这种通过互联网来沟通、整合上下游信息的2B服务和以消费者为对象的2C服务相结合，他们将此称为“产业互联网”，而把2C的服务称为“消费互联网”。

从国外的来源看，“产业互联网”一词则来自于“Industrial Internet”（以下简称IE）的翻译。

2000年，硅谷的沙利文（Frost&Sullivan）咨询公司发布了一份报告，在报告中，提出了IE的概念，并将其定义为“复杂物理机器和网络化传感器及软件的集成”。在当时，这个概念并没有流行。直到2012年，通用电气发布了报告《Industrial　Internet：Pushing　the　Boundaries　of　Minds　and　Machines》，全面论述了IE在未来经济生活中的可能应用场景，IE的概念才开始为人们所重视。

由于通用电气是一家著名的工业企业，因此我国在引入IE概念时，就自然地将其翻译为了“工业互联网”。后来，这个概念又和从德国引进的“工业4.0”相融合，逐步进入到了各种政府报告和学术文献中。

不过，如果我们重新读一下通用的报告，就会发现其讨论的领域不仅包括工业，还包括航空管理、医疗等。由此可见，至少从通用电气的本意看，IE不仅仅局限于工业范围，还涉及到更为广义的产业。

尽管“土”、“洋”两个源头的产业互联网提出背景有很大差异，侧重的方面也是各不相同，但其实它们之间却存在着一种共识，那就是试图通过互联网的技术来改造产业。

如果我们抽取这一共同点，那么或许可以将产业互联网定义为：

应用互联网的技术来连接、重构产业，从而让产业效率得到提升的实践活动。

在这一概念之下，“土”“洋”两种产业互联网的传统都可以被统摄在内。只不过，本土的产业互联网概念强调的是借助互联网技术，通过连接来帮助产业中的企业更好地进行规划，而外来的产业互联网概念则强调应用互联网技术来实现对生产流程的改造。

与我们所熟悉的“消费互联网”相比，“产业互联网”蕴含的商业潜力是巨大的。消费互联网的连接对象主要是人与PC、手机等终端，其连接数量大约为35亿个，而产业互联网连接的对象则包括人、设备、软件、工厂、产品，以及各类要素，其潜在的连接数量可能达到数百亿。

从App的数量上看，整个消费互联网现有的App不到千万，而仅在工业领域，产业互联网需要的App数就约为6000万。在互联网的流量红利已经见顶，消费互联网市场已经越来越“红海”化的今天，产业互联网这片“蓝海”显得尤其诱人。

产业互联网的现有路径和推进困难

在现有的实践当中，产业互联网的建设主要有三种流行路径。

第一种流行的路径是本土互联网实践者所宣称的“产业互联网”。

这种路径强调的主要还是提供连接服务，通过打通上下游信息来辅助生产端的决策，应用的依然是互联网最基本的连接技术。

第二种路径是传统企业的互联网化，将在某一个具体企业中应用良好的技术和经验推广到行业范围。采用这一路径的代表企业是通用电气。

通用电气利用其在长期产业实践中积累的技术和经验，建立了著名的Predix平台，建成了“边缘+平台+应用”的完整架构，为很多工业企业提供相关服务。在Predix的发展达到鼎盛时，整个工业互联网的圈子都言必称Predix，而做工业平台的企业则更是纷纷以Predix作为榜样，向Predix对标。这种路径的“产业互联网”是现在最为常见的。国内外出现的很多产业平台，采用的都是这种路径。

第三种路径则是互联网企业的产业化，将互联网领域发展出的技术、流程应用到具体的行业。

谷歌就是采用这一路径的代表。近几年，谷歌收购了多家机器人企业，将其本身拥有的海量技术与物理世界充分结合，将业务逐步从虚拟的互联网领域拓展到了生活的各个领域。目前，谷歌的产品已经包括了工业机器人、仿真机器人、特种机器人和无人车等众多工业产品。

目前，三种实践路径都取得了一定的成就，但在推进过程中也存在着很多的困难。

先看第一种路径。个人认为，这种路径的前景并不十分光明。

对于企业来讲，连接和信息服务确实很有价值，但在信息高度发达的今天，企业已经可以用很低的成本获得这些服务，而无需诉诸专门的中介平台。企业现在真正需要的，是在连接之外的附加价值，而这一切，是纯做信息服务的平台无法提供的。

这里需要强调一点，就是面向C端的连接和做B端的连接其实有很大的不同。一般来说，C端的交易单笔数额较小，而交易的频次则比较频繁，这就决定了用户自己去自建交易过程中的基础设施是不合算的。基于这一原因，面向C端的平台可以很容易从信息服务做起，然后将业务迅速扩展到支付、物流等领域。

而面向B端的服务则不同，企业之间的业务合作一旦建立，很可能是长期的、大额的。出于交易安全的考虑，它们更倾向于自己解决支付、物流等问题，而不让平台插手。因此，如果简单地按照“消费互联网”的逻辑来做“产业互联网”，平台就很难成功。

再看第二种路径。相比于第一种路径来说，这种路径已经从单纯的外部信息提供转入了内部流程的再造，这在一定程度上击中了企业的某些痛点。从对生产效率的促进来讲，这种路径所产生的影响也可圈可点。不过，如果我们从经济角度上来重新审视这一路径，就会发现它并不算成功。现在市场上有很多产业平台，都是为企业提供数字化转型服务的，但大多数做得并不成功。即使是口碑良好的Predix，也没有能够实现盈利。

为什么会出现这样的情况呢？其中最重要的一个原因，就是这种路径下的努力很难被简单复制，因此成本不容易压下来。我们知道，企业是具有很强的异质性的，即使在同一个产业的内部，不同企业的情况也会千差万别。因此，即使某套产业互联网的解决方案在一个企业取得了成功，它也很难简单推广到其他企业。在这种情况下，提供产业互联网服务的平台就很难有效发挥规模优势，这就使得成本居高不下，盈利难以实现。

最后看第三条路径。这种路径的实践固然取得了很好的成绩，但从根本上看，它依然局限于某些大型互联网企业内部，其成功经验很难推广，也很难惠及广大的传统企业。因此，其对社会产生的综合效益并不显著。

通过以上分析，我们知道，现有的三种产业互联网实施路径，虽然各自取得了一些成绩，但是在实践当中也遭遇了很大的阻碍。这些阻碍，我们主要是从供给面去看的。那么，如果从需求面看，产业互联网推进中遭遇的困难又有哪些呢？我对一些企业走访后发现，现在的问题主要有以下几个：

首先，拥抱产业互联网、推行数字化转型的成本较高，企业难以承受。

数字化转型的成本不仅包括购买和使用技术的成本，还包括对组织、流程、商业模式进行重构的成本。所有这些成本加在一起，往往不是个小数目，很多企业，尤其是中小企业往往难以负担。

其次，市场的需求通常是不确定的，通过产业互联网来优化内部生产流程的结果往往不能适应需求变化的需要。

我走访过一些传统企业，这些企业的负责人告诉我，通过产业互联网优化内部生产流程确实可以提升效率，但如果企业效率上去了，产量增加了，需求却出现了波动，那么企业就不仅不能从效率改进中收益，还将面临产能闲置的问题。转型一开启，固定成本就投下去了，要再调整很难。相比之下，如果不进行数字化，企业倒可以更为自如地调整可变成本（例如雇员），来应对需求的波动。

再次，企业要进行产业互联网转型，就需要向数字化服务的提供者开放一定的数据，很多企业担心在这个过程中可能会造成企业信息的泄露。

最后，现在数字技术的进步日新月异，很多技术出现后不久就被新技术替代了，不少企业担心在数字化之后，自己的企业根据某种技术进行了全面调整，反而会将自己固定在这一技术水平之上，难以对更新的技术进行回应。

在上述几个因素的共同作用之下，很多企业虽然也认识到了拥抱产业互联网、推进企业的数字化转型从长远看对本企业有莫大的好处，但却在实践当中踯躅不前。

模块化：产业互联网的一种解决方案

通过总结现有产业互联网各种发展模式所面临的困难，以及企业不愿意接受产业互联网的原因，我们可以认为，一个产业互联网的解决方案要获得成功，至少需要满足如这样几个要求：

• 第一，这种解决方案在提供单纯的连接之外，应该可以对企业内部的流程进行塑造，帮助生产端实现对效率的改进；

• 第二，这种解决方案应该考虑到企业的异质性，适应企业的具体需求；

• 第三，这种解决方案应该在成本上相对低廉。尤其是固定成本不能过高，因为这会严重妨碍企业选用方案的积极性；

• 第四，这种解决方案应该能够确保企业的数据安全，尽可能少地要求企业提供关键数据；

• 第五，这种解决方案应该具有良好的扩展性，在新技术出现时，允许企业进行技术升级；

• 第六，这种解决方案应该能让产业互联网服务商的规模优势得到发挥。

有没有一种方案才能同时满足如上这六个要求呢？在我看来，答案是肯定的。这种方案就是“模块化”。

“模块化”一词最早出自工程设计领域。1997年，哈佛大学商学院的两位教授鲍德温（Carliss Baldwin）和克拉克（Kim Clark）在《哈佛商业评论》上发表了一篇题为《模块化时代的管理》的论文，从而将“模块化”的概念引入了管理学界。

根据鲍德温和克拉克的定义，所谓“模块化”，就是一个将复杂系统分解成相对简单、具有独立功能、能够独立运行的子系统的过程。这里所指的复杂系统被称为“模块化系统”，它可以是一件产品，也可以是一个过程。通过“模块化”，它可以被分解成若干个部分，这些部分就是“模块”。这些模块都是被独立设计的，但它们可以通过某些规则联系起来，共同发挥系统的整体功能。

与整体化的设计和制作相比，“模块化”有很多鲜明的特点。

第一，它可以让各个模块独立设计，从而最大程度节约所需要的信息。

在固定的标准下，各模块自身的融资、设计、生产等全部可以在模块内部进行。这样，相关人员所需要的知识就可以被压缩到最低限度，从而做到“有价值的无知”（Valuable ignorance）。

第二，它可以提供足够的空间和激励来大幅度促进创新。

由于所有模块都能够独立设计，因此创新就可以在模块的层面进行，而无需有“牵一发动全身”的顾虑。与此同时，模块的独立设计性也让各模块产生了竞争压力。所有模块都必须不断创新，才能保证不被系统外的其他模块替换掉。在这种竞争的压力之下，系统的效率会获得提升。

第三，它可以大幅提升系统的应变能力，从而更能够适应市场变化。

“模块化”对系统的不确定性有很强的适应能力。通过添加、拆分、整合、转化等“模块化的操作”，系统可以灵活应对各种变化。当某一模块失去了价值，可以很容易地通过删除、更新等操作，让系统迅速恢复有效性和最佳状态。而当市场形势变化时，则可以通过合并模块、拆分模块等手段，使整个生产链迅速符合市场的要求。

第四，它有利于引入新型的竞争与合作，让整个市场更为有效地运行。

在共同标准下，上级模块可以选择不同的下级模块，这使得竞争性在模块化的组织结构中表现得很明显。模块化环境下的竞争比传统环境下要激烈，因为企业只有不断进行研发和创新，才能保证不被其他模块所淘汰。

此外，“模块化”安排也为拥有新技术的小企业带来了更多与大企业合作的机会。由新技术催生的新型企业很容易与上层的模块达成合作，使之融入上层的模块，成为它的子模块。在这种安排下，大企业和小企业之间的优势可以得到良好的互补，从而产生较为理想的合作成果。

“模块化”的上述特点意味着如果采用模块化的思路来做产业互联网，就有可能很好地解决现有的各种方案所遭遇的问题。

首先，产业互联网组件很多，通过不同的模块，服务商就可以有效地提供除了连接之外的各种服务；

其次，根据企业具体诉求的不同，产业互联网服务商可以提供不同的模块，供企业自己进行组合，从而让解决方案变得更有针对性。

第三，在模块化的设计下，企业无需选择全套的产业互联网解决方案，而是可以根据自身需求来挑选模块，这样就降低了成本，尤其是固定成本。

第四，在模块化之下，服务提供商只需要根据企业的诉求提供相应模块，对于数据的要求很少。即使在涉及某些业务，必须要企业提供数据时，其需要的也只是局部的涉及特定模块的数据，而不用整体的数据。这就在很大程度上保证了企业数据的安全。

第五，由于模块化利于应变、利于合作，采用模块化思路的产业互联网方案将具有更好的扩展性。当有新技术产生时，企业无需进行整体的变更，只需要更换相应模块就可以实现升级。

第六，在模块化的解决方案之下，产业互联网服务商所提供的将不是全套的、个性化十足的服务，而是分散的、同质化的模块产品。在这种同质化产品的提供过程中，服务商将很容易实现规模效应，可以通过服务的不断积累来让成本不断下降，利润不断增加。

产业互联网的设计规则

如果我们把互联网企业的传统连接业务比作提供电线，那为企业用户提供模块化的数字化解决方案就可以比作是售卖积木。事实上，在模块化构造下，每一个具体的功能模块就相当于是一块积木，它们的组合，构成了对于具体业务的解决方案。

熟悉积木的朋友都知道，一套积木要成功，就必须对其组合的规则进行精心的设计。积木应该有几种形状，积木与积木之间的插槽如何设计，这些都很重要。同样的，一个成功的模块化设计，也需要有很好的设计规则作为保证。

模块化的设计涉及到两类设计者。一类是架构设计者，他们的任务是制定相应规则，明确模块之间怎么进行互动、怎么进行连接；另一类则是模块的设计者，他们的任务是推进具体模块的设计，让其性能、效率得到不断的改进。与角色相对应，两类设计者需要制定两种不同的规则。

架构设计者需要制定的是“可见的设计规则”。这类规则包括结构、界面和标准。其中，“结构”规定哪些模块是系统所需要的，它们如何发挥作用；“界面”规定模块之间如何互动、如何进行信息交互；“标准”则被用来检验系统中的模块是否适合系统的需要，是否能保证系统功能的发挥。无论是“结构”“界面”还是“标准”，都是进行后续设计时需要参考的，因此最好预先设定好。

模块设计者制定的是“隐形的设计规则”。这种设计规则仅限于一个模块之内，对其他模块的设计没有影响。它们可以被代替或在事后重新选择，在设计时也没有必要与本模块的其他人员沟通。

在现实中，不同类型的企业所扮演的设计角色是不同的。一般来说，那些业务涉及更多领域，或者更多流程的企业担当架构设计者，设计所有模块都应该遵守的“可见的设计规则”；而专注于某个特定业务的企业，则更适合充当模块设计者，设计“隐形的设计规则”。

以上逻辑同样适用于产业互联网的建设。互联网企业原本的业务主要是对不同主体进行连接，它们所涉及的业务领域是更为宽广的，而其拥有的技术也主要是那些适用于多个领域的“通用目的技术”（General Purpose Technologies），这些特点决定了其更适合架构设计者的角色，专门设计“可见的设计规则”。

相比之下，具体产业中的企业则更专注于某个具体工序或流程，拥有的也更多是“专用目的技术”（Specific Purpose Technologies），这些特点决定了它们更适合作为模块设计者，专门设计“隐藏的设计规则”。

与设计职能相对应的，互联网企业应该花费更多的资源和精力，对产业互联网的基础设施进行建设，而具体行业中的企业，则应该将力量更多投放到对本模块相关技术和工艺的开发中。

需要说明的是，在架构设计者与模块设计者之间进行合理的分工是十分必要的。究竟哪些设计规则、设施的建设应该由架构设计者做，哪些又应该交给模块设计者，这需要通过成本-收益分析来决定。

总体来说，由架构决定的设计规则会更有约束力量，更能发挥模块之间的合力，但却可能对模块的独立演化造成限制，从而阻碍系统的演化；而由模块决定的设计规则因为对本模块之外的部分没有吸引力，比较难以调动系统整体的合力，但却更适应本模块的发展状况，更有助于促进本模块的独立演进。

蒂瓦纳（Amrit Tiwana）曾提出了如下五个原则，来指导架构与模块之间的分权：

• 原则一，可重复性较高的功能应该进入架构设计，可重复较低的功能应该留给模块设计；

• 原则二，通用规模应该进入架构设计，专用功能应该留给模块设计；

• 原则三，所有的接口都应该进入架构设计，架构设计者应该明确规定各模块之间进行合作对接的标准；

• 原则四，稳定的功能应该进入架构设计，不稳定的功能应该留给模块设计；

• 原则五，确定性高的功能应该进入架构设计，不确定性高的功能应该留给模块设计。

在进行产业互联网的建设时，这几个原则是很有启发性的。总体来讲，由于每个行业的性质各异，其本身的变动又都十分迅速，所以作为架构设计者的互联网企业不应该将“可见的设计规则”定得过多、过细，而应该把更多的发展空间留给作为模块的各行业企业。

它们也不宜放弃自身比较优势，过度介入每个行业本身，而应该将更多精力放在为各行业提供通用的基础设施和工具。与此同时，各行业的企业可以在互联网企业提供的总体架构之下，利用其创造的基础设施，根据本行业特征，积极推进行业技术的变革。

以零售业为例。在通常的认知中，零售业作为一个古老的行业，其业态和商业模式是比较固定的。但这其实是一种误解，零售的多样性其实远比人们想象的大得多。科特勒在其经典教科书《零售管理》中曾经对零售下过一个定义：

“将商品或服务直接销售给最终消费者供其个人进行非商业性使用的过程中涉及到的一切活动”。

根据这一定义，零售的形式是十分多变的。商品或服务从提供者手中到达消费者手中的路径可以是非常多样的，每一种路径都可以选择不同的环节。

例如，有的零售商提供送货，另一些零售商则不提供；有的零售商承诺提供售后服务，另一些零售商则不作如此承诺。在每一个具体环节上，不同企业也常选择不同的服务形式。

以销售环节为例，有的零售商选择专卖店的形式，只销售较少的商品品类，其目的是为了发挥销售过程中的“规模经济”；而另一些零售商则会选择百货店的形式，同时销售大量的商品品类，从而让销售过程中的“范围经济”得以发挥。不同的环节选择，加上统一环节的不同服务形式，决定了零售业尽管古老，但却极富多样性。

现实中，零售商选择提供哪些环节服务、不提供哪些环节的服务，在某个具体环节提供哪种形式的服务，都是要根据具体的情况进行具体分析的，其变化十分复杂，这一特征决定了很难用一个完整的模式来解决所有零售商的问题。因此，在对零售业进行产业互联网化的改造时，采用“模块化”的思路就是更为合适的。

目前，国内的几大互联网巨头都提出了不同的零售改革方案。阿里巴巴的方案是“新零售”、腾讯的方案是“智慧零售”、京东的方案是“无界零售”。尽管这些方案之间存在着很多差异，但从本质上看，它们都是在用“模块化”改造传统的零售业，其做法都是由互联网企业给出一个基本架构，提供一些基础服务，然后再让零售企业在此基础上进行个性化的发挥。不同之处只在于具体的架构及架构和模块之间的设计规则及分工。

我们以腾讯的“智慧零售”为例来说明零售业的产业互联网化是如何通过模块化来实现的。

由于腾讯在零售方面的经验相对较少，因此它并不过多介入行业，而是选择了一种工具或助手的角色。换言之，作为一个架构设计者，它选择在架构中保留了较少的功能，让“看得见的设计规则”尽可能简单，而将更多的设计规则留给了具体的零售商。

在进行架构设计时，腾讯提供了很多实用的工具，包括腾讯云、小程序、公众号、移动支付、社交广告、泛娱乐IP等，这些工具在很多场景下都可以使用。零售商可以在售前、售中、售后等各个环节，通过腾讯给出的接口，调用这些工具。

当然，究竟在什么环节使用工具、使用哪些工具，这些都是由零售商决定的“隐藏的设计规则”，不同的零售商可以根据自身的需要和具体的环境进行相应的选择。

图1：智慧零售的模块化示意

事实上，根据相同的架构和工具，不同的零售商玩出了完全不同的花样。

例如，一些零售商利用腾讯提供的开发平台，开发出了用来获客的小程序，从而大幅增加了客流量；一些零售商则利用腾讯云和小程序，记录并分析了交易过程中的有效数据，并在此基础上对整个销售流程进行了改造；而另一些零售商则借助腾讯云提供的人工智能服务，对自身的地理位置进行了重新的选择……

总而言之，在既定的架构规则之下，这些模块都实现了迅速的创新和演化，而这也大大增加了整个零售生态的活力。

从电线到积木：腾讯的产业互联网之路

除了零售，在过去一年多里，腾讯在医疗、交通、政务、文旅等多个领域都取得了很大的成就，在制造业、农业等领域，也在积极推进。

对于腾讯向产业互联网转型，最初很多人是抱着质疑态度的，他们认为，腾讯一直是做C端业务的，完全没有B端的基因，因此不可能做好产业互联网。乍听之下，似乎很有道理——深耕C端，因此既难以像阿里巴巴那样通过掌握商家的供需来了解产业痛点，更难以像具体产业中的企业那样了解具体的业务流程，这样的一个企业，凭什么可以做B端，做产业互联网呢？

但正所谓事实胜于雄辩。经过一年多的努力，腾讯交出了一张很不错的答卷。那么，一个被认为没有B端基因的互联网平台，究竟是如何做到了这一点呢？其原因就在于，腾讯在不经意之间，选择了一条模块化的产业互联网道路。

很多服务提供商一说到产业互联网，就会讲要提供整体的解决方案。但这样一来，就难免会遭遇我们前面说到过的种种困难。与这些服务提供商不同，腾讯明确地提出了不深入产业，只做工具、做助手。

这是什么意思呢？用模块化的语言讲，就是只提供通用性的架构和模块，而把利用、组合模块的选择权留给具体的产业使用者。

由于拥有强大的C端基因，因此腾讯提供的架构和模块都颇能抓住消费者的应用痛点。通过这些架构和工具，具体产业的从业者就可以根据产业的具体特征，很容易搭建起属于自己的解决方案。前述零售业如此，车联网行业也如此。

所谓车联网，通俗来说就是车辆的物联网。它以行驶中的车辆为信息感知对象，借助新一代信息通信技术，实现车与云平台、车与车、车与路、车与人、车内等全方位，从而达到提升车辆整体的智能驾驶水平，提升用户驾车体验，以及提升交通运行效率等目的。 

目前，车联网还处于发展的早期，整个行业发展面临着很多问题：首先，与移动互联网相比，车上内容、服务依然匮乏，大量的需求场景亟待开发；其次，现有的互联网生态很难简单“搬上车”， 移动互联网的应用很少能满足用车场景的需求。再次，目前的车联网应用场景碎片化，车上、车下无法获得一致、连贯的使用体验。

针对这些问题，很多大型互联网企业都给出了自己的解决方案。其中，一些互联网企业选择自己造车，利用自身在人工智能方面的优势直接与车企竞争；而另一些互联网企业则致力于开发封闭式的整体解决方案，将其出售给车企。

相比于这些方案，腾讯给出的方案要“轻”得多。它既不碰硬件，也不碰操作系统，而是在上层打造车的场景和体验，为车企提供模块化的工具组件，帮助它们实现与互联网生态的对接。

首先，腾讯车联推出了场景引擎。基于超级ID、AI、大数据和LBS能力，场景引擎可以十分便捷地实现用户兴趣、车端场景和服务应用的智能匹配，通过场景感知进行个性化服务的主动推送。

其次，腾讯车联提供超级ID与微信支付能力，让车企可以接入丰富的移动互联网服务，从而打通手机-车机-智能设备等多个终端，实现服务的“全时在线”。通过这种打通，用户手机、车机上收藏的歌单可以实现同步，用户也就可以续听早上在家听的电台节目，更可以在车上用车载语音助手订一杯咖啡，下车后与咖啡同步抵达办公室。

再次，腾讯车联在“生态车联网解决方案”中，推出了一套跨OS的、云端轻量化的开发者应用框架——腾讯小场景。小场景无需下载和安装，可以在云端进行更新上线，实现基于语音和场景的“主动唤醒”。有小程序基础，开发者只需简单改造即可发布成为腾讯小场景，同时支持腾讯丰富内外部生态资源接入。

利用以上这些工具，车企就可以根据自身的实际，轻松设计适合自身的车联网方案。与自行研发汽车的方案相比，腾讯的车联网解决方案的“侵入性”显然要小很多——它是与车企合作，而不是和车企竞争；与提供封闭式整体方案的做法相比，这种模块化的方案则有利于车企自由选择、搭配车联网方案，同时也有助于降低车企的成本。

从这个意义上讲，这种方案在推进车联网的发展，实现与传统车企的共荣上，可能是最为有利的。