给一份虚构的美国设备租赁单写上“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 创造。

我们的验收建议包括：可产生歧义的斜线日期、明确写出月份的日期，以及不存在的日期。用虚构资料走过输入、翻译、保存和导出，核对每一步的实际值。记录哪些需要澄清、哪些应被拒绝；这是一份建议测试方案，本文未执行客户系统测试。

在最终交接单并排显示原文、确认后的年月日和目标字段，注明谁确认了含义。只检查中文是否通顺，会漏掉业务事实的变化。团队应把“日期仍待确认”当作可见状态；宁可保留一个待答问题，也不要把模型流畅的猜测变成正式承诺。