背景：一个让人头疼的经典问题
做 BI 的同学大概都遇到过这种场景------业务方跑来跟你说："同一张报表，我用 admin 账号看和用普通账号看，数据对不上，是不是系统有 bug？"
上周我就碰上了。两个 Smartbi 管理员账号（admin 和 H0200XXX），同样的筛选条件，确认过权限配置一致，但报表跑出来的数据就是不一样。排查这种问题的传统流程是：打开 Smartbi 后台 → 导出两个账号的 SQL 执行日志 → 逐行比对 SQL 差异 → 定位到底是 SQL 结构不同还是权限数据不同 → 最终找到根因。
问题是，Smartbi 的 SQL 日志是 JSON 格式的，里面嵌套着 CTE 链、子查询、动态拼接的权限过滤条件，一个查询的完整 SQL 动辄上千行。人工比对两份 SQL 的差异，不仅枯燥，而且极易遗漏。上次我手动排查类似问题花了将近 3 个小时，还差点漏掉一个关键的 GROUP BY 差异。
普通对比工具很难找出差异点，sql嵌套太多了。。。
这次我换了个思路------把两份 SQL 日志直接丢给 AI 助手，让它帮我做结构化比对。
痛点拆解
在数据排查场景中，效率瓶颈主要集中在三个环节：
日志解析耗时。 Smartbi 的执行日志包含 sqlExecInfos、sourceSqls、duckDbSql 等多层结构，Oracle CTE 链嵌套可达十几层（zuzhi → zuzhi2 → zuzhi3 → tmp0 → jingxiaoshang → bili → tmp2 → jiezhuan → khbm_qc → tmp1 → tmp4 → tmp7 → tmp8 → tmp9 → tmp10），人工梳理完整链路非常吃力。
差异定位困难。 两份 SQL 可能有 99% 的内容相同，但那 1% 的差异（比如一个多了 GROUP BY，一个没有）恰恰就是根因。人眼在几千行 SQL 里找差异，效率极低。
权限逻辑复杂。 Smartbi 的数据权限通过 dim_sale_user_permission_df 表实现，过滤条件包含多层 OR 嵌套（classify_level2/classify_level3/job_nm 三级权限维度），加上 INNER JOIN ... ON 1=1 的 cross join 模式，理解起来需要同时吃透业务逻辑和 SQL 技巧。
实操过程：我是怎么做的
第一步：导出 SQL 日志
在 Smartbi 后台分别用两个账号执行同一张报表，导出 JSON 格式的 SQL 执行日志。这一步是常规操作，不再赘述。
第二步：把日志丢给 AI，给出明确指令
我的 prompt 大致是这样的：
我需要你分析两段 SQL 执行日志。它们来自同一张报表、同样的筛选条件、确认一致的权限，但 admin 和 H02001736 两个账号跑出来的数据不一样。请帮我找出两份 SQL 的所有差异点，并分析哪个差异可能导致数据不一致。
AI 拿到日志后，做了以下几件事：
- 结构化解析：自动识别出 JSON 中的多层 SQL 结构（Oracle 层 + DuckDB 层），分别提取出完整的 CTE 链路。
- 逐项比对：对比了 GROUP BY、ORDER BY、CTE 结构、过滤条件、JOIN 条件、计算字段逻辑等所有维度。
- 精准定位差异 ：第一轮分析就发现了关键差异------admin 的汇总层是纯 SUM 聚合（无 GROUP BY，返回单行），而 H02001736 的汇总层有
GROUP BY "T"."战区3"（返回多行，按战区拆分）。
这个差异如果让人眼去找，在两份各上千行的 SQL 里，真的很容易漏掉。
第三步：验证权限数据
AI 分析后提出一个假设：差异可能来自权限表 dim_sale_user_permission_df 中两个账号的数据不同。为了验证，我跑了一条查询：
sql
SELECT classify_level2, classify_level3, job_nm
FROM jz_dwd.dim_sale_user_permission_df
WHERE is_core_user = '是'
AND job_number IN ('admin', 'H0200XXX')结果截图给 AI 后，它立刻分析出：两个账号的权限数据确实一致（classify_level2 和 classify_level3 都是 NULL），这意味着权限过滤走的是同一个 OR 分支，理论上应该产生相同的结果。
第四步：二次排查，锁定根因
既然权限数据一致，AI 建议我重新拉取 SQL 日志做第二轮比对。第二轮日志来自不同的报表组件（经销商明细层，SQLQuery_6），这次两份 SQL 的结构完全一致------同样的 GROUP BY（经销商名称、战区、省区、专管业务员），同样的 ORDER BY，同样的 CTE 链路，同样的过滤条件。唯一的差异仍然是 job_number = 'admin' vs job_number = 'H0200XXX'。
AI 的结论是：从 SQL 逻辑层面看，两个查询应该返回完全相同的结果。如果实际数据仍然不一致，最可能的原因是数据时效性------两次查询间隔了 2 分钟，底层数据可能在此期间发生了更新。
结果：提效显著
| 环节 | 传统方式 | 使用 AI 助手 |
|---|---|---|
| 日志解析与结构化 | 30-40 分钟 | 2 分钟 |
| SQL 差异比对 | 40-60 分钟 | 3 分钟 |
| 权限逻辑分析 | 20-30 分钟 | 5 分钟 |
| 根因定位与建议 | 20-30 分钟 | 5 分钟 |
| 合计 | 约 2-3 小时 | 约 15-20 分钟 |
最大的价值不只是快，而是不容易遗漏。AI 会系统性地比对每一个维度（GROUP BY、ORDER BY、CTE、JOIN、过滤条件、计算字段），不会因为看到前面几百行都一样就放松警惕。
可复用的排查模板
经过这次实践，我总结了一个用 AI 排查 BI 报表数据不一致的 prompt 模板，供参考：
第一轮 prompt（差异定位）：
我有两份 SQL 执行日志（见附件），来自同一张报表的两个不同账号。筛选条件相同，权限已确认一致，但数据结果不同。请帮我：
- 分别提取两份 SQL 的完整结构（包括 CTE 链、GROUP BY、ORDER BY、JOIN 条件、过滤条件、计算字段）
- 逐项比对，列出所有差异点
- 分析每个差异是否可能导致数据不一致
- 给出排查建议
第二轮 prompt（验证阶段）：
我跑了这条验证查询（附 SQL 和结果截图），请根据结果判断之前的假设是否成立，并给出下一步排查方向。
几个避坑要点：
- 日志要完整导出：Smartbi 的日志有时会被截断，确保拿到完整的 JSON，特别是 duckDbSql 部分不要漏掉。
- 分轮排查比一次性甩给 AI 效果好：先让它找 SQL 差异，再让它结合权限数据分析，最后让它给结论。一次性把所有信息都丢过去，反而容易得到泛泛的回答。
- 截图比文字描述高效：权限表数据用截图直接给 AI 看，比手动打字描述字段值快得多，也不容易出错。
- 注意时间戳：AI 会帮你关注两次查询的执行时间差，这在排查"数据时效性"问题时是关键线索。
写在最后
数据排查类工作的特点是：逻辑不复杂，但细节极多、比对量极大。这恰好是 AI 助手最擅长的领域------它不会觉得枯燥，不会看漏，而且速度极快。
这次排查如果按老办法，我至少要花半天时间。用 AI 辅助，从拿到日志到锁定根因，前后不到 20 分钟。更重要的是，排查过程的系统性和完整性远超人工比对，让我对结论更有信心。
如果你也经常处理 BI 报表的数据问题，强烈建议试试这个思路。把脏活累活交给 AI，你只需要负责提问题和验证结论。