我想做一款利用手机来做监控的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 背景的人来说可能完全不知道应该从哪里开始。但好在我虽然没有安卓开发经验但还是很多年的后端开发经验并且AI编程也用了很久了。这次开发里我把 GPT-5.6 当成随时可以讨论方案、解释概念的搭档ChatGPT Codex 则更像一个能真正进仓库干活的开发伙伴读代码、改文件、跑命令、编译 APK、把 APK 装到手机上。对我来说最大的变化是不用把自己变成 Android 专家而是一个产品经理、一个需求方。只要把用户做了什么、看到了什么、希望它变成什么样说清楚AI 通常能把问题拆成代码、权限、服务或设备兼容性等具体方向。二、先写 spec再开始编码我没有一上来就让 Codex“直接做一个监控 App”而是先让 GPT 整理需求文档。需求spec也是我通过会话的方式告诉GPT然后GPT整理完善的。最后的spec 明确了 Camera Mode、Manager Mode、PIN、RTSP、录像切片、存储清理、权限、语言和隐私等边界。这里有些技术方案比如RTSP一开始我并不了解也是GPT整理出来的技术方案。到最后还让GPT进行了review确认是否还需要进一步澄清和完善。其中有一些决定后来影响很大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 工具链也不会完全失去控制感。四、从最小可运行版本开始开始开发并没有让GPT一次完成所有的开发第一阶段没有追求漂亮界面而是先打通一条最小链路Camera 手机打开摄像头 ↓ Camera 端启动 RTSP 服务 ↓ Manager 手机发现或输入 Camera IP ↓ 输入 PIN 后播放实时视频链路打通后再逐步加入录像切片、音频、暂停和恢复、历史文件列表、下载、截图、前后摄像头切换、语言切换、电量显示等。根据以往的AI辅助编程经验我觉得这种拆分很重要。一次性加入所有功能时任何一个黑屏或连接失败都可能有多个原因先建立最小闭环后续每个功能都可以单独验证。五、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 开发经验可以按下面的顺序开始先让 GPT 把想法整理成 spec包括角色、状态、数据流、权限、存储和验收条件。让 Codex 检查环境并创建最小可运行工程不要一开始就实现全部功能。尽早连接一台真实手机建立“修改—编译—安装—验证”的循环。每次只处理一类问题例如先解决连接再解决预览再解决录像。遇到错误时提供完整错误文本、复现步骤和期望结果。要求 AI 修改后运行构建、检查 diff并说明没有覆盖哪些测试场景。最终一定由人工在目标品牌和目标系统版本上完成完整操作测试。总结回头看这次 IdleCam 开发GPT-5.6 和 ChatGPT Codex 确实不只是“帮忙补几行代码”。从需求拆解、环境搭建到改代码、跑终端、装真机、看日志它们都参与进来了。甚至APP的图标都是GPT帮忙生成的。但它没有替我省掉软件工程本身。没有 Android 经验的人确实可以做出能运行的应用只是责任还在自己身上权限、兼容性、测试范围和发布质量都得一项项确认。我现在更愿意把分工理解成AI 把执行能力放大人负责把问题讲明白、把结果看仔细、在关键地方作判断。一个可靠的 App 不是靠一条完美提示词生成的而是在真实设备、真实操作和一次次修正里慢慢长出来的。最后分享一下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 背景的人来说可能完全不知道应该从哪里开始。但好在我虽然没有安卓开发经验但还是很多年的后端开发经验并且AI编程也用了很久了。这次开发里我把 GPT-5.6 当成随时可以讨论方案、解释概念的搭档ChatGPT Codex 则更像一个能真正进仓库干活的开发伙伴读代码、改文件、跑命令、编译 APK、把 APK 装到手机上。对我来说最大的变化是不用把自己变成 Android 专家而是一个产品经理、一个需求方。只要把用户做了什么、看到了什么、希望它变成什么样说清楚AI 通常能把问题拆成代码、权限、服务或设备兼容性等具体方向。二、先写 spec再开始编码我没有一上来就让 Codex“直接做一个监控 App”而是先让 GPT 整理需求文档。需求spec也是我通过会话的方式告诉GPT然后GPT整理完善的。最后的spec 明确了 Camera Mode、Manager Mode、PIN、RTSP、录像切片、存储清理、权限、语言和隐私等边界。这里有些技术方案比如RTSP一开始我并不了解也是GPT整理出来的技术方案。到最后还让GPT进行了review确认是否还需要进一步澄清和完善。其中有一些决定后来影响很大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 工具链也不会完全失去控制感。四、从最小可运行版本开始开始开发并没有让GPT一次完成所有的开发第一阶段没有追求漂亮界面而是先打通一条最小链路Camera 手机打开摄像头 ↓ Camera 端启动 RTSP 服务 ↓ Manager 手机发现或输入 Camera IP ↓ 输入 PIN 后播放实时视频链路打通后再逐步加入录像切片、音频、暂停和恢复、历史文件列表、下载、截图、前后摄像头切换、语言切换、电量显示等。根据以往的AI辅助编程经验我觉得这种拆分很重要。一次性加入所有功能时任何一个黑屏或连接失败都可能有多个原因先建立最小闭环后续每个功能都可以单独验证。五、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 开发经验可以按下面的顺序开始先让 GPT 把想法整理成 spec包括角色、状态、数据流、权限、存储和验收条件。让 Codex 检查环境并创建最小可运行工程不要一开始就实现全部功能。尽早连接一台真实手机建立“修改—编译—安装—验证”的循环。每次只处理一类问题例如先解决连接再解决预览再解决录像。遇到错误时提供完整错误文本、复现步骤和期望结果。要求 AI 修改后运行构建、检查 diff并说明没有覆盖哪些测试场景。最终一定由人工在目标品牌和目标系统版本上完成完整操作测试。总结回头看这次 IdleCam 开发GPT-5.6 和 ChatGPT Codex 确实不只是“帮忙补几行代码”。从需求拆解、环境搭建到改代码、跑终端、装真机、看日志它们都参与进来了。甚至APP的图标都是GPT帮忙生成的。但它没有替我省掉软件工程本身。没有 Android 经验的人确实可以做出能运行的应用只是责任还在自己身上权限、兼容性、测试范围和发布质量都得一项项确认。我现在更愿意把分工理解成AI 把执行能力放大人负责把问题讲明白、把结果看仔细、在关键地方作判断。一个可靠的 App 不是靠一条完美提示词生成的而是在真实设备、真实操作和一次次修正里慢慢长出来的。最后分享一下app的运行截图如果读者有兴趣也可以通过这个链接下载体验IdleCam 下载
