给数据仓库配个 AI 助手：dbt 建模与 SQL 排错的自动化实践

数据分析师的一天，往往不是”写 SQL”，而是”和 SQL 搏斗”：字段对不上、口径不一致、跑挂了两小时才发现上游改了表名。2026 年，把 AI 助手接进 dbt 工作流，能把这些瑣事砍掉一大半。关键是要接在正确的环节。

环节一：自动生成 dbt 模型骨架

给 AI 足够的上下文（源表结构、业务口径、命名规范），它能直接产出 stg → int → mart 的分层模型：

• staging 层：清洗、类型转换、字段重命名
• intermediate 层：业务逻辑聚合、join 维表
• mart 层：面向报表的宽表

要点是把规范写进提示词：命名约定、增量策略（incremental vs table）、分区键、测试要求。AI 输出后人工 review 逻辑，而不是从零写。

环节二：解释报错（省最多时间）

数仓报错通常又长又晦涩。把报错原文 + 相关模型代码 + dbt 日志一起给它，让它：

1. 用大白话解释错在哪
2. 指出是哪张表哪个字段的问题
3. 给出 2–3 个修复方案及各自影响

这一步尤其适合处理”跑了两小时才失败的作业”——不用再靠经验猜。

环节三：血缘与变更影响分析

当上游要改一张核心表，最怕的是”改完不知道炸了谁”。让 AI 读 dbt 的 manifest.json（血缘图），可以快速回答：

• 这张表被哪些下游模型依赖？（改前影响面）
• 直接改会让哪些指标口径变化？
• 建议的兼容改法（新增列而非改列名）

这是 AI 在数仓里价值最高的场景之一——人读血缘图很累，机器读 JSON 很快。

环节四：口径一致性与去重

同一个”活跃用户”在不同模型里有三种写法，是最隐蔽的数据事故来源。让 AI 扫描所有模型，找出同一指标的重复定义并标出差异，统一到一个 macro 或 metric 定义里。

落地要点（避坑）

• 喂 schema 不喂数据：把表结构、字段注释、业务字典给 AI，但不要喂真实业务数据，避免合规风险。
• AI 产出必过 CI：AI 写的 dbt 模型必须走 dbt test（唯一性、非空、关系测试）和 code review，不能直接上生产。
• 保留人工把关口径：逻辑可以 AI 起草，但业务口径的最终解释权在人。
• 用 manifest 做事实来源：让 AI 基于真实血缘文件工作，别让它凭空想象依赖关系。

一句话总结

数仓里的 AI 助手不是”替你写 SQL 的机器”，而是**“随叫随到的排错与血缘分析助手”**。把生成、排错、影响分析这三件事交给它，把口径判断和数据测试留给人，数据分析的效率才能真正上一个台阶。