每次身边朋友看到我用AR眼镜喊一句“中午吃啥”眼镜两秒钟就报出一个推荐菜都说这玩意儿有点未来感。其实这个功能背后的链路拆开看并不神秘就是Rokid Glasses上接入AIUI让语音识别、语义理解、对话管理、结果播报这一整套流程跑通而已。这篇文章我就拿“今天吃什么”这个最小的全链路Demo当例子从硬件准备、平台配置、端侧开发到真机调优完整讲一遍我自己的上手过程。内容偏向从0到1的实操路径适合刚拿到Rokid Glasses、想在眼镜上做语音交互应用但又不知道从哪下手的开发者。1. 为什么选“今天吃什么”入门一个小功能背后的完整交互链路很多做应用开发的同学一听AR眼镜上的语音交互就觉得门槛高觉得要先搞懂多模态模型、手势识别、空间定位这些东西。其实完全不用。Rokid Glasses这类眼镜开发语音应用最核心的路径就一条麦克风采集用户的语音交给AIUI做识别和理解得到结构化结果后由应用逻辑处理再把结果通过语音播报和眼镜镜片上的文字反馈出来。“今天吃什么”恰好踩中了这条链路的每一个环节而且没有复杂的业务状态非常适合当第一个练手项目。1.1 拆开一句“今天吃什么”用户在眼镜前说出一句“今天中午吃什么”整条链路实际发生的事情可以拆成五个阶段拾音阶段眼镜的麦克风阵列采集语音做回声消除和噪声抑制这一步硬件已经帮你处理好了。语音识别ASRAIUI把音频转成文字得到“今天中午吃什么”这个字符串。语义理解NLPAIUI把文字归入你在平台配置的“推荐菜品”意图同时识别出“中午”这个餐别槽位。业务处理你的应用代码根据意图和槽位从菜品池里随机选一个结果。反馈阶段眼镜播报“今天中午吃红烧牛肉面吧”同时在镜片上展示推荐文字。这五个阶段里真正需要你写代码的只有第四步前面三步全部由AIUI平台和眼镜端SDK承接。这也是我推荐新手用这个项目入门的原因——你不需要从零训练模型只需要学会“配置技能”和“写业务逻辑”这两件事就能看到一个完整的语音交互应用在自己写的代码驱动下跑起来。1.2 为什么不是“Hello World”而是场景应用如果只是初始化AIUI然后让它回显一段文字你学到的只是SDK怎么调对实际开发没什么感知。真实应用中用户的表达永远比你预期的复杂。有人会说“今天吃什么”有人会说“有点饿了想吃点啥”还有人说“中午别吃太油腻的”。这些表达背后的语义可能是同一个意图只是说法不一样。用“今天吃什么”当入门项目你能在配置技能阶段就直面这种多说法归一的问题而这恰恰是语音交互开发最核心的思维习惯。后面我踩过的那些坑——比如在嘈杂的食堂里识别率骤降、播报过程中重复唤醒、随机推荐连着三次都是面条——也都是真实场景里必然会出现的问题。从这些坑里学到的经验比单纯看文档有用得多。接下来我按时间顺序写你跟着走一遍就能把整个项目搭起来。2. 动手前的环境准备眼镜、平台账号和本地开发环境很多人拿到设备的第一步就想直接写代码我建议先花半小时把环境理清楚。开发AIUI语音应用并不需要特别复杂的工装但有几个项特别容易漏漏了之后排查起来很麻烦。2.1 硬件端检查清单Rokid Glasses眼镜本体确认电量充足Type-C数据线可以连接电脑。配对手机用于给眼镜配网和安装应用。Rokid Glasses的整机应用安装通常通过手机端配合完成所以手机也需要保持联网状态。正常可用的Wi-Fi环境。眼镜端的AIUI语音识别走的是在线识别断网状态下听写和语义理解都会失效这是我实测中遇到的头号前置条件。USB调试开关在眼镜的系统设置里连续点击版本号打开开发者选项。具体路径不同固件版本略有差异找不到就翻一下官方固件说明但一定要开。检查完这一遍确保眼镜能连上同一个局域网手机也能访问外网基本硬件条件就算齐了。2.2 AIUI开放平台账号与应用创建AIUI是语音交互能力的提供方你需要先到科大讯飞的AIUI开放平台注册账号然后在控制台里创建一个应用。创建应用时会让你选择领域我选了“智能硬件-智能眼镜”这个分类这个分类只是影响默认推荐的能力组合后续可以手动调整。创建完成后最关键的就是记录三个凭证AppID、APIKey、APISecret。这三个值会用在后面的SDK初始化里缺一个都连不上服务。建议直接存到一个文本文件里别临时截图保存后面配置代码时翻来翻去容易手滑填错。2.3 本地开发工具链Rokid Glasses的系统底座是Android应用开发走Android工具链。我本地的环境是Android Studio最新稳定版加JDK 17用Gradle构建。第一次新建工程时需要注意以下几点编译SDK版本选Android 12API 31以上否则可能出现系统API兼容问题。包名建议用com.yourname.eatwhat这种带反域的格式不要用纯小写单词后面配置混淆规则时会方便很多。如果要用官方提供的示例工程注意它的依赖版本普遍偏老直接把gradle文件里的版本号升级到兼容版本再sync。我的习惯是先用官方示例工程验证整条链路跑通之后再从空项目重建这样即使后面出现问题也能快速定位是环境问题还是自己的代码问题。3. 技能配置是第一道关卡让AIUI真正听懂“吃什么”这一步是在AIUI开放平台的网页控制台完成的不需要写代码但它是整个项目中最重要的部分。平台把语音交互的理解能力抽象成“技能”技能里包含意图、说法、槽位等配置项理解这些概念比写代码本身更重要。3.1 意图、说法和槽位的关系用一个生活化的比喻来解释意图是你想让系统识别出的“用户真实目的”比如“推荐菜品”。说法是用户表达这个意图时可能说的各种句子比如“今天吃什么”“中午吃点啥”“晚上有什么推荐”。槽位是说法里可变的参数部分比如“中午”是餐别“不油腻”是口味偏好。当用户说出一句话AIUI会同时输出两样东西命中的意图名和提取出的槽位键值对。你的业务代码根据这两个信息决定下一步干什么。3.2 在控制台配置“推荐菜品”技能我在AIUI控制台新建了一个技能名字就叫“今天吃什么”然后按下面的形式配置意图名称intent_recommend_food这个名字是你自己定的后续代码里判断意图时会用到。注意不要用中文命名避免编码问题。内置说法我配置了这样一组说法越贴近真实口语越好今天吃什么今天中午吃什么今天晚饭吃啥中午吃点啥有点饿了推荐点吃的晚上有什么好吃的给我推荐个菜槽位定义我在说法里标注了两个槽位格式是$meal_type餐别$和$taste口味$。槽位的候选值也要填好餐别早餐、午餐、晚餐、午饭、早饭、晚饭、夜宵口味清淡、重口、辣的、不辣、甜的、酸的配置完后要点“保存并训练”平台会生成一个语义模型。这个过程需要等几分钟训练完成后再到测试台用真实语音或文字验证。3.3 测试台验证不发一行代码先看语义我强烈建议在写代码之前先在平台测试台把语义验证透。输入“中午想来点清淡的”如果输出里同时带上了intent_recommend_food和taste清淡这两个字段说明理解路径已经通了如果识别成别的意图或槽位为空就回到上一步补说法配置一条新说法再训练一次。我自己的习惯是多准备20到30条说法尤其是那些口语化省略很多的句子。“吃啥”“吃点啥”“整点吃的”这种词在书面语里看着别扭但在真实语音交互里出现频率极高。宁可多配不要少配少的后果就是用户说一句你没覆盖的话AIUI直接回一句“没有听懂你说什么”体验非常差。4. 应用端代码把AIUI接入Rokid Glasses配置好技能之后整个理解侧的工作已经完成剩下的是在眼镜端写业务代码。这一章我按初始化、回调解析、结果反馈的顺序展开每部分都是完整可落地的代码片段。4.1 初始化SDK先把AIUI的Android SDK包接入工程。在build.gradle的dependencies里加入SDK依赖后在你的应用入口Activity里完成初始化。核心初始化代码长这样// AIUI初始化示例 AIUIAgent agent AIUIAgent.createAgent(context, new AIUIConfig.Builder() .setAppId(你的AppID) .setApiKey(你的APIKey) .setApiSecret(你的APISecret) .setLogLevel(LogLevel.VERBOSE) .build(), new UIListener() { Override public void onEvent(int eventType, AIUIEvent event) { // 各类监听事件 } });这段代码解决的问题就是把眼镜端和AIUI云端服务连接起来。setAppId、setApiKey、setApiSecret三个参数对应控制台里拿到的三把钥匙填错任何一个都会导致初始化后在回调里收到错误码。这个初始化建议挪到Application里做一次而不是每次打开页面都创建因为AIUIAgent是长连接资源频繁创建销毁内存会持续上涨。4.2 处理音频和语义结果初始化完成后把眼镜的麦克风采集数据交给AIUI做识别在事件的回调里获得结果。最核心的结果类型是AIUIEvent.TYPE_RESULT事件你需要从event参数里取出JSON字段再反序列化。我的处理代码大致是这个方向Override public void onEvent(int eventType, AIUIEvent event) { switch (eventType) { case AIUIConstant.TYPE_RESULT: { String result event.getInfo().optString(result); // result是一个JSON字符串 JsonReader reader new JsonReader(result); // 解析到intent和slots字段 break; } case AIUIConstant.TYPE_WAKEUP: { // 唤醒事件处理 break; } } }解析出来的JSON结构里最关键的是这组字段intent意图名比如intent_recommend_food。slots槽位键值对数组比如[{name:meal_type,value:午餐}]。text完整的识别文本用于调试和日志记录。confidence置信度分数这个字段在嘈杂环境下做二次校验特别有用。拿到这些结构化数据后你的应用就算真正“听懂”了用户说的话。4.3 触发方式与麦克风控制的衔接Rokid Glasses的使用场景决定了用户不会一直举着眼镜说话所以触发方式很关键。我在这个项目里做了两套触发逻辑按键触发用户点一下眼镜侧的实体按键触发录音并启动VAD语音活动检测说完话自动停止。近距唤醒用户说唤醒词系统进入交互状态。这个功能在安静环境下体验很好但在嘈杂环境里误唤醒率会上涨需要试情况取舍。代码层面要处理的麦克风切换逻辑是按下键时开始录音并设置“正在识别”标志位识别完成或超时时释放麦克风。这里有个常见的失误是只启动不管停导致录音一直开着、内存和功耗都异常后面真机调试那节我还会细讲。5. 推荐逻辑怎么写从随机到“看起来像个真人”到这里AIUI已经能把用户说的“中午想吃点清淡的”解析成结构化的意图和槽位接下来才是真正属于你的业务逻辑部分。这一步的技术含量不高但设计得好不好直接影响用户愿不愿意真的使用这个功能。5.1 菜品池设计“今天吃什么”的菜品池不能只有十来个菜那样三天就吃腻了。我自己维护了一个约60个条目的菜品清单按类别组织起来类别菜品示例面食类红烧牛肉面、麻酱拌面、番茄鸡蛋面米饭类宫保鸡丁盖饭、黄焖鸡米饭、猪脚饭家常菜番茄炒蛋、油焖茄子、蒜蓉西兰花轻食类鸡胸肉沙拉、牛油果三明治汤品类冬瓜排骨汤配饭、酸辣汤配饺子特色小食煎饼果子、肉夹馍、砂锅米线每道菜存成一个对象包含名称、类别、口味标签、热量建议几个字段。这样后续扩展偏好过滤、营养建议时不用改数据结构直接加字段就行。5.2 夹带着人味的随机算法最开始我写的是Math.random()均匀随机结果实测发现连续两天推到同一种面的概率其实不低而且纯随机没有任何“记忆”用户问第二遍往往拿到和第一遍一样的答案这就显得很蠢。我的改进方案是引入简单权重和排除逻辑给每个菜品一个initialWeight值所有菜品初始权重相同。维护一个今天已推荐列表推荐时跳过所有已推荐项。如果当天推荐次数超过菜品池的三分之一就重置列表保证永远有得推。代码逻辑并不复杂ListDish candidates dishPool.stream() .filter(d - !todayRecommended.contains(d.getId())) .collect(Collectors.toList()); if (candidates.isEmpty()) { todayRecommended.clear(); candidates new ArrayList(dishPool); } Dish result candidates.get(weightedRandom(candidates)); todayRecommended.add(result.getId());这个改动的核心价值在于用户连续问三次你给出的是三个不重复的答案而且从第二次开始用户听到的每个菜品都能体现程序的“记忆”。实际体验下来比纯随机的完成度高了很多。5.3 结合槽位做口味过滤如果AIUI识别出taste槽位你就在上面那套逻辑之前先做一轮过滤只保留口味标签匹配的菜品。比如用户说“别太油”就把菜池里所有含“油炸”标签的菜品剔除再随机。需要注意槽位识别不是百分百可靠我的策略是只做过滤不强匹配识别不出口味就用全量菜品池不给用户一种“AIUI没听懂”的感觉。5.4 播报与展示的节奏感推荐结果确定后同时要做两件事语音播报和镜片文字展示。播报用的是AIUI自带的TTS能力我建议把播报文本处理成带前后缀的完整句子比如“今天中午推荐你吃一份宫保鸡丁盖饭营养均衡不会太辣”。镜片上的文字展示则保持在两行以内只显示菜名和类别不要堆长句——用户在移动中看眼镜信息越聚焦越好。这里有个细节值得注意播报的语速和音量在眼镜这种近耳设备上要调得比手机略慢、略低一些。我的实测舒适参数是语速0.9倍、音量0.8倍左右。声音太大或语速太快人在户外走路时会产生明显的压迫感。6. 真机调试踩过的坑五个典型问题与排查链路文档里写好的流程永远顺利真机一跑起来各种问题就来了。我把自己在Rokid Glasses上调试时踩过的五类坑完整记录下来每个都是实际遇到、实际解决的希望能帮你省掉一部分排查时间。6.1 冷启动首次识别超时现象眼镜重启后第一次说话AIUI一直不返回结果或者等了好几秒才回。第二次再问就正常了。排查过程我先在日志里看AIUI事件流转发现连接服务器阶段耗时异常。进一步排查确认原因是应用冷启动时AIUIAgent还没建立完与云端的连接此时用户已经开口说话音频发过去了但服务端链路没就绪结果被丢弃。代码里也没做重发机制于是这个请求就消失了。解决方式在AIUI初始化到建立连接的间隙维护一个ready标志位在这个标志位变成true之前不开启麦克风采集而是提示用户“正在准备中请稍后再试”。具体实现是监听AIUIConstant.TYPE_CONNECTED事件收到后再设置标志位为true。6.2 嘈杂环境下的误识别现象在食堂或者马路边用户说“今天中午吃啥”识别结果变成了一些完全不相关的句子。排查过程我从结果JSON里打出了confidence字段发现误识别时的置信度普遍在0.45到0.6之间而安静环境下正常识别的置信度通常在0.8以上。这说明AIUI本身在嘈杂环境下是会降级的不能全指望模型。解决方式在解析结果时加一道置信度门槛低于0.6的结果不执行业务逻辑并回复“没有听清请再说一遍”。另外把眼镜的麦克风增强选项在嘈杂场景下手动调到更高档位实测识别率有明显改善。这个策略不复杂但对体验的提升立竿见影。6.3 播报过程中重复唤醒现象AIUI播报完推荐结果后马上又开始识别而且识别出的是播报内容的最后几个字直接把“盖饭”当成了新指令触发二次推荐形成循环。排查过程我检查了唤醒链路发现问题在于播报阶段没有关闭麦克风采集TTS播放的音频被自己的麦克风重新拾取形成了回声。虽然眼镜端的回声消除算法能抵消大部分但在特定音量下还是会有残留刚好达到唤醒阈值。解决方式播报开始时将麦克风采集置为暂停状态播报完成后再恢复。这个开关用业务层标志位控制我在AIUI的onPlayBegin和onPlayEnd事件里分别置位。这个改动之后死循环问题彻底消失。6.4 长时间运行内存增长现象连续使用半小时后应用内存占用从80MB缓慢涨到200MB以上触发了系统的内存回收导致后续识别延迟明显增加。排查过程我用Memory Profiler抓了内存曲线发现增长点主要集中在AIUI事件回调里。分析源码定位到问题我在处理每一条结果时都直接保存了原始的JSON字符串没有做任何缓存回收而AIUI的结果对象里包含大量临时字段长时间累积之后内存占用自然水涨船高。解决方式结果解析后只保留自己需要的intent、slots、confidence几个字段其余字段直接丢弃不再持有引用。同时把每次识别产生的中间音频数据在循环复用后主动置空。调整完再跑半小时内存稳定在100MB附近问题解决。6.5 指示灯状态与用户预期不一致现象用户在等待结果时眼镜上的指示灯已经熄灭但AIUI还在处理中用户以为识别已经结束容易反复重复指令。排查过程这个环节本质上不是AIUI的问题而是应用状态展示和AIUI内部状态不同步。我在代码里发现指示灯状态绑定的是麦克风采集结束事件而采集结束不等于语义处理结束。解决方式把指示灯状态改成绑定“完整结果返回”事件标志位在拿到最终结果后再熄灭。同时手动延长了VAD尾点探测时间到500毫秒给用户把一句话说完整的时间避免过短的停顿被当成一句话说完。7. 从Demo到能用的产品三个值得投入的扩展方向跑通“今天吃什么”之后这个Demo已经有了一个完整语音交互应用的全部骨架但离“值得每天戴眼镜用它”还有一段距离。我自己后续做了三个扩展都在原架构基础上花了很少的代码量。7.1 加入历史推荐队列避免短期重复上一章的“当天已推荐列表”只解决一天内的重复跨天重复的问题还在。我的做法是维护一个轻量的本地数据库表记录过去7天内推荐过的菜品和日期推荐时先排除这7天内出现过的菜品。用户戴眼镜用得越久越会觉得这个推荐是有“记忆”的。7.2 让槽位参与推荐排序而不是只做硬过滤我在第一节里配置的口味槽位原本只用来过滤效果是用户说“辣的”就把不辣的都删掉。后来我把槽位改成了加权逻辑口味标签匹配的菜品权重乘以1.5不匹配的保持不变。这样用户即使不表达任何偏好推荐也不太会飘得太离谱。实测反馈比硬过滤好得多因为槽位识别本身带有不确定性加权的方式容错率更高。7.3 把“吃什么”扩展到“附近有什么好吃的”更进一步的方向是接入LBS数据用户问“这附近有什么吃的”AIUI识别出位置相关意图后应用调用定位能力拿到坐标再通过公开的POI数据服务把附近餐厅列表拉回来按距离和评分排序后播报。这一步的技术难点不在服务端而在于如何把外部数据转换成语音播报里的自然语言比如“你往东走300米有一家评分4.8的面馆”。说实话这个工程改起来就像把接口和数据拼接在一起但做完之后整个应用的可用性会完全不同。最后再分享一个小细节在AIUI控制台做任何配置修改后记得重新训练语义模型再测试。我因为忘记点训练在配置完新槽位后花了整整一个下午排查结果发现服务端跑的还是旧模型。语音交互的调试周期和普通App不一样多留意服务端的版本状态能省下不少冤枉时间。