我是在被一个背单词软件“按时复习”逼疯之后才决定趁手头有点大模型资源自己做一款AI驱动的英语学习APP。这项目前前后后花了大概四个月从产品原型、Prompt设计、端到端链路联调到最后上架两端的应用市场踩过的坑比预期多得多。这篇文章我把整个开发过程里最核心的决策和教训拆出来讲适合独立开发者、移动端程序员、AI应用产品经理以及所有想用生成式AI做C端产品的人参考。我不会只罗列功能也不会只贴概念图而是尽量把“为什么这样设计”和“实际开发中哪里会翻车”讲清楚。毕竟这类产品最大的问题不是写不出代码而是AI生成内容不可控、语音链路延迟高、单用户成本压不住。这些问题不解决再漂亮的界面也留不住用户。1. 为什么我把英语学习App押注在生成式AI上需求验证与产品边界1.1 现有英语工具的不足在哪里我一开始没有急着写代码先把自己当成重度用户把主流英语学习产品重新用了一遍。背单词类工具普遍的问题是“管理”功能远大于“理解”功能。它们帮你安排复习计划、记录遗忘曲线但一个单词为什么这样拼、什么语境下用、和近义词差在哪里完全靠用户自己去查。听力类工具则是固定语料库今天听的和昨天听的难度差不多水平上去以后就感觉整套内容变成了低效重复。真人外教课确实是好的方向但价格和约课时间成本摆在那对上班族来说很难做到每天半小时持续沉浸。通用聊天机器人我也试过英文对话能力不错但问题在于它们“太配合”了。你说错了它为了保持对话流畅往往会顺着你的错误理解继续聊而不是指出你其实少了一个冠词或者时态用错了。这种不够“较真”的反馈恰恰是语言学习里最致命的问题。这些痛点总结起来就是三个内容不个性化、反馈不及时、成本下不来。生成式AI正好能把这三件事一起解决。它能根据用户水平实时生成阅读材料能在对话里做温和但明确的纠正而且单位调用成本随着模型迭代持续下降。所以我判断这个赛道不是在PPT上炒概念而是真的有产品空间。1.2 AI能带来多少增量价值我把AI介入英语学习的价值拆成四个层次按实用程度从高到低排即时反馈用户说一句英文App能立刻告诉他哪里不自然、怎么改更地道。这是传统App很难做好的事因为规则语法只能查“对不对”查不了“好不好”。无限可变的练习材料背单词不是换个例句就完了而是可以生成一段包含这个单词的小故事让用户在上下文里重新遇到它。阅读材料也可以按用户当前词汇量动态生成而不是永远停留在“新概念英语第二册”。个性化节奏根据用户的错题和遗忘曲线调整后续内容的难度和复习频率。这里不需要特别复杂的算法简单的数据记录加Prompt里的词汇表控制就够了。陪伴感AI口语陪练可以24小时在线用户可以随时进入一个场景对话比如“在机场换登机牌”或者“和房东讨论租房问题”。这种沉浸感是静态题库做不到的。但我也必须泼一盆冷水。生成式AI并不是万能老师。它不适合做高风险的应试精确批改比如雅思写作的最终打分也不适合做需要强教学策略的零基础启蒙。这类场景一旦模型出错用户会直接失去信任。所以我的产品边界划定得很明确AI负责提供陪伴、反馈和内容生成但最终的教学节奏和用户数据必须由产品自己掌控。1.3 MVP阶段要圈定的范围为了避免做一个“什么都沾一点但什么都做不深”的AI壳子我第一版只做了四件事智能生词拆解点击一个词生成包含词根词缀、场景例句、记忆钩子的讲解。AI口语陪练按场景和用户进行多轮对话每轮会给出评分和纠正建议。个性化阅读生成根据用户词汇量生成短文并对生词进行标注。写作批改用户写一段英文短文AI按语法、用词、表达层次给出反馈。这四件事构成一个“每日30分钟学习闭环”先拆解新词再在口语和阅读里反复遇到它们最后用写作把词汇用出来。当时我没有做AI排课、没有做全自动复习提醒是因为这些功能依赖的长期用户行为数据还不够硬做很容易变成“伪智能”。2. 产品功能拆解四个AI模块的业务逻辑与Prompt设计2.1 智能生词拆解把背单词变成“搞懂一个词”传统单词卡只给释义和例句用户看似记住了其实只是建立了一个模糊映射。我希望AI拆解能让用户真正理解一个词的来龙去脉。这个模块我设计了固定的JSON输出结构Prompt里明确要求模型按字段返回方便客户端直接渲染而不是让用户看一大段刀切不断的大白话。我的Prompt核心逻辑是这样写的你是一位英语词源学老师和记忆法专家。请解析用户输入的单词。 要求 1. 输出JSON字段包括word, phonetic, root, affix, rootMeaning, meaning, example, scene, memoryTip。 2. root和affix如果不存在填null不要胡编词源。 3. meaning要区分中文释义和英文释义。 4. memoryTip要给出一个具体的谐音或图像联想不能是空洞的“联想记忆”。 5. 如果对词源不确定请在memoryTip中注明“词源不确定建议查证”。早期版本里最大的坑是模型会“一本正经地胡说八道”比如把某个词错误拆成“拉丁语词根”实际上它是日耳曼语源。为了降低这种风险我自己整理了一份包含两千多个常见词根词缀的本地知识库把拆解请求改成先从本地查表查不到再用模型生成。这样既准确又省Token。2.2 口语陪练有上下文、有反馈的双向对话口语模块最容易做成“你一句AI一句”的聊天但那和通用聊天机器人没什么区别。我的产品里加入了两个特有的东西场景约束和纠正机制。场景约束就是每个对话开始前系统先设定角色、地点、目标。比如{ role: 机场地勤人员, location: 东京成田机场值机柜台, goal: 用户需要办理国际航班登机手续并询问行李限额, difficulty: CEFR B1, strictness: medium }这个场景上下文会拼进每轮对话的系统Prompt里AI不能跳出角色。同时我要求回复结构也是一个JSON而不是纯文本{ corrected_script: I would like to check in for my flight to Boston., feedback: 这里用‘check in for’比‘check in my flight’更自然。, score: 82, fluency_note: 语速偏慢但发音清晰 }这里的核心设计是用户说完之后AI先展示一个“正确版本”的完整句子再给出针对当前错误的反馈最后才是一个总分。不要让用户自己从长篇解释里找错误要把错误指到具体位置上。如果有多轮对话后台会把前几轮的上下文、用户的错误记录全部传入模型让纠正有连续性而不是每轮都像第一次见面。2.3 阅读素材生成按用户词汇量动态出题阅读生成模块我用了“词汇表控制”的思路。用户每次进入阅读App会把他最近掌握的词汇列表发送给模型要求模型生成一篇短文同时保证以下几点不超过300词。80%以上的词汇来自用户已掌握列表。生词数量控制在5个以内。主题可选比如“科技”“生活”“旅行”。Prompt里最关键的一句话是禁止在文章中使用超出用户CEFR等级A2词汇表的高频难词如果必须使用生词请用星号*标记并在文末给出不超过两个单词的中文注释。这一手看起来简单但实际效果非常好。模型会主动把复杂表达拆成短句也会在文末用标准格式列出需要讲解的词汇。这篇文章生成完之后我会把带星号的词汇自动加入当天生词列表和智能拆解模块联动。用户读完整篇文章既完成了阅读训练又预习了明天要记的新词。2.4 写作批改从语法纠错到表达升级写作批改我一开始想做成一键“改完整篇文章”但效果并不好。用户看到一整篇改得花花绿绿的文章反而不知道重点学哪里。所以我换成分层次反馈模式第一层错误列表每条包含错误位置、错误类型、修改建议。第二层用词升级建议比如把“very good”改成“remarkable”前提是上下文匹配。第三层整体风格评价和两个具体改进方向。Prompt要求输出这样的结构{ errors: [ { original: I go to school yesterday., corrected: I went to school yesterday., type: tense, explanation: 过去时间状语yesterday要求过去时 } ], word_upgrade: [ { original_word: good, suggested_word: commendable, sentence_context: The result was commendable. } ], overall_comment: 逻辑清晰但被动语态使用偏少。, next_focus: 练习过去完成时 }这种结构化输出还有个好处就是可以自动化统计数据。哪个用户常犯时态错误哪个常用词超纲后台都能分析出来然后反哺给口语和阅读模块形成真正的个性化。我在前后端联调时最费时间的反而不是写Prompt而是设计JSON Schema和异常兜底逻辑因为模型偶尔会多返回字段或漏字段。下表整理了四个模块的输入、输出和耗时要求模块主要输入AI输出可接受耗时生词拆解单词 本地词根库单词卡片JSON1秒内口语陪练用户语音识别文本 会话上下文纠正、建议、评分JSON2秒内阅读生成用户词汇表 难度等级 主题短文HTML/JSON3秒内写作批改用户短文 最近学习记录分层反馈JSON3秒内3. 技术选型与架构设计独立开发者的取舍3.1 客户端为什么选了Flutter一个人开发iOS和Android双端不想维护两套代码这是选型的第一约束。我对比过React Native和Flutter最后选了Flutter原因很实际Flutter的渲染引擎是自绘的不同系统上UI一致性更高对语音对话界面里的动画、波形图、卡片翻转支持得更好。Dart的isolate并发模型在做录音切片、流式文本解析时很顺手不用像RN那样频繁考虑JS线程阻塞。插件生态里音频录制、播放、权限请求这些常用功能都比较稳定。当然Flutter也有坑比如第三方语音识别插件的质量参差不齐。实际开发里我最后没有用纯插件方案而是用原生端原生能力加上MethodChannel把录音和播放功能封装成一套统一的音频接口让底层平台只负责采集和播放业务逻辑全在Dart层。这样后面要换语音服务商只需要改原生端。3.2 服务端一个轻量的“AI编排网关”服务端我没有用重型框架而是选了一个很轻的FastAPI应用。它做的事情比较纯粹接收客户端的请求统一处理鉴权和频率限制。把用户学习数据、词汇表、会话上下文拼装成Prompt。调用AI模型和语音服务的SDK。把结果转化为客户端需要的JSON。这个网关的独特之处是我把每一个AI功能都抽象成了一个“能力节点”。生词拆解是一个节点口语评分是一个节点阅读生成是一个节点。每个节点都有输入Schema和输出Schema节点之间可以通过管道组合。比如口语对话节点跑完之后可以自动触发一个“提取不熟悉单词”的子节点把高频错词写入生词本。这样做的好处是当我要换底层模型时只需要改节点内部实现不需要动路由逻辑。我在开发中实测换过一次模型接口层代码完全没改只改了一个环境变量很省心。3.3 模型通道大模型、语音识别、语音合成怎么组合AI驱动的英语学习App至少涉及三条AI链路文本生成、语音识别ASR、语音合成TTS。我的选型对照如下能力我用的方案选型理由注意事项文本生成多模型网关轻量任务用小模型复杂对话用大模型控制成本复杂场景保证质量小模型偶尔会返回格式错误要有重试逻辑语音识别云端流式ASR支持中英混说英语学习者发音不标准更健壮的ASR能减少输入噪声要开启“自动标点”和“置信度”字段语音合成云端TTS支持情绪参数口语陪练需要自然度不能像机器人念稿语速要略慢于真人方便学习者跟上我强烈建议不要只绑定一家云厂商的ASR和TTS因为不同地区的网络延迟和准确率差异很大。我的架构是在网关层做一次抽象所有语音请求统一走同一个接口底层按用户IP或服务配置路由到不同服务商。这样即使在网络环境差的时候也能通过降级到单向文本对话来保住用户体验。3.4 数据存储与查询设计数据规模初期不大但有三张表必须设计好users用户ID、CEFR等级、每日目标、模型配置偏好。learning_records用户学习行为日志字段包括学习类型、内容ID、是否正确、耗时。words单词ID、拼写、定义、难度等级、词根ID。word_progress用户单词进度记录熟悉度和下次复习时间。dialog_sessions对话会话ID、场景ID、对话历史JSON、评分。这里最容易踩坑的是“对话历史存JSON还是拆表”。我一开始把完整对话历史塞进一个JSON字段确实方便但后来要统计用户常犯错误类型时查询变得很痛苦。所以我改成了一张独立的event表每轮对话产生两三条记录一条存用户输入一条存AI输出一条存评分详情。这样后面做报表和训练数据回放都很轻松。4. 两个核心链路的实现细节口语对话和阅读生成4.1 口语对练的端到端流程整个口语对练链路是录音采集 → 静音检测 → 音频切片 → 语音识别 → Prompt组装 → 大模型生成 → 结果解析 → 文本展示 → 语音合成 → 播放。这中间我遇到的第一个大坑是“静音检测”。如果等用户说完再检测停顿至少要额外等0.5到1秒体验很拖沓。我的做法是在录音过程中每200毫秒计算一次音频能量如果连续1.2秒能量低于阈值就认为用户已经说完立刻停止录音并发送给ASR。同时前端会显示一个“音频能量波形”让用户知道自己正在被识别避免他以为App卡住了。语音识别完成之后后端拿到的是文本。组装Prompt时我不会只把用户最后一句话传给模型而是把整个会话摘要一起传。会话摘要包含场景设定、之前用户的错误类型、以及最近三句话的原始文本。这样才能保证AI的反馈不是碎片化的。模型返回的JSON还会经过一次校验如果缺字段或者格式不对会重新请求一次最多重试两次。4.2 用流式响应解决“一卡一顿”的问题大模型生成整段回复通常要1到3秒如果等全部生成完再一起显示用户会觉得特别慢。口语对话这个场景我最后用了SSE流式输出。模型返回一个token就立刻推给客户端客户端把已经收到的文本先渲染出来类似打字机效果。不过流式输出也有它的麻烦TTS无法直接消费流式文本部分TTS服务需要完整片段才能合成自然语音。如果强行把不完整的句子拿去合成会听到断句很奇怪。JSON解析被截断如果输出是流式JSON可能在半路就解析失败。我的妥协方案是文本回复流式展示给用户同时等整段回复完成后再生成TTS。为了让用户等待音频时不焦虑前端会在文字流结束后自动启动一个音频加载动画。实测下来用户感知延迟从“对完话干等三秒”变成了“看着文字逐渐出现然后声音跟上”体验提升非常明显。在服务端实现时我用的是FastAPI的StreamingResponse。核心伪代码大概是async def chat_stream(request: ChatRequest): async for chunk in model_client.stream(messagesbuild_prompt(request)): yield fdata: {chunk}\n\n客户端用标准的EventSource或者Flutter的stream包去监听整体接入不算复杂。4.3 阅读生成的难度控制与词汇过滤阅读生成不是简单地给模型一个主题就能完事。我实现了两级词汇过滤。第一级是前置词汇过滤。用户发出生成请求时后端取出他的“已掌握词表”和“生词表”把这些词全部塞进Prompt并明确要求“只允许使用以下词汇表中的单词超出词汇表的单词每篇不超过5个并用星号标记。” 这个限制对模型来说是有压力的所以我会同时提供一个可选的“替换词表”让模型用同义短语替换难词。第二级是后置生词提取。模型返回文章后后端把所有带星号的生词提取出来去调用生词拆解模块生成单词卡片存进生词本。如果用户点击某个词不需要重新调用大模型直接从生词本里查卡片就好。这个二级流程让用户每次阅读短文都能自然预习5个以内新词不会因为生词过多而放弃。产品上线后不少用户反馈“每篇文章刚好能读懂又能学到新词”说明这个难度控制策略是有效的。4.4 生词本回捞和错题重练机制做英语学习App不能只把新词塞给用户就完事。我的回捞机制参考了间隔重复的简化版但不在客户端写复杂算法而是靠一个简单的数据库查询加上AI辅助每个新词初始熟悉度为0。每次用户在任何模块里遇到这个词并答对熟悉度加1。熟悉度达到3后进入“已掌握词表”。如果答错熟悉度直接减半并且当天晚上自动安排一次“错题重练”。重练时的题目由AI生成可能是选词填空也可能是给一个中文场景让用户造一个包含这个词的句子。这个机制的好处是把AI生成能力用在了最需要的地方不是每次复习都背“单词释义”而是“在新场景中重新用一次”记忆效果明显好很多。我在开发时给重练题目的Prompt做了一个强制约束题目必须包含目标词但正确答案不能是目标词的近义词这样模型不会偷懒。5. 从联调到上架成本、幻觉和审核这三道坎5.1 语音链路里的真实瓶颈延迟分析与缓存策略我最初以为口语对练最慢的是大模型生成但联调后发现完全不是。一次完整对话的时间分布大约是静音检测1秒、ASR识别1.2秒、Prompt组装0.1秒、模型生成1.5秒、TTS合成1秒、音频播放前缓冲0.3秒总共超过5秒。这对口语对练来说是致命的。我做了几个优化最终把“从用户说完到听到回复”的等待时间控制在2秒左右静音检测时间从1.2秒缩短到0.8秒并加入“用户说完后按结束按钮”的兜底操作。ASR开启“中间结果”用户还没说完时就开始识别结束静音后直接用最后结果。模型生成后直接返回文本先渲染文本TTS生成的同时让用户看到内容用户不再干等。热门场景预生成缓冲对高频场景如“登机对话”“咖啡馆点单”我会在前一天晚上用低峰期把几个常见回复预生成并缓存到CDN命中缓存时几乎零延迟。这里最核心的心得是AI应用不能只看单个模型耗时要全链路看。每个环节省几百毫秒用户体验就是天壤之别。5.2 大模型幻觉在教学场景里的后果和防御生成式AI最大的问题是幻觉在英语教学里尤其危险。用户如果发现一个单词解释错了他不会怪模型他会觉得这个App是垃圾。我在开发中实际遇到的幻觉包括词源解释完全错误、例句里用了中文名词的英文硬译、甚至编造一个根本不存在的短语“look forward to hear from you”然后告诉我这是高级表达。防御策略分了三层Prompt约束所有教学类输出都明确标注“如果对词源不确定请返回null不要编造不存在的固定搭配。”本地知识库兜底常见单词的词源、短语搭配尽量从本地库或权威API拉取只有查不到才让模型生成。用户反馈通道每条AI解释下方都有一个“有问题”按钮点击后我会人工复查并把这个词拉入“重点检查列表”下次不再让模型单独解释。这套机制上线后AI内容被用户投诉的比例从早期的2%降到0.5%以下对于学习类产品已经可以接受。5.3 Token成本控制一个真实用户一天要烧多少钱很多做AI应用的开发者容易忽略成本觉得单个请求便宜。实际上口语对话如果每轮都传完整上下文Token消耗非常快。我在成本模型里算过一笔账一个活跃用户每天学习30分钟大约会产生30次AI请求平均每次请求输入输出一共3000 Token一天就是9万Token。按当时的中端模型价格折算一个月成本大概在20到30元人民币。这个数字如果用户量上千月成本就是两三万完全不可忽视。我做的控本措施对话上下文只保留最后三到五轮不做无限历史。会话摘要单独存一个字段不再每次把原始对话历史全量重放。生词拆解和阅读生成尽量用小模型只有口语评分和复杂写作批改才用大模型。设置用户每日AI次数上限免费用户每天8次付费用户每天30次防止恶意刷量。同时我在后台做了实时成本监控每小时的Token消耗和每用户日成本都会画成曲线。一旦发现某个用户平均成本超过阈值会自动降级到轻量模型处理他的非核心请求。5.4 应用市场上架前的合规准备AI驱动类App上架时审核比普通工具严格不少。我整理了一份必须提前准备的材料清单隐私政策明确说明哪些数据会被发送到AI服务商音频是否会被保留以及用户如何删除数据。AI生成内容说明在App内必须对AI生成的内容做显著标识不能误导用户以为是人类老师。投诉与举报机制用户在遇到AI内容错误或不适场景时必须有便捷渠道反馈并可以拉黑该AI角色。年龄分级口语对话中的场景设定要做过滤避免出现涉及不当内容的话题。内容安全过滤无论是用户输入还是AI输出都要接一层敏感内容检测服务不能直接拿模型输出上屏。苹果商店审核时特别关注“AI言论”和“用户生成内容”两块。我提前在设置页集成了“清空对话记录”和“撤回授权”按钮审核时顺利通过。安卓市场则更在意隐私权限说明特别是录音权限必须动态申请且说明用途。这次开发最大的体会是AI能力并不稀缺稀缺的是把AI塞进一个真正可持续的学习闭环里。对话要能纠错内容要按难度生成单词要能回捞复习成本要把控到可商业化的程度。如果你也在做类似的AI学习产品建议先从最小闭环跑通把一个交互做到极致再谈扩展功能。毕竟用户记住一个学习App往往不是因为功能多而是因为某个功能让他真正觉得“学到了”。