【让AI-Agent 在数据治理的前线作战】

接入期就把数仓「讲清楚」：AI 工作流如何落地 ODS→DWD 主题治理第一步

说明：本文聚焦数据接入期的治理方法，案例为抽象化表达， 公司建设数仓，最常见的痛点不是“没有数据”，而是数据进来了、模型也在建，但没人能把「为什么这么建」讲清楚。

ODS 已经接进来了，DWD 也在建，但模型背后的业务过程、口径边界和建设理由，往往只活在少数人的脑子里。

这在业务迭代快、组织变化快的互联网团队里尤其常见：产品需求一轮接一轮，数据链路不断加字段、补逻辑、赶上线；人员一流动，原来靠口头传递的业务背景就断了。新同学看表注释——空的；读 SQL——几百行SQL没有说明；问口径——要翻调度平台、翻历史 SQL、翻群聊和口头约定；主题边界——各说各话。
这不是「缺一张宽表」的问题，而是数据接入阶段少了一步：把业务过程解读清楚，并把主题策略写下来。

在让 AI-Agent 参与数仓治理之前，还有一个容易被忽略的前提：先用业务知识文档喂养 AI-Agent。这里的“喂养”不是让模型直接替代业务判断，而是把业务术语、对象关系、流程说明、口径边界与历史 QA 整理成可检索、可引用的知识材料，让 Agent 先理解业务语境，再进入数据表与任务链路。

因此，接入期治理的关键不是等表建完后再补说明，而是在 ODS 进入模型规划的过程中，同步完成业务语义、模型意图与任务口径的结构化沉淀。它要解决的不是“画几张图”，而是把原本散落在代码、调度、群聊和个人经验里的信息，沉淀成团队可复用的知识资产。

一、破局点：治理的第一步，应发生在「接入期」

很多不够规范的建仓过程，往往把治理放在「事后」：业务先上线、数据先接入、报表先交付，等表已经堆满、任务已经跑了几个月，再补元数据、补质量规则、补文档、开评审会。
这时再回头追问“这张表为什么这样建