我给孩子报过线下外教课也把市面上能下载的英语启蒙App几乎都试了一遍最后被同一个问题卡住孩子对着屏幕点来点去真正开口说英语的时间太少家长又没法时刻在旁边纠正发音。后来我干脆决定自己动手做一款以AI对话和发音评测为核心的小儿英语学习App。整个项目从零起步用了大模型做自由对话语音识别做跟读评测再加上游戏化反馈保持孩子的兴趣前后折腾了好几个月。这篇文章我会把项目的产品逻辑、技术选型、核心实现和上线后的踩坑记录完整整理出来适合正在做儿童AI产品、或者想入行AI教育应用开发的朋友参考。1. 先把产品逻辑想清楚不是把AI塞进App而是解决“开口难”1.1 少儿英语学习的真实痛点孩子不开口做儿童产品之前我一直以为技术是最大的门槛做完才发现产品逻辑才是。儿童英语学习的核心问题不是“没有资源”而是“缺少有效输出”。线下外教课一周两次每次25分钟价格不低回到家之后孩子基本没有英语环境。录播课和点读绘本都是单向输入孩子听懂了、跟读了但没有人跟他来回对话他很难把短语句型内化成自己的语言。市面上很多App把动画做得很好看点一下单词会发声但本质上还是一个“有声词典”孩子不需要思考也不需要组织语言。我观察自家孩子一段时间后发现3到8岁的孩子学英语有两个特点第一注意力窗口很短一个互动环节超过30秒就开始走神第二他们需要即时、具体的反馈说完一句话如果没有任何反应他很快就失去兴趣。所以产品核心必须是“对话”让孩子觉得对面有一个真实的、会听他说话并且回应的伙伴而不是一台考试机器。这个观察直接决定了整个App的形态以语音对话为主线所有学习内容都嵌在对话里而不是做一堆孤立的背单词关卡。1.2 功能范围MVP阶段只做三个闭环我在产品规划阶段列了三十多个功能从自然拼读到语法练习、从单词闯关到绘本阅读但后来砍到只剩三个核心闭环。第一个闭环是“AI自由对话”。孩子进入一个场景比如农场、海洋、太空AI扮演农场主或者小动物用简单的英语跟孩子交流。孩子不需要打字直接说话AI听懂后回应。这个环节解决“开口”问题。第二个闭环是“跟读评测”。每轮对话结束后系统会抽取刚才出现过的高频句子让孩子再跟读一遍并对发音进行打分和纠错。这个环节解决“发音准确度”问题。第三个闭环是“智能复习”。根据孩子当天对话中掌握不好的词汇和句型第二天生成5分钟的复习小游戏而不是简单地把所有内容再推一遍。这个环节解决“遗忘”问题。这三个闭环凑在一起刚好形成一个完整的学习循环输入、输出、反馈、复习。至于语法讲解、阅读理解、单词拼写这些功能我全部放到二期。原因很简单儿童产品功能越多测试成本越高而且很容易让小朋友迷失在功能菜单里反而不愿意开口。1.3 技术选型为什么我选了React Native而不是Unity技术选型阶段我同事建议我用Unity做理由是以后可以上3D场景和虚拟角色。Unity做3D互动确实强但当时的情况是团队只有两个人要快速开发Android和iOS两个平台核心交互是语音对话和列表页面没有复杂动画和3D场景需求Unity带来的开销远远大于收益。最终我选了React Native。理由有三点第一跨平台复用。一套TypeScript代码同时覆盖两个平台省掉至少三分之一的工作量。第二原生模块生态成熟。语音采集、音频播放、推送通知这些能力都能找到稳定的原生模块不需要自己造轮子。第三团队技术栈统一。前后端都用TypeScript新人接手成本低调试工具链也完善。对比下来Flutter当然也可以壁龛在于如果你后续要做大量自定义渲染和动画Flutter上限更高但React Native社区里儿童教育类App的模板和组件更多拿过来改改就能用。对创业团队来说速度就是生命线所以我选了RN。需要说明的是AI模型我全部放在了云端客户端不做任何本地推理。原因很简单儿童用户设备从几百元的入门安卓到最新iPhone都有本地跑大模型既受限于算力也无法及时更新模型版本。云端统一调度客户端只负责录音、渲染和播放这样整个产品对终端设备的要求可以降到很低。2. 核心AI能力落地对话、语音、评测三驾马车2.1 大模型对话引擎与儿童语料适配对话引擎是整个App的大脑我基于通用大模型API做的二次开发。为什么不用开源模型本地部署因为训练数据和推理硬件都在云端API里开箱即用省去运维成本开源模型虽然数据可控但需要自己准备GPU服务器而且儿童对话场景的微调不是一两天能完成的。直接调用通用大模型有一个问题它默认用成人的语气和词汇量来对话孩子根本接不住。我改造的核心是提示词工程。下面是一版简化后的系统提示词实际生产环境要重得多system_prompt 你是一个面向3到8岁儿童的英语口语陪练伙伴名字叫Milo。 规则 1. 只说英语使用不超过6个词的短句。 2. 每次回复只包含一个问句不要连续提问。 3. 如果孩子用中文回答你用简单的英文翻译并鼓励他再跟读一遍。 4. 如果孩子说错了先肯定他的努力然后给出正确说法不要批评。 5. 你扮演的角色是{scene_role}围绕{scene_topic}这个主题展开对话。 这段提示词里最关键的是第2条每次只问一个问题。成人对话可以接受连续提问但儿童如果连续被问两个问题第二句基本就不听了。只问一个问题的设计是实测下来保持孩子参与度的核心技巧。参数设置上也踩了坑。默认的temperature是1.0生成的回答非常发散经常跑题到恐龙和外太空。后来我调到0.4每次对话都尽量贴在当前场景词汇上。同时把max_tokens限制在120避免AI一次说太多孩子跟不上。对话内容的组织上我按主题整理了词汇库。比如“农场”主题下有cow、pig、duck、farmer、feed等核心词AI的每一轮对话都尽量围绕这些词展开。这样可以保证孩子学到的是有体系的内容不是随机聊天。2.2 语音识别与发音评测儿童发音是天然难点语音这块是整项目里最难啃的骨头。刚开始我以为直接调商用语音识别API就能搞定结果孩子一开口识别准确率惨不忍睹。儿童发音有三个特点音色比成人高语速忽快忽慢词汇量小但经常自创发音。通用ASR模型是在大量成人语音上训练的对童声适配很差。孩子说“I see a cat”差点被识别成“I see a cap”这种错误频率非常高。我后来做了两级处理。第一级是识别第二级是评测。识别层我对比了三种方案列个表格供大家参考方案识别准确率成本离线能力我的评价商用云ASR中上童声需调优按量付费单价中等不支持上手快推荐起步使用Whisper本地部署中大模型较重需GPU机器支持可控性强但延迟高Kaldi定制声学模型高但工作量大研发成本最高支持量级不够时不推荐我选了商用云ASR但加了一层定制词汇表。把当前场景下的核心词汇、孩子常见错误发音都配置到识别模型的词库里让模型在解码时优先匹配合法候选词。这招很管用“cat”和“cap”这种混淆问题立刻少了大半。评测层比识别更复杂。发音评测不只是“识别对没对”而是要判断每个音素的发音是否标准。我一开始直接用ASR的置信度分数当发音分数结果发现置信度高不代表发音好因为识别模型会把接近的读音也算成对了。最终我采用的方案是拿到音频后用强制对齐算法把音频切到音素级别再把每个音素的标准发音和实际发音做声学特征对比计算一个相似度分数。核心逻辑大约是这样def grading_result(phoneme, audio_segment): # 提取实际音素的MFCC特征 mfcc extract_mfcc(audio_segment) # 和标准音素模型做对比 score similarity(mfcc, standard_model[phoneme]) return score纠错策略上也有讲究。孩子说错的时候我一开始会在界面上打一个大大的红叉结果孩子立刻情绪低落不肯再录了。后来改成“微笑脸正确发音示范”先播放一遍标准读音再让孩子跟读一遍任何时候不做否定性纠错。儿童学习最怕打击信心这个改动让复读率提高了将近两倍。2.3 语音合成与互动反馈的延迟优化语音合成TTS是很多入门者忽略的环节。孩子的耐心窗口很短AI如果两秒不回话他就开始切后台了。我最初把“识别-大模型-合成-播放”整条链路串行处理总延迟经常到5秒以上体验很糟糕。优化思路有三个方向。第一个是通信层客户端和服务器之间用WebSocket建立长连接而不是每次对话都重新走HTTP握手。语音数据等到一句话说完再上传不要实时传全流减少等待感。第二个是合成层采用流式TTS。传统TTS是等整句话生成完再播流式TTS可以像视频直播一样边生成边播放。首包延迟从1.5秒降到0.5秒左右体验提升明显。第三个是缓存层把高频反馈句子提前合成好。比如“Great job!”“Try again!”“Nice to meet you“这类句子每天出现几十次提前合成好存到CDN播放时直接下音频文件根本不走TTS服务。实测效果非常明显整体交互延迟压到了1.8秒以内孩子基本感知不到卡顿。3. 从原型到上线的工程实践客户端的那些坑3.1 儿童友好UI不只是把按钮变大先说一个很多团队都会忽略的问题儿童App的字体设置。成年用户觉得好看的字体孩子可能根本看不清。我在第一版设计稿里用了比较纤细的字体字号24px测试时发现孩子距离屏幕一远就看不清经常凑到屏幕前导致录进去的语音全是呼气声。后来我做了三件事。第一所有正文字号不低于28px关键按钮文字不低于32px。第二选择了笔画较粗的圆体字字母区分度高尤其是a、o、e这种容易混淆的字母。第三适配系统字体缩放安卓手机上用户把系统字体调成特大时页面布局不会乱掉iOS同样做了动态字体适配。除了字体儿童触控区域也要重新设计。成年人手指点击目标可以做到44x44pt儿童手指更小但控制力更差实际可点击区域我做到56x56pt以上并且所有按钮之间留出足够间隙避免误触。孩子一旦点错按钮进错了页面基本没有能力自己返回家长又不在旁边很容易产生挫败感。音频播放模块我参考了一个开源音乐播放器的源码结构。刚开始做跟读评测时音频播放和录音经常冲突孩子录音过程中如果上一段AI语音还没播完两个声音混在一起评测结果完全乱七八糟。后来我把音乐播放器里的音频焦点处理逻辑搬到App里开始录音前主动请求音频焦点、暂停当前播放录音结束再释放焦点。这个细节不解决整个对话流程就没法用。3.2 后端服务与Agent调度把场景拆给不同智能体后端服务的架构不算复杂但有一个点我认为值得重点说我把不同能力拆成了独立的Agent来调度而不是在一个服务里堆砌所有逻辑。所谓Agent开发在这个项目里的落地方式是三个独立的智能体模块对话Agent负责维持多轮会话上下文。它保存孩子的对话历史把当前场景、词汇表和最近三轮对话记录一起传给大模型保证上下文连贯。评测Agent负责发音评分。它拿到音频后就做强制对齐、音素对比、评分不和对话逻辑混在一起。好处是即使大模型响应慢了评测流程还能独立跑完不会整个功能挂掉。推荐Agent负责生成复习内容。它读取对话Agent产生的词汇掌握记录按遗忘曲线算法筛选今天的复习单词和句型再把这些素材交给复习小游戏模块。后端我用了FastAPI搭建逻辑简单、性能足够。Agent之间通过消息队列通信避免实时性要求高的对话链路被低频任务拖累。下面是一段调用对话Agent的示例已经去掉了业务细节from fastapi import FastAPI, WebSocket app FastAPI() app.websocket(/v1/chat) async def chat_stream(ws: WebSocket): await ws.accept() while True: audio_path await ws.receive_text() text asr_recognize(audio_path) reply dialogue_agent.run(text, session_iduser_id) tts_url synthesize_quick(reply) await ws.send_json({text: reply, audio_url: tts_url})这里最容易被忽视的问题是儿童session状态管理。孩子用完iPad之后下一个孩子接着玩如果session没隔离上一个孩子的对话记录会泄漏到下一个孩子的会话里轻则内容错乱重则隐私问题。我在服务端为每个孩子分配独立的session_id并在客户端切换用户时强制刷新这是儿童类产品必须做好的底线工作。3.3 儿童隐私合规、数据安全与上线发布面向未成年人的App隐私合规是一个绕不开的关卡而且现在应用商店审核对这个领域卡得越来越严。我采取的数据策略是“最小化收集”。注册只需要家长手机号不收集孩子的真实姓名、照片、精确地理位置。语音数据只在会话过程中临时使用评分完成后立即删除音频文件只保留文本记录和分数。文本记录默认6个月后自动清理家长可以随时在设置里手动删除全部记录。应用商店审核时好几处细节容易踩坑。首先产品必须声明儿童年龄分级并在隐私政策里明确说明数据收集方、用途和保留期限。其次任何需要联网的对话功能都要提供家长控制开关让家长能查看对话记录。最后第三方SDK如果也在收集数据必须在隐私政策里同步公示不能只说自己收了什么。App上架之前我只做了功能测试结果两次被驳回一次是因为隐私政策链接打不开一次是因为缺少儿童模式说明页。这里强烈建议在提审前就准备好完整的隐私政策页面和儿童信息保护说明别等审核意见出来再补白白浪费几天时间。上架之后也要接入崩溃监控和日志系统儿童用户设备碎片化非常严重很多问题只在特定机型上出现没有日志追踪等于瞎猜。4. 上线后的常见问题与排查实录4.1 高频问题速查表上线两个月我收集了几百条用户反馈整理出几个高频问题的排查表这个表格对同类项目应该也有参考价值现象常见原因我的解决办法孩子说英语识别不到麦克风权限未授权/ASR词库缺失首轮对话前强制检查权限每个场景动态加载词库AI回答超时大模型响应慢/弱网环境增加超时降级逻辑超时直接播放缓存反馈音频发音评分总是偏低分数标定偏高/童声适配不足收集真实用户录音重新校准分数线孩子连续点按钮没反应缺少防抖和loading状态全局按钮节流进入待机动画部分手机字体错乱系统字体缩放适配遗漏全面启用动态字体并做布局约束对话时音频断续音频焦点冲突/播放服务被系统回收使用前台服务保活处理来电打断场景每一条背后都是一段真实的调试经历。比如评分偏低那条最初我设定的60分及格线是基于成人用户的发音测试做出来的但儿童口腔肌肉发育不完全音素时长和共振峰都有差异同样的音色在成人模型下只能拿50分。后来我收集了一批3到6岁孩子的录音重新标定了各个年龄段的中位数和标准差分数分布才正常。4.2 延迟与成本的实测优化调试到后期我把一次完整对话的耗时拆解成了四个环节语音上传、ASR识别、大模型生成、TTS播放。第一次实测大模型生成占了将近50%的时间TTS合成占25%ASR占15%网络上传占10%。单纯提升服务器配置对整体改善有限因为大头在大模型调用上。我做的优化有两类一类是缩短模型输入。对话Agent每轮只传最近三轮对话记录超过部分做摘要压缩。输入token少了首字返回时间能快300到500毫秒。另一类是缓存命中。如果用户说的句子是高频句型直接命中提前预设的答复模板不再调用大模型。比如“What‘s your name”“How are you”这类句子大概能命中20%的请求省下来的就是不必要的大模型费用。成本上也有些实际数据。大模型按token计费一个孩子每天20分钟深度对话大概消耗2万到3万token折合约两毛钱人民币。加上ASR和TTS费用单人单日成本控制在五毛以内。对于家庭订阅制的产品来说这个成本结构是可以商业化的。4.3 内容安全防止孩子被AI带偏儿童AI对话产品和成人AI最大区别是一旦内容出问题后果非常严重所以在内容安全上绝对不能省。我的做法是三层过滤。第一层在提示词层面设定严格的角色边界AI只能在当前场景内说话不讨论与学习无关的话题也不主动引出任何超出儿童认知范围的内容。第二层敏感词库实时拦截。第三层如果孩子反复追问边界外问题AI用固定的安全回复兜底比如“Let‘s go back to the farm and see the animals”。有人可能会想儿童AI要不要做“无违禁词限制”的完全开放对话我坚决反对这个方向。儿童心智还不成熟开放领域的自由对话风险远大于收益。产品层面上家长端可以看到完整的历史对话记录一旦发现任何可疑内容可以一键反馈并拉黑对应会话。做儿童产品安全合规不是功能是所有功能的前置条件。5. 开发和运营阶段的一些补充建议5.1 用AI辅助自己写代码这个项目周期压得紧我一个人同时写前端、后端和AI逻辑纯靠手工写代码根本不可能完成。实际开发中我大量使用了Cursor这类AI编程工具。RN页面组件、重复的表单逻辑、表格配置这些模板代码直接给AI描述需求就能生成准确率很高。但AI生成代码有个坑它写出来的界面样式往往偏“通用”颜色和间距需要整体调一遍。所以我的习惯是让AI负责结构化代码人类负责设计感和产品细节。代码审查一定要人工做尤其涉及音频、麦克风权限、数据存储这些关键模块不能盲信AI输出。5.2 后续扩展方向与硬件联动App第一版稳定之后我尝试了两个扩展方向都还处于实验阶段。第一个方向是增加游戏化场景。当前对话场景是平面图片加AI语音后续想做成角色扮演类的互动剧情孩子和AI一起完成任务在情境中重复运用目标句型。这个方向在技术上是可行的但需要动画、剧情设计和AI对话强耦合开发量不小。第二个方向是硬件联动。我试过用蓝牙控制ESP32做一个简单的语音互动玩具孩子按下玩具按钮后玩具发一句英语孩子回复App收集语音做评测。这样做的好处是把屏幕时间转化为身体活动时间更适合低龄儿童。目前只是原型阶段后续如果做出来了我再单独写一篇硬件和App联动的实战记录。写在最后项目做到现在我最大的体会是给孩子做的AI产品技术反而不是最难的部分最难的是让孩子愿意开口、愿意继续开口。你可以把大模型调得很好语音评测做得很准但如果孩子第一句话说完没有获得正向反馈他下次就不会再拿起点读笔或者打开App了。所以无论技术方案多先进儿童产品的第一原则永远是先友好再智能。建议所有想做儿童AI产品的朋友不要在电脑前闷头调模型先找一个3到8岁的孩子试玩一个小时看他盯着屏幕什么时候笑了、什么时候皱眉头、什么时候把设备摔到沙发上比你看十篇技术方案都有用。