用Gemini Nano 4打造智能眼镜音频优先体验

智能眼镜正在从极客玩具走向日常穿戴设备，而音频优先的交互方式，正在成为这类设备最自然的使用范式。在近期一场技术分享中，Google工程师Amy和Alice详细拆解了如何利用Gemini Nano 4和ML Kit，为智能眼镜构建无需动手的AI体验，并给出了一个完整开源示例——XR Language Teacher。

智能眼镜的硬件形态与开发入口

所谓智能眼镜，指的是可全天佩戴的轻量级眼镜，涵盖带显示和不带显示两种形态。硬件上通常配备触控板（支持点按和滑动）、扬声器、摄像头和麦克风。对于纯音频眼镜而言，语音就是唯一的用户界面，这决定了交互设计的核心逻辑。

开发层面，Android开发者具有天然优势：现有Android应用可以通过蓝牙向眼镜投射语音通知等内容，而要进一步差异化，则需要借助Jetpack projected库创建一个专用于眼镜的Activity。在Manifest中声明时，需要使用XR projected作为必需显示类别，并加入XR projected launcher意图类别，这样Gemini才能发现应用，让用户以免手方式启动。

连接管理方面，isProjectedDeviceConnected方法用于持续监测眼镜状态——不只是配对或开机，而是确认眼镜真正被佩戴且就绪。开发者还可以通过projected device controller检查设备能力，例如是否包含visual UI能力，从而针对显示眼镜和音频眼镜做差异化适配。需要注意的是，访问眼镜摄像头等硬件时，即便手机端已有权限，仍需通过projected activity重新申请眼镜侧权限。Google为此推出了projected hardware技能，可在Android CLI和Android Studio中辅助完成权限工作流配置。

Jetpack projected 与 XR projected 显示类别

Jetpack projected 是 Android 面向 XR 与智能眼镜的专用库，核心思路是把手机或主设备上的 Activity 投射到眼镜端渲染。XR projected 显示类别的作用是声明该 Activity 只适合在眼镜这类投射设备上运行，系统据此在手机主屏隐藏入口、仅在眼镜连接时呈现；而 XR projected launcher 意图类别则让眼镜端的启动器（例如 Gemini 的免手启动入口）能够发现并拉起该 Activity。两者配合，才能实现“戴上眼镜、免手唤醒”的体验。若只声明其一，应用可能无法被眼镜启动器检索到，或在手机上出现不该有的图标。

用ML Kit构建语音输出与音频提示

音频优先体验的核心交互包括三部分：语音输出、earcon（音频图标）提示，以及用户输入处理。

ML Kit新推出的GenAI文本转语音库目前处于alpha阶段，在部分Pixel和Samsung设备上可用。它解决了传统系统TTS声音不够自然的痛点，同时避免了云端语音方案带来的延迟和额外成本。该库提供8种不同特质的音色和21种语言区域支持，首次下载后完全在设备端运行，模型由系统共享，不会增大APK体积。

代码流程相对直接：初始化speech synthesizer并设定locale，检查下载状态并选择音色，构造请求并播放，同时监控状态和收集错误。示例中使用firstOrNull获取音色，若返回null则说明设备不兼容，此时需要准备好降级方案，例如回退到系统TTS或播放预录语音。

earcon是音频版的图标，用短音效传达信息。Android Design Hub已提供应用打开、关闭、错误提示、静音切换等标准化音效，开发者也可自定义。设计上有几条经验值得遵循：避免过度使用导致听觉疲劳，使用熟悉的音高和节奏，避免需要解释的复杂音效——这类信息更适合用语音播报。

Earcon 的概念与设计约束

Earcon（audio icon）指用极短音效替代视觉图标的听觉符号，最早在人机交互研究中被提出，用于在不打断语音流的前提下传达状态变化。它与语音播报的分工在于：earcon 适合表达“已保存”“出错了”“静音已开”这类二元或类别化信息，语音则适合承载需要语义解释的内容。在音频优先的眼镜上，earcon 是唯一能提供即时反馈又不占用语音通道的手段，因此节奏、音高和时长需要统一，同一含义在全应用内保持同一音效，否则用户无法形成条件反射。

语音识别：基础模式与Gemini Nano增强模式

输入侧除了触控板手势，还可以启用对话式UI。ML Kit的GenAI语音识别API同样处于alpha阶段，分为两种模式：基础模式使用传统设备端语音识别，支持API level 31及以上的Android设备；高级模式由Gemini Nano驱动，在Pixel 10及以上设备提供更好的质量和语言覆盖。

识别流程会返回四类结果：partial用于实时流中的热词检测，final是完整分析后的最终文本，completed表示语音结束，error则收集异常。

一个典型用法是语音命令保存内容：用户说出save、bookmark或remember等任一关键词，识别器检测到后即保存内容、停止识别、播放自定义earcon，并通过TTS告知用户已保存。

约束解码（Constrained Decoding）与 @Generable / @Guide

约束解码是一类推理期技术：在每一步生成 token 时，把不符合目标结构的候选直接屏蔽，使输出天然满足给定的 schema，而不是事后再用正则或 JSON 解析去修补。ML Kit 的结构化输出 API 正是基于这一机制，@Generable 标注的数据类会被编译成 schema，@Guide 则对单个字段施加约束（取值范围、描述、是否可空）。相比提示词里写“请输出 JSON”，约束解码从采样层面保证格式合法，因此适合在后台把对话文本稳定地转成词典字段。可空字段的设计让“没有教新词”这一情况有显式表达，避免模型硬凑内容。

实战案例：XR Language Teacher如何工作

Alice分享的动机来自真实痛点：在东京市场里看到想买的东西却叫不出名字，而那一刻正是学习动机最强的时刻。她想要的是戴着智能眼镜随处走动，看到什么就开口问，晚上回到酒店时所有问过的内容已经变成手机上的词汇卡。

这个演示的架构是一条完全本地的三模型链路：麦克风输入进入语音识别，摄像头帧与转录文本一起送入Gemini Nano 4，模型输出再交给语音合成从扬声器播出。Gemini Nano 4构建于开源模型Gemma 4之上，在受支持的旗舰Android设备上通过ML Kit API直接调用，模型交付由Android系统负责，应用无需打包模型。

选择Gemini Nano 4有三个原因：它能一次性完成看图与理解，不需要检测器、分类器、翻译器串联；训练覆盖超过140种语言，能处理习语、正式与非正式语体；并且对系统提示词遵循度高，可以赋予教师人格设定，降低开口练习的心理门槛。

设计上还有一个巧思：眼镜模式对话进行时，应用在后台静默生成词汇卡，包含单词、翻译、例句和提问瞬间的照片。音频优先不等于只有音频——眼镜承载好奇心，手机承载事后的回顾。

三条来自实战的工程经验

第一，用两遍式设计保障实时延迟。 在音频眼镜上，每一秒沉默都被放大。每个交互回合需要两样东西：即时的语音回答和结构化的词汇卡。如果让模型一次生成两者，后台数据生成的每个token都会推迟第一句语音。因此团队把每回合拆成两遍：第一遍只流式生成语音回复，首句完成即触发TTS；由于芯片生成短回复远快于TTS播完，中间存在数秒的空闲窗口。第二遍把第一遍的文本回复（无需图像）送回空闲芯片，提取结构化数据。等老师说完话，词汇卡已经生成完毕。

第二，流式输出中使用轻量XML标签。 早期版本中，模型正确识别出日本玩具kendama，但整句送入英语TTS后却被读成了类似"kenmi"的音——因为kendama由平假名和汉字混合书写，英语TTS处理汉字部分时完全失效。类似问题也出现在西班牙语和法语中。解法是在第一遍让模型把每个目标语言词汇包裹在target标签内流式输出，客户端按标签切分，将各片段路由到对应locale的TTS会话，再无缝拼接，实现句内切换口音。

第三，保存数据时改用结构化输出。 对话中用户可能追问而不涉及新词，数据库又需要干净的词典字段。与其用脆弱的正则表达式解析第一遍文本，不如让第二遍在后台通过ML Kit的结构化输出API提取保存对象，底层使用约束解码。开发者只需用@Generable标注数据类、用@Guide标注字段，并通过可空的卡片字段区分"教了新词"和"纯对话"两种情况。

从原型到你自己应用的路径

XR Language Teacher已随Google AI Edge Gallery应用发布，可直接下载体验，完整实现已在GitHub开源。代码库还展示了同一体验如何适配纯手机模式，以及如何通过LiteRT运行时和MediaPipe任务API触达其他平台，或接入其他开源设备端模型。

Alice列举了这套方案的延展方向：博物馆导览、看着灶台操作的烹饪助手、维修指引、无障碍解说、现场巡检工具。模型、运行时、开源实现和工具链均已就绪。

对于已有移动应用的团队，最务实的起步方式是审视现有产品：哪些核心功能改成免手操作会更好？给现有APK增加一个projected Activity，就是通往眼镜体验的第一步。