简介这份PPT聚焦AI人工智能与RPA机器人流程自动化可作为RPA概念入门、企业案例分析与行业趋势分享的演示素材适合技术团队、业务管理者及培训讲师快速建立认知框架。文档共包含1个pptx文件压缩包大小约1.27MB共11页版式简洁以图文和排比形式组织内容涵盖RPA公司发展历程、自研X5内核在速度与稳定性上的优势、售前技术支持流程、政府招商引资场景以及移动支付与互联网发展趋势等典型模块。读者可从中了解RPA如何替代重复劳动、提升效率以及RPA与AI结合后在复杂决策与开放平台战略中的延伸应用。通过浏览这份演示文稿学习者能快速梳理RPA的应用边界与落地路径理解RPA在金融、政务、互联网等行业的典型实践节省自行搜索和整理资料的时间。目前已有867人学习下载适合用于内部培训、课件优化或方案素材参考。1. 先说结论AIRPA不是概念替换是给重复劳动装了一套自动驾驶你有没有见过这样的场景业务员每天登录五六个后台把订单导出、清洗、比对、再录进另一个系统一干就是一上午。AI人工智能和RPA机器人流程自动化这两件事凑到一起就是为了把这种“规则清晰但步骤繁琐”的活儿接过去。这份PPT资料最实在的地方是它没有停在概念层而是把RPA的能力层次、AI介入的方式、流程拆解的顺序都串成了能直接照做的路线。准备人工智能大作业的学生、想转RPA工程师的从业者、负责企业自动化选型的人都能拿它当第一份实战地图。2. 先把RPA的底摸清从规则自动化到AI Agent协作认清四个能力层2.1 从“点击模拟”到“目标驱动”RPA能力分层的四个台阶很多新手拿到RPA工具的第一反应就是开录制功能把鼠标键盘操作录一遍以为这就完事了。这个认知恰恰是项目翻车的起点。常见做法是把RPA能力粗暴分成四层第一层是人工手动操作不算自动化第二层是录制回放式的键鼠模拟适合临时任务生成的选择器和固定坐标一换环境就废第三层是结构化流程自动化靠元素选择器、数据表、条件判断和循环来编排生产环境里跑的大多数RPA其实都在这一层第四层才是智能流程自动化流程里嵌入了OCR识别、语义判断甚至大模型决策。我一般会建议初学者先别急着拖组件先把手上的流程按这个分层对号入座。分辨方法很简单如果操作步骤能用“如果A成立就做B循环N次”这样的规则完整描述那就是第三层的问题不需要AI只有遇到“这张图片里有没有异常”“这段留言是什么意图”“这封邮件该分给谁”这种规则说不清的问题才需要上第四层。资料里提到的组件编排思路本质上也是在第三层打底座再在特定节点接上层AI能力。这个分层还有一个实际用途想面RPA工程师岗位的话面试官经常拿“你们项目为什么需要AI介入、不介入行不行”来考察你能一句话说清层级的候选人通常比背一堆组件名的人更分得清需求边界。2.2 AI和RPA的分工边界AI负责看和想RPA负责点、读、写、发把AI硬塞进RPA流程的每一步是另一个极端。正确的分工应该是AI负责处理非结构化信息比如票据上的文字、用户留言的情绪、图片里的物体RPA负责执行结构化动作比如打开程序、读取单元格、点击按钮、发送邮件。AI的输出必须变成一份确定的指令通常是JSON或结构化文本RPA再根据这份指令走下一步两边才算接上。举一个实际例子。某电商后台每天有大量买家留言需要判断哪些留言属于“要求拦截发货”再对命中订单执行拦截操作。留言是自然语言用规则枚举关键词会漏让RPA去逐句理解也不现实。常见做法是RPA先把留言批量采集下来调大模型接口做意图分类返回“是/否拦截置信度”置信度超过阈值的RPA再去后台点击拦截按钮。整套流程里AI只做判断动手的事全交给RPA组件。这里有个血泪经验大模型再能说本质还是鹦鹉学舌式的模式补全决策层必须有校验。我一般会要求AI返回结果里强制带confidence字段低于0.85的统统转人工确认队列不要让它直接驱动RPA执行否则一次幻觉判错就把流程带沟里了。3. 把流程拆成五段来落地组件编排、参数传递与一个完整实例3.1 五段式流程框架识别、编排、参数、兜底、回退资料里把一条RPA流程拆成五段这个框架我后来做项目一直在用。先看整张表每一段对应一组明确的组件职责。段落职责定位常用组件/机制常见误区目标识别确认流程入口和操作对象窗口/元素选择器、页面标题匹配用固定坐标代替选择器组件编排把步骤串成可执行的顺序顺序容器、条件判断、循环、子流程一个流程塞几百个步骤不拆块参数传递在步骤与子流程间交换数据变量、参数表、全局变量、数据表把单元格内容当数字直接用异常兜底处理流程运行中的意外情况异常捕获、重试机制、超时设置不做兜底挂了才去查日志人机回退把机器判断不了的交回给人人工确认弹窗、待办队列、消息通知全自动硬跑没人监管识别段最容易被忽略。新手总以为打开窗口这个动作“肯定没问题”但窗口标题变了、按钮换了个位置选择器就失效了所以识别段要做的第一件事是确认“对象是否存在”而不是默认它在。编排段的核心是给流程分层把稳定的主流程和易变的子流程分开页面改版时只动一个子流程模块。参数段负责把数据在步骤之间传顺。异常兜底和人机回退是上生产环境的前提缺了这两段流程就只能在有人盯着的电脑上跑。3.2 实战示例Excel对账差异检测邮件通知的完整配置下面这个例子是资料里流程图的典型场景我按自己在某公司实施过的版本细化了一遍。需求是每天从系统导出对账单和本地主数据表的订单金额比对把差异订单筛选出来发邮件给财务。步骤组件/操作关键参数设置说明1打开Excel工作簿文件路径参数化超时时间30秒别用绝对路径写死“D:\data\对账.xlsx”用变量2读取主数据表指定Sheet和区域如A1:C500给明确范围不要全表扫描3读取对账表同上记录行数到变量rowCount行数用于后面的循环次数4循环逐行比对循环变量i从1到rowCount步长1在循环体里做差值计算5条件判断判断金额差的绝对值是否大于0.01浮点误差在财务里不能简单用“等于”比6写入差异表把差异行追加到新Sheet记得先判断目标Sheet是否存在7发送邮件SMTP服务器、收件人列表、附件路径附件路径必须用上一步实际生成的文件名8关闭工作簿保存方式选“另存为”还是“覆盖保存”一定要做关闭失败的兜底参数设置里最容易翻车的是第5步。Excel里单元格读出来的值默认是文本如果直接拿它减另一个单元格的值要么报类型错误要么得到不对的结果。我一般会在读取后先做一步类型转换再进入循环。第4步的循环次数如果从表里读要小心空行读到的rowCount可能比实际数据行多所以要处理“空行跳过”。3.3 参数传递与三种等待策略别再用固定sleep扛一切参数传递这块资料里用了不少篇幅强调作用域我在做项目时也确实验证过这个坑。变量作用域分三类局部变量只在当前流程块里有效适合临时存储中间结果全局变量在整个流程里共享适合存文件路径、账号这类贯穿全程的数据会话变量则用于跨机器同步在分布式编排时才需要。类型作用范围典型用途失效场景局部变量当前步骤块循环计数器、临时拼接字符串子流程里读不到全局变量整个流程文件路径、登录账号、公共配置并发运行时互相覆盖会话变量单次运行会话任务批次号、Token系统重启后丢失等待策略是另一个大坑。新手习惯在每一步后面加一个固定等待比如“等待5秒”本地跑刚好能过换一台慢一点的机器就超时。正确的做法是显式等待元素出现而不是sleep固定时长。组件里一般都有“等待元素出现/可点击”的配置设置超时时间为30秒每1秒检查一次比写死等待时间稳定得多。只有极少数场景比如等待外部系统异步处理完成才需要用固定等待而且要把等待时间参数化方便上线后调。注意三种等待策略的优先级是“显式等待元素状态 等待数据条件满足 固定sleep”固定sleep是最后手段不是默认选项。4. AI怎么挂进RPA流程OCR识别、语义分类与大模型兜底的三条接法4.1 接法AOCR端点识别把图片里的文字变成RPA能用的字段最朴素的接法是OCR。场景是发票、截图、扫码枪无法覆盖的图片信息。常见做法是RPA先截取目标区域图片保存到临时目录然后调OCR服务识别把识别结果按行拆成字典结构返回RPA再拿字段去做后续判断。import requests import json # 读取RPA传入的截图路径调用OCR服务 def ocr_recognize(image_path, ocr_urlhttp://localhost:8000/ocr): with open(image_path, rb) as f: resp requests.post(ocr_url, files{image: f}, timeout30) if resp.status_code ! 200: raise RuntimeError(fOCR service error: {resp.status_code}) data resp.json() # 返回 {text: ..., blocks: [...]} lines [b[text] for b in data.get(blocks, [])] return lines这段代码做的事情是把图片文件送到本地OCR服务30秒内拿不到结果就抛异常。返回的blocks列表里每一项是一段识别出的文本块顺序按图像从上到下排列。后面的RPA流程拿到这个列表后可以按关键词过滤比如只保留含“金额”“订单号”的行再做字段抽取。参数说明ocr_url指向本地服务时用localhost就可以了如果OCR服务部署在另一台机器要改成它的局域网IPtimeout不建议超过60秒识别慢的机器宁可做异步回调也不要死等。4.2 接法B用大模型做语义分类让不确定的判断有置信度语义分类场景比OCR更常见比如留言分类、工单分派、舆情分级。RPA把文本内容采集下来调大模型接口让模型返回结构化JSON再根据JSON里的结论决定走哪个分支。import requests import json def llm_classify(text, llm_urlhttp://localhost:9000/v1/chat/completions): prompt f 判断以下用户留言是否需要拦截发货只输出JSON {{need_block: true/false, confidence: 0.0-1.0, reason: 简要原因}} 留言内容{text} payload { model: qwen2.5:7b, # 本地模型名称 messages: [{role: user, content: prompt}], temperature: 0, # 分类任务必须设0关闭随机性 max_tokens: 300, # 避免回复过长截断JSON response_format: {type: json_object} } resp requests.post(llm_url, jsonpayload, timeout45) result json.loads(resp.json()[choices][0][message][content]) return result这段代码的设计核心是两点temperature设为0模型输出几乎不带随机性同一个输入每次结果一致这是RPA流程可复现的基础response_format强制JSON输出省去RPA端解析字符串的麻烦。调用失败时比如超时或者返回内容不是合法JSON我一般会做三次重试重试间隔按2秒、5秒、10秒递增三次都失败就把该条记录写入人工队列。4.3 接法CAI Agent编排多个RPA机器人多AI协作处理跨系统任务第三种接法层级更高AI Agent不负责某个步骤而是负责拆解任务和调度多个RPA机器人。比如用户给Agent一个目标“把本月所有异常订单整理成报告发给管理层”Agent先识别出子任务从订单系统采集数据、从财务系统取对账表、执行差异分析、生成PDF、发送邮件然后分别调用对应的RPA流程去执行。接法输入类型开发量判断能力适用场景OCR接法图片/截图低弱只负责文字提取票据识别、截图数据录入LLM分类接法文本中中能理解语义但有幻觉工单分类、留言判断、风险预警Agent编排接法自然语言目标高强能拆解和决策跨系统综合报表、复杂任务指挥需要提醒的是Agent编排目前还不适合关键生产环节我见过不少把编排跑挂了的情况原因大多是Agent拆解出的子任务顺序和现实系统有冲突或者是某个RPA流程执行失败后Agent没有及时切换备选方案。我的建议是先从前两种接法把AI能力验证清楚再考虑上Agent编排不要一上来就追求全自动。5. 上线前避坑RPA项目最常见的五个翻车点与排查思路5.1 元素选择器频繁失效页面一改流程就断现象RPA流程运行两周后突然在某个点击步骤报“找不到元素”完全相同的脚本前一天还在跑。原因页面改版导致元素的class、id或XPath变化选择器失去了锚点。这是RPA最普遍的生产事故。解决不要在组件里写死单一条目的选择器。常见做法是给关键元素配置多个备选选择器例如优先用id找不到再用name再不行用文本内容匹配同时把选择器集中放配置文件里页面改了不用翻几十个步骤去改代码只动配置。5.2 流程在自己机器跑得好好的换一台电脑就罢工现象开发机运行零失误部署到服务器或其他同事电脑上启动就报错。原因环境差异包括屏幕分辨率不同导致坐标偏移、输入法状态不同导致中文输入异常、Excel版本不同导致COM组件行为不一致、杀毒软件拦截进程。解决上线前准备环境检查清单至少有四项目标程序版本一致、显示缩放比例设为100%、所有路径改为网络共享路径或UNC路径、在无人值守模式下关闭屏幕保护与自动锁屏。碰到“本地好好的换机就挂”的问题先从这四条逐项排查。5.3 固定等待引发的偶发超时现象流程偶尔在某一步停住重跑一遍又好了让人摸不着头脑。原因使用了固定等待操作执行时上一环节的数据还没加载完。系统响应速度有波动固定时间无法覆盖高峰时段的慢响应。解决把固定等待全部替换为“等待元素出现/可点击”超时时间设为30秒。如果等待超过10秒仍失败再捕获取当前界面截图和DOM状态方便看到底卡在哪一层。5.4 中文乱码与换行丢失现象从网页表格复制到Excel或数据库后中文显示成乱码或者多行文本变成一行。原因源系统编码是UTF-8接收端默认GBK或ANSI两边没对齐网页里的换行符是br标签RPA读取的却是纯文本换行信息丢失。解决数据传输环节统一转成UTF-8写入Excel时显式指定单元格文本格式对br标签在做数据清洗时替换为\n不要等写入后再处理。排查思路是先确认乱码是发生在“采集时”还是“写入时”给每个数据节点前后都打一次编码标记。5.5 无人值守凌晨跑挂了没人发现现象定时任务在凌晨3点执行中途异常退出第二天早上才从日志里发现昨晚任务白跑了。原因异常兜底只做了一部分弹窗关闭、重试、失败通知都没配置。流程一旦卡在没有人的弹窗界面上就变成了黑洞。解决全局异常处理器做三件事第一把异常截图存档第二尝试关闭异常弹窗并记录弹窗标题第三发送失败通知到企业微信或邮件。最后再判断是否需要人工介入处理。排查主题现象优先排查项选择器失效找不到元素页面版本、备选选择器环境差异换机就挂分辨率、缩放、输入法、路径偶发超时重试即过固定等待、元素等待中文乱码写入后乱码编码格式、换行符无人值守失败次日才发现异常捕获、失败通知6. 验证与交付日志埋点、成功率指标和灰度上线技巧流程写完能跑和能上生产是两回事。我习惯在交付前给流程做一套“体检”核心就三个指标执行成功率成功次数/总执行次数、平均耗时趋势、异常恢复率自动恢复次数/异常总次数。给它配一张执行记录表每次运行都往里写流程ID、开始时间、结束时间、结果状态、失败步骤和错误信息。没有这张表流程一跑挂就只能对着黑匣子猜。日志埋点有一个很实用的技巧在关键数据节点记录输入输出的哈希值比如对读取到的订单行计算MD5写日志时只记哈希不记原始内容既避开了敏感数据泄露的问题又能快速判断两次运行的数据变化点。做AI演示或者项目答辩时把这些运行记录表和AI判断的命中样例截图放上去说服力比贴十页流程设计图都强。灰度上线也有固定套路。先让流程在影子模式下跑一周也就是只读数据、只写临时表、不触发真实业务动作统计识别成功率和判定准确率确认无误后再挑一个低频业务场景单点上线持续观察两三天最后才全量放开定时调度。每一步都保留回滚开关出问题能一键切回人工流程。从那以后我每次交付RPA流程都强制自己走一遍埋点、异常演练、灰度上线三步哪怕只是给自己跑的小工具也不偷懒。这套习惯帮我挡住了不少半夜三点的故障电话也让你手里的这份资料真正变得可落地。希望帮到你。本文还有配套的精品资源点击获取