用 Power Automate for desktop 实现核心系统转录自动化 ── 将 Excel、纸质单据的手动录入替换为 UI 自动化

「负责人每天都要把 Web 订单表单或邮件收到的订单，手动重新录入到公司内部的销售管理系统里」「月末要把考勤、申请用的 Excel 汇总转录到核心系统，得花整整两天」。我们经常收到这类咨询。这些案例的共同点是：转录的目的地，是一套已经使用了 10 年、20 年的老旧业务系统（WinForms 或 VB6 时代的界面、专用客户端），既没有 API，也没有 CSV 导入功能。

对系统进行改造固然能从根本上解决问题，但由于供应商已经不在了、没有源代码、或改造费用不划算等原因，手动录入持续存在的情况并不少见。填补这一空白的现实工具，就是通过 Power Automate for desktop（PAD）实现的 UI 自动化。它直接重现人所进行的键盘输入和鼠标操作，因此无需对转录目标系统做任何改动即可实现自动化。而且在 Windows 11 上，不用额外安装即可直接尝试，门槛也很低。

不过，UI 自动化也是一种「一开始跑起来很容易，要稳定持续运行却很难」的工具。本文将聚焦于转录业务，从是否应该选择 UI 自动化的判断开始，梳理免费可用范围与许可的边界、稳定运行的设计，直至失败时的恢复。关于 Power Automate 整体的使用场景划分与错误处理的一般性讨论，笔者已经在「用 Power Automate 自动化业务 ── 云端流程与桌面流程的使用场景划分及错误处理设计」中写过，本文则是针对转录业务的专题讨论。

1. 先说结论

• UI 自动化是最后的手段。 应先确认转录目标是否具备 CSV 导入、数据库直接写入、API、文件对接等接口。只要有一种可用，稳定性都会明显更高。
• PAD 标准内置于 Windows 11，在 Windows 10 上也可以免费安装。 借助录制器和 400 多种操作，读取 Excel 并输入到界面的转录流程可以零代码搭建。¹²
• 只要是自己搭建流程并在本机手动运行（有人执行），就不需要额外付费。 无论使用职场・学校账户还是 Microsoft 账户都是如此。而从云端流程自动启动、按计划执行、共享流程，则需要 Power Automate Premium 许可。³⁴
• 类似夜间批处理的无人执行（unattended），还需要额外完成计算机注册并购买 Power Automate Process 许可。 技术层面也存在「所有用户必须已注销」等特有前提条件。⁵⁶
• 稳定运行的关键在于选择器的构建方式、元素等待、以及按单条记录粒度的异常处理这三点。用一连串固定 Wait 拼起来的流程，迟早一定会出故障。⁷⁸⁹
• 为了在失败时能知道「已经录入到哪里」，应从一开始就设计成让输入源 Excel 具备状态列和登记编号列，并按每条记录写回结果。这样即使重新执行，也不会发生重复录入。
• 由于因界面变化而出故障的宿命无法消除，件数多、不能停摆、目标应用更新频繁的业务，属于数据对接开发或核心系统改造的范畴。 具体的判断界线将在第 8 章整理。

2. 转录工作存在什么问题

从 Excel 或纸质单据向核心系统转录数据，其问题并不仅仅是「简单作业占用时间」这么简单。根据我们收到的咨询，常见的问题共有以下三点。

• 时间集中在结算日附近。 如果是每天的接单录入，工作量还算分散，但月末结算的账单处理和考勤汇总，往往会在结算日之后的一到两天内高度集中地进行转录。在这段时间里，负责人几乎无法做其他工作，很多公司应该都是靠加班或增援来消化这部分工作量。
• 录入错误会流向下游。 位数打错、行错位、商品编码搞混——转录错误往往要等到变成账单或库存数量出问题之后才会被发现，因此排查原因和更正所耗费的功夫，往往是录入错误本身的好几倍。加入双重核对可以减少错误，但同时也会增加时间成本。
• 会变成只有那个人才能做的工作。 「这个界面必须按这个顺序输入，否则会报错」「只有这家客户需要特殊的录入方式」之类的诀窍，会积累在负责人个人的脑子里，一旦他休假，业务就会停摆。

自动化的价值并不只是缩短时间。由于流程只会按照设定好的方式录入，转录错误得以消除；而且操作步骤以流程的形式被固定下来，也能缓解业务对个人的依赖。能够抹平结算日附近的高峰，同样意义重大。

另外，如果转录来源是纸质单据或传真，在此之前还需要一道「读取」工序。关于传真订单的 OCR，笔者已经在同期发布的「用 AI Builder 读取传真订单并交由 Power Automate 处理」中做了说明，本文则以转录来源「已经是 Excel 等数据形式」为前提展开。

3. 自动化方式的选择 ── UI 自动化是最后的手段

首先要强调的一点是：界面操作自动化（UI 自动化）是选择项中的最后一个。 UI 自动化依赖界面布局、分辨率、响应速度等「显示层面的因素」，因此无论做得多么细致，都不可避免地比直接传递数据的方式更容易出故障。应先确认转录目标核心系统是否具备下列接口。

另一个选择方向，是「消除」转录本身——也就是对核心系统进行改造或重建。关于是否要给 VB6 应用添加导入功能，或者干脆将其 Web 化、从接单入口重新构建，笔者在「将 VB6 应用迁移到 .NET ── 事前调查、兼容性、分阶段迁移的实践指南」和「判断是否应将 Windows 应用迁移到 Web ── 判断标准与现实的迁移模式」中做了梳理。由于改造需要投入开发费用，先用 PAD 自动化来争取时间，等业务量增加、看到自动化的极限之后再投资改造，这样的顺序也是现实可行的。

4. Power Automate for desktop 的基础

导入门槛低

PAD 标准内置于 Windows 11 中。在开始菜单搜索「Power Automate」即可找到该应用，首次启动时会自动下载并可立即开始使用。² Windows 10 和 Windows Server 2016 同样拥有使用权限，可以从下载中心免费安装。² 安装方式分为 Microsoft Store 版和 MSI 安装程序版；如果还考虑到后文提到的云端对接（计算机注册），建议选择可以一并安装计算机运行时应用的 MSI 版。¹⁰

用录制器搭建骨架

PAD 具备录制器，可以记录操作并转换为一系列操作步骤。它会以与 UI 元素的关系为基础记录鼠标和键盘操作，对于搭建转录流程的骨架来说已经足够实用。对转录业务尤其有帮助的一点是，记录方式可以在 UIA（UI Automation）和 MSAA（Microsoft Active Accessibility）之间选择。 UIA 是面向 WPF、WinForms 等相对较新应用的推荐方式，MSAA 则是面向 VB6 或经典 Win32 等 UIA 无法识别元素的老旧应用的方式。 当老旧核心系统的界面元素无法顺利识别时，把录制器的记录模式切换为 MSAA，有时就能识别成功。¹¹

不过，录制器终究只是用来搭建骨架的。它无法记录条件分支和循环，因此前提是录制之后还要在设计器中编辑完善。¹¹

UI 元素与选择器

PAD 会把界面上的按钮、文本框等记忆为「UI 元素」。其实质是一种选择器，通过窗口层级与属性的组合来定位元素。转录流程的寿命，几乎完全取决于这个选择器的构建方式。如果选择器中包含连续编号的索引或动态变化的 ID，即使界面外观完全相同，也可能在某一天突然无法识别。把会变化的属性从 Equals 改为 Contains 或正则表达式，为重要操作设置备用选择器以实现故障转移，出故障时用 Repair selector 功能生成修复候选——这些基本做法，笔者在整体指南中已经写过。⁷

有一点是转录业务特有的注意事项：UI 自动化的操作，是以目标窗口位于前台为前提运行的，如果不在前台，会自动将其切换到前台。¹² 也就是说，运行期间的电脑基本上是「流程独占」的。 应避免负责人在同一台电脑上一边运行流程一边做其他工作，因为这容易导致误点击、误输入。

转录的基本结构：从 Excel 读取，写入界面

转录流程的基本形态是「用 Excel 操作读取 → 在循环中逐条用 UI 操作写入」。用 Launch Excel 打开文件，用 Read from Excel worksheet 读取范围后会得到一个数据表变量。如果勾选「将首行作为列名」选项，后续在循环中就可以用类似 CurrentItem['客户编码'] 的方式按列名引用值，对列顺序调整的抗性也更强。¹³ 写回结果时使用 Write to Excel worksheet。如果想追加到行末尾，可以用 Get first free row on column 查找空行。¹³

5. 免费可用范围与许可的边界

在决定是否引入 PAD 时，一定会被问到「免费到什么程度、从哪里开始收费」。这条边界，位于「构建流程・手动运行」与「自动运行・以组织为单位进行管理」之间。

无论使用哪种账户，构建流程和手动执行都不需要额外付费。³⁴ 使用 Microsoft 账户时，流程会保存到 OneDrive；使用职场・学校账户时，则会保存到默认环境的 Dataverse。如果是在公司里使用，出于后续管理的考虑，通常建议从职场账户开始。⁴

跨越这条边界的时机，是想要实现「无需人工点击按钮也能运行」的时候。要让桌面流程在固定时刻或事件触发时启动，需要配置成由云端流程调用，为此需要做好以下准备。¹⁴

1. 计算机注册：将运行流程的电脑注册到 Power Automate 云端。用 MSI 版中包含的计算机运行时应用登录即可完成注册。需要注意的是，Windows 10/11 的 Home 版不支持这种直接连接方式。¹⁰
2. 桌面流程连接：创建一个连接（Windows 账户的凭据），供云端流程登录到该计算机。¹⁴
3. 许可：创建连接的用户，必须持有与执行形态相匹配的许可。¹⁴ 如果是在有人登录的电脑上运行的有人执行（attended），需要 Power Automate Premium（包含有人 RPA 权限的用户许可）。¹⁰⁶
4. 无人执行（unattended）还需要为该计算机分配 Power Automate Process 许可。 Process 许可不是绑定在用户身上，而是绑定在计算机（或流程）上的许可，每台计算机可获得一个无人执行名额（无人机器人）。需要注意的是，分配 Process 许可的计算机，前提是必须已经由持有 Premium 许可的用户注册完成。也就是说，光购买 Process 许可，如果没有 Premium 用户，也无法完成配置。⁵⁶

总结来说，如果运行模式是「负责人早上按下按钮，在眼前看着转录流程跑完」，那么在免费范围内就能完成。如果是「深夜自动跑完」的运行模式，就需要 Premium + Process（外加已注册的计算机）。如果转录所需时间大约是每天 30 分钟，先从免费的有人执行开始，等件数增多之后再考虑无人化，这样的顺序就已足够。关于许可的整体思路（包括标准／高级连接器的边界），笔者在同期发布的「Power Automate 的许可与标准・高级连接器的边界」中做了详细梳理。

6. 实现稳定运行的设计

用「等待元素」代替固定 Wait

老旧核心系统的搜索、登记响应时间会随负载大幅波动。用「等待 3 秒」这类固定 Wait 调出来的流程，一定会在系统变慢的那天出故障。基本做法是用 Wait for window content 操作，实现「等待特定 UI 元素或文本出现（或消失）」的等待方式。⁸ 获取窗口（Get window）也可以设置超时，可以选择「在指定秒数内找不到就判定失败」还是「持续等到出现为止」。⁸ 在转录流程中，「等待登记完成的提示消息出现之后再进入下一行」这种等待方式尤其重要。如果不等待就开始下一条录入，画面会在上一行尚未登记完成时就切换过去，导致数据混乱。

按「单条记录」组织异常处理

转录流程的异常处理，惯用做法不是包裹整个流程，而是用 On Block Error 包裹循环中单条记录的处理逻辑。 出错时记录该行的失败内容，把界面恢复到初始状态（关闭录入界面、返回菜单等），然后进入下一行。这样一来，即使 100 条记录里只有 1 条商品编码有误，其余 99 条也能完成录入，只留下失败的这一条交给人工处理。对于响应延迟等临时性错误，还可以配合按操作粒度设置的重试机制。⁹ 关于错误处理的细节做法（用 Get last error 获取错误内容、善后设计等），请参阅整体指南以及同期发布的「Power Automate 的错误处理与重试设计」。

即使失败，也要能知道「录入到哪里了」

UI 自动化没有像 Web 系统那样的事务机制。如果流程中途崩溃，而又不知道「已经登记到核心系统的哪一行」，就只剩下两个选择：重新执行导致重复录入，或者对全部记录进行目视核对。有两种设计可以防止这种情况。

1. 让输入源 Excel 具备状态列。 准备「未处理」「处理中」「完成」「错误」这样的状态列，以及记录核心系统所生成登记编号的列。在开始录入某一条记录之前先标记为「处理中」，在界面上确认登记完成并读取登记编号后，再写回「完成」状态和该登记编号。由于流程始终只以「未处理」的行为对象，无论重新执行多少次，都不会触碰已经录入完成的行（可安全重试）。
2. 只需人工确认停留在「处理中」状态的行。 流程如果会崩溃，一定是发生在录入过程当中，因此需要怀疑的只有停留在「处理中」的行。重新执行之前，只需针对这一行去核实核心系统的情况即可，核对范围会从 100 条缩小到 1 条。

这个状态列本身也就成了执行记录。「昨天的转录是否全部完成」这样的问题，不需要查看流程的执行历史，只要打开 Excel 就能看到——这种形式也很便于向业务现场解释说明。

无人执行环境的陷阱

「有人执行时运行正常的流程，一旦转为无人化就跑不动了」——这类咨询真的非常多。原因大多在于环境的差异。

• 会话前提：在无人执行时，Power Automate 会在目标计算机上新建一个远程桌面（RDP）会话，并在执行结束后注销。执行期间，目标计算机的屏幕会保持锁定状态。作为前提条件，该计算机必须所有用户都已注销；在 Windows 10/11 上，只要还残留任何人的会话（哪怕只是锁定状态），执行就会失败。在 Windows Server 上，如果残留着与连接使用的同一用户的锁定会话，也会报错。如果维护作业结束后习惯用「锁定」或「断开连接」的方式离开，而不是注销，夜间流程就会因此停摆。务必注销是这里的关键口诀。⁵
• 权限：连接所使用的用户，必须能够在该计算机上创建 RDP 会话（通常需要属于 Remote Desktop Users 组）。此外，无人执行不支持涉及提升到管理员权限的操作。⁵
• 屏幕分辨率：RDP 会话的默认分辨率，有时会与搭建流程时所用的屏幕不同。分辨率降低后，搭建流程时能看到的 UI 元素可能被隐藏到屏幕之外，从而导致「找不到元素」的失败；基于坐标的操作也可能因此点到别的地方。⁵ 对策是可以在流程属性中，把「无人执行时的屏幕分辨率」固定为与搭建时相同的数值。¹⁵ DPI 缩放的差异也是同类失败的原因之一，因此稳妥的做法是让搭建时与执行时的 DPI 都统一为 100%。¹⁶

验证完这些要点之后，再到云端流程一侧设置计划触发（例如工作日每天早上 6 点执行）。包含工作日判断和月末处理在内的计划设计，笔者在同期发布的「Power Automate 的定期执行流程与工作日设计」中做了讨论。

7. 转录流程的实例设计

把前面介绍的各个部件组合起来，设计一个「订单清单 Excel → 核心系统的接单录入界面 → 结果写回 Excel」的典型转录流程，大致如下。

flowchart TD
    Start([开始：手动或从云端流程触发]) --> ReadX[Read from Excel worksheet<br/>读取订单清单 首行作为列名]
    ReadX --> Filter{状态列中是否存在「未处理」的行}
    Filter -- 没有 --> Report[汇总处理结果并记录日志・通知] --> End([结束])
    Filter -- 有 --> Launch[启动核心系统并登录<br/>用等待元素确认菜单界面已显示]
    Launch --> Loop[对未处理的行逐条循环<br/>循环内用 On Block Error 包裹]
    Loop --> Mark[将状态列更新为「处理中」]
    Mark --> Entry[打开接单录入界面并输入各项目<br/>每次界面切换都用 Wait for window content]
    Entry --> Confirm[点击登记按钮 → 等待完成消息<br/>从界面读取生成的登记编号]
    Confirm --> WriteBack[将状态列设为「完成」并写回登记编号]
    WriteBack --> Loop
    Loop -. 某一条发生错误 .-> Handler[将错误内容记录到该行<br/>登记前失败标记为「错误」/登记后失败保持「处理中」<br/>将界面返回菜单后处理下一行]
    Handler --> Loop
    Loop -- 全部处理完毕 --> Close[登出并关闭核心系统] --> Report

对设计要点做一些补充说明。

• 输入值的校验要在 UI 操作之前完成。 商品编码的位数、数值项目中是否混入了文字、必填项目是否缺失——读取 Excel 之后应立即在流程一侧进行校验，有问题的行应在接触核心系统之前就标记为「错误」。相比通过 UI 操作去处理核心系统弹出的错误对话框，提前在前面拦截要稳定得多。
• 只有在点击登记按钮之前发生的失败，才可以标记为「错误」。 如果异常处理一律把状态列改写为「错误」，那么即便登记按钮的操作已经成功（例如在等待完成消息、或写回过程中）之后才失败的行，也会被标记为「错误」，这会导致负责人重新执行该行，从而在核心系统中造成重复登记的事故。登记操作之后发生的失败，应让状态列保持「处理中」；不将「处理中」的行作为重新执行的对象，而是由人工核实核心系统一侧是否已经登记成功，再手动改为「完成」或「未处理」。这种设计的要点，不是消除模糊状态，而是把模糊的情况有意识地交给人工确认。
• 要预先考虑到界面上的错误对话框。 即便如此，仍然会发生录入时的错误（库存不足、客户授信错误等）。可以预见的对话框，可以用「是否包含某个窗口」的条件分支来捕获，并记录到该行的错误内容中；无法预见的情况则交给 On Block Error 处理。⁹
• 要对件数和耗时有大致的预估。 UI 自动化每条记录耗时数十秒并不罕见。如果 100 条记录耗时 1 小时，那么用夜间无人执行完全可以承受；但如果每天有数千条记录，那就是应该重新审视 UI 自动化这一手段本身的信号（详见下一章）。
• 输入源的规范化要提前处理好。 字符编码和日期格式的不一致、全角半角混杂等来自 CSV、Excel 的常见陷阱，笔者在「CSV 文件处理实践指南 ── 防止乱码、0 丢失、日期错乱」中做了梳理。

8. PAD 自动化应该做到什么程度

UI 自动化只要界面发生变化，迟早会出故障。这并不是靠设计就能解决的问题，而是这种方式本身的宿命。正因如此，才需要对「可以用 PAD 自动化的转录」和「应该转向开发・改造的转录」划出一条清晰的界线。

判断的大致标准，是看「即使这个流程坏掉一周不修，改回手动录入，业务是否还能照常运转」。如果能运转，用 PAD 自动化就有足够的价值；如果不能运转，那么这项转录工作就已经不再是「自动化」的需求，而是「系统对接」的需求，需要考虑新增导入功能、数据库对接，或者干脆将接单・发单本身电子化（例如 EDI 或 将传真接单迁移到 Web）。

还有一点，PAD 的流程也容易变成「只有搭建者本人才能碰的资产」。流程内容、连接、执行用计算机由谁来交接，笔者在同期发布的「Power Automate 的个人依赖对策 ── 所有者、连接、交接的设计」中做了梳理。

9. 总结

对于既没有 API 也没有 CSV 导入功能的核心系统，转录工作可以用 PAD 的 UI 自动化实现「无需改动系统」的自动化。在 Windows 11 上可以直接开始使用，只是搭建后在本机运行也不需要额外付费。仅仅是让负责人从每天一小时的转录中解放出来、不再需要排查和更正转录错误，就已经足以收回引入所花费的功夫。

不过，重要的是不要弄错顺序和设计。在使用 UI 自动化之前，先寻找 CSV 导入、数据库、API、文件对接等接口；从免费的有人执行开始，若要无人化，要把握好 Premium + Process 许可以及计算机必须已注销这些前提；用选择器、元素等待、按单条记录的异常处理来实现稳定运行，并通过状态列的写回始终保留「录入到哪里了」的记录；一旦件数、重要程度、界面变更频率超出 UI 自动化的守备范围，就不要勉强让它继续承担，而应切换到核心系统改造或数据对接开发。

我们公司承接从 PAD 转录自动化的设计评审，到后续导入功能新增、系统间对接的受托开发，乃至遗留应用迁移这一整条链路的咨询。即便您还处在「不知道我们的核心系统能不能做到」这个阶段，也欢迎随时垂询。

相关文章

• 用 Power Automate 自动化业务 ── 云端流程与桌面流程的使用场景划分及错误处理设计
• 将 VB6 应用迁移到 .NET ── 事前调查、兼容性、分阶段迁移的实践指南
• 判断是否应将 Windows 应用迁移到 Web ── 判断标准与现实的迁移模式
• Power Automate 的错误处理与重试设计
• CSV 文件处理实践指南 ── 防止乱码、0 丢失、日期错乱

相关咨询领域

合同会社小村软件（合同会社小村ソフト）承接从 Power Automate for desktop 转录自动化的设计与稳定化咨询，到 UI 自动化无法覆盖的核心系统数据对接开发、遗留应用改造等一系列业务。

• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

Power Automate for desktop 可以免费使用吗？

可以。Windows 11 标准内置了 Power Automate 应用，Windows 10 也可以从微软下载中心免费安装。使用职场・学校账户也无需额外付费，即可使用录制器、400 多种操作、异常处理等流程构建与手动执行（有人执行）的全套功能。不过，从云端流程自动启动、共享流程、集中管理执行日志，则需要付费的 Power Automate Premium 许可。

要在夜间或清晨无人值守的情况下运行转录流程，需要哪些条件？

无人执行（unattended）需要配置为由云端流程调用，前提条件包括：注册目标计算机、创建桌面流程连接，以及为该计算机分配 Power Automate Process 许可。计算机的注册本身也必须由持有 Premium 许可的用户来完成。从技术层面看，无人执行会新建一个远程桌面会话来运行，因此目标计算机上必须所有用户都已注销；只要还残留一个锁定中的会话，在 Windows 10/11 上就会执行失败。

听说 UI 自动化容易出故障，它真的能实用吗？

只要目标核心系统的界面保持稳定，它就是实用的。出故障的原因大多在于 UI 元素的识别方式（选择器）和等待不足，因此把会变化的属性改为 Contains 或正则表达式、设置备用选择器、用等待元素出现的操作代替固定等待，这些设计能大幅提升稳定性。不过，因界面布局变化而出故障的宿命本身无法消除，所以如果目标应用更新频繁，或者处理的件数、重要程度使得停摆会影响业务运转，就应该考虑数据对接开发或核心系统本身的改造，而不是 UI 自动化。

如果转录流程中途失败，会不会搞不清楚已经录入到哪里了？

只要设计得当，是可以防止的。关键在于让作为输入源的 Excel 具备状态列（未处理・处理中・完成・错误）和登记编号列，每录入一条记录，就先确认核心系统一侧的登记结果，再把状态写回去。这样一来，一旦失败，Excel 中就会保留已登记到哪一行的记录；即使重新执行，也只会以「未处理」的行为对象，因此不会发生重复录入。如果按每条记录的粒度做异常处理，记录出错的行并继续处理下一行，就能避免一条录入错误导致整个流程停止。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。