前些天河南暴雨，超过历史极值，导致数地遭遇灾情。我身为河南人，家乡遭灾，自然是十分揪心和关注。在收集、转发、建议的循环中，我发现了一些本可以做得更好的地方，而这些只需要进行技术改进并辅以轻微相应培训。我在自己力所能及的范围尽量呼吁，但用处显然不大。于是，在情况已经基本稳定的当下，我尝试将其整理出来，期待将来可有改进。

前事不忘，后事之师。

另：本文亦发在B站：https://www.bilibili.com/read/cv12513521

目睹问题

我在此之中目睹的状况和问题有许多，有些是不可避免的，有些则是可以通过技术手段解决或大幅改进的。下面我举几个比较典型的例子，然后对其反映的问题进行整理。

1. 信号中断

在灾害发生之初，绝大部分人还可以发布信息，分享灾情。但过了半天左右，问题开始出现，一些地区的基站受到了影响，信号质量下降，乃至没有信号。

其中个人认为最严重的是地铁五号线的状况。这次运气似乎还不错，受困于郑州地铁五号线的人仍然大规模有信号，于是可以通报情况，按目前的消息看，大部分人算是有惊无险。 但仍有其他地方信号完全中断，甚至许久后仍然未能恢复。

2. 消息溯源、迟滞和真伪

在消息可以正常流动的情况下，我们见到了大量的分散消息源。这本身没什么问题，而且应当被鼓励，毕竟消息总是需要由受灾的人启动传递的，这样才能尽可能保证及时。

但接下来的事情就是消息本身存在如迟滞、重复或虚假之类的问题。这些消息会消耗人的注意力，耽误更重要的真实的新消息的传播。

我在两天内看到三次某同一条消息，但第一次看到时就有当事人已经反驳了该说法；有的消息则是传播了两三天，早已过了有效期。更恶劣的是，在此情况下仍然有不少人在造谣。有的人是道听途说然后渲染加工，勉强还算可以原谅；但有的人则可以肯定就是故意造谣，制造虚假消息。

这些事情共同造成的结果，就是后来我们群里的这些消息大部分都需要由群成员人工验证，确认后再发。但几乎也就在此前后，转发来的消息也开始加上了「已验证」之类的话语——但仅仅考虑信息本身，这句话没有任何意义，完全可以也是编造之人直接加上的。

3. 重要信息被埋没

我们都看到了一些火车受到影响被迫停在半路，也有人去帮助。然而问题在于，舆论几乎全部在关注其中一辆，但实际上同时有多辆均被迫停在半路（报道1，报道2）。我看到一些车上的人在呼吁大家也关注关注其他车子，但效果非常有限。

以目前的做法，政府也许可以收到他们的报告，但民间救援力量难以有效发现该情况——民间救援目前只是依靠社交网络（如微博）和即时通信软件（如微信）上的信息，而这些地方正是重要信息容易被埋没的地方。

4. 险情传递

灾害时发生道路淹没、道路坑洼不可视、电线切断等问题。这些问题在每个城市都发生了，到处都有不同版本不同内容的相关信息。

这些问题其实政府或相关企业大多能够及时，也在派出人手处理/整修，但相关信息却往往不及时通报。导致的结果是人们要么不知道险情，要么只能从社交网络看到。但社交网络信息会有前面说到的真假以及过时的问题，所以有时候反而耽误事。

5. 捐赠物资很多，但发出不及时

在稍微晚一些的时候，我还看到一种问题，那就是捐赠物资分发不及时。

我直接看到的一个例子是某村子只领到了有限的物资（勉强够用），村干部说从区政府（管理物资存储和分发）要不来更多物资，故而村子在向外寻求帮助；而区政府说已经给他们了大量物资。在这一事件中，我的消息来源方面确认，村干部在此事中没有隐瞒；我们也有人在区政府的临时仓库附近，能确认物资很多。事实上，此时生活物资早已充足乃至过量，都堆在仓库发不出去，相关公告已经在呼吁不要再捐这些东西了。

问题整理

考察这些问题，我们会发现虽然事情的表现多种多样，但其中许多部分的原因是相近的。整理下来，其主要分为三部分：网络失效后的运转（1），信息的获取与筛选（2、3、4），政府信息数字化水平（3、4、5）。

下面对上文提到的三类问题分别讨论。

网络失效后的运转/无因特网状况下信息传递

对于绝大多数当代中国人来说，我们太过习惯了因特网尤其是移动网络的存在，没有意识到它不是自然的一部分，会有情况将你我强制抽离于它。

而灾害是最容易导致它们失效的原因。意识到这点后，我们总要考虑，如果没有信号，那么自然切断了在经历灾害的人和因特网乃至其他近在咫尺之人的联系。那么这些人该如何做，有没有更好的方案可以尽量增大他们传递信息的能力？哪怕是无法和外界通信，至少互相有所照应？

有的，而且不需要额外的设备，只要充分发挥蓝牙的功能即可。方法，则是选择manyverse或rumble这样的软件（app），或使用类似的通信方案。

蓝牙是本地通信协议，十分省电，有效通信距离在10-100米左右，超过呼喊的有效范围。而多个蓝牙设备组合在一起，可以互相作为中继以形成一个局域网，这样局域网内的设备间可以互相通信。这就是上述这些软件的基本原理。然后，这些软件又各有侧重，有的强调多功能性，会强化内容的分类，有的强调信息的重要性，会侧重信息流。

而在此之外，这些软件一般也都支持继续在因特网上通信。这样，但凡整个群体中有一人有信号，那么通过一个个的中继，因特网上的用户便可以看到那些原本没有信号的人所发出的信息。而且由于蓝牙的低功耗特性，蓝牙完全可以一直开启，这样随着人的流动，信息的传递范围会大幅增大。

该方案本质上就是以蓝牙为基础的ad hoc网络。没有东西是万能的，如果人群实在过于分散，无法形成有效的中继，那么该方案也无能为力。此时或许可以考虑无线网卡的ad hoc模式，逻辑原理和前述类似，但通过无线网卡而不是蓝牙模块，范围更大，但功耗也更大得多。然而绝大部分手机厂商都没有意愿去支持该功能，故而暂时难以大范围运用。

在此之外，其实还有另一种问题，那就是在没有那么严重但仍然信号中断的区域，导致目前的在线服务完全失效，包括但不限于在线支付，互联网叫车服务，共享单车类服务。其实这些服务完全可以做成不那么依赖网络通信，那么中心化的方式。其中一个例子就是央行正在推动的数字人民币——数字人民币设计的一个考量就是离线（无网络）使用，因而研究了区块连技术；而现在的在线支付服务依托的是所谓的「云」平台，要求完全联机使用。其他服务也完全可以考虑是否有更好的解决方案，但很可惜在市场经济下，它们现在的模式就是最稳定的。目前看来，必须要更强力来推动它们走向更好的模式。

信息的获取与筛选

在灾难下，假消息当然很令人生厌，但限制消息传播也不是办法，尤其伤害正在受灾的人——必然会有受灾之人完全没有被注意到的情况。但除了走两个极端外，我们完全可以选择第三条道路：不干涉现有信息传播渠道，但在其旁加入一个更好用的平台，而且允许/推动现有渠道支持调取该平台中的信息；同时推动人们在该平台中发布、整理、追踪、验证、更新这些消息，不论是一手的信息还是二手/代理的信息。

这一方案在本次救灾中有一个自发的现实例子：郑州一些人使用了一个共享在线表格，登记求助信息，增加帮助提供信息，整理互助手册，等等等等。但这只是临时的方案，本身也有绕不过去的问题。更好的方法则是建立专门的平台，并融入已有的服务中。

这个平台功能不复杂而且也不应该复杂，因为只是为了灾难救助信息发布，完全可以由大型公益组织开发或由政府牵头成立——政府牵头成立的一个潜在好处是政府行事更为稳健（更新动作缓慢），可以限制平台功能扩张的倾向，毕竟任何一个平台扩张过大最后既会带来不便，又会限制生产力发展。我会在另一篇文章中详细描述我对这样一个平台的设计，不在此赘述。其设计要点是需要增加信任度和信任链机制，且适当包装这些机制，使得用户不需要理解技术细节即可使用；用户发布信息不应该要求必须在此平台重新注册，要善用SSO；最好提供网页版，要是自适应的/响应式的（responsive），且最好支持PWA，这样无论是什么设备都可以便捷使用，不耽搁时间。

这样一个平台最主要的好处是不同的人可以根据自己的需求去筛选信息，并进行进一步行动。例如不在场的普通人去为其他人增加信息，或对已有信息进行补充或查重；在场或附近人员支持或否决信息真实性（同时接受对虚假/错误信息的系统内可信度惩罚）。这一方式的存在也可以解决或负责信息重要性的调度，避免杂乱信息影响——救援人员/支援人员只筛选实时有效信息，而过滤掉不确定的部分；在确定真实问题解决完毕后，追踪不确定部分。

当然，鉴于我国最大的两个同一公司的即时通信软件都设计成封闭花园（是花园还是其他什么见仁见智），均不支持在聊天记录中提供网页概览等，这样一个平台的设计也不得不考虑这一现实。有两个方向：要么推动它们不要那么封闭，要么平台同时提供可在它们内便捷使用的方案。这就属于实现细节了，没必要在这里过多讨论。

信息数字化水平

在救援进行的时候，遇到这些问题只能逢山开路遇河搭桥，先让活动进行下去。但在事情已经基本解决的现在，我们回看会发现，其中有些问题完全可以通过改进政府/企业信息的数字化程度来解决。

一些人对「数字化」究竟可以做到什么程度没有多少概念，或者对信息公开究竟要公开什么信息有所误解。我们国内最常见的模式就是：建个网站/公众号，描述一下组织架构，定期发发领导新闻或机构动态，或者是发公文的时候同时在网站上也发一份并且附件加上原文/扫描件。这些算不算数字化，算不算信息公开呢？

算，但不太算。

为什么？因为这些信息对大部分都是只对上级、平级或雇员有用，但对人民群众用处不大。一些先进一些的，会考虑开通微博等自媒体，增大面向人民群众的网络服务。但即使这样，他们还是没有解决一个重要问题：这些信息都只是人类可读，而完全没有机器可读性。

为什么这些重要？这里举两个例子说明：气象站（河南省气象局）和供电局（国网河南省电力公司）。

河南省气象局的网站打开之后，映入眼帘的就是大量的机关新闻、党组织教育信息。而人民群众打开他们网站要看什么信息？至少我扪心自问，主要会是气象信息/预警、行政工作查询和联系方式这些类别。那么这些信息在哪？最近的是气象信息：首先向下滚动631像素，超过大多数人电脑屏幕竖向（1080）的一半；然后看向网页的右侧，只占了244/1200≈20%的横向内容空间。行政工作查询和联系方式则要再向下滚动。而作为一个算是掌握了一些信息技术的人，我如果想要提供一个带地图的河南省气象预警服务（比如微信公众号），或是调取气象数据做一些后续整理（如分析天气预报和后续实际天气的偏差程度），则完全找不到API在哪里，该去哪里读取数据。这样，我们作为人民群众如果想要这些服务，要么没有这些服务，要么只能等待他们自己开发——而且我们知道，他们开发的那些效果一般比较有限，往往不能完全满足我们的需求。

国网河南省电力公司的网站信息比气象局的网站信息更少，基本上只有企业基本信息和联系方式，然后就是新闻报道。而我作为普通居民，最关心的当然不是企业的领导是谁，而是供电和线路故障信息。关注这些信息一是在自家停电后希望获悉是否已在维修以及预计何时可以修复；二是如本次水患情况下，希望关注哪些地方出现了线路故障，尤其是会否有触电风险。当然，一条条看这些信息要消耗许多时间，所以自然会想到要开发/使用一个对此整理好的服务，可以更便捷地查询。而纵观整个网站，完全没有这些方面的信息。仅有的可能性要么是人工服务，要么是使用它们的微信服务号，然后再跳转到他们的专有app。而这些，像前面一样，是否真的以用户为中心，则可以从苹果App Store上的用户评论窥知一二。至少我无法理解想要查询线路故障信息，为什么一定要注册账号。

上面只是举了单功能服务，但实际上，如果每个相关方的信息数字化完善，完全可以开发一个整合的全功能「故障灾害警报」服务/平台，整合气象、交通、电力等多方面的故障和灾害信息。然而这一理论上行得通的方案，在现实中卡在了相关政府部门或国企的数字化程度上。

而如果有这样的平台，本次灾害下就可以减少许多虚假的或过时的电力等险情信息。类似地，也可以实时获知道路通畅与否、物资仓储是否足够、哪里最需要增援等情况，而不需要一遍遍在不同微信群等群聊中询问，最后发现消息过时。

其他障碍

面对上面这三大问题，我提出了相应的数字化解法。但这些都是理论上可行的方案，最终落地还需要和现有的技术相结合。

开发这些项目不复杂也不困难，但如何将其整合到已有的工具（如微信）上则是一个难题——问题不在这些新项目上，也不在缺少工具或方法上，而是在微信等已有平台上。

最自然和便捷的使用这些新工具的方法，自然是在分享相应信息（如URL/网址）给其他人时，其他人方面自动展示信息的梗概，并且在打开URL时访问相应服务。一种很顺理成章的方案就是在收到URL后，聊天工具自动获取该URL对应网页的头部信息，并且附加在URL消息之下（如下图所示）。然后在打开URL时，要么按系统上已注册规则自动跳转到对应应用程序/app上，要么转到浏览器打开网页。

然而微信等程序不支持这种展示网页预览信息的方式，且丝毫没有打算这么做。在微信上，类似的功能需要通过一套复杂的流程完成：发送URL，在微信中用微信内置浏览器打开URL，点击菜单，重新点击分享，再发送出去。另一种方式是使用专有的「小程序」等做法来压过通用的以HTTP协议为基础的网站——然而本质上只是重新发明轮子而已，且将生产轮子的授权牢牢控制在腾讯手中。 而且微信还强制使用内置浏览器打开任何发送的URL，需要额外的步骤才能使用系统的浏览器调用。这种商业伎俩任谁都能看破，本文不讨论它。但它带来的后果则是该网站被迫只能选择微信登录或帐号密码（含手机验证码）登录，因为网站不能跳转到其他app的登录调用上，哪怕是对腾讯自家的QQ也一样；这样的做法，也导致用户难以在聊天信息和网页间切换，影响从聊天中提取信息粘贴到网页中。这样，会影响用户的使用热情，很可能会导致一些本来可以更新的信息没有更新，最终导致灾害救助的延误。

虽然前面主要讨论了微信，但国内几大平台其实均是如此，且小平台也未必不是如此。这需要整个行业风气的调整，不是一朝一夕之功，也不是靠用户呼吁呼吁可以解决的问题——没有足够的代价，他们不会愿意改变。

我能呼吁的，也只能是在已有这些之外，同时使用其他的更好的平台。不需要一次性迁移。

总结

本文从我自己在本次家乡水灾救灾中看到的一些现象出发，考虑其在（信息）技术层面的问题，对造成这些现象的原因进行了分类。然后对所分成的三个类别分别讨论，提出了对应的数字化技术方法，以便解决或改进该方面的服务，消除或降低下一次灾害中再次遇到类似的状况的可能性。最后，本文联系工具现实，讨论了实现这些改进会遇到的现实障碍，并指出这些障碍的原因以及解决方法。

我希望，这篇文章可以启发一些讨论，最好可以推动改进。当然，本文也可能有未能预计到或轻视的问题，导致所提出的技术解法可能无效。如果有此类问题，欢迎进一步讨论。