没有安卓经验，如何用 GPT-5.6 和 ChatGPT Codex 做出一款局域网监控 App

做IdleCam这个APP的起因其实很简单。孩子上网课时经常会走神，我想拿家里闲置的旧手机放在旁边看一看。去应用商店找过类似产品，发现不少评价并不好：有的广告很多，有的关键功能要收费，还有的总让人担心画面会不会传到云端。

6月份claude code fable 5出来后叫好声一片，最近GPT-5.6也出来了，并且Codex直接升级成了ChatGPT，模型号称直接对标fable5，于是就有了利用GPT-5.6自己做一个的念头：一台旧手机做 Camera，另一台手机做 Manager；画面和声音只在局域网里跑，视频也尽量留在手机本地。最终做出来的 IdleCam 能提供摄像头预览、局域网直播、历史视频、截图和本地同步等功能。

我没有 Android 开发经验。这篇文章记录的是一次很朴素的尝试：借助 GPT-5.6 和 ChatGPT Codex，从需求设计、环境搭建开始，连上真机，一边写一边测，最后把它做成能装到手机上的 App。过程并不轻松，黑屏、权限、录像和不同手机的兼容性问题，一个也没少。

一、没有 Android 经验，从哪里开始

传统 Android 开发通常需要先掌握 Java/Kotlin、Gradle、Android Studio、Activity 生命周期、权限模型、前台服务、MediaCodec 和设备兼容性。对一个没有 Android 背景的人来说，最容易卡住的不是某一行代码，而是不知道应该从哪里开始。

这次开发里，我把 GPT-5.6 当成随时可以讨论方案、解释概念的搭档；ChatGPT Codex 则更像一个能真正进仓库干活的开发伙伴：读代码、改文件、跑命令、编译 APK、把 APK 装到手机上。

对我来说，最大的变化是不用先把自己变成 Android 专家。只要把用户做了什么、看到了什么、希望它变成什么样说清楚，AI 通常能把问题拆成代码、权限、服务或设备兼容性等具体方向。

二、先写 spec，再开始编码

我没有一上来就让 Codex“直接做一个监控 App”，而是先让 GPT 整理需求文档。spec 中明确了 Camera Mode、Manager Mode、PIN、RTSP、录像切片、存储清理、权限、语言和隐私等边界。这里有些技术方案比如RTSP一开始我并不了解，也是GPT整理出来的技术方案。

其中有一些决定后来影响很大：

• Camera 提供直播，录像保存则由独立开关控制；新安装版本默认先不保存视频，用户确认角度后再开启本地保存。
• Manager 的“保存到本机”是把 Camera 已完成的视频片段下载到 Manager 手机，而不是让 Manager 录制屏幕。
• RTSP 只负责直播，录像列表、控制、下载和删除由独立的 HTTP API 完成。
• 录像按日期目录保存，空间不足时按修改时间优先删除最旧文件，并至少保留两个完整片段。

需求先结构化的价值在于，后续每次修改都有上下文可追溯。缺点是 spec 不可能一次覆盖所有真实交互，测试阶段仍然需要大量调整。

三、让 Codex 先把开发环境准备好

开始时，电脑甚至没有完整的 Android 开发环境。Codex 根据项目需要检查并安装了 JDK、Gradle、Android SDK、platform-tools 和 build-tools，还处理了 Android SDK license 和离线 Gradle 缓存。

这一步很省心。以前得自己搜索“Android 开发环境怎么装、版本怎么配、环境变量怎么设”；现在可以让 Codex 先检查缺什么，再解释为什么要装，最后跑一遍构建确认环境真的可用。

我的做法是让 Codex 每次都说清三件事：当前环境缺什么、接下来命令会改什么、怎么判断成功。这样即使不熟悉 Android 工具链，也不会完全失去控制感。

四、从最小可运行版本开始

第一阶段没有追求漂亮界面，而是先打通一条最小链路：

Camera 手机打开摄像头
        ↓
Camera 端启动 RTSP 服务
        ↓
Manager 手机发现或输入 Camera IP
        ↓
输入 PIN 后播放实时视频

链路打通后，再逐步加入录像切片、音频、暂停和恢复、历史文件列表、下载、截图、前后摄像头切换、语言切换、电量显示等。

这种拆分很重要。一次性加入所有功能时，任何一个黑屏或连接失败都可能有多个原因；先建立最小闭环，后续每个功能都可以单独验证。

五、USB 真机连接让开发进入“可验证”阶段

模拟器无法完整代表真实设备的摄像头、硬件编码器和后台策略。实际开发中，我把手机通过 USB 连接电脑，打开 USB 调试、USB 安装，并在 ADB 设备列表中确认手机已经连接。其实这也是GPT主动要求进行真机测试的：

之后 Codex 可以直接完成：

• 编译 Debug 或 Release APK；
• 通过 ADB 安装或覆盖安装；
• 启动 App、读取设备型号和系统日志；
• 检查是否崩溃、是否存在权限异常；
• 在必要时读取截图或当前终端输出。

这一步让我第一次觉得它不只是“会写代码”。代码改完不是停在编辑器里，而是真的能装到手边的手机上跑起来。

六、真实测试暴露出的 Android 问题

1. 预览黑屏

最早遇到的典型问题是：GPT报告自测已经成功，但真机测试时录像服务在运行，但 Camera 端预览是黑屏。后来让GPT排查后GPT得出结论：后台录像使用的摄像头输出和 Activity 中用于预览的 Surface 生命周期并不总是同步，锁屏、切换桌面、从设置页返回，都可能让 Surface 被销毁并重新创建。我当然不懂这些，让GPT自己给出解决方案，调整后GPT自己部署并且进行了截屏验证，从调整到修复二十分钟左右，还是比较让人省心的。

2. 不同手机的硬件解码差异

GPT编程对于硬件适配也并不能一次到位，比如同一条 RTSP 流在小米 6、小米 10 和更新的小米设备上的表现并不完全相同。一开始使用的设备硬件解码比较稳定，但换了新设备就出现花屏、缓冲或 Surface 分配失败。

因此 Manager 端加入了按设备情况选择软件解码器的兼容策略，并对播放器失败进行释放、延迟重建和重新连接。Android 支持某个 API，不等于所有厂商设备都以相同方式实现它。

总结：再强的AI写出来的代码也得在真机上验证一下。

3. 需求变更

开发过程中增加了一个需求点，要求增加一个旋转按钮可以旋转摄像头展示的视频。但是GPT认为开发完成后真机测试发现点击后没有效果，这有点让我诧异。马上让GPT进行分析，原来最初点击旋转按钮后，只调用了 SurfaceView 的 setRotation()。按钮角度变化了，但实际视频图层没有旋转。原因是 SurfaceView 的视频 Surface 由独立的 Surface 图层管理，普通 View 变换不一定会作用到实际画面。

后来GPT改成：0° 时使用兼容性更好的 SurfaceView；旋转到 90°、180° 或 270° 时，切换到支持变换的 TextureView，并重新计算显示区域。这个例子说明，看到“代码执行成功”并不代表用户看到的图像真的改变了，GPT对于这种交互方面的自我验证还不够强大。

七、用 GPT-5.6 和 Codex 工作时，什么提示方式更有效

1. 给目标和边界，不要只给一句“修一下”

比较有效的描述方式是：

现象：Manager 点击暂停后，切换 Camera 镜头，状态又显示运行中。
期望：暂停状态在切换镜头后仍保持暂停，Camera 实际编码状态不应被误报。
约束：不改变录像文件格式，不影响正常恢复录像。
请先定位状态来源，再修改并编译验证。

2. 让 Codex 先读代码再改

可以这样要求：

先搜索相关字符串、接口和生命周期回调，说明你认为的根因；
确认后再修改最小范围的文件；
修改后运行 Debug 构建，并报告测试结果。

这比直接要求“重写整个页面”更容易保持已有功能。

3. 把真机日志和截图作为上下文

截图适合验证布局、黑屏、按钮是否被遮挡、画面比例和文字是否截断。日志适合定位崩溃、权限和解码器问题。两者结合后，AI 不只是根据代码猜测，而是能看到真实结果。

八、AI 测试的效率和边界

Codex 可以自己通过 ADB 安装 APK、运行命令、读取日志，有时也会通过截图检查界面。这种自动验证非常方便，但也有明显代价：截图、日志和多轮交互会消耗较多 token，开发期间我多次遇到 Codex 的 5 小时使用限额。

后来形成了几个习惯：

• 把多个只读检查合并成一次命令；
• 先用代码和日志缩小问题范围，再请求截图；
• 小改动先编译，多个相关小改动再一起安装真机；
• 每轮测试明确列出要验证的 case，避免无目的地反复截图。

AI 的自动测试 case 通常比人工真实使用场景少。除非明确要求，它不会自然地覆盖所有返回路径、锁屏、切后台、权限拒绝、重复点击、不同屏幕尺寸和不同设备解码器。因此，人工测试仍然不可替代。

这次开发期间，黑屏、录像写入失败、权限后跳后台、语言返回不生效、目录日期重复、不同设备解码差异等问题，都是在人工操作或真实手机上才更容易发现的。

九、需求不断变化并不是失败

开发过程中，需求从最初的录像和直播，逐步增加了多语言、帮助文档、电量显示、按钮文案、视频旋转。测试时还会提出“这个按钮文案是否更易懂”等交互问题。

需求反复改时，和 AI 协作确实轻松一些：它不会因为“昨天刚改过、今天又要改”就不耐烦。不过产品判断还是人的事。每次变化都得想清楚：它解决什么问题，会不会影响已有行为，怎么验收，要不要同步更新帮助文档和版本号。

十、给没有 Android 经验读者的实践建议

如果你也没有 Android 开发经验，可以按下面的顺序开始：

1. 先让 GPT 把想法整理成 spec，包括角色、状态、数据流、权限、存储和验收条件。
2. 让 Codex 检查环境并创建最小可运行工程，不要一开始就实现全部功能。
3. 尽早连接一台真实手机，建立“修改—编译—安装—验证”的循环。
4. 每次只处理一类问题，例如先解决连接，再解决预览，再解决录像。
5. 遇到错误时提供完整错误文本、复现步骤和期望结果。
6. 要求 AI 修改后运行构建、检查 diff，并说明没有覆盖哪些测试场景。
7. 最终一定由人工在目标品牌和目标系统版本上完成完整操作测试。

总结

回头看这次 IdleCam 开发，GPT-5.6 和 ChatGPT Codex 确实不只是“帮忙补几行代码”。从需求拆解、环境搭建，到改代码、跑终端、装真机、看日志，它们都参与进来了。甚至APP的图标都是GPT帮忙生成的。

但它没有替我省掉软件工程本身。没有 Android 经验的人，确实可以做出能运行的应用；只是责任还在自己身上：权限、兼容性、测试范围和发布质量，都得一项项确认。

我现在更愿意把分工理解成：AI 把执行能力放大，人负责把问题讲明白、把结果看仔细、在关键地方作判断。一个可靠的 App 不是靠一条完美提示词生成的，而是在真实设备、真实操作和一次次修正里慢慢长出来的。

最后分享一下app的运行截图，如果读者有兴趣也可以通过这个链接下载体验：https://download.winroad.net/