从0到1构建AI英语陪练智能体：大模型垂直应用实战解析

先从一个痛点说起。我自己练英语口语很多年试过真人外教、口语App、也试过直接跟通用大模型聊天。真人外教的效果最好但约课贵、频率跟不上口语App里的对话机器人剧本感太强说来说去就那么几个场景直接跟通用大模型聊它能聊但该纠错时不纠你错了一天也没人提醒聊着聊着就变成你一句它一句根本坚持不下来。所以才有了这个“AI 英语智能体”项目——不是简单做一个聊天窗口而是把一个懂教学的英语陪练流程真正落到产品里让用户打开就能跟练、跟练就有反馈、反馈完又能沉淀成学习记录。项目从设计到上线前后花了一个多月这里面有思路、有选型、也有不少坑。这篇文章就把完整过程拆给你看想用大模型做垂直场景应用、或者想做英语陪练类 Agent 的朋友可以直接参考。1. 项目定位与整体设计思路1.1 先想清楚这个智能体到底解决什么问题很多团队做 AI 应用上来就堆功能结果做出来是个大杂烩。我一开始就给自己划了一条线这个智能体只解决“英语口语输出不足”这一个核心问题不做题库、不做背单词 App、不做视频课。为什么选口语陪练因为这是大模型相对传统 App 最有优势的场景。传统 App 的对话脚本是写死的你说“I want a coffee”它只会回固定的句子而大模型可以接住任何表达还能根据上下文自然延展。但通用大模型又缺少教学感它不会判断你的水平不会给你纠错也不会记录你长期的学习轨迹。这个项目要做的就是在大模型的灵活性之上加一套教学流程和教学规则。我把它类比成“私人教练”和“全科医生”的区别。通用大模型像全科医生什么都能看但不会陪你练肌肉而英语智能体是私人教练目标明确、节奏可控、每次训练都有记录。这个定位一旦清楚后面所有设计都不会跑偏。1.2 核心场景与需求拆解先砍掉多余功能把定位拆成具体功能我列了一个清单按优先级排序学习者水平测评首次使用先摸清用户当前英语水平后面所有对话难度才有依据。情景对话陪练覆盖日常生活、面试、旅行、商务等高频场景让用户开口说。即时纠错与反馈对话中识别明显语法错误、搭配错误以最自然的方式反馈。口语评分对话结束后给一个维度化的评分让用户看到进步。学习记录与复习保存错题、生词、薄弱点下次对话之前先复习。学习报告与推荐每周生成一次学习小结推荐下一阶段练习方向。我当时把“学习报告”放到了最低优先级第一个版本只做了测评、陪练、纠错、评分这四件事。原因很简单MVP 阶段最重要的是把“对话—反馈—评分”这条主链路跑通让用户有完整的学习体验。报告类功能后续可以慢慢加但如果主链路没做好什么报告都是空壳。需求边界也很重要。我明确不做的事情包括不支持读写训练、不替代真人外教考级辅导、不承诺任何考试分数提升。边界划清楚后面跟协作方沟通、跟用户解释都会省很多麻烦。2. 技术选型平台、模型与语音方案的取舍2.1 为什么我最终选了 Dify 做智能体编排做智能体开发市面上有两条路一条是用 Coze、Dify 这类低代码平台快速搭建另一条是用 LangChain、LlamaIndex 或自研框架从零写。我团队规模不大又要快速验证产品所以选了 Dify 作为核心编排平台。Dify 最打动我的点有三个工作流可视化、知识库管理、 API 发布能力。英语陪练场景需要多步逻辑——先判断用户水平、再决定对话难度、最后触发评分这些在 Dify 的工作流里能很清楚地理出来不用写一堆胶水代码。知识库功能也很实用我可以把常见语法知识点、场景词汇表、纠错规范导进去让智能体在回答时参考这些内容而不是完全靠模型临时发挥。Coze 我也试用过它更适合快速做抖音、微信等渠道的 Bot玩法模板多但我要做的是更偏产品级的后端服务需要高度自定义接口和数据结构Dify 的开发者体验更合适。如果你只是做个 Demo 或渠道 BotCoze 完全够如果你要长期迭代、有复杂业务逻辑Dify 这类偏“开发者平台”的工具会更顺手。这里说句掏心窝的话低代码平台不等于不能做复杂产品关键看你怎么用它。真正复杂的逻辑可以放到外层业务服务里平台负责编排模型调用和知识检索两者结合开发和维护成本都低很多。2.2 底层大模型不是越强越好而是分活干模型选型是整个项目里最容易被忽视、又最影响体验的一环。英语陪练场景对模型的要求有几个指令遵循能力强、对话自然、少幻觉、能处理多轮上下文。我一开始全部用 GPT-4o效果确实好但成本也高得吓人尤其是用户一天聊几十轮Token 消耗蹭蹭往上涨。后来我改成“分级模型策略”主对话用 GPT-4o 或 Claude 系列负责难度最高的教学对话和纠错而像文本摘要、意图分类、学习记录归档这类“脏活累活”交给更便宜的国产模型处理。比如用户聊完一段我需要把这一段提取成学习记录摘要这个任务模型要求不高用国产模型能省 80% 的成本。这里要纠正一个观念模型不是越强越好而是“按任务难度匹配模型”。对话质量决定用户留存不能省但后台任务可以省钱。实测下来这套分级策略让单用户每日成本下降了 60% 左右体验几乎没有变化。2.3 语音链路ASR、TTS 和延迟预算英语口语陪练离不开语音。整个语音链路是用户说话 → ASR 转文字 → 智能体处理 → TTS 合成语音 → 播放给用户。链路里最影响体验的不是某个模型有多聪明而是延迟。我先定的目标是从用户说完话到听到回复整体延迟控制在 2 秒以内。想要做到这个指标每一环都得抠。ASR 我用过 Whisper 本地部署版和云厂商的语音识别接口。Whisper 识别准确率不错尤其对中英文混说的口音更友好但不加优化时延迟偏高。后来我在前端做 VAD 语音检测用户一停顿就立刻结束录音并开始识别省掉了“等用户说完”的空闲时间这一步就把体感提速了不少。TTS 我对比过 Azure、火山引擎和 MiniMax。Azure 的声音最稳但有些场景有延迟火山和 MiniMax 的音色更自然价格也更便宜。最后我选了火山引擎做主力 TTS因为它在延迟和自然度之间平衡得最好。这里建议你一定要做真实网络环境下的压测别只看官网参数实际跑一轮对话延迟和卡顿都是能直接感受到的。3. 核心功能实现从测评到陪练到复习3.1 水平测评模块怎么在两分钟内摸清用户底细水平测评是整个产品的入口决定后续对话难度必须做得轻、快、准。我参考了 CEFR 分级体系把用户从 A1 到 C2 分成六个等级用一轮“自适应问答”来估算等级。流程是这样的系统先出一个接近 B1 的引导性问题比如“What did you do last weekend?”根据用户回答的长度、复杂度、语法正确性自动决定下一题难度。如果用户答得很好下一题就提高到 B2如果答得磕磕绊绊就降到 A2。这样五到六轮之后基本能估出一个比较稳的等级。测评不能做成审讯这一点很多人会忽略。用户刚进产品心理状态是“我想试试”不是“我要考试”。所以我在测评里也加入了轻松的寒暄环节比如“What kind of music do you like?”测评感弱聊天的感觉强。用户回答得越多系统拿到的基础语料就越多级别判断也更准。级别判断不是靠简单数句子长短而是靠一套打分规则加模型综合判断。我让模型输出结构化 JSON包含建议等级、判断依据、用户语言亮点和薄弱点。这样后续对话模块直接读 JSON 就能继续等于测评结果成了整个用户画像的第一块拼图。3.2 对话陪练Prompt 指令是灵魂也是最大的坑测评定级之后就进入核心环节情景对话陪练。这个模块我几乎每天都在调 Prompt可以负责任地说对话质量 80% 取决于指令设计而不是模型本身。我先定义了一个“教学型陪练”角色而不是“聊天机器人”。这个角色最大的不同在于它有教学目标。每次对话不仅是为了聊得开心还要让用户有机会使用目标语言点。举个例子如果目标是过去时智能体会在对话里自然创造条件让用户描述“昨天做了什么”而不是东聊一句西聊一句。下面是我早期版本的一段核心系统提示词做了简化但思路是一样的你是英语陪练助手 Teacher Lewis服务对象是 CEFR B1 水平的学习者。 规则 1. 对话优先保证流畅不要频繁打断用户更不要一次纠正所有错误。 2. 当用户出现明显语法或用词错误时选择最重要的一处进行反馈反馈要简短、自然。 3. 难度遵循 i1 原则每轮对话里的生词不超过 2 个优先用英文简单解释。 4. 如果用户无话可说主动抛出下一步引导问题让对话继续。 5. 所有回复按 JSON 格式输出字段含义见示例。关键是第五点结构化输出。我不让模型自由发挥文本而是要求它返回 JSON里面包含reply对用户说的话、feedback纠错内容、vocabulary生词解释、score本轮评分、next_topic下一步话题。这样前端展示、后端记录都非常方便而且模型在生成 JSON 时会“被迫”把教学逻辑走一遍不会只回一句“Great!”就结束。这种 Prompt 的效果立竿见影。加上结构化输出之后纠错不再是随机的而是真正有针对性的。举一个实测例子用户说 “I go to school yesterday”模型会返回这样一条反馈{ reply: Good! You mean I went to school yesterday, right? Lets continue. What did you do after school?, feedback: [ { type: grammar, original: I go to school yesterday, suggestion: I went to school yesterday, explanation: 描述过去的事情要用过去式go 的过去式是 went } ], vocabulary: [], score: 82, next_topic: after_school_activities }这个模块最大的坑是“纠错频率”。早期版本里模型一遇到错误就纠正结果用户说两句就被打断一次体验非常糟糕。后来我在规则里明确写了一句话“每次回复最多反馈一个语法错误优先选择影响理解的错误。” 这一改用户留存数据立刻有了变化。3.3 记忆与复习让智能体记住你而不是每次都重新认识英语学习最怕的是“今天聊完明天就忘”如果智能体每次都把用户当新用户学习就毫无积累。所以我设计了三级记忆体系短期记忆、中期画像、长期复习。短期记忆走的是常规的多轮上下文管理保留最近 10 轮对话保证对话连贯。这里有个技术细节不要把所有历史都塞进模型上下文很快会超过 Token 限制成本也兜不住。我采用“滑动窗口摘要压缩”的方式超过 10 轮的旧对话让模型总结成一段简短的背景信息比如“用户上周聊过旅行话题提到想去日本”然后放进上下文里旧对话细节就丢掉。中期画像是一份结构化用户档案存在数据库里包含CEFR 级别、常用话题、常犯错误、已掌握词汇、薄弱语法点。每当一轮对话结束后台模型会把本轮学到的关键信息更新到画像里。这样下次对话开始时智能体就知道“你上次总是弄混过去时这次我们有意识地练一下过去时”。长期复习我借鉴了间隔重复的思路。每周生成一批复习任务比如把本周的 10 个错题整理成填空或选择题优先复习那些“多次犯错”的内容。这个模块工作量不小第一个版本可以先不做太复杂但记忆机制要从一开始就设计好否则后期数据累积起来想加都难。3.4 口语评分不是让模型随便打个分而是多维拆解口语评分是最容易被做成“花架子”的功能。很多产品让大模型直接输出一个分数看起来方便其实极不稳定换个表达方式分数就乱跳。我做的评分体系分四个维度发音、语法、词汇、流利度每个维度单独打分再加权汇总。发音和流利度靠 ASR 的中间结果来算。ASR 转录文本后我会拿到语速每分钟单词数、停顿次数、重复/修正次数这些是流利度的硬指标。发音分数一部分靠 ASR 的置信度一部分靠云端音素级评测接口。语法和词汇打分则交给大模型把转录文本和用户级别一起交给模型让它按 CEFR 标准输出语法错误数和词汇丰富度评分。这里有个非常重要的校准步骤不要直接信模型的分数。我拿了一批真人教师打过分的历史对话让模型对同一批对话打分对比差异然后调整 Prompt直到模型分数和真人教师在多数样本上接近为止。这一步不做评分功能就是“图一乐”对教学没有参考价值。最终给用户的分数我会同时展示“综合分”和“分项雷达图”并且写一句可执行的建议比如“你的流利度不错但过去时错误较多建议复习不规则动词”。用户需要的是能指导行动的结果不是一个冷冰冰的数字。4. 上线部署与成本控制4.1 部署方式与接口设计把智能体封装成产品级服务Dify 搭建好工作流之后可以直接发布成 API。但在正式上线前我在外层套了一层业务服务用 Node.js 写的负责用户登录鉴权、接口限流、并发控制、数据落库和内容安全过滤。这样做的好处是Dify 只负责模型编排业务逻辑和用户数据都掌握在自己手里后续扩展不会被平台绑死。接口设计上我推荐使用 SSEServer-Sent Events做流式输出而不是等整个回复生成完再返回。用户说话之后如果等两三秒才看到整段话会觉得卡如果用流式输出模型一边生成一边往客户端推用户几百毫秒就能看到第一个字体感会流畅很多。语音场景下这一条尤其重要。消息格式也要提前约定好。我定义了一个统一的消息结构包含消息 ID、类型语音/文本、内容、反馈列表、评分、时间戳等字段前端不管收到的是文本还是语音解析逻辑都是同一套。上线之后迭代版本很频繁数据结构稳定前后端联调就会轻松很多。4.2 成本控制分级模型、缓存和 Token 预算AI 应用的成本大头几乎都在大模型 API 调用上。英语陪练又是典型的多轮长对话场景用户一次练 20 分钟消耗的 Token 相当可观。我上线第一周就吃过亏账单比我预估的高了快一倍。我做了三件事来止损。第一是模型分级前面提到的主对话用好模型后台任务用便宜模型。第二是对话缓存用户重复触发同一个场景时可以复用开场白和标准回复模板不走模型调用。第三是设置单用户每日 Token 预算超过一定量就自动把主模型切换成更经济的替代模型保证用户还能继续练但成本不会失控。成本预估公式其实不复杂单轮对话平均消耗 Token 乘以人均对话轮数再乘以日活用户数就能算出一天的消耗量。我建议在上线前就把这个公式算清楚并且给每个用户设定成本上限。很多人只盯着功能不看账单等到月底发现成本是预期的两倍那就被动了。4.3 数据回流与 Prompt 持续迭代上线只是开始上线不是项目的终点而是迭代的起点。我在产品里埋了反馈入口对话结束后用户可以点“反馈”标记这次回答是否有帮助如果用户点了“不满意”后台自动记录这条对话的完整上下文标注为 badcase。每周我会系统性地看这些 badcase挑出典型的 5 到 10 条分析是 Prompt 问题、模型问题还是产品设计问题。比如有用户反映“机器人总打断我”我去看数据发现是纠错规则没有限制频率有用户反馈“对话太简单了”发现是等级判断偏保守导致高等级用户被当成低等级来教。这些问题逐一修完之后下一周 badcase 就会明显减少。Prompt 的迭代我用一个很笨但有效的方法维护一份版本记录每次改动都写清楚改了哪条规则、为什么改、上线后数据有什么变化。一个月下来这份记录就是最宝贵的工程资产比任何方法论都有用。5. 上线后的踩坑记录与问题排查5.1 常见问题速查表这里整理了我上线后遇到频率最高的问题做成一张表方便你对照排查。问题现象可能原因解决办法对话响应慢用户等很久TTS 等待完整文本生成后才开始合成改流式 TTS边生成边合成用户说“机器人老打断我”Prompt 里没限制纠错频率明确每次最多纠一个错优先纠影响理解的错误用户答案识别成乱码或错误文本ASR 对特定口音覆盖不足换多语种 ASR或在前端加 VAD 分段录音模型造出错误的单词示例大模型幻觉在 Prompt 里限定示例来源或接知识库校验评分时高时低用户投诉不公LLM 直接打分不稳定改成规则LLM 结合多轮取平均值Token 成本快速上升长对话历史全部塞入上下文用摘要压缩只保留最近对话和关键画像用户中途流失严重对话场景太窄或引导不足在上一步反馈里加“继续话题”引导5.2 几个值得单独拆解的反面案例第一个是“纠错过载”案例。上线初期模型几乎每句话都纠正用户用户刚说一个不完整的句子机器人立刻打断说“You should say...”没过几天流失率就上来了。后来我把纠错策略改成“先让用户说完、只纠一个最重要的错、用正面语气反馈”流失率才慢慢降下来。这个问题的本质不是模型不行而是产品没有替用户做减法。第二个是“幻觉例句”案例。有次用户问一个生词模型随口编了一个例句语法没毛病但用法在真实语境里很少见。这对英语学习产品是硬伤因为用户会当真。我后来在 Prompt 里限定“例句必须来自内置词汇库如果库里没有就说明不确定而不是编造”同时接了一个小规模的知识库做校验才把这个坑填上。第三个是并发打爆案例。上线第二天小范围推广瞬间来了几百个并发请求结果 ASR 和 TTS 服务的限流策略没配好导致一部分用户直接拿到报错。后来我做了两件事一是把外部服务的调用改成带队列的异步模式二是给关键环节配了熔断降级ASR 挂了就先走文字输入TTS 挂了就先出文本保证对话不中断。5.3 运营层面不能回避的事技术做完了运营和安全合规同样不能省。英语陪练类产品会涉及用户语音数据这属于敏感个人信息。我在上线前做了几件事隐私政策里明确写清语音数据只用于学习分析、不对外共享用户可以选择关闭语音功能只用文字输入所有对话数据加密存储支持用户一键删除。这类产品还特别容易被滥用。我在对话模块外层接了一层内容安全过滤大模型的回复在推给用户之前会过一次内容审核接口不合规的内容直接拦截并换成安全提示。虽然英语学习场景风险相对低但安全性没必要赌。运营层面我建议一开始就建一个种子用户群把前 100 个用户拉进来主动收集反馈。这比任何数据分析工具都直接。种子用户往往愿意贡献最真实的意见他们的一句话可能比后台一千条日志更有价值。我在实际开发中还有一个体会AI 智能体开发真正的门槛不在“接入大模型”而在“把教学逻辑变成工程逻辑”这一层。模型只是引擎决定产品价值的是你怎么设计测评、怎么控制难度、怎么纠错、怎么沉淀学习记录。尤其是英语教育类场景哪怕是一点点小的交互细节失误都会直接影响用户是否愿意长期使用。做好一个垂直智能体最值钱的不是某一句 Prompt 写得有多妙而是整个学习闭环是否真的跑得通、用户是否真的有收获。后续如果要把这个产品继续做深可以把方向拓展到听力预测、写作批改、多语种口语评测甚至跟课程系统打通让智能体成为整个教学链路里的一环。但无论怎么扩展核心还是那句先服务好一个具体场景再谈更大的故事。