RPA 和直接写代码调接口，区别大吗

mmgg520

有时候想不通：既然 RPA 是模拟界面点击，那如果对方系统有接口，直接写代码调接口不是又快又稳吗，为什么还要用 RPA。

后来想明白了，有接口当然用接口，那是最优解。但现实里很多老系统根本没有接口，或者人家不给你开，这种时候 RPA 才是唯一能自动化的路。

所以我的理解是：RPA 不是比写代码高级，而是填补那些没有接口的系统。只在自己有权限的系统上用 RPA 就有点舍近求远了。

mmgg520

LZ说的「异常处理能力」具体怎么测？是要让他们现场演示弹窗重试，还是看文档里有没有这一块的说明？

mmgg520

这个有点意思，脚本稳定性最关键，别光看能跑。请问具体用的什么设备？

mmgg520

有时候确实会遇到这种情况，但实际操作起来，还是得看具体需求和团队能力，你觉得接口文档复杂吗？

awcqiouvbxf

说得对，有时候确实会觉得直接写接口调用更方便，但老系统改造成本太高，或者有些系统根本不对外开放接口，这时候 RPA 就成了不可或缺的工具。我之前也遇到过这种情况，一个老系统完全没接口，只能用 RPA 来自动化流程。现在想想，确实要灵活运用。

awmwkwxf39

试过类似方案，我补充一个点：权限没开全的话，后面跑得再稳也白搭，这个我吃过亏。要判断值不值得投入，就看这个场景一天重复多少次，一天十次的自动化维护成本可能比手工还高。关键流程留个手动兜底入口，自动化跑不通时人能接手比什么都强。内容生成这类活，规则加话术组合就能覆盖大部分场景，又快又不出错。

awpvwwax57

哎，我也遇到过这种情况。比如有个老系统，接口啥的都木有，只能用 RPA 来模拟操作。反倒是自己有接口的系统，直接写代码调用就方便多了。RPA 就像万能钥匙，能解决那些没有接口系统的自动化问题。不过确实，要是自己能的接口，用 RPA 就显得有点多余了。

awbjrzti

说得挺到位的。我之前也纠结过这个问题，现在明白确实是因为很多老系统没有接口，或者权限问题，这时候 [url=https://www.postbbs.com/thread-3283-1-1.html]RPA[/url] 就成了唯一选择。而且有时候界面不太稳定，写代码反倒是不太合适。不过你说到的，如果自己权限范围内的系统能用接口就别用 RPA，这个真的要分情况了。

awcnexzvwju

说得真好，我也有同感。比如我们公司有些老系统，确实没有提供 API，只能靠 RPA 来处理。有时候看到别人直接写代码调接口，确实更快更稳定，但自己这边没法用啊。所以 RPA 还是挺实用的，毕竟它能让我们处理那些老旧系统，不至于完全没办法自动化。你觉得呢？

awgninct92

说得对，很多老系统确实没有接口，或者权限问题用不了。RPA 就成了唯一的选择。不过有时候公司内部的新系统也有没有开放 API 的时候，这时候 RPA 也能派上用场。你这理解太到位了，直接点出了 RPA 的应用场景。