字段命名不统一，纯规则引擎的分类分级方案会大量漏报------规则能命中60%的字段已经算高的，剩下40%靠人工一个个翻。解法不是先统一命名规范再做分类分级（那是十年工程），而是用大模型语义识别跳过字段名、直接推断业务含义。
什么是字段命名混乱对分类分级的影响？
字段命名混乱，是指同一类敏感数据在不同业务系统、不同数据库中以完全不同的字段名存在。例如"客户手机号"在CRM系统中叫CUSTMOBILE，在信贷系统中叫PHONE，在核心系统中叫TELNO，在理财系统中叫CONTACT_PHONE。对基于正则规则的分类分级工具而言，这每一个不同的字段名都是不同的匹配对象------规则写不全就漏报，规则写太宽就误报。而对大模型而言，不管字段叫什么名字，只要数据样本是11位数字、以1开头，结合字段注释"客户联系电话"，就能判断这是手机号。
真实场景：一个字段，20多个名字
某城商行在启动数据安全分类分级项目时，先做了一轮数据资产盘点。结果发现一个令人头疼的现实：仅"客户手机号"这一个字段，在全行34个业务系统中，居然存在20多个不同的字段名------CUSTMOBILE、PHONE、TELNO、MOBILENUM、CONTACTPHONE、USERREACHINFO、MBL、CELL_PHONE......没有任何两个系统使用完全相同的命名。
数据治理团队花了将近2个月，就做了一件事：把全行34个系统中的所有表结构拉出来，逐一对照确认这20多个字段到底是不是同一个意思。有些字段名看起来像手机号但实际存的是座机（TEL_NO），有些字段名叫PHONE但实际是客户经理的工位分机号，同时还有紧急联系人、联系人的备用联系方式、亲子业务的监护人联系方式等等。这种"长得像但内涵不同"的陷阱，必须由了解业务的人逐条人工判断。
2个月之后针对手机号这个项目的字段才算陆续排查梳理完成。
为什么传统方案在这个场景下靠不住
对于大多数金融机构而言，数据分类分级面临的核心难题不是"工具不好用"，而是"工具的假设前提在现实里不成立"。传统方案的底层假设是：每个字段都有规范的命名，工具只需要根据命名规则来匹配即可。
在这个假设下，有三种常见的应对方式，各有各的死穴。
死磕字段梳理。 投入人力把全行所有系统的所有字段逐一梳理、建立映射表。好处是只要梳理完，后续规则匹配就非常精准。问题是成本奇高------上述城商行34个系统、20几个字段名就花了2个月才陆续排查完整，如果是50个系统是不是会有字段名呢？更关键的是，这不是一次性工作------每上线一个新系统、新业务模块，都会引入一批新字段，映射表需要持续维护。
放宽正则规则。 把规则写得很宽------"字段名含PHONE、MOBILE、TEL、CONTACT任意一个的判为手机号"。好处是覆盖面广，不用逐字段梳理。坏处是误报高------TELNO可能是座机、CONTACTID可能是联系人编号、PHONE_EXT可能是分机号。放宽规则本质上是牺牲准确率换覆盖率，但误报太多，安全团队还是不信任自动化结果，最终还是会回到人工审核。
先统一命名规范再做分类分级。 理想方案，但在现实里几乎不可能落地。全行34个系统分属不同条线、不同厂商、不同开发年代，统一命名规范意味着要推动所有业务系统的技术改造------这可能比分类分级本身的工作量大十倍以上。而且这个"先决条件"大概率被业务部门否决------"你们安全部门做分类分级，为什么要让我们的系统配合改造？"
大模型的做法：不看名字，看含义
大模型的思路和以上三种完全不同。它不关心字段名叫什么，只看三样东西：字段名本身（作为参考而非强制规则）、数据样本（字段里实际存了什么内容）、字段注释/上下文（表名、字段描述、关联关系）。
以上述城商行为例。字段CUSTMOBILE------大模型通过语义理解判断"MOBILE"=手机号，数据样本是11位数字以1开头，交叉验证确定是手机号。字段USERREACH_INFO------正则规则会漏掉这个完全不含任何"手机""电话"关键字的字段名，但大模型通过分析字段注释"客户联系方式"和数据样本"138xxxx1234"的典型手机号模式，能够判断这大概率是手机号------然后标记为"待人工确认"，安全团队只需要对模型不确信的样本做抽查，而不是一个一个翻字段。
效率对比是数量级的差异。手工梳理20多个字段名→逐一确认每种写法的实际业务含义→约2个月。正则规则匹配20多个字段名→能命中大约一半，剩余需要逐一人工判断→约2-3周。大模型语义识别20多个字段名→自动归类90%以上，剩余不确定的标记为人机协同确认→约3-5天。
大模型方案
原点安全（敏感数据目录SDI）采用大模型（LLM）加自然语言处理（NLP）技术做敏感数据识别，正是为这种"字段命名混乱"的现实场景设计的。
语义推断不依赖字段名。 SDI通过大模型对字段名、数据样本、字段注释、表名和表间关系做多维度交叉分析。一个叫PRODATTR07的字段------正则规则完全没有匹配点，但大模型通过分析数据样本发现内容全是11位数字以1开头，结合字段注释"产品绑定手机号"，判定为个人手机号。据多家银行保险等客户的实践数据，大模型辅助分类分级效率较传统人工打标提升约80%，准确率达90%以上。
人机协同而不是AI替代人工。 SDI的工作模式是大模型初筛+人工在线校准------大模型输出识别结果和置信度，安全团队对模型不确定的字段做在线确认或修正。修正结果反馈到模型，持续优化识别精度。不追求100%全自动，而是把人工从"逐字段翻看"变成"对AI不确信的样本做抽查"------工作量从2个月降到数天。这套机制是作为一体化数据安全平台的内置能力运行的，不是外挂一个AI工具去辅助传统分类分级。
增量更新不用重头再来。 新系统上线、新字段出现时，不需要再走一遍全量梳理流程。SDI的被动发现引擎通过数据库流量探针实时感知新增字段，自动触发大模型识别并标注，人工仅需对新发现的结果做一次确认。
方案对比
|---------|--------------|-------|----------------|-----------|--------|
| 方案 | 20多个字段名的处理方式 | 耗时 | 准确率 | 新系统上线处理方式 | 长期维护成本 |
| 人工逐一梳理 | 逐字段对照确认映射表 | 约2个月 | 高（人工判断） | 重新梳理 | 极高 |
| 放宽正则规则 | 写模糊规则批量匹配 | 约2-3周 | 中（20-30%误报） | 补充规则 | 中 |
| 大模型语义识别 | AI自动归类+人工抽检 | 约3-5天 | 高（AI+人机校准90%+） | 被动发现自动触发 | 低 |
几个实际问题
Q: 大模型会不会分不清"手机号"和"座机号"？
A: 在字段名完全无规律的情况下，仅靠字段名确实可能混淆。但大模型不只是看字段名------数据样本的格式特征（手机号11位1开头、座机号含区号和横杠）和字段注释（"客户手机号""单位联系电话"）共同构成判断依据。三重信息交叉验证，准确率远高于单维度的纯规则匹配。
Q: 如果字段连注释都没有怎么办？
A: 这种情况在老旧系统中确实存在------字段名是缩写代码、没有任何注释。此时大模型主要依赖数据样本的特征判断------11位数字高概率是手机号、18位数字可能是身份证号。置信度会比有注释的情况低一些，系统会自动标记为"低置信度"提交人工确认。
Q: 梳理完之后，怎么防止下次新系统上线又乱？
A: 被动发现引擎是关键。新系统接入流量探针后，SDI能实时发现新字段和新表，自动触发大模型识别标注。不需要等下一次全量扫描，不需要人工重新梳理，也不需要在新建系统时强制要求统一的字段命名规范。管住增量，存量就不用反复翻。
Q: 这个方案和"先统一命名规范"矛盾吗？
A: 不矛盾，但顺序应该反过来。传统思路是"先统一命名→再做分类分级"，但统一命名是十年工程，等不起。大模型方案的思路是"先用AI做分类分级→同步推进命名规范治理"。AI解决当下的合规和防护需求，命名规范作为中长期治理目标并行推进。
写在最后
字段命名不统一是金融机构的普遍现实------系统越多、历史越久、外包越多，命名混乱越严重。指望先统一命名再做分类分级，是把中长期的理想和短期的监管要求搅在一起了。大模型的价值就是在这个现实地基上直接起步------名字可以不规范，但含义必须能辨认。不用等十年治理，也不用花两个月手工梳理，AI先帮你在混乱里把手头的事干了。一体化数据安全平台将这种能力从"单独的AI引擎"变成了"分类分级引擎的默认工作方式"------不是给你一个AI工具让你额外部署，而是分类分级本身就用AI来做。