我怎么看「即刻」这款应用
在「即刻」订阅超过一百个主题之后，它终于成为我在每天都会打开的应用之一。
「即刻」是一款支持用户自定义信息颗粒度的产品，与我有关的主题，就有「阑夕又有新的女演员点评」、「阑夕的几点看法」、「阑夕微博点赞提醒」等。
这些主题既有「即刻」官方主动策划并创建的，也有基于公开规则由用户提交创建的，前者需要针对某种颗粒的内容撰写算法程序，比如「又有大公司的负面信息了」，显然需要专门的索引和判断，而后者则由指定动作触发，比如「张小龙又有新的知乎回答」，只需要爬取张小龙的知乎账号动态就可以实现。
「即刻」的运行机制，让人想起美国的自动化神器「iFTTT」，这是「ifthisthenthat」的缩写，通过调用互联网产品的开放API，用户可以高度定制由一种动作引发另一种动作的功能，同时排除冗余干扰。
比如想要获得下雨提醒，用户可以不必安装某款天气应用——它意味着你可能会收到大量并不需要的提醒——而是可以使用「iFTTT」关联这款天气应用的API，并下达指令：只要所在地的天气状况变成下雨，那就通知另一款短信应用，由后者给自己发送一条注意带伞的内容。
在英文互联网的世界，因为去中心化的游戏规则属于「政治正确」的一部分，所以大多数主流产品——包括Google、微软、Facebook、雅虎旗下的总计上百款应用——都在技术协议层面允许「iFTTT」的操作，甚至主动提供了前端的触发条件，比如Flickr就支持用户通过「iFTTT」把所有被其打上星标的图片同步到Dropbox，一些智能家居产品，也支持「iFTTT」做出诸如当狗盆里的食物吃光之后提醒主人及时添加这种便利功能。
众所周知，中国的互联网公司对于用户资源的重视超乎想象，故而可能诱导用户接触其他应用的风险是极少可给容忍的，而「iFTTT」及其模仿者在国内几乎都毫无施展空间，直到「即刻」在内容领域曲线救国，部分性的重新定义了信息流的去中心化。
换句话说，「即刻」注重的是条件端的个性化定制，而在触发端，则统一收于「即刻」应用内的提醒，最终形成崭新的阅读场景。
比如在「即刻」里有很多「XX微信公号有更新了」的自建主题，它完全没有任何不同的创造体验——用户大可在微信里订阅这个公号——但是之所以用户愿意在「即刻」里完成这个动作，不外乎微信本身的溢出效应：订阅的公号太多，以至于对更新提醒变得麻木起来，加上公号与公号之间的认知权重区别难以划分，于是干脆在「即刻」里单独设计一个更新提醒。
于是，弱水三千，只取一瓢饮，「即刻」的产品定位，就只是那个瓢而已。
因为内容太少了。
我是一个除了微信之外不会向任何应用开放推送通知权限的非典型用户，所以「即刻」对我而言也不是一个通知工具，而是在细分信息类型之后的补充性阅读器。
所以，「即刻」的产品和运营团队，也在尽可能的促进用户留存方面，下了很大功夫。
但是这种做法却遭到了「即刻」用户的强烈反弹：我来这里就是为了完全自主的设计信息流，如果你可以主动帮我推荐内容，那我为什么不回微博？
此时的「即刻」，也不再需要用尽心思的在用户的信息流里「夹带私货」，而是在工具属性之外，把更多的算法放在了揣测用户兴趣方面，把内容池反复激活。
美国的科技作家埃利·帕雷瑟曾将社交网络「宠溺」用户的代价形容为「过滤气泡」的诞生：人们越来越善于将相异的观点和他人拒之门外，最后酿造出一个又一个充满回声的私人房间。
就像在书店里，有的书是论斤卖，有的书是论个卖，而「即刻」这个柜台想要做的，是按页卖。
