一名合格的UiPath开发人员究竟需要具备什么核心技能？业务梳理？沟通技巧？VB.net吗？VBA吗？Python？还是SQL？出于多种原因，关于这一点总是众说纷纭，莫衷一是。尽管这些技术都算沾边，但我始终觉得并没有触及RPA或者UiPath的核心。
那么我就反过来想，究竟缺少了哪一点，RPA就不再能够称之为RPA？
一上来就直面这个问题，其实是有些困难的。于是我便进一步问自己，RPA到底是什么？
我相信许多同行跟我一样，经常被问到——所谓的RPA，跟按键精灵到底有啥区别？我努力试图向人们解释RPA比按键精灵更高大上，但往往人们的表情依然困惑。一个人问，可能只是个疑问，一万个人问，那必定有什么道理。为此我冥思苦想，忽然觉得以往试图强行将它与按键精灵区分开，似乎是个错误的方向。这个东西，本质上跟按键精灵并没有什么不同，都是图形界面的自动化技术。至少在单机环境下，按键精灵和各种RPA工具理应能够实现同样的功能和效果。这么一想，就豁然开朗起来。
那么既然RPA是图形界面的自动化技术，这一类技术的核心是什么？
当然是找到正确的界面元素，并与其进行预期的交互。所以说，搞明白在UiPath中如何准确地定位界面元素，是UiPath开发的首要技术要求。
那么在UiPath中定位元素，有哪些关键知识点呢？
我认为有以下几点。
完整选择器
部分选择器
模糊选择器
绝对定位
相对定位
动态定位
其中动态定位技术最复杂，涉及一些相关的Activities，包括但不限于：
Anchor Base
Context Aware Anchor
Element Scope
Find Children
Find Relative Element
Get Ancestor
Indicate On Screen
Pick
Try ... Catch ...
Switch
Throw
Rethrow
Get Position
等等。如何灵活运用以上知识进行准确的元素定位，才是UiPath的核心技术。并且，以上提及的知识点也都是UiPath的难点。UiPath玩过好几年但还是没有完全搞懂上述知识的开发人员，我见过不少。新手更是经常在定位界面元素的问题上翻车。可见吃透定位技术并不容易。据我所知这方面的系统学习资料并不多，官方教程也只做扫盲然而并不深入，只能全凭各人的钻研和经验积累，所以可以用来考察UiPath开发人员的功力深浅。
我觉得将它视为UiPath开发人员技术合格与否的第一道分水岭都不为过。
核心定义的后半句话是，进行预期交互的能力。预期交互是指什么呢？其实说白了，就是设计和实现逻辑分支的能力。
有的人可能会觉得，实现逻辑分支有什么难的？不就写个if/Else，True/False嘛？会这么想虽然算有些理解，但缺少实践支撑。
我知道有不少人在设计流程的时候，是线性的思维，流程图是一条直线一二三四走下来，开发的时候也常常喜欢用Sequence一条写到底。这样遇到小的逻辑分支还能修修改改，遇到大的逻辑分支就完蛋了，完全改不动。一个典型的例子就是登录流程的设计，往往一登录就了事，从来不想密码错了流程怎么走，密码过期了流程怎么走，登录成功还是失败也不确认，遇到任何异常就简单粗暴地重试三次了事，最终导致账户被锁定，才回头想办法返工重做。登录的例子还算简单明了，有些场景逻辑分支实现起来相当复杂，需要对业务异常和技术异常全盘考虑尽量处理，还要兼顾用户需求，就很棘手。特别是异常流程要怎么走，应该做到什么，能做到什么，什么动作做不了，这些事心里有没有数，也是应该考察的重点之一。
以100分制来打比方的话，定位技术可以用来判断UiPath开发人员达到60分没有，而按预期进行交互的能力则可以用来评判是否达到80分。
另外，由于目前大多数RPA客户还处于小打小闹的尝鲜状态，许多RPA项目只是做Front-Office Robot，即前端的，助手形的机器人。这种类型的机器人设计上有一个特点是自动化流程有可能与用户当前的操作同时进行。因此，如何尽量避免影响用户操作，也是一个虽然不大但蛮重要的考察点。
与传统IT开发技术不同，准确和稳定是RPA的首要要求，性能虽然也蛮重要但其实很少优先考虑。