喺一張虛構嘅美國設備租借單寫上「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 自己創造。

我哋建議嘅驗收包括：有歧義嘅斜線日期、清楚寫出月份嘅日期，同根本唔存在嘅日期。用虛構資料行過輸入、翻譯、儲存同匯出，每一步都核對實際值。記錄邊啲要澄清，邊啲應該拒絕；呢份係建議測試方案，本文冇執行客戶系統測試。

喺最後嘅交接單，並排顯示原文、確認咗嘅年月日，同目標欄位，亦要註明邊個確認咗意思。淨係檢查中文順唔順，會漏咗業務事實嘅改變。團隊應該將「日期仲等緊確認」當成睇得到嘅狀態；寧願留低一條未答嘅問題，都唔好將模型講得流暢嘅猜測，變成正式承諾。