订单取消、退款、软删除后，AI 问数为什么还把它算进销售额？

“昨天销售额是多少？”

如果订单表中一笔订单先支付、后退款，AI 应该回答支付时的成交额、退款后的净销售额，还是当前仍有效的订单金额？

企业业务数据不是静止的。订单、合同、工单和会员记录都会经历状态变化。只读取当前表，或者把每次变化都当成一条新业务记录求和，都会产生错误答案。

一笔订单可能有多条事实

常见订单生命周期包括：

• •创建但未支付；
• •支付成功；
• •部分退款或全额退款；
• •取消、关闭或超时失效；
• •修改商品、数量、价格或归属门店；
• •业务系统做逻辑删除，但数据库仍保留记录。

因此，“订单数”和“销售额”至少要明确统计状态、统计时点与退款处理方式。

当前状态表不能回答所有历史问题

如果源系统只保留订单当前状态，昨天还是已支付、今天变成已退款的订单，会改写昨天的查询结果。

这可能适合回答“截至现在，昨天订单最终净收入是多少”，却不适合回答“昨天收银时实际成交了多少”。两个问题都合理，但对应不同时间语义。

CDC 记录变化，不等于直接累加

Change Data Capture（CDC，变更数据捕获）会记录插入、更新和删除。SQL Server CDC 会将表上的变更写入可查询的变更表；Debezium 还会为删除事件输出删除记录与 tombstone 消息。

这些记录的用途是重建状态和保留轨迹，不是把每个版本的金额直接相加。数据模型需要识别：

• •哪个字段是稳定的订单业务主键；
• •本次事件是新增、修改还是删除；
• •哪个版本在指定时点有效；
• •退款是修改原订单，还是独立退款事实；
• •逻辑删除是否应从经营口径中排除。

建议同时保留三类指标

为了减少争议，可以分别定义：

• •支付口径：指定期间支付成功的订单与金额；
• •净额口径：扣除指定规则下退款、退货和取消后的金额；
• •当前有效口径：查询时点仍处于有效状态的订单。

AI 在答案中应展示采用的口径，并在用户只说“销售额”时根据业务场景选择默认值，必要时追问。

结论

订单状态变化不是脏数据，而是业务事实的一部分。

AI 问数要正确处理取消、退款和删除，关键不是过滤一列状态，而是保留状态历史、区分事件时间与查询时间，并明确支付额、退款额和净额的关系。只有这样，历史数据才不会随着今天的一次退款而被悄悄改写。

参考来源

• •Microsoft Learn：About change data capture
• •Debezium：MySQL connector delete events and tombstones