AI 怎么＂看清＂数据怎么流的银行里负责画数据血缘的人，有一个共同的秘密：图永远是"阶段性完成"的。年初立项，全行数据血缘治理，先画核心系统到数仓这一段。耗时半年，画完了。画完的当天，数仓做了个版本升级，ETL 脚本改了十几条。图里谁也不知道哪些线还是对的。年底再立项，补下游报表到报送这一段。又半年，又画完了。这时候年初那段已经没人敢拍胸脯说还准了。三年下来，钱花了不少，图一直处于"画完即过时"的状态。不是团队不努力。一个人翻代码、查脚本、找开发求证，一条字段的完整链路搞清楚，短则半天，长则两三天。全行几千张表、上万条加工链路，靠人力的速度跟不上系统变更的速度。本质问题是：人工画血缘，是在用"访谈考古"的方式维护一张需要实时更新的地图。接下来要讲清楚一件事——AI 不是画得比人快，是画的方式完全不一样。它不看文档，不看注释，看的是数据加工留下的"痕迹"。AI 不需要"看懂"数据。AI 做的事更简单，也更诚实——它去找数据生产过程中留下的痕迹。想象一个刑侦比喻。你要还原一栋楼里所有人的行动轨迹，有两种办法。一种是挨个问"你有没有去过 3 楼"，然后画图。另一种是调出所有的门禁记录、监控录像和电梯刷卡日志，把同一时间、同一路径的事件拼起来，自然就知道谁去了哪一层、经过了哪个房间、和谁有过接触。AI 做数据血缘用的是后一种思路。银行的数据每天都在流动，每一次从源系统被抽取、每一次在数仓里被清洗和计算、每一次被送到下游报表——都在系统日志、SQL 执行记录和调度框架里留下了痕迹。这些痕迹是客观的，不会撒谎，也不会因为写文档的人离职而消失。AI 做的就是把这些离散的痕迹收集起来，按时间顺序拼回去，还数据一个完整的"移动轨迹"。它不是"画"出血缘，是"还原"出血缘。银行的数据加工，核心执行单元是数据库存储过程。每个存储过程里封装了大量的 INSERT…SELECT… 语句——从上游表取哪些字段、经过什么计算、写入下游哪张表。一套完整的数据链路，少则几十个、多则上百个存储过程。这里要先说清楚数据仓库的分层结构。银行的数据仓库一般是三层：ODS 层存储从业务系统同步过来的原始数据，MID 层按主题域（客户、贷款、存款、风险等）生成宽表数据，MRT 层生成最终报表数据。数据从业务系统进入 ODS，再经过 MID 加工，最终落到 MRT 的报送字段，这是主链条。但存储过程只管自己这道工序的事。谁先跑、谁后跑、上下游怎么衔接——这些信息不在存储过程里，在 ETL 配置表里。ETL 配置表是数据仓库调度框架的一张核心表。每开发完一个存储过程，开发人员就在这张表里登记一条配置：这个存储过程叫什么、上游是谁、下游是谁。ETL 脚本读取配置表里的上下游依赖关系，依次或并发地调度存储过程，完成整条数据加工链路。上游作业执行完成后，ETL 根据配置表触发下游存储过程。有一个例外：ODS 层的数据直接从业务系统来，在 ETL 配置表里没有上游。对 T+1 数据仓库，ODS 层是每日 0 点从业务系统抽取数据，不是被上游触发，是时间触发。现在回到 AI 怎么还原血缘。它要找的不是文档，是代码里留下的三样东西：第一样，SQL 执行日志。每个 INSERT…SELECT… 跑过就会留下记录——数据从哪个源表取、经过什么筛选条件、写入了哪个目标表。日志记录的是"谁从哪搬了什么到哪里"，但不包括字段级的加工逻辑。第二样，存储过程的源代码。AI 解析每个存储过程的代码，把 INSERT…SELECT… 拆成字段级映射——目标表的每个字段是从源表的哪个字段来的、经过了什么计算。这些信息不在日志里，在存储过程的源码里。这里有一个工程上的便利：银行的存储过程名和目标表名字是一一对应的，名字一样。AI 不需要猜"这个存储过程的输出去了哪个表"，名字直接给了答案。第三样，ETL 配置表的上下游依赖。这张表不仅定义了执行顺序，还记录了每个存储过程的全部源表。AI 不需要去存储过程的代码里自己找"这个存储过程从哪些表取了数据"，配置表里已经登记好了。这让 AI 的解析路径短了一截：配置表给出上游表的清单，存储过程源码给出字段级的加工细节，两块拼在一起，上下游链路就完整了。三层拼在一起，才是一条能说清楚"数据从哪来、被做了什么、按什么顺序走"的完整血缘链路。不管开发人员还在不在、文档更新没更新，代码和日志不会骗人。讲了 AI 能从代码里挖出三样东西，接下来必须讲它挖不出什么。不讲清楚边界，就是给读者制造虚假期望。先说 AI 能还原的。有代码痕迹的地方，AI 都能还原：存储过程里的字段映射、ETL 配置表里的调度依赖、SQL 日志里的数据移动记录。这些是"硬痕迹"——客观存在，不会因为解释而变形。第一，手工调数的历史。有些报表字段在跑完存储过程后，被人在数据库里手工 SQL 改过值。存储过程和日志里都没有这次修改的记录，这条链路就断了。AI 能补的是代码链条，补不了人的键盘操作。第二，数据从银行外部来的那一段。比如从人行征信系统拉回来的数据、从第三方数据服务商接进来的接口数据、从 Excel 导入的补录数据。这些数据进系统之前发生了什么，AI 看不到，因为它没有银行内部的代码和日志痕迹可读。第三，管业务口头解释——"这个字段虽然叫贷款余额，但我们实际上加进了垫款，口径从 2019 年就改了"。这种约定只在人脑子里、邮件里、会议纪要里，不在代码里。AI 读不到，就不存在。AI 还原的不是全部事实，而是代码层面的事实。这是个重要限制，但它比"全靠人记"已经好了几个数量级。AI 做完上面这些事之后，数据治理团队的角色发生了一个根本性的变化。以前的工作模式是"访谈考古"。一群人去翻代码、问开发、查文档，靠人工一点一点把血缘"挖"出来。大部分时间消耗在找信息上，而不是判断信息。AI 接手"找信息"这一步之后，事情变了。AI 出图——自动扫描代码和日志，生成一张完整的血缘链路图。人不再负责画图，转而负责审图：AI 画出来的链路对不对？哪里对不上？对不上的原因是代码有 Bug，还是存在 AI 还原不了的手工操作？审图的能力比画图的能力更值钱。画图的人只需要知道代码在哪，审图的人需要知道业务逻辑——这张报表的口径和那张报表为什么不一样、AI 标注的链路缺口需不需要补、怎么补。对数据治理人员来说，这不是被替代，而是升级。把翻代码、拼链路这种机械劳动交给 AI，把业务判断、口径验证、缺口识别这种高价值判断留给自己。团队人数不变，产出翻倍，而且产出的质量更高——因为人终于有时间做只有人才能做的事。把 AI 当成"更快的画图工具"，是理解这件事最常见的偏差。快当然有价值——原来三个月的梳理周期压到几天。但快的背后是质变：人工画图是在做"项目"，AI 还原是在做"能力"。项目的特征是做完就过时，能力的特征是持续更新。系统升级一次、存储过程改一次、日志跑一次，链路自动刷新一次。你每次打开看，都是最新的。这才是真正值得写这篇文章的原因。银行合规最怕的不是链路复杂，是链路复杂且没有人能说清楚。监管现场检查不会因为你"正在做数据治理项目"就不问问题。检查组要的是"现在、此刻，你能不能拿出完整链路"。在这个意义上，AI 做数据血缘的价值不是省人工，是把"能说清楚数据怎么流"从一个项目交付物，变成一项日常存在的基础能力。银行数据的每一条流动痕迹都在代码里，只是之前没有人系统地挖掘过。以上，给大家分享，仅作参考。
PS：常规宣传，想加入星球，跟我一起学习《银行合规人的AI工作流》，私信「星球」就好。
夜雨聆风
