用 AI 规划数据迁移：别只搬表，要保住口径、关联和可恢复性
数据迁移不是复制表格。本文讲清如何用 AI 辅助源盘点、字段映射、质量修复、增量同步、分层对账、切换和回滚。
旧系统有八十万条客户记录，团队让 AI 写了迁移脚本，测试环境里运行成功，行数也完全一致。切换后却发现手机号前导零丢失、同一客户被合并、历史订单时区偏了八小时，部分已停用账号重新变成有效。数据确实“搬过去了”，业务含义却变了。
AI 可以读表结构、生成映射草案、发现异常和起草校验查询，但数据迁移不是复制文件。它必须证明迁移了正确对象、保留了业务语义、没有遗漏与重复、切换期间变化可控、失败后能够恢复。
迁移成功的标准不是脚本执行完，而是目标系统里的业务事实仍然正确。
先定义迁移目标与边界
明确迁哪些业务对象、保留多久历史、哪些数据归档、哪些系统继续读写、切换窗口和合规要求。不要从数据库表名推断范围：一个“客户”可能分散在账户、联系人、地址、同意记录和外部身份系统中。
建立源数据清单
记录数据源、表或接口、所有者、规模、更新频率、主键、质量问题、敏感等级和下游使用者。影子表、手工表格、定时导出和第三方系统经常不在架构图里，却可能参与真实业务。
字段映射必须包含语义
| 映射内容 | 示例问题 |
|---|---|
| 来源与目标 | 旧字段对应哪个新字段？ |
| 类型与格式 | 字符串日期如何转换时区？ |
| 业务口径 | “有效”在两套系统定义相同吗？ |
| 默认值 | 缺失值是未知、零还是不适用？ |
| 转换规则 | 枚举、单位、精度怎样转换？ |
| 责任人 | 谁确认这条规则正确？ |
AI 可以根据名称和样本提出候选映射，但相似字段名可能含义不同。每条高风险规则都要由领域负责人确认，并配正例、反例和边界样本。
不要把脏数据悄悄“修好”
空值、重复、非法枚举和断裂关联需要明确策略：阻断迁移、隔离待处理、按规则修复或原样保留。模型擅自猜测缺失生日、性别、地区或客户归属，会制造无法追溯的新事实。修复必须有规则、记录和批准。
先做数据画像和基线
统计总量、非空率、唯一值、分布、极值、引用完整性和按关键维度的分组数量，形成迁移前基线。迁移后使用同样口径比较。仅比较总行数，会漏掉一边重复一边缺失、金额互相抵消等问题。
主键和身份合并最容易出大错
旧系统多个 ID 可能映射到一个新客户，也可能一个账号下有多个合法联系人。先定义身份规则、冲突优先级、不可自动合并条件和人工复核。保留旧 ID 到新 ID 的映射表，便于追踪、重跑和处理售后。
迁移顺序要尊重依赖
先迁基础字典和主对象，再迁引用它们的交易、明细和日志；或者设计临时键和补链过程。外键只是数据库约束，业务依赖还可能藏在缓存、搜索索引、文件、消息和下游报表中。
全量与增量要能衔接
大迁移常先做全量，再同步切换前新增和修改的数据。必须定义增量起点、变更捕获、删除事件、顺序、重复处理和水位线。时间戳不是天然可靠游标，同秒更新、时钟差异和延迟写入都可能造成漏数。
迁移脚本必须可重入
任务中断后应能安全重跑，不因重复执行创建重复对象或二次扣减。为批次、源记录和目标结果保留状态，明确失败隔离与重试规则。AI 生成的脚本必须经过代码审查、固定依赖和隔离环境测试。
验证要覆盖数量、内容和业务
| 验证层 | 检查方法 |
|---|---|
| 结构 | 表、字段、约束、索引与权限 |
| 数量 | 总量及按状态、日期、地区分组 |
| 内容 | 哈希、精度、格式、空值和关联 |
| 业务 | 余额、订单、权益和核心流程 |
| 用户 | 典型账户与高风险边界样本 |
抽样不能只抽“看起来正常”的
结合随机抽样与风险抽样：最大金额、最早日期、长文本、特殊字符、跨时区、重复候选、缺失字段和历史异常记录。少数高价值错误可能不会改变总体指标，却会造成严重客户影响。
切换计划要写到分钟和角色
明确冻结写入、最终增量、验证、切换连接、清缓存、业务验收和开放流量的顺序。每一步有执行者、预计耗时、成功信号、停止条件和决策人。避免多个团队同时修改源与目标。
回滚不只是把连接切回去
如果新系统开放后已经产生新订单或状态变化，直接回旧系统可能丢数据。设计反向同步、双写、只读窗口或前滚修复，并明确不同失败时刻采用哪种方案。必须演练权限、备份恢复和实际耗时。
保护敏感数据和审计证据
临时导出、测试库、日志和错误样本同样需要加密、最小权限、脱敏与删除期限。不要把生产个人信息直接交给外部 AI。记录谁批准规则、谁运行批次、改了什么和验证结果。
上线后还要观察延迟问题
搜索索引、周期账单、通知和下游数仓可能在数小时或数天后才暴露问题。规定观察期、对账频率、用户反馈入口和旧系统退役条件，不要切换当天正常就立即删除源数据。
切换前做影子运行和业务签字
条件允许时，让新系统在不承担正式写入的情况下处理同一批输入，与旧系统比较结果。差异要分类为预期规则变化、数据问题或程序缺陷，不能为了让数字一致而直接忽略。最终由数据负责人确认对账，业务负责人用真实流程验收，技术负责人确认性能与恢复；三者关注的成功标准并不相同。
AI 辅助迁移流程
- 输入脱敏的架构、字典、样本和业务规则。
- 生成源清单、映射候选、冲突与待确认问题。
- 领域人员批准语义、清洗和合并规则。
- 在隔离环境试迁并保存基线。
- 执行结构、数量、内容和业务多层验证。
- 演练增量、切换、失败恢复和回滚。
- 生产迁移后持续对账，达到条件再退役旧系统。
可直接使用的提示词
“你是数据迁移审查助手。只能依据编号数据字典、规则和脱敏样本。先列业务对象、源、目标、主键、敏感级别、更新方式和下游依赖；随后输出字段映射、类型与单位转换、默认值、冲突、未知项和责任人。禁止猜测缺失数据。为每条高风险规则设计正反例，并给出全量与增量衔接、幂等重跑、分层对账、切换停止条件、回滚及上线后观察计划。”
切换前检查
- 总行数之外是否验证业务语义和高风险样本？
- 身份合并和缺失值是否有批准规则？
- 增量水位、删除和乱序事件是否处理？
- 脚本能否安全重跑并追踪每条记录？
- 回滚是否处理新系统产生的数据？
- 旧系统退役是否有观察期与审计证据？
AI 可以加速映射和校验设计，却不能替业务定义一条数据真正代表什么。把迁移当成业务事实的重建工程，而不是一次文件搬运，团队才有机会在切换后仍然相信自己的系统。
本文为读懂 AI 原创内容。迁移客户、员工、财务或身份数据时，请遵守数据最小化、权限、隐私、安全、留存与审计要求，并在隔离环境完成验证。
