两个系统字段对不上，用 AI 出一张可核对的映射表

一句话结论

字段映射能不能交给 AI，关键不在模型多强，而在你给没给它取值样本：先出候选表，再用真实数据逐条核，人工只做裁决不做检索。

这篇解决什么问题

老系统迁数仓、跨库取数、对接第三方接口，几乎都会撞上同一件事：两边字段名对不上，语义还似是而非。适用的情况是字段清单能导出、关键字段能取到脱敏样本值。不适用的是字段本身没有稳定含义，或者一方压根没有数据字典，那种得先把文档补出来再谈映射。

开始前要准备什么

• 豆包或通义的网页版就行，日常免费额度跑几十轮对话够用
• 两边的字段清单：字段名、类型、备注，先导成纯文本
• 每个关键字段十来条脱敏样本值，值域类的多给几条
• 一张空表模板：序号、源字段、目标字段、规则、结论
• 时间预算：字段五十个以内，一轮坐下来通常 1 小时上下

具体怎么做

第 1 步 · 把两边字段清单整理成纯文本

别丢 Excel 截图，模型读表格图片时常漏行，还看不全备注。把两边的字段名、类型、备注按行抄成文本，一段给 A 系统，一段给 B 系统。这一步看着像纯手工，其实决定了后面所有输出能不能被核对。

你是数据建模工程师，帮我做两个系统的字段映射。这一轮先不做映射，只做整理。
A 系统：老客户中心，表 cust_main
B 系统：新数仓宽表 dwd_customer_df
请完成三件事：
1. 把两边字段清单整理成统一三列：字段名 / 数据类型 / 备注（没有备注写 -）；
2. 单独列出两边明显同义、几乎不用判断的字段；
3. 指出哪一边信息不足，需要我补什么才能继续。
A 系统字段：
cust_id varchar 主键
cust_name varchar 客户名
cust_mobile varchar 手机号
cert_no varchar 证件号
cust_type char 1 个人 2 企业
reg_date date 注册日期
src_channel varchar 来源渠道
is_del char 0 正常 1 删除
upd_time datetime 更新时间
B 系统字段：
customer_id string
full_name string
mobile_no string
id_card string
customer_category string
create_time string
channel_code string
delete_flag int
etl_time string

预期产出：两份结构统一的字段清单，外加一份”明显同义、几乎不用判断”的白名单。

第 2 步 · 让模型出第一版候选映射

这轮只要求它列候选和依据，不许它下结论。我在实操中发现，只要提示词里明确允许它回答”没有对应”，胡编的映射会少很多——不少错误是被”必须配上”的暗示逼出来的。

基于上一轮的字段清单，输出第一版候选映射表，按下面要求来：
1. 一行一组映射，列为：A 字段 / B 字段 / 关系类型（一对一、一对一拆分、一对多、无对应）/ 置信度（高、中、低）/ 判断依据 / 待确认问题；
2. 判断依据要写清是靠字段名、类型、备注还是业务常识，不要只写”名称相似”；
3. 明确列出 A 有 B 无、B 有 A 无的字段，不要强行配对；
4. 置信度低的行，写出你缺哪条信息才能提高判断；
5. 这一轮不要输出 SQL，只要映射表。

预期产出：一张候选映射表，每条都带判断依据和待确认问题。

第 3 步 · 补取值样本做二次校验

字段名像、值是两回事的情况太多了。像状态位这种，一边是 0/1，一边是 personal、enterprise 这样的字符串，光看名字永远判不出来。给关键字段贴十来条脱敏样本，让它从值域反推关系。

下面这些字段我附了脱敏后的真实取值，请重新评估映射关系。
cust_type：1,1,2,1,2,2,1,1,1,2
customer_category：personal,enterprise,personal,personal,enterprise,personal,personal,personal,enterprise,personal
is_del：0,0,1,0,0,0,0,1,0,0
delete_flag：0,0,1,0,0,0,0,1,0,0
reg_date：2021-03-04,2020-11-19,2019-07-30,2022-01-12
create_time：2021-03-04 09:12:33,2020-11-19 17:03:08,2019-07-30 08:45:51,2022-01-12 22:10:04
要求：
1. 能对上值域的，直接写出对应规则，比如 1=personal、2=enterprise；
2. 对不上的标”需人工确认”，不要猜；
3. 更新置信度，并说明每一条为什么升或降；
4. 输出表格：A 字段 / B 字段 / 值域映射规则 / 置信度 / 变化原因。

预期产出：带值域映射规则的映射表，以及一批被明确标成”需人工确认”的条目。

第 4 步 · 让 AI 生成核对清单而不是结论

这一步是整件事的分水岭。让它把”怎么验证”写出来，你照着打勾，而不是让它告诉你”这条没问题”。核对方法落到空值率、长度分布、枚举覆盖这些查得动的东西上，才算可执行。

针对每一条候选映射，生成一份可逐条打勾的核对清单。用表格输出，列固定为：
编号 / A 字段 / B 字段 / 核对方法 / 通过标准 / 结果（留空）
核对方法从下面几类里选，并写清参数：
– 空值率对比：两边分别统计，差值超过 5 个百分点记为不通过
– 长度分布：比较最大长度和前 10% 分位长度，判断有没有截断
– 枚举值覆盖：列出 A 的全部取值，逐个确认在 B 里能否找到
– 唯一性：主键候选字段做去重计数，和总行数比对
– 时间格式：写出两边样例，标注时区和精度差异
结果列全部留空，我自己填”通过 / 不通过 / 待定”。不要替我下结论。

预期产出：一张能逐行打勾的核对清单，结果列空着等你填。

第 5 步 · 回灌核对结果，生成最终表和转换规则

核对完把结果贴回去，让它出最终版。人工只处理清单里”不通过”和”待定”的那几行，其余默认通过。这部分通常占大多数，效率真正省下来的地方就在这儿。

下面是我逐条核对后的结果，结果列已经填好。请基于它生成最终字段映射表。
1. 只保留”通过”和”待定”的行，”不通过”的行单独列在表尾并写明原因；
2. 最终列为：序号 / A 字段 / B 字段 / 转换规则 / 类型转换 / 是否必填 / 负责人（留空）；
3. 转换规则写成一句人话加一段伪代码，例如 cust_type 的 1 转 personal；
4. 字符串时间字段写清解析格式和目标格式；
5. 最后给一段 20 行以内的清洗 SQL 草稿，字段名以 B 系统为准。
核对结果如下：
（把上一步的表格粘到这里）

预期产出：一份带转换规则和伪代码的字段映射表，末尾附一段 SQL 草稿。

实测记录

两次返工都栽在同一处：想省事，跳过第三步直接把名字像的字段配了对，结果客户类型和删除标记全反了。补上样本重跑一遍，问题当场暴露。

最容易错的 3 个地方

1. 只给字段名不给取值：同名不同义必错，先补样本再判
2. 一次把全部字段丢进去：注意力被稀释，按主题分批映射
3. 把 AI 的表当结论：没人打勾就上线，结果列必须留白

可复用的东西

五个提示词其实是一条链：整理清单、出候选、值域校验、出核对清单、回灌生成最终表。链条里唯一不能省的是第四步，它把”AI 的判断”换成了”你能验证的清单”。

复用时只换三样东西：两段字段清单、关键字段的样本值、核对结果表。其余措辞基本不用改，尤其是那句”不要替我下结论”，留着能省掉大量返工。

字段映射这活儿，AI 负责的是把检索和起草这段压缩掉，判断权始终在你手上。你手上那套系统里，最难对的是哪一类字段？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接