AI做资产盘点,46%的表已经3年没人碰过

这不是个例！我接触过的零售企业，数据资产盘点几乎全是一笔糊涂账。直到我把这事扔给AI跑了一次，结果比我预期的好太多，也比我预期的吓人

直接扔一段"帮我把数据库里的表盘点一下"给AI，它会给你一篇看起来很有道理、实际上完全没法落地的废话。想让AI产出真的能用，前置准备比Prompt本身更重要。我做了三件事：

第一步，拉元数据。从 information_schema 或者你们的数据目录工具里，拉出每张表的基础信息：表名、库名、字段名和类型、注释、创建时间、最近一次读写时间、数据量大小、创建人。这些信息大部分数据库原生就有，不用额外采集。我跑了下面这条SQL，不到30秒拿到了一千多行

第二步，按业务域分类。这个别让AI猜。你自己先给个业务域框架——鞋服零售常见的几大块：商品域、会员域、门店域、库存域、订单域、财务域、供应链域。让AI在这个框架内做匹配，而不是从零开始发明分类。

第三步，设计Prompt。最关键的环节。我反复调试了三四版，发现一个规律：你得告诉AI几个明确的标准，而不是让它"分析一下"。下面是我用的Prompt——你可以直接复制改改就用

元数据准备好、Prompt调好之后，AI出结果的速度比你想象的要快。487张表，5分钟跑完第一轮分析

AI的分析报告出来以后，我对着看了很久。不是说它发现了什么惊天秘密，而是这些信息本来就躺在数据库里，只是没人汇总过。AI干的活其实很简单：把每个人都知道一点、但没人拼起来的碎片，拼成了一幅完整的图。下面是它发现的五类问题

僵尸表：46%。最近一次读写超过2年。不是归档表，不是备份表，就是活生生躺在生产库里、占着存储、有些还在跑定时任务的表。最夸张的一张，某品牌2019年做过一次会员标签项目，建了17张中间表，项目结束后没人记得删。4年过去了，这17张表占了将近200GB，每天凌晨还在跑全量刷新。七年没一个人看过里面的数据

孤儿表：31%。创建人已离职，注释栏是空的，没有任何文档，甚至问了一圈现有的同事，没一个人知道这张表是干什么的。其中有一张叫 bi_daily_push_v2 的表，每天还在更新，查了调度才发现它还挂着一个3年前的邮件报表任务。但那个报表的接收人列表里，6个人有5个已经不在公司了。唯一还在的那个人说：我以为是系统自动发的，从来不看的

重复表：12组。不同库里存着高度相似的数据。最常见的场景：业务部门从数仓拉了一份数据到自己的MySQL里做分析，然后这个"副本"就一直留着了。ODS有一份、业务库有一份、某个分析师3年前导出的excel被存回表里又是一份。字段重合度超过80%，但有三份在同时更新，而且更新逻辑不完全一样

临时表：数不过来。前缀是 tmp_、bak_、test_ 的表散落各处。有些是ETL中间步骤留下的，有些是开发联调时建的，有些名字本身就写着"测试"，但已经在生产环境跑了两年。最讽刺的是，这些表加起来占的存储，超过了核心业务表的总和

沉默成本类：日志和中间表。ETL的增量日志、埋点数据、同步中间表，这些表从技术上讲"在用"，但业务上几乎没有任何查询。某张用户行为日志表存了4年数据、800GB，日常查询只取最近7天。剩下3年零51周的数据，说好听是资产，说难听是填坑的土

AI帮你把问题全标出来了，这个阶段最容易犯的错误就是 冲动。看到46%的僵尸表，恨不得马上全删了，千万别这么干。。。

第一步不是删，是打标签。用AI的标注结果给每张表挂上状态，"在用""待确认""疑似废弃""已废弃"。这一步的价值不是做分类，是建立共识。以前没人敢说某张表没用，因为谁也不知道它背后还连着什么。现在AI把证据摆出来了，最后读写时间、依赖关系、是否有调度任务在跑，决策就有依据了

第二步是分级处理。别一刀切。我的做法分三档：临时表可以直接清，因为名字本身就说明了意图；僵尸表先归档到备份库，观察30天，没人来找再删；孤儿表和重复表要人工确认，AI标记的"疑似"不是最终结论，得找一个懂业务的人复核，但不用全量复核，只复核AI标记为"待确认"的那部分。487张表里，"待确认"的只有62张

第三步是建立持续盘点机制。这事不能做完一次就算了。我让AI生成了一个自动化脚本，每个月跑一次元数据采集，对比上次标注结果，自动标记新增的僵尸表和孤儿表。相当于把盘点从"项目"变成了"日常"

最后说一句实在话：AI做资产盘点的价值，不在于它发现的问题有多惊人，而在于它把"没人敢做的事"变成了"5分钟跑个报告"。以前盘点靠人力推、靠人去问、靠人去猜，每次推都推不动。现在AI替你跑出了完整的清单和证据，你只需要做的事情从"搞清楚有什么"变成了"决定怎么办"。这个变化，比46%这个数字本身重要得多

数据+AI · 数字化实战专注数据治理与AI落地