一句月底前在同一个智能助手里可能对应两串不同的日期。某制造企业的售后团队给助手加了一项功能让它在每天的工单列表里挑出临近时限的那批结果同一条催办问题问两次得到的时间范围一次落在本月二十五日到三十一日另一次落到了下月月初两批工单里各有几张被漏掉客户的催办电话随之打到了主管那里。团队起初以为是模型对中文时间表达的理解不够于是往提示词里补了一长串示例把月底前下周三三个工作日内逐条解释一遍。改完之后出错的比例降了一些却没有消失。症结不在模型懂不懂这句话而在这句话被换算成日期时缺少几项必须事先确定的约定。相对时间要先有锚点。同一句月底前锚点是当前时刻还是当前业务日按所在时区还是按服务器默认时区计算结果可能落在不同的月份。跨时区的团队更容易碰到这种情况服务器按协调世界时结算业务按本地时间记账两者相差几个小时恰好卡在月末最后一天的傍晚答案就会分岔。一天的口径也要先说清楚。自然日、工作日与节假日是三套算法遇到跨周、跨月与法定假日调休差别会被放大。系统若只按自然日推算三个工作日会被算成三天中间夹着周末时留给业务的时间比预期短反过来也会出现同样的问题。区间的边界同样需要写明。从哪天算起、含不含当天、截止时刻是当天的开始还是结束这几项不确认同一条时间条件可以解析出多个都说得通的区间。不少实现只在文本里保留月底前这样的原句检索时让它以字符串参与匹配而没有把它落成一个带起点与终点的结构化条件。一种可行的方法是把时间表达解析成结构化的时间条件并把解析所需的要素一并固化。解析结果包含五部分起点、终点、时区、日历口径与目标时间字段。时间条件除起点、终点、时区和日历口径外还应明确它约束的是哪个业务时间字段例如创建时间、截止时间、履约时间或结算时间同一个区间作用在不同字段上业务含义并不相同。日历与工作日表单独维护并带有版本或生效时间由业务人员配置与调整便于复核历史查询时回溯当时使用的规则边界规则在登记时就写明避免每次由执行者临时判断。解析时使用的参考时刻或业务日期应与结果一并记录后续复核应读取当时的锚点而不是重新用当前时间解释原问题解析遇到锚点不明或者口径有歧义的情况应当先向提问的人确认一句而不是自行选一个默认值继续往下走。时间条件在检索阶段要作为过滤条件生效而不是当成普通关键词去参与相似度打分。否则一份措辞更贴近提问、时间范围却并不匹配的文档仍然可能被召回并进入答案。系统还应当把解析出的时间区间随答案展示可以让用户快速发现明显的范围偏差并为后续复核留下明确依据。如果同一句表达在不同入口解析出不同结果说明装配的参数不一致需要回到统一配置去处理。通用模型与Agent平台通常能识别常见的中文时间表达但以什么时区为锚点、按哪一套日历口径换算、区间边界如何界定这些仍要结合企业自身的业务规则来确定。在青山不语AI工作室的企业AI Agent定制方案中时间表达会解析成带时区、起点、终点、日历口径与目标时间字段的结构化条件日历与工作日表独立维护并带版本检索阶段以过滤条件生效解析锚点与结果随答案一并呈现。边界也要说明白。系统能做的是按事先登记的规则与日历把表达换算成区间它无法判断业务上的月底究竟指自然月末还是财务结账日这属于业务口径需要企业指定日历调整、节假日安排与特殊结算周期也要由业务侧维护助手负责读取与提示。验收可以挑一个跨月又跨周末的日期组合来做。用同一条问题在月初与月末各问一次观察解析出的区间是否与业务口径一致再核对答案里呈现的区间与依据能否对应。测试应当使用构造的样例不要带真实客户信息。我的判断是中文时间表达的处理难点不在词表而在词表之外的那一层约定时区、日历口径与区间边界。企业在评估AI定制服务时可以顺手问一句这套方案对月底前的解析规则是写在配置里还是散在提示词里。规则落在配置里时间类的故障才有被持续修正的机会。