做自动化最怕的不是不会技术，而是根本没想到还能这么做

AI 时代做自动化，真正重要的可能不是“会什么”，而是“想到什么”

先说明一下：这篇并没有跑题，日期选择器依然是核心案例，只是我想借这个案例再往前走一步——聊聊除了模拟点击、输入之外，RPA 还能不能从更高一层直接解决问题。

做自动化这么久，我越来越觉得一个很有意思的问题：

自动化，到底为什么一定要“模拟人”？

很多 RPA 新手刚开始做自动化的时候，天然会按照人的思路来设计流程：

人怎么做，RPA 就怎么做。

人点击按钮，RPA 点击按钮。

人打开下拉框，RPA 打开下拉框。

人滚动页面，RPA 滚动页面。

人输入文字，RPA 输入文字。

人从登录页面开始操作，RPA 也从登录页面开始操作。

这种思路当然没有错。

毕竟 RPA 最直观的价值，本来就是把人的操作交给机器。

但做到后面，你会慢慢发现：

人的操作路径，不一定是程序最优的实现路径。

先举一个甚至和 RPA 都没关系的例子

比如我要让电脑关机。

按照模拟人工的思路：

点击开始菜单 → 找到电源 → 点击关机 → 等待系统响应

但如果你知道 CMD 命令，一条 shutdown /s /t 0 就可以直接完成。

那为什么还要模拟人点来点去？

难道点得更像人，就会更稳定？

恰恰相反。

点击开始、寻找菜单、寻找按钮、点击、等待……

步骤越多，就意味着可能出问题的地方越多。

而：

一条命令 → 完成

反而更加直接。

所以我觉得自动化有一个特别容易被忽略的原则：

自动化的核心不是模拟人，而是找到更短、更直接、更稳定的实现路径。

如果有巧招，为什么非要绕远路？

很多 RPA 新手，其实一直在模拟“人”，而不是在解决“问题”

比如一个下拉框。

人工操作可能是：

点击下拉框 → 等待展开 → 寻找目标选项 → 点击目标选项

于是自动化也照着做。

但如果它是一个原生 select，从程序的角度看，我们真正想要的结果可能只是：

让它最终处于某个指定的 value。

那么为什么一定要模拟：

点击 → 展开 → 寻找 → 点击？

当然，这里不是说所有网站都可以简单修改 select.value 就结束。

现在很多网站使用 Vue、React 或各种自定义组件，直接修改 DOM 后还可能需要同步组件状态、触发事件。

但这里真正值得关注的，其实不是：

“Select 到底怎么改？”

而是：

“我有没有必要按照人的方式操作它？”

这两个问题看起来差不多，实际上已经不是一个层次。

再比如很多人特别喜欢“模拟滚动”

假设我要操作一个页面底部的元素。

人的操作习惯当然是：

往下滚 → 再往下滚 → 找到元素 → 点击

所以很多自动化流程也会写成：

滚动 500 → 等待 → 再滚动 500 → 等待 → 寻找元素 → 点击

但如果 RPA 本身能够直接定位这个元素，很多时候根本不需要你提前模拟人的滚动过程。

直接：

找到目标元素 → 操作

至于元素当前是不是在屏幕可视区域里，自动化工具本身可能就会帮你处理，比如自动滚动到元素所在位置。

所以：

人需要滚动页面才能看到元素，不代表程序也必须先滚动页面。

这句话我觉得特别值得 RPA 新手记住。

不要把人的限制，一起复制给程序。

甚至“从电脑开机开始自动化”，也不一定是好事

还有一种我经常看到的思路：

恨不得电脑开机以后，整个流程全部自动化。

电脑开机 → 启动浏览器 → 打开网站 → 输入账号 → 输入密码 → 验证码 → 滑块 → 登录 → 进入业务页面 → 开始真正的自动化。

然后花大量时间研究：

验证码怎么处理？

滑块怎么处理？

登录态怎么保持？

风控怎么处理？

但如果实际工作场景允许：

人工登录 → 进入目标网站 → RPA 接管 → 开始真正的业务流程

为什么不可以？

注意，这不是因为验证码解决不了。

而是：

这一步有没有自动化的价值？

如果人工登录只需要十几秒，你却为了让整个流程“100% 无人参与”，花几个小时研究验证码。

那到底是在提高效率，还是在给自己增加工作量？

所以自动化还有一个非常重要的原则：

不是所有能自动化的步骤，都值得自动化。

自动化的目的，是减少人的工作量、提高效率和稳定性。

而不是为了证明：

“我连登录都能自动化。”

元素捕获也一样：捕获出来，不代表这个定位就是最好的

很多新手遇到元素：

发现元素 → 捕获元素 → 复制 XPath → 得到一大串表达式 → 直接使用

甚至自己都不知道这个 XPath 为什么能够定位到它。

页面稍微变化：

失效。

如果暂时还不熟 XPath、CSS，其实 AI 时代已经有一个非常方便的辅助方式。

把目标元素附近的一小段 HTML 源码复制出来，然后告诉 AI：

我要定位这个元素，帮我分析一下这个 HTML，给我一个尽可能短、稳定的 XPath 或 CSS。

AI 可以帮你分析：

父子结构、class、id、属性、文本、兄弟节点、动态属性……

然后给出一个更合适的定位方式。

这并不是说：

“XPath 不需要学了。”

而是：

你首先要知道，HTML 结构本身就是一条解决问题的路。

至于具体怎么写，在 AI 时代，完全可以让 AI 帮你完成。

你不一定要把所有东西都背下来。

但你要知道：

这里有一条路。

真正应该提高的，是“换一层”的能力

我现在反而觉得，RPA 学习过程中一个非常重要的能力，不是记住多少模块。

而是：

当当前这条路走不通的时候，你能不能想到还有另一条路。

比如：

元素操作不行？

可以考虑 JavaScript。

JavaScript 还不够？

可以看看 DOM。

DOM 只是表象？

可以继续看看组件。

组件背后还有什么？

状态。

状态背后还有什么？

数据模型。

再往下？

接口。

当然，不是让你每次遇到一个按钮，都一路研究到接口。

完全没必要。

真正合理的原则应该是：

简单的问题 → 简单解决。

复杂的问题 → 换一层。

当前方案步骤太多、太脆弱 → 寻找更直接的方案。

所以：

不是越底层越高级，而是找到最适合当前问题的那一层。

这时候你会发现，很多所谓“表单操作”，根本不一定是在操作表单

这其实也是我特别想强调的一点。

我们平时说：

“填写日期。”

“填写进度。”

“选择地区。”

“填写富文本。”

看起来都是一些非常普通的表单操作。

但现代网页里的这些控件，早就不一定是一个简单的 input 或 textarea 了。

比如：

日期选择器

你看到的是一个日期框。

但背后可能是 Vue / React 组件维护的一组日期状态。

进度条

你看到的是一个滑块。

人工可能需要按住鼠标拖到 70%。

但它背后可能就是一个 value = 70。

级联选择器

你看到的是：

省 → 市 → 区。

人工需要一级一级点击。

但组件内部可能维护的其实就是一组数据：

省份值、市级值、区县值。

下拉选择器

你看到的是一个需要点击展开的菜单。

但如果是原生 select，它本身就有对应的 value。

甚至一些自定义组件，也可能存在自己的选中状态。

富文本编辑器

这个就更加典型了。

很多人看到一个编辑框，第一反应就是：

点击 → Ctrl+A → 输入 → 换行 → 粘贴 → 调整格式……

但有些所谓的“输入框”根本不是普通的 input。

可能是 contenteditable，也可能是网站自己封装的一整套编辑器。

而它真正维护的内容，可能已经是结构化的数据：

段落、换行、加粗、链接、图片……

甚至某些场景下，你根本不需要模拟几十次键盘操作，而是可以研究它真正接受的数据结构，再从数据层面解决。

当然，这里同样不是说：

“所有表单都应该直接改数据。”

而是想让刚开始做自动化的人意识到：

你看到的是 UI，不一定就是它真正的数据入口。

所以，别把“填写表单”理解得太死

以后再看到：

日期选择器、时间选择器、下拉框、级联选择器、进度条、富文本编辑器、自定义编辑框……

不要条件反射式地认为：

“我得模拟一个人把它操作一遍。”

可以多问一句：

“这个控件真正需要改变的是什么？”

我要的是一次点击吗？

还是最终的选中值？

我要的是鼠标拖动吗？

还是最终的进度值？

我要的是一级一级选择吗？

还是最终的地区数据？

我要的是模拟键盘输入吗？

还是最终的富文本内容？

这时候你会发现：

“操作 UI”只是实现目标的一种方式。

而不是唯一方式。

AI 时代，这个问题变得更加有意思

以前很多时候：

不会 XPath → 做不了。

不会 JS → 做不了。

不会 Vue → 做不了。

不会接口 → 做不了。

但 AI 出现以后，情况发生了变化。

你不一定什么都已经掌握。

但如果你知道：

“这个问题可能可以从 DOM 入手。”

那么可以让 AI 帮你分析。

如果你知道：

“这个控件可能是 Vue 组件。”

你可以把相关结构、对象信息交给 AI，让它帮你判断。

如果你知道：

“这个值可能藏在某个 JavaScript 对象里。”

你可以让 AI 帮你分析对象结构。

如果你知道：

“这个问题可能存在一个接口。”

也可以让 AI 帮你分析请求。

所以我越来越觉得：

AI 时代做自动化，真正重要的可能不是“会什么”，而是“想到什么”。

做自动化最怕的，不是不会技术

而是：

根本没想到还能这么做。

你不会 XPath，可以学。

不会 JS，可以让 AI 辅助。

不会分析 DOM，可以让 AI 帮你看。

不会某个框架，也可以逐步研究。

真正麻烦的是：

你遇到一个问题以后，脑子里只有：

点击 → 输入 → 滚动 → 再点击。

你根本不知道：

还能改 value。

还能改 DOM。

还能找组件状态。

还能找数据模型。

还能调用接口。

还能执行命令。

还能把某些步骤直接省掉。

那么 AI 再强，也很难帮你。

因为：

AI 可以帮助你实现一条路，但首先得有人想到这条路。

所以我现在越来越觉得：

技术能力决定你能不能把方案落地。

但：

思路决定你有没有方案。

这其实就是我理解的“自动化思维”

很多人学 RPA，是在不断积累：

“这个模块怎么用。”

“那个模块怎么用。”

“这个元素怎么点。”

“那个组件怎么捕获。”

这些当然都重要。

但如果一直停留在这里，很容易形成一种固定思维：

看到什么，就操作什么。

看到按钮 → 点。

看到输入框 → 填。

看到下拉框 → 展开。

看到页面底部 → 滚。

看到登录页 → 自动登录。

看到元素 → 捕获。

而更进一步的自动化思维应该是：

看到目标 → 先想实现目标最短的路径。

按钮一定要点吗？

下拉框一定要展开吗？

页面一定要滚吗？

登录一定要自动吗？

元素一定要用工具捕获吗？

表单一定要模拟输入吗？

组件一定要按照人工方式操作吗？

如果不这么做，还有没有更直接的方法？

所以现在再让我总结“自动化最重要的能力是什么”

我可能不会首先回答：

XPath、Python、JavaScript、Selenium、影刀……

这些当然重要。

但我觉得更重要的是：

当一条路走不通的时候，你能不能想到还有另一条路。

你不一定马上会写。

你甚至可以暂时不会写。

但你得知道这条路存在。

比如：

下拉框 → 能不能直接设置值？

进度条 → 能不能直接控制 value？

日期选择器 → 它真正维护的数据在哪里？

级联选择器 → 能不能直接处理最终选中状态？

富文本 → 它真正的数据结构是什么？

元素不在屏幕里 → 我为什么非得先滚动？

登录流程 → 这一步到底有没有必要自动化？

XPath 不会 → 能不能把 HTML 给 AI 分析？

页面操作复杂 → 有没有更底层的数据入口？

重复操作很多 → 有没有一条命令、一个对象或者一个接口可以直接完成？

这些问题本身，可能比：

“具体怎么写代码。”

更加重要。

我觉得这就是 RPA 新手真正值得提高的一层“眼界”

不是让大家抛弃传统 RPA。

也不是说：

“以后都别点击了。”

恰恰相反。

简单问题，就用简单的方法。

该点击就点击。

该输入就输入。

该捕获元素就捕获元素。

但是当你发现：

步骤特别多。

等待特别多。

模拟动作特别多。

流程特别脆弱。

或者一个小小的控件就要折腾半天。

这个时候就应该警觉：

是不是我选错层了？

是不是可以换一个定位方式？

是不是可以用 JS？

是不是可以直接操作 DOM？

是不是可以寻找组件状态？

是不是可以寻找数据模型？

是不是可以调用接口？

是不是可以执行命令？

甚至是不是可以把这一段留给人工，让 RPA 从真正有价值的地方开始接管？

能省的步骤，就应该省。

有巧招，就应该优先考虑巧招。

能直接完成，就没必要绕一圈模拟人工。

因为从稳定性的角度来说：

模拟人工，本身就意味着你在复刻人的操作过程，而人的操作过程往往充满了不必要的中间步骤。

最后

我越来越觉得：

自动化不是把人的动作复制一遍。

人怎么做，只是一种实现方式。

程序真正应该寻找的是：

更短、更稳定、更直接的实现路径。

如果一条命令能解决：

就没必要点十次。

如果直接改值能解决：

就没必要模拟鼠标。

如果直接控制数据能解决：

就没必要绕着 UI 走一圈。

如果某一步本身就不值得自动化：

就没必要为了“全自动”而强行自动化。

而 AI 时代，又给了我们一个新的可能。

以前可能是：

“我不会，所以做不了。”

现在可能变成：

“我知道这可能是一条路，让 AI 帮我把它走通。”

所以现在再让我总结一句：

AI 时代做自动化，真正重要的可能不是“会什么”，而是“想到什么”。

因为很多时候，真正限制我们的不是不会做。

而是：

根本没想到可以这么做。

所以做 RPA，别只学：

怎么点击。

也要慢慢学会：

为什么一定要点击？

能不能不点？

能不能换一层？

能不能少几个步骤？

能不能找到更短、更稳定的路径？

能不能直接改变驱动 UI 的数据？

能不能让 AI 帮你把一个你“想到但不会做”的方案落地？

这可能才是 AI 时代，普通 RPA 用户真正值得提高的一层：

眼界。