每日计数可以回答发生了多少次请求，却无法说明每次请求检测到的名称、精确时间和读取方式。当页面已经显示非零的 AI 请求总数，却没有任何逐次访问可列出时，这个差异就会直接暴露出来。

系统需要为新流量保存更丰富的记录，同时保留旧总数原本的含义。如果把一个历史计数拆成几条看似合理的明细，界面会更整齐，证据却会变弱。因此，这次演进保留旧聚合作为聚合，只为实际观测到的新请求写入事件，并向读者明确标出两者边界。

信息在聚合时已经丢失

旧模型保存文章 slug、语言、规范化 AI 家族、UTC 日期和请求次数。这些字段足以计算每日总量，却没有单次请求的客户端名称、时间、检测来源，也没有记录客户端读取 …

一个桌面任务存储在归档近期任务时持续返回“找不到文件”。会话内容仍可读取，源文件确实存在，状态数据库的完整性检查也正常；重复调用归档接口，结果没有变化。

排查线索落在路径身份上。部分旧记录保存的是物理存储根目录，当前应用则统一从逻辑主目录访问数据。目录链接让两种写法都能读到同一份字节，但归档事务没有把它们视为可互换的路径。

这个案例说明，“文件存在”只覆盖了路径故障的一部分。持久化路径身份与应用当前使用的根目录发生漂移，同样会让有状态事务失败。

先分开现象与证据

界面报错可能来自源文件丢失、权限不足、数据库损坏或路径过期。任何修复之前，先用只读检查缩小范围：

• 目标记录仍在状态库中，归档状态没 …