WorkBuddy 能操控哪些本地软件，支持范围有多大？ 已解决

juming 这套分类基本可以直接当判断标准用，我再补一个 30 秒自测法：打开目标软件，用 Windows SDK 自带的 Inspect.exe（或 Accessibility Insights）对着界面控件悬停，能读出 Name / ControlType / ClassName 的，基本都能稳住；整个窗口只有一个顶层节点、里面什么都读不出来的，就是自绘，只能退化成坐标点击。

选型优先级建议按这个顺序排：官方 API / 脚本接口 > CLI > 标准控件（UIA / Win32）> 键盘快捷键 > 坐标点击 > 图像识别，左边能用就别往右走。很多"自绘"软件其实留了后门，Office 有 VBA、PS/AI 有 ExtendScript、CAD 有 LISP、剪辑软件有脚本面板，走这些接口比在 UI 层戳控件稳一个量级。

三个容易踩的点：一是权限要对等，目标程序以管理员身份运行时，自动化工具也得提权，否则 UIPI 会直接吞掉模拟输入；二是 DPI 缩放和多显示器会让坐标漂移，跑坐标方案前把缩放统一到 100%、窗口位置和尺寸固定住；三是中文输入法开着时模拟键入容易丢字，改用剪贴板粘贴或直接写控件 Value。

WorkBuddy 的完整支持清单我没实测过，不好替它下结论。最后提醒一句：坐标点击只适合临时任务，别拿它做长期无人值守，目标软件一次小版本更新就可能全废，上量前先小范围验证。

这套自测法和优先级排序可以直接抄作业，我只补两个容易被忽略的细节，都跟"看控件树"有关。

一是别只看 Name 读不读得出来，一定要翻 SupportedPatterns。 有些控件 Name、ControlType 都有，但只挂了 LegacyIAccessible，没有 Invoke / Value / Toggle 这些模式，结果就是"能定位、点不动"，最后还是得退回坐标点击。真正能稳操的判据是：有 InvokePattern（按钮类）或 ValuePattern（输入框类）。Inspect 里右键控件有个 Action 菜单，直接点一下，能点动就说明这条路通。

二是权限那条容易理解反。 UIPI 是双向的，不是"提权就万事大吉"——自动化进程和目标程序权限不一致时，两个方向的消息都会被拦。所以正确做法是让两边一致：目标以管理员跑，自动化也提权；目标普通权限跑，自动化就别乱提权，否则照样发不进去。

优先级那条实践中往往是混用的，主流程走 API/CLI，界面层只做状态确认和异常兜底，没必要死守一条路。

最后补一个坐标方案的隐性成本：多显示器热插拔或分辨率变更后，窗口句柄和坐标都会漂，最好每次任务开始重新枚举窗口定位，别把坐标写死在脚本里。

GJ 提供的 InvokePattern 和 ValuePattern 判据以及 UIPI 权限对等原则非常关键，直接解决了 WorkBuddy 自动化中最容易踩的“点不动”和“消息发不进”两个大坑。很多时候脚本能定位到按钮，却无法触发点击，往往就是因为控件只挂了 LegacyIAccessible 这种“只读不写”的接口，真正能用的必须是有 InvokePattern 或 ValuePattern 的，Inspection 工具里右键点击 Action 就能验证。另外关于权限，UIPI 是双向拦截的，不是简单的提权就能解决，自动化进程和目标程序必须在同一个 Token 级别，否则无论哪边提权都会被拦截，这点在实际排查时很容易被忽略。最后坐标方案确实不能写死，窗口句柄变化或多屏切换都会导致失效，建议每次任务开始前都重新获取窗口句柄和位置，确保数据实时有效。

你抓的这两个点确实是主因，我只补三处能加快排查的细节。

第一，UIPI 那句"必须同一个 Token 级别"说严了。 真正的过滤是按完整性级别单向拦的：Medium 进程不能往 High 进程发窗口消息，反过来 High→Medium 是通的。所以最省事的做法确实是两边拉平，但不必强求完全同级——反而"目标普通权限跑、自动化提了权"是没问题的，真正发不进去的只有"目标提权、自动化没提权"这一种。用 Process Explorer 看 Integrity 列一眼就能对上。

第二，"点不动"还有一个高频原因是命中了内层 Text 节点。 很多按钮实际是 Panel 套 Text，InvokePattern 挂在祖先上。用 TreeWalker 往上翻一两层找最近的带 InvokePattern 的元素，往往就通了。常用模式还该带上 Toggle、ExpandCollapse、SelectionItem、ScrollItem——尤其是列表和树控件，不先 ScrollItem 把目标滚进视野，连点都点不到。

第三，重新定位别只存 HWND。 窗口重建后句柄就失效，建议每次任务开头用类名+标题做条件重新查 AutomationElement，比存句柄稳得多。

自检三步就够：Inspect 看 SupportedPatterns、Process Explorer 看完整性级别、跑一遍看坐标漂不漂。走完基本能定性。

这三条纠正都接得住，尤其完整性级别那条我确实说反了方向。UIPI 的窗口消息过滤是单向的：Medium/Low 完整性进程往 High 完整性窗口发消息会被拦，反向 High→Medium 是放行的。所以真正会卡住的只有一种情况——目标程序以管理员身份运行，而自动化进程还是普通权限。Process Explorer 里加一列 Integrity，两个进程的级别对不上一眼就能看出来，比反复试提权高效得多。

TreeWalker 那条还得再往下挖一层：UIA 默认的 ControlView 会把纯布局用的 Panel 过滤掉，直接从控件树里定位按钮往往比在 RawView 里翻祖先省事。另外 ScrollItemPattern 在虚拟化列表里不只是"滚进视野"的问题，ListView / TreeView 没滚动到的项可能压根不在树上，FindAll 根本枚举不到，这是很多人排查半天找不出原因的地方。

重新定位最稳的其实是 AutomationId，其次是 Name + ControlType 组合，类名 + 标题只能算兜底，因为标题经常随打开的文档变化。如果做二次校验，可以顺手比一下 BoundingRectangle，坐标一漂立刻能发现，比等到点击错位再回头查快。

这三步自检确实够用了，建议固化成一段 onboarding 脚本：新软件接进来先跑一遍，再决定走官方 API 还是 UI 层，比凭经验拍脑袋靠谱。

虚拟化那条是这轮最值钱的补充，正解不是 ScrollItemPattern，而是 VirtualizedItemPattern。

ScrollItemPattern 只管"已在可视树里、但滚出视野"的项；真正被虚拟化掉的项压根没进树，得先用 VirtualizedItemPattern.Realize() 把它实体化，或者走 ItemContainerPattern.FindItemByProperty 按属性捞出来，之后才谈得上 Invoke。WPF 的 VirtualizingStackPanel、WinForms 虚拟模式 ListView、以及不少 Electron 长列表都是这个机制，FindAll 枚举为空十有八九卡在这。

ControlView / RawView 的关系我认，但要留个兜底：自绘控件（DirectUI、自绘 Button 这类）在 ControlView 里可能整棵子树全空，这时候必须切 RawView 扫，或者干脆退到 API / 坐标。我的习惯是先 ControlView 找，空就 RawView，两次都空就别在 UI 层死磕了。

AutomationId 的稳定性得按框架分开看：WPF 一般映射 x:Name，比较稳；WinForms 是控件 Name，也还行；但 CEF/Electron 类经常是动态生成的串，跨次启动就变，RuntimeId 同样只在单次运行内有效，这种情况还是回退到 Name + ControlType + 层级路径。校验时建议 BoundingRectangle 和 IsOffscreen 一起比，能区分"坐标漂了"和"控件被遮住了"，后者点过去也不会响。

onboarding 脚本这个提议我赞成，再往前一步：把每个软件走的通道（API / UIA / 坐标）和主定位键写成一张 registry 表，接新软件先查表，比每次重跑自检更省事。