先看一个真实场景
接手一家工厂的数字化工作，第一件事往往是这样开场的：老板要 AI 问数，随时问产量、问工时、问库存。你打开数据库一看——行业通用工时软件的表名是 001、002、003，字段是 xsrq、gysmc、gyssj 这样的拼音缩写。
问遍全公司，只有当年实施的外包开发记得这些表的结构，而对方未必愿意细说。ERP 跑了四年，数据十个 G，表结构一到两个月还会调整。另一边，商用软件的数据字典锁在原厂手里。七八套业务系统摆在那里，AI 能直接读懂的几乎没有。
这不是个例。AI 落地企业的第一关，经常不是模型能力，而是语义鸿沟——模型读不懂你的表。
三类"读不懂"，对症才好下药
黑话化命名。早年开发图快省空间，编号加缩写满天飞。写的人省事，十年后的维护者只能靠猜，而系统还在跑核心业务，动不得。
字典锁死。商用软件的表结构是原厂资产，文档不开放。数据是你的，数据的说明书不是。
结构漂移。表结构一两个月一调整，人工整理的对照表很快过时，映射刚建好就变。
三类的病根相同：表的业务含义只在个别人的脑子里或原厂文档里，机器读不到。大模型缺的不是推理能力，是一本业务语言字典。
工程上的解法：语义映射层
对跑着核心业务的老系统，推倒重来不现实。工程上更务实的做法是加一层语义映射，不动表，只补字典。三步走：
第一步，标注核心表。不做全量——AI 问数高频涉及的表通常占两三成。由懂业务的老员工口述字段含义：001 表是工序工时记录，xsrq 是生产日期，gysmc 是工序名称。这一步本质是把人脑里的字典搬出来。
第二步，映射资产化。每张表每个字段挂到业务概念上，"工序工时"这个业务对象落在 001 表的哪些字段，形成一份可版本管理的映射。这份映射不是一份静态文档——字段级的对应关系、每次变更的记录、各部分的负责人，都要像管理代码一样有 diff、可回滚。表结构变了，只改映射这一处，业务概念和上层应用都不用跟着动。
第三步，AI 沿语义取数。用户问"上个月各工序工时汇总"，AI 从业务概念出发，沿"本体—属性—字段—表"的路径定位到 001 表生成查询。使用者全程不接触物理表名，就像用搜索引擎不需要知道数据存在哪个机房。
这条路径在 JBoltAI本体语义平台上的实现思路一致——它是新一代智能数据中台，核心就是在业务概念和物理表之间维护语义映射层。对开发者的额外价值在于：明年换库换表，只要映射跟着改，建立在业务概念上的应用不用推倒重来。
这套方案的边界
顺带说一个常见的工程疑问：这层翻译能不能用数据库视图做？视图能解决一部分命名转换的问题，但承载不了业务概念的描述、映射的版本管理，也带不上权限信息——视图活在库里，AI 读不到视图背后的业务含义。语义映射层要放在业务侧，才能同时承担翻译和资产管理两个职责，这是它和视图的本质区别。
有开放 API 的系统，协同办公、主流财务软件这类，直接走接口更干净，语义层只负责把接口数据挂到业务概念上，不必反向硬做映射。
字典彻底锁死、连导出权限都没有的软件，任何技术方案都无解，那是商务问题不是技术问题。
还要说清一点：语义映射解决"读得懂"，不解决"数据本身乱"。表里大量错录漏录的话，映射再准，答出来的数也不可信，那是数据治理的另一个课题。
落地建议三条
从高频问题倒推标注范围。收集管理层最常问的二十个问题，涉及哪些表就标哪些，两周见效的范围好过两年的全量蓝图。
把标注当资产管理。老员工口述的字段含义，版本化管理、改动留痕——人走了字典还在，这是这项工作最大的价值。
给映射指定维护责任人。表结构频繁调整的系统，映射没人跟就会退化，AI 三个月后又变回文盲。维护成本不高，但不能缺位。
老系统的表叫 001 还是 002 不是关键，关键是业务概念和物理表之间有没有一层翻译。这层翻译建起来，跑了十几年的数据资产才能对 AI 开放。
