為什麼機器人在錯誤時間問候會打破真實感的幻象
帶有時間性的問候看似只是微不足道的客套，但它同時也提出了一個事實陳述：系統知道對話發生地的時間。如果它在深夜說「早安」，這種不一致會讓整個互動顯得生硬機械或不可靠。實際的解決方法是：任何時間參照都必須基於當前的時間戳記與明確的時區、保持問候與其他地方顯示的時間一致，並針對邊界情況進行測試。如果缺乏這些上下文資訊，一句簡單的「你好」遠比胡亂猜測對方的早晨更值得信賴。
為什麼錯誤的時間感受上不僅僅是措辭失誤
像「早安」這樣的問候是一種社交線索，但它也傳達了資訊。使用者可以將它與同一螢幕上的時鐘或當地的實際時間進行比對。當兩者產生衝突時，這種不一致會立即顯現，並可能讓問候顯得刻板機械。這是根據可觀察到的矛盾所做出的設計推論，並不代表每位使用者的反應都會完全相同。
針對對話型代理人的研究顯示，錯誤會影響人們對代理人的看法，儘管不同類型的錯誤產生的影響有所不同。在一項針對具身對話代理人的研究中，輪流發言的錯誤降低了討喜度，而某些連貫性錯誤則產生了不同的影響。這項研究帶來有價值的啟示並不是說錯誤時間的問候一定會引發特定反應，而是互動錯誤所形塑的印象往往會超出當下內容本身。Adobe Research，《Conversational Error Analysis in Human-Agent Interaction》
帶有時間的問候還可能暗示系統擁有一些它實際上並不具備的認知。知道當前的時鐘時間，並不等於知道使用者何時起床、正在做什麼，或是他們將一天中的哪段時間視為「早晨」。可靠的計時能支援準確的用詞，但並不能建立起個人的理解。
從時間戳記和已知的時區開始
請將當前時間與使用者的當地時區視為兩個獨立的輸入項。時間戳記識別的是時間軸上的一個點；時區則提供了將該瞬間表示為當地時鐘時間所需的規則。W3C 的指南區分了這些時間表示方式，並解釋時區包含時區偏差與日光節約時間變化的規則。指南建議在需要計算當地時間時使用時區識別碼。W3C，《Working with Time and Timezones》
對於由軟體產生的問候，一個健全的流程應該是：
從系統時鐘或其他受信任的時間來源獲取當前瞬間。
獲取已知代表目標使用者或對話上下文的時區設定。
使用支援時區的格式化工具將該瞬間轉換為該時區的時間。
根據轉換後的當地時間選擇問候語，若上下文資訊不可用或已過期，則省略時間參照。
在 JavaScript 中，Intl.DateTimeFormat 接受用於格式化日期的 timeZone 選項。如果應用程式省略該選項，則會使用主機環境的當前時區，而這可能是伺服器或裝置的時區，而非使用者的時區。格式化工具也可以從同一個瞬間產生介面上顯示的時間與日期。MDN，《Intl.DateTimeFormat》
僅靠數值偏差可能不足以應對未來或重複發生的時間行為。像 Europe/London 這樣的命名時區代表了一組區域規則；其偏差可能會隨日期而變化。IANA 解釋其時區資料庫會持續更新，以反映邊界、UTC 偏差與日光節約時間規則的變化。因此，軟體既依賴於合適的時區，也依賴於合理最新的時區資料。IANA，《Time Zones》
讓問候與可見的時鐘共用同一個來源
問候語和螢幕上的時鐘應衍生自相同的時間戳記與相同的時區上下文。如果一個元件使用瀏覽器的本地時區，而另一個元件使用伺服器的預設值，那麼在午夜前後或使用者旅行時，它們之間可能會產生分歧。如果介面顯示日期，請連同問候語一起檢查：本地日期可能與伺服器所在位置的日期不同。
一個實用的實作規則是：為對話事件計算一次當地時間，並將該結果同時傳遞給問候邏輯與顯示介面。避免另外要求語言模型從對話文字、裝置上下文或記住的日程表中去推斷時間。模型可以根據已驗證的值來選擇措辭，但時鐘的計算應該來自時間資料。
如果使用者尚未提供時區，且產品沒有可靠的本地設定，請避免指稱一天中的特定時段。「你好」在各個時區和時間下都保持準確。如果某項工作必須使用明確的時區，請以清晰、低阻力的方式詢問，而不要暗中將伺服器的時區當作使用者的時區。
深思熟慮地選擇問候的時間區間
早晨、下午和傍晚之間並不存在普遍且客觀的界限。團隊應該將當地時間的範圍界定視為產品措辭的選擇，然後驗證所選的措辭是否符合預期的語氣。在設定檔或程式碼中明確保留這些範圍，以便審查人員可以清楚看到每個邊界上會發生什麼。除非使用者確實提供了相關資訊且切合當下情境，否則請避免使用暗示了解其生活作息的措辭，例如「你今天起得真早」。
安全的備用方案應成為設計的一部分。如果時間戳記無效、時區識別碼缺失或無法辨識，或是轉換失敗，請使用中性的問候。不要在未明確說明該選擇的情況下逕自替換為伺服器時鐘。如果時鐘讀取可能發生延遲，一句通用的「你好」也比在訊息等待顯示期間就變得不合時宜的問候更能經得起時間的考驗。
測試時間轉換與上下文，而不僅僅是一般的午後
在平常的當地時間進行正常路徑測試（happy-path test）無法發現許多時間上的缺陷。請使用固定的時間戳記與明確的時區，以確保結果具可重複性，並檢查以下情況：
緊接在每個問候邊界前後的時間。
當地午夜，包括本地顯示與伺服器之間的日期更迭。
在同一瞬間具有不同本地日期的兩個時區。
在實施日光節約時間的時區中的切換瞬間。
偏差為半小時或四十五分鐘的時區。
時區缺失或無效的情況，此時預期結果應為中性問候。
延遲發送的訊息，檢查其措辭是基於產生時間還是顯示時間——以及該選擇是否與產品的行為保持一致。
這些案例源自時區如何將瞬間對應至當地時鐘時間，以及各區域時鐘規則可能會發生變化的事實。測試套件應該讓選定的行為清晰可見，而不是依賴隱式的機器預設值。IANA 的版本歷程記錄記載了實際的規則變更，這提醒了我們測試環境與已部署的時區資料都可能會過期。IANA，《Time Zone Database Releases》
給產品團隊的實用決策準則
只有在具備三項要素時才使用特定時間的問候：值得信賴的當前瞬間、與對話上下文關聯的時區，以及問候與任何可見時鐘之間一致的格式化。如果任何一項元素不確定，請選擇中性的措辭。如果系統只知道時間，它可以準確地提及當前時段；但不應暗示它知道個人的日程、心情或正在進行的活動。
單靠問候語本身無法讓助理顯得體貼周到。它的價值取決於它所做出的細微陳述是否與介面的其餘部分相符。準確且克制的措辭能為互動提供一個協調一致的起點，同時將個人化的脈絡留給真正能夠提供它的人。