影刀 RPA 开发规范

让流程更清晰。

让维护更轻松，让能力可复用。把开发规范做成一套能被新人听懂、能被团队复用的工作方法。

支持滚轮、方向键和左侧章节跳转

结构清晰 主流程编排，子流程执行。

命名可读 不点开流程，也知道职责。

能力复用 公共逻辑沉淀成工具。

第一件事：先拆结构

所有指令都写进一个流程，
确实也能运行。

但很快就会失控。

随着分支、循环和异常处理不断增加，流程会越来越难定位、难修改、难维护。

难定位难修改难复用

图片未找到assets/images/ch01-flow-complexity.png请检查素材路径

图片未找到assets/images/ch01-mainflow-overload.png请检查素材路径

错误结构的后果

把所有事情塞进主流程，
会发生什么？

看不懂接手人必须从头读到尾。

找不到失败时很难快速定位模块。

不敢改担心修改会影响其他步骤。

如果一个流程名无法概括内部内容，通常说明它承担了太多职责。

先明确角色

主流程负责编排，
子流程负责执行。

主流程决定先做什么、后做什么，子流程完成一个具体任务。

主流程负责： 控制整体执行顺序调用各功能模块处理整体主分支

子流程负责： 完成一个清晰任务接收输入并返回结果可以被重复调用

主流程像导演，子流程像专业执行者。

图片未找到assets/images/ch01-main-subflow-architecture.png请检查素材路径

拆分标准

一个子流程，只完成一个清晰目标。

判断方法很简单：子流程名称能不能准确概括里面的全部动作？

拆分前

B-处理业务.flow

登录网站下载数据清洗数据写入系统发送通知

“处理业务”到底处理了什么？

拆分后 B-登录网站.flow C-下载订单数据.flow D-清洗订单数据.flow E-写入业务系统.flow F-发送运行通知.flow

职责更清晰排错更直接复用更容易

文件夹和层级

让目录先讲清业务顺序。

不打开流程，也能先看懂项目骨架。

A / B / C / D一级业务阶段和执行顺序

A1 / A2 / B1 / B2某个阶段内部的具体步骤

Z被多个流程复用的通用工具

一级流程表达业务阶段，下级流程表达阶段内部步骤。

主流程.flow

0-读取配置.flow

A-初始化.flowA1-检查运行环境.flowA2-创建临时目录.flow

B-登录系统.flow

C-读取数据.flowC1-下载订单.flowC2-读取Excel.flow

D-业务处理.flowD1-录入订单.flowD2-回写结果.flow

Z1-关闭弹窗.flowZ2-日期转换.flow

回到影刀界面

在影刀里，结构就体现在流程文件树中。

不打开任何流程，只看文件树，也应该大致知道项目如何运行。

影刀项目流程

◆主流程.flow入口

▣0-配置.flow

▾A-初始化配置

◇A-初始化配置.flow

▾B-登录系统

◇B-登录系统.flow

▾C-读取数据

◇C-读取数据.flow

◇C1-下载订单.flow

◇C2-读取Excel.flow

▾D-业务处理

◇D1-加载数据.flow

◇D2-获取数据.flow

◇D3-写入数据.flow

◇D4-保存结果.flow

▾Z-通用工具

◇Z1-验证码处理.flow

◇Z2-弹窗处理.flow

①主流程入口控制整体执行顺序

②一级业务阶段A/B/C/D 对应业务模块

③阶段内子流程D1/D2 表示内部步骤

④Z-通用工具沉淀复用公共能力

清晰项目结构 = 主流程编排 + 子流程单一职责 + 文件夹表达层级 + 公共能力集中复用

第二件事：先定名字

流程、变量、元素、应用，
都要一眼看懂。

不要让接手人猜。

命名不是美观问题，而是排错、交接、复用和长期维护的成本问题。

看得懂找得到敢修改

图片未找到assets/images/naming-clarity.png请检查素材路径

坏命名的真实成本

一个叫“流程1”的流程，
出了问题以后会怎样？

坏命名不一定立刻报错，但会把成本推迟到排错、交接和修改时。

排错 “流程1”执行失败 不知道失败的是登录、下载还是回写。

交接

流程1.flow
流程2.flow
新建流程.flow

必须逐个打开才能知道用途。

修改

tmp1
按钮1
variable

不知道数据来源，也不敢直接修改。

坏命名不会阻止流程运行，但会持续增加理解和维护成本。

四类命名对象

先分清对象，
再决定怎么命名。

流程、变量、元素、应用，关注的信息并不相同。

流程

关注点：顺序与职责

前缀 + 序号 - 语义 A-登录系统.flow

strlist

变量

关注点：业务含义与数据类型

业务含义 + 类型后缀 订单编号_str

查询按钮

元素

关注点：页面位置与控件用途

页面_区域_元素 订单页_筛选区域_查询按钮

应用

关注点：业务归属与版本

部门-应用概述_版本 财务-费用报销流程_v2

逐项变清楚

从“只有我懂”，
变成“团队一眼看懂”。

流程 流程1.flow A-登录系统.flow

变量 tmp1 订单编号_str

元素 按钮1 登录页_登录按钮

应用 新建应用 财务-费用报销流程_v2

从“需要解释”，变成“不打开也能理解”。

命名公式推导

好命名 = 对象类型 + 业务含义 + 必要后缀 / 层级编号

对象类型流程业务含义登录系统层级编号A- A-登录系统.flow

订单编号_str 登录页_账号输入框 财务-费用报销流程_v2

互动判断

下面哪个名字，
交接给同事时不需要解释？

点击你认为更清晰的名称。

0 / 4

流程

变量

元素

应用

能不能不打开、不运行、不猜测，也知道它是什么？

元素管理

让流程今天能找到，
明天也能找到。

网页文字、列表顺序和页面结构都可能变化，稳定元素需要经得住变化。

元素不是一次点击的位置，而是机器人长期识别目标的规则。

图片未找到assets/images/ch03-element-stability.png请检查素材路径

先分清

坐标会变，
元素规则才稳定。

坐标记住的是屏幕位置，元素记住的是目标对象和定位条件。

坐标定位

X 843 / Y 421 查询

页面一变，就可能点偏

窗口大小、分辨率、弹窗和列表位置变化，都会让坐标失效。

元素定位

页面：订单页区域：筛选区控件：查询按钮 唯一匹配 1 个

条件稳定，目标就能重找

元素通过节点、属性、文本和层级规则识别目标，而不是只记住位置。

元素=目标对象+定位条件+唯一校验

捕获后别急着用

先检查元素，
再交给流程执行。

基础主线只做四件事：重命名、看条件、去动态、验唯一。

01捕获后重命名别留下“按钮1”

02检查定位条件看节点、属性、匹配值

03移除动态条件订单号、数量、时间慎用

04校验唯一性目标最好只找到 1 个

图片未找到assets/images/ch03-element-name-and-match.png请检查素材路径

命名与匹配

捕获后及时修改元素名称，并确认当前找到 1 个元素。

节点路径

先选对节点路径，
再选择定位属性。

节点告诉机器人“目标藏在哪一层”，属性告诉机器人“这一层里具体是哪一个”。

页面容器 <div>区域、卡片、弹窗 <span>行内文本、状态 <p>段落、提示说明

交互控件 <input>输入框、日期框 <button>查询、提交、保存 <a>链接、菜单、下载入口

列表与表格 <li>菜单项、列表项 <table>表格整体 <tr>表格行 <td>单元格

独立页面区域 <iframe>嵌入的独立网页区域

订单页面

筛选区域

日期输入框

div 订单页面

div 筛选区域

input 日期输入框

button 查询按钮

节点链正确

目标在 iframe 内时，
iframe 节点必须保留。

取消 iframe 节点后，机器人可能只在外层页面查找，最终导致元素未找到。

外层页面div 业务区域iframediv 内部页面button 查询按钮

iframe 不稳定时： 不要直接取消 iframe 先找稳定父级区域用父级 + iframe 类型 + 相对层级定位再校验元素数量

定位路径=父级结构+目标节点

属性判断

属性不是越多越好，
而是要稳定、可解释、能唯一定位。

判断属性是否适合长期使用，不能只看属性名称，更要看属性值的规律。

优先保留：语义明确、长期不变需要观察：需组合父级或其他属性不建议单独用：随机、过长、随数据变化

普通节点和属性不足时，再考虑：锚点XPath重新捕获捕获相似元素AI 辅助定位

稳定定位=正确节点链+稳定属性+唯一结果

组织方式

元素也要像流程一样，
按页面和场景归档。

元素越多，越不能靠记忆找；名称和分组要先替接手人解释清楚。

散落状态 按钮1输入框2查询确定文本3

按页面归档

登录页账号输入框 / 登录按钮

订单页筛选区域_查询按钮

弹窗确认按钮 / 关闭按钮

好元素名=页面+区域+控件用途

云元素库

不是所有元素都上云，
高频稳定才沉淀。

云元素组适合跨应用、跨流程复用的公共元素，不适合临时页面里的偶发控件。

适合上传云元素组 登录页按钮公共弹窗确认统一查询入口多应用复用页面

高频使用？

稳定不变？

跨应用复用？

满足再上云

不建议上传 临时活动页面只在单流程使用频繁变动控件尚未校验唯一

本地元素组 → 上传到云 → 企业元素库统一管理 → 加入其他应用复用

官方截图教程

云元素组如何上传、
管理和复用？

按真实影刀界面理解：本地元素组上传到云，再加入其他应用使用。

01 上传入口

从本地元素发起上传

在本地元素组菜单中选择“上传到云”。

交付前自测

能判断元素是否可靠，
才算掌握本章。

下面四题不是背概念，而是判断真实开发里该怎么处理。

0 / 4

元素名：按钮1

定位条件包含：订单号 202607130001

校验结果：找到 4 个元素

三个应用重复捕获同一个稳定登录按钮

元素可靠 = 名称清楚 + 条件稳定 + 校验唯一 + 复用有归属。

变量参数

流程拆开后，
数据不会自动流过去。

主流程和子流程一旦分开，就必须明确哪些数据内部使用，哪些数据需要显式传递。

最终问题：调用子流程时，数据到底怎么跨过去？

调用流程，不等于数据自动传递。

主流程.flow 文件保存地址_path 当前日期_str 下载文件标题_str

流程边界 未绑定参数

B-下载文件.flow 需要：下载路径_path 需要：日期_str 需要：下载文件标题_str 缺少输入数据

下载到哪里？下载哪一天？文件叫什么？

变量的作用域

变量的“全局”和“局部”，
说的是谁能看见这份数据。

先理解可见范围，再决定数据应该放在哪里。

应用级共享配置

主流程.flow

这些过程数据不会自动进入子流程。

本流程可见

B-下载文件.flow

主流程不能直接读取子流程内部变量。

本流程可见

作用域=变量可以被哪些流程看见和使用

全局变量还是局部变量

不是多个流程会用，
就一定要放全局。

先判断它是稳定共享配置，还是当前流程的过程数据。

适合全局变量

稳定 · 共享 · 配置类 · 不随单次业务频繁变化

文件保存地址_path运行环境_str系统主页地址_url公共配置开关_bool

适合局部变量

过程性 · 临时性 · 只服务当前流程 · 随流程结束而结束

当前日期_str当前订单号_str当前循环行_dict当前重试次数_num

点一下，判断它该放哪里： 跨流程需要交接的过程数据，不要为了方便全部塞进全局变量。

为什么需要流程参数

主流程的局部变量，
子流程看不见怎么办？

流程参数负责把数据显式地交给另一个流程。

主流程.flow 当前日期_str = 2026-07-14

当前日期_str 流程边界 输入参数接口

B-下载文件.flow 需要：日期_str 日期_str = 2026-07-14 可以执行

主流程局部变量→参数绑定→子流程输入参数

输入参数与输出参数

输入参数负责接收，
输出参数负责交回。

输入参数 下载路径_path 日期_str 下载文件标题_str

调用方必须传给子流程的数据。

B-下载文件.flow

执行下载

当前重试次数_num 临时文件名_str

输出参数 实际文件路径_path 下载状态_bool

子流程执行完成后返回给调用方的数据。

输入回答“你需要什么”，输出回答“你交回来什么”

参数声明与内部使用

子流程先声明接口，
内部指令再使用参数。

参数必须先定义方向、类型和用途，进入子流程后才能被具体指令使用。

01 声明输入参数

声明输入参数

B-下载文件.flow 先声明自己需要：下载路径_path、日期_str、下载文件标题_str。

赋值和传参的区别

设置变量是赋值，
调用流程是传参。

它们都涉及数据，但改变的是不同关系。

赋值

glv['文件保存地址_path']↓本次下载目录_path

赋值 = 让一个变量获得新的值。

传参

B-下载文件.flow

本次下载目录_path下载路径_path

当前日期_str日期_str

下载文件标题_str下载文件标题_str

绑定完成

传参 = 让数据跨越流程边界。

参数绑定不要求左右名称完全相同，关键是业务含义和数据类型正确对应。

完整数据闭环

数据传进去，
结果还要交回来。

输入和输出都明确，流程之间才形成完整、可追踪的数据链。

互动判断

这份数据，
应该放在哪里？

根据共享范围、流程边界和数据方向做判断。

0 / 6

全部流程共用的文件保存地址

当前循环中的订单编号

主流程传给下载子流程的日期

下载子流程返回的实际文件路径

下载子流程内部的当前重试次数

多个流程共同使用的运行环境配置

共享配置 → 全局变量内部过程 → 局部变量跨流程传入 → 输入参数处理结果返回 → 输出参数 全局放配置，局部放过程；输入负责接收，输出负责返回。

异常处理

可控判断，
不可控捕获。

异常处理不是把流程全部包起来，而是让不同问题进入正确的处理路径。

先判断问题类型，
再选择处理方式。

运行现场批量处理订单

01

订单列表为空可预期业务状态

IF 判断

02

页面暂未加载完成短暂可恢复问题

Wait / Retry

03

点击时页面刷新运行时异常

Try-Catch

Finally统一收尾

先分清问题

业务结果、短暂问题和运行异常，
不是一回事。

IF

正常业务分支

订单列表为空 · 订单已处理 · 没有待办

IF 判断 → 记录结果 → 正常出口 无数据通常是业务结果，不一定是异常。

↻

短暂可恢复问题

页面加载较慢 · 接口偶发超时 · 文件仍在下载

等待 → 有限重试 → 超限后捕获 再次执行可能成功，才值得重试。

!

运行时异常

页面突然刷新 · 文件被占用 · 浏览器进程退出

Try-Catch → 留下现场 → 决定下一步 致命异常不能被悄悄吞掉。

正常分支不要包装成异常短暂问题不要无限重试运行异常不要悄悄吞掉

IF 还是 Try-Catch

能在执行前判断，
就不要等它报错。

这个情况能提前检查吗？

能元素可见 / 文件存在 / 数据长度使用 IF

不能执行具体操作时瞬间失败使用 Try-Catch

IF：订单为空、是否登录、金额超阈值捕获：页面刷新、网络中断、文件占用

可预期状态→ 判断运行时失败→ 捕获

执行关系

Try 负责尝试，
Catch 负责处理，
Finally 负责收尾。

TryCatchFinally结束

Try 成功后跳过 Catch，但仍然进入 Finally。

Try 放风险操作+Catch 放异常处理+Finally 放必做收尾

单条隔离

循环处理时，
一条失败不应拖垮整批。

Try-Catch 保护当前订单，而不是包住整个订单列表。

ForEach 订单列表_list 当前订单_dict

Try：处理当前订单

Catch：记录失败原因 → 继续下一条

错误边界Try 包住整个 ForEach第 3 条失败后，第 4 条及以后全部停止。

主流程继续遍历，单条 Catch 隔离当前失败。

每一条数据独立保护每一条数据在循环内部由独立的 Try-Catch 保护。

Catch 之后

Catch 不是忽略错误，
而是记录异常并做出决定。

异常处理记录单批量处理订单 · DD20260714001

失败流程: D1-处理单条订单.flow
失败步骤: 点击提交按钮
异常信息: 元素未找到
发生时间: 2026-07-14 20:31:33
运行日志: 已记录异常；截图需另加指令
处理决策: 当前订单失败，继续下一条

业务上下文异常信息运行日志后续决策

哪里错了？哪条数据？什么证据？接下来怎么办？

有限重试

只有再次执行可能成功，
才值得重试。

适合重试

页面未加载 · 接口偶发超时 · 文件仍在下载 · 网络短暂波动

原因可能随时间自动消失

等待开始有限重试演示点击按钮，观察三次尝试的因果过程

1页面未加载失败，等待 2 秒

2页面仍在加载失败，再等待 2 秒

3页面已经就绪执行成功，停止重试

不适合重试

密码错误 · 字段缺失 · 定位失效 · 路径错误 · 权限不足

重复执行不会改变原因

最多 3 次每次等待 2 秒记录重试次数超限进入 Catch

先问：错误原因会随着时间自动消失吗？

统一收尾

无论成功还是失败，
必须执行的动作放在 Finally。

Try 成功Catch 已处理异常重新抛出Finally结束 / 上层处理

执行前：资源仍被占用

浏览器：已打开
Excel：已占用
临时文件：已创建
数据库：已连接
日志：未保存

点击后逐项回收资源

执行后：资源已回收

浏览器：已关闭
Excel：已释放
临时文件：已清理
数据库：已断开
日志：已保存

适合关闭网页、释放 Excel、断开连接、保存日志不适合成功通知、错误截图、正常业务处理

Finally 不是成功或失败分支，它是必须执行的资源回收区。

快速判断

这个情况，应该判断、重试还是捕获？

0 / 8

订单列表为空

登录按钮不可见，已登录

页面较慢，按钮暂未出现

点击瞬间页面刷新

当前订单缺少必填字段

浏览器进程已经崩溃

接口偶发超时

成功失败都要释放 Excel

稳定异常处理= 提前判断 + 小范围捕获 + 有限重试 + 完整留证 + 统一收尾

日志排错

通过增加日志，
增强对于流程的把控。

大部分技术报错，影刀已经记录了失败流程、失败指令和错误信息。

系统日志定位技术问题业务日志只补充系统不知道的业务上下文。

图片未找到assets/images/ch07-system-run-log.png

运行失败→主流程→第 2 行→未找到登录按钮

第一步不是猜原因，而是先确定失败位置。

定位失败指令

排错的第一步，
是锁定哪条指令失败。

先从应用定位到流程，再从流程定位到具体指令。

应用网页批量录入

流程主流程

行号第 2 行

失败指令点击元素(web)

目标元素登录按钮

图片未找到assets/images/ch07-failed-instruction-location.png

无效“这个网页流程报错了”有效“主流程第 2 行点击元素指令未找到登录按钮”

先准确描述失败位置，再分析失败原因。

信息缺口

系统日志知道程序怎么失败，
但不一定知道业务发生了什么。

系统日志已经知道

流程: 主流程
指令: 点击元素(web)
元素: 登录按钮
错误: 未找到元素
时间: 2026-07-16 09:47:24

信息缺口同一种技术报错，可能对应不同业务原因

系统日志不一定知道

当前处理哪条数据、处于第几次循环？
当前页面是登录页还是业务页？
为什么此时需要点击登录按钮？
失败后继续、重试还是终止？
整批数据最终成功、失败、跳过多少条？

“未找到登录按钮”可能因为：页面未加载完成已经登录进入其他模块弹窗遮挡定位规则失效

必要的业务日志

系统日志无法表达的业务状态，
才值得主动记录。

不要重复技术错误，只补充业务标识、阶段、判断原因和处理结果。

01 业务标识行号、订单号、工号、文件名

02 业务阶段数据检查、网页录入、提交结果

03 主动判断已存在跳过、数据为空结束

04 结果汇总成功 80、失败 5、跳过 15

图片未找到assets/images/ch07-print.png

日志定位失败位置，
断点和变量帮助寻找根因。

让流程停在问题发生前，再检查当时的数据和页面状态。

业务数据已脱敏

图片未找到assets/images/ch07-breakpoint-debug.png

运行回放与证据

日志定位位置，
回放还原页面过程。

运行回放需要提前开启，用于观察错误前页面经历了什么变化。

系统日志哪条指令、什么错误、何时失败

调试变量当时的数据、对象、循环和分支状态

运行回放页面跳转、弹窗遮挡和实际操作过程

业务日志必要的业务标识、阶段与决策

图片未找到assets/images/ch07-run-playback.png

这是运行回放的设置入口，不是播放器界面。

系统日志锁定位置+变量确认状态+回放还原页面+业务日志补上下文=完整排错证据

排错判断练习

先读证据，再决定下一步。

0 / 7

01 / 07

影刀提示“未找到登录按钮”，第一步应该做什么？

02 / 07

系统日志已经记录技术错误，什么内容值得额外打印？

03 / 07

已经知道失败指令，但不知道变量为何错误，下一步用什么？

04 / 07

怀疑登录页被弹窗遮挡，哪类证据最直接？

05 / 07

批量任务结束时，最有价值的业务日志是？

06 / 07

修复后如何证明问题真的解决？

07 / 07

哪组信息构成完整排错证据？

完整排错信息= 影刀系统日志 + 必要业务上下文 + 运行现场

交付门禁

交付不是
“跑通一次”

真正可交付的流程，要能验证结果、重复运行、定位问题，并由其他人接手。

开发完成→测试运行成功 ✓

结果真的正确吗？

批量运行稳定吗？

重复运行安全吗？

换一台电脑还能运行吗？

其他人可以独立接手吗？

开发完成

结果验证

稳定性验证

环境确认

资料交接

正式交付

单次成功只能证明当前场景能运行，不能证明应用已经可以交付。

四项交付标准

交付前，
至少确认四件事。

不是检查代码看起来是否整齐，而是确认应用能否在真实环境中持续工作。

结果正确

输入与输出可以核对
成功、失败、跳过都有结果
关键字段符合业务规则

运行稳定

正常、空和异常数据均测试
单条失败不拖垮整批
浏览器、Excel 等资源正常释放

环境可用

路径、账号和运行参数明确
运行机器具备所需权限
正式环境实际测试通过

资料完整

输入模板和字段规则清楚
输出位置和结果字段清楚
接手人知道如何运行与查看结果

可交付=结果正确+运行稳定+环境可用+资料完整

必要测试场景

只测试正常数据，
等于没有完成测试。

交付前至少覆盖四类场景。

测试不是证明流程能成功，而是确认不同情况都能按预期结束。只测一条标准数据，无法证明批量、空数据和异常数据也安全。

结果核对与重复运行

运行成功，
不代表业务结果正确。

还要核对数量关系，并确认第二次运行不会制造重复结果。

业务结果核对

100输入总数

80成功

5失败

15跳过

100输出记录

100 = 80 + 5 + 15　✓ 数量可核对

关键字段正确文件真实生成系统真实提交失败原因明确跳过有业务依据

重复运行安全

第一次：成功 95失败 5

再次处理 95 条已成功数据

重复提交、重复通知、重复生成文件

5 条失败数据仍混在整批任务中

这种“重复运行仍不制造额外错误结果”的能力，技术上通常称为“幂等”。

重跑安全=识别已完成+只处理未完成+避免重复副作用

让流程更清晰。

所有指令都写进一个流程，确实也能运行。

把所有事情塞进主流程，会发生什么？

主流程负责编排，子流程负责执行。

一个子流程，只完成一个清晰目标。

让目录先讲清业务顺序。

在影刀里，结构就体现在流程文件树中。

流程、变量、元素、应用，都要一眼看懂。

一个叫“流程1”的流程，出了问题以后会怎样？

先分清对象，再决定怎么命名。

流程

变量

元素

应用

从“只有我懂”，变成“团队一眼看懂”。

下面哪个名字，交接给同事时不需要解释？

让流程今天能找到，明天也能找到。

坐标会变，元素规则才稳定。

先检查元素，再交给流程执行。

先选对节点路径，再选择定位属性。

目标在 iframe 内时，iframe 节点必须保留。

属性不是越多越好，而是要稳定、可解释、能唯一定位。

元素也要像流程一样，按页面和场景归档。

不是所有元素都上云，高频稳定才沉淀。

云元素组如何上传、管理和复用？

从本地元素发起上传

能判断元素是否可靠，才算掌握本章。

流程拆开后，数据不会自动流过去。

变量的“全局”和“局部”，说的是谁能看见这份数据。

不是多个流程会用，就一定要放全局。

适合全局变量

适合局部变量

主流程的局部变量，子流程看不见怎么办？

输入参数负责接收，输出参数负责交回。

B-下载文件.flow

子流程先声明接口，内部指令再使用参数。

声明输入参数

设置变量是赋值，调用流程是传参。

赋值

传参

数据传进去，结果还要交回来。

这份数据，应该放在哪里？

可控判断，不可控捕获。

正常业务分支

短暂可恢复问题

运行时异常

能在执行前判断，就不要等它报错。

Try 负责尝试，Catch 负责处理，Finally 负责收尾。

循环处理时，一条失败不应拖垮整批。

适合重试

不适合重试

执行前：资源仍被占用

执行后：资源已回收

通过增加日志，增强对于流程的把控。

排错的第一步，是锁定哪条指令失败。

系统日志已经知道

系统日志不一定知道

推荐格式

日志定位位置，回放还原页面过程。

影刀提示“未找到登录按钮”，第一步应该做什么？

系统日志已经记录技术错误，什么内容值得额外打印？

已经知道失败指令，但不知道变量为何错误，下一步用什么？

怀疑登录页被弹窗遮挡，哪类证据最直接？

批量任务结束时，最有价值的业务日志是？

修复后如何证明问题真的解决？

哪组信息构成完整排错证据？

结果正确

运行稳定

环境可用

资料完整

正常数据

空数据

异常数据

批量数据

业务结果核对

重复运行安全

所有指令都写进一个流程，
确实也能运行。

把所有事情塞进主流程，
会发生什么？

主流程负责编排，
子流程负责执行。

流程、变量、元素、应用，
都要一眼看懂。

一个叫“流程1”的流程，
出了问题以后会怎样？

先分清对象，
再决定怎么命名。

从“只有我懂”，
变成“团队一眼看懂”。

下面哪个名字，
交接给同事时不需要解释？

让流程今天能找到，
明天也能找到。

坐标会变，
元素规则才稳定。

先检查元素，
再交给流程执行。

先选对节点路径，
再选择定位属性。

目标在 iframe 内时，
iframe 节点必须保留。

属性不是越多越好，
而是要稳定、可解释、能唯一定位。

元素也要像流程一样，
按页面和场景归档。

不是所有元素都上云，
高频稳定才沉淀。

云元素组如何上传、
管理和复用？

能判断元素是否可靠，
才算掌握本章。

流程拆开后，
数据不会自动流过去。

变量的“全局”和“局部”，
说的是谁能看见这份数据。

不是多个流程会用，
就一定要放全局。

主流程的局部变量，
子流程看不见怎么办？

输入参数负责接收，
输出参数负责交回。

子流程先声明接口，
内部指令再使用参数。

设置变量是赋值，
调用流程是传参。

数据传进去，
结果还要交回来。

这份数据，
应该放在哪里？

可控判断，
不可控捕获。

能在执行前判断，
就不要等它报错。

Try 负责尝试，
Catch 负责处理，
Finally 负责收尾。

循环处理时，
一条失败不应拖垮整批。

通过增加日志，
增强对于流程的把控。

排错的第一步，
是锁定哪条指令失败。

日志定位位置，
回放还原页面过程。