1. UI操作容易受到各种意外的干扰，因此应该缩短UI操作阶段的总体时间。而为了缩短UI操作阶段的总体时间，应该将UI操作尽量放在一起，将后台的各种操作尽量放在UI操作的前后。例如，现在有一个Assign和两个Click需要执行，那么比较推荐的设计是Assign->Click->Click或者Click->Click->Assign，而不是Click->Assign->Click。集中的UI操作也会给人一种“机器人非常高效”的观感，留下较良好的印象。
2. 为了确保“增加一倍的投入就必须相应提高一倍的效率”，流程的总体设计要尽量将问题转化为事务式（Transactional）处理的模式。这是什么意思呢？假设现在有一份Excel表格记录了宾客列表，机器人要读取这份列表，为每位宾客生成一份Word请柬，然后以邮件形式发送出去。有一种流程设计思路是这样的，机器人读取宾客列表ABC后，为A生成请柬->为B生成请柬->为C生成请柬->向A发送邮件->向B发送邮件->向C发送邮件。这种流程设计模式虽然逻辑上没有错，但是多机器人共同协作时分割工作负载相对比较困难，很难确保“增加N倍数量的机器人可以以相应提高N倍的处理能力”。因此，应该尽可能的将流程设计为，机器人读取宾客列表ABC后，为A生成请柬->向A发送邮件->为B生成请柬->向B发送邮件->为C生成请柬->向C发送邮件。可以看到在这个例子中，一个事务包含“生成一个请柬”和“相应地发送一封邮件”两个操作。只有事务中的操作全部成功，才可以判定事务成功。否则事务中的任何一个操作失败，即认定事务失败。事务失败可以中止运行，也可以跳过失败的事务，继续运行下一个事务。当增加机器人数量时，只需通过简单地分配事务，即可达到充分利用机器人效能的目的。
3. 凡是需要人工输入的环节，就一定会出错，因此绝对不能信任人工输入的数据。那么对于人工输入的问题，有几种办法可以提高稳定性。
a. 对人工输入进行严格约束和校验，拒绝不符合要求的数据。（不推荐，但有时候不得不这么干）
b. 设计时加入一定的弹性以实现容错的能力。
c. 减少人工输入的环节，减少人工输入的数据量。
d. 设法尽可能地为人工输入进行辅助，比如弹出相关提示，给出格式示例等等。
4. 当需要处理文件关系时，有几种办法可以在文件之间体现关联：
a. 用某种命名规则来确保文件关联。比如说，有一个Excel文件为叫小明_总成绩.xlsx，而另一个Excel文件为小明_语文成绩.xlsx，这里文件的命名规则是“学生姓名_科目成绩.xlsx”，那么可以认为小明_总成绩.xlsx和小明_语言成绩.xlsx是相关的文件。
b. 建立一个表格用于存储文件关系。这样文件可以通过这张表来查找，不需要特别指定命名规则。比如
5. UiPath Studio项目目录里的文件在每次发布到UiPath Robot时都会相应地新建，因此需要持久化存储的数据（比如配置文件）不应该存储在UiPath Studio项目目录里。建议用Get Environment Folder(UiPath.Core.Activities.GetEnvironmentFolder)存储在某个系统自带的文件夹下（推荐保存到MyDocuments）。
6. 机器人往往需要能够自动登录各种系统，而各种系统往往需要凭据（用户名+密码）才能登录。可以将登录凭据保存在Windows自带的凭据管理器，然后用Get Secure Credential(UiPath.Credentials.Activities.GetSecureCredential)去读取。需要输入密码时不要用Type Into，必须用Type Secure Text。采用Get Secure Credential + Type Secure Text的组合，机器人可以做到全程不接触密码明文，相对安全。
7. 使用Get Text或者Get Attribute从网页上获取的原始内容应该用Log Message保存到日志里以便于查错。
8. 在Excel中填入URL会被自动转化为超链接，但是如果UiPath需要读取这个URL，那么需要移除这个超链接，否则会报错。
9. 注意生产环境与开发、测试环境的差异，容易导致意想不到的异常。也因此，大体上，开发流程所需的时间≈调整稳定性所需的时间≈迁移到新环境测试调整所需的时间。任何环境因素的变化都需要重新测试以确保稳定性。
10. 加入源代码管理的时候，UiPath Studio里项目目录.screenshots下的内容也必须全部加入源码管理。
11. 每次运行都需要保存一个配置文件的副本，以备查错。
12. 如果需要建立自定义日志，流程运行的最初步骤将已存在的"C:\Users\你的用户名\AppData\Local\UiPath\Logs\日期_Execution.log"文件改掉名字，然后在运行中用Log Message记日志。UiPath会自动创建新的日志文件，然后在运行的最后将这个日志文件复制出来即可。通过这种方式可以简化自定义日志的工作，而且必要时可以改变日志级别以获取更多信息用于查错。
13. 流程较长时，可以分割为多个阶段来开发，每个阶段流程用一个.xaml文件来处理。分割的原则大体上是，给定机器人一个文件A，机器人经过阶段性的UI或者后台处理，一定可以产生文件B。那么只需要将A的完整路径作为这个.xaml文件的输入参数，而将B的完整路径作为输出参数，即可很方便地开发调试这个流程。当有多人一起协作开发同一个流程时，只要这样分割为多个小流程，并且详细约定好中间文件的各项内容，就可以同时进行。这种方式也称为“面向接口编程”。
14. 当RPA项目团队有多人开发时，每人负责一个流程的组织模式有可能造成每个流程都赶不完的局面。不如将单个流程划分成更小的流程，一起协同进行一个流程的开发，这样团队在预期的时间内可以完成尽可能多的流程，而不是制造大量完成度参差不齐的流程。特别是，团队成员可以不需要了解流程的全貌，只了解流程的局部即可，实现流水线式的开发管理。而对流程掌握最全面的成员，可以少承担一些开发工作，但需要负责不断地进行集成测试，由这个人来负责交付完整的UiPath Project。
15. 编辑Selector时，要善用相对Selector和部分Selector，例如Anchor Base，Element Scope，Find Relative Element， Get Ancestor。
16. 开发的最初不应该加入任何Try Catch，以便在测试中发现会产生Exception的位置，以及Exception的类型，并进行相应地处理。即使逻辑实现确实需要加入Try Catch，也切忌直接Catch System.Exception，防止预期外Exception类型无法在Catch中正确处理。但最后一定要在最外层套一个Try Catch，以处理预期外的Exception。
17. Get Text获取的数据是UiPath.Core.GenericValue类型，需要输出为特定格式字符串的时候，可以尝试使用Format Value（UiPath.Core.Activities.FormatValue）。
18. 目前大多数RPA的使用场景只是数据处理领域ETL工作的变种，因此可以尽量参考ETL的设计思想和有益经验。
19. 每个Activity都必须命名，必要时还须加上Annotation进行解释说明。参数和变量也是如此。