閃人測試 — 如果開發團隊明天消失，你的系統還能活嗎？

一個不舒服的問題

軟體業有個殘酷的思想實驗叫 Bus Test（公車測試）：如果你的核心工程師明天被公車撞了，專案還能活嗎？

大多數團隊不敢認真回答。密碼在某人腦袋裡，部署流程只有一個人會跑，資料庫只有創辦人有權限。在一般 SaaS 產品，這頂多意味著停機幾天、客戶抱怨、工程師加班。

但如果你的軟體跑在災難現場呢？

當一台 Raspberry Pi 扛著整間野戰醫院的病歷、庫存、輸血紀錄，而最近的網路基地台在 50 公里外——這時候 Bus Test 的答案關乎人命。

Bus Test 通常是拿來嚇人的。大家點點頭，說「對，我們應該寫文件」，然後什麼也沒做。

我們決定把它變成正式的驗收標準。不叫 Bus Test——叫 Walkaway Test（閃人測試）。名字刻意選得輕鬆，但內容很認真：五項檢驗，每一項都必須通過，系統才算合格。

網路斷了，系統能不能繼續跑？

這是最基本的。聽起來簡單，但絕大多數現代軟體做不到。你的 EHR 系統試試看拔掉網路線？

xGrid 的答案：15 個以上的 PWA（護理站、藥局、手術室、血庫……）全部離線運作。Service Worker 快取 + IndexedDB 本地儲存。斷網不是異常狀態，斷網是預設狀態。

中央伺服器炸了，邊緣裝置能不能重建它？

這才是真正的硬題。多數系統的架構是「中央是真理來源，邊緣是快取」。中央死了，邊緣手上的資料就變成孤兒。

xGrid 的做法是反過來的：每一台邊緣裝置都攜帶著重建中央的能力。我們叫它 Lifeboat Protocol（救生艇協議）：

像海星斷了一隻腳長回來。不需要備份磁帶，不需要 IT 部門，不需要打電話給任何人。

2026 年 1 月 26 日，我們跑完 12 步驟的驗證測試。100% 通過。

現場人員不懂技術，能不能自己操作？

這題考驗的不是技術，是設計。災難現場的操作者是護理師、醫師、後勤人員——不是工程師。如果系統需要有人 SSH 進去重啟服務、手動跑 migration、看 log 排錯，那就不及格。

xGrid 的所有操作都透過 PWA 介面完成。沒有終端機，沒有命令列，沒有「請聯繫 IT 部門」。

沒有 license server，系統會不會鎖死？

這是很多商業軟體的致命弱點。公司倒了、合約到期了、license server 連不上了——軟體直接變磚。在災難現場，這等於殺人。

xGrid 沒有 license call-home。部署之後，它就是你的。沒有訂閱制，沒有到期日，沒有「請續約」的彈窗。

不靠程式，人工能不能驗證資料完整性？

最後一道防線：如果連軟體本身都不信任了呢？xGrid 的資料結構設計成可以人工稽核的格式。SQLite 資料庫可以用任何工具打開檢視。每一筆紀錄都有時間戳和操作者。不需要專屬軟體才能讀自己的資料。

五項全數通過後，我們在內部寫下一句話：

Bus factor approaching infinity.

這句話的意思是：就算整間公司明天不存在了，已經部署到前線的系統，明天、下個月、明年，都還能繼續運作。

Walkaway Test 表面上在測試軟體架構，但它真正測試的是一個更深層的問題：你的系統是為誰設計的？

如果答案是「為了我們公司的營收」，那你會設計 license lock-in、雲端依賴、年度訂閱。如果答案是「為了使用者在最極端的情況下還能完成任務」，那你會設計出通過 Walkaway Test 的東西。

我們選了後者。

不需要重寫你的整個系統。從三個問題開始：

Walkaway Test 不是一個一次性的檢查表。它是一個設計哲學：每一個架構決策都應該讓使用者更不需要你。

聽起來很矛盾——為什麼要讓客戶不需要你？因為在災難醫療的場景裡，「需要你但聯繫不上你」等於零。而「不需要你但你還在」才是真正的信任基礎。