一块50元的板子，让AI长出了“手”

让AI打开iPhone上的白板，画个笑脸；再让它去时钟里，设一个每天早上7点响的闹钟。听着像手机厂商又展示了什么新功能，其实手机下面只插着一块小小的ESP32-S3开发板。

最近看到的开源项目esp32-iphone-agent，干的就是这件事。手机不用越狱，不用安装配套App，也不用先买一台Mac。板子的成本，按项目介绍，大约四五十元。

我是做嵌入式的，看这类东西，先关心的不是AI有多聪明，而是它的“手”到底怎么接上去。模型说得再明白，最后那一下点不到屏幕上，事情还是办不成。

不走测试框架，先做一只鼠标

过去做iPhone界面自动化，常见路线是XCTest和WebDriverAgent。需要构建、签名并安装测试用的runner，通常离不开Mac和Xcode。免费开发签名还涉及短期有效期，长期运行需要继续处理维护问题。

这条路不是不好。测试框架能提供更丰富的界面信息，也有自己的工程优势。只是对于想拿现成手机做个小实验的人，准备工作实在不少。

这个项目换了个入口：不在手机里安装一个负责点击的软件，而是在手机外面接一只负责点击的“鼠标”。

ESP32-S3通过原生USB接口，把自己呈现为鼠标和键盘。iPhone开启辅助触控后，屏幕上出现指针，点击可以触发轻点，按住拖动可以做滑动。USB-C机型可以直接连接；Lightning机型还需要合适的相机转接器。它省掉的是手机上的应用安装和签名，不是所有硬件准备。

板子经Wi-Fi接收电脑发来的移动、点击、滚动和输入命令。任务怎么拆、点哪里、下一步怎么办，主要都由电脑端决定。板子只负责把动作送出去。

这个分工我挺喜欢。改模型、改规划策略，通常不必重新烧录固件。硬件把接口做好，软件去折腾自己的逻辑，谁也别把谁拖得太重。

手机能接收点击，不代表AI知道该点哪里。

项目用AirPlay屏幕镜像，把iPhone的画面送到电脑上的UxPlay接收端，再通过GStreamer处理成图像帧，交给视觉模型判断。手机端不用装额外的截图应用，但仍然要手动开启镜像，电脑和手机也要处在可互通的网络环境里。

于是，一套很直白的分工就出来了：镜像负责看，USB HID负责动，电脑上的模型负责想。

注意，50元板子不是在本地运行大模型，它只是在替模型执行输入动作。 电脑、手机和推理服务，都在这块板子的价格之外。

模型又分成两个角色。一个负责根据任务和当前画面写计划，另一个盯着新截图执行下一步动作。可以用同一个模型，也可以分别配置；接口兼容还不够，模型本身必须能处理图像。

“设一个每天7点响的闹钟”，不是一次点击。要找到时钟，进入闹钟页，修改时间，选重复日期，再保存。每一个动作之后，眼前的界面都可能变。

AI是不是会说“已经完成”，不重要。闹钟是不是真的保存了，才重要。

USB鼠标常用相对位移。发一个“向右移动多少”，并不等于指针就到了某个绝对坐标。指针加速度、跟踪速度和前一次的位置误差，都可能影响下一步。

人点偏了会看见，也会补一下。机器如果只相信自己发出去的命令，就可能在错误界面上继续执行后面的计划。

项目为此加入了指针定位和校准：点击流程中通过小幅移动指针，在镜像画面里寻找它，再修正位置；动作后检查画面是否变化，把结果反馈给模型。连续重复无效动作时，还会触发重新规划。

这不是说它已经保证每次都点得准。画面变了，也未必就是目标达成；画面没变，有时只是动画或加载还没结束。反馈能减少盲操作，却不能把“发生变化”直接当成“执行正确”。

不过，方向是对的。做控制系统的人都明白，发出指令和执行成功，是两回事。看得见结果、发现错误、能够停下来修正，才算把闭环补上。

固件也考虑了断线后的动作释放、重连和看门狗。它们不如“AI自动操作手机”那么容易做标题，却决定了设备出问题时，会不会一直按着一个键不松手。

类似方案也可以走蓝牙HID，把板子变成无线鼠标。桌面上少一根线，确实清爽。

但无线还要处理配对、重连以及射频共存。有线USB省掉了蓝牙配对，输入链路也更直接，手机还能给板子供电。代价是占用接口；想一边运行一边充电，还需要支持供电透传的合适扩展设备。

不能因为用了USB，就断言整套系统一定比蓝牙快。画面仍然通过网络传输，命令仍然经过Wi-Fi，模型推理也要时间。它减少的是一个输入链路的不确定因素，不是把整个系统变成了有线系统。

在这种一步接一步的任务里，我更看重可预测。少一点摆放上的优雅，换一个更容易检查的连接关系，是很正常的工程取舍。

原稿里最容易让人误会的，是“1.3秒一步”。项目给出的测试条件，是在两台NVIDIA DGX Spark上运行本地视觉模型，关闭思考模式，动作阶段约1.3秒、规划阶段约2秒。这不是我做的实测，也不是随便一台电脑都能复制的成绩。

走云端接口，不必自己买那套推理硬件，但每次截图、推理和重新规划都会计入使用成本，还要考虑网络延迟。一个任务走几十步，反复失败再重来，成本就得按整条任务链算。

还有几道现实的边界：目前主要按竖屏设计，键盘输入只支持ASCII，中文输入仍在计划里；锁屏会中断镜像，一些受保护界面也不会完整参与镜像。接得上鼠标，不等于拿到了手机里所有界面的控制能力。

屏幕截图送给云端模型时，通知、聊天内容和账号信息也可能一起出去。实验最好用自己的测试设备和账号，先从画图、设置闹钟这类低风险任务开始。支付、发消息和删除数据，不能只凭模型一句“我知道了”就放手，人工确认和急停要留着。

项目采用MIT许可，但允许商用不等于无需保留许可声明，也不等于可以无视应用服务的使用规则。开源给的是代码使用条件，不是所有场景的通行证。

我觉得这类项目对嵌入式工程师的启发，并不是“又有一种办法控制iPhone”。更值得看的，是把一个很大的问题，拆成了几个已经存在的小接口：投屏、鼠标、键盘，再加上能检查结果的决策循环。

便宜硬件可以替AI接上手，但真正决定这只手能不能放心用的，是反馈、权限和出错以后能不能停下来。