日期角色：支付日还是入账日
时间窗口：时区与闭开边界
事实粒度：订单、明细或日汇总
数据水位：迟到与回补
比较基准：完整且可比的期间
直接答案：先确定“哪种销售额”和“哪一天”
“上周销售额”没有唯一数字。零售经营可能按支付成功日和含税实付金额，财务报表可能按收入确认日和不含税收入，仓配则看发货日。AI 应先依据当前业务域找到获批准的指标定义，给出采用的日期角色和周起始规则；若几个候选同样合理，就先澄清。在澄清之前，不要返回一个仅因历史问法最多而被选中的数字。
用户看到的答案至少应有窗口、时区、指标版本、数据截止时间和是否包含退款。把这些信息藏在 SQL 或系统提示词里，业务人员无法判断变化来自经营、口径还是数据刷新。Microsoft 的星型模型指导也强调事实表粒度与维度关系，日期并非可以随意互换的标签。解释应与数字来自同一次查询计划，避免页面口径和实际过滤各说各话。
把四个时间概念分开
事件时间是业务动作发生的时间，例如支付成功；处理时间是数据进入仓库的时间；有效时间描述一条规则或归属何时生效；报告时间则是用户要求的观察窗口。迟到订单可能在周一入库却属于上周日支付，若用入库时间替代支付时间，会让上周销售额在重算时出现不明原因的差异。同一订单可以同时带有这四类时间，查询必须标明采用哪一类，不能混用后再取平均。
日期角色也要独立命名：created_at、paid_at、shipped_at 和 booked_at 对应不同问题。一个事实表有多列日期，并不意味着查询可以用默认第一列。语义层应为每个指标指定允许的时间角色、默认角色和需要澄清的角色冲突。指标没有声明默认角色时，应停下来询问，而不是按字段在表中的顺序碰运气。
定义可复用的窗口，而不是让模型猜自然语言
“上周”可解析为业务时区内上一个完整自然周，采用左闭右开区间 [周一零点，本周一零点)。国际团队还要声明一周从周日还是周一开始。跨日营业的门店可能使用营业日，例如凌晨两点前订单仍归前一营业日；此时要使用门店日历，不应直接截取 UTC 日期。例子：业务时区为上海且周一起始时，上周一零点至本周一零点才构成“上周”，周日晚间的支付仍落在该窗口内。
月、季度和财年同样需要日历版本。零售的 4-4-5 财务日历与公历月不同；“去年同期”要说明是同一公历日期、同一营业周，还是相同数量的完整营业日。闰日、节假日和夏令时不应由语言模型临时发明处理规则。日历版本应按生效日追溯，避免今年修改周起始后，把去年同期用新规则悄悄重算。
事实粒度决定能否正确聚合
订单头一行一个订单，订单明细一行一个商品，支付流水一行一笔交易。若直接把订单头金额关联到明细再求和，含多件商品的订单会被重复计入。先声明事实粒度和可加性，再决定聚合、去重或分摊。Kimball 的粒度原则是这里的基础：一行代表什么业务事件必须先于维度和度量确定。例子：一张订单含三行商品时，订单头金额只能计一次，周合计应先回到订单或客户粒度。
日汇总表能加速固定口径分析，但无法自动回答需要订单级退款追溯的问题。同比、客单价等衍生指标也不能简单平均各日百分比，应回到共同分子与分母重算。对不可加的期末库存或去重客户数，必须定义快照或去重范围。跨周比率若先对每周比率做简单平均，会偏离业务负责人对照表上的结果。
把数据水位和回补写进答案
业务问“本周至今”时，应取各关键表共同完成的数据水位，而非将销售更新到今天、退款只到昨天的数字拼在一起。数据源需记录最后完整分区、预计延迟和回补策略。答案可显示“截至 9 月 27 日 08:00 的完整数据”，并注明后续退款可能重述历史。水位要写明时区，并与指标日期角色使用同一套日历，避免把“数据已到今天”理解成事件时间已经完整。
对领导晨会，快速估计与财务结账数字可以并存，但必须明确标记 provisional 与 final。若迟到数据超过约定阈值，应暂缓同比结论或显示区间，不可把不完整周与完整周做无提示比较。标记本身不够，未加限定的同比结论里不应直接引用 provisional 数字。
三种实现路线与适用条件
临时 SQL 模板适合少量固定报表，但一旦有多个日期角色和地区时区，模板会迅速分叉。语义层把指标、时间维度、日历和过滤定义集中管理，适合多入口复用；自然语言问数则在语义层上承担解析与澄清，不能取代定义。传统 BI 可让分析师手动选择日期，适合深度诊断，但仍须同一套指标契约。对话与固定报表若同时存在，必须引用同一指标版本，否则两边数字无法对照。
选型时看系统能否显示所用日期角色、复用已批准的周定义、识别缺失水位和处理追问。漂亮的对话界面不能补救底层时间语义不一致；相反，治理清楚的指标即便先只在固定报表中运行，也能提供可信基线。选型还应检查追问切换日期角色时，是否重算窗口，而不是只改回答里的文字。
实施：从十个真实问题建立时间测试集
先收集销售、财务和仓储各自的“昨天、上周、本月、同期”真实问法。为每个问题记录业务负责人、指标、日期角色、时区、周日历、粒度、过滤、数据水位和期望澄清。挑一个订单跨午夜、一个退款跨周、一个迟到入库、一个多明细订单，人工算出黄金答案。黄金答案由负责人保存窗口端点和预期行集，而不只留一个合计数字。
再让语义层或问数系统生成结构化查询计划，对比计划节点和最终数值；差异须归因到时间窗口、粒度、过滤或数据质量。先灰度一项高频指标，冻结旧报表作为对照，业务负责人确认解释可懂后再扩展。灰度期间可并行记录新旧计划，只向用户展示已确认的一条，差异留给负责人复盘。
反例与验收边界
反例一：用户说“本周”时系统只按服务器 UTC 周聚合；反例二：上周订单按支付日，退款按入库日，二者水位不齐；反例三：订单头金额与明细多对一连接后翻倍。三种情形都可能得到看似精确的数字，单靠模型回答流畅度无法发现。再补一个反例：把“本月至今”的不完整窗口直接与去年完整月比较，得到没有限定的增速。
验收要同时检查数字、计划与解释：不同地区零点前后是否归期正确，周一/周日边界是否按合同，迟到回补能否重述并留痕，周与月汇总是否守恒，追问“改按发货日”是否显式换指标。AskTable.ai 可作为企业问数入口候选，但这篇文章不证明其当前版本自动支持全部日历、回补和澄清策略；应以实际配置与测试结果为准。核验时至少回放午夜边界、跨周退款、迟到入库和多明细订单。