UI.Vision RPA实战：表格脚本、视觉识别与桌面自动化

UI.Vision RPA 这个名字我第一次看到的时候以为是又一个套壳的浏览器小插件点开装上之后才发现它其实是一套把“网页操作、图像识别、键鼠模拟”装进同一个扩展里的自动化工具箱。它原来的名字叫 Kantu核心玩法是用一张三列的表格来写脚本——命令、目标、值一行就是一步能点按钮、填表单、翻页抓数据、按图找位置、模拟桌面上的鼠标键盘还能被外部程序用命令行唤起来跑。它解决的问题很实在那些每天重复几十遍、逻辑简单但量大、又懒得每次都找人写的网页操作全都归它管。适合谁做运营的要天天批量填后台做测试的要跑冒烟流程做数据整理的要定时扒页面上的数字甚至普通办公场景里那种“每月固定去某个系统导一份表”的活都能落在它身上。零编程基础也能在半小时内出第一个能用的脚本懂点 JavaScript 的话上限还能再拔高一截。1. 先想清楚这类工具真正补的是哪块缺口1.1 从“能不能自动”到“值不值得自动”我见过太多人一上来就问“这个能不能自动登录后台批量提交”答案是能但真正该先问的是另一句这条流程一个月跑几次一次多少分钟改一次要多久。如果一个月只跑一次、一次五分钟你花两小时去调脚本这笔账是亏的但如果是每天跑、一次四十分钟哪怕调试花一整天也值。自动化工具的价值从来不在“酷”而在“把人的注意力从低价值动作里赎回来”。所以选型的第一步不是看功能列表是先给手上的活分个类。我把重复劳动大致分三层第一层是纯网页内的动作比如登录、点菜单、填字段、翻页、导出——这类用浏览器自动化最省事第二层是网页加本地文件的组合比如从页面抓数存成表格、或者读一份名单批量提交——这就需要有文件读写能力第三层是必须碰桌面软件或者必须“看见屏幕”才能干的活比如某个只提供客户端的系统、比如一个弹窗必须靠图像确认位置——这一层才是真正拉开工具差距的地方。搞清楚自己的活落在第几层再决定要不要深入这个工具比盲目上手强得多。1.2 几条主流路线的取舍市面上能自动点网页的路子不算少我把常见的几条摆在一起对比这是我的实际判断不是纸面参数路线上手成本网页内操作桌面/图像能力维护成本适合谁纯录制回放类工具极低够用但脆基本没有页面一改就崩一次性任务代码型自动化框架高强且稳需要额外桥接中但可版本管理有开发能力的人本工具表格脚本视觉低到中强自带图像识别与键鼠模拟中靠选择器和图片非专职开发但要干实事的人代码型框架的优势是工程化程度高、断言和日志体系成熟劣势是门槛在那儿摆着一个不写代码的运营同学要独立维护一套脚本成本太高。纯录制工具的优势是快问题是它记的是坐标和脆弱的路径页面结构一动就得重来。而 UI.Vision RPA 这类工具的位置很微妙它把脚本写成表格把“找元素”和“认图片”两套能力揉在一起门槛压到很低同时保留了变量、条件、循环、JavaScript 执行这些能撑起复杂逻辑的东西。我个人的判断标准很直白如果这个流程只有我一个人跑、跑完就作废我用录制如果这个流程要交给别人维护、要跑半年以上我会认真写选择器和错误处理如果这个流程必须跨越浏览器边界去碰桌面软件那基本就只剩这类带视觉能力的工具可选了。1.3 架构拆解它其实是三层拼起来的把工具拆开看结构比我最初想的清晰。最上面一层是浏览器扩展本体负责在页面里执行点击、输入、读取文本、执行页面内的 JavaScript这一层的能力边界就是浏览器的权限边界——它能做浏览器允许脚本做的一切也做不了浏览器不允许的事。中间一层是视觉与识别把屏幕上的一块区域截图、和预先存好的小图做匹配或者把区域里的文字转成可读字符串这一层解决的是“页面上没有可靠的标识、只能靠眼睛”的场景。最下面一层是本地桥接模块通常叫 XModules 之类负责突破浏览器沙箱去读写本地文件、真实地移动鼠标点击桌面、调用更强的文字识别。这个分层很重要因为它决定了很多问题的归属脚本报“找不到元素”问题在第一层脚本报“图片置信度不足”问题在第二层脚本报“无法写入文件”问题在第三层。新手最容易犯的错是把三类错误混在一起排查越查越乱。我后面写排查章节的时候会严格按这个分层来先定位是哪一层的锅再谈怎么修。还有一点要提前说明这个工具的核心脚本格式兼容 Selenium IDE 那套命令体系意味着一份脚本理论上可以在两边迁移。这个设计的好处是你不会被锁死坏处是有些命令的语义为了兼容做了妥协用起来会觉得“怎么这么绕”。我的处理方式是核心流程用通用命令写只有需要视觉和桌面的部分才用它的扩展命令这样将来真要迁到代码框架改造成本可控。2. 上手前的准备与核心概念对齐2.1 环境准备与权限边界先说清楚安装本身没什么可说的从浏览器的扩展商店装上工具栏出现一个图标就算完事。真正要提前想清楚的是权限。这类工具要正常工作基本会向你要三项东西读取和修改你访问的网页内容、访问你下载和上传的文件、以及在本地开一个服务端口给外部程序调用。前两项是它干活的必需品第三项是它能被命令行唤起的原理。装的时候别一路无脑点同意看清楚它要什么心里有个数。我的习惯是给自动化单独开一个浏览器用户配置Profile不和日常浏览混用。原因很实际脚本跑起来会连续打开关闭标签页、会疯狂点击混在日常窗口里你自己都没法干活另外有些脚本需要保持登录态单独配置里登录一次能管很久还不会污染你日常的账号环境。这个动作花五分钟能省掉后面无数次“脚本把我正在写的文档页面给关了”的糟心事。还有一条如果你只用网页内的功能扩展本体就够了一旦涉及读写本地 CSV、模拟桌面点击、更强的文字识别就需要装本地桥接模块。这部分能力有一部分是要授权的免费额度够跑通大多数个人场景但要拿它做长时间无人值守的批量任务得先算清楚授权成本和省下的人力哪个更划算。我的建议是先用免费能力把手上的流程跑通确认真能省时间再考虑升级不要一上来就买。2.2 命令三要素Command、Target、Value这个工具的脚本本质就是一张表三列命令做什么、目标对谁做、值做成什么样。比如要在一个输入框里打字命令是输入类命令目标是这个输入框的定位表达式值是要打的文字。要读页面上某个数字命令是取文本目标是那个元素值填一个变量名读到的内容就存进这个变量。这套设计的精妙之处在于它极容易理解看一眼就知道这行在干嘛不像代码那样需要脑内模拟执行。但它的坑也在这儿三列都是字符串没有类型你写1和写1在它眼里可能不一样。数值比较和字符串比较的结果差异是这个工具里最容易翻车的地方之一。我踩过一次循环条件里拿读出来的文本直接和数字比大小结果字符串按字典序比10 比 9 小循环提前退出了查了半小时才反应过来。从那以后我养成习惯凡是参与计算的值先用 JavaScript 执行那类命令转一遍数字再拿去比。变量在表格里用${变量名}的形式引用这个语法和很多模板引擎一致不难记。内置变量是一堆以感叹号开头的名字比如控制等待超时的、控制出错是否中断的、记录上一条命令是否成功的、当前循环行号的。这些内置变量是写出健壮脚本的关键比命令本身更值得花时间记我在第 5 章会集中讲几个最常用的。2.3 存储结构宏、子宏、测试套件工具里管脚本叫“宏”一个宏就是一张命令表。多个宏可以放进一个文件夹文件夹可以整体按顺序执行相当于一个测试套件。宏之间可以互相调用也就是一个宏执行到某一步时跳去跑另一个宏跑完再回来——这就是“子宏”的用法。这个结构看着简单但用好了能把项目组织得很干净。我的组织方式是一个原子动作一个宏比如“登录”“打开目标页面”“导出报表”“退出登录”每个宏只干一件事只关心自己那一段然后写一个主宏按顺序调这些子宏主宏里只放流程调度和错误处理不放具体操作细节。这样做的直接好处是改需求时改动面极小——登录逻辑变了只动登录宏其他宏一行不用碰间接好处是调试方便哪个环节出问题单独跑那个宏就行不用每次从头跑一遍完整流程。这里有个容易忽略的细节子宏调用时的变量作用域。我的经验是全局变量在各宏之间是通的但子宏里定义的局部变量回到主宏可能读不到所以凡是需要跨宏传递的数据我会显式地存到全局变量里命名加个前缀区分避免撞名。这个习惯在宏数量超过五六个之后会救你的命否则你会在某一天发现两个宏用了同一个变量名互相把对方的值覆盖了而你完全不知道为什么数据是错的。3. 十五分钟跑通第一个能用的宏3.1 录制起手手写收尾新手最快的上手路径是先录一遍。点录制手动把流程走一遍停止你会得到一张完整的命令表。这一步的意义不是直接拿去用而是让你看清楚每个动作被翻译成了什么命令、目标长什么样。录出来的脚本九成情况下是不能直接投入生产的因为它记的元素定位往往很脆弱而且塞满了多余的等待和无关点击。我的做法叫“录制起手手写收尾”录一遍拿到骨架然后逐行清理——删掉所有无意义的点击和停顿把脆弱的定位表达式换成稳定的给关键步骤补上等待把硬编码的值抽成变量。这个过程大概能把二十行的录制脚本压到八行左右而且稳定性提升一个档次。清理时我有个判断标准凡是“页面加载完成后自动就会到位”的等待删掉凡是“点了按钮要等接口返回才出现”的等待保留并且改成条件等待。前者是无脑等纯浪费时间后者是真的需要等删了必崩。区分方法很简单把那条等待注释掉跑三次一次不崩就删崩了就改条件等待。3.2 元素定位三套方案怎么选定位是这个工具里最需要动脑子的部分它支持三种方式我按优先级排序第一优先是元素自带的唯一标识比如 id 或 name。这类定位最快最稳页面改版通常也不会动它。可惜现实是很多内部系统根本不给你这个能用的就珍惜。第二优先是结构路径xpath 或 CSS 选择器。这类定位灵活能表达“第三个表格里的第二行第五列”这种复杂关系。写的时候我有个铁律尽量用语义定位不用序号定位。//button[text()提交]比//div[3]/button[2]稳得多后者页面加一个广告位就全乱。写 xpath 我一般先在浏览器开发者工具里试能唯一定位到一个元素才算过关返回一堆的说明写得太宽。第三是图像定位也就是把按钮截个小图存下来让脚本在页面上找这块图。这是兜底方案用在两种场景页面元素完全无法用选择器描述比如整块是画布渲染的或者定位表达式写出来极其复杂且易碎。图像定位的代价是换分辨率、换主题、换浏览器缩放就失效所以它只适合环境高度可控的场景。提示图像定位一定要在“最终运行环境”里截图。你在自己电脑上截的图拿到别人机器上跑字体渲染和缩放比例差一点点就匹配失败这个坑我踩过不止一次。定位表达式写完一定要做的一件事是加断言先确认元素存在、可见再做操作。多写这一行你得到的报错会从“点击失败”变成“第 N 步找不到提交按钮”排查时间差十倍。3.3 完整例子读名单、批量填表、回写结果说一个我认为最有代表性的场景手上有一份名单表格需要逐个到某个系统里查询并记录结果。这个流程麻雀虽小五脏俱全涵盖了读文件、循环、操作、写回、错误处理五件事。第一步是读入。用文件读命令把名单读进来工具会把它当成一张二维表同时提供一个内置变量告诉你总共有多少行、当前在第几行。这里要注意的是表格的编码问题我建议统一存成 UTF-8否则中文姓名字段读进来就是乱码而这问题在报错信息里完全看不出来只会表现为“查询不到这个用户”。第二步是循环。用条件循环命令从第二行开始第一行一般是表头条件是当前行号不超过总行数。循环体内部通过行号去取每一列的值取到的值赋给变量备用。这里有个很实用的技巧把行号本身也存进一个变量并且写进日志这样跑到一半崩了你能准确知道断在第几行下次从那里续跑不用从头再来。第三步是操作。打开目标页、定位输入框、清空、填入刚才取到的值、点查询、等结果出现、把结果文本读出来存到变量。这一串里最容易出问题的是“等结果出现”因为查询是异步的你点了按钮页面不会立刻变。这里的正确做法是用等待可见类命令指定目标元素和超时时间而不是拍脑袋写个固定睡眠。固定睡眠的问题在于慢的机器上不够、快的机器上浪费而且它会掩盖真实的加载问题。第四步是写回。把刚才读到的结果追加到输出表格的对应列或者在内存里维护一张结果表循环结束后一次性落盘。我倾向后者原因是一行一存盘在数据量大时会有明显的 IO 开销而且中途崩了文件处于半写状态很麻烦。第五步是错误处理。在循环体内每一步操作之后检查上一条命令是否成功的内置变量失败了就把这一行标记为“失败”、记下原因、继续下一行而不是整个流程中断。这个设计非常关键——批量任务里个别行失败是常态你要的是一份带失败标记的结果表而不是一个跑到第 37 行就停住的脚本。这套骨架写顺了之后你会发现公司里八成的重复网页操作都能往里套只是换一下定位和字段。4. 视觉识别与桌面自动化真正的分水岭4.1 图像匹配的置信度参数怎么定图像匹配的原理不复杂拿你存的小图在屏幕或页面的指定区域里逐块滑动比对算一个相似度分数超过阈值就算找到。这个阈值通常叫置信度取值在 0 到 1 之间。参数看着简单但它是整个视觉能力里最需要经验的地方。调高阈值匹配更严格误点少但容易找不到调低阈值容易找到但可能匹配到相似的其他元素上。我的一般取值是 0.7 到 0.8 这个区间起步先跑通确认能稳定找到再看有没有误匹配的风险往上调。如果同一个页面上存在长得几乎一样的多个按钮比如列表里每行都有一个“编辑”那必须把阈值调高、同时把截图范围收窄只截那个按钮独有的特征部分否则脚本会一直在第一行上打转。截图本身也有讲究。我的三条经验第一只截必要区域图越小匹配越快、越不容易被页面布局变化影响第二避开动态内容千万别把按钮上的数字、时间戳、未读红点截进去那些东西每秒都在变第三留一点边距把按钮周围的空白也截进去一点匹配时能利用上下文提高准确率。这三条听着琐碎但每一条背后都是被误匹配折磨过的经历。还有一个很少被提到的点分辨率和缩放。图像匹配本质上是像素比对如果运行环境的屏幕缩放不是 100%或者浏览器缩放不是默认值截图和实际渲染就对不上。我现在的做法是在脚本开头用命令把浏览器缩放强制归位并且把这条写进注释里免得以后接手的人一脸茫然。4.2 文字识别什么时候靠谱什么时候别碰工具带的文字识别能力用对了是神器用错了是灾难。它能做的是把屏幕上一块区域里的文字转成字符串适合的场景很明确某个数字或状态只以图像形式呈现页面上抓不到。比如图表里的数值标签、截图里的水印文字、客户端软件里的余额显示。不适合的场景同样明确能用选择器直接读到文本的地方绝不要用识别。原因很实在识别是有误差的会把 0 认成 O、把 1 认成 l、把小数点吃掉而这些误差是随机的、不可预测的一旦进入下游计算就会变成灾难性的错误数据。我的判断标准是如果这个值最终要参与计算或者要写进正式报表选择器能拿到就必须用选择器只有选择器完全拿不到才退到识别而且识别出来的结果必须经过格式校验。校验怎么做我一般加两步先用正则匹配确认格式对不对比如金额必须是数字加两位小数格式不对就重试一次两次都不对就标记失败。这个小逻辑写起来不到十行但能挡掉九成以上的脏数据。识别的准确率还跟区域大小强相关。区域越大识别引擎要做的工作越多出错概率越高。所以截图要尽量贴着文字边缘别把大片空白和无关元素框进去。另外如果文字是白字彩底或者字号很小识别率会明显下降这种场景我会考虑先放大页面再截。4.3 桌面自动化绕不开的焦点与坐标一旦流程跨出浏览器去操作桌面软件会立刻遇到两个新问题焦点和坐标。焦点问题的表现是脚本模拟的按键跑到了别的窗口里。原因是模拟键盘输入是把事件发给“当前活动窗口”如果脚本执行过程中有什么东西抢了焦点一个弹窗、一个系统通知、你自己手贱点了一下按键就打偏了。我的处理原则是每次模拟输入前先显式地把目标窗口激活一次不要假设它还是前台。这个动作多花半秒能避免大量“偶尔失败一次”的诡异问题。坐标问题更麻烦。图像匹配能找到位置但如果你用的是硬编码坐标那换个分辨率就全废。所以桌面点击我一律用“找图再点”的方式绝不用固定坐标。即使必须用相对偏移比如“点在找到的图标右边 50 像素处”我也会把这个偏移写成变量并注释清楚方便环境变化时统一调整。还有一个容易被忽略的点执行速度和界面响应速度不匹配。脚本的点击间隔是毫秒级而桌面软件打开一个窗口可能要一秒。如果你不主动等待脚本会在窗口还没出来的时候就开始找图然后报“找不到”。所以桌面流程里我几乎每个动作之间都插了一个“等待某个标志出现”的等待而不是固定睡眠——固定睡眠在快机器上是浪费在慢机器上是不够。5. 工程化让脚本能被别的程序调用5.1 命令行入口与参数传递脚本调通了下一步就是让它脱离“手动点运行”的状态。这个工具提供了一个本地接口扩展在本地开一个服务端口外部程序往这个端口发一段结构化的请求说明要跑哪个宏、传什么参数扩展执行完再把结果返回。具体端口号在设置里能查到不同安装可能不同这一点要自己确认。这个能力打开了很多门。最典型的是定时任务——用系统自带的任务计划每天早上八点发一个请求过去跑完自动关掉。其次是和其他程序串起来先用别的脚本准备好数据文件再唤起宏去处理处理完宏写一个结果文件下游程序读走。整个过程不需要人在中间点任何东西。通过请求传参数这件事需要设计一下。我不建议在请求里塞大量数据因为请求体大小有限制而且调试起来不直观。更稳的做法是请求里只传一个文件路径或者任务编号宏自己去读对应的文件。这样数据量不受限而且出了问题你能直接打开文件看比在日志里翻一大段 JSON 舒服得多。5.2 错误捕获、重试与断点续跑无人值守的任务健壮性比功能重要十倍。我总结出三个必须做的动作。第一个是全局的错误开关。工具默认遇到错误就中断整个宏这在调试时是好事在生产时是灾难——因为一次网络抖动就让整批任务停了。我会在宏开头把“出错继续”的内置变量打开然后在每个关键步骤之后单独判断是否成功自己决定这一步失败了该怎么办。这样控制权在我手里而不是在工具的默认行为里。第二个是重试。网页自动化失败的原因里相当一部分是瞬时的网络慢了一拍、元素渲染晚了一点、接口偶发超时。这类失败重试一次大概率就好了。我的做法是把高风险步骤包进一个“最多试三次”的小循环每次失败后等一到两秒再试三次都失败才标记为真失败。实测下来这一招能把失败率压下去一大截而且实现成本极低。第三个是断点续跑。批量任务最怕的是跑到第 800 条崩了重新跑又得从第一条开始。解决办法是让脚本记住进度每处理完一条就把已完成的标识写进一个进度文件脚本启动时先读这个文件跳过已完成的。这个机制写起来不复杂但需要保证“写进度”这个动作在处理成功之后立刻执行不能放在循环末尾统一写否则崩溃时进度就丢了。5.3 日志与结果落盘不带日志的自动化脚本等于黑盒。出了问题你只能看到“失败”两个字然后开始瞎猜。我要求自己的每一个脚本都能回答三个问题跑到第几步了、这一步的输入是什么、输出是什么。实现方式很朴素在关键节点往日志文件里追加一行格式是“时间戳 步骤名 关键变量值”。日志不要写得太细每一步都写会淹没重点也不要太粗只写开始和结束等于没写。我的粒度是每个业务步骤写一行每次重试写一行每次异常写一行带原因。这个粒度下出问题时看日志基本能一眼定位到哪一条数据、哪一步出的岔子。结果落盘我坚持用表格文件不用文本。原因是表格能直接被人打开看、能排序筛选、能二次加工而纯文本日志给人看的体验差太多。落盘时机前面提过我倾向在内存里攒着、循环结束或者攒够一批再写减少 IO但进度标记必须实时写这两者不冲突分开存两个文件就行。6. 踩坑实录与排查速查6.1 常见现象对照表下面这张表是我和身边人真实遇到过的问题汇总按“现象—可能原因—处理方式”组织遇到问题时可以先扫一眼。现象大概率原因处理方式报找不到元素但人眼看着就在元素在 iframe 里 / 元素还没渲染完先切换框架再定位把固定等待改成等元素可见偶尔成功偶尔失败毫无规律存在竞态某一步没等加载完就往下走逐个步骤加条件等待找出真正的瓶颈步图片匹配一直失败缩放比例、分辨率、主题与截图时不一致在运行环境重新截图统一缩放比例循环只跑了一轮就退出条件里拿字符串比大小强制转成数字再比较中文全是乱码文件编码不是 UTF-8统一存成 UTF-8读取时确认编码桌面按键打到了别的窗口焦点被抢每次输入前显式激活目标窗口批量跑到一半停住默认遇错即停打开容错开关逐条判断并记录失败定时任务没跑起来浏览器没开 / 端口不对 / 用户会话未登录确认浏览器常驻、端口正确、登录态有效这张表覆盖不了所有情况但能挡掉最常见的一批。真正排查时我的顺序是固定的先看日志定位到具体哪一步再判断错误属于哪一层页面内、视觉、本地桥接然后只在这一层里找原因。跳层排查是最浪费时间的做法。6.2 几条交过学费换来的经验第一条能在页面内解决的绝不上升到视觉。视觉定位是最后手段因为它的稳定性天然比选择器差一个数量级。我见过有人图省事整个脚本全用找图点击结果换了台电脑全部报废重截了三十多张图。选择器写起来麻烦但那是“一次麻烦换长期稳定”账要算长远。第二条不要在脚本里硬编码任何会变的东西。账号、网址、文件路径、阈值、超时时间全部抽成变量放在宏的开头改的时候只改那几行。这个习惯的价值在你需要把脚本交给同事、或者需要在测试环境和生产环境之间切换时会成倍体现。第三条先让脚本能跑再让它跑得稳最后才让它跑得快。新手常犯的错是一上来就追求效率删掉所有等待、优化所有循环结果脚本跑得飞快但每天崩两次维护成本远高于省下的那点时间。我的顺序反过来先加足够的等待保证不出错稳定运行一周之后再逐个把固定等待换成条件等待一点点压缩时间。这个过程急不得。第四条每个脚本都要写“这个脚本干什么、谁改过、改了什么”。工具本身没有强制的版本管理但可以在宏的第一行放个注释写明用途和最后修改时间。这个动作十秒钟能省掉半年后你自己看着一堆脚本发呆的半小时。最后分享一个我在实际使用中的体会这类工具最大的价值不是替你点几下鼠标而是逼着你把手上的流程第一次完整地、无歧义地描述出来。很多人以为自己熟悉某个流程真到要写成脚本时才发现中间有三处“看情况”、两处“凭经验判断”这些模糊地带平时靠人的临场反应糊过去了一旦要交给机器就全暴露了。把这些模糊地带补清楚哪怕最后没用工具你对这个流程的理解也已经上了一个台阶。