一 项目简介
英语外教是一款使用 Rokid AIUI 实现的个人英语学习智能体。它把语音陪练、场景辅助、单词复习和跟读练习放到眼镜中，并通过可选的个人网页后台保存学习配置。本文介绍如何把“我想练英语”这样的需求，转化为可选择场景、可持续交谈、可看到反馈的完整操作过程。
最初的需求很直接：用户想在通勤、出差或工作间隙练习英语，却不希望一直拿着手机、阅读长菜单、反复点击录音。在咖啡馆里，用户真正需要的可能只是一句点单练习；在会议前，可能是围绕自己准备的材料进行问答。把这些任务都装进一个聊天框，虽然能够回答问题，却不容易让用户知道下一步该做什么。
因此，我把设计重点放在 AI 能力和眼镜交互之间的衔接。用户先用极少的操作确定场景，进入通话后持续交流，眼镜显示双方字幕和当前状态；通话之外，再用单词、跟读和收藏承接需要继续练习的内容。网页后台是增强项，未登录和未绑定设备时，也能使用独立访客学习空间。基础学习仍需要相应网络服务，免绑定并不等于全部离线。
首页保留智能对话、场景助手、背单词、跟读练习、收藏和设置六个入口。设置和收藏独立出来，让当下正在执行的学习任务少受配置项干扰。对眼镜而言，减少一次选择，往往比增加一项功能更有价值。

二 场景与用户意图
我把用户意图区分为进入哪项任务，以及任务开始后如何承接当前情境。智能体定义负责把“打开英语外教”“跟读练习”等明确请求引导到对应页面；对话服务负责理解通话中的英语内容。两者共享产品上下文，但不把模型生成的一段文字直接当成设备操作授权。
以智能对话为例，第一次进入时先选择 Alex 男声陪练或 Emma 女声陪练，再进入场景配置。之后再次进入，无需重复首次引导。用户可以选择内置场景，也可以主动拍照，把本次环境描述带入练习；已绑定个人后台的用户，还可以使用本人配置的文本和学习词汇。用户不拍照时，仍可以从默认话题开始。
这里有一个重要的边界：进入对话不等于同意拍照。只有用户明确选择拍照，并通过点按、相应功能键或确认手势触发时，才调用摄像头。识别得到的内容只是本轮练习的背景，不应变成系统指令，也不应自动保存为长期记忆。
用户需求 交互承接 边界与反馈
现在练口语 角色偏好 → 场景 → 通话 可默认开聊 拍照另行确认
围绕眼前环境练习 主动拍照 → 环境描述 → 对话 识别失败可重试或改用内置场景
复习一个单词 滑选释义 → 确认 → 学习回执 答错保留正确释义
练习一句发音 生成示范 → 跟读 → 讯飞评测 有效录音和真实结果才显示评分

例如，用户选择咖啡馆场景后，期望的是围绕点单展开短句问答，问候与提问应承接该场景；选择学习资料时，期望的是围绕自己的材料练习，而不是重新填写一遍主题。这些设计让界面承担必要的确认，让模型处理开放式语言交流。页面不需要不停增加按钮，也能把“想练什么”变成清晰的下一步。
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/b831b6c8422f451eab56fe64d8e6953b.png#pic_center

图 2 场景配置界面示例 用户确认场景后开始通话
三 方案设计
工程分为眼镜智能体、业务后端、语音服务和个人网页控制台。眼镜端使用 AIUI 的全屏 Page 作为交互主体，负责界面、设备输入、录音和播放；业务后端负责身份、会话和个人学习数据；语音服务负责识别、模型回复与语音合成；网页提供可选的学习资料和记忆配置入口。
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/5c8811975ec540b5aa8d0b5d0c717df1.png#pic_center

图 3 眼镜端与服务端的能力分工 按项目工程结构绘制
语音链路需要按终端选择传输方式。网页实时通话使用 SmallWebRTC；AIX 则通过眼镜原生录音和播放能力，使用经过身份校验的 WSS 长连接传输音频。两者可以复用服务端的 Pipecat 处理管线，但眼镜并不需要运行一套浏览器 WebRTC 页面，更没有在设备上部署大语言模型。
页面状态围绕用户任务组织。进入通话前是角色与场景选择；准备阶段显示连接状态；用户说话时保留自己的字幕；模型处理时给出等待反馈；播放回复时显示 AI 字幕；结束后释放录音、播放与网络资源。准备失败时回到可重试的界面，而不是把用户留在一个无法操作的“正在检查”按钮上。
这种划分也决定了故障处理的位置。界面按钮失效应先检查焦点和事件；录音占用应检查本机音频生命周期；模型超时则由服务端限制等待并返回明确状态。把所有失败都提示成“网络异常”，会让用户和维护人员都失去判断依据。
四 AIUI 实现
工程结构和页面声明
agent/app.json 注册页面、运行时版本范围以及录音和摄像头权限。页面采用 .ink 单文件形式，把配置、逻辑、模板和样式组织在一起；共享的交互、身份、录音、通话和学习逻辑放入 agent/lib。当前公开包包含 24 个注册页面，但用户日常看到的仍是六个主要入口。
agent/
app.json # 页面和权限
app.js # 应用生命周期
pages/phone/phone.ink # 智能通话
pages/call-scene/ # 场景配置
lib/two-button.js # 统一输入
lib/realtime-call.js # 通话状态
lib/recorder.js # 录音所有权
backend/ # 身份与个人学习数据
voice_service/ # 语音处理管线
web/ # 个人后台与演示

AIUI 页面逻辑使用 export default 导出对象，由 this.setData 更新可见数据；模板事件使用 bindtap 等声明方式，不能照搬浏览器的 DOM 操作。下面是从通话页提炼的结构示意，省略了身份校验、会话建立和资源回收代码，重点展示双方字幕与单一结束动作如何绑定到状态。

{{userText}} {{aiText}} 结束对话

在 480×352 单色绿显示中，页面高度是硬约束。我把头像、字幕和操作区分开预留空间，避免长文本与角色图相互挤压。字幕更新与音频播放分别处理，收到模型文字不等于已经播出声音。动态嘴型只跟随实际播放活动；流畅优先模式则使用静态大头像，保留双方字幕和等待提示，减少持续重绘。
连续语音链路
眼镜采集 16 kHz 单声道 PCM，按短帧持续上传；传输层支持 μ-law 编码以降低带宽。服务端用 Pipecat 编排 VAD、ASR、LLM 和 TTS。当前眼镜实时通话使用服务器上的 faster-whisper 本地英语识别；工程保留其他语音识别适配，跟读发音评测独立使用讯飞 ISE。回复使用服务端配置的 DeepSeek 流式模型，英文合成通过独立 Piper 服务完成。模型配置与密钥保留在服务端，不写入 AIX。
流式模型输出按句聚合后送入合成，第一句不必等待整段回答全部生成。用户插话时，取消旧回复生成和待播音频，停止旧嘴型，再处理新输入。对话期间保持同一会话连接，避免每一句都重新建立录音和服务连接。
识别速度和设备资源
持续上传音频，能够减少说完以后再整段上传的等待，但不能把本地 Whisper 识别描述成逐字实时识别。当前工程还允许在稳定停顿时预计算识别候选；如果用户继续讲话，候选就作废，最终语音端点确认前不把它提交给模型。字幕渐显是一种呈现方式，也不意味着识别器已经确认了每一个词。
麦克风释放是另一项必须独立处理的工程问题。智能通话、现场辅助、会议记录和翻译共用设备录音能力。如果旧会话只在界面上消失，原生录音没有真正停止，下一个页面仍会遇到占用。为此，我把录音所有权集中管理：先请求旧录音停止，确认原生 onStop 已到达，且最新一次 stop 调用已经结束，再允许下一次录音。仅有旧一轮调用结果或超时计时，不足以释放占用。
0.6.86 对已经请求停止的旧录音提供有限重试，同时保留占用保护。超时只能触发提示或再次检查，不能假装硬件已经释放。页面失焦、离开或切换学习身份后，迟到的回调也不能重新开麦。这个规则让异常处理更严格，却能避免两个页面同时争用麦克风。
拍照和学习数据
拍照识别通过 AIUI 原生设备能力取得图像，再通过宿主 LanguageModel 的图像能力生成短环境描述，带入本次通话；完整照片不发送至自建 EnglishMate 服务器。这也不代表眼镜在离线运行视觉模型。识物与 OCR 是不同能力，不能仅凭识别出一段文字就宣称理解了整个场景。拍照确认、处理中、识别失败与重新拍摄应分别反馈。
个人学习数据以当前学习身份为边界。未绑定时使用访客空间；绑定后由后端验证设备与账号的关联，再访问对应资料。通话记忆与自动收词是分开的设置：允许使用学习目标，不代表允许自动保存候选生词；自动收词需要独立同意，也不能把聊天里出现过的词直接标为“已掌握”。
跟读练习则采用更短的任务链：按难度生成一句英语，播放示范，用户主动开始跟读，取得有效录音后提交讯飞 ISE 发音评测，再显示反馈。没有声音、上传失败或服务未返回有效结果时，不填入演示分数。发音评测结果也不等于对用户综合英语能力的认证。
五 交互与体验
眼镜中的操作需要同时照顾触摸板和头部手势。我的做法是统一维护当前选择项，让前后滑动改变选择，点按或点头执行；摇头可以切换选项，无法使用手势时仍保留镜腿操作。需要执行动作的子页面尽量只保留一到两个按钮，菜单本身不再重复显示“进入”和“下一项”。
智能对话页优先营造面对面交流的感觉。角色居中放大，用户和 AI 的字幕各有位置，通话中只保留“结束对话”。准备、等待和播放状态能看见，但不铺满解释性小字。长字幕需要在固定区域内完整呈现，不能因为形象变大而把句子裁掉。

图 4 大头像与双方字幕区域 脚本化对话演示
背单词的反馈也要直接。三个释义同屏横排，用户左右滑选后再确认；答对经服务端回执核对，显示正确标记后自动进入下一词；答错则保留正确释义，等用户主动进入下一题。“不知道”是明确的选择，不应被埋在轮播命令里。复习排期由服务端 FSRS 调度承接，完成一道题与长期掌握程度仍分别记录。

图 5 横排释义与答错反馈 示例词汇和演示回执
六 调试与验证
实际迭代让我意识到，模拟器能打开页面，只证明了一部分。滑动事件、录音停止、摄像头确认和投屏时的性能，都需要按目标设备与具体版本分别核验。因此，我把验证分为页面渲染、可控回归、公网文件核对和真人实机使用几层，避免用其中一层替代其他层。
遇到的问题 处理方法 验证重点
一次滑动跨过两项 统一输入控制与事件分组，处理默认导航 一次物理操作只改变一次选择
角色引导文字重叠 固定内容槽和字幕高度，减少叠加状态 长文本与角色区域无重叠
退出通话后录音占用 集中所有权，等待真实停止证明，有限重试 不以超时假释放，不迟到开麦
投屏或录屏时交互卡顿 默认静态头像，减少动态嘴型与波形重绘 保留语音与字幕，另做实机负载验证

0.6.86 的发布记录包含 2518 项原生工程回归和 41 项附加检查，均通过；网页预览也完成了相应交互检查。这些数字是自动化检查项数，不是用户样本量，更不是学习效果实验结果。该版本发布记录没有包含学生眼镜复测，也没有记录本次 Studio 上传，因而不能由此推导出所有固件、网络和录屏条件均已通过。
为了让远程反馈更容易定位，我在设置里增加了版本检查。它分别显示本机 AIX 版本和公网最新版本。即使离线，也能查看本机版本；公网请求失败时显示未确认，不能把服务器的版本号覆盖成本机版本，再让用户误以为已经更新。

图 6 本机版本与公网版本分别显示 离线分支界面演示
网页预览使用隔离的示例数据来演示页面与交互，既不录真实麦克风，也不代表已取得真实识别、模型或评分结果。评审者可以先通过它理解操作流程，再下载 AIX 在有相应服务和权限的眼镜上验证完整链路。
七 成果与复盘
目前项目已经形成可下载的 AIX、对应源码包和网页交互预览。它把场景选择、持续语音交流、字幕反馈与后续复习串在同一产品中，也保留了不绑定后台即可开始学习的路径。个人网页控制台则承担学习材料、通话记忆和同步等增强配置，减少用户在眼镜上输入长文本的负担。
这次实践中最有价值的经验，是把“理解意图”落实到具体状态。用户想练口语时，界面帮助确定角色和场景；用户正在说话时，界面让出空间；服务处理中，提供可理解的等待反馈；答错一个单词时，立即展示正确释义；任务结束时，真正回收设备资源。每一个环节都需要界面与执行结果相互对应。
后续迭代将优先补充不同眼镜固件和弱网条件下的实机回归，并按语音端点、识别、模型首句和播放起点分别记录时延。投屏与录屏场景需要单独评估渲染和音频负载。只有获得这些实测数据后，才适合对延迟、并发容量或稳定性给出量化承诺。
体验和复现入口
产品页面提供当前版本、AIX、源码包与校验信息。建议先在网页预览中查看角色选择、场景配置、通话字幕和词汇反馈，再按 AIUI 文档将对应 AIX 导入 AIUI Studio。源码阅读可从 app.json 的页面声明开始，依次查看 two-button.js 的输入控制、realtime-call.js 的会话管理以及 recorder.js 的资源回收。真实通话、拍照与跟读评分需要在设备权限和相应服务可用时验证。
产品与下载 https://englishmate.site/english-teacher/product/
网页交互预览 https://englishmate.site/english-teacher/product/preview/
个人学习后台 https://englishmate.site/english-teacher/login.html