换个角度看微信小程序

去年参加几次技术沙龙时，我注意到一个有意思的现象：与之前大家统一接受的换名片不同，有些人并不愿意被添加微信好友——“不好意思，不熟的人不加微信”。

这个现象之所以有意思，是因为名片暴露的个人信息似乎更多：所在公司、职位、电话、邮件等等;相反，微信只暴露一个账号。如果是从隐私角度考虑，能接受换名片就应当能接受加微信。但不愿意加微信，恰恰也是从隐私的角度出发的，因为不愿意被打扰。

所以不加微信的原因，是“隐私”之外另一重考虑：不愿意跟你发生某种形式的联系。

所谓“联系”，指的是发生交互的能力。名片暴露了公司、职位、电话、邮件等等联系，看似繁多，其实都是单向的联系方式，外人不主动联系你，是没法获取更多信息的，如果有危害，也无非是些很容易拒绝的骚扰。微信的联系则复杂很多：加了好友就可以看你的朋友圈，持续看到你的动态、了解你的爱好和心理，可以把你拉到某个陌生的群，还可以“零成本”把你的微信名片发给其他人…… 从这个角度来看，不加微信就很容易理解了。

如果顺着这个角度继续思考就会发现，工具提供的交互能力，与基于工具建立的联系的强弱是大致匹配的：电话是独占式而且“必须即时答复”的，所以联系强度很高，不轻易发起;微信是全方位介入生活而且形式多样的，所以强度也不小，而且包罗万象;短信、QQ不要求马上答复，表达形式也较贫乏，所以往往用于不那么正经的场合(银行通知类短信除外);邮件的情况复杂一点，虽然交互能力有限，但因为往往揉合了职级体系和工作安排，并不能简单算作弱联系。

这些结论不难理解，但仍然有很多时候大家会“搞错”联系的强度，本该交换名片的时候变成了互加微信，本该留邮件地址的时候留了电话号码。究其原因，未必是参与者对联系形式没有感知，还有可能是因为确实没有合适的联系形式。

要知道，真实世界的联系是非常复杂的，即使看起来很固定的“双人好友联系”，也可能需要在不同强度和形式中切换——有时候我只想和你的邮件联系，有时候又需要和你电话联系。可惜的是，大多数通讯工具只提供了“好友”这类联系模式，它是固定的，缺乏灵活变化的柔韧。所以，如果我加了你的微信好友，那么任何时候——哪怕我们的关系不那么密切了——你都可以随时给我发消息、给我拉群、看我的朋友圈。这，正是让很多人感觉不适的原因。

再举个例子。很多人都有过饭馆排队等号的经历，领号之后往往只能干等着，如果错过就只能重来。好一些的饭馆会提供让食客留下电话号码，这样领号之后就可以四处逛逛，快到了会接到饭馆电话通知。但这也只解决了单方面的问题，不少食客在闲逛时希望知道进度——“前头还有几个人，是不是快了”，电话显然不能胜任。于是，专门用于查询和通知等号情况的微信服务出现了，它提供了双向的、即时的通讯，既可以等通知，又可以主动查询。

看起来，这种服务完美地解决了问题，其实不是，这种交互还是不能灵活变化。用餐完毕之后，食客就不再希望和服务号保持紧密联系，至少不要再受它们的骚扰，但刚刚已经关注的服务号还会遗留下来，也没有办法自动切断联系。不知道其他人怎么对付这种问题，我经常不得不关注的各种“服务号”，只能手动取消关注或者关掉“接收消息”的选项，下次到某些时候又必须手动开启“接收消息”，如此往复，烦不胜烦。有没有可能，我虽然关注了你，但是只在我需要的时候你会出现，我不需要的时候你就不出现?目前来看，似乎还没有。

前些年有个概念非常流行，叫LBS，也就是“基于地理位置的服务”，比如当年流行的“签到”，就是最直观的例子。LBS单纯从形式上看可能是强联系，但只有你到了特定的地理位置才能使用某种服务，一旦离开特定位置，服务也随之消失。人能不能和服务交互、如何交互，在一定程度上是随着地理位置的变化而变化的。可惜很多LBS都是“为了LBS而LBS”，一方面特别希望建立强联系黏住用户，另一方面又没有很好的适配场景。结果在用户不需要的时候总是跳出来烦扰，要么在用户真正需要的时候又帮不上忙。LBS应用的功能再强，不能“体谅”用户就是白搭。

总的来看，基于现下流行的单纯“加好友”或“关注”方式所建立的静态联系，它所提供的交互能力，即便功能足够强，也太不灵活，太难变化，所以还有大量应用场景不能覆盖——上面提到的依时间或者地理位置变化而变化的联系，其实都是具体的应用场景。理想状态下，个体与个体、个体与服务之间的联系，应当能根据应用场景变化而不断变化。如果有统一的账号和基础能力，提供的联系有不同层级的区分，有针对具体应用形态的定制，并且能平滑地切换，自然很容易催生千丝万缕的联系。

微信已经在这方面做了些尝试，而且效果不坏，订阅号就是例子。虽然微信的存储、推送在技术上都没有问题，大家也默认接受微信的实时消息，但绝大多数微信订阅号每天只能推送一次，这种“克制”在微信高黏性、高频度的应用特性下生生开辟了“弱联系(弱触达)”的特区。它虽然引发了不少抱怨，却保证了订阅号和读者之间相对健康的联系，订阅号不能毫无节制的乱推，读者也不会感到烦腻。

现实生活中还有更多类似的场景，需要专属而且灵活的联系形式和规则。组团出游就是这样：在旅行团没有结束之前，所有团员的联系是非常紧密的，大家需要聊天，需要分享照片，需要收到统一通知，需要定位团员，需要能方便地清点人数和答到…… 一旦旅行团结束，就应当各回各家各找各妈，避免持续的打扰，真正愿意保持联系的人，完全可以自己拉微信群接着聊。单纯为旅行团做个应用程序又太重，所有人需要注册、登录、加好友，最后还得记得注销和退出;但是没有这样的应用，效率确实又无比低下。理想状态下，通用工具在轻松解决身份问题的基础上，能很好提供“在特定场景下定制联系形式和能力”的服务。可惜，这样工具我还没有看到过。

上面这些问题我之前一直在思考，也和不少朋友交流过。基本观点认同的人不少，但这种问题究竟要如何解决，未来在哪里，一直没有明确的答案。上周看到微信小程序的公开课，看到张小龙的演讲，尤其是他谈到场景、生态的部分，我相信微信团队也思考了这类问题：在现实生活中的每个具体场景下，应当有办法定制出最精简最适合用户需要的“小微信”(这个名字不一定准确)，在其中，服务与用户的交互能力不会被滥用，也就不会给用户带来麻烦。如果能做到这一点，整个生态圈里联系的粒度就会细致很多，能够催生的联系也会大大超出人们的想象。

但我失望的是，现在看到很多关于小程序的文章，大都在讲如何开发、如何调用、如何部署，并没有多少产品设计和交互能力定义上的讨论。所以，我把自己的想法写在这里。

作者：余晟

（编辑：ASP站长网）