今年二月有个做财务共享中心的客户火急火燎地来找我，说他们的RPA发票验真系统全部崩了，脚本跑起来要么报错要么找不到元素，一张发票都验不了。积压了两千多张发票没验真，财务月底关账马上要到了，整个财务部都在加班手动验真，累得人仰马翻。我问他出什么事了，他说国家税务总局的全国增值税发票查验平台改版了，页面布局整个换了，按钮位置变了，输入框的ID也变了，他之前写的30多个RPA脚本全废了。
这个客户之前花了三个月开发了一套RPA发票验真系统，对接国家税务总局的查验平台，自动输入发票代码、发票号码、开票日期和校验码，抓取验真结果，再把结果写回他们的财务系统。30多个脚本覆盖了不同类型发票的验真流程，每天能自动验500多张，效率很高。但平台一改版，所有脚本依赖的页面元素定位全部失效——以前用按钮ID找元素，现在ID变了；以前用XPath定位输入框，现在页面结构变了XPath也废了。RPA脚本的核心就是定位页面元素，元素找不到了，脚本自然就跑不动了。
这种事在RPA领域叫”目标系统变更”，是RPA项目最常见的翻车场景。今天就讲讲遇到这种事怎么抢救，还有怎么提前预防。
平台改版导致RPA脚本失效这种事我遇到不下十次了，每次都是鸡飞狗跳。下面我把怎么应对说清楚。
RPA脚本为什么对平台改版这么脆弱
你得先理解RPA脚本的工作原理。RPA机器人模拟人在网页上操作，它的每一步都依赖”定位”——通过某种方式找到页面上的元素，然后对它做操作。定位的方式有很多种：用元素的ID属性，用CSS选择器，用XPath路径，用元素的文本内容。不管哪种方式，本质都是基于当前页面的结构来定位。一旦页面结构变了，原来的定位方式就失效了。按钮还在那个位置但ID变了，XPath变了，甚至整个页面布局都换了，脚本自然找不到元素了。
很多企业在开发RPA脚本的时候图省事，用浏览器自带的”录制”功能，点几下就把操作流程录下来了。录制功能生成的定位代码通常是基于XPath的，而且是最脆的那种——从页面根节点一路写到目标元素的完整路径。页面上只要多一个div或者少一个span，这个XPath就断了。我那个客户的30多个脚本，大部分就是录制生成的，定位代码特别长特别脆，改版一冲击全军覆没。
还有一种脆的情况是依赖元素的顺序位置定位。比如脚本用”第三个输入框”来定位发票号码的输入框，改版后输入框的顺序变了，原本第三个变成了第五个，脚本就把验证码填到了错误的框里。这种错误更隐蔽，不会报错但结果全是错的，如果不仔细检查输出根本发现不了。
脚本全废了怎么紧急抢救
遇到这种情况先别慌，按步骤来。第一步是评估改版的范围。打开新版页面，用浏览器开发者工具看一下页面结构，跟旧版对比，看哪些变了哪些没变。如果只是个别元素的ID变了，修复很快；如果整个页面重构了，可能要重新写定位逻辑。我那个客户的平台改版比较大，页面框架从传统的服务端渲染改成了前端框架渲染，影响面很广。
第二步是优先修复最核心的脚本。你不可能同时修30多个脚本，得排优先级。发票验真最核心的流程就是：打开验真页面 → 输入发票信息 → 点击查询 → 读取验真结果。先把这个主流程的定位修好，让基本验真能跑起来，其他边缘脚本后面再说。修复定位的时候，尽量用最稳定的定位方式：优先用元素的ID属性（如果新版有ID的话），再说CSS选择器配合唯一的class名或者data属性，实在不行才考虑XPath。XPath也要用相对路径而不是绝对路径，用元素的文本内容或者语义属性来定位，别用从根到叶子的完整路径。
第三步是批量测试和逐步上线。修复一个脚本就测一个，别全修完再一起测。每修好一个核心脚本，就拿几张测试发票跑一遍，确认验真结果正确再修下一个。我帮那个客户花了三天时间，先修好了最核心的通用发票验真脚本，覆盖了80%的发票类型，积压的两千多张发票两天就验完了。剩下的特殊发票类型脚本又花了一周陆续修好。
修复过程中有个教训要注意：别在修复的时候把脚本的逻辑也改了。有些开发者看到新版页面觉得操作流程可以优化，顺手改了步骤顺序或者增加了新逻辑，结果旧的问题没修完又引入了新的bug。修复就是修复，只改定位，不动逻辑。等所有脚本恢复正常运行了，再考虑优化。
怎么让RPA脚本更抗变更
抢救是亡羊补牢，预防才是正经事。让RPA脚本更抗变更，核心思路就是”用最稳定的定位方式”和”做监控告警”。
定位方式方面，我总结了几个原则。第一，能用API就别用UI操作。国家税务总局的发票查验平台其实是有接口的，虽然不对外开放，但可以通过正规的渠道申请对接。API接口比UI操作稳定得多，平台改版后端API一般不会大变。如果实在没有API，就用最稳定的UI定位方式。第二，优先用元素自带的功能性属性定位，比如ID、name属性、data开头的自定义属性。这些属性是开发者为了功能写的，改版的概率比class低。第三，用元素的文本内容辅助定位。比如按钮上写”查验”两个字，你用文本内容来定位这个按钮，只要按钮上的字没变，定位就不会失效。第四，如果非用XPath不可，用相对路径，从最近的稳定父元素往下找，别从页面根节点开始写。
监控告警方面，你得分两层做。第一层是运行时监控，脚本每一步执行后检查结果是否符合预期。比如点击查询按钮之后，检查页面上是否出现了验真结果区域，如果没出现就说明可能定位失效了，立即停掉脚本并发告警。不要让脚本继续跑下去把错误结果写进系统。第二层是定时巡检，每天在非工作时间跑一遍脚本的健康检查——打开目标平台，检查关键元素能不能定位到，定位不到就发告警，在人上班之前就发现问题。我帮那个客户加了一个每天凌晨6点自动跑的巡检脚本，如果验真平台又改版了，6点半就能收到告警，上班之前就能开始修复，不至于堆积一堆发票。
还有一个长期策略是降低对单一平台的依赖。发票验真除了国家税务总局的查验平台，有些第三方平台也提供验真服务，虽然底层数据是一样的但入口不同。如果你的RPA系统支持多平台切换，一个平台改版了可以切到另一个平台继续验，不至于全面停摆。这需要你在设计RPA架构的时候就把多平台适配考虑进去，把验真逻辑和平台操作分离，每个平台写一套适配器，主流程不变。我那个客户现在就在做这个事，花了两个月搭了双平台架构，再也不会被一个平台改版搞得鸡飞狗跳了。
说到底，RPA做发票验真这种依赖外部平台的场景，最大的风险不在你的脚本写得好不好，而在你控制不了的那个平台什么时候改版。你能做的就是把定位做得尽量稳、监控告警做到位、多平台适配兜底。在北京帮企业做RPA自动化的项目，我每次都会跟客户强调：RPA不是一锤子买卖，上线后要持续维护，目标系统一变你就得跟着改。把维护成本提前算进去，别觉得上线了就万事大吉。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18910232032
- 扫码添加专业经营合规顾问，免费咨询 ↓
