解读 Power Automate Desktop 2.54：测试用例、SAP 新动作与 Azure Key Vault 凭据支持，教你把桌面自动化做得更可控。
Power Automate Desktop 2.54：测试、SAP与密钥库更新
桌面自动化最常见的失败，不是“做不出来”，而是“做出来之后不敢改”。流程一变就担心报错；换了电脑、换了账号、换了版本就怕跑不起来。对小团队来说，这种不确定性比“不会写脚本”更耗时间。
Microsoft 在 **Power Automate for desktop（PAD）2.54（2025 年 3 月更新）**里做了三件很务实的事：引入测试用例、加强 SAP 桌面自动化、把 Azure Key Vault 凭据纳入开箱即用的凭据来源。我认为这三项改进的共同指向只有一个：让桌面自动化从“个人宏”更像“可交付、可维护的生产系统”。
这篇文章会把更新内容讲清楚，更重要的是把它放进一个更大的叙事里：我们在对比“端到端自动驾驶 AI（Tesla 路线）”与“中国车企多传感器、多供应商协同路线”时，反复看到一个规律——系统越复杂，越需要可验证、可观测、可治理的工程能力。桌面自动化也一样。PAD 2.54 的价值，恰恰在“工程化”。
这次更新解决了什么“真实痛点”？
答案先说：PAD 2.54 把桌面流（Desktop flows）从“能跑”推向“可测试、可控的交付”。
如果你在小公司做过自动化，会很熟悉这些场景：
- 流程每天跑 50 次没问题，但月底报表期一改字段就崩；排查靠“猜”。
- SAP 的菜单项点选不稳定，UI 稍微变动就要重录。
- 流程里需要登录、密钥、token，只能放在本地/凭据管理器/共享文档里，风险很大。
这三个痛点对应 2.54 的三项更新：
- 测试用例（Test cases）：把“验证流程正确”从手工变成可重复的步骤。
- SAP 新动作：用更稳定的方式选择 SAP 导航菜单。
- Azure Key Vault 凭据支持：把密钥从流程里移出去，降低泄漏和维护成本。
把它类比到自动驾驶路线对比里：
- Tesla 端到端强调“统一模型”，但上线必须靠严密回归测试与数据闭环；
- 多传感器协同强调“模块可替换”，那就更依赖接口契约与组件级测试。
桌面自动化同理：流程越多、参与者越多、版本迭代越快，测试与凭据治理就越不是锦上添花，而是生存工具。
新增测试用例：让桌面流开始“可回归”
答案先说：测试用例让你在改流程前先知道“会不会坏”，在坏了之后更快定位“坏在哪里”。
PAD 2.54 在控制台加入了一个新的 Test cases 选项卡，并在“Testing”模块中新增两个动作：
Assert：断言某个期望是否成立（比如某个变量值、某个 UI 文本、某个文件是否存在）。Test a desktop flow：触发并测试另一个桌面流（用于把大流程拆成可测的模块）。
小团队最实用的 3 类断言（Assert）
我建议从最“便宜”的断言开始做起——不追求覆盖所有路径，先覆盖最常坏的点。
- 输入校验（一开始就失败，省时间）
- 断言下载目录存在
- 断言参数非空、日期格式正确
- 关键 UI 状态（UI 自动化最容易飘）
- 断言窗口标题包含某些关键字
- 断言登录后出现某个元素（而不是“等 5 秒就算成功”）
- 输出结果（保证交付物可靠）
- 断言导出的 Excel 行数大于 0
- 断言生成的 PDF 文件大小大于某阈值
一句话总结：别用“Sleep 5 seconds”当作成功标准，用断言。
为什么这对“AI 语音助手与自动化工作流”尤其关键
语音助手把操作入口变得更“随意”：一句“帮我跑一下对账”就触发流程。入口随意，后台必须更确定。
你可以把 PAD 流程做成语音助手的执行单元：
- 语音助手负责：意图识别、参数收集（日期、客户、门店）、权限确认
- PAD 负责：桌面端实际操作（ERP/SAP/旧系统）、生成报表、归档
- 测试用例负责：把“随时触发”变成“随时可信”
换句话说：语音入口会放大自动化失败的代价，所以测试会变成刚需。
SAP 自动化新增动作：更稳定地选择导航菜单
答案先说：Select SAP navigation item 让 SAP 菜单交互更像“结构化选择”，而不是“坐标点击”。
SAP 桌面自动化的难点在于：
- UI 元素层级深、对象识别不稳定
- 不同用户权限/布局带来菜单差异
- 稍微升级或调整主题就可能影响选择器
PAD 2.54 在 SAP automation 模块新增 “Select SAP navigation item”，用于与 SAP 窗口工具栏的菜单项交互。
对小企业/中小团队意味着什么
很多中小团队的现实是：前台用 SaaS，后台还在 SAP 或传统 ERP；数据对账、开票、出入库、对供应商结算，仍然绕不开 SAP GUI。
这个新动作的价值不在“多一个按钮”，而在：
- 减少录制依赖：尽量用语义化的导航项选择
- 提高流程可维护性：菜单路径更清晰，交接更容易
- 降低回归成本：升级 SAP GUI 时更不容易全盘重录
类比自动驾驶：当系统需要同时对接多供应商传感器或多个 ECU，工程上必须追求“接口稳定、行为可预期”。SAP 自动化也是同一条逻辑。
Azure Key Vault 凭据支持：把秘密从流程里“移走”
答案先说：把凭据放进 Azure Key Vault，能显著降低泄漏风险，也能让账号轮换更轻松。
2.54 里，Get credential (preview) 动作新增对 Azure Key Vault credentials 的支持（原文提到此前支持 CyberArk，现在扩展到 Key Vault）。
为什么我强烈建议把“密码/密钥”从 PAD 流程中抽离
把凭据写在流程里，常见后果有三种：
- 泄漏：流程文件被复制、被导出、被截图，密码跟着走。
- 不可轮换：一换密码就要改 N 个流程，改一次坏一次。
- 权限失控：谁能运行流程，谁就可能拿到明文凭据。
用 Key Vault 的思路是：
- 流程只拿到“临时使用权”，拿不到长期明文
- 密钥轮换只在 Key Vault 做一次
- 审计和访问控制更集中
如果你正在把桌面自动化接到 AI 语音助手（比如用于财务、采购、IT 支持的“语音触发”工作流），那凭据治理必须提前做。越晚做，迁移越痛。
把这三项更新串成一个“小企业可落地”的自动化框架
答案先说：用“模块化 + 测试 + 凭据治理”三件套，能把 PAD 从单点工具变成团队资产。
这里给一个我更推荐的落地顺序（不是理论最优，是现实最省心）：
1）先做流程分层：把“易变的 UI”关进笼子里
- 层 A：入口层（语音助手/表单/按钮）
- 只负责收集参数、权限确认、触发
- 层 B：业务编排层（PAD 主流程）
- 串联步骤、错误处理、日志
- 层 C：系统适配层（PAD 子流程）
- 专门对接 SAP/旧系统/网页 UI
这样做的好处是：SAP UI 变动只影响层 C，入口层和编排层不需要大改。
2）再补测试用例：优先覆盖“高频 + 高风险”路径
建议用一个很具体的标准挑选测试：
- 高频：每天/每周必跑的流程
- 高风险：一旦出错会影响钱（开票、对账、付款）或影响合规（数据导出、客户信息）
每个流程至少做 5 个断言：
- 2 个输入断言
- 2 个关键状态断言
- 1 个输出断言
这已经能解决 80% 的“改了就炸”。
3）最后做凭据集中：把账号轮换变成常规操作
把凭据迁移到 Key Vault 后，建立两条规矩：
- 密码轮换固定周期（比如 30/60/90 天游走一次）
- 流程只用凭据引用，不允许再出现硬编码
工程上最值钱的能力之一就是：让正确的事更容易，让危险的事更麻烦。
常见问题（People Also Ask 风格）
PAD 的测试用例适合做“单元测试”吗？
更接近“流程级回归测试”。它不会像传统代码那样天然适配纯单元测试，但你可以通过 Test a desktop flow 把大流程拆成小模块，从而获得类似单元测试的收益。
只有 IT 团队才需要 Key Vault 吗？
不是。只要你的流程涉及财务、CRM、ERP、邮箱、数据库登录，Key Vault 就是更安全也更省维护的选择。小团队更需要它，因为小团队通常没有专职安全岗来兜底。
SAP 自动化为什么总是不稳定？
因为它依赖 UI 元素识别与窗口状态。你要用更结构化的交互动作（比如本次新增的导航项选择），再加上断言与重试策略，才能把“不确定性”降到可接受。
你现在就能做的三步
PAD 2.54 的三项更新，本质上是在鼓励你把桌面自动化做成“可交付的软件”。这跟我们在“自动驾驶 AI：Tesla 与中国车企的发展路径对比”系列里强调的观点一致：规模化不是靠更聪明的点子，而是靠更可靠的工程系统。
如果你想把 AI 语音助手接入桌面自动化工作流（比如语音触发对账、开票、下载报表、同步 Excel），我建议从这三步开始：
- 挑一个最有 ROI 的桌面流（每周至少节省 1-2 小时的那种）
- 为它加上 5 个断言（别多，先让它“可验证”）
- 把凭据迁到 Key Vault（让下次改密码不再是灾难）
当你的团队开始用“测试 + 凭据治理”的方式对待自动化，下一步就很自然了：让语音助手成为更轻的入口，让 PAD 成为更稳的执行层。
你更担心哪件事：流程改动后的不可预测，还是凭据管理带来的安全压力？把你的具体场景写下来，往往就能反推出最该先改的那一层。