做小程序这事起因特别简单。我白天写代码晚上背单词结果发现市面上那些App要么强制登录要么听写功能藏在会员后面要么内置词单根本改不了。有一天下班我实在忍不住决定自己写一个。于是用了大概20天下班后的时间捣鼓出一个能朗读、能听写的单词小程序。不吹牛现在每天用它过30个旧词加10个新词已经变成习惯错词本里那几十个“老顽固”也慢慢被清零了。这篇文章就把这段时间踩过的坑、做过的方案对比、以及核心实现逻辑一次说清楚如果你也在琢磨自己做一个小程序或者打算做一个背单词小工具应该能少走不少弯路。1. 动手之前需求、技术选型和功能边界1.1 先盘点自己的真实痛点市面上背单词工具很多但有几个点一直让我难受。第一很多App的听写本质上是个“填空选择题”我把单词拼写敲进去以后它给一个分数可是过程里它压根没有把单词“读”清楚很多时候我听不出到底是i还是e。第二词单不可编辑。我自己的生词本存在系统备忘录里App里根本导不进去一个个手打太痛苦。第三我想在通勤、做家务的时候“听”单词而不是一直盯着屏幕但大多数App的朗读模式会把中文解释一起读出来啰嗦又拖沓。归纳下来就三个需求能按我的词单朗读、能在朗读后留出停顿让我听写、能把拼写错的和漏听的自动收集起来。这三个点单独拎出来都不复杂凑到一个App里还要免费无广告就只能自己动手。那段时间我的场景特别具体下班回到家把今天积累的生词丢进小程序洗漱时让它一个词一个词地读我在心里拼一遍再掏出手机验证。这种需求太小众指望大厂产品经理安排上不太现实自己动手是唯一的解。1.2 为什么最终选了小程序原生开发在技术方案上我纠结了很久。一开始想用跨端框架基于Web技术来写理由是以后可能想上其他平台不想写两遍。但把实际功能列了一版以后我发现这个项目其实特别轻词单管理、朗读、听写、设置核心就是和小程序底层音频能力打交道。跨端框架在这里能帮上的忙不多反而会引入一层抽象出了问题以后排查路径更长。我最后选择用小程序原生技术栈三个原因。一是文档和工具链最成熟报错了上网一搜基本都能找到答案二是音频播放、插件市场这些能力在原生环境里最稳定用框架反而要处理不同平台的兼容差异三是这个项目完全不需要双端复用也不用“未来一定怎样”的假设。技术选型由此确定。说到底小项目最忌讳的是为了“以后可能怎样”去选一个现在更复杂的方案。项目周期只有20天任何不必要的复杂度都是在给自己埋雷。1.3 真人录音包和TTS合成怎么权衡做朗读功能第一反应是找真人录音包。我在网上翻了很久发现很多开放词库附带的音频要么只覆盖两三千个高频词要么就是不同来源的声音混在一起音色根本不统一。如果只是做考试词表勉强能撑住但我的生词本里经常有专业词、人名、地名这些一旦没有录音小程序就“哑”了体验非常割裂。所以我转向文本转语音方案。小程序生态里有一个官方同声传译插件提供语音识别和文本转语音能力英文、中文都能读而且直接在手机本地调用不需要额外的后台服务。实测下来它的发音清晰语速和音调可调完全能覆盖“听写”场景。配置成本很低不需要自己搭服务转发。后续就算词表存到一万词合成方案也不用改数据。真人音源确实自然但对一个20天要上线的个人项目来说TTS的可维护性远远胜出。1.4 功能边界第一版坚决不做五件事第一版我给自己定了几条硬规则只做核心闭环不做登录、不做收费、不做社区、不做社交分享。核心闭环就是“选词单—朗读—听写—错词本”每一步都不能省。登录涉及到用户信息授权和隐私协议收费涉及支付权限分享涉及内容合规这些都不是20天能妥善处理的再说个人使用也不需要它们。把这些需求划掉以后工作量一下清晰了。具体拆下来数据层大概1天页面骨架3天语音模块4天听写交互2天串流程和测试3天最后剩下时间全用来调细节。实际开发还是比计划多花了几天但“先划功能边界再排期”这个动作保证了我没有在开发到一半时临时加需求。小工具类项目的通病就是越做越大边界不划清20天很可能连一个能跑的版本都出不来。2. 词库、朗读和音频参数让小程序开口说话2.1 词库数据从哪里来、怎么清洗词库是工具的灵魂但我不可能在20天内手工整理几千个词。我的做法是“基础词库个人生词本”双轨并行。基础词库来自一套开源高频词表保留约3500个日常高频词。导入时我做了很必要的预处理把纯人名、地名、缩写全部删掉单词统一小写后再去重按字母顺序排列。每个词条只保留四个字段word、phonetic、meaning、sentence例句来自开源例句库每个词固定关联一句。一开始我把全量词库直接打进前端包结果包体一下就涨了几百KB小程序首次启动解析也变慢。后来我改成把词库放到云数据库里用户首次进入时按需拉取再写入本地缓存。缓存里存一个版本号只有版本号变化时才做增量更新。这个设计的收益在后续迭代中会越来越明显不管词库怎么扩充老用户的数据都能平滑升级不用重新下载全量包。2.2 朗读功能封装播放队列和语音停顿引入同声传译插件后我做了一个特别薄的封装函数。这里最关键的点是直接TTS播一个单词容易被截断。部分手机上音频播报的完成回调有延迟如果判断播放完成的时机太早下一个词就紧跟上来听感里单词末尾的辅音像被切掉一样。为了解决这个问题我给每个单词的播放末尾加了一段100到300毫秒的静音缓冲具体长度按用户设置的语速动态计算语速越快静音间隙越小。听写模式和朗读模式的停顿逻辑是完全分开的。朗读模式在单词之间只停500毫秒维持节奏听写模式必须在读完一个词后停3到8秒留给用户敲键盘的时间。这个停顿间隔我做成了设置页里的滑块默认5秒。不要小看这个参数间隔太短根本来不及把单词敲完太长又会走神实测下来多数人最喜欢5秒。我在封装里维护了一个全局播放队列确保同一时间只播一个音频外层调用只要按顺序塞进去就行核心逻辑大概是这样function speak(text, options {}) { playQueue.push({ text, rate: options.rate || 1, pause: options.pause || 300, callback: options.callback }); if (!playLock) { playLock true; runPlayQueue(); } } function runPlayQueue() { if (!playQueue.length) { playLock false; return; } const item playQueue.shift(); const tts plugin.getTTS(); tts.start({ text: item.text, rate: item.rate, callback: () { setTimeout(() { item.callback item.callback(); runPlayQueue(); }, item.pause); } }); }这里有两个细节容易踩坑。第一回调不只是用来通知“播完了”它更重要的职责是更新界面上的“当前播到第几个词”好让列表高亮和进度条同步。第二大段文本不要一次性丢给TTS。朗读例句时TTS对长文本的表现并不稳定更合理的做法是按标点把例句拆成短句一句一句放入队列句间停顿500毫秒听感更有节奏。2.3 音色选择好听不等于适合听写插件提供好几套音色我逐个试过。最终选定的是一套发音清晰的美音女声作为默认。这里有一个很容易被忽略的教训听写场景下用户对读音的辨识度要求特别高。“好听”不等于“清晰”。有的音色很自然但词尾的t、d容易吞听写时就会频繁踩雷有的音色偏机械但每一个音节都清清楚楚反而更适合背单词工具。所以我把辨识度最高的音色设成固定默认只在设置页提供一个开关允许用户换到备选音色。我故意没有把所有音色都摊在用户面前因为选择太多也会让一个工具显得复杂。工具类小程序的目标是让用户三秒钟进入学习状态而不是先研究十分钟设置项。2.4 自定义词单和批量导入很多背单词的人手里都有一份自建生词本形式就是来回换行的纯文本。我在“我的词单”页面做了批量导入功能规则很简单每行一个词条支持两种格式要么只写单词要么写“单词 中文释义”用空格或Tab分隔。如果只有单词小程序会去基础词库自动补全释义基础词库找不到的词就用“待补充”占位并提示用户手动编辑。这个功能帮我解决了最大的迁移成本。我的备忘录里攒了六百多个生词复制粘贴进去几十秒就全部导完。手动编辑单个词条也同样支持点击列表中的编辑按钮弹层里可以修改释义或补充一个个人例句。所有数据都保存到云数据库本地同时缓存一份完全不需要自己搭后端。初次进入时如果没网小程序会先读本地缓存等有网了再悄悄同步体验不会受影响。3. 听写模式与错词本让拼写检查有反馈、有记忆3.1 听写的三种形态纯听、提示首字母、看释义反写听写不能只是一个“听—写—对错”的无脑循环。我设计了三种形态用户在做测试的时候随时切换。第一种是纯听写只播放单词界面上除了一个“再听一遍”的按钮什么都没有适合已经复习过两三遍的词第二种是提示首字母播放单词后输入框上方显示首字母剩下的字母用下划线占位帮用户找回记忆的抓手第三种是中文释义提示播放单词以后不显示拼写只显示中文释义让用户根据释义反写英文单词。三种模式用标签页切换设计上很轻量体验上的差异却非常明显复习阶段用第二种临睡前自我检测用第一种冲刺强化阶段用第三种各有各的使用时机。提交答案后的反馈也不是简单的“对与否”。我做了一个三档判定完全正确、拼写错误但发音接近、拼写错误。第二档“发音接近”是用编辑距离算出来的属于一个偏娱乐性的鼓励机制。它不会影响错词统计但能显著降低用户连续答错时的挫败感很多人会为了看到“接近”的提示再多拼两次。3.2 输入归一化别让空格和大小写误杀答案用户输入拼写时最常见的脏数据有三种首字母大写、末尾多了一个空格、把单词里的连字符输成了空格。这些如果直接拿去和标准答案做字符串比较一定会误判。我在提交判定前统一做归一化处理去掉首尾空白、全部转成小写、把空白字符替换成连字符然后再进行严格比较。实际操作中我还观察到一个很有意思的现象听写模式下用户特别急于敲完字母去按确定结果经常因为少一个字母被判定为错误。为了减少这种挫败我在界面上把“确认答案”按钮做得很大同时放了一个小一号的“偷看答案”按钮。“确认答案”会计入结果“偷看答案”不会。看似是小的交互设计但对连续做五十个词的听写任务来说体验差距非常大。核心判定代码很短function normalizeInput(raw) { return raw.trim().toLowerCase().replace(/\s/g, -); } function checkAnswer(input, target) { const a normalizeInput(input); const b normalizeInput(target); if (a b) return correct; const dist editDistance(a, b); if (dist Math.min(2, b.length / 4)) return close; return wrong; }我给“接近”设了两个条件编辑距离不超过2同时不超过目标词长度的四分之一。这个阈值很宽松因为“接近”本来就是给台阶不是考试评分。真正的目的是让那些记不准的词在错词本里留下记录而不是用一次失败去打击用户的练习热情。3.3 错词本不仅仅是把错词塞进数组错词本不是简单把错词推到一个数组里。我设计了一个独立的错词表字段包含单词、中文释义、错误次数、最近一次错误时间、连续错误次数。连续错误次数是后来加上的字段效果很明显如果一个单词连续三次拼错它就进入高优先级队列在下一轮朗读模式里至少被朗读三遍属于强制强化如果只是偶发一次错误它只会排进普通错词队列不会一直刷存在感。这个设计的灵感来自我自己的学习习惯。把偶尔拼错和系统性拼错混在一起处理很容易让人产生“我怎么什么记不住”的无力感。错词本的学习速度也可以调整系统默认每天安排巩固上一批错词中的前10个用户还能手动把某个词标记为“已掌握”把它从错词本里移出去。移出去的时候我会弹一个提示告诉它只是从错词本移除基础词库里的词并不会消失避免用户误以为以后再也见不到这个单词。3.4 听写间隔固定好“播完后再停”的时间前面提到听写间隔默认是5秒实际开发时我做了3秒、5秒、8秒三档设置页里可以自定义。但这里有一个隐藏问题朗读一个长单词比如“communication”时长可能超过2秒那么“上一次单词结束”到“下一次单词开始”的时间要怎么算如果做成固定间隔容易让用户觉得节奏不稳。我最终放弃固定间隔改为“播完后停X秒”。这样用户实际可用的书写时间大约等于停顿时间加上单词本身的播放时间长单词播放更久留给书写的时间也更长符合直觉。这个细节看起来很小但在连续听写30个词的任务里直接影响整体的舒适度和完成率。实现时就是前面封装函数里的pause参数在朗读模式下传入500在听写模式下传入用户设置的停顿秒数乘以1000底层完全复用同一个播放队列。3.5 后台锁屏播放部分机型能做到的折中方案通勤场景下熄屏听单词是刚需。但我测试后发现小程序在绝大多数情况下一旦退到后台或者屏幕熄灭音频很快就会被系统暂停。我翻了很多资料最终只做到了“部分机型在朗读页面下可以继续播”。具体做法是在朗读页面初始化一个独立的播放管理控制器引导用户把小程序添加到“我的小程序”并在系统设置里开启后台朗读权限。我也在页面底部诚实地写了一个小提示无法在锁屏后无条件连续朗读。这个约束其实不是一个技术遗憾更像一种产品取舍。用户真的需要后台播报时可以退而求其次把小程序的音量调到最大、播放一两组词后再按需唤醒。好在单词学习这种短音频场景对后台连续播放的依赖并不强比起折腾更多系统权限我更愿意把时间花在听写准确率上。4. 20天里最磨人的几个坑和处理方法4.1 读到特殊字符语音内容无效上线前我自己导入了一批词单第一个崩溃的瞬间是某些单词读不了插件直接返回“无效的语音内容”。排查下来发现是文本里带了特殊字符比如“c/o”“3D”“COVID-19”这种。TTS引擎对数字、斜杠、点号的处理很不稳定一旦混进去就可能整个队列都不播。后来我在speak函数内部加了一个文本清洗步骤所有非字母、数字和常见标点统一剥离必要时把含特殊字符的词拆成子片段播放例如把“COVID-19”拆成“COVID 19”。这个处理对整个上层调用是无感知的朗读列表、听写题、例句都能自动走同一套清洗逻辑。加了这层保险以后再没有遇到过无效内容的报错。4.2 iOS和Android的停顿节奏差异开发早期我把听写间隔做成了固定值自己在Android手机上测试觉得节奏刚好换到iOS上就发现间隔明显变长像是卡住了一样。原因是两个平台对TTS播放结束回调的精度不一致。Android部分机型在音频实际停止前就可能触发成功回调导致播放队列推进太快iOS却经常滞后给我的感觉是半天没反应。解决方案是不要过度依赖“播放结束”回调改用“播放开始回调预估时长”兜底。我对每个单词的预估播放时长做了粗略计算只有同时满足两个条件才播下一个结束回调已经触发且距离播放开始时间不少于一个最短时长。这套机制上线后双端听感基本对齐了。后来我总结了一个通用经验在跨平台音频场景里“回调精准”永远是奢望代码里必须自己做兜底。4.3 蓝牙耳机没声音、只响一边戴蓝牙耳机背单词时我遇到了一个很普遍的坑部分蓝牙耳机在Android手机上的媒体音量和通话音量是分开管理的如果媒体音量被调低TTS播放时会完全没有声音或者是从听筒出声。排查之后我在每次进入朗读页面时都主动把音频管理器设置成媒体音量流并在页面启动时读取当前音量如果低于30%就弹一个比较轻的提示引导用户调高音量而不是让用户误以为小程序坏了。至于耳机“一边响一边不响”的问题主要是音频焦点抢占造成的。连续播放场景下每次都重新申请音频焦点可能会触发系统的焦点释放策略。我改成在进入朗读页面时申请一次音频焦点整个播放过程中复用不再反复申请问题基本没有再出现。如果你只是自己开发这些坑可能很隐蔽但一旦要分享给朋友用不同机型的差异立刻就会被放大。4.4 审核被拒绝一次之后我学到了什么准备发布的时候我被驳回了一次反馈写的是“听写模式下用户输入错误后出错提示不够清晰建议增加可见性”。作为开发者我本来觉得红绿颜色已经够直观但审核人员明显更关注色彩盲用户和无障碍场景。后来我在结果反馈区域增加了“正确/错误”文字标签错误时单词正确拼写会放大显示提交按钮文案也会动态变化为“继续/再听一遍/看答案”这才通过。这件事让我明白哪怕是一个小众工具类小程序也要在无障碍和可读性上做一些基础设计。红绿色块并不是通用语言文字和动效叠加才能覆盖更多人。这次调整本身也不复杂但对最终的上线起到了决定性作用。4.5 为什么我放弃了真人发音音源开发到中间我差一点引入真人发音包。某平台确实提供了一套覆盖两三千词的发音资源但我最终还是放弃了。原因很现实一个音频文件塞进包体至少让安装包增加10MB以上非常容易触达小程序的体积限制更重要的是个人词单里的单词会长出音源覆盖范围一旦出现“某个词没有真人音频”体验就立刻断裂。只要不是固定在考试大纲词表内TTS是唯一能保证“所有词都能读”的方案。合成音色在反复使用后会慢慢觉得习惯用户的耳朵也会适应。对于背单词这种偏功能性的工具来说稳定覆盖比音色自然更重要这也是我整个项目中反复出现的选择标准。5. 上线后的观察、迭代方向和个人体会5.1 真实使用数据原来大家都在睡前听写小程序发到一个小型学习圈子后我看到了几组很有意思的使用行为。绝大多数人集中在晚上10点以后打开听写模式和我的使用习惯几乎一模一样属于典型的“睡前复盘场景”。还有一部分人把自定义词单当成“课堂抓词工具”每节课结束就把新词丢进去当晚做完听写再睡觉。最意外的是有人同时用两个设备学习手机负责朗读平板负责输入。背后的诉求其实是学习记录同步。我的错词本已经存在云数据库但每日学习进度仍存在本地于是我在设置页补了一个“进度同步”开关用户可以把自己的当日学习进度也上传到云端换设备后登录同一个账号就能拉取。这个小改动不大但让工具一下子有了“正经产品”的质感。5.2 后续想做发音评分和记忆曲线调度下一版最想加的是发音评分。技术路线已经比较清晰利用插件自带的语音识别能力让用户跟读一个单词然后把识别结果和原词做对比给出一个0到100的分数。这个功能在界面上只需要加一个“跟读模式”但实际难点在于提示用户开始说、检测静音、判断说话结束这些都要反复调参数不是一两个晚上能实现完的。记忆曲线调度是另一个想做的方向。目前错词本里的“连续错误次数”只是一个粗糙的优先级信号并没有精细到用间隔重复算法来安排每个词的最佳复习时间。如果能抽出时间我希望把每日任务真正变成一个由数据驱动的复习计划而不是简单的顺序队列。这两个方向都会继续做但不会为了功能全而牺牲稳定性。5.3 最后分享一点个人的真实体会20天写完这个小程序最大的收获不是代码量而是“项目收敛”的能力。我先圈定只能做什么再往圈子里填细节直到上线都没有推翻过一次核心模块。第二点体会是工具类小程序的第一版不需要完美能把一条核心闭环跑顺比什么都重要。很多细节比如停顿时间、错词反馈、后台播放限制都是自己用了一段时间以后才逐步调整出来的边用边改才是个人项目最自然的迭代方式。第三点做个人工具时官方能力只要够用就先别引入花活。我一开始差点因为“技术上的高级感”去上一个额外框架后来全砍了反而是最省心的操作。最后分享一个我每天会用的小方法晚上听完一批新词后把生成的错词表格导出来放进手机备忘录第二天早高峰时在地铁上自己考自己一遍。这个习惯让我半个月内在同一个错词本里的存量下降了不少。如果你也在做类似的单词学习工具这篇复盘里的方案可以直接抄也希望你的“捣鼓20天”能和我一样最终变成每天都会打开的工具。
做小程序这事起因特别简单。我白天写代码晚上背单词结果发现市面上那些App要么强制登录要么听写功能藏在会员后面要么内置词单根本改不了。有一天下班我实在忍不住决定自己写一个。于是用了大概20天下班后的时间捣鼓出一个能朗读、能听写的单词小程序。不吹牛现在每天用它过30个旧词加10个新词已经变成习惯错词本里那几十个“老顽固”也慢慢被清零了。这篇文章就把这段时间踩过的坑、做过的方案对比、以及核心实现逻辑一次说清楚如果你也在琢磨自己做一个小程序或者打算做一个背单词小工具应该能少走不少弯路。1. 动手之前需求、技术选型和功能边界1.1 先盘点自己的真实痛点市面上背单词工具很多但有几个点一直让我难受。第一很多App的听写本质上是个“填空选择题”我把单词拼写敲进去以后它给一个分数可是过程里它压根没有把单词“读”清楚很多时候我听不出到底是i还是e。第二词单不可编辑。我自己的生词本存在系统备忘录里App里根本导不进去一个个手打太痛苦。第三我想在通勤、做家务的时候“听”单词而不是一直盯着屏幕但大多数App的朗读模式会把中文解释一起读出来啰嗦又拖沓。归纳下来就三个需求能按我的词单朗读、能在朗读后留出停顿让我听写、能把拼写错的和漏听的自动收集起来。这三个点单独拎出来都不复杂凑到一个App里还要免费无广告就只能自己动手。那段时间我的场景特别具体下班回到家把今天积累的生词丢进小程序洗漱时让它一个词一个词地读我在心里拼一遍再掏出手机验证。这种需求太小众指望大厂产品经理安排上不太现实自己动手是唯一的解。1.2 为什么最终选了小程序原生开发在技术方案上我纠结了很久。一开始想用跨端框架基于Web技术来写理由是以后可能想上其他平台不想写两遍。但把实际功能列了一版以后我发现这个项目其实特别轻词单管理、朗读、听写、设置核心就是和小程序底层音频能力打交道。跨端框架在这里能帮上的忙不多反而会引入一层抽象出了问题以后排查路径更长。我最后选择用小程序原生技术栈三个原因。一是文档和工具链最成熟报错了上网一搜基本都能找到答案二是音频播放、插件市场这些能力在原生环境里最稳定用框架反而要处理不同平台的兼容差异三是这个项目完全不需要双端复用也不用“未来一定怎样”的假设。技术选型由此确定。说到底小项目最忌讳的是为了“以后可能怎样”去选一个现在更复杂的方案。项目周期只有20天任何不必要的复杂度都是在给自己埋雷。1.3 真人录音包和TTS合成怎么权衡做朗读功能第一反应是找真人录音包。我在网上翻了很久发现很多开放词库附带的音频要么只覆盖两三千个高频词要么就是不同来源的声音混在一起音色根本不统一。如果只是做考试词表勉强能撑住但我的生词本里经常有专业词、人名、地名这些一旦没有录音小程序就“哑”了体验非常割裂。所以我转向文本转语音方案。小程序生态里有一个官方同声传译插件提供语音识别和文本转语音能力英文、中文都能读而且直接在手机本地调用不需要额外的后台服务。实测下来它的发音清晰语速和音调可调完全能覆盖“听写”场景。配置成本很低不需要自己搭服务转发。后续就算词表存到一万词合成方案也不用改数据。真人音源确实自然但对一个20天要上线的个人项目来说TTS的可维护性远远胜出。1.4 功能边界第一版坚决不做五件事第一版我给自己定了几条硬规则只做核心闭环不做登录、不做收费、不做社区、不做社交分享。核心闭环就是“选词单—朗读—听写—错词本”每一步都不能省。登录涉及到用户信息授权和隐私协议收费涉及支付权限分享涉及内容合规这些都不是20天能妥善处理的再说个人使用也不需要它们。把这些需求划掉以后工作量一下清晰了。具体拆下来数据层大概1天页面骨架3天语音模块4天听写交互2天串流程和测试3天最后剩下时间全用来调细节。实际开发还是比计划多花了几天但“先划功能边界再排期”这个动作保证了我没有在开发到一半时临时加需求。小工具类项目的通病就是越做越大边界不划清20天很可能连一个能跑的版本都出不来。2. 词库、朗读和音频参数让小程序开口说话2.1 词库数据从哪里来、怎么清洗词库是工具的灵魂但我不可能在20天内手工整理几千个词。我的做法是“基础词库个人生词本”双轨并行。基础词库来自一套开源高频词表保留约3500个日常高频词。导入时我做了很必要的预处理把纯人名、地名、缩写全部删掉单词统一小写后再去重按字母顺序排列。每个词条只保留四个字段word、phonetic、meaning、sentence例句来自开源例句库每个词固定关联一句。一开始我把全量词库直接打进前端包结果包体一下就涨了几百KB小程序首次启动解析也变慢。后来我改成把词库放到云数据库里用户首次进入时按需拉取再写入本地缓存。缓存里存一个版本号只有版本号变化时才做增量更新。这个设计的收益在后续迭代中会越来越明显不管词库怎么扩充老用户的数据都能平滑升级不用重新下载全量包。2.2 朗读功能封装播放队列和语音停顿引入同声传译插件后我做了一个特别薄的封装函数。这里最关键的点是直接TTS播一个单词容易被截断。部分手机上音频播报的完成回调有延迟如果判断播放完成的时机太早下一个词就紧跟上来听感里单词末尾的辅音像被切掉一样。为了解决这个问题我给每个单词的播放末尾加了一段100到300毫秒的静音缓冲具体长度按用户设置的语速动态计算语速越快静音间隙越小。听写模式和朗读模式的停顿逻辑是完全分开的。朗读模式在单词之间只停500毫秒维持节奏听写模式必须在读完一个词后停3到8秒留给用户敲键盘的时间。这个停顿间隔我做成了设置页里的滑块默认5秒。不要小看这个参数间隔太短根本来不及把单词敲完太长又会走神实测下来多数人最喜欢5秒。我在封装里维护了一个全局播放队列确保同一时间只播一个音频外层调用只要按顺序塞进去就行核心逻辑大概是这样function speak(text, options {}) { playQueue.push({ text, rate: options.rate || 1, pause: options.pause || 300, callback: options.callback }); if (!playLock) { playLock true; runPlayQueue(); } } function runPlayQueue() { if (!playQueue.length) { playLock false; return; } const item playQueue.shift(); const tts plugin.getTTS(); tts.start({ text: item.text, rate: item.rate, callback: () { setTimeout(() { item.callback item.callback(); runPlayQueue(); }, item.pause); } }); }这里有两个细节容易踩坑。第一回调不只是用来通知“播完了”它更重要的职责是更新界面上的“当前播到第几个词”好让列表高亮和进度条同步。第二大段文本不要一次性丢给TTS。朗读例句时TTS对长文本的表现并不稳定更合理的做法是按标点把例句拆成短句一句一句放入队列句间停顿500毫秒听感更有节奏。2.3 音色选择好听不等于适合听写插件提供好几套音色我逐个试过。最终选定的是一套发音清晰的美音女声作为默认。这里有一个很容易被忽略的教训听写场景下用户对读音的辨识度要求特别高。“好听”不等于“清晰”。有的音色很自然但词尾的t、d容易吞听写时就会频繁踩雷有的音色偏机械但每一个音节都清清楚楚反而更适合背单词工具。所以我把辨识度最高的音色设成固定默认只在设置页提供一个开关允许用户换到备选音色。我故意没有把所有音色都摊在用户面前因为选择太多也会让一个工具显得复杂。工具类小程序的目标是让用户三秒钟进入学习状态而不是先研究十分钟设置项。2.4 自定义词单和批量导入很多背单词的人手里都有一份自建生词本形式就是来回换行的纯文本。我在“我的词单”页面做了批量导入功能规则很简单每行一个词条支持两种格式要么只写单词要么写“单词 中文释义”用空格或Tab分隔。如果只有单词小程序会去基础词库自动补全释义基础词库找不到的词就用“待补充”占位并提示用户手动编辑。这个功能帮我解决了最大的迁移成本。我的备忘录里攒了六百多个生词复制粘贴进去几十秒就全部导完。手动编辑单个词条也同样支持点击列表中的编辑按钮弹层里可以修改释义或补充一个个人例句。所有数据都保存到云数据库本地同时缓存一份完全不需要自己搭后端。初次进入时如果没网小程序会先读本地缓存等有网了再悄悄同步体验不会受影响。3. 听写模式与错词本让拼写检查有反馈、有记忆3.1 听写的三种形态纯听、提示首字母、看释义反写听写不能只是一个“听—写—对错”的无脑循环。我设计了三种形态用户在做测试的时候随时切换。第一种是纯听写只播放单词界面上除了一个“再听一遍”的按钮什么都没有适合已经复习过两三遍的词第二种是提示首字母播放单词后输入框上方显示首字母剩下的字母用下划线占位帮用户找回记忆的抓手第三种是中文释义提示播放单词以后不显示拼写只显示中文释义让用户根据释义反写英文单词。三种模式用标签页切换设计上很轻量体验上的差异却非常明显复习阶段用第二种临睡前自我检测用第一种冲刺强化阶段用第三种各有各的使用时机。提交答案后的反馈也不是简单的“对与否”。我做了一个三档判定完全正确、拼写错误但发音接近、拼写错误。第二档“发音接近”是用编辑距离算出来的属于一个偏娱乐性的鼓励机制。它不会影响错词统计但能显著降低用户连续答错时的挫败感很多人会为了看到“接近”的提示再多拼两次。3.2 输入归一化别让空格和大小写误杀答案用户输入拼写时最常见的脏数据有三种首字母大写、末尾多了一个空格、把单词里的连字符输成了空格。这些如果直接拿去和标准答案做字符串比较一定会误判。我在提交判定前统一做归一化处理去掉首尾空白、全部转成小写、把空白字符替换成连字符然后再进行严格比较。实际操作中我还观察到一个很有意思的现象听写模式下用户特别急于敲完字母去按确定结果经常因为少一个字母被判定为错误。为了减少这种挫败我在界面上把“确认答案”按钮做得很大同时放了一个小一号的“偷看答案”按钮。“确认答案”会计入结果“偷看答案”不会。看似是小的交互设计但对连续做五十个词的听写任务来说体验差距非常大。核心判定代码很短function normalizeInput(raw) { return raw.trim().toLowerCase().replace(/\s/g, -); } function checkAnswer(input, target) { const a normalizeInput(input); const b normalizeInput(target); if (a b) return correct; const dist editDistance(a, b); if (dist Math.min(2, b.length / 4)) return close; return wrong; }我给“接近”设了两个条件编辑距离不超过2同时不超过目标词长度的四分之一。这个阈值很宽松因为“接近”本来就是给台阶不是考试评分。真正的目的是让那些记不准的词在错词本里留下记录而不是用一次失败去打击用户的练习热情。3.3 错词本不仅仅是把错词塞进数组错词本不是简单把错词推到一个数组里。我设计了一个独立的错词表字段包含单词、中文释义、错误次数、最近一次错误时间、连续错误次数。连续错误次数是后来加上的字段效果很明显如果一个单词连续三次拼错它就进入高优先级队列在下一轮朗读模式里至少被朗读三遍属于强制强化如果只是偶发一次错误它只会排进普通错词队列不会一直刷存在感。这个设计的灵感来自我自己的学习习惯。把偶尔拼错和系统性拼错混在一起处理很容易让人产生“我怎么什么记不住”的无力感。错词本的学习速度也可以调整系统默认每天安排巩固上一批错词中的前10个用户还能手动把某个词标记为“已掌握”把它从错词本里移出去。移出去的时候我会弹一个提示告诉它只是从错词本移除基础词库里的词并不会消失避免用户误以为以后再也见不到这个单词。3.4 听写间隔固定好“播完后再停”的时间前面提到听写间隔默认是5秒实际开发时我做了3秒、5秒、8秒三档设置页里可以自定义。但这里有一个隐藏问题朗读一个长单词比如“communication”时长可能超过2秒那么“上一次单词结束”到“下一次单词开始”的时间要怎么算如果做成固定间隔容易让用户觉得节奏不稳。我最终放弃固定间隔改为“播完后停X秒”。这样用户实际可用的书写时间大约等于停顿时间加上单词本身的播放时间长单词播放更久留给书写的时间也更长符合直觉。这个细节看起来很小但在连续听写30个词的任务里直接影响整体的舒适度和完成率。实现时就是前面封装函数里的pause参数在朗读模式下传入500在听写模式下传入用户设置的停顿秒数乘以1000底层完全复用同一个播放队列。3.5 后台锁屏播放部分机型能做到的折中方案通勤场景下熄屏听单词是刚需。但我测试后发现小程序在绝大多数情况下一旦退到后台或者屏幕熄灭音频很快就会被系统暂停。我翻了很多资料最终只做到了“部分机型在朗读页面下可以继续播”。具体做法是在朗读页面初始化一个独立的播放管理控制器引导用户把小程序添加到“我的小程序”并在系统设置里开启后台朗读权限。我也在页面底部诚实地写了一个小提示无法在锁屏后无条件连续朗读。这个约束其实不是一个技术遗憾更像一种产品取舍。用户真的需要后台播报时可以退而求其次把小程序的音量调到最大、播放一两组词后再按需唤醒。好在单词学习这种短音频场景对后台连续播放的依赖并不强比起折腾更多系统权限我更愿意把时间花在听写准确率上。4. 20天里最磨人的几个坑和处理方法4.1 读到特殊字符语音内容无效上线前我自己导入了一批词单第一个崩溃的瞬间是某些单词读不了插件直接返回“无效的语音内容”。排查下来发现是文本里带了特殊字符比如“c/o”“3D”“COVID-19”这种。TTS引擎对数字、斜杠、点号的处理很不稳定一旦混进去就可能整个队列都不播。后来我在speak函数内部加了一个文本清洗步骤所有非字母、数字和常见标点统一剥离必要时把含特殊字符的词拆成子片段播放例如把“COVID-19”拆成“COVID 19”。这个处理对整个上层调用是无感知的朗读列表、听写题、例句都能自动走同一套清洗逻辑。加了这层保险以后再没有遇到过无效内容的报错。4.2 iOS和Android的停顿节奏差异开发早期我把听写间隔做成了固定值自己在Android手机上测试觉得节奏刚好换到iOS上就发现间隔明显变长像是卡住了一样。原因是两个平台对TTS播放结束回调的精度不一致。Android部分机型在音频实际停止前就可能触发成功回调导致播放队列推进太快iOS却经常滞后给我的感觉是半天没反应。解决方案是不要过度依赖“播放结束”回调改用“播放开始回调预估时长”兜底。我对每个单词的预估播放时长做了粗略计算只有同时满足两个条件才播下一个结束回调已经触发且距离播放开始时间不少于一个最短时长。这套机制上线后双端听感基本对齐了。后来我总结了一个通用经验在跨平台音频场景里“回调精准”永远是奢望代码里必须自己做兜底。4.3 蓝牙耳机没声音、只响一边戴蓝牙耳机背单词时我遇到了一个很普遍的坑部分蓝牙耳机在Android手机上的媒体音量和通话音量是分开管理的如果媒体音量被调低TTS播放时会完全没有声音或者是从听筒出声。排查之后我在每次进入朗读页面时都主动把音频管理器设置成媒体音量流并在页面启动时读取当前音量如果低于30%就弹一个比较轻的提示引导用户调高音量而不是让用户误以为小程序坏了。至于耳机“一边响一边不响”的问题主要是音频焦点抢占造成的。连续播放场景下每次都重新申请音频焦点可能会触发系统的焦点释放策略。我改成在进入朗读页面时申请一次音频焦点整个播放过程中复用不再反复申请问题基本没有再出现。如果你只是自己开发这些坑可能很隐蔽但一旦要分享给朋友用不同机型的差异立刻就会被放大。4.4 审核被拒绝一次之后我学到了什么准备发布的时候我被驳回了一次反馈写的是“听写模式下用户输入错误后出错提示不够清晰建议增加可见性”。作为开发者我本来觉得红绿颜色已经够直观但审核人员明显更关注色彩盲用户和无障碍场景。后来我在结果反馈区域增加了“正确/错误”文字标签错误时单词正确拼写会放大显示提交按钮文案也会动态变化为“继续/再听一遍/看答案”这才通过。这件事让我明白哪怕是一个小众工具类小程序也要在无障碍和可读性上做一些基础设计。红绿色块并不是通用语言文字和动效叠加才能覆盖更多人。这次调整本身也不复杂但对最终的上线起到了决定性作用。4.5 为什么我放弃了真人发音音源开发到中间我差一点引入真人发音包。某平台确实提供了一套覆盖两三千词的发音资源但我最终还是放弃了。原因很现实一个音频文件塞进包体至少让安装包增加10MB以上非常容易触达小程序的体积限制更重要的是个人词单里的单词会长出音源覆盖范围一旦出现“某个词没有真人音频”体验就立刻断裂。只要不是固定在考试大纲词表内TTS是唯一能保证“所有词都能读”的方案。合成音色在反复使用后会慢慢觉得习惯用户的耳朵也会适应。对于背单词这种偏功能性的工具来说稳定覆盖比音色自然更重要这也是我整个项目中反复出现的选择标准。5. 上线后的观察、迭代方向和个人体会5.1 真实使用数据原来大家都在睡前听写小程序发到一个小型学习圈子后我看到了几组很有意思的使用行为。绝大多数人集中在晚上10点以后打开听写模式和我的使用习惯几乎一模一样属于典型的“睡前复盘场景”。还有一部分人把自定义词单当成“课堂抓词工具”每节课结束就把新词丢进去当晚做完听写再睡觉。最意外的是有人同时用两个设备学习手机负责朗读平板负责输入。背后的诉求其实是学习记录同步。我的错词本已经存在云数据库但每日学习进度仍存在本地于是我在设置页补了一个“进度同步”开关用户可以把自己的当日学习进度也上传到云端换设备后登录同一个账号就能拉取。这个小改动不大但让工具一下子有了“正经产品”的质感。5.2 后续想做发音评分和记忆曲线调度下一版最想加的是发音评分。技术路线已经比较清晰利用插件自带的语音识别能力让用户跟读一个单词然后把识别结果和原词做对比给出一个0到100的分数。这个功能在界面上只需要加一个“跟读模式”但实际难点在于提示用户开始说、检测静音、判断说话结束这些都要反复调参数不是一两个晚上能实现完的。记忆曲线调度是另一个想做的方向。目前错词本里的“连续错误次数”只是一个粗糙的优先级信号并没有精细到用间隔重复算法来安排每个词的最佳复习时间。如果能抽出时间我希望把每日任务真正变成一个由数据驱动的复习计划而不是简单的顺序队列。这两个方向都会继续做但不会为了功能全而牺牲稳定性。5.3 最后分享一点个人的真实体会20天写完这个小程序最大的收获不是代码量而是“项目收敛”的能力。我先圈定只能做什么再往圈子里填细节直到上线都没有推翻过一次核心模块。第二点体会是工具类小程序的第一版不需要完美能把一条核心闭环跑顺比什么都重要。很多细节比如停顿时间、错词反馈、后台播放限制都是自己用了一段时间以后才逐步调整出来的边用边改才是个人项目最自然的迭代方式。第三点做个人工具时官方能力只要够用就先别引入花活。我一开始差点因为“技术上的高级感”去上一个额外框架后来全砍了反而是最省心的操作。最后分享一个我每天会用的小方法晚上听完一批新词后把生成的错词表格导出来放进手机备忘录第二天早高峰时在地铁上自己考自己一遍。这个习惯让我半个月内在同一个错词本里的存量下降了不少。如果你也在做类似的单词学习工具这篇复盘里的方案可以直接抄也希望你的“捣鼓20天”能和我一样最终变成每天都会打开的工具。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
