起因
手头有十几台 Android 测试机，之前一直用 Python + PyQt5 写的群控工具凑合着用。界面丑、响应慢、截屏卡顿，PyQt5 在 macOS 上的兼容性也越来越差。一直想重写但没时间。
上周试着让 AI（Claude）帮我重写，结果从架构设计到完整可用，一个下午全部搞定。
成品效果
Phone Control------ 一个现代化的 Android 多设备群控桌面应用：
-
实时截屏预览，10+ 台设备同时刷新不卡顿
-
批量点击、滑动、输入文本、发送按键
-
一键 scrcpy 投屏，支持远程 ADB 服务器
-
内置 ADB Shell，对选中设备批量执行命令
-
分页浏览、设备筛选、FPS 调节
-
深色主题，原生桌面体验
技术栈：Rust + Tauri 2 + React + TypeScript。打包后的 app 只有 10MB 左右，内存占用是 Electron 方案的 1/5。
AI 做了什么
整个项目100% 由 AI 编写，包括：
后端（Rust）
-
ADB 设备发现与轮询机制
-
多服务器管理与配置持久化
-
异步截屏循环（PNG 解码 → 缩放 → JPEG 压缩）
-
坐标缩放算法（不同分辨率设备自动适配）
-
scrcpy 启动集成（本地/远程 ADB 服务器）
-
10 个单元测试
前端（React + TypeScript）
-
Zustand 状态管理
-
Tauri IPC 事件监听
-
设备卡片网格（React.memo 优化）
-
分页逻辑 + 自动预览管理
-
Text/Shell 双模式工具栏
-
完整的 CSS Modules 深色主题
工程化
-
Tauri 2 项目脚手架
-
GitHub Actions CI（macOS + Windows 自动构建）
-
README 文档
开发过程
整个过程就是不断对话：
-
我描述需求 → AI 出架构方案
-
我确认方案 → AI 写代码、跑编译、修 bug
-
我截图反馈 → AI 看截图定位问题、修复
-
我提新需求 → AI 增量开发、重新打包
几个印象深刻的瞬间：
-
我说"远程 ADB 的 scrcpy 连不上"，AI 直接知道要设置
ADB_SERVER_SOCKET环境变量和--tunnel-host参数 -
我说"用久了会白屏"，AI 分析出是截屏数据太大导致 WebView 内存溢出，改成 JPEG 压缩 + 缩放，数据量降低了 30-50 倍
-
我说"打包后找不到设备"，AI 知道是 macOS app bundle 不继承终端 PATH，自动补了常见路径
没有手写一行代码。我的工作就是提需求、测试、反馈。
值得注意的技术决策
这些都是 AI 自己做的，不是我指定的：
|----------------------------|----------------------------|
| 决策 | 原因 |
| 截屏用异步 tokio::process 而不是同步 | 10 台设备并发不阻塞线程池 |
| PNG → JPEG 压缩在 Rust 端做 | 减少 IPC 传输量，防止 WebView 内存泄漏 |
| 选中状态只存前端 Zustand | 减少 IPC 通信，serials 按需传给后端 |
| DeviceCard 用 React.memo | 截屏更新只重渲染对应卡片 |
| 分页时自动管理 preview 生命周期 | 切页停旧的、启新的，不浪费资源 |
和之前 Python 版本对比
|--------------|-----------------------|--------------|
| 指标 | Python + PyQt5 | Rust + Tauri |
| 安装包大小 | ~150MB（含 Python 运行时） | ~10MB |
| 内存占用（10 台设备） | ~800MB | ~150MB |
| 截屏延迟 | 明显卡顿 | 流畅 |
| 跨平台 | 需要分别打包，兼容性差 | 一套代码，CI 自动构建 |
| 开发耗时 | 两周 | 一个下午 |
| UI 美观度 | 原生 Qt 风格 | 现代深色主题 |
开源
项目已开源，MIT 协议：
-
支持 macOS / Windows
-
开箱即用，只需要安装 ADB
-
详细的 README 和架构说明
如果你也有多设备管理的需求，欢迎试用。
github: https://github.com/0pen1/PhoneControl
这篇文章也是 AI 写的。