Mac AI 助手不能只靠截图：三种上下文源与验证闭环设计

截图只能告诉我 Mac 屏幕上有什么，但它本身无法告诉我某个控件意味着什么、某个操作是否成功，或者助手应该拥有多大的权限。

这就是为什么我认为，一个具备屏幕感知能力的助手需要的不仅仅是视觉。它需要一个有边界的观察与执行循环。

三种屏幕上下文

我将屏幕上下文分为三个来源：

无障碍结构（Accessibility structure）：macOS 暴露的角色、标签、值、焦点和操作。这通常是对语义控件而言最强的信息来源。

视觉上下文（Visual context）：当无障碍信息不完整时的像素、OCR 或检测到的标记。

交互状态（Interaction state）：活动窗口、近期用户输入，以及操作后的可见变化。

每个来源都有缺陷。无障碍树可能不完整。视觉模型可能误读坐标。可见的变化可能发生但并不能证明达到了预期结果。可靠的助手会交叉验证各个来源，并在置信度不够时明显地失败。

使用动作循环，而非点击生成器

我想要的循环是：观察、规划、在需要时请求批准、执行、验证。

对于一次点击，验证可能意味着确认无障碍值发生了变化，或者新窗口出现了。对于引导式工作流，助手应该只在用户的操作产生预期状态后才推进。坐标是一个实现细节，而不是持久的结果。

保持观察的有界性

屏幕访问权限很强大，因此助手应该只收集当前任务所需的内容。它不应该默认将临时上下文转化为永久存档。

实际规则很简单：

• 在像素之前优先使用无障碍数据
• 仅在必要时捕获视觉上下文
• 在本地模式下保持观察的本地性
• 将设备外规划透明化
• 允许用户禁用屏幕和日志来源
• 为操作保留审计轨迹，但不保留无关的屏幕历史

Pace 的做法

Pace 可以结合本地无障碍上下文、OCR 和本地视觉模型。它的执行路径对可能的目标进行评分、验证结果，并对模糊控件保留恢复路径。它还可以在屏幕上绘制指导，等待用户完成预期的步骤。

重要的不是助手能够点击，而是每次观察和操作都保持在可见的信任边界内。

我记录了当前的屏幕模型、隐私边界和局限性：https://heypace.app/screen-aware-ai-assistant-mac/