最近我又被一個看起來很小的問題提醒：儀表板上的狀態訊息，不能只當成文案處理。尤其是那些會影響判斷、風險意識和下一步動作的提示，它其實是系統對人的承諾。
很多後台系統或決策儀表板，都會有一塊「目前狀態」：資料是否正常、風險是高是低、流程能不能往下走、建議現在該等還是該做。這些訊息通常只佔畫面一小角，開發時也很容易被歸到最後才修的 UI 細節。但我越來越覺得，這種文字其實很核心，因為它是系統把內部狀態翻譯給人看的最後一道介面。
麻煩的是，系統內部狀態通常比一句話複雜得多。資料可能有進來，但市場條件還不成熟；候選項目可能足夠，但風險模型仍在觀望；流程可能沒有壞，只是策略上不該繼續。這些狀態如果全部被壓成一句「資料不足」或「暫不建議」，表面上好像也沒錯，實際上卻會讓使用者往錯的方向排查。
「資料不足」跟「資料足夠但訊號不明確」是完全不同的事。
前者代表資料管線、來源、同步、權限或查詢可能有問題；後者代表系統看到了資料，但根據目前規則選擇保守。對技術主管來說，這兩個狀態背後的處理方式完全不同。資料不足要查 ETL、API、排程、快取和連線；訊號不明確則要檢查規則、門檻、權重與使用情境。如果系統把後者講成前者，就等於把使用者導向錯誤的故障假設。
這也是為什麼我不太喜歡「先給一個泛用 fallback 文案」的做法。Fallback 當然需要，系統不可能每個邊界狀態都一開始就設計完美。但 fallback 如果太像結論，就會變成假訊號。使用者看到「資料不足」，自然會以為資料真的不足；看到「系統異常」，自然會以為工程端壞了；看到「低風險」，也可能誤以為模型已經完整評估過所有因素。
狀態訊息最重要的不是漂亮，而是可定位。
我會希望它至少回答三件事。第一，系統現在看到什麼。不是把所有欄位列出來，而是交代關鍵前提，例如資料來源正常、候選項目已取得、最新時間點為何。第二，系統為什麼做出目前判斷。是因為規則門檻未達、趨勢不明、風險過高，還是因為真的缺資料。第三，人下一步該怎麼做。是等待訊號、補資料、重跑排程、調整條件，還是暫時不要動。
這三件事講清楚，使用者就不需要猜系統心裡在想什麼。
從工程設計看，這其實要求我們不要只把狀態當 enum。例如 GREEN、AMBER、RED 本身是不夠的。顏色只是摘要，真正有價值的是狀態原因。AMBER 可以是資料不足，可以是資料延遲，可以是訊號未確認，也可以是風險偏高但尚未失控。這些都叫 AMBER，但人的反應不該一樣。
比較好的做法，是把狀態拆成幾層：健康狀態、資料完整度、策略判斷、建議動作。健康狀態回答系統有沒有壞；資料完整度回答材料夠不夠；策略判斷回答目前規則怎麼看；建議動作回答使用者接下來該做什麼。UI 上不一定要全部攤開，但資料模型裡應該要分得開，否則最後一定會被迫用一句模糊文字包山包海。
這件事在 AI 系統裡更重要。因為 AI 或自動化儀表板常常會把資訊整理得很順，順到使用者降低警覺。如果文字看起來很肯定，大家就會自然相信它真的理解了狀態。可是很多時候，它只是把一個粗糙分支包裝成自然語言而已。這種「看起來懂」的介面，比直接報錯更危險。
我現在看這類系統，會把狀態訊息當成一種小型契約。它不是裝飾，也不是客服語氣，而是在承諾：我看到了哪些事、沒看到哪些事、為什麼現在這樣判斷、你不該誤會成什麼。
好的狀態訊息會讓人放心，不是因為它永遠報喜，而是因為它能誠實描述不確定性。資料不足就說資料不足；資料夠但條件未成熟，就說正在等待訊號；系統壞了就明確標出哪一段壞；如果只是保守策略，也不要偽裝成故障。
工程上很多信任感，都是從這種小地方累積起來的。按鈕、提示、狀態燈、警告文字，看起來都不是架構核心，但它們是人理解系統的入口。入口講錯，後面再準也很難被正確使用。
所以我給自己的提醒是：下次看到一句「暫無資料」或「目前不建議」時，不要只問文案順不順。要問它到底對應哪個狀態、會不會讓人誤判、能不能幫忙定位下一步。
狀態訊息不是文案，是系統對人的承諾。承諾如果講得模糊，信任就會從那裡開始漏水。