江阴帮
微信应用号在张小龙的新年第一次公开演讲中被大家所知晓，随之而来的是铺天盖地的关于应用号的猜想，拙作《微信应用号来了，你的 APP 怎么办》发布后，被广泛转载，阅读量较大。
很多人在看完文章后给我留言，询问关于微信应用号的一些问题，比如微信应用号入口在哪？微信服务号是调起 native app 还是加强 web app？微信应用号会用什么样的方式提供某种能力？
毕竟我不是微信的人，也没有微信的 “线人”，我所了解的关于微信应用号的内容不比大家更多。虽然如此，我还是想通过我对微信的理解、对应用号的产品设计逻辑的判断，来和大家一起 YY 一下微信应用号。
预测这件事向来都是有风险的，分析已知的产品都是 “马后炮”，这一次，我来做一次冒险，不做马后炮的 YY 一下微信应用号。
如果不幸猜中了一二，不一定能证明作者如何未卜先知，只能证明张小龙符合其一贯坚持的的产品哲学和产品逻辑。同时也可以证明我的一个观点，产品制造者基于产品的沟通和交流，其实可以通过产品本身展开，而未必需要认识、见面或者一起吃饭。
以下进入正文，我分 4 部分来主要阐述我的看法。
一.已有对于微信应用号的推测都是不靠谱的
应用号出来后，市面上也有一些文章号称有了微信应用号的原型 Demo，我看了几个，觉得很是山寨，完全没有基本的产品逻辑和产品认知，把微信当做一个被 “强奸” 的产品，没有任何技术含量。
先来看看所谓的微信应用号原型，第一组：
这是所谓的第一组原型，居然被广泛的传播了起来，其主要的设计思路是在底部导航栏增加了一个叫 “应用” 的一级入口，点击进去看到的就是各种应用的 icon。
大家看完这个能联想到什么？没错，就是我们这些上了年纪的人在 2010年 见过的 “360 桌面”！
但我敢肯定的说，微信绝对不会走 360 桌面的老路。更不会在微信中硬生生的插入一个 “应用宝”！应用分发这件事应用宝虽然做的越来越顺风顺水（事实上应该很快能到行业第二，仅次于百度手机助手），但也绝不可能对张小龙 “霸王硬上弓”！
再看一个网传的原型图:
第二组由于设计风格不太像 360 的粗暴风格，更接近微信原生风格而被更多人觉得更像。其主要设计思路是把底部的导航变为 “微信、朋友圈、应用和钱包”，应该说这对现有的微信简直是极其大的挑战。但作者并没有说清楚应用这个 tab 里面到底是什么样的。
这个设计思路最大的问题就是没有弄清楚微信所处的产品生命周期（PLC）阶段并忽视了微信的用户体量。
微信目前属于产品生命周期的增长期结束，成熟期开始的黄金时期，这一时期的产品迭代必然是循序渐进的 “微迭代”，不可能大刀阔斧的 “改头换面”。
另一点就是对于一个用户量超过 7 亿级别的产品来说，任何小的调整都会带来强大的 “蝴蝶效应”（这是张小龙公开课的原话），所以不可能有如此重大的改变。
这种设计思路的产品经理应该说没有过操盘如此大用户量产品的经验。以上两种原型我觉得不仅完全 YY，而且基本上没有产品设计的基本逻辑和原则，权当一个假想设计图看看罢了。
今天我们想 YY 的这个微信应用号，还是基于严谨的产品设计逻辑和微信及张小龙先生一如既往的产品哲学而讨论，希望通过这个讨论能给大家带来一些产品规划、设计上的参考。
二.微信应用号服务的企业端用户是谁？
在聊应用号的产品设计前，我们先想想应用号到底和你有没有关系。市面上的 App 很多，其实不是所有的应用都需要微信应用号，虽然所有的应用都需要微信。
我们先把应用分下类：如果我们将互联网的产品根据 “重要-不重要” 和 “高频-低频” 来画一个四象限的图，那么我们可以看到，其中有三个象限是可以放入很多 App 的。
为什么左下的象限是没有内容的呢？
为了更容易看清楚这个图，我对四个象限进行了命名。如下图：
所以我们看到：
第一象限：BAT 象限里基本都是 BAT 的公司或者他们控股、投资的公司，这个区域资金密集、用户密集。
第二象限：创业象限，有着流量和用户，但其价值变现需要转移才能实现。
第三象限：Loser，基本属于失败者的空间，不多说了。
第四象限：目前看到的 “互联网 +” 领域和所谓的 O2O 领域。这个区间的产品，缺流量，有资源。
所以，我们从上表可以看出，最需要流量和入口的是第四象限，而最有流量的是第一象限。所以我们看到，微信也好，百度也好，都是在做从第一象限往第四象限分发流量的事情，美其名曰 “链接人和服务”。
所以，我认为，第四象限的从业者最需要链接进入应用号。
当然，多说一点，我们看到今天投资的方式是 BAT 在投资第二象限，服务资源在第四象限。对于第二象限流量的争夺以及对第四象限服务能力的争夺正成为 BAT 的新战场。
三.微信应用号背后的基本产品逻辑
那微信应用号到底会有什么样的产品逻辑和产品哲学观呢？我觉得要了解这一点，首先我们得了解下微信是一款什么样的产品。
我曾经说过，这个世界上有四种产品：小而美的产品、大而美的产品、小而丑的产品、大而丑的产品。大部分产品是小而丑的，基本所有的大型产品都是大而丑的。小而美的产品现在越来越多，但大而美的产品很少。如果有，微信应该属于这一类。
微信属于大而美的产品，主要是她用户量很大，但在产品体验和设计细节上把握的很 “谨慎”，这种谨慎甚至到了 “防微杜渐” 的程度。
联想到最近张小龙说的 “蝴蝶效应” 更是感觉他们更多的考虑在微信这个产品上，不是能做什么，而是不能做什么。操盘大而美的产品，我想应该是 “治大国如烹小鲜” 的感觉，只有这样，产品的态势才会持续下去。基于此，我认为微信应用号应该符合微信一贯的设计理念和产品哲学。
我还说过，微信一共有三个阶段：
第一个阶段，微信是一个 IM，即时通讯软件，沿袭的 QQ 的移动端地位。
第二个阶段，微信是一个浏览器，沿袭了 QQ 浏览器在移动端的地位，成为移动流量入口。
第三个阶段，是一个云 OS，跨越 iOS 和 Android，继承 Chrome 想在 PC 时代做的云 OS 的事。
事实上，我们非常需要一个跨越 iOS 和 Android 的云 OS，我说的是开发者。目测来看，微信目前属于第二个阶段和第三个阶段之间。应用号应该是肩负着完成第二阶段或者开启第三阶段的光荣使命。
至于具体是完成第二阶段还是开启第三阶段，我们需要分析后面微信团队所秉持的技术路线而定。如果他们选择了 Web app 的路线，则应该是属于第二阶段的收官之战。如果他们挑战了 Native app 路线，则应该属于开启了第三阶段的第一战。
无论如何，在我们聊到微信应用号的时候，有几个原则是必须要了解的，这几个原则是微信应用号产品会坚持的几个原则。
1）去中心化
如果我没有记错，2015年 的微信公开课，张小龙虽没有出席，在国家会议中心的的 VCR 里，他提出的当年主题就是 “去中心化”。所谓的去中心化，实质上是指每个人都是中心,从原来舆论中心——受众的二级传播，变为每个人都是传播的中心，我把他起名叫一级传播。
上图来自我的新书《产品的视角：从热闹到门道》
这主要是由微信的社区属性决定的，SNS 不像门户或者搜索，有一个统一的入口和首页-landing page 的结构，每个人看到的朋友圈都和别人不一样，每个人既接受信息，又传递信息。
所以，微信应用号应该也是基于这个逻辑设计，基于此，我们上述选取的山寨原型就被排除了，因为加一个一级入口，并且将一些 icon 排列起来的方法，正是所谓的 “中心化” 的表现。
如果微信那么做，只能证明张小龙已经失去微信产品操盘能力，或者他自己说的话已经忘了。
2）服务于留存
应用号对于开发者来说，是为了拉新还是为了留存？显然是为了留存。拉新这件事对于广点通、应用宝来说做的很有感觉了，开发者也已经有解决方案了。最痛的痛，还是来自留存和活跃用户这件事。
而微信作为一个用户高频次的入口级产品，按照张小龙的说法，最可能做的事情就是当用户想起一件要做的事情，或者想获得某个服务的时候，“赶紧离开”。好的产品是让用户赶紧离开的产品，而离开后去哪呢？去提供服务的人那了。谷歌不就是这么做的么？
所以，一个基本判断是微信服务号是为了让用户更加容易使用一些产品，而不是推荐更多产品去下载或者关注。
3）基于关系链的自生长模式
之前我有一个判断，腾讯里面的所有产品，但凡使用 “关系链” 这一核心资产的产品，都发展的不错，但凡和关系链关系不大的产品，都发展的一般。
比如阅读、小说这样的产品，很一般。比如腾讯视频，也表现平平，但一旦和社区关系发生联系，腾讯视频的影响力和用户量一下起来了。
某种意义上说，应用宝这款产品其实也是因为腾讯社交广告的推动，成为了第二大（预测）的应用分发平台。
所以，应用号也必然会和关系链这一核心能量联系起来。这一核心能量，就是基于用户关系和朋友圈这一媒体出口表现出来。这一使用场景，我们后面的例子会给大家展示出来。
以上 3 个原则，在我们讨论微信应用号的过程中，应当谨记，并作为一条准绳来看待。
四.产品技术路线选择
好了，最后一个大问题来了，各位看官看了一堆东西，发现还没进入正题，咱们要 YY 的微信应用号是到底个什么样子呢？聊完了这里，我们接下来就要正式进入猜想了。
其实，在 Web app 和 Native app 的技术路线选择上，我拿不准。不仅我拿不准，估计微信产品团队应该也有很长的争论。
选择 Web app 吧，有很多挑战。毕竟 Web app 基于 html 来做，体验差，挑战了用户使用习惯（用户更多用 Native app 购买服务），受网速和开发框架限制。
选择 Native app 吧，面临 iOS App Store 的危险，同时要让很多 app 提交 in app 的 link，或者在应用里加入微信的 sdk，这个对中小 app 没有太大问题，对于大型 app 来说是不可能的。而用户最常用的 app 反而是那些大型企业的 app。所以，如果只有中小 app 加入了 sdk 或者提交了 links，其实对大部分用户来说也用不上。
从推动的角度来说，我个人还是偏于保守，把票投给了 Web app。如果微信真的会支持 Native app，我只能说他们的想象再一次超出了我的预期。
基于 Web app 的形态来做，可能会更加快速的使微信应用号跑起来，也能更发挥微信的能量。特别是，2012年 加入微信的 “风铃” 团队这次应该能派上大用场了。
风铃团队一直在腾讯做着无线 wap 建站的事情，后来归入微信旗下，为微信服务号和订阅号的框架做了很多基础性的工作，但还没完全发挥他们的价值。如果基于 wap 和 h5 来做产品形态，微信的接入框架不能太复杂，体验和响应速度方面也要做很多优化，这方面的工作风铃可以有用武之地了。
五.微信应用号的场景和产品原型猜想
终于到了正式的猜想部分，我们先分析猜测一下微信应用号的几个有意思的点。
1）应用号有所谓的一级入口么？
我猜，不会存在一级入口（也就是 Tab 入口），甚至没有统一入口。只有管理入口。
我的观点是：微信应用号没有入口，更没有一级入口。其入口来自轻应用服务提供者自发传播和运营而来，不会设置统一的拉新入口。
但服务号一定有自己的管理入口，每个有用户都需要管理自己账户里的应用号。而应用号的管理入口在哪里？这涉及到我们第二个猜想，人格化的应用号。
2）应用号必将是一个拟人化的应用号
所谓拟人化的应用号，是指无论应用号后面接入的是 Web app，还是 Native app，但其之所以叫应用号，必然是他还是个 “微信账号”，应该和微信的服务号、订阅号一样，都是一种账号。
事实上，微信的服务号和订阅号一直以来被大家认为是一个 “伟大的创新”，然而用过 Facebook 的同学都应该知道，FB 里面的账号就有个人账号、public 账号和 organize 账号。
微信只是借鉴了 FB 的 public page 的理念来做，但真正的创新在于讲服务号、订阅号这样的组织账号拟人化出现了，在产品表现上，产品形态和个人账号极其接近，运营者也都以拟人化的方式去和用户沟通。
拟人化的应用号，应该也是一个合乎逻辑的推断。而如果这一逻辑成立，那么其基本的产品形态也就不难预测。
3）应用号将会有一个基于 IM 的基本结构的产品形态
我认为应用号和服务号一样，可能也是基于 IM 的基本形态打造。
简而言之：看起来有一堆服务，但事实上也是个聊天框。
4）应用号的假想原型和场景
说了这么多，大家一定想知道应用号的入口在哪里，长什么样。但是别急，我们再来揣摩一下张小龙的原话：
“推出应用号之后，用户关注一个公众号，就像安装了一个 APP。平时这个号不会向用户发东西的，所以 APP 就会很安静的存在那里，等用户需要的时候找到它就好了。这样的话我们可以尝试做到让更多的 APP 有一种更轻量的形态，但是又更好使用的一种形态来存在。并且，未来将通过云端技术，即便更换了手机，之前安装的应用也不会丢失需要重装。”
从中我们可以看出，张小龙希望应用号是 “一种更轻量的形态”。这很容易让我们联想到 H5 页面，打开网页即可使用。但原话中也提到了，应用号是需要用户关注或者安装的。很明显，张小龙脑海中的应用号并不是一个个简单的 H5 页面，它的形态与服务号、订阅号更为相似一些。
也有人说，钱包中的应用，可能就是应用号的原型，似乎有些道理。
想象下用户的管理入口：根据之前的想法，应用号应该是没有很强势的统一入口，而应该有一些管理入口。
应用号的管理和添加有没有可能出现在通讯录里呢？我认为是可能的。
如果是这样，那应用号的入库逻辑可能和公众号很相似。使用搜索、二维码等作为发现\安装入口，在通讯录中增加应用号的管理入口。
进入应用号后，里面的样子我也 YY 一下下：
简单来说，就是通过一个应用号框架，把目前的 H5 站点接入进来，并且打通账号和支付两个基础模块。具体样式肯定有变。
sponsored story 会被加入么？
当然，这根本不够酷。但如果我们将微信的关系链加进来一起想象呢？
我们假设一个场景：周末无聊，一个人想去看电影，于是我打开了微信电影票的应用号，果断买了张票，然而一个人看电影最无聊了！这时候，微信应用号的关系链分享功能触发（观察到你只买了一张票）：“是否邀请好友一起去看场电影啊？”选择邀请好友，应用号在我的朋友圈中添加了一条状态：“下午我去看《三体》这部电影，谁会陪我去呢?”
我其中一位朋友看到了这条状态，通过应用号购买了同场电影票，并获得了优惠。
在这个场景中，我的朋友感知到了应用号的存在，并享受到了它的服务。甚至没有看到烦人的优惠券，就获得了折扣。
不要害怕，这其实在 Facebook 里面已经存在，他的名字叫 “sponsored story”，星巴克经常玩这个功能。（PS：sponsored story 是 Facebook 的一种广告形态，很类似几天我们讲的应用号的使用场景。FB 将每个服务提供者的 web app 放入一个框架，并且提供 FB 资源给广告主去运营这个 web app）
如此一来，可能就完成了应用号虽不会给用户推送消息，但也能提供相当大的能量给他到应用号的提供者，以帮助服务提供者提升留存。
五.最后的脑洞
上文探讨技术路线时，我们猜测应用号可能会有两种形式，一种是 Web app 的形式，一种是 web+Native 的形式。
我们刚才探讨了 Web app 的形式，那 Web+ Native 可能是怎样一种形式呢？
如果基于 Native 的逻辑，我想微信更加倾向于做云 os 层面的东西。而云 os 的特点是能够在所有 Native app 之间打通一条横向的连接线。
先来说个例子：我在应用号中的日历应用中添加了 19 点约朋友吃饭，此时应用号自动调起团购 APP，向我推荐了可预订的餐馆。18 点的时候，日历提醒我该出发了，并自动调用地图 APP 帮我查到当前路况，并用滴滴出行 APP 帮我叫了一辆快车。
当然，所有的行为最后的确认都是我自己做的。
在这个例子中，各 APP 不仅被调起了，还通过应用号相互的串联起来，提供了一整套更为智能的服务。
每一个 APP 就不只是独立的与 OS 之间发生联系，相互之间也发生了联系。听到这里，似乎感觉微信像一个机器人，有点不可思议。我们用两张图来展示这个 YY 的场景，在没有打通 Native app 的情况下是这样的：
打通了之后，微信作为一种云 OS 就能让用户顺畅流转起来了。
如果做到这一点，那些叫嚣 “做机器人” 的公司基本上又遭受了一次强大的打击！腾讯从来没有提出要做机器人，它只是把微信变成了你最贴心的 “机器人”！
