夜雨聆风我最近用 Codex 写了一个很小的本地工具。
它的名字叫「安卓扫描器」，但本质上是一个 ADB 文件管理器：手机插到电脑上以后，我可以在电脑端查看手机目录，上传文件，导出文件，扫媒体库，预览图片和视频，也可以做截图、录屏。
这个工具不是为了发布给所有人用，也不是为了做成一个完整产品。它只是解决我自己的一个问题：手机和电脑之间传文件太碎了。
以前我经常遇到这种情况：手机上截了图、录了屏、下载了文件，后面要拿到电脑上整理。偶尔一两次还好，多了以后就会在微信文件助手、网盘、数据线、命令行之间来回切。做 Android 调试时更麻烦，想拿应用缓存、数据库、日志文件，还要回到 adb pull、adb shell、run-as 这些命令。
我不想每次都记命令，也不想为了一个文件在几个工具之间切换。所以我干脆让 Codex 帮我把这套流程做成了一个桌面 App。
这个工具长什么样
先看最基础的界面。
左边是设备和常用目录，右边是当前手机目录。连接手机并开启 USB 调试以后，就可以直接刷新设备、进入 /sdcard、/sdcard/Download、/sdcard/DCIM 这些常用路径。
我给它留了几个最常用的动作：
• 上传，把电脑文件传到手机当前目录。 • 导出，把手机文件保存到电脑。 • 删除，只允许删单个文件，不直接删文件夹。 • 截图和录屏，把手机画面采集到电脑。
我没有一上来就做无线局域网传输。对我这个场景来说，ADB 更直接，也更稳定。手机调试本来就要接电脑，文件管理、截图、录屏、应用数据导出都能走同一条链路。
我真正想解决的不是“传文件”
如果只是传一个文件，随便什么工具都能做。
我真正想解决的是：手机上的几类文件太分散了。
第一类是共享存储，比如下载目录、相册目录、视频目录。它们一般在 /sdcard 下面，普通文件管理器也能看到。
第二类是媒体库，比如图片、视频、音频、APK、压缩包。它们不一定都在一个目录里，但 Android 系统会把它们登记到 MediaStore 里。对我来说，按文件名、路径、MIME 类型搜索，比一层层翻目录快很多。
第三类是应用数据。调试自己的 Android 应用时，我可能要看某个包下面的缓存、配置、数据库或临时文件。这类数据通常在应用内部目录里，普通文件管理器看不到。我的工具里单独做了「应用数据」模式。
媒体库这一页，是我后来补上的。它不要求我先知道文件在哪个目录，而是先把手机里可访问的媒体文件扫出来，再按图片、视频、音频、压缩包、APK 分类筛选。对我这种经常从手机里找截图、视频和下载文件的人来说，这比一层层翻目录更省事。
这里有一个限制要说清楚：应用数据不是想看就能看。这个工具通过 run-as 访问应用内部目录，所以只适合 debuggable 应用。正式包、不可调试应用、没有权限的目录，都不应该强行访问。
这也是我喜欢把这种工具做成本地小工具的原因。它不需要绕规则，只服务我自己的开发和整理流程。
我是怎么让 Codex 帮我做的
我写这个工具时，没有把需求一次性丢给 Codex，让它“帮我做一个 App”。
我一般是按功能一块一块来。
第一步，只做设备和共享存储。
我先让它用 Electron + React 搭一个桌面界面，再把 ADB 的设备列表、目录读取、上传、导出这些能力接进去。这个阶段只要能看到设备、能进目录、能导入导出，就算完成。
第二步，补应用数据。
共享存储解决的是普通文件，应用数据解决的是开发调试。我让 Codex 加一个模式切换：共享存储、应用数据、媒体库。应用数据这一块用 pm list packages -3 列出第三方应用，再用 run-as 检测包名是否可访问。能访问就列目录，不能访问就给出原因。
第三步，补媒体库扫描。
我不想只靠目录浏览，因为手机相册、视频、下载文件散在不同路径里。于是又加了 MediaStore 查询，按图片、视频、音频、压缩包、APK 分类，再做搜索、排序和批量导出。
第四步，补预览。
只看到文件名还不够，图片和视频最好能点一下就预览。所以工具会把文件先拉到电脑本地缓存，再用内置预览打开。图片、视频、音频、PDF、文本类文件都能处理一部分，大文件和不支持的格式就提示导出后用系统应用打开。
第五步，补截图和录屏。
截图走 adb exec-out screencap -p。录屏优先用 scrcpy 的无窗口录制，没有 scrcpy 时再走 ADB 自带的 screenrecord。这样我在做手机操作记录、教程素材、Bug 复现时，不用再单独开一堆命令。
整个过程里，Codex 最有用的地方不是“自动写完所有代码”，而是帮我把每个小功能接上、跑通、再根据截图和报错继续修。
我会怎么跟 Codex 描述需求
如果你也想用 Codex 做这类工具，不建议一上来写很大的需求。
我会这样说：
我想做一个本地 Electron 工具，用来管理 Android 手机文件。第一阶段只做共享存储：1. 左侧列出 adb devices。2. 右侧显示 /sdcard 目录。3. 支持进入文件夹、返回上级、上传文件、导出文件。4. 不做删除目录，只允许删除单个文件。5. 每次修改后运行 typecheck。这类提示有几个好处。
边界很清楚，Codex 不会一开始就发散到登录、云同步、移动端 App、账号系统。验收标准也很清楚，最后能不能列设备、能不能打开目录、能不能上传导出，一试就知道。
等第一版跑通后，再继续加功能：应用数据、媒体库、预览缓存、截图录屏。每次只改一层，出问题也容易定位。
这个项目让我更确定一件事
Codex 很适合做贴着自己工作流的小工具。
很多人用 AI 写代码，会盯着“大项目”：做一个 SaaS，做一个完整 App，做一个自动化平台。其实我现在更喜欢从很小的地方开始。
比如这个安卓扫描器，功能看起来不复杂，但它解决的是我每天可能遇到的真实问题：手机里的截图、视频、文件、应用数据，怎么更快到电脑上处理。
它也不是纯命令行工具。命令行适合我自己用，但图形界面对后续迭代更友好。以后我想加搜索、预览、批量操作、导出记录、素材归档，都有界面可以承载。
普通人怎么借鉴这个思路
这篇不是让你也去写一个 ADB 文件管理器。
更值得借鉴的是这套拆法：
1. 找一个你真的会反复做的动作。 2. 不要一开始做大系统，先做最小闭环。 3. 把需求写成 Codex 能验收的步骤。 4. 每次只让它改一个功能点。 5. 用截图、报错、实际操作结果继续迭代。
如果一个动作你一个月只做一次，可能不值得工具化。
但如果你每周都在重复做：整理文件、处理截图、导出素材、同步数据、批量改名、上传商品、剪视频、整理文章，那就可以考虑让 Codex 帮你写一个自己的小工具。
对我来说，AI 提效不是每天问它几十个问题，而是把自己的重复工作一点点变少。
这个安卓扫描器就是一个例子。它没有多炫，但我自己会用，这就够了。
