润木听听并不是从一个宏大的创业计划开始的。

它最初只是我在生活里反复遇到的一个小问题：

我想在日常生活中偶尔对孩子说几句英语，但真正到了吃饭、洗澡、穿衣或者出门的时候，经常一句自然的话都想不起来。

有时候我会临时搜索，有时候会收藏一些亲子英语内容，也尝试自己整理句子。但这些内容通常散落在不同的文章、视频、表格和聊天记录里。

真正需要的时候，我还是要重新查找。等查到以后，那个生活场景往往已经过去了。

后来我慢慢把这个问题概括成一条很短的路径：


想说 -> 找到 -> 听到 -> 说出

润木听听想做的，就是尽量缩短这条路径。

我需要的不是一套英语课程

市面上当然不缺英语学习产品。

但我慢慢意识到，我需要的东西和大多数英语学习产品不太一样。许多产品关心的是：怎样让孩子系统地学习英语，或者怎样帮助成年人提高英语水平。

而我的问题要小得多：

当我想在一个真实的生活场景里，对孩子说一句英语时，能不能马上找到一句简单、自然、不尴尬的话？

我并不准备每天花一个小时学习语法，也不想完成复杂的课程、考试和打卡。我只是希望在吃饭、洗澡、玩耍或者睡觉的时候，能够顺手说上一两句。

例如：

  • 洗手的时候应该怎样说？
  • 提醒孩子慢一点应该怎样说？
  • 准备出门时有哪些自然的表达？
  • 睡觉前可以对孩子说什么？

这个需求并不大。甚至从商业角度看，它可能也不是一个非常大众的需求。大多数家长更愿意花钱让孩子学习，而不是让自己承担一项新的学习任务。

但它确实是我自己的真实需求。

从“学习工具”变成“播放器”

一开始想到亲子英语产品，很容易自然地往“学习 App”方向走：每日打卡、学习计划、发音评分、AI 对话、课程体系、排行榜、成长报告……这些功能放在一起，看起来才像一个完整的教育产品。

但想得越多，我越觉得它偏离了最初的问题。

我的目标不是再建立一套需要家长坚持完成的学习体系，而是降低开口的阻力。如果一个家长本来就没有太多时间，再让他选择课程、完成任务、查看报告，这个工具本身反而可能成为新的负担。

所以，我最后把它定义成一个播放器。

传统播放器播放音乐，润木听听播放“亲子英语包”。一个英语包里包含若干生活场景，每个场景里是家长可以直接说出口的句子：


英语包 -> 场景 -> 句子

用户可以像选择歌单一样选择一个英语包，但界面里不会出现“课程”“课时”或者“训练”。可以先听中文提示，再听慢速和正常语速的英文；可以留出跟读时间，也可以连续、随机或者循环播放。

听到一句适合当下场景的话，就试着对孩子说出来。

它不负责判断你说得是否标准，也不要求你今天必须完成多少任务。它只解决一件小事：

缩短“我想说一句英语”和“我真正说出口”之间的距离。

这也逐渐变成了润木听听最重要的一句话：

爸妈先开口，孩子自然听见。

第一版应该做什么，也应该不做什么

确定了播放器的方向以后，功能反而更容易取舍。

第一版重点保留：

  • 按生活场景整理的英语包；
  • 播放整个英语包、单个场景或者单句；
  • 聆听模式和跟读模式；
  • 顺序、随机和循环播放；
  • 中文提示、英文慢速、英文正常语速和跟读留白；
  • 收藏常用句子和本地搜索；
  • 播放记录和继续上次；
  • 后台播放、通知栏和锁屏播放；
  • 本地保存收藏、设置和播放记录。

暂时不做：

  • 用户账号和云同步；
  • 社交、排行榜和打卡；
  • 发音评分、录音纠音和测评；
  • AI 聊天老师和连续对话；
  • 用户上传、公开分享和内容市场；
  • 订阅、VIP、金币和充值体系。

这些功能并不是在任何情况下都没有价值，只是现阶段必须先回答一个更基本的问题：

家长会不会真的在日常生活里打开它，并且说出其中的一句话？

如果这个问题还没有得到验证，增加再多功能也没有意义。

真正做起来以后，内容比我想象中更重

最初我以为，播放器的主要难点会是技术。真正做起来以后，我发现内容本身同样复杂，而且工作量一点也不小。

一句英语语法正确，只是最基本的要求。它还需要考虑：

  • 是否自然；
  • 是否适合家长对孩子说；
  • 是否符合具体生活场景；
  • 中文提示是否容易理解；
  • 句子长短是否适合听和跟读；
  • 同一场景里的句子应该怎样排序；
  • 哪些表达值得反复使用；
  • 哪些表达虽然正确，却很少出现在真实家庭里。

如果内容只是大量堆积，用户仍然需要自己搜索和筛选。润木听听真正应该做的，是提前完成这部分选择和整理，让家长打开一个场景后，可以直接听到当下可能用得上的表达。

为了让内容可以持续维护，我没有把句子直接写死在页面里，而是建立了一条相对清楚的内容生产流程：


整理后的 CSV 内容源
-> 脚本校验英语包、场景和句子的关系
-> 生成本地 SQLite 内容库
-> 生成中文、英文正常和英文慢速音频
-> 校验音频完整性
-> 随 App 一起打包

截至 2026 年 7 月 13 日，当前内测内容已经整理为：

  • 6 个官方英语包；
  • 81 个生活场景；
  • 1530 条亲子英语句子；
  • 4590 个本地 MP3 音频文件；
  • 每句话各有中文提示、英文正常和英文慢速三路音频。

这些数字看起来只是内容数量，背后却意味着分类、去重、翻译、语气、排序、音频生成和逐层校验。做完这一轮以后，我更加确定：润木听听不仅是一个播放器，也是一个经过选择和组织的亲子表达库。

为什么核心内容坚持离线

我希望这个工具在真正需要的时候尽量少制造阻力，所以当前官方英语包、数据库和音频都直接打包在 App 里。

这样做有几个很实际的好处：

  • 没有网络时也能查找和播放；
  • 不需要登录以后才能使用；
  • 收藏、设置和播放记录可以优先留在本机；
  • 播放不依赖远程接口临时返回内容；
  • 技术链路更短，内测阶段更容易定位问题。

内测版另外加入了可关闭的匿名使用统计和反馈入口，用来判断用户有没有顺利找到播放入口、实际听了多久、问题集中在哪里。它不使用设备硬件 ID，也不收集姓名、手机号、定位、录音、孩子信息或搜索原文。用户关闭匿名统计后，本地待上报事件也会清理。

关于页、反馈页和公告文案可以从远程更新，但即使远程请求失败，App 也会使用内置默认文案。远程能力服务于内测反馈，不改变核心内容和播放离线可用的原则。

播放器不是“把几个音频放出来”

真正开始做播放器后，我才发现，一句内容在页面上只是一句话，在播放系统里却可能由很多短片段组成。

例如跟读模式的一句话实际是：


中文提示 -> 英文慢速 -> 留白 -> 英文正常 -> 留白 -> 下一句

聆听模式还要处理混合、慢速和正常三种英文语速。暂停、继续、重听和下一句都必须理解“句子边界”，不能把中文、英文或留白误当成独立的一首音频。

这带来了几个只有真机使用时才会暴露的问题：

  • 很多短音频频繁切换时，通知栏可能闪烁；
  • 留白如果只用计时器模拟，切到后台后媒体会话可能中断；
  • 页面和底层播放器各自保存暂停状态，会出现按钮显示和实际声音不同步；
  • 通知栏的“下一首”如果照搬音乐播放器逻辑，可能只跳到下一个短片段，而不是下一句话。

后来，播放系统改成先把整段播放步骤组成一个播放列表，再交给底层播放器连续播放。跟读留白也不再靠停止播放器等待，而是使用打包好的静音音频。播放页、底部迷你播放器和系统媒体控制尽量读取同一套播放状态，“下一句”也统一跳到下一句话的开头。

这些改动用户未必看得见，却直接决定了这个 App 到底像不像一个可靠的播放器。

从浏览器预览到真机运行

开发过程中，我也踩了不少以前没有意识到的坑。

浏览器里的界面看起来正常，不代表真机上的效果正常。手机屏幕尺寸、系统字体、数据库复制、音频资源、后台播放、通知栏和锁屏控制，都会带来新的问题。

有时候只是一个句子太长，就会破坏整个卡片布局；有时候浏览器预览很舒服，到了手机上却显得拥挤；有时候页面里的播放按钮工作正常，切到后台后音频却会中断；还有时候 Debug 版本和 Release 安装包在同一台手机上的系统媒体控制表现并不一样。

目前，润木听听已经可以在 Android 真机上运行。App 内开始播放、暂停、继续和下一句已经能够正常工作，锁屏后音频也可以继续播放，短音频导致的通知栏闪烁问题已经修复。

但内测也留下了一个很具体的兼容问题：在当前测试的华为手机上，Release APK 的通知栏可以显示媒体标题和播放模式，却没有显示播放、暂停和下一句按钮；同一台设备通过 Debug 方式安装时，按钮又可以显示。系统已经能检测到 App 发布的媒体会话和控制能力，所以问题更可能与具体系统、Release 包或媒体通知兼容有关。锁屏媒体控制组件目前也还没有正常显示。

这件事让我更加清楚：

产品不是把页面做出来，而是在真实设备、真实场景和真实使用习惯里仍然能够工作。

承认一个问题还没有解决，比在文档里把“支持锁屏控制”写成一句轻飘飘的完成项更重要。内测的价值，正是把这些边界找出来。

我不是程序员，但第一次有机会把想法做成产品

我做过土木工程、保险销售，现在从事跨境电商。

过去几年，我在工作中接触了大量表格、数据、运营流程和重复操作，也陆续使用自动化工具解决过一些实际问题。但我不是科班程序员，也没有独立开发完整 App 的经验。

以前，即使产生一个产品想法，我也很难真正把它做出来。找人开发意味着较高的成本，同时还要不断解释需求、确认细节，并承担试错风险。而像润木听听这样的小众需求，很难在一开始就证明它值得投入那么多资源。

AI 编程工具改变了这一点。

我可以先描述需求，让 AI 帮助我拆解任务、设计数据结构、生成代码、补测试、排查错误，再到真机上不断验证和修改。我仍然不具备传统程序员那样完整的技术能力，但第一次拥有了把一个想法逐渐变成真实产品的可能。

AI 降低了开发门槛，但没有替我做产品判断

真正开始开发以后，我发现，写出代码并不是唯一的困难。很多时候，更难的问题是：

  • 这个功能究竟需不需要？
  • 首页应该展示什么？
  • 播放器应该怎样操作才自然？
  • 长句应该怎样显示？
  • 英语内容应该怎样分类？
  • 哪些数据必须联网，哪些应该留在本地？
  • 是否真的需要账号系统？
  • 什么时候应该停止增加功能？

AI 可以提供很多方案，也可以很快把一个新功能加进来。但它无法替我决定：

润木听听最终应该成为一个什么样的产品。

例如，AI 很容易帮我增加聊天助手、发音评分或者复杂推荐。这些功能看起来先进，却未必能解决家长真正的问题。相反，一些看起来并不起眼的事情可能更加重要：

  • 播放是否稳定；
  • 锁屏以后能否继续播放；
  • 收藏的句子是否容易找到；
  • 英语包分类是否自然；
  • 一句话是否符合真实家庭表达；
  • 家长能否不经过学习就马上使用。

开发过程中，我甚至需要专门写下产品原则和功能边界，让每一次修改都回到同一个判断标准：它是否能帮助家长更快找到、听到、说出一句亲子英语？

这也是我使用 AI 编程以后很深的一点感受：AI 让实现变快，也让“克制”变得更加重要。因为增加功能越来越容易，知道什么不该做，反而成为更稀缺的能力。

内测不是证明我做完了，而是验证最小闭环

润木听听目前已经进入内测准备阶段，但“功能能运行”和“产品值得长期使用”之间还有很长的距离。

第一阶段真正要验证的并不是用户每天打开多少次，也不是能不能迅速做大，而是一个很小的闭环：


家长选择一个英语包
-> 开始播放
-> 听懂中文提示和英文表达
-> 跟着说出一句
-> 离开页面后仍能方便地暂停和继续

如果用户找不到入口，如果内容不自然，如果播放两分钟就被系统中断，或者需要理解一堆设置才能开始，那么这个闭环就没有成立。

所以，内测阶段我更关心的是：第一次打开能否顺利开始播放，哪些英语包真的有人听，用户通常在哪些地方暂停，哪些句子让人觉得别扭，以及不同手机上的后台播放是否稳定。

数据只能告诉我发生了什么，真实反馈才能帮助我理解为什么发生。两者都应该服务于下一步判断，而不是为了让产品看起来更“数据化”。

这是一个很小的产品

我不知道润木听听最终会有多少用户。

它可能只是一个很小众的播放器，也可能只适合一部分愿意在生活中主动开口的家长。但我越来越觉得，小并不一定意味着没有价值。

过去，一个需求必须足够大众，才值得投入程序员、设计师和运营人员去开发。很多具体需求因为市场太小、开发太贵，只能长期被忽略。人们只能继续使用不合适的通用软件，或者依靠 Excel、笔记、搜索和人工操作将就。

AI 正在降低这种产品的生产成本。它不会自动创造需求，也不能保证产品一定有人购买。但它至少让一个普通人有机会先从自己的真实问题出发，把一个过去“不值得开发”的小工具做出来，再交给真正需要它的人使用。

这也是我开始个人开发以后最感兴趣的一件事：

那些过去因为需求太小、太具体，或者开发成本太高而无法成立的产品，现在是否有机会被认真做出来？

接下来做什么

润木听听接下来不会急着增加很多新功能。

第一阶段仍然会优先处理：

  • 播放稳定性；
  • 后台、通知栏和锁屏播放；
  • 内容错误和不自然表达；
  • 搜索与收藏体验；
  • 长句显示；
  • 不同手机上的适配；
  • 真实家长的使用反馈。

我也会继续记录它从一个个人需求逐渐变成真实产品的过程，包括做对的事情，也包括做错的判断。

这是我的第一个产品。

先把它做完，再做下一个。