公司内部业务系统做了一次大版本升级历史数据要从旧系统迁到新系统。这个活儿一开始排期是3天——财务和业务部门各出一个人专职配合后面还要留出1天核对。最后我们用了RPAAI把整条数据迁移流程压到了30分钟而且不是只图快迁移质量也通过了业务验收。写这篇实录是因为我后来发现很多团队一提数据迁移就想到写脚本、连库、导数据但在权限收紧、系统结构复杂、数据本身又脏又乱的情况下RPAAI的组合反而才是更接近真实人工的解法。文里的思路和坑对做RPA实战、企业内部系统集成的朋友应该有直接参考价值。1. 这次迁移到底难在哪从3天说起1.1 业务背景与数据现状我们的场景是典型的老系统换新系统旧业务系统跑了好几年停掉之前财务要求把主数据、订单明细、附件关系全部迁到新平台。数据量不算特别大——客户主数据6000多条关联订单明细15000多条。听起来不多但难点在于老系统的数据质量很差客户名称有的填全称、有的填简称联系电话一栏里混着手机号、座机、微信号地址栏里还掺杂备注……当年录数据的人怎么方便怎么来根本没考虑后面要迁移。更麻烦的是老系统的导出报表不是一张干净的表格几张Sheet之间结构不一样有的带合并单元格有的有隐藏行列还有几列字段名根本对不上。新系统那边是一套严格的定义客户全称、联系电话、信用代码、地址分得清清楚楚导入模板也卡得死格式不对直接拒收。这种迁移的本质不是复制粘贴而是把一堆无规则的人肉记录翻译成另一套系统能读懂的结构化字段。翻译这件事纯靠人做又慢又累纯靠规则做又挡不住各种例外。1.2 3天是怎么算出来的有人可能觉得6000条数据而已Excel里整一整复制粘贴不就行了。真上过手就知道不是这么简单。我们当时按正规流程拆过工第1步导表、整理字段0.5天。几张表结构不一致有的还有合并单元格和隐藏行列需要人工核对没办法直接拼。第2步数据清洗和字段映射1天。要把旧系统的客户名称/客户简称/联系人映射到新系统定义好的客户全称/联系电话还要处理脏数据这一步最耗人。第3步录入或用系统模板导入1天。新系统有标准导入模板但不是拖个Excel就能成功经常有字段格式不合法、主键重复等问题一批一批返回错误又要人工改。第4步双方核对0.5天。业务部门要抽查财务要核对金额纯人工双人复核磨时间。这还不算中间被打断的时间。所以3天的估算是合理的甚至偏保守。1.3 RPA和AI各自能干哪一段我当时的判断是这个迁移流程里真正吃时间的不是搬运本身而是理解和判断。老Excel格式烂、字段含义模糊需要人去看、去猜、去统一新系统的导入模板又僵硬一次导不通得反复试错。纯人工干这活又慢又容易烦而RPA擅长的是重复操作AI擅长的是语义理解和信息抽取——两者拼起来恰好能覆盖人工3天的绝大部分工作。所以我从最开始就把方案框在RPA动手、AI动脑这个方向而不是去写脚本硬碰生产库。2. 方案选型为什么是RPAAI而不是纯脚本或纯RPA2.1 纯脚本方案为什么被否掉很多人第一反应是写Python脚本直接连数据库一条UPDATE完事。我们没这么干原因很现实一是生产库权限不在我们手里要走审批不说数据库结构老得没人敢动二是数据里包含大量非结构化内容比如扫描件里的备注、手写的纸质表单脚本处理不了三是合规要求所有操作可追溯直接改库很难形成业务认可的留痕。所以我一开始就把方案框在模拟人工操作这个路线上RPA负责打开系统、上传文件、读返回结果AI负责理解那些不太规整的内容。2.2 纯RPA为什么也不够很多公司上RPA喜欢录一个傻瓜流程把点击、输入、回车的动作固定下来。但数据迁移场景有个它处理不了的死结规则太灵活。比如客户名称这一列有的行填的是北京某某科技有限公司有的行填的是北京某某科技还有的行填的是李某负责北京区域——纯RPA按固定规则取数取出来的值八成是错的。只有AI才能像人一样根据上下文判断嗯这里填的其实是客户简称应该取全称那一列。这就是为什么必须RPAAI一个负责动手一个负责动脑。拆开来看都不稀奇合在一起才覆盖得住真实场景。2.3 分工设计与工具选型我们最终用的工具组合RPA端用了影刀RPA主要看中它对国内系统兼容性好、有丰富的组件库、调试方便AI端直接接通用大模型API用来做字段理解和结构化抽取同时用RPA自带的OCR能力处理扫描件。整体分工是环节负责人职责导出与读取RPA自动登录旧系统/读取本地Excel脏数据识别AI识别这句话里哪个部分是客户名、哪个是电话字段映射AIRPA规则AI给映射结果规则做兜底系统导入RPA按新系统模板组织数据、上传、抓取报错校验对账AIRPAAI抽查语义RPA做数量/金额对账这里有个选型心得不要一上来就追求全自动先把流程拆成人能看懂的步骤再逐步让机器接管。工具永远是为流程服务的不是反过来。2.4 整体流程与关键角色我们在本地搭了一个数据中间层所有AI处理结果先落到一份JSONExcel再交给RPA去执行。中间层很重要它让每一步都可审计。整个流程的骨架是旧系统导出 → AI清洗映射 → 中间结果确认 → RPA按新系统模板导入 → 自动校验反馈。这个结构让我在后面踩坑的时候能很快定位问题AI错了看JSONRPA错了看运行日志不混在一起。建议做同类项目的人也保留这个习惯——中间产物别嫌占地方它就是你出问题时的监控录像。3. 30分钟是怎么实现的核心步骤拆解3.1 第一步RPA读取与标准化我们先用影刀做了一个数据抽取流程自动打开旧系统导出报表把几张Excel汇总成统一格式。这里有几个动作细节很关键先遍历Sheet去掉空Sheet对存在合并单元格的表先取消合并并填充隐藏行列如果影响读取直接识别并跳过统一列名旧表里叫客名的、叫客户名称的、叫名称的全部归到标准名。这一部分用RPA做主要是为了可重复。以后如果有人再导出来一份新数据跑一遍就标准化了不用再手工折腾。实际敲定的时候我们还针对日期格式做了处理Excel里有的日期是2023/1/1有的是2023年1月1日RPA在读取阶段就统一转成标准字符串省的后面AI还要花时间去猜。3.2 第二步AI字段映射与清洗标准化之后最难啃的骨头来了字段映射和脏数据识别。我的做法不是直接让AI自由发挥而是写了一个固定格式的提示词让AI按JSON结构返回结果你是数据迁移助手。下面是旧系统的客户表记录请按新系统字段定义抽取并映射。 字段定义客户全称、联系电话手机/座机、联系人、统一社会信用代码、备注。 要求 1. 只输出JSON数组不要解释 2. 无法确定的值填 UNKNOWN禁止编造 3. 联系电话只保留数字和-去掉手机Tel等前缀 4. 客户全称优先取公司全称如果整行只有简称则保留简称并在备注中说明 5. 日期字段统一输出为 YYYY-MM-DD。 输入如下 ...用这个提示词批量喂给大模型返回的JSON我再写了一段规则代码去做二次校验比如电话号码必须满足正则、统一社会信用代码长度必须为18位。规则能判定的走规则规则判不了的才用AI结果——这种AI规则双保险比纯AI输出稳定得多。3.3 第三步RPA自动录入与异常拦截AI清洗完数据之后我们不是让RPA去新系统里一条一条手工录入而是先把结果组织成新系统的标准导入模板然后用RPA完成登录 → 进入导入界面 → 上传文件 → 等待返回 → 解析错误的循环。这一步把原来的1天压缩到了不到10分钟。具体RPA流程里有几个骨架节点启动影刀客户端打开新系统网址若页面出现验证码转入人工处理队列我们做了提示弹窗上传Excel后轮询等待导入结果发现失败原因列有内容自动截图并记录到日志全部成功或失败清单生成后RPA关闭流程并发送通知。这里我特别强调失败清单RPA不负责把所有错误都修好但必须把错误记录得清清楚楚谁能看到哪一行因为什么原因失败这样处理的人不用再翻系统。3.4 第四步自动校验导入之后不能拍拍手就结束了。我们让RPA自动从新系统导出已导入数据和旧系统的汇总做对账条数、金额、主键重复情况。另外抽了50条把原始记录→AI映射→导入后的值并排放在一张表里人工扫一遍做语义确认。这一步很快但对验收特别重要。我后来跟业务部门汇报的时候用的就是这50条抽查表和两张汇总对账单——没有任何技术术语但对方看了就点头。因为业务方真正关心的不是你怎么实现的而是迁完之后数对不对、钱对不对。4. 踩坑实录最折磨人的四个问题4.1 AI识别翻车字段解析不稳定的排查链路第一个坑来得特别快。第一版提示词写好后我拿20条数据做小样验证准确率91.5%看着还行直接跑了200条。结果拉到中间层一看几十条联系电话带了手机前缀还有几条把地址里的某某街道当成了联系人。排查链路是这样的先抽了25条输出和人工标注对比发现错误集中在联系电话和联系人两个字段回到原始数据发现问题根源是老系统里这两列经常混放比如联系人列填的是张三/138xxxx电话列填的是021-xxxx 转 财务。AI对混排内容的理解不稳定。解决办法分三层改进提示词明确告诉模型联系人字段如果同时包含人名和电话只提取人名电话字段如果包含多个号码取第一个有效号码增加few-shot示例每个字段给两个脏数据→期望输出的例子加规则兜底凡是AI输出里带手机Tel转这类关键词的先用正则清洗一遍再入库。改完后同样20条小样准确率从91.5%到了98.7%。这给我一个特别深的经验不要指望一次prompt就完美AI输出必须有规则层做安全检查。4.2 元素定位的坑被iframe和动态ID支配RPA录制新系统导入按钮的时候一切正常一跑起来就偶发找不到元素。最诡异的是同一段脚本上午能跑通下午就挂在同一个步骤。我打开浏览器的开发者工具逐个看DOM发现这个页面用了两层iframe——外层的iframe加载框架内层的iframe才是真正的业务页面。影刀默认在顶层文档找元素找不到就报错。解决办法是先在RPA流程里加进入框架操作一层一层切进内层iframe再用类名或文本定位不要依赖带随机后缀的动态ID。这次排查的教训是RPA脚本报元素不存在不代表元素真的不存在而是在当前上下文里没找到。优先检查所在frame、窗口焦点、以及页面是否还在加载。后来我把这个检查顺序写成了团队内部的标准排查流程再有人报类似问题先按这三步过一遍基本能解决八成。4.3 批量导入把流程跑挂了AI清洗后的主数据拆出来有5000多行我第一次直接用RPA上传给新系统结果系统直接提示文件过大或长时间无响应。后来发现新系统导入模板其实有行数限制大批量上传还会触发内存问题。解决方式很粗暴也很有效按500条一个批次拆分一个批次导入完、确认返回结果后再导入下一批。同时RPA里加了每次上传后等待结果页完全加载再继续的判断超时自动重试两次。拆批之后整个导入过程反而更稳定而且某个批次出问题不需要全部回滚。这里有个容易忽略的细节拆分批次时不能只按顺序硬切要把存在关联关系的记录尽量放在同一批。比如同一个客户名下的多个订单如果分到不同批次第一批导入了、第二批失败了中间态就是有订单但客户还没迁移完对账会非常痛苦。4.4 AI接口超时与限流从单条调用到批量合并最开始我设计的AI处理是逐条调用6000多条记录每条调一次大模型接口。理论上一分钟能跑几十条实际跑起来问题不断单条调用有网络延迟偶尔超时跑一半触发接口限流整个流程直接卡住。后来改成批量合并把标准化后的数据按50条一组拼成一段文本一次性让大模型返回50条的JSON数组。调用次数从6000次降到120次单次消耗的token更多但总时间从预计的几小时降到几分钟限流问题也基本消失。这个改动的核心认知是AI在处理批量结构化抽取时的效率远高于逐条只要你把输出格式约束好完全可以让它一次处理一组数据。但要注意批量返回的内容必须再做一次JSON解析校验防止模型返回残缺数组。我们当时就遇到过一次批量返回把最后两条截断的情况靠解析异常捕获才发现。5. 数据迁移速度不是唯一指标质量与回滚设计5.1 事前20条样本验证在正式跑全量之前我们花半小时做了样本验证从旧表里随机抽20条人工把期望结果标好然后让AI输出结果对比。只有准确率达到97%以上才允许全量执行。这个步骤成本很低但能在大规模处理前把明显的方案问题暴露出来。后来我在复盘时觉得20条其实偏少最好是每个容易出错的字段单独抽20条比如联系电话抽20条、客户名称抽20条这样能更早发现字段级别的规律性问题。5.2 事中三段式留痕我在整个流程中做了原始值→AI映射值→最终导入值的三段式留痕。每一条数据都有对应的JSON记录原始数据长什么样、AI判断了什么、RPA最终写了什么。这个设计在业务方质疑这里怎么和原来不一样的时候特别好用直接调出三段记录一眼能看出是AI理解偏差、规则清洗还是导入环节写错。留痕的格式没有用特别复杂的系统就是一份带时间戳的JSON文件按批次归档。但就是这个简单的动作省掉了无数次嘴上说不清、只能打开系统当场翻记录的扯皮。5.3 事后对账与回滚数据导入完成后RPA自动从新系统导出最新数据与旧系统做三种对账对账项方法数量一致主数据条数、订单明细条数逐一对比金额一致按客户汇总订单金额比较合计主键唯一检查新系统里有没有重复的客户编号对账通过后还抽了50条做人工语义复核。如果发现问题回滚方案是用备份好的CSV 新系统批量删除功能把本次导入数据清空修好清洗规则后重新导入。因为整个过程是分批的回滚颗粒度也很小不会牵连历史数据。这块我多说一句回滚一定要在迁移开始前就设计好不要等出错再临时想。我们当时把导入批次表维护在本地每一批导入的文件名、时间、行数、状态都记录清楚回滚的时候直接按批次号过滤干净利落。6. 复盘这套RPAAI组合还能用在哪儿6.1 可复用的迁移方法论这次项目让我确认了一件事凡是人工在多个Excel/系统界面之间搬运数据还要靠脑子理解内容的活基本都可以套用RPAAI的框架。比如供应商档案清理、历史订单补录、库存盘点表整理、报销单信息抽取。方法论上可以抽象成四步标准化读取、AI语义理解、RPA自动化操作、自动对账。每一步都保留中间产物方便审计和回滚。具体到场景我觉得最值得优先尝试的是两类一类是表格字段混乱程度高的数据整理一类是需要登录多个系统做重复录入的操作。前者AI发挥价值后者RPA发挥价值合在一起效果会很明显。6.2 以后再做我会调整什么如果下次再做类似迁移我会在几个地方直接改进一是AI清洗结果先做一轮机器抽检人工抽检再全量跑而不是全量跑完才看准确率二是为AI调用做本地缓存同样一批数据重复处理时秒出结果三是所有失败数据先进人工确认队列而不是直接失败停机。这次踩坑的经验告诉我速度不是数据迁移的终点可控和可追溯才是。任何新工具组合都要先想清楚出了问题怎么定位、怎么回滚再谈效率。最后说点个人的真实感受。30分钟跑通第一个批次的时候我们团队其实并没有兴高采烈而是反复看了三遍对账结果。原因很简单数据迁移这种活最怕的不是慢而是看起来成功了实际上错了。RPAAI的组合能不能被信任靠的不是技术本身多先进而是你有没有把校验、留痕、回滚设计到位。这套方法跑下来业务部门最后给的评价是你们怎么这么快我们还没来得及核对。但真正让我放心的不是那30分钟而是每一笔数据都能从新系统一路追回原始记录的底气。