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

我曾经说过，这个世界上有四种产品：小而美的产品、大而美的产品、小而丑的产品、大而丑的产品。大部分产品是小而丑的，基本所有的大型产品都是大而丑的。小而美的产品现在越来越多，但大而美的产品很少。如果有，微信应该属于这一类。

微信属于大而美的产品，主要是她用户量很大，但在产品体验和设计细节上把握的很 “谨慎”，这种谨慎甚至到了 “防微杜渐” 的程度。

联想到最近张小龙说的 “蝴蝶效应” 更是感觉他们更多的考虑在微信这个产品上，不是能做什么，而是不能做什么。操盘大而美的产品，我想应该是 “治大国如烹小鲜” 的感觉，只有这样，产品的态势才会持续下去。基于此，我认为微信应用号应该符合微信一贯的设计理念和产品哲学。

我还说过，微信一共有三个阶段：

第一个阶段，微信是一个 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年 加入微信的 “风铃” 团队这次应该能派上大用场了。

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

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