「AI 造物实验」系列第 1 篇。这个系列记录我用 AI 从零做一个真实 App 的全过程：踩过的坑、翻过的车、上线和迭代。不带货、不神化，只交代真实发生的事。全系列共 5 篇，每周三晚更新。
你家孩子睡觉也要听着点什么吗？
我家是：孩子躺下，自己挑好儿歌或故事，听着听着，自己就睡着了。每晚固定节目，比任何日程都准时。
这个固定节目，有两个长期的背景噪音。
一个来自 QQ 音乐。它的免费听歌，是拿广告换时长的：看一段广告，换 30 分钟收听时间。30 分钟一到，声音就停了——想续上？再去看一遍广告。孩子躺下听得好好的，时长用完，你是过去点广告，还是赌他这回已经睡着了？
要不开会员？孩子听歌用 QQ 音乐、听故事用喜马拉雅——意味着两份会员。为了孩子睡前的个把小时，每个月多一笔固定开销。
另一个来自喜马拉雅。听故事有“定时停止”，功能是好功能，但只能选 5 分钟、10 分钟这样的固定档位。麻烦在于，孩子入睡的时间不固定：定时 10 分钟，人还没睡着，声音先停了；干脆不定时，人睡着了，故事还在耳边放到后半夜。想设个 25 分钟——差不多刚好够孩子入睡的时长？没有这个选项。
我受够了。
先把火气翻译成需求
冷静下来，把火气翻译成需求，其实就三条：
- 能播放手机里已有的音频文件——儿歌和故事，家里早就存了一堆；
- 定时停止，分钟数我自己定；
- 不用看广告换时长。
这三条，没有一条是技术难题，甚至算不上“需求”，只能算“常识”。
但商业 App 满足不了。原因不是做不到，而是不值得做：免费用户的注意力是广告库存，定时功能的自由度是会员卖点。我的需求太小众、太不赚钱，在这个市场里，它活该不被满足。
想明白这一点的那个晚上，我冒出一个念头：与其围观同行争论“AI 到底会不会取代程序员”，不如拿这个真实的小需求，亲手做个实验。
一条反向的实验规矩
先交代背景，这个很重要：我是程序员，写了 10 年后端。我的日常是服务器、接口和数据库——App 开发，我一行都没写过，在这个领域是彻头彻尾的外行。
所以这个项目从头到尾是这样一副画面：一个后端程序员，不做界面、不碰安卓、不看日志，让 AI 独立开发出一个手机 App。
准确说，“不看日志”不是硬撑出来的规矩，是自然形成的分工。几次翻车之后我发现，我真正能干、也值得干的是三件事：**提需求、验收、把问题原样反馈回去。**剩下的——读代码、查日志、改文件、跑构建——全部交给它。
我用的是 Claude Code，一个装在电脑终端里的 AI 编程助手：能直接读写项目文件、自己执行命令、自己排查报错，像坐在旁边的一位工程师。
说白了，我从后端工程师的工位，直接坐进了这个项目产品经理的工位——中间隔着的“客户端开发”那一整段路，AI 替我走完了。
我给它的开场白，大意是这样的：
给我做一个安卓音乐播放 App。要求：能导入手机里已有的音频文件（mp3、flac 这些），有音乐库、歌单、收藏，界面参考 Apple Music 的简洁风格。另外要一个定时停止播放的功能，时间可以自定义输入，比如 25 分钟。
第一版能用之前，翻车三连
两三天后，第一版装上了我的手机。
界面有模有样：音乐库、歌单、收藏、正在播放页，还真是 Apple Music 那个味儿。我满怀期待点开一首歌——
翻车一：一打开就闪退。
App 图标点开，白屏一闪，弹回桌面。连试三次，次次如此。
我把现象原样丢回去：“点开就闪退，连试三次都是。”它教我把手机上的报错日志导出来。那个日志文件里写了什么，我一个字没看——复制，粘贴，发送。几轮对话后，真相大白：它选用的播放器内核组件（react-native-track-player，一个开源的音频播放模块）刚经历大版本更新，初始化的注册方式整个改了；而 AI 记忆里的接法，还是老版本的。
打个比方：像一位老实师傅按十年前的电路规范给新房接线——他没偷懒，只是他的经验停在了旧标准。
翻车二：点“导入音乐”，毫无反应。
闪退修好，App 能进了。我点“导入”，按钮按下去，界面纹丝不动。
又是一轮“描述现象—发日志—等修复”。这次的原因让我哭笑不得：AI 担心我权限不够，在打开系统文件选择器之前，贴心地先申请了一遍存储权限——而安卓现在的文件选择机制，压根不需要这个权限。这个多余的申请，把选择器堵死在了半路。
标准的好心办坏事。
翻车三：新建歌单，崩。
前两个修好之后，App 顺了。用到第三天，我新建一个歌单——白屏一闪，又是熟悉的配方。
这次的元凶最隐蔽：AI 用了一个业界标准的编号生成工具（uuid，程序员用它给每条数据生成唯一“身份证”），并且默认用最新版；最新版用了一个新的标准函数，而 App 内部那颗为了省内存、省电而精简过的运行引擎（技术名：Hermes），不认识这个函数。AI 写代码时默认“标准环境”，它不知道这辆车，被改装过。
这个 bug 从发现到修好，我没看懂其中任何一行日志。说真的，客户端领域的报错，我这个写后端的看着也眼生——但我也没打算看懂：日志原样转交，等它给修法，装新版，验收。修好了，就是修好了。
三次翻车，三次都不是需求太难，全是“知识错位”：记忆过时了、好心过剩了、想当然了。
真正的验收标准：25 分钟
界面稳定之后，我第一个验收的不是音质，不是颜值，是那个定时时长。
打开定时页：固定档位之外，有一个“自定义”按钮，输入分钟数，1 到 720 分钟都行。我设了 25 分钟，开始播放。25 分钟后，声音停了，App 安安静静待在后台。
从那晚开始，睡前变成了：孩子躺下，自己挑歌，自己听，自己睡着。听歌没有 30 分钟一到就被按下的暂停键，听故事没有 10 分钟的固定档位；孩子睡着之后，声音会在恰当的时候自己停掉。
这个 App 的第一个用户，是我家孩子。孩子不知道这个东西是怎么来的，只知道从今往后，听歌这件事再没被打断过。
一个需求只值三条描述，但满足它的价值，是“听着听着就睡着了”这件事，从此有了刚好合适的时长。
这一篇，我想说的
如果这个系列你只带走一句话，我希望是这句：
AI 没有把做 App 变成一句话的事。但它正在把“会写代码”从一张门票，变成一个加分项。新的门票是：会提需求、会验收、会判断 AI 给的答案靠不靠谱。
翻车三连那几天，真正让项目往前走的，不是我的编码能力（后端的老本行，在这里一次都没派上用场），而是三件事：把现象描述清楚、把报错完整转述、逐条验收每个版本。
如果你不写代码，这是好消息：这三种活儿，不需要写过一行程序也能干，而且越干越熟练——你和一个后端程序员做 App 时的差距，比想象中小得多。
如果你写代码，这也是个提醒：我写了 10 年代码，头一回这么清楚地感到——我的价值里“敲代码”的占比在缩水，“提对问题、判断答案”的占比在涨。这个趋势，两边的人都值得认真对待。
下集预告
本地版安稳用了一周，新的问题如约而至：音频文件越存越多，手机存储开始吃紧；换手机、给家人的手机也装一份，就得把歌重新导一遍。靠“本地导入”这条路，走到头了。
下一篇，我把整个音乐库搬上云——一台最便宜的云服务器，一个 AI 从零写出的后端。从此家里每台设备打开就能听全部的歌，手机上一首都不用存。
再往后某一篇，会讲这个项目里最精彩的一个 bug：“播放全部”时灵时不灵——不报错、不崩溃、毫无规律，AI 排查了三轮才抓到真凶。那个案子，值得每一个跟 AI 协作的人看看。
AI 造物实验·一个 App 的诞生
- 01 孩子听歌入睡，我干脆让 AI 写了个音乐 App（本篇）
- 02 AI 写代码翻车实录：怎么当 AI 的产品经理
- 03 我搭起了全家共用的“私人音乐云”
- 04 一个安装包，从我的手机装进了全家的电视
- 05 一个人 + AI = 一支产品团队：完整复盘
聊两句：你家孩子睡前听什么？用的哪个 App，被什么坑过？评论区说说——说不定下一个实验，就从你的痛点开始。
如果这个系列对你有启发，点个“在看”，下一篇见。