我们为何不愿加微信了？换个角度看微信小程序

在去年的技术沙龙活动中，我发现了一个引人注目的现象：在交换名片这一传统礼仪中，许多人并不倾向于添加微信好友，其理由往往是“不好意思，不熟的人不加微信”。这一现象之所以引人深思，是因为名片所承载的个人信息远比微信更为广泛，包括所在公司、职位、电话、电子邮件等诸多内容；而微信则仅仅提供了一个虚拟账号。从隐私保护的角度来看，如果愿意交换名片，那么接受添加微信好友也应当不是问题。然而，许多人出于不想被打扰的考虑，选择不添加微信好友，这同样是从隐私角度出发的考量。

那么，不添加微信好友的原因究竟是什么？除了隐私之外，还有一层更深层次的考虑，那就是不愿与你建立某种形式的联系。这里的“联系”，实际上是指双方之间进行互动的能力。名片虽然暴露了诸如公司、职位、电话、电子邮件等联系信息，看似繁多，但实际上这些都是单向的沟通方式。外人不会主动向你发起联系，因此无法获取更多信息，即使有潜在的危害，也不过是一些容易被拒绝的骚扰信息。

相比之下，微信的联系则显得复杂得多。一旦添加好友，你不仅可以查看对方的朋友圈，持续追踪对方的动态、兴趣爱好和心理状态，甚至可以将你拉入一个陌生的群组，甚至可以“零成本”地将你的微信名片分享给其他人。从这个角度来看，不添加微信好友就变得容易理解了。

进一步分析，工具所提供的交互能力与基于该工具建立的联系强度大致上是相匹配的。电话是一种独占式的沟通方式，需要即时回应，因此联系强度较高，不易轻易发起；而微信则是一种全方位介入人们生活的沟通方式，形式多样，联系强度也不容小觑。短信和QQ虽然不需要即时回应，表达方式也较为单一，但它们通常用于较为随意的场合（如银行通知类短信除外）；而邮件则更为复杂一些，虽然交互能力有限，但由于它通常包含了职级体系和工作的安排，因此不能简单地视为弱联系。

然而，尽管这些结论不难理解，但在实际操作中，人们往往会“搞错”联系的强度。例如，在应当交换名片的场合却变成了互加微信好友，或者在应当留下电子邮件地址的时候却留下了电话号码。究其原因，可能并非参与者对联系形式没有感知，而是因为确实缺乏合适的联系形式。

在现实生活中，真实世界的联系是非常复杂的。即使看起来固定的“双人好友联系”，也可能需要在不同强度和形式之间进行切换。例如，有时我可能只想通过邮件与你联系，而有时又需要通过电话进行沟通。遗憾的是，大多数通讯工具仅提供了“好友”这一联系方式，缺乏灵活性和可变性。

如果我添加了你的微信好友，那么无论我们的关系如何变化，你都可以随时向我发送消息、拉你入群、查看我的朋友圈。这正是许多人感到不适的原因。

再举一个例子，在饭馆排队等号时，领号之后往往只能干等着，如果错过就只能重来。一些饭馆会要求顾客留下电话号码，这样领号之后就可以四处逛逛，快到了会接到饭馆电话通知。然而，这也只解决了单方面的问题，许多顾客在闲逛时希望知道进度——“前头还有几个人，是不是快了”，电话显然不能胜任这一任务。于是，出现了专门用于查询和通知等号情况的微信服务，它提供了双向、即时的通讯，既可以等待通知，又可以主动查询。然而，这种服务看似完美地解决了问题，实际上却不能灵活变化。用餐完毕后，顾客不再希望与服务号保持紧密联系，至少不要再受它们的骚扰，但已经关注的服务号仍然会残留下来，无法自动切断联系。

目前来看，似乎还没有能够实现只在需要时才出现、不需要时则不出现的联系形式。例如，基于地理位置的服务（LBS）虽然看似是一种强联系，但实际上只有在特定地理位置才能使用某种服务，一旦离开特定位置，服务也随之消失。人能否与服务进行交互以及如何交互，在一定程度上是随着地理位置的变化而变化的。

遗憾的是，许多LBS应用都是“为了LBS而LBS”，一方面希望建立强联系以黏住用户，另一方面却未能很好地适配场景。结果在用户不需要的时候总是跳出来烦扰，或者在用户真正需要的时候又帮不上忙。即使LBS应用的功能再强，如果不能“体谅”用户，那么它就是无用的。

理想的联系形式应当是专属且灵活的。总的来看，基于现下流行的单纯“加好友”或“关注”方式所建立的静态联系，所提供的交互能力即便功能足够强，也过于僵化，难以适应不同的应用场景。因此，理想状态下，个体与个体、个体与服务之间的联系应当能够根据应用场景的变化而不断调整。如果有统一的账号和基础能力，提供的联系应有不同层级的区分，有针对具体应用形态的定制，并且能平滑地切换，这样自然很容易催生出千丝万缕的联系。

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

现实生活中还有更多类似的场景，需要专属且灵活的联系形式和规则。例如，组团出游就是这样：在旅行团没有结束之前，所有团员的联系是非常紧密的，大家需要聊天、分享照片、收到统一通知、定位团员、方便地清点人数和答到……一旦旅行团结束，就应当各回各家各找各妈，避免持续的打扰。真正愿意保持联系的人，完全可以自己拉微信群接着聊。单纯为旅行团做个应用程序又太重，所有人需要注册、登录、加好友，最后还得记得注销和退出；但是没有这样的应用，效率确实又无比低下。

理想状态下，通用工具在轻松解决身份问题的基础上，能很好提供“在特定场景下定制联系形式和能力”的服务。然而，这样工具我还没有看到过。上述问题我一直在进行思考，并与不少朋友进行了交流。基本观点认同的人不少，但这种问题究竟要如何解决，未来在哪里，一直没有明确的答案。

上周我看到微信小程序的公开课，看到张小龙的演讲，尤其是他谈到场景、生态的部分，我相信微信团队也思考了这类问题：在现实生活中的每个具体场景下，应当有办法定制出最精简最适合用户需要的“小微信”（这个名字不一定准确），在其中，服务与用户的交互能力不会被滥用，也就不会给用户带来麻烦。如果能做到这一点，整个生态圈里联系的粒度就会细致很多，能够催生的联系也会大大超出人们的想象。

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