在上一篇探讨 cliclick 的文章中，我们了解了如何通过屏幕像素坐标来模拟键鼠操作。然而，基于坐标的点击是极其脆弱的——窗口尺寸变动、分辨率切换或是 UI 的微小更新，都会导致脚本直接失效。为了追求极致的稳定性和精准度，我们需要超越表面的像素，直接深入到 macOS 应用程序的内部骨架中去。今天，我们就来揭开 macOS 自动化的底牌：AXUIElement。
1. 什么是 AXUIElement？macOS 的“原生 DOM 树”
如果大家有 Web 开发经验，一定非常熟悉 DOM（文档对象模型）树。在浏览器里，我们可以通过选择器轻松获取到任何一个按钮或输入框，并直接读取或修改它的值，而完全不需要知道这个元素在屏幕上的物理坐标。
对于 macOS 桌面端应用而言，AXUIElement (Accessibility UI Element) 就扮演了类似于 DOM 树的角色。它是 Apple 提供的一套底层无障碍 API。当一个标准的 macOS 应用程序运行时，系统会自动为其构建一棵无障碍节点树。
通过 AXUIElement 接口，我们的自动化脚本可以获得宛如“透视眼”一般的能力：
- 精准查询：直接遍历窗口内的每一个 UI 元素（如按钮、输入框、滑块等）。
- 读取属性：直接获取元素的
role(角色类别)、label(标签文本)、value(当前值) 等语义信息。 - 直接操控：绕过鼠标点击，通过代码直接向元素发送动作（例如
set value填入文本，或触发press点击动作）。
因为不需要在屏幕上移动真实的鼠标光标，使用 AXUIElement 的自动化脚本可以在后台静默、极速且百分之百稳定地运行。
2. AXUIElement 的能力边界与“黑盒”局限
尽管 AXUIElement 如此强大，但它并不是万能的。它的能力范围与应用程序的底层架构息息相关。
原生框架的绝对掌控力：对于使用 Apple 官方原生框架（如 AppKit 和 SwiftUI）开发的应用，AXUIElement 具有几乎完美的掌控力。系统会在底层自动将所有 UI 控件桥接到 AX 树上，使得自动化脚本可以畅通无阻地探索和操作。
自研渲染引擎的“黑盒”危机：然而，随着跨平台技术的普及，许多现代应用（例如剪映等）采用了完全不同于原生的技术栈。它们往往使用了基于 Web 技术的 Electron，或者是自研的高性能自定义渲染画布（Custom Canvas）。
在这种架构下，应用内部的按钮、数字滑块、时间轴等复杂组件，本质上只是画布上“画”出来的像素图像，系统层面根本不知道它们的存在。虽然像剪映这样的软件出于基本的无障碍合规考虑，可能会手动向系统注册部分基础控件（例如主导航的 Tab 切换，这就是为什么有时候你能选中它们），但它绝大部分复杂的交互组件（如参数调节滑块）多半不会暴露在 AX 树里。
对于 AXUIElement 来说，这类自研渲染的界面就变成了一个无法解析的“黑盒”。
3. 总结
在构建高级的 macOS Agent 和自动化工具时，AXUIElement 是一项必须掌握的核心技术。它能为原生应用的自动化带来极高的工程级稳定性。
但在实际开发中，我们必须清醒地认识到它的局限性。当我们面对大量采用跨平台或自研渲染方案的现代应用时，AXUIElement 只能作为一种“值得优先尝试，但成功概率不高”的手段。在未来的自动化探索中，结合基于大模型的计算机视觉（CV）理解与传统的物理按键模拟，才是实现全场景覆盖的最优解。
