前些天河南暴雨，超過歷史極值，導致數地遭遇災情。我身爲河南人，家鄉遭災，自然是十分揪心和關注。在收集、轉發、建議的循環中，我發現了一些本可以做得更好的地方，而這些只需要進行技術改進並輔以輕微相應培訓。我在自己力所能及的範圍儘量呼籲，但用處顯然不大。於是，在情況已經基本穩定的當下，我嘗試將其整理出來，期待將來可有改進。

前事不忘，後事之師。

另：本文亦發在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也一樣；這樣的做法，也導致用戶難以在聊天信息和網頁間切換，影響從聊天中提取信息粘貼到網頁中。這樣，會影響用戶的使用熱情，很可能會導致一些本來可以更新的信息沒有更新，最終導致災害救助的延誤。

雖然前面主要討論了微信，但國內幾大平臺其實均是如此，且小平臺也未必不是如此。這需要整個行業風氣的調整，不是一朝一夕之功，也不是靠用戶呼籲呼籲可以解決的問題——沒有足夠的代價，他們不會願意改變。

我能呼籲的，也只能是在已有這些之外，同時使用其他的更好的平臺。不需要一次性遷移。

總結

本文從我自己在本次家鄉水災救災中看到的一些現象出發，考慮其在（信息）技術層面的問題，對造成這些現象的原因進行了分類。然後對所分成的三個類別分別討論，提出了對應的數字化技術方法，以便解決或改進該方面的服務，消除或降低下一次災害中再次遇到類似的狀況的可能性。最後，本文聯繫工具現實，討論了實現這些改進會遇到的現實障礙，並指出這些障礙的原因以及解決方法。

我希望，這篇文章可以啓發一些討論，最好可以推動改進。當然，本文也可能有未能預計到或輕視的問題，導致所提出的技術解法可能無效。如果有此類問題，歡迎進一步討論。