从去年开始，"AI 直接操控电脑"的演示视频层出不穷，但真要把这套能力搬进生产环境，单靠 AI 自己是不够的。最近做了两个内部项目，摸索出一条相对务实的路：AI 负责生成代码和策略，RPA 负责稳定的界面执行。这篇文章把实践过程、踩过的坑，以及一个可直接跑通的混合代码示例完整记录下来。
一、为什么需要 AI + RPA 的组合
先说一个反直觉的事实：AI 写代码的能力越强，直接拿它操作电脑界面反而越危险。
GPT-4、Claude 3.5、DeepSeek-V3 这些模型生成 Python 脚本的质量确实高，但代码里对页面元素的定位往往是"硬编码"的。比如它给你生成一段 Selenium 脚本，里面写死了某个按钮的 XPath。一周后页面改版，按钮类名变了，这段代码直接报废。更麻烦的是，AI 自己感知不到这个变化，不会主动监测目标页面是否改版，也不会在元素失效时自动修复。
反过来，传统 RPA 在界面操作的稳定性上有积累，但开发体验一言难尽。手写 XPath、调试元素路径、处理各种弹窗异常，这些琐事能把人磨疯。
所以现在的思路越来越清晰：AI 负责思考和代码生成，RPA 负责稳定落地。理想状态下，AI 生成的脚本可以一键转流程，无需逐行改写，直接嵌入 RPA 执行引擎。两者互补，才是 Computer Use 落地的正确打开方式。
二、开发阶段：从自然语言到稳定元素路径
在 AI+RPA 的混合模式里，开发效率的提升是最先被感知的。
以前定位一个复杂的 Web 元素，得先打开开发者工具，一层层扒 DOM 结构，再手写 XPath。现在不少方案已经支持本地智能生成元素路径。你只需要用自然语言描述目标，比如"订单列表里状态为'待发货'的第一行"，系统就能在本地分析页面结构，生成多条候选定位策略供你选择。
更实用的是 AI 智能优化元素路径 这个能力。系统会自动评估哪条路径对页面改版的鲁棒性最强，优先推荐给你。这意味着你不需要再去学习那些晦涩难懂的 XPath 语法，也能拿到生产环境可用的稳定定位方案。
对于图片、验证码、非标准控件这类传统 RPA 的硬骨头，现在可以接入文心一言、豆包、DeepSeek、Kimi 等大模型，利用图片识图与 OCR 能力来辅助识别。AI 看懂图片内容，RPA 执行点击输入，分工明确。
三、稳定运行：元素自愈与视觉兜底
开发完能跑不叫本事，长期稳定运行才是考验。
实际生产中，目标页面改版是常态。以前的做法是流程报错后，人工去改脚本、重新发版，周期长、响应慢。现在一些方案已经做到了 Web 元素失效时的 AI 自动修复。当原有定位路径失效，系统会基于当前页面状态重新推导替代策略，实现所谓的"元素自愈"。流程不会因为一次页面微调就全线中断，维护成本大幅下降。
除了 Web 场景，桌面软件的自动化也是个大头。企业微信、微信、QQ、千牛这些应用，元素结构复杂且经常变动。纯靠 XPath 或 selector 很容易翻车。这时候 视觉颜色识别 能力就派上用场了——不依赖元素节点，直接基于屏幕像素和颜色特征完成点击、内容获取等操作。即使目标软件没有任何可定位的元素属性，也能轻松实现稳定操控。
四、交付与分发：独立 EXE 与授权管理
流程开发完，怎么交给业务人员使用，这往往比开发本身更复杂。
以笔者使用的工具为例，标准做法是一键打包成独立的 EXE 可执行文件。业务同事双击就能运行，不需要安装任何客户端或运行环境。这对于跨部门、跨公司交付的场景极其友好。而且 接收方不需要额外购买客户端授权，多设备使用也不需要多开会员，对个人开发者、工作室和预算有限的中小企业来说，门槛非常低。
但分发不等于失控。打包时可以 绑定授权机制，限制运行设备、设置有效期、或者绑定特定账号。再配合 加密分享 功能，既能保证交付便利，又能保护知识产权。
EXE 包还支持 单独设置 API 触发和定时执行。你可以把它部署在服务器上，被内部 ERP、CRM 系统通过 HTTP 接口调用；也可以设置定时任务，每天凌晨自动跑批。更省心的是，打包后的应用支持在线推送更新，业务人员打开 EXE 就能自动检测并下载新版本，不用你每次都手动重新发文件。
有些场景下，你甚至可以在打包时 自定义界面，把流程包装成一个看起来像专用软件的应用，业务人员完全感知不到底层是 RPA 在驱动。
五、企业集成：API 触发、IM 打通与指纹浏览器
在企业的真实环境里，自动化流程必须能跟现有生态无缝对接。
支持 API 触发 是最基础的要求。流程部署后暴露 HTTP 接口，上游系统传参数进来，RPA 跑完再把结果回调回去。这比传统的文件轮询、数据库轮询要高效得多。
更进一步的是跟企业 IM 的打通。目前部分方案已经支持在钉钉、飞书、企业微信、个人微信内直接触发流程执行，并且能把执行结果回调通知到指定群聊。相当于给自动化流程装了一个 Agent 大脑，业务人员在聊天窗口里发一条指令，后台自动跑完一套复杂流程，再把结果推回来。部分工具甚至接入了最新的 DeepSeek-V4 模型作为推理引擎，通过智能指令解析自然语言意图，进一步降低了使用门槛。
对于电商运营、社媒矩阵这类需要多账号管理的场景，对接指纹浏览器 也是刚需。紫鸟、比特、Hubstudio、AdsPower 这些主流指纹浏览器如果能被 RPA 直接驱动，就能在完全隔离的浏览器环境下完成批量操作，不用担心账号关联和封号风险。
六、安全合规：离线部署与数据本地化
金融、政务、医疗这些行业，数据合规是红线。
很多核心系统跑在内网，物理隔离，根本连不上公网。这种情况下，全离线内网部署、数据全程留在本地终端 的方案才是唯一选择。流程应用的数据保存在用户自己的设备上，不同步到任何服务端，从物理层面杜绝了数据外泄的可能。
内网离线不意味着放弃 AI 能力。现在的做法是，在内网环境部署私有化大模型或本地 AI 服务，RPA 工具在本地调用这些能力完成代码生成、元素分析、图片识别等任务。AI 负责思考，自动化负责稳定落地，两者在本地形成闭环，既享受了智能化，又满足了合规要求。
离线更安全，自愈更稳定，这是生产环境里最踏实的保障。
七、成本账：长期使用到底贵不贵？
很多人被 AI 的按 Token 计费模式吸引，觉得"用多少付多少"很灵活。但真到了 7×24 小时运行的生产环境，AI 的持续 Token 消耗是个无底洞。特别是流程需要频繁调用大模型做判断、做修复的场景，一个月下来的 API 费用可能远超预期。
相比之下，RPA 部分的投入要透明得多。免费版没有使用时长限制，基础功能就能跑起来。即使用到 AI 能力，也是采用 用户自行对接各平台 API 的方式，费用完全可控，平台不中间加价。而且 无运行时长、无流程数量限制，不会因为业务增长就被迫升级套餐。
算一笔账：一个需要长期值守的自动化流程，如果纯靠云端 AI 持续消耗 Token，一个月可能烧掉几千块；而把稳定的部分固化在 RPA 里，只在必要节点调用 AI 做动态处理，成本透明，长期运行下来的性价比差异非常明显。
八、实战代码：AI 脚本一键转 RPA 流程
下面这段代码展示了一个典型的混合模式：AI 生成数据获取逻辑，RPA 负责稳定的界面执行和异常兜底，同时演示了"一键转流程"和"API 触发"的完整链路。
import re
from flask import Flask, request, jsonify
app = Flask(name)
========== AI 生成的核心逻辑（纯 Python，无 RPA 依赖）==========
def extract_orders_ai(page_source: str) -> list:
"""
AI 根据页面结构生成的解析逻辑
实际生产中，这段代码由大模型根据页面截图/HTML 自动生成
"""
orders = []
pattern = r'data-order-id="(\d+)".?status="(待发货)".?amount="([\d.]+)"'
matches = re.findall(pattern, page_source, re.DOTALL)
for order_id, status, amount in matches:
orders.append({
"order_id": order_id,
"status": status,
"amount": float(amount)
})
return orders
========== 一键转流程：RPA 引擎自动包装 AI 脚本 ==========
def ai_script_to_rpa_flow(ai_script_func, entry_url: str, fingerprint_id: str = None):
"""
将 AI 生成的脚本一键转为可执行的 RPA 流程
无需手动改写，自动注入浏览器上下文、异常处理、数据本地化
"""
flow = RPAFlow()
# 1. 打开浏览器（支持指纹浏览器模式）
flow.add_step("browser.open", url=entry_url, fingerprint=fingerprint_id)
# 2. 智能等待：基于视觉颜色判断页面是否加载完成
flow.add_step("visual.wait",
color_rgb=(24, 144, 255), # 目标按钮的主色调
region=(100, 200, 300, 400), # 搜索区域
timeout=30)
# 3. 获取页面内容，注入 AI 脚本执行
flow.add_step("browser.get_source", inject_to=ai_script_func)
# 4. 结果写入本地 Excel，数据不出本地
flow.add_step("data.save_local", path="orders.xlsx", format="excel")
# 5. 异常兜底：元素失效时自动修复，最多重试 3 次
flow.add_step("error_handler", heal=True, retry=3, callback="notify_admin")
return flow
========== RPA 执行引擎（伪代码示意）==========
class RPAFlow:
def init(self):
self.steps = []
self.context = {}
def add_step(self, action, **kwargs):
self.steps.append({"action": action, "params": kwargs})
return self
def run(self):
for step in self.steps:
try:
self._execute_step(step)
except ElementBrokenError:
if step["params"].get("heal"):
self._ai_heal_element()
self._retry_step(step)
except Exception as e:
self._notify(f"流程异常: {str(e)}")
raise
return {"status": "success", "data": self.context.get("result")}
def _execute_step(self, step):
action = step["action"]
params = step["params"]
if action == "browser.open":
# 支持指纹浏览器：紫鸟、比特、Hubstudio、AdsPower 等
print(f"打开浏览器: {params['url']}, 指纹: {params.get('fingerprint')}")
elif action == "visual.wait":
# 视觉颜色识别等待，不依赖 DOM 节点
print(f"等待视觉特征: RGB{params['color_rgb']}")
elif action == "browser.get_source":
# 模拟获取页面源码并注入 AI 脚本
mock_source = '<div data-order-id="10086" status="待发货" amount="199.00"></div>'
ai_func = params["inject_to"]
self.context["result"] = ai_func(mock_source)
elif action == "data.save_local":
print(f"数据保存到本地: {params['path']}, 不同步到服务端")
elif action == "error_handler":
print("异常处理策略已注册: heal=True, retry=3")
def _ai_heal_element(self):
"""AI 自动修复失效元素路径"""
print("元素失效，触发 AI 自愈...")
def _retry_step(self, step):
print(f"重试步骤: {step['action']}")
def _notify(self, msg):
print(f"[通知] {msg}")
========== API 触发端点 ==========
@app.route("/run/order-sync", methods=["POST"])
def trigger_flow():
"""
通过 HTTP API 触发 RPA 流程执行
可被 ERP、CRM、IM 机器人等上游系统调用
"""
data = request.get_json() or {}
entry_url = data.get("url", "https://xxx.com/orders")
fingerprint = data.get("fingerprint", "profile_01")
# 一键转流程
flow = ai_script_to_rpa_flow(
ai_script_func=extract_orders_ai,
entry_url=entry_url,
fingerprint_id=fingerprint
)
# 执行并返回结果
result = flow.run()
return jsonify(result)
if name == "main":
# 本地调试运行
print("=== 本地调试模式 ===")
flow = ai_script_to_rpa_flow(
ai_script_func=extract_orders_ai,
entry_url="https://xxx.com/orders"
)
print(flow.run())
# 启动 API 服务（生产环境）
# app.run(host="0.0.0.0", port=5000)
这段代码的核心思想是：AI 负责变化和推理（获取逻辑），RPA 负责稳定和兜底（界面操作、元素自愈、数据本地化）。两者通过清晰的接口分层，互不侵入。ai_script_to_rpa_flow 函数实现了AI 生成脚本一键转流程，无需逐行改写；Flask 端点实现了API 触发；visual.wait 和 _ai_heal_element 分别对应视觉颜色识别和元素自愈。
九、踩坑实录：AI 与 RPA 的能力边界
第一，AI 生成的元素定位不要直接上生产。复杂项目里，页面结构一变就挂。一定要把核心流程放在 RPA 侧，利用元素自愈和智能路径优化来兜底。
第二，桌面软件自动化别硬上纯 AI 方案。AI 操作微信、企业微信、QQ、千牛这类桌面应用极其困难，但 RPA 配合视觉颜色识别能力，不依赖元素节点也能轻松实现稳定操控。
第三，流程执行过程中实时调用 AI 做动态判断，和事前让 AI 写死逻辑，完全是两回事。前者可以根据页面实时状态灵活调整策略，后者一旦遇到边界情况就懵。RPA 流程里要预留动态调用 AI 的节点，而不是每次出问题都重新找 AI 改代码。
第四，授权管理要前置。如果流程需要分发给外部团队使用，提前把授权机制设计好，别等交付了再补。
第五，AI 写的判断逻辑往往不够全面。异常分支、边界条件很容易遗漏。RPA 侧要有充足的容错设计，不能指望 AI 一次性写出完美无缺的代码。
Computer Use 的落地，不是让 AI 取代 RPA，也不是让 RPA 硬蹭 AI 的热点。AI 写代码，RPA 跑代码，这套组合拳的精髓在于"各取所长"：AI 负责快速迭代、复杂推理和代码生成，RPA 负责稳定执行、元素自愈和流程兜底。
对于想要尝试这条路的团队，建议先从一个具体的单点场景切入——定时数据获取、报表自动生成、IM 消息自动处理都可以。把 AI 生成的逻辑嵌入 RPA 流程，打包成 EXE 试运行，观察一周的稳定性和维护成本，再决定是否扩大范围。
AI 负责思考，自动化负责稳定落地。这条路走通了，Computer Use 才算真正从 demo 视频走进了生产环境。
