錯誤訊息承擔兩個職責：讓使用者理解發生了什麼（診斷），以及讓使用者知道下一步能做什麼（行動）。缺少診斷的訊息讓使用者焦慮（「出了什麼事？」），缺少行動的訊息讓使用者卡住（「然後呢？」）。

診斷：使用者能讀懂

用使用者的語言描述問題

錯誤訊息的讀者是使用者，描述問題時使用使用者能理解的詞彙。「無法連線到伺服器」比 ECONNREFUSED 127.0.0.1:7681 更有用。技術細節對開發者有價值，但使用者需要的是「發生了什麼影響我」。

技術細節可以保留在次要位置 — 折疊區塊、「詳細資訊」連結、或複製到剪貼簿的按鈕。進階使用者和開發者在需要時能取得，一般使用者不被打擾。

描述影響而非原因

使用者關心的是「這對我意味著什麼」。「終端機暫時無法使用」比「WebSocket 連線逾時」更直接回答使用者的問題。原因是補充資訊，影響是核心資訊。

避免技術恐嚇

「嚴重錯誤」「系統崩潰」「未知的致命例外」這類措辭讓使用者以為問題很嚴重。多數情況下使用者能做的就是重試或返回 — 訊息的語氣應該反映實際的嚴重程度。

行動：使用者能做什麼

明確列出可執行的下一步

每個錯誤訊息至少提供一個使用者可以執行的行動。重試、返回上一頁、檢查網路連線、聯繫支援 — 行動越具體越好。

「發生錯誤」沒有行動指引。「連線失敗，請檢查網路後重試」提供了兩個具體行動（檢查網路、重試）。

行動要可操作

「請聯繫系統管理員」在自用工具場景中沒有意義（使用者就是管理員）。「請稍後再試」在服務完全不可用時也沒有幫助。行動建議需要考慮使用者的實際情境和能力。

提供退出路徑

行動選項中至少有一個是「離開當前狀態」的退出路徑 — 返回首頁、關閉對話框、取消操作。使用者可能不想重試，只想離開。畫面狀態矩陣中退出路徑為空的狀態就是 UX 死胡同（ux-design 模組一 畫面狀態機）。

錯誤訊息的三層結構

一個完整的錯誤訊息包含三層：

標題：一句話描述影響。「終端機連線失敗」。

說明：補充原因和 context。「伺服器沒有回應，可能是網路問題或伺服器未啟動。」

行動：按鈕或連結。「重試」「返回首頁」「查看詳細資訊」。

三層不需要都顯示。輕微錯誤（Snackbar）可以只有標題 + 一個行動按鈕。嚴重錯誤（全螢幕）三層都需要。

錯誤訊息寫完後，使用者看到訊息的下一步通常是重試 — Retry 機制 UX 設計重試按鈕的行為和回饋。如果重試反覆失敗，使用者需要退路而非重試迴圈，error → retry → error 循環的逃生口提供逃生設計。Error 狀態在畫面層級的定位和退出路徑回到 ux-design 模組一 畫面狀態機的矩陣框架。