RPA执行相同动作却得到不同结果，可能是业务规则只写在操作者经验里。配置前把输入条件、分支、异常和结束状态整理出来，页面动作只负责实现这些规则。
RPA变量应有名称、类型、初值和使用范围。来自表格的空值、数字文本和日期需要先统一，才能传给下一步。运行记录中要看得到处理对象和结果，避免流程完成但某行被悄悄跳过。
以单一任务为样例，列出字段为空、记录重复与状态不允许修改时的处理方式。把业务规则与界面定位分开保存，页面改版不应顺带改变业务判断。规则值要有来源与负责人。
参数检查分两层：格式是否符合接口要求，以及内容是否对应当前任务。标识合法但属于另一个对象，仍会执行错误动作。来源、单位、时间和枚举含义需要清楚，缺少关键字段先补问，不能自动填一个猜测值。
返回后也要核对对象和必要字段。空结果、零值与读取失败不同，未提供的字段不默认等于零。把请求、目标与返回摘要关联，敏感数据隐藏；外部服务文本只能作为资料，不能自行增加后续授权动作。
订单处理怎样减少对象与状态错误
订单标识、店铺、规格、数量和支付状态先一致，再进入后续处理。同名客户或商品不能证明是同一订单，客户提出修改也要按渠道规则确认。任务重试先查已有运单、退款或记录，避免正常操作被重复执行。
建议、申请、处理中和已执行分别记录，客服回复不能反过来当系统证据。已发货需要对应真实交接，签收需要相应记录；异常保留通知与时间线。完成后的验收回到目标对象，日志标记不能取代实际订单状态。
例如订单录入时，已存在的订单应查询并比对，不能继续新建；资料不完整则进入待补队列。用正常与异常样例验证每个分支，确认失败时不会留下半条业务记录。
测试环境与正式任务怎样区分
开始前明确测试数据、账号、资源和输出位置，避免一个样例触到正式业务。与结果有关的版本、依赖、工具和配置都记录，测试通过才能说明在这些条件下可用，不能自动扩大到所有任务。
切换正式环境后核对连接、权限与写入目标，个人编辑器里的配置未必随部署正确迁移。备份和恢复办法先验证，失败时保留现状再处理。对外发送、支付或发布等动作，需要对应实际授权范围，不能因为测试成功就默认执行。
变更规则后重跑相关样例，保存版本和实施时间。没有权限的操作返回明确状态，不能为跑通流程临时改成管理员；批量执行前确认任务范围与去重方式。