那个周六早上7点40分，手机震了
客户的对账机器人挂了。这是它连续第14天准时跑完，第15天挂了。
远程连上去，日志停在 Click '导出' 这一步——超时30秒，重试3次，全挂。打开浏览器一看，对方财务系统悄悄把导出按钮从 <button id=“btnExport”> 换成了 <div class=“ant-btn” role=“button”>。一次前端重构，我们这边4个流程全废。
改选择器前后花了40分钟。但类似的事，2023年我遇到了27次。所以今天不想讲 RPA 能做什么——那玩意儿厂商 PPT 里都有。我想聊聊为什么大部分 RPA 项目会在第3到第6个月开始烂尾，以及如果你还没上车，怎么判断该不该上。
先说个不太讨喜的观点
RPA 本质上是把一件本该用接口解决的事，降级到 DOM 和像素层面去解决。
银行、老 ERP、十几年前的 OA，要么根本没 API，要么有 API 但要走三个月采购流程。这种时候 RPA 是个能绕过 IT 部门的权宜之计，它天生是补丁，不是地基。问题在于很多公司把补丁当地基用——第一个流程上线，老板觉得爽，半年内铺了40个机器人，没人管维护，最后运维团队天天救火。
所以我不太认同「RPA 能替代人工」这种说法。准确点讲：RPA 是把「人工执行的成本」换成了「维护的成本」。省没省，得看你换得划不划算。
该不该上？我一般让客户先算三个数
| 指标 | 红线 | 我的判断 |
|---|---|---|
| 流程页面的年变更次数 | 大于 4 次 | 别做，或者退化成半自动模板 + 人工确认 |
| 每天执行频次 | 小于 1 次 | 投入产出比撑不住，让实习生来 |
| 对方系统有没有可用 API | 有 | 有就别用 RPA，直接写脚本，维护量差5倍以上 |
第三个数字是我最看重的。见过太多项目，业务方说「系统没有接口」，结果一查，有个现成的 REST 接口，只是要 IT 开个权限，走流程等了六周。为了省这六周，他们上了 RPA，后来每年多花 150 个工时维护。这笔账我到现在都没想明白。
四种方案摆一起，成本差在哪
| 维度 | UI层RPA（UiPath/影刀） | 浏览器自动化（Playwright） | 系统API对接 | LLM Agent |
|---|---|---|---|---|
| 单流程首次开发 | 24–80 工时 | 16–40 工时 | 40–120 工时（含联调） | 20–60 工时，不含调 prompt |
| 年均维护工时 | 120–260 | 40–80 | 8–20 | 60–150，看模型版本变动 |
| 界面改版后修复时间 | 0.5–3 小时 | 0.5–2 小时 | 0 | 视情况，有时改一晚上 |
| 能不能操作 Citrix / 桌面客户端 | 能 | 基本不能 | 看情况 | 很弱 |
| 业务人员看不看得懂 | 能，流程图摆在那 | 看不懂 | 看不懂 | 半懂不懂 |
这里有个反直觉的地方：Playwright 这类浏览器自动化，稳定性其实比 RPA 还好一点。因为它可以用 get_by_role('button', name='导出') 这种语义定位，比 RPA 里那种 div[12]/div[3] 的路径靠谱得多，而且跑在无头模式里，速度快 3 到 5 倍。
但 RPA 赢在覆盖面。它能开 Excel、点 SAP 客户端、在一台 Citrix 虚拟机里像个真人一样操作，还能让业务流程的人看懂那条流程图然后签字确认。这两件事 Playwright 都做不到。所以选型不是比谁先进，是比谁的短板更不致命。
选择器这件事，我现在有5条硬规矩
- 绝不用 idx。UiPath 里那个
idx='2'，翻译成人话就是「右边第三个按钮」，页面顶上加个公告条就废了。 - 能用 automationid / data-testid 就别用 XPath。真要用 XPath，用语义定位：
//label[normalize-space(text())='导出']/following::button[1]，而不是//div[@id='app']/div[2]/div[3]/div[1]/button。这两种写法在页面加一个广告位之后的存活率，我实测差了不止10倍。 - 上模糊匹配 + anchor。UiPath 的 Fuzzy Selector 和 Anchor Base 很多人装了就没用过，其实在那些 class 名天天变的老系统上，能救一半的命。
- 把默认的30秒超时拆开。默认值太长了，一个流程10个元素，全卡满就是5分钟白等。我一般改成 5 秒显式等待 + 最多 3 次轮询，实际平均失败判定时间从 30 秒降到 8 秒左右。
- 重试用指数退避：2秒 → 5秒 → 15秒，3次还不行就丢队列，别
while true死循环。我见过一个跑了一整夜把对方接口刷爆的机器人，就是因为循环里没写退出条件。
一个我自己在用的办法：探针
这可能是今天唯一算得上原创的东西。
每上线一个流程，我会额外写一个探针流程，只干一件事：每天早上 7:00 打开那几个关键页面，检查 6–10 个核心元素存不存在，30 秒跑完，任意一个返回 False 就推企业微信。
成本：开发 1 小时，每天消耗 30 秒机器人时间。 收益：把「业务方发现机器人挂了」变成「我发现，然后提前修」。
2023 年我在一个 12 流程的项目里加了探针，那一年业务方投诉 2 次；前一年，同样的系统，11 次。这个改动本身没什么技术含量，但它改变的是责任的位置。
算笔账：为什么说维护是开发的3倍
拿一个中等复杂度的流程举例（登录 → 取数 → 校验 → 上传 → 回执）：
- 首次开发：约 60 工时，按 800 元/工时外包价算，4.8 万
- 第一年维护：约 180 工时，14.4 万
- 机器人授权：UiPath unattended 大概 1.5–3 万/年/台；国产的影刀、实在便宜一些，几千到一万不等
- 出错后的业务成本：一次对账错误，财务要花 2–4 小时人工核对，还不算被老板问话的时间
三年 TCO 大概是首次开发的 4–6 倍。这个数厂商不会主动给你算，PPT 上一般只写「节省 3000 人天」。
这几类流程，我劝你别做
- 界面一年变 6 次以上的
- 有验证码又没打码预算的（打码平台 1 万次大约 100–300 元，量大了真不便宜）
- 每天数据量不到 20 条的，人工点两下就完了
- 涉及资金流转但没人做人工复核的——这个是真会出事，不是吓唬你
- 只是为了让老板看到「AI 转型」的
最后
RPA 不是不好，是它被卖得太好了。它的甜区很小：高频、稳定、没 API、规则明确。这四个条件缺一个，成本就开始指数上升。
我现在接项目前习惯先问一句：这个流程，一年会变几次？答不上来的，我一般不接。