用代码真的能接管 iPhone？聊聊这个一周涨一千多星的 USB 自动化项目
一个 Python 项目，让你接上数据线就能让 Codex 操控真机：装 App、抓屏幕、点界面、回退截图。它不是演示玩具，但也不是万能遥控器。
适合：需要在真机上做机械性 iPhone 自动化、又想压低门槛的开发者与测试人员。
先说结论
iPhone 不开放系统级的自动化接口，这条线一直是堵的。zhongerxin/iPhone-use 这个仓库做的事情很直接：用一条 USB 数据线，让运行在本地的 Codex 直接指挥你的真机。一周时间在 GitHub 上拿下 1700 多颗星，说明这个方向踩中了很多人的痛点。它不是演示玩具，但也别把它当成万能遥控器，更合适的用法是先拿来做装包、截屏、回归这种机械活。
真正的问题
真要驱动 iPhone，你会发现选择并不多。云测平台按设备收费，本地工具链要么依赖 macOS，要么只敢做截图。开发者想自动化点击、安装、跨 App 跳转，常常得自己拼 idb、appium、WebDriverAgent，再硬扛签名和版本兼容。这个项目把 OpenAI 刚发布的 Codex CLI 装到了那条链路上：本地推理做计划，Python 脚本负责发指令，截图再回传给模型判断下一步。
它的关键卖点是把引导流程做得比较平。第一次跑会自动拉 WebDriverAgent、装驱动应用、问你信任证书，照着终端提示敲回车就行。等装好之后，重连设备基本就是即插即用。日常看到的无非三件事：安装或启动 App、按照自然语言指令点界面、每一步都把屏幕画面带回去当上下文。
怎么做更省力
如果决定拿它来干活，建议按场景拆开看。下表是几种常见任务和这条链路比较合得来的部分：
| 任务类型 | 用 iPhone-use 的体感 | 替代方案 |
|---|---|---|
| 安装新 App 并核对启动页 | 很快，截图回传直接比对 | TestFlight 手动流程 |
| 固定路径的 UI 回归 | 稳定，可重复 | appium + 真机 farm |
| 跨 App 数据搬运 | 能跑，但要分多个 prompt | Shortcuts 自动化 |
| 即时交互测试 | 延迟明显，需要等待模型返回 | 人工或 Selenium 替代 |
把它当一个会听指挥的测试员更准确。给的任务越具体，比如「打开设置—通用—VPN，告诉我当前状态」，它越像样。要是让它「自己想想怎么登录微信」，基本会陷进循环里。
想顺手把这种任务写成可复用的脚本，可以先把每一步的自然语言操作整理清楚，再放到 Markdown 里维护。这种结构化的长稿完全可以交给 Markdown 智能编辑器 整理成带目录、带代码块的版本，比丢在备忘录用起来稳得多。
哪些坑要避开
几个边界要先看明白再动手。第一，设备必须保持解锁状态，锁屏或者被自动锁都会断流，自动化中途切走会被打断。第二，每次执行前它会弹权限申请，越狱设备或被风控的账号，建议先用备用机跑通流程，别拿主力机做实验。第三，截图回传意味着流量并不小，连续跑十分钟很容易吃掉好几百兆，公共网络下要小心。
还有一个容易被忽略的点：模型会真的去点屏幕。脚本里一旦写错条件，可能出现狂点支付按钮、反复拨号的场景，提前加一个 kill 开关，留好中断快捷键，比出事再后悔强。
现在就能动手
最稳的起步方式是准备一台空闲 iPhone、一根原厂数据线、一台装好 Python 3.10 以上和 Node 18 以上的电脑。然后在终端里克隆仓库，按提示装一次 WebDriverAgent，再用项目自带的「打开 Safari 并读取首屏标题」任务做冒烟测试。能跑通，再把日常想偷懒的步骤换成自然语言指令；如果跑不通，先回去检查驱动签名和开发者证书，不要急着改任务描述。
把它当一位耐心的实习生，而不是一个会自己思考的同事，你大概率能用得很舒服。