給一份虛構的美國設備租賃單寫上“11/12/2026”，再讓 AI 翻譯成中文。若原意是十一月十二日，譯成十二月十一日便改變了交貨日期。兩個日期都有效，普通格式檢查未必發現問題。本文用這個合成例子，討論跨語言交接，而非報告客戶事故。

遇到斜線日期，保留原始字串與來源欄位的格式說明。格式沒有明確約定時，向提交者確認月份和日期，不讓模型根據中文或英文語氣猜測。確認後分別儲存已核實的日期和原文；翻譯可以改變表達，不能代替事實確認。

MDN 說明，HTML 日期輸入控制項的顯示會隨瀏覽器語言環境變化，而實際值採用 yyyy-mm-dd。 因此審核單可寫“2026 年 11 月 12 日”與“November 12, 2026”，介面儲存“2026-11-12”。這些表示應指向同一天，不能靠螢幕截圖判斷實際提交值。

交貨日期可能只表達日曆上的一天。RFC 3339 把 full-date 與包含時間與時區偏移量的 date-time 分開定義。 不要為了配合欄位格式，擅自給日期補上午夜 UTC，再按當地時區轉換。若業務確實需要交貨截止時刻，應另行確認時間與時區，而不是由 AI 創造。

我們的驗收建議包括：有歧義的斜線日期、明確寫出月份的日期，以及不存在的日期。用虛構資料走過輸入、翻譯、儲存和匯出，核對每一步的實際值。記錄哪些需要澄清、哪些應被拒絕；這是一份建議測試方案，本文未執行客戶系統測試。

在最終交接單並排顯示原文、確認後的年月日和目標欄位，註明誰確認了含義。只檢查中文是否通順，會漏掉業務事實的變化。團隊應把“日期仍待確認”當作可見狀態；寧可保留一個待答問題，也不要把模型流暢的猜測變成正式承諾。