一个看似简单的词也有参照物
设想客户深夜发来一句“明天下班前给我初稿”，销售第二天早上把消息转进 AI 工作流。如果系统以转发时间理解“明天”，任务就可能晚一天；如果按服务器所在时区处理，又可能和客户预期不同。这是演示情境，不是某个项目的事故记录。它说明时间解析不能只看句子，还要看是谁在什么时候说的。
很多流程把日期当成一个字符串，能识别出年月日就算成功。实际交付却需要更多信息：这个日期是客户期望、内部计划还是已确认承诺，是开始时间还是截止时间，到了时点应该提醒、停止还是继续。先回答这些问题，再讨论用什么模型提取时间，能减少一类很难在演示中发现的差错。
保存原话和解析结果两份信息
建议把原始表达、原消息时间、发送方已知时区、解析后的时间和确认状态分开保存。“周五之前”这样的原话不应被处理完就丢掉，后续有争议时需要回看。来源没有时区时，记录未知，不要让模型根据姓名、语言或电话区号猜。企业可以设置默认业务时区，但必须明确这是系统约定，而非客户已经确认的事实。
输出给员工的摘要应能看见关键解释，例如“暂按项目时区，将截止时间理解为某日营业结束，待客户确认”。涉及对外承诺或自动执行的任务，未知信息应进入补问或人工审核。对于只生成草稿的低风险环节，可以保留待确认标记继续处理，但不能把这个标记在下游转换时悄悄去掉。
工作日需要一份业务日历
“三个工作日内”不能简单等同于加三天，也不能只排除周末。公司服务时间、客户所在地和项目约定都可能影响计算。应由业务负责人指定使用哪份日历、从哪个事件起算、当日是否计入以及遇到非营业日如何处理。模型可以帮助识别时间表达，真正的日期运算适合交给确定性的程序和已确认的日历数据。
跨地区项目还要区分显示与存储。系统内部可以保留统一时刻，同时保留业务时区供展示和解释；不能只存一个丢失地区信息的本地时间。对于采用夏令时的地区，不应全年使用同一个固定偏移量替代时区规则。这里不需要给员工讲复杂术语，界面写出日期、时间和地区，再让他确认即可。 “月底前”还有一个业务细节：它有时表示交付承诺，有时只是客户表达的大致期望。系统不应把每个带日期的句子都升级成定时执行指令。可以在提取结果里同时标注用途，由负责人决定是否形成正式任务。历史聊天中讨论过的旧时间，也不能因为再次被检索到就自动激活；需要检查它是否已被后来消息替代。
如果一份材料有多个时间，先说明各自归属。例如资料提交期限、初稿时间和验收时间是三个不同节点，不能只挑最早的日期当作整单截止。界面可按节点排列，让业务人员确认先后关系。出现验收早于初稿等冲突时，提示具体矛盾并停下相关排期，而不是静默调整成系统认为合理的日期。修正后的计划应保留谁做了决定，这样下一轮沟通不会再次回到原来的歧义。
截止以后做什么也要写进去
同一个期限，在不同任务里意味着不同动作。内部初稿过期可能只需要提醒负责人；预约窗口结束以后继续发送邀请，则可能已经没有意义。企业应按任务类型定义到期行为，避免把所有逾期任务都自动重试。重试解决技术失败，不会让过期的业务机会重新有效。
当客户改期，系统要知道新日期替代了哪个旧日期，尚未触发的提醒是否取消，已经派发的任务由谁处理。不要只改任务卡上的显示时间，底层队列里仍保留旧定时器。保存变更原因、确认人和更新时间，让员工能看出这是客户修改、内部调整还是系统修正了解析错误，这些原因决定后续该怎么沟通。
验收专门挑不舒服的时间点
正常白天输入一个完整日期很容易通过，测试应加入跨午夜转发、周末提交、月末跨月、闰日、时区缺失和夏令时切换等边界。具体用例由工程人员根据实际系统支持范围构造，不必全部交给业务人员手工算。每个用例都应有事先确认的预期结果，包括什么时候应当拒绝自动确定。
还应测试消息到达较晚的情况：原计划执行时间已经过去，系统应该标出过期，而不是把它重新解释成下一个同名日期。输入“下周五”和“本周五”时，检查业务定义是否一致；输入只有日期没有时刻时，检查是否使用了已说明的默认值。验收不是看系统能否总给出答案，而是看它能否在信息不足时停在正确位置。
让责任人能直接核对
上线前可以选一条实际流程，把所有时间字段列出来，写清来源、规则、用途和确认人。销售确认客户承诺，运营确认营业日规则，开发实现转换与触发，不能让其中任何一方替其他人猜。面向员工的任务回执最好同时显示客户原话和最终期限，让他一眼发现偏差，而不是到逾期时才去翻日志。
日常复盘时关注的是时间被人工改正的原因、因缺失信息进入补问的任务，以及定时动作是否按已确认期限触发。不要把“模型成功提取日期”当作完整交付指标。真正可验收的结果，是团队知道这个时间怎么来的、谁认可了它、到了那一刻系统会做什么，以及客户改口之后旧安排能否被正确撤回。
要点总结
- 可以作为已明确的业务约定，但跨地区客户的原始表达仍需核对，不能把默认时区当成对方已确认。
- 模型可提取表达，实际计算宜用确认过的业务日历与确定性程序，避免每次生成不同结果。
- 不必一概而论。草稿可带待确认状态继续，涉及承诺或执行的关键节点应先完成确认。
参考来源说明
本文为业务方法讨论，文中场景为说明用例。下列官方技术资料用于核对相应机制，站内服务页用于了解相关业务；不作为客户案例或效果数据的证明。