开头可以先抛出结论很多团队以为数据迁移就是写脚本、导数据但实际上内部业务系统的情况远没那么简单特别是老系统字段乱、流程散、数据也不规范靠人工一点一点搬既慢又容易出错。我们这次做的项目就是把一个物料主数据的全量迁移从原来的人工3天压缩到RPAAI联合处理的30分钟。中间踩了不少坑但最后跑通的方案应该能帮到不少面临同样问题的团队。1. 项目背景与问题定位为什么3天的工作量能压到30分钟1.1 内部系统的历史遗毒迁移难的根本原因这个项目发生在公司内部目标系统是一个跑了好多年的业务管理系统。所谓物料主数据全量迁移其实就是把旧系统里几千条物料基础信息包括物料编码、名称、规格、单位、分类属性、采购信息、库存维度等同步到新系统里。听起来不就是一张表导到另一张表吗真正做过的人知道哪有这么简单。老系统的数据有几个特点字段含义和值域完全不标准比如单位一列里既有个又有PCS还有只关键信息散落在多个界面和附件里系统列表页看不到全部字段必须逐条点进去才能看到部分属性还是图片或者PDF形式的质检报告人工得打开附件去读内容有的物料存在重复编码、失效状态、历史遗留数据需要通过业务规则做判断。一开始团队走的是传统数据迁移路线让业务人员每天打开旧系统一条一条看再手工录入新系统。这个做法的结果就是3天起而且累得够呛还容易漏字段。我们做智能化的目标就是把这样一个3天的场景拆解成机器能自动跑的动作。1.2 为什么不用纯API对接而要用RPA可能有人会说直接调数据库或者调用后端API做数据导出导入不就行了。这个思路业务系统如果支持当然好但实际阻力很大旧系统是很多年前外包开发的没有文档数据库表结构没人说得清新系统虽然有API但接口权限归IT部门管走审批流程就很麻烦迁移不是一次性动作后期还有增量同步和变更处理不能一直依赖业务方提工单。RPA的价值在于它绕过了系统底层集成模拟人在界面上的操作不改造现有系统。在这个项目里旧系统打开页面、查询数据、复制字段这些操作都能由RPA完成而不需要动旧系统的一行代码。1.3 AI在这里到底解决什么问题RPA本身擅长读界面、填界面但面对非结构化数据就抓瞎了。物料描述里可能存在各种写法螺丝 M4*10 304不锈钢和304不锈钢十字盘头螺丝M4X10指同一个东西但RPA无法判断。这就要AI来做语义理解和字段归一化。另外系统里许多规格参数藏在PDF质检报告或Word工艺文件里。RPA无法解析这些没有固定版式的文档而AI OCR加上大模型的信息抽取可以把标题、热处理要求、材质报告这些信息提取出来转成结构化字段。所以在这个项目里AI负责看懂和判断RPA负责执行和搬运两者分工明确。2. 方案选型RPAAI组合的边界与分工2.1 主流程与辅助流程的设计思路我们最终采用的架构是RPA总控调度 AI能力中台 人工复核兜底。整个流程分成三段数据采集段RPA登录旧系统按照物料清单逐个查询记录、进入详情页把页面上的字段抓取下来。对于页面上的附件下载到本地指定目录交给AI处理。数据处理段AI先做OCR识别再通过大模型的信息抽取和字段归一化输出标准化的JSON数据。同时规则引擎检查必填项、枚举值、长度限制把异常数据单独标记出来。数据写入段RPA根据AI输出的结构化结果登录新系统按照界面顺序一条条创建物料录入完成后截图存档并记录成功或失败状态。这个设计里最关键的一点是不要让AI一次性处理所有字段而是只处理需要理解的部分比如名称标准化、规格提取、分类映射那些枚举值固定、格式明确的字段比如创建人、创建时间完全可以通过规则直接透传减少AI调用成本和出错的概率。2.2 RPA平台选型为什么选中了它在选型时我们对比了好几款主流RPA工具。公司里当时已经在用影刀RPA所以就优先测试了影刀的社区版和企业版。另外也看了金智维和国外的一些产品最终选择影刀有几个原因支持Python扩展可以在流程里直接调用AI接口不用额外写Web Service操作录制相对智能能识别网页元素旧系统虽然老旧但有ID属性识别准确率能达到95%以上有流程编排面板能把打开页面、抓取数据、调用AI、回写数据这些步骤可视化后期维护方便。当然如果你们公司已经有其他RPA工具比如实在RPA、UiBot也完全可行。关键是看它有没有开放接口、支不支持Python脚本嵌入、能不能在不稳定网页环境下做容错。2.3 AI能力选型大模型不是万能的OCR也要配套AI部分我们用了两段式处理OCR层使用PaddleOCR做本地识别。原因是业务资料涉及大量表格、手写批注其他公有云OCR对特殊字体识别效果不稳定且数据安全不允许把内部物料信息发到外部服务。PaddleOCR部署在内网服务器识别精度通过调参能达到相对理想的效果。语义层在内网部署了一个开源大模型的API服务主要做三件事物料名称标准化、从文本中抽取规格参数、把旧分类映射到新分类体系。因为公司不允许使用外部大模型所以私有化部署是唯一的合规路径。这里我得提醒一句大模型的输出有随机性不能直接拿输出结果去写生产系统。我们为每个AI调用都加了JSON Schema校验不仅校验字段类型还校验枚举值是否在业务允许范围内。校验不通过的数据会进入人工处理队列而不是卡死整个流程。2.4 人工复核兜底设计任何自动化方案如果完全没有人工参与上线风险都很大。我们的兜底逻辑是RPA每处理完100条数据就暂停一次人工抽检10条发现异常则调整模型参数或补规则所有AI识别置信度低于阈值的字段自动标黄提供一个人工复核界面操作员可以逐条查看原始截图、AI提取结果和标准化结果确认或修改后再触发RPA写入新系统。这个设计看起来简单但在实际运行中帮我们挡掉了至少好几百条因为历史脏数据导致的错误。3. 核心实施过程数据迁移完整链路拆解3.1 第一步老系统的数据采集怎么做才稳老系统是一个B/S架构的页面RPA需要在登录态下打开查询页面每页显示10条记录手动一条条点进去。RPA流程大致是这样的1. 打开浏览器访问旧系统URL 2. 输入账号密码等待首页加载 3. 进入物料管理菜单输入待迁移的物料范围 4. 循环每页记录 a. 读取列表页当前行的物料编码 b. 双击物料编码或点击详情按钮 c. 等详情页加载完成 d. 抓取页面指定字段的值 e. 如果有附件点击下载并记录附件文件名 f. 返回列表页继续下一行 5. 将采集到的字段数据写入本地JSON文件 6. 记录本轮采集进度已处理/总量这里有几个细节特别重要等待条件不能用死等而是要在页面元素出现后再执行下一步否则系统慢的时候很容易误判下载附件时要注意文件名重复建议按照物料编码附件类型时间戳重命名列表页翻页和详情页返回一定要抓到稳定的控件有些旧系统点返回按钮弹出确认框需要额外处理。起初我们没太在意这些结果前两轮跑下来不是漏了记录就是下载了空文件浪费时间排查才发现都是等待条件写得不够严谨。3.2 第二步AI处理环节的提示词与字段映射AI处理是最有技术含量的部分也是踩坑最多的部分。我们给大模型设计了一套结构化提示词核心是让输出严格符合JSON格式。以物料名称标准化为例你是物料主数据标准化助手。用户会提供一条物料信息里面包含原始名称、规格描述、附件文本等。请根据以下规则输出 1. 物料名称统一为【材质】【产品类型】【规格】【表面处理】如304不锈钢内六角圆柱头螺钉M4x10 2. 如果无法判断不要编造输出UNKNOWN 3. 只输出JSON格式为{standard_name:...,spec:...,material:...,unit:...}大模型当时能够返回一个看起来还不错的输出但有两个隐患一是偶尔会输出Markdown代码块也就是在JSON外面加json 包裹直接导致解析失败二是会把一些无法判断的字段填上推测值这个非常危险。针对这两点我们在AI接口外层封装了文本清洗模块和字段校验模块。清洗模块负责去掉代码块标记、多余空格、转义符校验模块会检查每个字段的合法性、枚举值是否在业务表里。def extract_ai_json(text): text text.strip() # 去掉 json 包裹 if text.startswith(): text re.sub(r^[a-zA-Z]*\n?, , text) text re.sub(r\n?$, , text) return json.loads(text)3.3 第三步新系统的写入策略与并发控制数据写入新系统时一开始我们是一条条按顺序写每写一条要等页面刷新完成速度很慢。后来改成多实例并发写入——开三个RPA机器人同时工作每个负责不同批次的物料编码写入速度提升明显。但并发也带来了问题新系统本身有账号并发数限制同时点多条数据可能导致会话互踢或者审批流程混乱。后来我们做了个简单的并发闸门最多允许3个RPA实例同时写入每个实例每处理完一条数据间隔1秒再操作下一条写入失败时自动重试两次两次失败就扔进错误队列而不是无限重试。这样既保证了速度又不至于把新系统怼出问题。3.4 第四步异常检测与日志设计自动化最怕的不是报错而是报错后不知道错在哪。我们花了不少功夫在日志和监控上每个物料编码分配一个唯一任务ID从采集、AI处理到写入所有日志都带上这个ID每一步的关键数据都存一份副本方便回溯异常数据单独生成Excel文件标明异常原因比如单位字段无法识别分类映射失败必填项为空等每天跑完定时任务后RPA自动发送一份汇总报告到邮箱包含成功数、失败数、各类异常的数量分布。这套日志系统虽然朴素但在后续调优和给业务部门解释的时候帮了大忙不然出了问题说不清到底是RPA漏抓还是AI识别错。4. 踩坑实录我们在这30分钟背后踩过的那些坑4.1 第一个大坑RPA抓取页面数据时字段顺序错位我们第一次跑通全流程是在测试环境一切正常。但到了生产环境开始正式跑时发现写入新系统的数据里有相当一部分张冠李戴——物料名称跑到规格字段里单位跑到分类字段里。排查了半天最后发现原因在于旧系统某些详情页布局不完全一致。比如大部分物料的规格字段在第5行但有些物料会在第3行多显示一个别名字段后面的行就整体往下顺延了。RPA如果按照固定的坐标或者固定的XPath去取值一旦页面结构有变化就会抓到错误的字段。解决方案是换用更聪明的定位方式优先通过字段标签比如规格、单位定位后面的值元素不依赖绝对位置而是根据标签元素的相邻节点动态查找匹配值如果找不到预期标签则记录该条数据为页面结构异常而不是随意取值。改完之后字段错位的问题基本绝迹。4.2 第二个大坑AI对历史数据的幻觉式补全这是一个非常值得警惕的问题。在测试阶段我们拿了一批相对干净的物料数据AI识别效果很好。结果一上真正历史数据发现大模型偶尔会做一些贴心的补全——比如旧系统的材质字段是空的但AI通过物料名称推测出该螺丝可能是碳钢就自信满满地填了个碳钢。在业务上这就是严重的错误。物料主数据的材质属性直接影响采购和质检流程不能靠模型猜。我们后来加了两道防线提示词里加上了强约束如果原文没有明确提及该字段信息必须输出空字符串或UNKNOWN禁止推测。在代码里对每个AI返回的字段做了和原文的引用比对也就是AI必须输出它依据的是原文中的哪一段文字如果无法引用就不允许写入。这个方法实际上就是现在常说的RAG思想识别结果需要能追溯来源否则宁可缺失也不能乱填。4.3 第三个大坑附件下载和OCR的并发打架附件处理是整个流程里最容易形成瓶颈的地方。一开始设计是RPA边抓取边调OCR每到一个有附件的物料就立即下载、识别、提取。结果跑多了发现OCR服务经常超时RPA进程被阻塞整个流程越跑越慢。后来调整为了采集与处理分离RPA先只负责快速抓字段和下载附件不调用OCR所有附件下载到本地后由AI处理程序异步批量识别每个物料的数据合并阶段唯一标识关联附件识别结果。这样改造之后RPA不再被OCR拖累30分钟跑完整个流程成为了可能。可以说这个调整是整个项目从看起来能跑变成真正高效的关键一步。4.4 第四个大坑数据校验时不只要查空值还要查语义合法性我们也在校验环节踩了坑。初期校验只检查了必填项是否为空长度是否超限结果仍然有漏网之鱼。比如单位字段填了个和PCS虽然非空但在新系统里对应的值域只有三个枚举值不接受PCS再比如重量字段填了数字但新系统要求重量单位必须是千克旧数据里可能填的是g。这类问题的根因是不同系统的数据模型和值域映射关系不同校验时必须对齐目标系统的元数据。我们后来把校验做成了两层第一层是通用规则空值、超长、格式如日期格式等第二层是业务规则枚举值映射、单位换算、编码前缀规则等。业务规则来自和业务部门逐项确认做成了一个可配置的Excel规则表每次校验前加载。虽然前期确认规则很费时间但一旦做完后续的准确性提升非常明显。4.5 第五个大坑小概率超时问题引发的连锁失败还有一次印象特别深的故障某个周五下午跑任务结果RPA在登录新系统时偶发超时导致登录态异常后面的数据全部写入失败。我们的第一版重试机制是在这一步内部重试但登录态异常不是多试一次就能解决的必须重新走登录流程重置会话。所以我们后来在整体设计中增加了会话健康检查步骤每处理完50条数据就主动检查一下新系统当前页面是正常页面还是登录页如果是登录页就自动重新登录。这个主动发现问题的思路比等失败了再重试要靠谱得多。5. 效果对比与经验复盘30分钟背后的真实意义5.1 数据对比时间、人力、准确率的全面改善项目最终上线后我们做了两周的跟踪统计结果非常直观指标人工迁移RPAAI迁移单批次迁移耗时3天左右30分钟涉及人力2名业务人员全职投入1名运维人员兼职监控数据错误率约3%400条里发现12条错约0.2%3000条里发现6条异常被拦截异常拦截率无拦截靠人眼查约98%的可识别异常自动拦截附件处理逐条打开PDF手工录入OCRAI自动提取这里要特别说明一个数字30分钟是全自动流程的纯机器处理时长不包括前期的规则配置和后续的人工抽检。但从业务视角看原来需要提前请假、专门安排人手做的事现在变成了下午定时自动跑跑完花15分钟抽检确认即可。这个体验上的改变比单纯省时间的意义大得多。5.2 这个方案的可复用性有多高如果你也在做内部业务系统之间的数据迁移这套思路完全可以复用。核心不在于具体用了哪款RPA和哪个大模型而在于把需要理解的部分和不需要理解的部分分开采集、处理、写入三段解耦避免相互拖累所有AI输出都经过结构化校验且可溯源留好人工复核的入口不要追求100%全自动。小到几十条的数据导入大到上万条的数据仓库初始化原理都是一样的。差别只是规模大了以后要加队列、分布式处理和更完善的监控但基础框架不变。5.3 如果重做一次我会在哪些地方做得更好最后聊点个人复盘的经验吧。如果重新来一次至少有三个方面我会调整第一规则梳理要前置。我们一开始把精力都放在跑通RPA流程上忽略了和业务部门确认枚举值映射。结果第一轮数据校验时大量数据因为单位不一致分类名称变了被打回来回沟通花了不少时间。这些规则如果能在写代码之前就和业务确认完后面会很顺畅。第二AI环节要有一份独立的测试样本集。不要用开发过程中用过的数据来评估效果而是在没有调过模的数据上做盲测这样得出的准确率才有说服力。第三日志设计要从第一天就做好。不要等出了问题再想着补日志那样根本还原不了现场。我们的任务ID贯穿全链路的设计虽然前期多花了一点时间但后期调试和向业务解释的时候帮了大忙。5.4 技术栈之外的最后一句话这个项目之后我最大的感受是RPAAI不是万能的但它确实能解决很多看起来无聊又重复的业务痛点。关键在于你要找对场景把流程拆到足够细并且对AI的输出始终保持怀疑和校验的态度。数据迁移这件事30分钟跑完并不难难的是这30分钟里每一步都稳定可靠。希望这篇踩坑实录能够给正在做类似项目的团队一些参考少走我们走过的弯路。
RPA+AI如何将物料主数据迁移从3天压缩到30分钟
开头可以先抛出结论很多团队以为数据迁移就是写脚本、导数据但实际上内部业务系统的情况远没那么简单特别是老系统字段乱、流程散、数据也不规范靠人工一点一点搬既慢又容易出错。我们这次做的项目就是把一个物料主数据的全量迁移从原来的人工3天压缩到RPAAI联合处理的30分钟。中间踩了不少坑但最后跑通的方案应该能帮到不少面临同样问题的团队。1. 项目背景与问题定位为什么3天的工作量能压到30分钟1.1 内部系统的历史遗毒迁移难的根本原因这个项目发生在公司内部目标系统是一个跑了好多年的业务管理系统。所谓物料主数据全量迁移其实就是把旧系统里几千条物料基础信息包括物料编码、名称、规格、单位、分类属性、采购信息、库存维度等同步到新系统里。听起来不就是一张表导到另一张表吗真正做过的人知道哪有这么简单。老系统的数据有几个特点字段含义和值域完全不标准比如单位一列里既有个又有PCS还有只关键信息散落在多个界面和附件里系统列表页看不到全部字段必须逐条点进去才能看到部分属性还是图片或者PDF形式的质检报告人工得打开附件去读内容有的物料存在重复编码、失效状态、历史遗留数据需要通过业务规则做判断。一开始团队走的是传统数据迁移路线让业务人员每天打开旧系统一条一条看再手工录入新系统。这个做法的结果就是3天起而且累得够呛还容易漏字段。我们做智能化的目标就是把这样一个3天的场景拆解成机器能自动跑的动作。1.2 为什么不用纯API对接而要用RPA可能有人会说直接调数据库或者调用后端API做数据导出导入不就行了。这个思路业务系统如果支持当然好但实际阻力很大旧系统是很多年前外包开发的没有文档数据库表结构没人说得清新系统虽然有API但接口权限归IT部门管走审批流程就很麻烦迁移不是一次性动作后期还有增量同步和变更处理不能一直依赖业务方提工单。RPA的价值在于它绕过了系统底层集成模拟人在界面上的操作不改造现有系统。在这个项目里旧系统打开页面、查询数据、复制字段这些操作都能由RPA完成而不需要动旧系统的一行代码。1.3 AI在这里到底解决什么问题RPA本身擅长读界面、填界面但面对非结构化数据就抓瞎了。物料描述里可能存在各种写法螺丝 M4*10 304不锈钢和304不锈钢十字盘头螺丝M4X10指同一个东西但RPA无法判断。这就要AI来做语义理解和字段归一化。另外系统里许多规格参数藏在PDF质检报告或Word工艺文件里。RPA无法解析这些没有固定版式的文档而AI OCR加上大模型的信息抽取可以把标题、热处理要求、材质报告这些信息提取出来转成结构化字段。所以在这个项目里AI负责看懂和判断RPA负责执行和搬运两者分工明确。2. 方案选型RPAAI组合的边界与分工2.1 主流程与辅助流程的设计思路我们最终采用的架构是RPA总控调度 AI能力中台 人工复核兜底。整个流程分成三段数据采集段RPA登录旧系统按照物料清单逐个查询记录、进入详情页把页面上的字段抓取下来。对于页面上的附件下载到本地指定目录交给AI处理。数据处理段AI先做OCR识别再通过大模型的信息抽取和字段归一化输出标准化的JSON数据。同时规则引擎检查必填项、枚举值、长度限制把异常数据单独标记出来。数据写入段RPA根据AI输出的结构化结果登录新系统按照界面顺序一条条创建物料录入完成后截图存档并记录成功或失败状态。这个设计里最关键的一点是不要让AI一次性处理所有字段而是只处理需要理解的部分比如名称标准化、规格提取、分类映射那些枚举值固定、格式明确的字段比如创建人、创建时间完全可以通过规则直接透传减少AI调用成本和出错的概率。2.2 RPA平台选型为什么选中了它在选型时我们对比了好几款主流RPA工具。公司里当时已经在用影刀RPA所以就优先测试了影刀的社区版和企业版。另外也看了金智维和国外的一些产品最终选择影刀有几个原因支持Python扩展可以在流程里直接调用AI接口不用额外写Web Service操作录制相对智能能识别网页元素旧系统虽然老旧但有ID属性识别准确率能达到95%以上有流程编排面板能把打开页面、抓取数据、调用AI、回写数据这些步骤可视化后期维护方便。当然如果你们公司已经有其他RPA工具比如实在RPA、UiBot也完全可行。关键是看它有没有开放接口、支不支持Python脚本嵌入、能不能在不稳定网页环境下做容错。2.3 AI能力选型大模型不是万能的OCR也要配套AI部分我们用了两段式处理OCR层使用PaddleOCR做本地识别。原因是业务资料涉及大量表格、手写批注其他公有云OCR对特殊字体识别效果不稳定且数据安全不允许把内部物料信息发到外部服务。PaddleOCR部署在内网服务器识别精度通过调参能达到相对理想的效果。语义层在内网部署了一个开源大模型的API服务主要做三件事物料名称标准化、从文本中抽取规格参数、把旧分类映射到新分类体系。因为公司不允许使用外部大模型所以私有化部署是唯一的合规路径。这里我得提醒一句大模型的输出有随机性不能直接拿输出结果去写生产系统。我们为每个AI调用都加了JSON Schema校验不仅校验字段类型还校验枚举值是否在业务允许范围内。校验不通过的数据会进入人工处理队列而不是卡死整个流程。2.4 人工复核兜底设计任何自动化方案如果完全没有人工参与上线风险都很大。我们的兜底逻辑是RPA每处理完100条数据就暂停一次人工抽检10条发现异常则调整模型参数或补规则所有AI识别置信度低于阈值的字段自动标黄提供一个人工复核界面操作员可以逐条查看原始截图、AI提取结果和标准化结果确认或修改后再触发RPA写入新系统。这个设计看起来简单但在实际运行中帮我们挡掉了至少好几百条因为历史脏数据导致的错误。3. 核心实施过程数据迁移完整链路拆解3.1 第一步老系统的数据采集怎么做才稳老系统是一个B/S架构的页面RPA需要在登录态下打开查询页面每页显示10条记录手动一条条点进去。RPA流程大致是这样的1. 打开浏览器访问旧系统URL 2. 输入账号密码等待首页加载 3. 进入物料管理菜单输入待迁移的物料范围 4. 循环每页记录 a. 读取列表页当前行的物料编码 b. 双击物料编码或点击详情按钮 c. 等详情页加载完成 d. 抓取页面指定字段的值 e. 如果有附件点击下载并记录附件文件名 f. 返回列表页继续下一行 5. 将采集到的字段数据写入本地JSON文件 6. 记录本轮采集进度已处理/总量这里有几个细节特别重要等待条件不能用死等而是要在页面元素出现后再执行下一步否则系统慢的时候很容易误判下载附件时要注意文件名重复建议按照物料编码附件类型时间戳重命名列表页翻页和详情页返回一定要抓到稳定的控件有些旧系统点返回按钮弹出确认框需要额外处理。起初我们没太在意这些结果前两轮跑下来不是漏了记录就是下载了空文件浪费时间排查才发现都是等待条件写得不够严谨。3.2 第二步AI处理环节的提示词与字段映射AI处理是最有技术含量的部分也是踩坑最多的部分。我们给大模型设计了一套结构化提示词核心是让输出严格符合JSON格式。以物料名称标准化为例你是物料主数据标准化助手。用户会提供一条物料信息里面包含原始名称、规格描述、附件文本等。请根据以下规则输出 1. 物料名称统一为【材质】【产品类型】【规格】【表面处理】如304不锈钢内六角圆柱头螺钉M4x10 2. 如果无法判断不要编造输出UNKNOWN 3. 只输出JSON格式为{standard_name:...,spec:...,material:...,unit:...}大模型当时能够返回一个看起来还不错的输出但有两个隐患一是偶尔会输出Markdown代码块也就是在JSON外面加json 包裹直接导致解析失败二是会把一些无法判断的字段填上推测值这个非常危险。针对这两点我们在AI接口外层封装了文本清洗模块和字段校验模块。清洗模块负责去掉代码块标记、多余空格、转义符校验模块会检查每个字段的合法性、枚举值是否在业务表里。def extract_ai_json(text): text text.strip() # 去掉 json 包裹 if text.startswith(): text re.sub(r^[a-zA-Z]*\n?, , text) text re.sub(r\n?$, , text) return json.loads(text)3.3 第三步新系统的写入策略与并发控制数据写入新系统时一开始我们是一条条按顺序写每写一条要等页面刷新完成速度很慢。后来改成多实例并发写入——开三个RPA机器人同时工作每个负责不同批次的物料编码写入速度提升明显。但并发也带来了问题新系统本身有账号并发数限制同时点多条数据可能导致会话互踢或者审批流程混乱。后来我们做了个简单的并发闸门最多允许3个RPA实例同时写入每个实例每处理完一条数据间隔1秒再操作下一条写入失败时自动重试两次两次失败就扔进错误队列而不是无限重试。这样既保证了速度又不至于把新系统怼出问题。3.4 第四步异常检测与日志设计自动化最怕的不是报错而是报错后不知道错在哪。我们花了不少功夫在日志和监控上每个物料编码分配一个唯一任务ID从采集、AI处理到写入所有日志都带上这个ID每一步的关键数据都存一份副本方便回溯异常数据单独生成Excel文件标明异常原因比如单位字段无法识别分类映射失败必填项为空等每天跑完定时任务后RPA自动发送一份汇总报告到邮箱包含成功数、失败数、各类异常的数量分布。这套日志系统虽然朴素但在后续调优和给业务部门解释的时候帮了大忙不然出了问题说不清到底是RPA漏抓还是AI识别错。4. 踩坑实录我们在这30分钟背后踩过的那些坑4.1 第一个大坑RPA抓取页面数据时字段顺序错位我们第一次跑通全流程是在测试环境一切正常。但到了生产环境开始正式跑时发现写入新系统的数据里有相当一部分张冠李戴——物料名称跑到规格字段里单位跑到分类字段里。排查了半天最后发现原因在于旧系统某些详情页布局不完全一致。比如大部分物料的规格字段在第5行但有些物料会在第3行多显示一个别名字段后面的行就整体往下顺延了。RPA如果按照固定的坐标或者固定的XPath去取值一旦页面结构有变化就会抓到错误的字段。解决方案是换用更聪明的定位方式优先通过字段标签比如规格、单位定位后面的值元素不依赖绝对位置而是根据标签元素的相邻节点动态查找匹配值如果找不到预期标签则记录该条数据为页面结构异常而不是随意取值。改完之后字段错位的问题基本绝迹。4.2 第二个大坑AI对历史数据的幻觉式补全这是一个非常值得警惕的问题。在测试阶段我们拿了一批相对干净的物料数据AI识别效果很好。结果一上真正历史数据发现大模型偶尔会做一些贴心的补全——比如旧系统的材质字段是空的但AI通过物料名称推测出该螺丝可能是碳钢就自信满满地填了个碳钢。在业务上这就是严重的错误。物料主数据的材质属性直接影响采购和质检流程不能靠模型猜。我们后来加了两道防线提示词里加上了强约束如果原文没有明确提及该字段信息必须输出空字符串或UNKNOWN禁止推测。在代码里对每个AI返回的字段做了和原文的引用比对也就是AI必须输出它依据的是原文中的哪一段文字如果无法引用就不允许写入。这个方法实际上就是现在常说的RAG思想识别结果需要能追溯来源否则宁可缺失也不能乱填。4.3 第三个大坑附件下载和OCR的并发打架附件处理是整个流程里最容易形成瓶颈的地方。一开始设计是RPA边抓取边调OCR每到一个有附件的物料就立即下载、识别、提取。结果跑多了发现OCR服务经常超时RPA进程被阻塞整个流程越跑越慢。后来调整为了采集与处理分离RPA先只负责快速抓字段和下载附件不调用OCR所有附件下载到本地后由AI处理程序异步批量识别每个物料的数据合并阶段唯一标识关联附件识别结果。这样改造之后RPA不再被OCR拖累30分钟跑完整个流程成为了可能。可以说这个调整是整个项目从看起来能跑变成真正高效的关键一步。4.4 第四个大坑数据校验时不只要查空值还要查语义合法性我们也在校验环节踩了坑。初期校验只检查了必填项是否为空长度是否超限结果仍然有漏网之鱼。比如单位字段填了个和PCS虽然非空但在新系统里对应的值域只有三个枚举值不接受PCS再比如重量字段填了数字但新系统要求重量单位必须是千克旧数据里可能填的是g。这类问题的根因是不同系统的数据模型和值域映射关系不同校验时必须对齐目标系统的元数据。我们后来把校验做成了两层第一层是通用规则空值、超长、格式如日期格式等第二层是业务规则枚举值映射、单位换算、编码前缀规则等。业务规则来自和业务部门逐项确认做成了一个可配置的Excel规则表每次校验前加载。虽然前期确认规则很费时间但一旦做完后续的准确性提升非常明显。4.5 第五个大坑小概率超时问题引发的连锁失败还有一次印象特别深的故障某个周五下午跑任务结果RPA在登录新系统时偶发超时导致登录态异常后面的数据全部写入失败。我们的第一版重试机制是在这一步内部重试但登录态异常不是多试一次就能解决的必须重新走登录流程重置会话。所以我们后来在整体设计中增加了会话健康检查步骤每处理完50条数据就主动检查一下新系统当前页面是正常页面还是登录页如果是登录页就自动重新登录。这个主动发现问题的思路比等失败了再重试要靠谱得多。5. 效果对比与经验复盘30分钟背后的真实意义5.1 数据对比时间、人力、准确率的全面改善项目最终上线后我们做了两周的跟踪统计结果非常直观指标人工迁移RPAAI迁移单批次迁移耗时3天左右30分钟涉及人力2名业务人员全职投入1名运维人员兼职监控数据错误率约3%400条里发现12条错约0.2%3000条里发现6条异常被拦截异常拦截率无拦截靠人眼查约98%的可识别异常自动拦截附件处理逐条打开PDF手工录入OCRAI自动提取这里要特别说明一个数字30分钟是全自动流程的纯机器处理时长不包括前期的规则配置和后续的人工抽检。但从业务视角看原来需要提前请假、专门安排人手做的事现在变成了下午定时自动跑跑完花15分钟抽检确认即可。这个体验上的改变比单纯省时间的意义大得多。5.2 这个方案的可复用性有多高如果你也在做内部业务系统之间的数据迁移这套思路完全可以复用。核心不在于具体用了哪款RPA和哪个大模型而在于把需要理解的部分和不需要理解的部分分开采集、处理、写入三段解耦避免相互拖累所有AI输出都经过结构化校验且可溯源留好人工复核的入口不要追求100%全自动。小到几十条的数据导入大到上万条的数据仓库初始化原理都是一样的。差别只是规模大了以后要加队列、分布式处理和更完善的监控但基础框架不变。5.3 如果重做一次我会在哪些地方做得更好最后聊点个人复盘的经验吧。如果重新来一次至少有三个方面我会调整第一规则梳理要前置。我们一开始把精力都放在跑通RPA流程上忽略了和业务部门确认枚举值映射。结果第一轮数据校验时大量数据因为单位不一致分类名称变了被打回来回沟通花了不少时间。这些规则如果能在写代码之前就和业务确认完后面会很顺畅。第二AI环节要有一份独立的测试样本集。不要用开发过程中用过的数据来评估效果而是在没有调过模的数据上做盲测这样得出的准确率才有说服力。第三日志设计要从第一天就做好。不要等出了问题再想着补日志那样根本还原不了现场。我们的任务ID贯穿全链路的设计虽然前期多花了一点时间但后期调试和向业务解释的时候帮了大忙。5.4 技术栈之外的最后一句话这个项目之后我最大的感受是RPAAI不是万能的但它确实能解决很多看起来无聊又重复的业务痛点。关键在于你要找对场景把流程拆到足够细并且对AI的输出始终保持怀疑和校验的态度。数据迁移这件事30分钟跑完并不难难的是这30分钟里每一步都稳定可靠。希望这篇踩坑实录能够给正在做类似项目的团队一些参考少走我们走过的弯路。
