夜深了，屏幕的光照在脸上。
我盯着那段 Selenium 脚本，它又崩了。原因和上次一样——某个后台系统改了登录页面的按钮 ID。从 btn_login 变成了 login-submit。就两个字符的变化，整个流程停摆。
改好定位器，重新跑通，我靠在椅背上想：这已经是这个月第三次了。每次改版都要花时间修，修完还要测试。如果这个任务要跑一年，维护成本早就超过了手工操作的时间。
那段时间我开始琢磨一件事：自动化的工具，到底应该怎么选？
两条路，两种抽象
第一条路，是我走了很多年的老路——手写代码。控制每一个细节，定位每一个元素，处理每一种异常。下面是一段典型的工作流，用来从某系统拉取报表：
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import pandas as pd
import time
driver = webdriver.Chrome()
driver.get("https://内网系统")
wait = WebDriverWait(driver, 10)
username = wait.until(EC.presence_of_element_located((By.ID, "username")))
username.send_keys("your_account")
password = driver.find_element(By.ID, "password")
password.send_keys("your_password")
login_btn = driver.find_element(By.XPATH, "//button[text()='登录']")
login_btn.click()
wait.until(EC.url_contains("/report"))
table = wait.until(EC.presence_of_element_located((By.CLASS_NAME, "data-table")))
df = pd.read_html(table.get_attribute("outerHTML"))[0]
df.to_csv(f"report_{time.strftime('%Y%m%d')}.csv", index=False)
driver.quit()
这段代码足够健壮，用了显式等待，定位方式也尽量通用。但它有几个绕不开的问题：你需要懂 HTML 结构，需要知道 XPath 怎么写，需要处理浏览器驱动的版本兼容。而且，对于一台低配置电脑来说，同时跑 Python 解释器和浏览器驱动，资源消耗不小。
第二条路，是我后来接触的可视化编程类工具。它们把浏览器操作拆解成一个个“块”——打开网址是一块，填写文本是一块，点击按钮是一块。把这些块按逻辑顺序连接起来，一个自动化流程就搭好了。
这类工具的好处很明显。对于桌面自动化工具小白操作要点，它几乎是零门槛。你不需要知道什么是 DOM 树，不需要记 XPath 语法，只需要清楚自己想先做什么后做什么。页面结构变化时，你也不用翻代码，直接在界面上重新抓取一下元素的位置就行。而且，很多这类工具是本地运行的，数据不经过任何云端，隐私安全上天然有优势。
但我也很快发现了它的软肋。当流程里需要加条件判断时——比如“如果页面出现弹窗就关掉，否则继续往下走”——在代码里就是几行 if，在可视化界面里却要拖出一堆条件块，嵌套两层，整个流程图变得臃肿难读。更不用说那些需要与数据库交互、做复杂计算的场景，可视化工具很难覆盖。
混合使用的经验
后来我摸索出一套自己的做法。
线性的、步骤固定的流程，比如每天早上的数据拉取，我用可视化工具搭。这类任务往往涉及多个应用之间的配合——浏览器里提取数据，桌面软件里整理，再发邮件——多应用协同自动化配置思路在可视化界面里就是几根连接线的事，比写代码跨进程通信要直观得多。而且，协同自动化工具轻量化部署流程的优势就在于快速落地，不需要搭建复杂的开发环境。
复杂的、需要深度定制的任务，我还是写代码。比如那个报表拉下来之后，要和数据库里的历史数据做比对，算出增长率，再根据阈值决定要不要发警报。这种逻辑用代码写清晰，用可视化搭反而会变得臃肿。
这两种方式不是谁替代谁，而是互补。代码给你最大的灵活性，可视化给你最低的上手门槛。
还有一个被很多人忽略的维度：资源占用。我有一台用了很多年的旧笔记本，跑 Python + ChromeDriver 时风扇会狂转，电池也撑不了多久。后来我把那些重复的浏览器操作迁移到可视化工具上，资源占用降了一大截。这让我意识到，低配置电脑跑自动化工具的适配方法有时候不一定是“升级硬件”，换一种工具可能比换电脑更实际。
两边的代价
说了这么多优点，也得承认两边的缺点。
手写代码的脆弱性，我太熟悉了。页面改版、网络抖动、依赖库更新，任何一个环节出问题，整个流程就停摆。而且代码维护需要持续的精力投入，尤其当你同时维护五六个这样的自动化任务时，成本会线性增长。有一次我统计了一下，一个跑了半年的脚本，维护时间加起来已经超过了手工操作的时间总和。
可视化工具的局限性则体现在它的“黑盒”属性上。你无法精确控制每一个细节，遇到边缘情况时往往需要绕路。比如某个网页的按钮需要先悬停才能点击，可视化工具如果没有对应的“悬停”块，你就只能用坐标点击这种不稳定的方式。而且，当流程复杂到一定程度时，可视化界面本身也会变得难以管理——拖拽几十个块、十几条连线，可读性甚至不如一段结构清晰的代码。
回到最初的问题
那天晚上修完脚本之后，我把那个任务分成了两部分。浏览器操作的部分，我换成了可视化工具来跑；数据分析和告警的部分，保留代码。两种工具各管一块，互不干扰。
到现在，那个流程已经稳定跑了四个多月，没有再崩过。
这让我想明白一件事：自动化的核心不是“用什么工具”，而是“如何把问题拆解成适合不同工具的部分”。代码也好，可视化也好，都只是手段。1949 这个标签代表的是其中一种思路——轻量、本地、低门槛——但它也只是众多选择中的一个。
选择哪条路，取决于你手里是什么样的活，以及你愿意为它花多少心思去维护。
