4、RPA基础组件：选择器、变量、参数、控制流

好，咱们进入正题。这一章讲的是RPA的「四肢」和「大脑」。你想想看，一个机器人要干活，总得知道「抓哪里」、「存什么」、「怎么走」吧？选择器、变量、参数、控制流，就是干这个的。

我刚开始带团队做RPA项目时，发现很多新人把精力全花在录流程上，结果一换环境就崩。为什么？因为没搞懂这几个基础组件。说白了，它们是RPA的骨架，骨架歪了，皮肉再好看也没用。

4.1 选择器：告诉机器人「抓哪里」

选择器，就是RPA的眼睛。它帮机器人定位界面上的元素——按钮、输入框、表格、下拉菜单，全靠它。

我个人习惯把选择器分成两类：静态选择器和动态选择器。

4.1.1 静态选择器

这种最简单。元素有固定的ID、Name、Class，直接写死就行。比如：

<html>
  <button id="submitBtn" class="btn-primary">提交</button>
</html>

选择器可以写成：

id='submitBtn'

或者：

class='btn-primary'

嗯，这里要注意：优先用ID。ID是唯一的，最稳定。Class可能多个元素共用，容易抓错。

4.1.2 动态选择器

现实世界没这么美好。很多系统的ID是动态生成的，比如：

id='btn_20240515_001'

第二天可能就变成：

id='btn_20240516_002'

怎么办？用通配符和正则表达式。我在项目中遇到过这种情况：一个ERP系统的订单列表，每行的「编辑」按钮ID都带时间戳。我当时的做法是：

id='btn_*'

或者更精确一点：

id~='btn_'

这表示「包含btn_即可」。你想想看，如果不这么处理，每天都要改选择器，那还叫自动化吗？

避坑指南：我曾经因为选择器写得太宽泛，把整个页面的按钮全点了一遍。后来养成了习惯——写完选择器先「高亮验证」，确认只选中了目标元素，再跑流程。

4.2 变量：告诉机器人「存什么」

变量就是RPA的便签纸。抓到的数据、计算的结果、判断的条件，都得存起来。

我建议你记住一个原则：变量名要见名知意。别用a、b、c这种，三个月后你自己都看不懂。

变量名 含义 示例值
customerName 客户姓名 张三
orderAmount 订单金额 1580.00
isApproved 是否审批通过 True
emailList 邮箱列表 ["a@b.com", "c@d.com"]

变量类型也很重要。字符串、数字、布尔值、数组、字典……用错了会报错。我记得有一次，同事把数字存成了字符串，结果做加法时变成了拼接——「100」+「200」=「100200」，而不是300。这种坑，踩过一次就记住了。

小技巧：在RPA工具里，变量作用域要尽量小。能用局部变量就别用全局变量。不然变量多了，调试时满屏都是，找都找不到。

4.3 参数：告诉机器人「怎么传」

参数和变量很像，但用途不同。参数是用来跨流程传递数据的。

你想想看，一个完整的RPA项目，不可能只有一个流程。比如：

  • 流程A：从Excel读取客户名单
  • 流程B：登录CRM系统查询客户信息
  • 流程C：把结果写回Excel

这三个流程之间怎么传数据？靠参数。

我个人习惯把参数分成三类：

  • 输入参数：调用时传入的数据。比如客户ID、日期范围。
  • 输出参数：流程执行完返回的数据。比如查询结果、状态码。
  • 输入输出参数：既能传进去，又能带出来。比如一个数据集合，进去时是空的，出来时填满了。

举个例子：

// 流程：查询客户信息
// 输入参数：customerId (String)
// 输出参数：customerInfo (Dictionary)

// 伪代码
Function QueryCustomer(customerId):
    OpenCRM()
    SearchByID(customerId)
    info = GetCustomerInfo()
    Return info

嗯，这里要注意：参数命名要统一规范。我见过一个项目，有的用驼峰（customerId），有的用下划线（customer_id），有的用拼音（kehuID）。维护起来简直灾难。

4.4 控制流：告诉机器人「怎么走」

控制流是RPA的大脑。它决定了流程的执行顺序。RPA里常见的控制流有三种：Sequence、Flowchart、State Machine。

4.4.1 Sequence（序列）

最简单，也最常用。从上到下，一步一步执行。适合线性流程，比如：

  1. 打开Excel
  2. 读取数据
  3. 登录系统
  4. 填写表单
  5. 保存截图

我建议新手先从Sequence入手。它直观、好调试。但别滥用——如果流程有分支、有循环，Sequence会变得又长又乱。

4.4.2 Flowchart（流程图）

Flowchart用图形化的方式展示流程。有判断、有分支、有循环。适合复杂逻辑。

举个例子：

开始 → 读取订单
       ↓
   判断金额 > 1000？
      /        \
    是          否
    ↓           ↓
 高级审批     自动通过
    ↓           ↓
   结束 ←——————┘

我在项目中遇到过这种情况：一个客户审批流程，有7个判断条件、3个并行分支。用Sequence写出来200多行，调试时眼睛都看花了。后来改成Flowchart，一目了然。

核心原则：流程逻辑简单用Sequence，复杂用Flowchart。别为了炫技而用Flowchart，也别为了省事硬塞进Sequence。

4.4.3 State Machine（状态机）

这个稍微高级一点。State Machine适合状态变化频繁的场景。比如：

  • 订单状态：待支付 → 已支付 → 已发货 → 已签收 → 已完成
  • 审批状态：待审批 → 审批中 → 已通过 / 已驳回

State Machine的核心是：定义状态、定义状态之间的转换条件。机器人根据当前状态和触发条件，自动跳转到下一个状态。

我记得有一次做CRM客户跟进自动化。客户状态有「新客户」、「跟进中」、「意向客户」、「已成交」、「已流失」。每个状态之间的转换条件都不一样。用Sequence写？累死。用Flowchart？画出来像蜘蛛网。最后用了State Machine，清爽多了。

避坑指南：我曾经在一个项目里滥用State Machine，把简单的登录流程也做成了状态机。结果状态图画了十几个节点，调试时自己都绕晕了。后来学乖了——只有状态超过5个、转换条件超过10条时，才考虑用State Machine。

4.5 四个组件怎么配合？

好，咱们把四个组件串起来，看看它们怎么一起工作。

假设我们要做一个「自动录入客户信息」的流程：

  1. 选择器定位到CRM系统的「客户名称」输入框
  2. 变量customerName存着从Excel读到的客户名
  3. 参数把customerName从主流程传到子流程
  4. 控制流判断：如果客户名不为空，就填入；如果为空，就跳过并记录日志

你想想看，这四个组件缺一个，流程就跑不起来。选择器抓不到元素，变量没存数据，参数传不过去，控制流不知道怎么走——任何一个环节出问题，自动化就崩了。

我的习惯：写流程之前，先在纸上画一遍。把选择器要抓什么、变量要存什么、参数要传什么、控制流怎么走，全画出来。画清楚了再动手写代码。这样能省一半的调试时间。

好了，这一章就到这里。下一章咱们聊聊「异常处理」——机器人也会犯错，关键是怎么让它犯错后还能自己爬起来。

← 上一章 📖 返回目录 下一章 →