一個巷號先被寫進了通報：芭東的淹水資訊，是一頁被排過的介面

回顧 2026 年 10 月 26 日至 28 日，泰國普吉島接連受豪雨與土石流影響。普吉府公關部門 26 日通報，暴雨造成全府三個行政區積水、山洪與土石流，芭東 Na Nai 5 巷與 8 巷有泥沙、石塊與雜物阻路，約百戶居民與業者受影響；28 日再降大雨，MGR Online 報導 Na Nai 8 再有山洪挾帶泥石湧入，芭東市府安排接駁，讓 Na Nai 5、8 巷有需要的居民前往 Wat Suwan Khiri Wong 避難。隔日 JS100 的交通通報又記錄 Na Nai 3 巷口因土石滑落封路。

先從一個小細節看起：Na Nai 這個名字，配上 3、5、8 這幾個巷號。對當地人來說，「Soi Na Nai 8」是一條有麵攤、有民宿、有坡度的具體街道；對遠方的旅客來說，它是一組必須被翻譯的座標。整場災情的可讀性，就建立在這幾個數字能不能被準確傳遞上。

巷號是這場災情的字級

災害通報裡最容易被讀漏的，往往是這種「最小單位的地址」。26 日的受損範圍寫的是 Na Nai 5、8 巷，28 日的山洪寫的是 Na Nai 8，29 日的封路寫的是 Na Nai 3 巷口。同一片區域，三天內出現了三組不同的巷號。若只看其中一天的「已恢復通車」，很可能漏掉隔天另一條巷子又封了。

這正是這類資訊的設計難處：路況的時間性遠高於一般旅遊資訊，但大多數旅客讀到的是被轉傳數次的靜態截圖。來源整理者特別註明「本文所列封路與撤離資料為 10 月 28 日至 29 日通報，並非即時路況」，這一行免責聲明，其實是整份資訊裡最誠實的設計：它替讀者標出了資料的儲存期限。

這與我們先前觀察的義大利旅遊警示的顏色與城市排序屬於同一課題：官方如何把一組變動中的風險，排成旅客一眼能判讀的層級。

一通電話與三個地名

泰國政府公告裡有幾個可指認的設計動作。第一個是 24 小時地方防災電話 076 342 600，並附上從海外撥打的格式 +66 76 342 600。同一組號碼寫兩次、換一次國碼，這個看似冗餘的細節，是給身在機場或旅館、正要撥號的旅客用的。第二個是三處支援與收容地點：芭東市府、Wat Suwan Khiri Wong School、Patong Bay Hill Hotel。市府是行政單位，學校是既有避難所，飯店則把「收容」這個生硬的詞，接回了旅客本來就認得的地圖。

公告同時提醒實際開放情形仍要向地方單位確認。避難地點的清單可以預先排好，開放與否卻是即時的，這也是為什麼電話與地點必須成對出現：清單負責「在哪裡」，電話負責「現在能不能去」。

從資訊分層看，這套通報把「道路、避難、求助」三件事各自綁上了不同的載體：巷號綁在交通通報，地點綁在政府公告，電話兩邊都出現。讀者不需要理解普吉府的行政架構，只需要沿著自己眼前的問題找到對應的那一行。

前一天的「恢復」不可靠

來源裡有一個反覆出現的提醒：不要開車或步行穿越湍流，遇到封路、積水或落石告示就改道，出門前先向飯店或接送業者確認路線。這段話的設計邏輯，是把最後一哩的判斷交還給現場的人。官方通報能標出封了哪條巷，卻標不出你腳下那攤水的深度。

與颱風路徑預報圖那種億萬人共看的決策介面相比，這裡的介面規模小得多，但結構相似：預報圖上的線條與圓錐提供的是不確定區間，芭東的巷號通報提供的也是一樣的東西。它不是一張完成的地圖，是一張標了「到此為止是 10 月 29 日」的快照。

收束來看，這場淹水留給設計觀察的一課很簡單：災害資訊的可讀性，取決於最小地址單位有沒有被寫清楚、時間戳記有沒有被標上、以及一組電話號碼有沒有被寫成可以立刻撥出去的樣子。巷號會變、封路會變，把「這份資料是幾點的」跟著巷號一起排出來，才是旅客真正用得到的那一頁。