当我们讨论微信应用号时，可别忘了张小龙的产品逻辑

风铃团队一直在腾讯做着无线 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 不仅被调起了，还通过应用号相互的串联起来，提供了一整套更为智能的服务。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!