可惜很多LBS都是“为了LBS而LBS”，一方面特别希望建立强联系黏住用户，另一方面又没有很好的适配场景。结果在用户不需要的时候总是跳出来烦扰，要么在用户真正需要的时候又帮不上忙。 LBS应用的功能再强，不能“体谅”用户就是白搭。

　　专属而且灵活的联系形式和规则是怎样的？

　　总的来看，基于现下流行的单纯“加好友”或“关注”方式所建立的静态联系，它所提供的交互能力，即便功能足够强，也太不灵活，太难变化，所以还有大量应用场景不能覆盖——上面提到的依时间或者地理位置变化而变化的联系，其实都是具体的应用场景。

　　理想状态下，个体与个体、个体与服务之间的联系，应当能根据应用场景变化而不断变化。如果有统一的账号和基础能力，提供的联系有不同层级的区分，有针对具体应用形态的定制，并且能平滑地切换，自然很容易催生千丝万缕的联系。

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

　　现实生活中还有更多类似的场景，需要专属而且灵活的联系形式和规则。组团出游就是这样：在旅行团没有结束之前，所有团员的联系是非常紧密的，大家需要聊天，需要分享照片，需要收到统一通知，需要定位团员，需要能方便地清点人数和答到……

　　一旦旅行团结束，就应当各回各家各找各妈，避免持续的打扰，真正愿意保持联系的人，完全可以自己拉微信群接着聊。

　　单纯为旅行团做个应用程序又太重，所有人需要注册、登录、加好友，最后还得记得注销和退出；但是没有这样的应用，效率确实又无比低下。理想状态下，通用工具在轻松解决身份问题的基础上，能很好提供“在特定场景下定制联系形式和能力”的服务。

　　可惜，这样工具我还没有看到过。

　　上面这些问题我之前一直在思考，也和不少朋友交流过。基本观点认同的人不少，但这种问题究竟要如何解决，未来在哪里，一直没有明确的答案。

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

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

　　未经许可，禁止转载。如需授权请联系微信公众号：余晟以为（yurii-says）