我开始把 AI 当作数据排查助手

数据问题通常不会直接告诉我原因。一个字段为空、两边数量不同或者任务结果不符合预期，背后可能涉及业务口径、源数据、同步条件、字段映射和平台规则。

经过一段时间使用，我开始把 AI 当作数据排查助手。这里的“助手”不是让它直接判断生产数据，而是让它帮助我整理问题、拆分链路、列出假设和检查遗漏。真正的结论仍然由业务定义、查询结果、任务日志和代码共同决定。

先把现象和结论分开

看到数据不一致时，很容易直接写“同步任务漏数”或“字段映射错误”。但这只是猜测，还不是已经确认的原因。

我会先记录能够观察到的现象：

• 哪两个结果不一致；
• 比较时间是什么；
• 使用了哪些筛选条件；
• 差异是数量、字段还是状态；
• 能否找到具体的差异记录；
• 问题是否可以重复出现。

已观察到的现象
    -> 需要验证的假设
    -> 使用的证据
    -> 排除或确认
    -> 当前结论

这样把信息提供给 AI 时，它更容易帮助我整理下一步，而不是围绕一个未经确认的结论继续推测。

给 AI 的不是整库数据

数据排查涉及真实业务信息，不能为了获得回答就复制整张表、数据库连接或内部日志。

我会保留问题结构，同时移除敏感内容：

• 用抽象名称替换真实系统、表和字段；
• 删除账号、Token、IP、域名和连接字符串；
• 使用数量级、比例或脱敏标识描述差异；
• 只保留与问题有关的字段类型和关系；
• 不提交真实个人、学校或客户数据。

例如，可以描述“A 系统有一批符合条件的记录，平台少了一部分”，再说明时间范围和过滤逻辑，而不是直接提供真实记录。

让 AI 帮我建立假设清单

当差异可能来自多个环节时，AI 适合帮助补充检查方向。

业务口径
源数据状态
抽取时间窗口
字段映射与类型转换
去重和覆盖规则
质量校验
任务失败与重试
查询本身的统计方式

这份清单不是问题原因列表，而是待验证的假设。每一项都需要对应证据，例如业务文档、源端查询、任务配置、日志或目标端数据。

如果没有证据，就应该继续标记为“待确认”，而不是因为某个解释听起来合理就写成结论。

按数据链路逐层缩小范围

我会尽量沿数据流向排查，而不是同时修改多个位置。

源端是否存在
    -> 是否满足抽取条件
    -> 任务是否读取
    -> 转换是否成功
    -> 目标端是否写入
    -> 查询是否按同一口径统计

如果源端本来就没有数据，就不需要先研究目标端写入；如果任务已经读取并成功转换，范围可以继续缩小到写入和目标端规则。

AI 可以帮助我把链路拆成问题，但实际状态必须从真实环境中获取。

用对照查询验证假设

确认某个假设时，我更愿意准备一条只回答一个问题的查询，而不是不断修改一条越来越长的 SQL。

例如，需要确认某个时间窗口是否包含记录，可以使用通用的只读查询：

SELECT COUNT(*)
FROM source_record
WHERE updated_at >= :start_time
  AND updated_at < :end_time;

需要确认哪些记录缺失，则可以分别导出脱敏后的唯一标识，再做集合对比。示例表名和参数都是通用写法，不来自真实项目。

AI 可以帮助设计对照查询，但查询条件是否符合业务口径，仍然要自己确认。

记录已经排除的方向

多轮排查中，如果不记录已经做过什么，AI 和人都容易重复给出相同建议。

我会维护一份简短的验证记录：

这个表格是通用示例，不代表某次真实排查的结果。实际记录中只写已经获得的证据，不提前填写原因。

警惕为了“对上数字”修改口径

当两个数字不同，最危险的做法之一是不断调整过滤条件，直到结果看起来一致。如果没有业务依据，这只能掩盖差异。

每次修改查询条件前，我会问：

• 这个条件来自哪条业务规则；
• 为什么一边需要过滤、另一边不需要；
• 是否会排除本应统计的数据；
• 修改后能否解释具体差异记录；
• 同样的口径能否用于后续核对。

AI 给出的条件也必须接受相同检查。

最终输出是证据链，不是答案列表

一次排查结束时，我希望留下的不只是“原因是某某”，还包括：现象、口径、差异范围、验证步骤、确认原因和复测结果。

AI 可以把零散信息整理成结构化记录，也可以提醒我哪些假设还没有证据。但只有真实查询、日志和业务规则能够关闭一个问题。

我开始把 AI 当作数据排查助手，是因为它能帮助我更快地组织复杂问题，而不是因为它能直接看到答案。把现象和猜测分开，把敏感信息脱敏，把每个方向转化为可验证的问题，AI 才真正成为排查过程中的辅助工具。