专访小米新生态总监董红光：小米快应用也是小米生态的快应用，它事关「人的交互」
2017 年 1 月，微信正式发布了小程序，几个月后，小米在 MIUI 8.5 中推出了「直达服务」，和小程序类似，直达服务无需下载，即点即用。2018 年 3 月，小米、华为、OPPO、vivo 等 10 大手机厂商共同成立了快应用联盟，并统一了免安装应用的技术框架，小米的直达服务也成了小米快应用。
小米新生态总监董红光在 2010 年加入小米，从最初负责主题商店，到 MIUI 系统框架工作，再到全面负责快应用，他经历了小米的互联网服务崛起的全过程，以及在移动互联网下半场的新形势下，从应用分发到服务分发的转变。
11 月 20 日的 2019 MIDC 小米开发者大会上，小米宣布快应用将跨越手机，进入电视、音箱、手表等智能设备和 AIoT 领域，满足用户更复杂和多场景的需求。
最近，知晓程序独家专访了小米新生态总监董红光，他完整阐述了小米快应用的发展历程，快应用要解决的问题，快应用和 AIoT 设备结合的原因及未来等问题，也正面回答了和微信小程序的竞争与合作，我们也得以更全面、正确地看待小米快应用。
以下是对话实录，知晓程序做了不改变原意的编辑。
知晓程序：您在小米的经历是怎样的？
董红光：我是 2010 年加入小米的，最初加入负责主题商店，因为当时 Android 还没有主题相关的能力。后来也一直在 MIUI 这边，做了一些 MIUI 系统底层和应用框架的事情。在 2016 年开始孵化快应用的业务，当时内部还叫直达服务。
知晓程序：为什么当时决定孵化这样的产品？
董红光：主要还是基于用户有这样的需求。
2016 年底我们算是正式孵化，但之前很早就有这样的想法，最早可以追溯到 2014 年，但考虑当时时机还未成熟，app 还有一定空间。对用户而言，还有需求并未满足，这是一个「有和无」的阶段，同时对开发者来说，他的获客成本就不高，可以轻松通过产品的能力，获取用户。
到了 2016 年，用户绝大多数需求已经有足够多的 app 来满足了，这就不是有和无的关系了，用户接下来会追求更方便地去使用这个时候就涉及很多层面的东西：比如用户希望应用即点即用，或者希望通过场景化的方式来用。我随便举一个例子，比如天气，它告诉你今天天气很糟糕，下面可能就有一个相应的打车按钮，我可以直接打车回家。如果是 app 的话，服务都是隔开的，用户需要回到桌面去点，整个路径是比较深的，如果他没装 app，就更糟糕了。
用户此时面对的是从有到优的过程，这需要类似于快应用这样的方案来解决。快应用的技术特征：一是免安装，二是服务直达，就是说能够直接到具体的一个落地页面，快应用还包含一些卡片化的能力，可以把内部的内容外展出来。
从开发者的层面来说，他们的流量成本越来越高，然后是用户质量，他从优质的渠道获得的用户已经相对饱和了，但是到一些其他的渠道去获得用户的转化都不是很好。
我们看数据发现，有很大一部分用户下了一个 app，从来没打开。这意味着用户下载安装完了的时候，场景已经没有了，我已经不记得有这样的一个需求了。
现在，用户能够直接去消费了，比如快游戏，当开发者在信息流里投放的时候，用户看到就可以直接点进去玩了。对开发者而言，折损率就低很多，同时它的转化率也高很多，因为用户是在这个场景内部延续他的动作。这个时候做一些精准化的投放，或者在一些精准场景和渠道合作，效果就会好很多。
这是我理解的两个层面的痛点，加上行业的时机，我们决定在 2016 年正式做这件事。
知晓程序：一开始找了哪些开发者，大家的反应如何？
董红光：直达服务是在 MIUI 的 8.5 版本推出。正式推出前合作了 10 个左右的开发者，包括饿了么、豆瓣、快看漫画等。上线后数据还行，当然我们的出发点并不是为了做生态而做生态，更多的是看能用这样的技术解决用户和开发者的什么需求。你看到虽然我们这个事情推得比较早，但是真正地去对外大范围的宣传，其实是快应用联盟成立之后。
当然，一开始用户规模肯定是不够的，但它的整体转化率在同样渠道下比 app 是高很多的。我印象中一个快应用，跟 app 相比，转化率有 70% 的提升。
知晓程序：最初是把应用商店作为主入口吗？
董红光：不是的，一开始立项的时候，我们也不觉得应用商店是我们的核心入口，原因就是它是偏中心化的分发，而不是场景化的分发。
用户来到应用商店，就是为了下载 app，甚至会有足够的预期说我先下载，等过段时间再用，这个时候快应用的优势是得不到体现的，快应用真正要解决的问题是场景化的问题，比如我看到一条航班信息的短信，能不能直接做后续的改签等操作。
我们最初的最重要的一个入口是网页跳转，在小米浏览器和其他地方都可用，我们做了一套系统的能力给到开发者，由他们决定当用户打开 URL 时跳转到哪里。相比 H5 页面，它解决了账号能力缺失、性能体验不好、没有支付能力、留存等问题。
除此之外，我们还做了很多场景入口，比如负一屏，全局搜索和浏览器搜索，小爱智能助手， AI 按键，我们刚提到的短信，还有一些小的，比如卸载一个原生应用的时候，会提醒他要不要切换到一个快应用版本。
从这些入口你应该大概也能看出，我们其实是覆盖了各种各样的场景，从你获取一个服务开始，到你从一个服务走的时候，我们在整个链路中都是有可能触达到相应的快应用的。
知晓程序：我很好奇应用商店的同事对你们的态度是怎样的？他们会觉得你做这个影响到应用商店吗？
董红光：其实还好。两个层面，第一个层面是文化，小米整个公司的内部氛围而言，大家还是会站在相对高的角度来看问题，你看应用商店和我们并不是一个团队的，但他们直接给了我们相应的入口，比如商店搜索之后上面是「安装」，下面就是「秒开」，这两个按钮是挨着的，大小也一样，并不会刻意弱化快应用。
第二个层面，它对应用商店也没有多大的影响，本质上，快应用解决的是在多场景下直接把服务给到用户这个需求，这是应用商店解决不了的问题。从数据层面上来说，影响也不大。
知晓程序：你们有提到「原子服务」这个概念，该如何理解？
董红光：其实我们内部还是叫「服务直达」和「内容前置」这两个概念。
服务直达是说无需安装，我能直接打开一个对应的服务页面；内容前置是指卡片化，我甚至可以不用点它，一些关键信息已经在这里呈现出来了。它不只是展现出来，还有一些简单的交互能力。这两个加起来就是所谓的「原子化服务」，这个能力本质上是让快应用和和场景的结合更紧密，这是 app 没有的。
App 是一个个信息孤岛，快应用的这两个能力相当于在岛之间建了无数的桥，用户可以在 A 快应用里看到 B 的相应消息，也可以一点就跳到 B。比如用户的航班信息，可能涉及到多个应用，但在快应用中只要一个卡片即可承载，并且可在负一屏中插入服务。
知晓程序：在我的小米手机上，我发现负一屏改成了「动态」的样式，过去它是固定的卡片，现在它会主动推荐一些服务。
董红光：这是我们正在改版的一个版本。过去的卡片需要用户设置，对用户来说划过来永远都是一样的，它是一个工具属性很强的东西，而现在我们把负一屏定位成智能助理。
什么是智能助理？在恰当的时候告诉你，接下来要做什么，或者给你展示你即将要看到的信息，这就意味着这个东西必须要动起来，才有可能把最关键的信息放到最前面去。
对于推荐，本质上我们要做的是识别场景，之后根据这个场景来推荐服务。这个服务推荐如果是基于用户安装的 app 是不够的，因为它毕竟是有限的，比如在坐飞机的场景下，如果用户没有安装地图或者值机类的 app，这个时候就没法快速顺畅搞定了。但快应用不同，它是免安装的，过去的推荐范围是你手机里安装了哪些应用，现在我们可以把全网的服务推荐给你。
知晓程序：很早的时候手机的发展方向之一就是变得越来越懂你，所以打通快应用之后，这个才更有可能？
董红光：对。本质上还是需要你了解他更多，才能更加懂他，以前 app 的方式，大家都是一个个孤岛，互相之间没有任何联动和打通。
知晓程序：小米曾说 2019 的目标是上线 10000 – 10 万个快应用，目前这个目标实现了吗？
董红光：我们没有订过这样的目标，我们从立项的第一天开始就不会把应用数量作为核心的考核指标。我们看得更多的是入口侧数据的提升，以及对每个开发者自身的转化率的提升。
知晓程序：快应用目前有哪些标杆应用？Top 10 的快应用是哪些？
董红光：标杆跟 Top 我觉得还是不一样。标杆是说他的玩法比较透，Top 说的更多的是量，我们更关心的是标杆。
菜鸟裹裹是一个典型的标杆，它在负一屏上处理一些快递信息，会露出一张卡片，直接显示给用户，它的整个数据表现也是比较好的。还有航班管家、高铁管家，你不一定会专门去下这样一个 app，但是在这种场景触发下，它可以直接拉起它的快应用，然后用户不仅查看信息，它背后还可以做到内容带服务，比如在航班信息下面，他还可以预约打车、购买航空保险等。
还有一些商业流量下玩得比较好的，比如连尚免费读书，它是免费小说加广告的模式；还有一些其他场景的标杆，比如携程，在我提到的短信上做了一些事情；还有小爱同学，去哪儿接入了，比如用户可以直接定一张「明天去上海的火车票」；还有比如内容电商，在浏览器的信息流里，内容可以直接带货，内容电商目前的标杆是唯品会。
知晓程序：所以从商业模式来说，快应用和应用商店是不一样的？应用商店更多是分发应用，然后收广告和推广费用；快应用，则是直接提供服务，然后从达成交易中获取佣金？
董红光：我们现在还没有规划快应用的商业模式，这件事为时尚早。
当然商业模式是两件事情，一个是我们的商业模式，一个是开发者的商业模式，对我们来说，至少现在还没有明确的规划。如果在什么阶段做什么样的事情，可以做个类比，Android 生态是大概 4 年后，也就是 2014 年才有一个比较良性的商业模式。
另外从小米角度来说，我们并不会把在生态中赚钱作为第一要务，而是应该首先解决用户侧的需求，同时让开发者在生态中获益，让他哪怕给你钱也是心甘情愿的。比如你帮他降低了成本，他是愿意把降低的这部分成本拿出一部分给你的。
第二点是开发者侧的商业模式，这其实是我们一直在做的，我们也希望帮他们解决获得用户后，怎么变现的问题。这里面交易类的可能比较简单，就是交易达成；但对非交易类来说，就需要类似于广告这样的模式。大的开发者他自己就能解决，但很多中小开发者就需要我们来提供一些能力，比如广告和数据能力的支持等。
知晓程序：小米快应用和 AIoT 的结合是什么时候有的计划？
董红光：立项很早。我们在做的过程中，兄弟部门已经找我们聊过说智能设备上更需要这样的东西。
第一个原因是用户侧的需求，用户在智能音箱上不能说「请帮我打开一个 XXX 应用」，然后进入 app，由它来接管你的需求吧？这样的体验是不顺畅的，这种情况必须是直接面对需求，直接分发服务的。
第二，对开发者来说，我不能为了每个端都开发一次产品，这就很复杂，比如电视上用 A 技术，手表上用 B 技术，音箱上用 C 技术，成本就很高。
第三，智能设备相对手机来说性能还是差一些，这个时候 app 的负担还是过重。我们希望一个偏轻量化的通用方案来做这件事情，快应用就比较适合，它本身就是基于原生渲染的一套方案，它可以跑在很低端的这种设备上去但同时它还可以做一些偏复杂的交互。
另外，AIoT 设备本身也需要一些额外的能力，比如在电视上点外卖，你直接用语音交互，不需要遥控器；我们刚发布的小爱同学 3.0，已经有了多轮对话的能力，可以和用户有持续的交互。这就是多模态的交互。
原来设备和设备之间没法直接打通，更多的是和手机端的打通，但现在设备和设备之间连接起来，快应用就可以做更多的事情。比如 K 歌场景中，手表可以控制歌曲切换，外卖场景中又能通过手表完成支付。
知晓程序：接下来快应用会进入哪些智能设备和场景中？
董红光：这个事情并不是小米自己在做，它更多的是联动开发者一起做。具体到场景的话，我们要不断尝试，看用户需求在哪里。从设备角度，几个核心的设备可能是要支持的，比如电视、音箱、手表的联动。另外，比如外卖场景里和门铃的联动，K 歌的氛围灯的联动等基于场景下的需要联动设备的能力，我们会逐步提供给开发者。
你可以这样理解，当用户需要一些复杂的东西，而不是简单的纯语音、纯设备的交互时——比如说某个传感器感受到什么东西，就控制另一个设备做什么就涉及到大量的人的交互，它一定就会是多模态的，可能涉及语音、图形化界面、视觉、人脸识别等交互。
这个时候就需要一个上层的框架来支撑，快应用就是这样的框架。
知晓程序：公司会为快应用定 KPI 吗？
董红光：公司是不会给大家下 KPI 的，这是小米的特点，但是会有一些目标，我们更关心你的路径本身是不是一个正确的路径。比如短期内我们不会太关心说数字一定要到一个什么样的程度，像开发者数量，你想追求这个的话是很简单的，无脑引入大量的长尾开发者、甚至就是商户，量级很好做上去，但是这些是不是你现在要解决的问题，是不是用户和开发者的痛点就很难说了。
知晓程序：快游戏和快应用要解决的问题一样吗？
董红光：不一样的。从应用角度来说，大多数应用都有场景化的需求，可能还有不同端的需求，但游戏不一样，重度游戏和快游戏的开发者是两类完全不同的开发者，后者不太会开发「端」，或者即使开发，也是一个很轻量级的端，他们更偏休闲游戏，或者超休闲游戏。当然，重度游戏的开发者，一般也不会用快游戏，小游戏技术来做游戏。
重度游戏和快游戏的用户人群也不一样，重度游戏更偏核心的玩家，快游戏则偏向玩家圈层之外的人群，甚至他之前都不玩游戏，但在信息流看到了，或者别人分享的，就点了一下开始玩了。两者的渠道也不同，重度游戏会找游戏中心、应用商店这些传统的中心化渠道。
知晓程序：有说法认为，是手机厂商看到微信小程序起来后，被迫发展快应用，并结成联盟的？
董红光：我刚刚提到，我们是 2014 年就有想法，在 2016 年的时候觉得时机成熟。我们的整个节奏跟微信没有直接关系。虽然他们的确在类似的时间点在做一些事情，但你看微信小程序正式发布是 2017 年 1 月，我们是 2017 年 3 月正式发布的快应用，就是之前我们的直达服务，时间间隔很近，是我们提前规划好的。
另外，我们的思路跟小程序还是不太一样，我们本身要解决的用户需求问题，和面向的开发者都不太一样。所以我理解我们和微信其实不是一个竞争关系，更多的是大家一起把整个市场做大的合作关系。
知晓程序：前段时间微信和三星达成了合作，在三星手机的负一屏和侧边栏直接打开微信小程序。微信曾告诉知晓程序，除了三星，也在和快应用联盟的其他手机厂家寻求合作，小米会和微信达成这样的合作吗？
董红光：理论上确实是可以合作的，但这中间涉及很多实际问题。
首先，它和应用商店分发应用不同，应用分发是流量层面的合作，我一次分发，后续的东西跟我就没什么关系了，但快应用这种模式是场景方面的合作，它是和业务深度绑定的，我要为这个入口的后向转化负责，反过来这个东西效果好不好，即后向数据表现，会直接影响到我前向入口的优化。
这就需要大家的节奏必须是高度一致的，比如要做个什么场景，就要有相应的开发者支持，这是需要持续短周期的深入配合，其实一个公司内部两个团队能有这样的配合都是不易的，更不用说两个公司层面。
第二是数据层面可能需要一些打通和融合，这就带来很多问题，比如隐私，以及因为商业层面的诉求，大家很难共享数据。
所以这件事不是不能做，但要做好还是很难的，短期内不是很看好这样的合作模式。
知晓程序：对于微信、支付宝、百度，包括 360、今日头条等推出的小程序平台，你怎么评价？哪一个平台的发展会更好一些？
董红光：我可能不太适合评价，因为我并不了解他们背后的整个逻辑链条，简单的想法下，我基本上就看两个东西，用户价值和开发者的价值。
大家都叫小程序，但实际上大家切的用户场景是不一样的，比如说微信，要在它几个比较重要的路径上解决用户和开发者的需求升级，比如在聊天、扫一扫、公众号等路径上，用户场景和开发者类型上稍有限制。当然不是说不能做其他类型，只是它可能并不符合用户预期。
微信在做小程序的时候，其实也在打破一些边界，培养一些新的入口和场景，比如在社交之外的「搜一搜」。能否培养起来用户习惯不好判断，因为会面临很多不确定性因素的影响，但我觉得这是很好的思路，在既有路径之下，我能够解决一部分开发者的额外需求以及升级用户侧的体验，但同时我去打破当前的一些既有路径，去培养一些新的入口和核心的场景。
其实大家都有类似的做法，像支付宝小程序打通淘宝、高德地图、微博等，相当于把他们体系之下的开发者输出到更多的场景之下。
这里面一个很重要的事情是，这些场景能不能有机整合起来，服务于同一个开发者。比如在微博场景的开发者能不能和支付宝上的场景做一些打通，如果可以，我理解他的这种联动协同效果就会好很多，但如果没有，可能就只是不同的入口用一套技术各自做不同的开发者生态。这就比较难。因为在一个垂直领域做生态，第一是流量问题，第二是面向的场景有限。
我所说的多个入口能联动协同起来，举个例子，一个服务类的应用，通过负一屏、搜索、短信、推送、桌面图标等入口，满足系统场景推荐、用户主动寻找、后续留存转化等需求，那用户和开发者的大部分需求就能在我的体系下转起来，这是我一直强调的，我觉得对生态是个挺重要的东西。
