模型抽取到 03/04/2026，怎样让日期歧义进入待确认而非猜一个

“03/04/2026”既可以表示三月四日，也可以表示四月三日。模型把它规范成某一天，并不等于原文提供了足够证据。日期抽取后的客户端应保留歧义，先枚举合法解释，再决定能否填写规范字段。

地区证据与格式候选分开

本文只允许年月日、月日年和日月年三种明确格式。原始字符串与来源地区分别保存，地区必须来自可靠文档上下文或用户确认，不能从用户界面语言猜测。没有地区证据时，对斜杠形式同时尝试两种格式；格式匹配后还要由日期库检查月份和天数是否成立。

样本“03/04/2026”产生两个不同日期，状态为 ambiguous，规范日期不可用。“13/04/2026”只有四月十三日合法，状态为 resolved；“31/02/2026”没有合法候选，状态为 invalid。多个格式解析出同一天时应先去重候选，不应因为解析路径有两条就误报歧义。

输出要解释为什么没有日期

歧义与非法不能都变成一个没有理由的空值。前者需要补充来源规则或人工选择，后者可能是原文写错或抽取失败。台账记录原字符串、候选集合、判定状态、来源证据和确认记录，便于后续处理。只有唯一候选才生成 ISO 形式的日期字段，不能把第一个成功格式当默认答案。

附件以纯 Python 日期运算枚举候选，不访问系统时区，不调用模型。它证明这三类输入按本文格式合同得到了不同状态。Structured Outputs 可以帮助规定这些字段形状，但不会替业务判断一个斜杠日期来自哪种地区习惯，不能把合法 JSON 当作确定日期。

人工确认也要留来路

用户明确说“这是日/月/年”后，可将对应候选提升为最终值，但应保留原歧义与确认来源。不要原地抹掉候选列表，让后续审查误以为结果从原文直接唯一可得。若确认内容与全部候选不符，应作为新证据重新检查，而不是强行套入旧格式。

失败反例是先试月日年，解析成功就返回。它对十三日这样的数据看起来没问题，对三月四日却会静默作出选择。测试集中必须有两个数字都不超过十二的样本，否则无法暴露这个缺陷。还应验证闰年、空字符串、非字符串和尾随时间，但日期与时间戳转换是不同任务，本文不替它们设默认时区。

在入库流程里，待确认记录应进入明确队列，不能用当天日期或月初日期填补。任何默认日期都可能影响合同期限和报表归属。本文只处理合成文本的日期解释，不提供法律期限计算，也不把其参考结果当作真实业务时间事实。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a013.json，离线检查器 a013.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a013.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。