给AI一双「眼睛和手」——这款开源工具让AI自动操作手机模拟器

上周有个做移动端开发的朋友跟我吐槽：「AI 写代码越来越强了，但写完能不能帮我把 App 跑起来看看效果？」 这个问题其实很戳心——AI 能写代码、能重构、能 review，但它「看不见」自己写出来的界面长什么样。

今天推荐的这个开源项目，就是要解决这个问题。

sim-use：让AI「看见」并「操作」手机屏幕

sim-use 是一个跨平台命令行工具，由日本公司 LY Corporation 开源。它的核心能力只有两句话：

Observe（观察）——把手机屏幕转成 AI 能理解的紧凑文本结构
Act（操作）——让 AI 根据观察结果，点击、滑动、输入文字

就这么简单？但做到这一步，背后其实藏着不少工程智慧。

Observe：一张屏幕变成 300 token

AI 模型很聪明，但处理「截图」这件事效率极低——一张 1080p 的截图传进去可能要几千甚至上万个 token。sim-use 换了一种思路：不传图，传文本大纲。

你运行 sim-use ui，它通过 iOS 和 Android 的 无障碍（Accessibility）API 读取当前屏幕上的所有元素，然后输出一段紧凑的结构化文本：

$ sim-use ui
App: Settings  402x874

[Top  y<120]
  @1  StaticText  "Settings"
[Content  y=120..754]
  @5  SearchField  "Search"
  @7  Button  "Sign in to your iPhone"
  @9  Button  "General"
  @10 Button  "Display & Brightness"
  ...
[Bottom  y>754]
  @43 TabBar

这比起原始的 JSON 无障碍树，体积缩小了约 16 倍——一个完整屏幕的文本描述只需要几百个 token，AI 读完就能「理解」当前界面的布局。

每个元素还被分配了一个 别名（alias），比如 @9 指向「General」按钮。这就为下一步操作做好了准备。

Act：点击「@9」即可

有了别名之后，操作就变得极其简单：

$ sim-use tap @9
✓ Tap at (201.0, 452.0) completed successfully

不需要坐标、不需要图像识别，用 @N 别名就能精准点击。还支持更多选择器：

选择器	示例	适用场景
`@N` 别名	`tap @9`	快速操作，上一步缓存的位置
`#<id>` 唯一标识	`tap #settingsButton`	布局变化后仍稳定
`--label` 文本标签	`tap --label "General"`	脚本化流程
`-x -y` 坐标	`tap -x 100 -y 200`	最后手段

Observe → Act → Verify，这就是 sim-use 设计的核心循环：

sim-use ui                  # 1. 读取屏幕
sim-use tap @9              # 2. 点击元素
sim-use ui                  # 3. 验证结果

整个过程耗时约 300 毫秒，基本做到了实时交互。

真正的「跨平台」——iOS + Android 统一接口

值得点赞的是，sim-use 用同一套命令同时驱动 iOS 模拟器和 Android 模拟器/真机。你不需要为两个平台分别写不同的脚本：

# iOS Simulator（通过 UUID 识别）
sim-use ui --device 1A2B3C4D-...

# Android 设备（通过序列号识别）
sim-use ui --device emulator-5554

命令完全一致：ui、tap、swipe、type、paste、screenshot，iOS 和 Android 都有。差异仅在底层实现——iOS 走 Accessibility API + HID 管道，Android 走 AccessibilityService + ADB 隧道。

一些讨巧的设计细节

Unicode 粘贴（Paste）：打字输入时，日文、中文、表情符号等通过 HID 键码可能被系统 IME 干扰。sim-use 提供了 paste 命令，先把文本写入模拟器剪贴板，再发送 Cmd+V，完美绕过键盘输入法的问题。

批量操作（Batch）：想在单次调用中完成多个步骤？用 batch 模式，共享一个 HID 会话和一次无障碍快照，大幅减少往返开销：

sim-use ios batch --device $UDID \
  --step "tap --id SearchField" \
  --step "type 'hello world'" \
  --step "key 40"

崩溃检测：sim-use 的守护进程会监控目标应用进程是否存活，当应用 crash 时自动在下次 ui 调用时给出提示——这对自动化测试来说是个特别实用的功能。

内嵌 Web Viewer：运行 sim-use viewer 会启动一个本地 Web 应用，在 SVG 画布上可视化渲染当前的 UI 树。你可以直观地看到无障碍树覆盖了哪些元素、遗漏了哪些盲区。

安装体验

macOS 用户一键安装：

brew tap lycorp-jp/tap
brew install lycorp-jp/tap/sim-use

然后就可以让你的 AI 助手学会使用它——项目内置了 agent skill：

sim-use init --client claude

这条命令会把 sim-use 的全部命令接口安装到 Claude 的 skill 目录里，之后 Claude 在写代码时就能自动调用模拟器验证效果。

技术原理简析

sim-use 的架构可以分三层理解：

1iOS 层：基于 Facebook idb^[1] 的 XCFramework，直接调用 Apple 的 Accessibility API 读取 UI 树，通过 Simulator HID 管道模拟触控输入

2Android 层：通过 ADB 部署一个轻量级 Bridge APK 到设备上，该 APK 暴露 AccessibilityService 树和输入注入能力，通过 HTTP 隧道通信

3统一 CLI 层：Swift 实现的 CLI，将以上两个后端封装为一致的命令接口，自动判断设备类型并路由到对应后端

一个有趣的设计是守护进程（Daemon）：首次使用时会自动启动一个后台进程，缓存设备连接和初始化状态。后续命令复用该进程，避免了每次都要重新初始化的开销（约 200ms）。守护进程在闲置 600 秒后自动退出。

横向对比

类似工具不多，值得一提的有：

•Appium / XCTest / Espresso：传统 UI 测试框架，面向的是预设脚本，而非 AI agent 动态决策。setup 复杂得多。

•AndroidViewClient / facebook-wda：Python 库，功能类似但缺少统一的跨平台抽象，输出格式也不是为 LLM 优化的。

•Playwright / Puppeteer：Web 端标杆，但只支持浏览器。移动端一直缺少一个对等的「agent-first」工具——sim-use 正在填补这个空白。

sim-use 最大的差异化在于： 它从第一天就是为 AI agent 循环设计的。输出格式紧凑、有别名缓存、支持 --json 机器可读输出、内置 agent skill——这些都是做 AI 自动化时「少走弯路」的设计。

局限与展望

•目前仅支持 macOS 14+：因为依赖 idb 的 XCFramework，无法在 Linux 或 Windows 上运行

•Android 端需要一次初始化：运行 sim-use android init 安装 bridge APK

•iOS 模拟器需要连接实体键盘：paste 命令的 Cmd+V 路径需要模拟器开启了「Connect Hardware Keyboard」

•首次使用约 200ms 初始化：虽然后续命令很快，但首命令有延迟

值得关注吗？

我的判断是：非常值得。

随着 AI coding agent 越来越成熟，「写完代码后自动验证」这个闭环一定会成为标配。sim-use 选择了一个很好的切入点——让 AI 能「看」到 UI、能「动」手机。它不一定能替代 Appium 这样的专业测试框架，但对于快速原型验证、AI 生成 UI 后的自动检查、以及个人开发者的自动化需求来说，已经足够实用。

而且它才上线几天就获得了 300+ Star，增长速度说明确实有人在用、有需求在。

项目地址： github.com/lycorp-jp/sim-use^[2]

安装方式： brew install lycorp-jp/tap/sim-use

许可协议： Apache 2.0

如果你也在做 AI agent 相关的事情，不妨试试把它接入你的工作流。有任何使用心得，欢迎留言交流。

参考链接

[1] idb: https://github.com/facebook/idb

[2] github.com/lycorp-jp/sim-use: https://github.com/lycorp-jp/sim-use