简介这是一份关于AI人工智能与RPA机器人流程自动化的PPT演示文档面向希望快速了解RPA技术概念及应用场景的技术人员、项目管理者也可用于内部培训或方案汇报。资源以单个PPTX文件形式打包文件大小1.27MB共11页内容结构紧凑适合直接使用或二次编辑。目前已有867人浏览学习。文档重点介绍了RPA机器人流程自动化的行业背景与业务价值讲解了其在售前技术支持、政府招商引资、互联网等场景中的实际应用并探讨了RPA与人工智能融合后的发展方向。具体内容涵盖终端用户快捷上网体验优化、产品技术问题诊断、政府招商模式创新等案例能够看到RPA如何被嵌入不同业务流程。同时PPT中包含了企业介绍、产品技术与人才理念等配套内容有助于读者在一个完整的企业叙事语境中理解RPA的落地方式。对于初次接触RPA的读者这份PPT可以快速建立概念框架对于需要对外展示的团队其中的结构安排也便于调整复用。1. AIRPA 不是汇报专用词它解决的是传统自动化接不住的脏活看到「AI人工智能RPA机器人流程自动化.pptx」这个标题很多人第一反应是“又要做汇报了”。但真在自动化一线待过的人会明白这个组合不是包装是刚需。传统RPA擅长的是路径固定的重复操作——打开系统、点按钮、填表单、抓数据只要界面不改它就能一直跑。可一旦屏幕上弹出一个新样式的对话框或者来一份扫描件、一张验证码规则脚本立刻就抓瞎。AIRPA 的实质是在 RPA 原有的“执行骨架”上补两层能力一层是视觉感知让机器人能看懂屏幕上的字、表格和控件另一层是语义决策让它能在非结构化内容面前判断该走哪条分支。适合读这篇笔记的人很具体正在做自动化选型的工程师、被重复录入和数据搬运折磨的业务岗以及被要求拿出 AI 转型落地方案的团队负责人。这套方向不需要推翻现有系统在旧软件上就能动工这也是它真正值得投入的地方。2. AIRPA 的技术栈该选哪一层执行、感知、决策的分工与选型逻辑2.1 三层架构流程编排是骨架AI 只补两层做 RPA 实战时最容易犯的错是一上来就纠结用哪个模型、识别率能到多少却没把架构分层想清楚。我习惯把一套 AIRPA 系统拆成三层执行层、感知层、决策层。执行层是 RPA 的本职工作负责模拟人的操作——鼠标点击、键盘输入、打开应用、读写文件。这一层的核心是流程编排和稳定性跟 AI 关系不大。感知层解决的是“机器看不懂”的问题把屏幕截图变成文字把图片里的表格结构变成可读字段把一段语音变成指令文本。决策层解决的是“不知道下一步该干嘛”的问题识别结果有多个候选时选哪个流程出现异常时继续重试还是转人工用户留言是投诉还是咨询需要分派给谁。这三层里AI 真正要投入的是感知和决策。执行层如果频繁出问题那是 RPA 本身没调好不是 AI 能救的。判断每条流程的 AI 介入点我的做法是沿着流程走一遍凡是“人需要用眼睛看才能判断”的步骤交给感知层凡是“人需要想一下才能决定”的步骤交给决策层剩下的重复操作留在执行层。这样分工的好处是每个环节可以独立测试、独立替换不会出现“整个流程黑盒跑起来出问题不知道怪谁”的局面。2.2 选型决策树哪个环节值得引入 AI给一个我常用的选型判断表能帮你快速决定每个环节用什么技术方案避免“杀鸡用牛刀”。场景特征推荐做法AI 投入成本系统提供接口或能拿到完整控件树直接走 API 或控件定位不用截图无界面固定、按钮位置稳定、页面简单图像模板匹配 坐标定位辅以 OCR低老客户端、拿不到控件树、界面会动态变化区域截屏 OCR 图像匹配组合定位中邮件、工单、合同等非结构化内容信息抽取模型或大模型做语义理解高这套判断逻辑的关键是别把“能拿到控件树”的流程硬做成“截图识别”。Web 页面上明明能通过 DOM 拿到按钮位置非要用图像去找等于把确定性问题改成概率问题纯粹给自己制造维护负担。反过来老客户端没有控件接口强行用坐标写死换台电脑就全崩这时候引入视觉识别反而是性价比最高的方案。我一般会在进入开发前先画一张这样的对照表把每个步骤归到对应方案里。表格画完哪块要投入、哪块不用碰基本一目了然。很多 rpa 面试里问“你怎么评估一个流程能不能自动化”答案的底层逻辑就是这张表先看接口再看控件最后才轮到视觉和模型。2.3 先别急着上大模型语义替代方案AIRPA 的技术方案里最容易被“大模型崇拜”带偏。有些场景的光鲜方案是用大模型读单据实际跑下来发现延迟高、成本贵还时灵时不灵。我踩过的坑告诉我语义理解能不用大模型就尽量不用。先试正则表达式。很多业务字段是有规律的发票号码、订单号、日期、金额几乎都能用正则抽取。再试词典匹配判断留言是投诉还是咨询准备两三百个关键词准确率往往不输模型。第三档是用规则引擎如果 A 条件成立且 B 字段存在就走分支 X这类硬规则在业务场景里非常可靠。什么情况下才真正需要大模型三个信号缺一不可文本格式完全不固定、判断条件无法枚举、异常类型经常超出预期。比如跨部门流转的复杂工单表达方式五花八门规则怎么写都漏这时候上语义模型才是对的。AI 是补盲区的不是给所有流程贴金用的。过早引入模型只会让系统的可解释性变差、故障率变高最后挨骂的还是写流程的人。3. 用 Python 搭一个能看屏幕、会录入的 RPA 脚本从截屏到数据落库3.1 先解决“看”屏幕截取与区域裁剪动手的第一步是采集数据。我拿一个最常见的场景举例某个业务弹窗里显示一张单据上面有单据编号和金额需要把这两个字段识别出来并录入到网页系统中。第一步是把弹窗区域截下来。import pyautogui # 截取屏幕上的固定区域 # region 参数是 (x, y, width, height)单位是物理像素 img pyautogui.screenshot(region(120, 240, 640, 320)) img img.convert(RGB) img.save(capture_region.png)这段代码只做一件事从屏幕左上角偏移 (120, 240) 的位置开始截取宽 640、高 320 的一块区域。区域坐标怎么定先用微信截图工具或者系统自带截图把窗口位置量出来再填进代码。注意这里的坐标系原点在屏幕左上角x 向右增大y 向下增大。实际项目里区域坐标不可能永远写死。窗口位置变化了怎么办我一般会在截图前做一步“窗口对齐”先把目标窗口用 win32 接口移动到固定坐标再执行截屏。这样 region 参数永远有效后续脚本稳定性会好很多。坐标写死不是懒而是刻意控制环境变量等流程跑通后再想动态定位的事。3.2 再把图变成字段OCR 识别与结构化输出截图只是原料下一步是把图片里的文字变成结构化字段。这里我以某个中文开源 OCR 框架为例代码里写的是 PaddleOCR 的调用方式它在发票、单据这类印刷体中文上有不错的准确率。from paddleocr import PaddleOCR # langch 指定中文识别use_angle_cls 开启方向分类处理旋转文本 ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) # 对裁剪区域做识别clsTrue 表示整图识别时启用方向分类 result ocr.ocr(capture_region.png, clsTrue) # 按行输出识别结果 for line in result[0]: text line[1][0] # 识别出的文字内容 score line[1][1] # 置信度 box line[0] # 四个角点的坐标 print(f{text} | 置信度: {score:.3f})PaddleOCR 返回的 result 是一个嵌套结构外层是图片列表内层每行包含文本框坐标和 (文本, 置信度) 元组。这里我们把每一行文本连同置信度打印出来就能直观看到哪些字段识别得稳、哪些字段模棱两可。关键参数是use_angle_cls和lang。方向分类会多消耗一点推理时间但对旋转、倒置文本效果明显建议开启。langch是识别中文的基础配置英文单据就改成langen中英混合的场景保持默认。真到生产环境我不会直接把整张图丢给模型而是先按字段区域切成小图再逐块识别——小图干扰少识别速度和精度都更好。3.3 让脚本“动手”定位输入框并回填数据识别完成后脚本要模拟人工操作把字段填进系统。这一步的坑最多。最常见做法是先用图像模板找到输入框旁边的标签文字再点标签右侧区域。import pyautogui import pyperclip import time # 假设 OCR 已经解析出两个字段 fields {单据编号: HD20240801123, 金额: 5200.00} for label, value in fields.items(): # 在屏幕上找到标签文字的坐标模板图用截图工具提前保存 label_pos pyautogui.locateCenterOnScreen(f{label}.png, confidence0.85) # 标签右侧一般是输入框偏移点击 pyautogui.click(label_pos.x 120, label_pos.y) # 全选后粘贴避免逐字符输入导致漏键 pyautogui.hotkey(ctrl, a) pyperclip.copy(value) pyautogui.hotkey(ctrl, v) time.sleep(0.3)这段代码的关键不是点击和粘贴而是两个容易被忽略的设计。第一confidence0.85是模板匹配的相似度阈值设太低容易点错设太高界面轻微变化就找不到。第二用剪贴板粘贴而不是typewrite逐字输入是为了处理中文输入法和长字符串逐字输入在中文环境下的丢键概率非常高。回填完不等于流程结束后面还要加断言检查输入框里的值是否和源数据一致或者截一张回填后的图做二次识别。这个习惯能阻止一大批“填对了但录错了”的诡异问题。整个流程走下来就是“截图 → 识别 → 决策 → 回填 → 验证”五步闭环AI 只负责其中两步剩下的还是 RPA 的本职。4. 让 RPA 稳定跑起来的四个关键参数阈值、重试、超时与兜底4.1 OCR 置信度阈值宁可漏识不要错识AIRPA 流程里识别置信度阈值是最值得反复打磨的参数。它的含义很简单模型对“这个字段识别正确”的把握有多大低于阈值就不该放行。我给一个起始建议自动提交类的操作置信度门槛设在 0.95只读展示不落库的操作可以放宽到 0.8介于两者之间的进人工复核队列而不是直接提交。为什么宁可漏识、不要错识因为漏识最多是流程中断提醒人工介入成本是一次人工点击错识可能把错误数据写进系统后续对账、审批、报表全是错的修复成本高出一个数量级。参数建议取值设偏大的后果设偏小的后果OCR 置信度阈值0.85~0.95漏识别增多人工介入变频繁错别字被当成正确值提交元素等待超时8~10 秒流程变慢异常发现变晚网络波动时误报流程失败输入间隔时间0.2~0.5 秒流程整体变慢界面卡顿丢输入失败重试次数2~3 次卡死时间过长偶发抖动直接打断流程4.2 界面等待策略显式等待比固定 sleep 靠谱新手写 RPA 最常见的问题是到处time.sleep(2)。页面加载快慢不稳定睡太短元素没出来睡太长流程拖沓。更稳的做法是显式等待轮询一个条件直到条件满足或超时。import time import pyautogui def wait_until(func, timeout10, interval0.5): 在 timeout 秒内每隔 interval 秒调用一次 func 返回 True 则等待成功否则到时间返回 False。 deadline time.time() timeout while time.time() deadline: try: if func(): return True except Exception: pass time.sleep(interval) return False # 等到“提交按钮”出现再操作 found wait_until( lambda: pyautogui.locateOnScreen(submit_btn.png, confidence0.85), timeout10 ) if found: pyautogui.click(submit_btn.png) else: print(提交按钮未出现进入异常流程)这个函数比固定 sleep 强的地方在于系统反应快时按钮一出现就立刻继续系统反应慢时它会等到超时再报错不会白白睡死。timeout参数要根据实际页面的加载特征来调网络系统给 10 秒本地桌面应用给 4 秒就够。你是 rpa 工程师这个等待策略就是你日常工作中最常用的基本功。4.3 失败时的三级降级重试、绕行、人工接管参数和等待都到位了依然会有意外。我的习惯是给每条关键操作设计“三级降级”策略低危操作自动重试中危操作换路径绕行高危操作停止并转人工。def process_field(value, confidence): # 第一级高置信度直接自动提交 if confidence 0.95: auto_submit(value) # 第二级中置信度自动填写但需要复核标记 elif confidence 0.80: fill_with_review_flag(value) # 第三级低置信度停止自动处理转人工队列 else: send_to_manual_queue(value)三级策略的核心不是技术而是风险意识。高置信不代表绝对正确只是把风险控制在可接受范围中置信度的数据如果业务上允许先填后审就带标记写入低置信度无论如何不进系统这不是效率问题是数据底线问题。这条原则同样适用于 AI 输出的每一个结构化字段不只是 OCR 识别结果。5. AIRPA 落地避坑指南5 个常见翻车现场与排查办法5.1 换台电脑就“玄学”失灵分辨率与 DPI 缩放现象脚本在本机跑得丝滑部署到同事电脑上就开始乱点点不到按钮还经常点到旁边的链接。原因Windows 默认开启了显示缩放比如笔记本 125%、150%而 pyautogui 截图和点击用的是物理像素。本机分辨率高、缩放比例特殊换台机器坐标就偏。解决第一在代码里提前声明 DPI 感知让系统按实际像素处理第二不要用全屏绝对坐标一律先定位窗口再基于窗口内的相对坐标操作。如果你用了模板匹配不同缩放比例下模板图也会失真可以动态缩放模板图或者干脆统一一套执行环境。5.2 识别率很高但数据回填老是错位现象OCR 识别出的文本全对打印出来毫无问题可脚本点击输入框时总是点到隔壁栏目。原因截图和点击之间界面发生过异步加载或布局位移。数据渲染完成时间和截图时机不一致按钮位置已经变了坐标还是旧的。解决回填前做“激活态断言”点击输入框后立刻检查光标是否在预期位置或者截取小区域二次识别确认焦点对了再输入。另一个办法是放弃“标签文字偏移点击”改用控件树或键盘 Tab 顺序导航让焦点自己走到该去的框里。5.3 中文识别慢到拖垮整条流程现象单张单据 OCR 要跑 3 秒多一百单跑下来快十分钟夜批流程直接超时。原因没做区域裁剪整张高清截图直接喂给模型没启用 GPUCPU 推理中文模型本身就慢。解决先按字段位置裁剪成小图再缩放处理识别面积缩小后速度提升明显。生产环境有条件就用 GPU 推理没条件就换更轻量的识别模型同时把use_angle_cls在非旋转场景关掉——它大概会增加 30% 的推理时间。5.4 一次误识别把正式单子提交了数据错误成了定局现象某个字段置信度只有 0.7还是被脚本当正确值写了进去月底对账发现问题但正式环境的数据已经污染。原因置信度阈值设得太低或者压根没判断置信度直接全部自动提交。这是 AIRPA 落地里最危险的设计缺失。解决参考 4.1 的参数表落库操作阈值调到 0.95 以上低于阈值就走人工复核。再补一条“事后后悔药”——所有自动写入操作保留原始截图和识别结果留存至少三个月出问题能追溯、能回滚。5.5 依赖装了一遍又一遍换环境还是缺包现象新环境跑脚本启动就报 ModuleNotFoundErrorrequirements.txt 装了三次某组件版本冲突。原因没用虚拟环境requirements 里的版本没锁死新环境装到了不兼容的版本。解决别直接装在系统 Python 里用 venv 或 conda 单独建环境。requirements.txt 里把版本全部固定比如pyautogui0.9.54而不是pyautogui。启动脚本时加一段环境自检缺包直接给出提示别等到运行到一半才炸。6. 把 RPA 流程升级成 AI Agent从单点自动化到多智能体协作单条流程跑稳之后下一站是把整套 RPA 能力升级成 AI Agent。两者之间的距离没有想象中远核心变化只有一点把固定脚本里的每个动作封装成可以被大模型调用的工具函数。tools [] def register_tool(func): tools.append({name: func.__name__, execute: func}) return func register_tool def open_customer_page(customer_id: str): 打开客户详情页并截取关键信息 # 这里的实现还是传统 RPA定位、点击、截图、识别 return {status: ok, customer: ...} register_tool def query_order_status(order_id: str): 查询订单状态 ...工具化之后大模型的角色是“调度员”收到一句自然语言指令自己拆解步骤按顺序调用这些工具。每个工具的粒度要控制在一个不可再拆的业务动作比如“打开页面”“读取字段”“提交表单”。粒度过大大模型调度不灵活粒度过小调用次数爆炸延迟和出错率都上去了。这一步做完你已经拥有一个多智能体协作的雏形传统 RPA 负责脏活累活AI Agent 负责理解任务和编排动作业务人员只下达意图剩下的看机器表演。真正的进阶方向不是追求全自动而是把 AI 的判断范围逐步扩大同时让每一步操作可追踪、可回滚。我踩过最深的坑是把 AIRPA 当成“识别率足够高就能全自动”结果一次中低置信度的误识别直接提交了错误数据。从那以后凡是写库、提交、付款这类操作一律默认高置信度才自动执行其余进人工。稳定性和可控性永远排在自动化率前面。希望帮到你。本文还有配套的精品资源点击获取