凌晨00:30，一条"全部完成"通知弹出来：今日共0个任务全部完成。
可就在过去的24小时里，我们明明完成了13个任务——所有任务都复核通过了。

一条荒谬的完成通知

我们的派发系统每个任务都有唯一ID，格式是 DEV-日期-序号：

DEV-20260804-001  删除登录页两行文字
DEV-20260804-002  删除提示语+输入框上移
DEV-20260804-003  整体上移
……
DEV-20260804-013  记住我/忘记密码点击修复

13个任务，全部"复核通过"，状态 verified。一切正常。

然后凌晨00:30，系统检测到"没有待处理任务"，按规则发送"全部完成"通知：

✅ 本次所有任务已完成。
结论：✅ 今日共0个任务全部完成

13个已完成的任务，统计结果是0。

排查：0是从哪来的

统计代码长这样：

today = datetime.now().strftime('%Y%m%d')   # 现在是 20260805
pattern = f'DEV-{today}-%'                    # 匹配 'DEV-20260805-%'
total = SELECT COUNT(*) WHERE task_id LIKE 'DEV-20260805-%'

看明白了吗？任务ID里的日期，和系统统计用的"今天"，不是同一天。

• 任务ID：DEV-20260804-xxx——派发那天是8月4日
• 统计代码：today = 20260805——现在是8月5日凌晨（刚过零点）

凌晨0点到1点之间，系统用"8月5日"去匹配"8月4日派发的任务"——一个都匹配不上，统计出来自然是0。

13个任务干了整整一天，跨过了零点，然后被"日期"一刀切没了。

为什么"日期"会骗人

这是日期处理最经典的坑：同一件事，在不同地方用不同的"日期口径"。

任务ID用派发日期（DEV-20260804——什么时候派的），统计代码用当前日期（datetime.now()——现在几号）。凌晨时分，这两个日期必然错位：

任务ID:   DEV-20260804-001  （8月4日派发）
统计:     DEV-20260805-%     （8月5日凌晨——匹配不到）
结果:     0个任务

8月4日晚上9点派发的任务，8月5日凌晨0点10分完成——它到底算哪天的任务？ 从"派发"角度是8月4日，从"完成"角度是8月5日。系统选了第三条路：按ID里的日期匹配，然后一个都匹配不上。

修复：别用ID里的日期做统计

任务ID里的日期是"派发日"的烙印，但统计"今日完成"应该看完成时间——这是两个不同的维度。

# 旧：按task_id里的日期匹配（凌晨必错位）
pattern = f'DEV-{today}-%'

# 新：按创建时间统计近24小时（跨天任务也覆盖）
created_at >= datetime('now', '-24 hours', 'localtime')

改成按 created_at 统计后，凌晨跨天任务也能算进来：

修复前: 凌晨统计"今日0个任务"（ID日期匹配不上）
修复后: 近24小时统计 → 13个任务全部计入 ✅

三条教训

第一，"今天"是个模糊概念。 派发日、完成日、统计日——同一个任务可以有三个"日期"。写统计代码前，先想清楚你统计的是哪个维度的"今天"。

第二，ID是标识，不是数据。 任务ID里的日期是为了让人一眼看出"哪天派的"——用它做统计条件，是把"展示用信息"当成了"业务数据"。统计永远基于业务字段（创建时间/完成时间），不基于ID。

第三，凌晨是bug的黄金时段。 跨天、跨周、跨月——边界时刻最容易出问题。0点和24点的行为不一样，是所有日期逻辑的试金石。 如果你的系统凌晨会出奇怪的结果，先查日期口径。

结尾

修复后，我特意在凌晨1点又跑了一次统计——13个任务，全部正确计入。

然后我把这条教训写进了代码注释：

任务的日期有两种：ID上印的，和数据库里记的。统计的时候，请相信数据库，不要相信ID。

凌晨0点，是日期逻辑的照妖镜。

（完）

---

本文是"多Agent派发系统"系列第34篇。前篇讲AI被截图噎死（session卫生）、0字节信任危机（假反馈）。这一篇讲时间口径（假日期）。技术事故的又一个规律：边界时刻（0点/跨天）专治各种"想当然"。

---