在当今社会，即时通讯已经成为了人们生活中不可分割的一部分，而在很多信息收集场景中，最常见的一句话可能就是：
收到。
这句话贯穿了几乎所有聊天场景，尤其是企业沟通。
但是，居然没有人认真思考过这句话的内在含义，和它对效率的影响。
从表面上看，这句话的意思是：告诉消息的发送者，自己已经知晓了这条消息。
但事实上，这条消息可能还有以下含义。
第一，告诉对方自己已经办完了这件事。
第二，告诉对方所有消息相关的附件已经全部接收完毕，且在其中没有文件损坏等情况。
第三，表示自己上传的信息已经被成功接收并计入统计。
可以看出，一个小小的“收到”，其实蕴含的意义还是不小的。
但在当今的企业，或是家校沟通场景中，很多消息的发送者都会提示，这条消息收到之后不需要回复“收到”，这又是为什么呢？
其实，本质上是为了防止已读回执淹没原本的通知。
大多数即时通讯软件，都是有“信息流”这个概念存在的。
所谓信息流，经常刷一些资讯类软件的人可能知道，这类消息一般是通过上下滑动来查看的，只有一个主线程，也就是说，在软件层面，只可以看到这些人在讨论一件事。
同时，真正有意义的消息和已读回执类消息并不能被有效地分隔开来。
而当这条通知类消息非常重要时，这样的信息流模式就会导致一个严重的问题：真正有意义的消息被顶到了信息流的顶端，而下方全部都是已读回执。
所以很多人才会在发消息后特别注明，不需要回复。
但是，目前的许多即时通讯类软件都没有已读未读提示功能，也就是说，我们是不能在消息发送者的视角，直接看到所有接收者是否已阅读消息的。
这就造成了一个悖论，如果回复收到，有可能会使更多的消息接收者收不到，如果不回复收到，那么消息发送者也不知道你是否收到。
好在一些软件开发商，尤其是做企业沟通的开发商，考虑到了这个问题，并在自家的软件中加入了这一项功能。
比如腾讯的企业微信，阿里的钉钉，字节跳动的飞书等。
飞书是字节跳动开发的团队协作工具，原本是企业内部使用的，所以他们也抓住痛点，加入了这一项功能。
但是，鹅厂的很多应用都没有加入这项功能。
这也就造成了在非企业内部写作场景下，尤其是家校沟通场景下，经常出现回复与不回复已读回执的冲突问题。
对于这种冲突，我们该如何应对呢？
我们应该从两种视角来看待这个问题，第一个视角是消息发出者的视角。
在消息发出者看来，他应该让这个通知准确的传达到所有消息接收者的手中。
所以，在大多数情况下，他都会提示“不需要回复”。
但是如果消息接收者有足够的耐心向上翻找，那么回复“收到”更便于他统计消息的接收人数。
在我遇到的消息发出者中，大部分人都是选择前者的。
由于我遇到大部分的场景都是家校沟通，作为学校一方，通知的信息往往都是非常重要的，比如作业完成的提醒等。
而家校沟通不可能只有一个老师参与，在实际生活中，很有可能遇到多个老师发出不同通知的情况。
对于这种情况，回复的“收到”，再也不知道是对应哪条消息了。
所以，与其让消息淹没在已读回执中，不如将消息的送达率交到接收者手中。
而作为消息接收者，较为省事的方法，肯定是收到消息后不需要回复。
但是如果消息非常重要，有些人会选择回复一下，以便消息的发出者可以及时统计。
在一些接到消息后，需要完成一些任务的场景下，也需要这些人完成后回复，以便他们更好地规划任务的进展。
很明显，这两种视角依然是存在冲突的。
当然，聪明的人们肯定也会有折中的解决方案，比如上述提到的已读提示功能。
对于那些还没有增加已读显示的软件，我的一般策略是这样的（以下策略从上到下优先级递减）：
- 对于消息中规范了回复方式的，按照其规定。
- 对于收到后需要完成一些任务的消息，一般我收到并完成任务后会回复。
- 对于绑定了一些文件的消息，我会在收到并下载查看所有文件，确认这些文件都没有损坏后回复。
- 对于没有绑定任务的消息，如果该消息判定为非常重要，则完成后回复，否则则不回复。
- 如果以上条件都不符合，完成后不回复，除非对方主动询问。
我使用这套规则也有很长一段时间了，这期间不得不说也遇到过这些规则相互发生冲突的情况，但按照优先级排序，我还是能妥善处理各种冲突，在消息的送达率与自己的便捷程度、别人的接收难易度之间取得最好的平衡点。
也许，这才是即时通讯的真谛吧。
