硬體眾籌，參差不齊的起點

當這個專案從「需求」走到「實作」的階段時，我們面臨的第一個現實問題，就是硬體來源。

所有設備都是透過志工與善心人士眾籌而來的。這聽起來溫暖，但也代表一件事：硬體規格完全不一致。

• 診間裡的叫號設備
• 診間外的顯示設備
• 大廳的電視設備
• 閉環網路所使用的機器
• 系統主機

它們雖然都掛著「安卓系統」的名字，但實際版本卻從 Android 5.0 到 14.0 不等，甚至還混雜著一些 toybox 型態的嵌入式安卓系統。對我來說，這是一場惡夢：沒有一份完整的規格文件，唯一能參考的只有一張「報價單」。

很多時候，必須靠志工在現場拍照，或者錄下使用效果，回傳給我做分析。這些「照片」與「片段影像」成了我設計與除錯的依據。

使用方式的意外挑戰

當地人的使用習慣也出乎我意料。他們會把電視立起來使用，像手機一樣直立，但這些設備大多數都 沒有陀螺儀。這意味著系統無法自動旋轉畫面。

那怎麼辦？最後的解法是 「用畫的」。我透過 CSS 的重新繪製 (repaint)，把原始畫面旋轉 90 度，硬生生模擬出直立的顯示效果。這是一種「妥協」的解法，但在資源有限的場域裡，能運作就是勝利。

這也是我在這個專案裡學到的第一課：不要期待完美的硬體支援，而是要思考怎麼用現有的條件，找到一個能走下去的解答。

借鏡台灣，卻無法直接套用

在開發這套系統之前，我訪談了許多台灣的醫療院所，甚至包含大型醫療集團。他們對叫號系統的需求往往很簡單：

• 在診間外顯示螢幕
• 醫師或護理師按下一個「NEXT」鍵
• 螢幕上顯示下一位病患的名字

就這樣而已。

但是，當這套邏輯搬到菲律賓的義診中心時，馬上就卡住了。因為這裡的患者很多是 眼科病患，代表有可能出現：

• 色盲
• 低視力或完全看不清楚

如果只是單純顯示名字，很多人根本無法辨識。於是我們必須重新設計：

1. 高對比畫面 —— 背景與字體之間必須有強烈對比，避免色弱患者看不清楚。
2. 清晰語音播報 —— 不只是顯示，而是要有大聲、清楚的語音。
3. 提示音 + 顏色 + 數字 —— 在語音廣播前，必須加一個提示音，讓現場所有人注意到，接著才讀出顏色與號碼。
4. 緊急訊息插播 —— 在面板上預留一個空間，能隨時推播緊急訊息。

這些都是在台灣的醫院裡不太會被考慮到的細節，但在義診現場卻是必須。

後台到前端的串接

系統的流程是這樣運作的：

1. 現場註冊完成後，資料會被送到後台。
2. 後台再把等待名單分配到各診間。
3. 診間內的叫號設備能看到「有多少人在等待」。
4. 當醫生或護理師準備好時，就能透過系統叫下一位進來。

這看似簡單，但在高人流的情況下，效能與即時性成為關鍵。

我們採用了 WebSocket + MQTT 雙軌架構：

• WebSocket 處理即時的使用者互動。
• MQTT 負責大規模的訊息傳遞，確保訊息不會遺失。

這樣的設計，讓系統能夠應對義診現場幾百人同時等待的狀況。

多語言語音的挑戰

另一個大挑戰是語音。義診現場需要 Tagalog + 英文 的雙語叫號，對某些年長者而言，還必須用到中文輔助。

我們設計了一個「組裝式」語音系統：

• 管理員可以在後台直接選擇「顏色」，或輸入要生成的文字。
• 系統會連線到外部 API（如 Google Speech API、Google Translate）生成語音檔案。
• 生成後的語音檔會下載回來，再用 ffmpeg 做後製，放大音量，確保廣播能清楚被聽見。
• 最後，這些語音會透過擴音設備播放，讓大廳裡的每個人都能聽清楚。

這套流程，聽起來繁瑣，但每一個細節都與「使用者體驗」緊緊相扣。

AI 與 RAG 在系統開發中的角色

很多人會問：這樣的系統，是不是 AI 幫忙做的？

答案是：是，也不是。

• 不是：AI 沒有幫我一次生成整套系統。
• 是：AI 在過程中扮演了非常關鍵的角色。

整個架構的思考方式，很多是透過 RAG 型態的對話去反覆驗證的。比如：

• 我把現場的照片、截圖丟給 AI，請它幫我分析可能的使用者體驗問題。
• 我針對不同模組（語音、畫面旋轉、擴音設備串接、後端通訊）各自開不同的 session，請 AI 提出可能的解法。
• 再把這些零散的建議，透過人類的規劃與整合，拼湊成一個可以真正落地的架構。

這過程讓我更清楚：AI 不是不能做大系統，而是需要縝密的規劃與拆解。
如果能把專案分成一個一個小模組，AI 就能提供很大的助力。

換句話說，這套系統並不是「AI 一次生成的成果」，而是「人類判斷 + AI 輔助 + 實際測試」共同完成的。

使用者體驗的核心思考

這個專案用到的技術橫跨了多個層面：

• 前端：AJAX + Bootstrap + ES5，確保在舊版瀏覽器或低規格設備上也能跑。
• 後端：Python Flask，搭配 SQL 與 NoSQL 資料庫，處理不同結構的資料。
• 通訊：WebSocket + MQTT，雙層確保即時性與穩定性。
• 語音：Google Speech API、Google Translate、ffmpeg。
• 系統支援：從 Android 5.0 到 14.0，甚至到更舊的嵌入式系統。

但這些技術的目的，最終都落在「使用者體驗」上：

• RWD：不同螢幕尺寸都能清楚呈現。
• SPA：減少切換頁面的等待時間。
• PWA：在常態停電或斷網的環境中，依然能繼續使用。
• SSR：讓低階硬體也能快速載入，避免患者和志工等太久。

換句話說，這不是技術炫技，而是為了讓現場的每一個人都能真正用得上。

結語

回顧這段開發過程，我覺得它像是一場馬拉松。沒有哪一個環節是輕鬆的，每一個挑戰都可能讓系統無法運作。但正因為這樣，我們才不斷被提醒：這不是單純的技術專案，而是一個與現場共生的系統。

硬體規格不一？就用 CSS 重繪。
廣播音量不足？就接上擴音設備。
語音不清楚？就加提示音、放大音量。
患者看不清楚？就用高對比設計。

所有的答案，都不是「最完美」的，而是「最適合當下的」。

這個案子到現在仍然在持續進行中，每一次改動都還在累積。
而我最深的體會是：AI 可以是一位強大的協作者，但唯有人，才能讓系統最終落地並被信任。