AI写的“本月SQL”多算一条？用5行数据检查月份边界与NULL

先写出任务合同，别让AI自行补时区

这次合同只有三项：字段occurred_at使用带时区时间戳；月份按UTC；缺失时间单独报告，不塞进任何月份。如果实际业务按纽约、伦敦或上海的本地月历结算，必须重新确定边界，不能直接拿本例UTC值去替换。

PostgreSQL时间类型文档区分带时区与不带时区时间戳。不要只看字符串里出现了+00就假定类型正确。数据导入阶段存在模糊时间时，先按AI日期规范化核查保留原值与偏移证据，再验证筛选条件。

五行数据把隐藏的假设变成可见差异

下面的数据全部为编辑自编，用来制造必要的边界情况；不是用户数据。先在不看SQL的情况下写出预期结果，之后才能判断查询是否符合任务，而不是用查询结果倒推答案。

使用两个可解释的边界

SELECT id
FROM events
WHERE occurred_at >= TIMESTAMPTZ '2026-10-01 00:00:00+00'
  AND occurred_at <  TIMESTAMPTZ '2026-11-01 00:00:00+00'
ORDER BY id;

这段查询只解决本例的月份过滤，不同时验证原始数据完整性、去重、连接关系或业务指标定义。

两种看似合理的写法会失败

PostgreSQL比较运算说明规定BETWEEN包含两个端点；普通NULL比较的结果也不能当成真实时间。若把上界写成11月1日，再使用BETWEEN，D会多进入结果。若把上界写成10月31日零点，则会漏掉C这类月末当日稍后的记录。

把验证要求写进给AI的提示词

请审查月份筛选，不执行任何数据库操作。
数据库：PostgreSQL。列occurred_at类型timestamptz。业务月份：UTC的2026年10月。
要求起点包含、下月起点排除。NULL单独报告，不补成零点。
先逐行判断A至E，再列出预期ID和数量；指出BETWEEN端点及类型假设。
只给可在隔离测试数据上验证的查询，不假称已经运行或通过。
在此粘贴本文五行样本与待审查SQL。

验收不止是“返回两条”

先比较B、C这两个具体ID，再查看A、D为什么被排除，最后单独统计E。若只看总数，某条错误记录替换一条正确记录仍可能得到二。和AI表格公式的样本验算一样，参考答案必须独立于被检查的生成结果。

不要靠把上界写成23:59:59来“覆盖整天”：不同数据可能有小数秒精度。采用下一个月份起点作为排除边界更容易说明，但依然必须先定义时区。真实数据的重复ID、夏令时或业务截止规则应另设样本，本篇并未一并验证。