数据库连接文档都丢了怎么办：AI 分析表结构自动生成接口的实战路径
最近做了一个挺典型的项目，客户是一家老牌纺织企业，2005年上的第一套MES，2011年换过一次财务系统，2015年上的WMS，2019年又追加了个能耗管理系统。现在老板想做数据整合，把这些系统的数据拉到一个平台看。听起来简单，动手一做发现--2011年那套财务系统的原厂已经倒闭了，接口文档一份都找不着；MES用的是一个国产小品牌，用户手册是一本翻烂的PDF，数据库连接文档压根没有。
这就是异构系统对接在真实企业里的常态。不是每个系统都有整齐的API文档等着你调，很多时候你面对的是一堆黑箱：知道它在跑、知道它在生产数据、就是不知道数据长什么样。
向量空间JBoltAI 这两年在做本体语义平台产品化的过程中，异构系统对接是绕不过去的第一关。今天把我们在这类"接口文档缺失"场景里的实战路径讲清楚。
## 一、异构系统对接难在哪
企业里的数据集成，真正难的不是把两个系统的数据搬来搬去。搬数据是体力活，写脚本谁都会。难的是三件事：
第一，不同厂商系统数据格式不一。ERP里的物料编码可能是10位数字，MES里可能是8位字符加分隔符，WMS里可能又变成16位UUID。同一个物料，三个系统里三种身份，跨系统查询根本关联不上。
第二，字段定义冲突。同样是"客户"这个字段，销售系统里存的是签合同的抬头单位，财务系统里存的是开发票的付款单位，两个可能不一样。同样是"发货时间"，WMS里指的是出库扫码时间，物流系统里指的是承运商签收时间，差半天到两天。
第三，历史系统没API或者API不能用。国产的老MES、老ERP，很多是纯C/S架构，只暴露了一个客户端登录界面，压根没考虑过让第三方对接。文档要么没有，要么写得不能用。
这三件事叠加起来，就是很多企业数据打通项目失败的根因。传统做法是找厂商来做定制接口，一个接口报价三五万起，接十个系统三十来万就出去了，还得等厂商排期，一等就是三个月。企业上系统花了几百万几千万，最后卡在数据打通这一步，账算下来血亏。
## 二、AI 分析数据库表结构生成接口的路径
向量空间JBoltAI 在几个项目里跑通了一条新路子：不再依赖厂商文档，把数据库丢给AI，自动分析表结构、推断字段含义、生成对接接口。这条路的核心是把"接口文档"这件事从"必须靠厂商"变成"平台自己就能生成"。
具体做法分四步：
**第一步：数据库直连，只读不破坏。**
先跟客户拿到数据库的只读账号。这里有个铁律--只读，绝不写。原系统正常跑生产，我们只是从数据库拉一份影子。这套做法叫"零侵入接入"，不修改原系统任何一行代码、任何一张表、任何一个字段。企业风险控制部门看到这一点通常就同意接入，因为出不了事。
**第二步：AI扫描表结构，自动打标。**
拿到数据库连接后，向量空间JBoltAI 的平台第一件事是全库扫描--把所有表名、字段名、字段类型、字段约束、字段样例数据都拉一份。这份东西丢给大模型，让它做三件事：
- 猜每张表是干什么的（订单表、客户表、库存表、生产工单表……）
- 猜每个字段的含义（这个"cust_id"看起来是客户编号、那个"m_code"看起来是物料编码）
- 猜表和表之间的关系（这个字段值域跟另一张表的主键几乎完全重合，可能是外键）
大模型不是万能的，它猜不准的地方会标"低置信度"。这一版结果拿给客户的业务或者IT负责人过一遍，人工确认几十个关键字段，剩下的AI补齐。一个几百张表的老系统，人工确认部分通常一两天就能过完，比让厂商写文档快十倍。
**第三步：本体语义层做字段翻译。**
不同系统里叫法不一样的字段，映射到本体语义层的统一定义。举例：
- MES里的"prod_no"、ERP里的"material_code"、WMS里的"sku_id"，在本体里统一映射到"物料唯一标识"
- 销售系统里的"customer_name"、财务里的"payer_name"、CRM里的"account_full_name"，在本体里统一映射到"客户主体名称"
这一层做完，跨系统查询就通了。老板问"某客户上个月买了多少物料"，平台知道要从销售系统查订单、从CRM查客户主体、从WMS查发货记录，用本体语义把三边关联起来。
**第四步：自动生成接口层。**
前三步做完，平台已经知道每张表是什么、每个字段是什么、跨系统怎么关联。这时候自动生成RESTful或者GraphQL接口就是模板化的事情。上层应用（大屏、语音助手、经营分析）通过这些接口取数，底下系统怎么变都不影响。
这套路径跑下来，一个中型企业的异构系统对接，从传统三个月压到两到三周。向量空间JBoltAI 已经在制造、贸易、能源三个行业各跑了几个项目验证过。
## 三、几个真实的坑
上面讲的路径听起来顺，实际做的时候有几个坑必须提：
**坑1：老系统里的中文字段和拼音字段混用。**
有的字段直接叫"客户名称"，有的叫"kh_mc"，有的叫"custName"。同一张表里三种命名都能见到。AI遇到拼音简写就得靠上下文猜，容易猜错。解决办法是让业务过一遍高频拼音简写字典，一次性给平台补上。
**坑2：字段类型和实际存储不符。**
有的字段类型是varchar(50)，实际存的是JSON字符串；有的是number，实际存的是被应用层拼接过的复合编码。这类字段AI扫不出来，必须靠人工点一遍样例数据。
**坑3：软删除和逻辑删除。**
很多老系统没有硬删除，用一个is_deleted字段做标记，或者用status='X'表示删除。AI默认全量拉数据的话，会把已删除的记录也一起接进来，导致统计口径偏差。这一层需要在字段翻译时明确"删除标记字段"是什么。
**坑4：多套编码规则历史遗留。**
同一个企业里，2015年之前的物料编码是8位，2015年之后改成12位，2020年上了新系统又变成UUID。这三套编码在数据库里同时存在。AI能识别出多套规则，但需要业务确认哪套是当前主流、老编码怎么映射到新体系。这一步不能省。
**坑5：字段冲突需要人工仲裁。**
前面提到的"客户"字段冲突，销售看的是签约主体、财务看的是付款主体。到底本体语义里的"客户"以哪个为准，这不是技术问题，是业务规则问题。必须让客户内部先对齐，然后再落到本体里。
## 四、异构系统对接跟本体语义平台的关系
回到向量空间JBoltAI 一直在讲的本体语义平台产品化。异构系统对接是这套产品的底层能力之一，不是产品本身。
上层看到的是老板问一句话平台答一句话，底下跑的是几十上百张表的关联、字段翻译、语义匹配、口径统一。异构系统对接做好了，本体语义平台才有活水。做不好，上层再华丽也是空中楼阁。
向量空间JBoltAI 在做产品化的时候，把异构系统对接这块能力做成了标准模块。新客户接入的时候，前一到两周专门做数据接入和字段翻译，后面才是配置分析模型、上大屏、上语音。这个节奏是过去50+项目积累出来的经验--数据接入不完整，后面全是坑。
## 五、结束语
企业数据打通这件事，过去十年从ETL到数据仓库到数据中台到数据湖，工具换了一轮又一轮，但异构系统对接这个第一道难关始终存在。向量空间JBoltAI 走的路子是不跟传统工具比谁抽数据抽得快，而是解决"接口文档丢了怎么办"这个真实痛点--把AI和本体语义结合起来，让平台自己就能读懂老系统。
一个纺织企业的老MES能被读懂，一个化工厂的老ERP能被打通，一个物流企业的老WMS能被接进来。这些具体的胜利加起来，才是企业数据集成真正的价值。异构系统对接不是终点，是本体语义平台产品化的起点。向量空间JBoltAI 在这条路上会继续把工具做扎实、把行业模板做厚、把接入速度做快。