macOS 用户连安卓手机，到底有多惨？我让 AI 写了个软件试了试
iPhone 用户插上 Mac，AirDrop 秒传照片，Finder 直接管理文件，macOS Sequoia 甚至能镜像操作手机。安卓用户插上 Mac——弹出一个 2012 年更新的黄色图标，告诉你「请重试」。
这不是段子。
Google 官方那个 Android File Transfer，在 2026 年依然是你唯一的选择（除了第三方付费软件）。打开之后如果手机里文件夹超过 30 个，它大概率闪退。文件名里带中文？乱码。想传一个 2GB 的视频？进度条走到一半挂掉，从头再来。
我用了十年安卓，换了五部手机，这个问题忍了十年。
今年年初想学 SwiftUI，决定拿这个当练手项目。但我不会写 macOS App——我之前的编程经验停留在 Windows Server 2003 时代的批处理和交换机配置。好在 2026 年有个东西叫 AI。
让 AI 写软件：三行命令起步
我打开 Claude，输入了第一行需求：「用 SwiftUI 写一个 macOS App，通过 ADB 连接安卓手机，列出 /sdcard/ 下的所有文件。」
Claude 给了我 80 行代码。我粘贴到 Xcode，Run——居然没报错。窗口弹出来，左侧是文件夹树，右侧是文件列表。连上我的小米 15，文件真的显示出来了。
那是 v1.0。本质上就是个 adb shell ls 的图形包装器，但就这么个东西，用起来比 Android File Transfer 爽了不止一点——至少不会闪退。
然后就停不下来了。每遇到一个痛点就让 AI 帮我加功能。
v1.0 → v1.3（一周内）：Claude 帮我写了一个文件操作类，把 adb 的所有命令（push/pull/mkdir/rm/mv）封装进去。我能复制粘贴了，能新建文件夹了。还做了个设备列表——插上手机自动识别品牌和型号，不依赖手机端 App。
v2.0（两周后）：重写了整个 UI。之前那个界面是我自己手画的（丑到不好意思截图），Claude 说「你用 List 和 NavigationSplitView 重构」。重构完的感觉很奇妙——一个不会 SwiftUI 的人，靠 AI 翻译需求，做出了一个像 macOS 原生应用的界面。左侧文件夹树、右侧文件列表、工具栏按钮全部中文标签。这时候已经有 1500 行代码了。
v3.0（一个月后）：加了无线连接。在同一个 WiFi 下点一下「启用无线调试」，以后就不用插线了。这个功能是 Claude 建议的——我说每次插线很烦，它说「你做一个无线 ADB 开关，连一次以后就自动连」。批量重命名也是这个阶段加的，四种模式（序号、查找替换、前缀后缀、正则），因为我手机里有一千多张照片全是 IMG_xxxx 格式。
v4.0（两个月后）：这是最大的版本跳跃。三个新模块：
- 屏幕镜像。这个不是我提的需求——是我在论坛看到有人问「Mac 能不能像 iPhone 镜像一样看安卓屏幕」。我查了一下，发现 scrcpy 能做到。Claude 帮我写了 scrcpy 的启动逻辑和 Mac 端的窗口管理。现在点一下工具栏按钮，手机画面实时显示在 Mac 上一个独立窗口里，鼠标可以点，键盘可以打字。支持的小米/华为/OPPO/vivo/三星等四十多个品牌，延迟 40-60ms。
- APK 批量备份。来自我自己换手机时的真实需求——想把老手机上的 app 全部备份到电脑上。以前没这个功能，一个 app 一个 app 折腾。现在弹个窗默认全选，一键备份到
~/Downloads/。 - 设备信息面板。电量、温度、存储环形图、系统版本、内核版本。这其实是开发过程中顺手加的——我在修一个 bug 时需要知道手机的 Android 版本和 SDK 级别，每次都去翻设置太烦了。一个面板显示所有关键信息。
代码量曲线：
- v1：80 行，一个人工编写的 shell 包装器
- v2：1500 行，Claude 重构后的 SwiftUI App
- v3：3500 行，无线连接 + 批量操作
- v4：6500 行，屏幕镜像 + 备份 + 设备信息
34 个单元测试全部通过，CI 已经上了 GitHub Actions（每次 push 自动编译 + 测试）。
AI 写软件的真实体验
我先说结论：AI 不会取代程序员，但会让有想法但不会写代码的人做出能用的东西。
我做这件事的过程中，Claude 写了大约 70% 的代码。但真正关键的是那 30%——我和 AI 都搞不定的部分，必须靠调试和搜索解决。举三个例子：
坑一：adb shell ls 格式不统一。 不同品牌的安卓手机，ls -la 的输出格式不一样。小米用的是 toybox 的 ISO 日期（2026-06-16 14:30），三星是另一个格式，OPPO 又不一样。Claude 写的第一版解析器只能处理一种格式，换手机就崩。我最后手动写了四种解析策略，按特征判断手机品牌再做格式匹配。这个问题花了我整整一个下午。
坑二：scrcpy 键盘输入。 v4 加屏幕镜像时，鼠标操控一切正常，但键盘打不出字。Claude 反复检查代码都觉得没问题。最后在小米官方文档角落里发现一句：「需要勾选 USB 调试（安全设置）」。一个复选框，卡了三个小时。
坑三：Android 16 封杀了 content query。 我本来想做通话记录查看功能，但 Android 16 把 ADB 的 content query 命令移除了。网上所有方案（content call、直读数据库、run-as）都试了一遍，全部被 SecurityException 拦截。这个功能从 v4 计划里砍掉了。
这三件事 AI 都帮不了——需要查官方文档、看源码、读 Android 安全策略。AI 擅长的是「把需求翻译成代码」，但「代码为什么在真机上不工作」它不知道。
为什么不用 Electron，为什么不做手机端 App
两个最常见的质疑。
Electron？ 能做。但 Mac 用户对「原生感」很敏感。菜单栏交互、快捷键行为、窗口管理——Electron App 永远隔着一层。而且这个项目的核心是调用 ADB（一个命令行工具），不需要跨平台渲染。SwiftUI 的 Process API 直接调 adb 二进制，比 Electron 的 Node 子进程快。
配套手机 App？ 很多同类工具要求你在手机上装一个 App。我没做——因为我自己都不想装。整个工具完全通过 ADB 工作，手机端零安装、零权限申请。代价是某些功能受限（比如前面说的通话记录），但换来了零摩擦的使用体验。插线就能用。
现在你能用上
项目 MIT 开源。不需要手机装任何 App、不需要 root、不需要除了数据线之外的任何东西。需要 macOS 14+、Apple Silicon。
GitHub：github.com/wordwu/android-file-manager 下载：Releases 页面，DMG 直接拖 Applications。
如果你也在忍受 Android File Transfer，试试这个。如果遇到 bug，在 GitHub Issues 告诉我——我自己也是用户，修起来快。