戴上眼镜在小区门口取快递两只手都占着手机在裤兜里——这时候你才会理解为什么AI眼镜这类产品从第一天起就把宝押在语音上。它的屏幕要么没有、要么只有一小块单 green 单色显示区它的触摸区只有镜腿上一小段冬天戴手套根本按不准它的电池塞在镜腿里容量小得可怜。屏幕、手、电三样都被掐死了剩下的入口只有嘴和耳朵也就是从业者嘴里的AIUI语音用户界面。我这段时间拿一副双麦克风加骨传导扬声器的AI眼镜做验证从零搭了三个语音技能全程没有写业务逻辑代码靠可视化编排加大模型意图识别跑通。这篇就把完整路径摊开讲AI眼镜的语音交互到底受哪些约束、零代码平台能覆盖到哪一层、第一个技能怎么一步步拖出来、真机上有哪些必须提前知道的坑。适合三类人看想快速验证产品想法的、做硬件固件或系统集成需要对接语音能力的、以及做对话设计但不太会写代码的。1. AI眼镜的交互入口为什么只能是语音1.1 三类真实场景把界面这条路堵死了先别急着谈技术先想清楚人在什么状态下会戴着一副眼镜说话。我梳理下来真正成立的使用场景只有三类而且每一类的共同点都是“手被占用、注意力被占用、身体在移动”。第一类是双手占用型做饭时手上是油、搬东西、骑车、遛狗、修东西。这类场景下掏手机的成本不是“几秒钟”而是“必须停下来、必须洗手、必须找地方放东西”。第二类是即时记录型脑子里突然闪过一个念头、开会时想记个待办、走在路上想起要给人回个消息。这类需求的特点是价值衰减极快三分钟内没记下来就忘了。第三类是环境查询型这个东西多少钱、这条路怎么走、前面那个牌子写的什么、这个词什么意思——信息就在眼前但需要额外解释。你把这 三类场景和“点开App→找到功能→输入文字→等结果”这条路径对一遍就会发现一个残酷的事实手机的交互范式在眼镜上是完全失效的。眼镜的优势不是“把手机搬到脸上”而是“把一次交互从二十秒压缩到三秒”。三秒能完成什么一句话加上一个反馈音。这就是AIUI的全部舞台。反过来看什么场景不适合语音需要对比多个选项的比如挑一件商品比价、需要输入精确信息的比如填地址、输密码、需要长时间阅读的。这些交给手机眼镜只负责“触发”和“确认”。我在做技能拆解的时候有一条硬规矩一个技能如果不能让用户在两次说话之内完成就不该放到眼镜上。这条规矩帮我砍掉了大半的想法。1.2 硬件约束不是参数表是设计边界很多人做AI眼镜应用失败不是想法不对是把手机上的交互经验直接平移过来了。我把硬件层面最影响语音体验的几个点列一下这些是没法绕开的麦克风位置固定在镜腿/镜框上离嘴的距离比手机远而且随头部转动而改变朝向。这意味着信噪比比手机差一截风噪影响被放大。扬声器是开放式或骨传导低频几乎为零外界噪声直接混进来音量开大了旁边人也能听见涉及隐私。电池容量只有百毫安时级别常开麦克风做云端识别续航会直接崩掉。没有屏幕或只有极简显示所有反馈必须靠声音和振动用户“看不见状态”只能“听出状态”。触摸区极小只能承担“确认/取消”这类二元操作不能做菜单导航。这几条约束推导出三个设计原则我在每个技能里都会检查一遍。第一唤醒必须在端侧完成用低功耗的关键词检测把绝大多数音频挡在门外只有命中之后才打开上行通道。第二反馈必须短且分层一个提示音表示“听到了”一句话表示“做完了”出问题才多说两个字。第三必须有不依赖网络的兜底地铁、电梯、地下车库这些地方眼镜最需要工作恰恰网络最差。提示不要把“唤醒词”当成装饰。端侧唤醒检测是AI眼镜续航的生命线一次误唤醒意味着一次完整的音频上行和一次云端调用一天多来几十次电量就肉眼可见地掉。1.3 语音优先不等于语音唯一反馈通道要组合使用我最初做的版本是纯语音的用户说一句耳机里回一句。真机跑了两天就发现问题在嘈杂环境下用户根本听不清反馈但他也不知道操作到底成没成。于是用户会重复说造成重复记录体验直线下降。后来我改成了三层反馈成本几乎为零但体验差别巨大反馈层载体时长承担的职责第一层短提示音80-150ms告诉用户“我听到了正在处理”第二层镜腿轻微振动50-100ms告诉用户“操作已生效”无需听清第三层极简语音播报1-2秒告诉用户“结果是什么”这三层是递进关系不是并列关系。第一层在拾音结束的瞬间就要响它的作用是把“等待焦虑”压下去第二层在动作执行完成的瞬间触发它是嘈杂环境下唯一可靠的确认信号第三层才承载信息。把手势镜腿单击也接进来就形成了“语音输入 触觉确认 手势取消”的闭环任何一个通道失效另外两个还能兜住。2. 零代码平台到底能覆盖到哪一层2.1 一条语音请求要穿过五个环节“不写代码”这四个字最容易误导人的地方是让人以为整条链路都能可视化。实际上一条语音请求从人嘴到人耳要穿过五个环节每个环节的技术属性完全不同能不能拖拽完成也差别很大。第一个环节是拾音与唤醒麦克风采集、回声消除、降噪、关键词检测。这一段跑在设备端依赖芯片和固件平台层完全够不着只能通过端侧SDK的参数来调。第二个环节是语音识别ASR把音频流变成文字需要流式返回、需要端点检测判断用户说完了没有。这一段是云服务或端侧模型的能力平台提供的是“开关和参数”。第三个环节是意图理解NLU把一句话映射成“用户想干什么 涉及哪些关键信息”。这一段是零代码平台真正的主场可视化配置意图、例句、槽位。第四个环节是对话管理与业务编排判断上下文、调用接口、处理分支、组装回复。这一段也是可视化编排的核心价值区。第五个环节是语音合成TTS与播放把文字变成声音还要处理语速、断句、数字读法。我在搭第一个技能时踩的坑就在这里我以为“零代码”意味着我在一个画布上从头画到尾结果发现第一、二、五环节全是配置项第三、四环节才是画布。认清这条分界线后面所有工作都会顺很多。2.2 选工具时我只看四张清单市面上的可视化对话平台多到挑花眼每家 demo 都演示得丝滑。我自己的筛选办法是做四张清单逐条对照能过三张就可以试用四张全过才值得投入。第一张识别能力清单。是否支持流式返回决定首字延迟、是否有远场/噪声场景的模型可选、是否支持热词表把“记一下”这类高频词加权、是否支持中英文混说。眼镜场景下远场和热词这两条几乎是刚需缺一个体验就掉档。第二张理解能力清单。是否支持“意图 槽位”结构、是否能用模板和正则补充、是否支持同义词词典“记一下/帮我记/添加一条”要能归到同一个意图、是否支持置信度阈值设置。置信度阈值非常关键它决定了“听不懂时是猜还是问”后面我会专门讲。第三张编排能力清单。是否有条件分支、变量与上下文、外部接口调用、超时与异常分支、多轮对话的状态保持。这一张最容易出问题很多平台单轮很漂亮一涉及“用户说到一半改口”就崩。第四张设备接入清单。是否有面向眼镜/耳机类设备的端侧SDK、是否支持蓝牙音频通道切换、是否提供端侧唤醒词自定义、是否能拿到端侧埋点。这一张是分水岭——不少平台只做手机App和小程序压根没考虑过眼镜这种“无屏、蓝牙、低功耗”的终端。2.3 我的实测结论七成拖拽三成配置跑完三个技能之后我给“零代码”下了一个更准确的定义业务逻辑零代码工程配置必须动手。具体拆开是这样工作内容实现方式是否零代码意图、例句、槽位定义平台表单填写是多轮对话流程、分支判断可视化画布连线是接口调用与结果拼装画布节点 参数映射基本是复杂文本处理如把口语时间转成时间戳少量配置或平台内置函数部分是唤醒词、降噪、VAD参数端侧SDK配置项否但只是改参数TTS音色、语速、SSML平台配置 文本标记是设备端音频通道对接需要固件/App侧配合否看清楚这张表你就不会在“为什么我还要改配置”这件事上浪费时间了。真正需要写业务代码的情况只有两种平台内置函数覆盖不了的文本处理以及要对接私有接口时的鉴权。这两种用平台提供的轻量脚本能力写十几行就能解决不至于把整个项目拖回传统开发。注意选平台时一定要问清楚“端侧唤醒词能不能自定义”。有些平台只提供固定的几个唤醒词而眼镜产品的唤醒词往往是品牌资产的一部分改不了就得整个换方案。3. 从零拖出一个“随手记”技能3.1 先写意图清单再碰画布新手最容易犯的错是打开画布就开始连线。我现在的固定流程是先在一张纸上把意图清单写完写完再动手。意图清单的格式很简单三列用户会怎么说、我要做什么、做完怎么回。以“随手记”为例第一版我列了四条意图创建记录“记一下买牛奶”“帮我记个事明天下午三点开会”查询记录“我昨天记了什么”“念一下我的待办”删除记录“把刚才那条删掉”无关闲聊兜底礼貌收尾这四条里只有第一条是核心其余三条都是为了让技能“像一个完整的东西”。这里有个经验第一版技能永远只做一个核心意图其他都先做成占位。因为核心意图跑通之后你会发现大量的问题集中在这一个意图的边界上用户说得太随意、信息不全、说一半改口把这些边界处理完比多做三个意图有价值得多。意图清单还要顺手标注“必需槽位”。创建记录的必需槽位是“内容”可选槽位是“时间”。这个标注直接决定了后面画布上要画几个分支——缺内容要追问缺时间可以默认当前时间。3.2 用模板而不是列举来定义说法意图识别的准确率八成取决于例句的质量。我见过很多配置是这么写的列二十条例句每条都是完整的一句话。这样做的结果是用户稍微换个说法就识别不到。我用的办法是模板 槽位标记配合同义词词典。平台一般支持在例句里用占位符标记槽位识别时自动抽取。配置大概长这样{ intent: note.create, templates: [ 记一下{content}, 帮我记{content}, 记个事{content}, 添加一条{content}, {content}记一下, 提醒我{time}{content} ], slots: { content: { type: free_text, required: true }, time: { type: datetime, required: false, default: now } }, synonyms: { 记一下: [记下, 记录, 帮我记, 添加一条, 存一下] } }这套配置里有三个关键点。第一动词短语全部进同义词表不要靠例句穷举因为用户的口头表达是无穷的而同义词是可枚举的。第二句式要覆盖前置和后置两种语序“记一下买牛奶”和“买牛奶记一下”在日常说话里出现频率都很高只配一种必然漏。第三自由文本槽位要设置结束条件否则用户说“记一下明天下午三点跟老王开会讨论预算的事”时槽位可能只截到“明天”。提示模板里的标点很关键。用户对着眼镜说话时语气词特别多“嗯”“那个”“就是”在预处理阶段要把这些填充词过滤掉否则会污染槽位内容。3.3 多轮不是越多越好两次是上限画布上的分支设计我遵循一条很朴素的规则能不追问就不追问非要追问只追一次。眼镜场景下用户是在移动中说话多一轮交互就多一次被打断、被环境噪声干扰、被同伴打断的机会。具体到“随手记”这个技能用户说“记一下买牛奶” → 内容齐全 → 直接执行 → 回“记下了”。用户说“记一下” → 缺内容 → 追问“记什么” → 用户补充 → 执行。用户说“记一下明天下午三点开会”但时间解析失败 →不要追问时间直接把整句话当内容存下来回“记下了时间没识别整句存了”。第三条是这个技能里最值钱的设计。因为“记不下来”比“记得不精确”严重得多用户的原始诉求是“别忘了”不是“帮我建个日程”。很多语音应用死在过度追求结构化上——为了拿到一个完美的时间字段反复追问三次用户早就烦了。画布上的结构大致是入口节点 → 意图判断 → 槽位完整性检查条件分支→ 补全节点 or 执行节点 → 结果播报节点 → 异常兜底节点。每个分支都要连到一个明确的播报节点不允许存在没有出口的分支这是我在真机测试中总结的铁律因为悬空分支在真机上表现为“说完话之后一片沉默”用户会以为设备死机了。3.4 语音文案是另一门手艺写TTS文案和写界面文案完全是两回事。界面上你可以写“好的已为您成功创建一条备忘记录”用户扫一眼就完了语音里这句话要念三秒多而且用户必须听完才能确认。我把这条经验总结成一句屏幕上的字是给人看的语音里的字是给人听的听觉没有回看功能。具体规则我列了一张对照表团队里所有人都按这个改场景别这么说改成为什么操作成功好的已经为您成功创建了一条备忘记录记下了三个字够用多余的字全是干扰查询中请稍等正在为您查询相关信息查一下短促的过渡语比客套话自然没听清抱歉我没有听清楚您说的内容请您再说一遍没听清再说一次七个字讲完的事不要用二十个字结果为空没有找到与您查询条件相匹配的记录没有空结果本身就是信息出错系统繁忙请稍后重试没连上等会儿再试说人话别甩系统状态除了长度还有三个细节必须处理。数字和单位要写成念出来的样子“3点”在不同上下文里可能念成“三点”或“三时”最好在文本里明确写“下午三点”。标点要当成停顿控制符用逗号短停、句号长停写文案的时候就要想着“这句话在哪里换气”。语速建议比默认慢一点点因为开放式扬声器的声音是“飘”在环境里的用户需要额外的注意力去解析语速太快直接听不懂。4. 真机上的问题九成出在实验室之外4.1 一条完整的排查链路长什么样先说一个具体现象技能在办公室里测试二十次能成十九次拿到马路边上十次里有三四次毫无反应。这个“没反应”包含三种完全不同的原因必须先区分开否则永远修不好。我的排查链路是这样的从设备端往云端一步步推第一步确认唤醒有没有触发。看端侧日志里的关键词检测记录。如果没有触发问题在拾音和唤醒模型跟后面的识别、理解、合成全都无关。这一步能排掉将近一半的“没反应”。第二步确认音频有没有上行。唤醒触发了但云端没收到音频通常是蓝牙音频通道没切过来——眼镜的麦克风和手机的音频通路是两套通道切换有延迟用户开口太快就会被截掉前半句。第三步确认ASR有没有返回。音频到了但识别结果为空多半是端点检测VAD被环境噪声卡住了一直认为用户还在说话迟迟不结束。第四步确认意图有没有命中。识别出来的是文字但意图置信度低于阈值走了兜底分支。这一步要打印出识别原文和置信度不要只看最终结果。第五步看链路耗时。每一段打一个时间戳算出差值哪一段超预算就优化哪一段。这套方法的价值在于它把一个模糊的“不好用”拆成了五个可以单独验证的假设。我见过太多团队在“识别不准”这个结论上反复调模型实际上问题出在蓝牙通道切换。4.2 唤醒误触发和漏触发是一对冤家唤醒这块永远在调一个平衡阈值调低漏触发少了但误触发上来了阈值调高误触发少了但用户要喊两遍。我的处理办法是分场景配置 二次确认。端侧SDK一般允许设置唤醒的灵敏度档位我把它和“当前是否在播放音频”“是否检测到人声活动”绑定起来设备静默时用中等灵敏度正在播放时降低灵敏度因为扬声器的声音会被麦克风拾到容易自激。另外加一个很便宜的设计——唤醒后先给一个短提示音再开始拾音这个提示音同时起到了“请开始说”的引导作用用户的开口时机被规整了端点检测的压力也小了。误触发的成本要算清楚一次误唤醒 一次音频上行 一次云端识别 一次可能的合成播报电量、流量、隐私三方面都吃亏。所以我宁可让用户偶尔喊两遍也不让它在安静的会议室里自己冒出一句“我在”。注意唤醒词不要选日常对话里高频出现的词。我试过一个由两个常见词组成的唤醒词在家里聊天时一天误触发十几次换成三个音节的组合之后降到个位数。4.3 延迟是感知问题不是数字问题用户说“这东西反应慢”实际感受的是三段延迟的叠加而这三段的“可感知程度”完全不同延迟段典型值用户感知优化手段拾音结束判断400-800ms中等调VAD静音阈值配合提示音掩盖识别首字返回200-500ms弱用流式识别边识别边理解意图与接口100-800ms强缓存常用结果接口降级合成首包300-800ms强用流式合成先播首句这里有一条反直觉的经验总时长一样的情况下先出声的那个体验明显更好。因为人是按“第一个反馈出现的时间”来判断快慢的。所以我把提示音放在拾音结束的瞬间把合成改成流式首包优先哪怕整句话要两秒才念完用户也会觉得“它立刻响应了”。另外一个细节是接口调用。查天气、查日程这类接口网络抖一下就是一两秒。我的做法是超时时间设短比如1.5秒超时之后立刻播报“没连上等会儿再试”而不是死等。用户等三秒没声音会以为设备坏了等一秒听到一句解释反而觉得“这东西挺诚实”。4.4 断网降级必须提前设计不能事后补眼镜最常用的场景——通勤、走路、地下空间——恰好是网络最不靠谱的地方。如果整个技能强依赖云端那它在最需要的时候就是一块废铁。我的降级策略分三层。第一层是本地缓存识别出的文本先在本地存一份云端不可用时也先回“记下了”等联网后补同步。这一层对“记录类”技能特别有效因为用户的核心诉求是别丢不是立刻同步。第二层是本地意图兜底把最高频的三五个意图做成端侧的规则匹配比如以“记一下”开头的句子直接归到创建记录不走云端理解。第三层是明确的失败反馈真做不了的时候用一句人话说清楚并给出替代方案“没网先存着联网再同步”。这三层里第一层的实现成本最低、收益最高。我在画布上就是加了一个条件分支接口返回失败 → 走本地存储节点 → 播报“先存着”。整个改动花了不到十分钟但真机体验提升非常明显。5. 语料、走查与上线之后的迭代5.1 自己攒语料两百条起步零代码平台一般会提供一些通用语料但眼镜场景的表达方式很特殊——句子短、语气词多、经常省略主语、经常边说边改口。这些通用语料是覆盖不到的。我的办法是攒一个“真实说法库”规模不用大两百到五百条就够用。来源有三个自己和同事在真实场景下随口说的话拿手机录下来转文字、对身边不熟悉这个产品的人做快速测试时的原话、以及把核心意图的每种表达方式做交叉组合生成的变体。攒完之后要做的是分类标注哪些是标准表达、哪些是省略表达、哪些是带噪声的、哪些是用户改口的。改口这一类特别值得单独拎出来比如“记一下——不对改成买酸奶”。这种句子如果直接整句当内容存就废了。处理办法是在预处理阶段识别“不对/改成/说错了”这类修正词取最后一次的内容。5.2 真机走查清单我每次都照着过一遍功能在办公室跑通只完成了三成。剩下七成靠走查我固定按这张清单走检查项具体做法关注点安静环境室内正常音量基线是否正常街道环境马路边、有车流唤醒率、识别准确率下降幅度风噪环境迎风走、骑车慢速是否出现持续的无效唤醒多人说话两人以上同时聊天是否会把旁人说话当成指令移动中断说到一半停下、改口是否能正确结束或修正网络切换走到信号弱的位置降级是否生效、反馈是否清晰长时佩戴连续使用两小时电量消耗、是否发热、是否误触发累积音量与隐私最大音量、旁人距离一米旁人是否能听清播报内容最后一项容易被忽略但对眼镜产品很关键。骨传导和开放式扬声器在安静环境下的漏音是实实在在的隐私问题播报内容里如果有具体的人名、地点、金额旁边人是能听到的。我的处理办法是把播报里涉及隐私的部分做模糊化比如“记下了”而不是“记下了明天下午三点跟某某开会”。5.3 上线看什么指标别看总数看分层技能上线之后最容易犯的错是只看一个总成功率。这个数字对优化毫无指导意义因为它把所有失败原因混在一起了。我埋的指标是分层拆开的唤醒层日唤醒次数、漏触发率用户重复说同一句的比例、误触发次数无后续指令的唤醒占比识别层字错率抽样人工比对、空结果率、平均识别耗时理解层意图命中率、兜底触发率、槽位置信度分布交互层平均对话轮次、中途放弃率、重复请求率结果层任务完成率、用户主动撤销率这五层指标里我最看重的是兜底触发率和重复请求率。兜底触发率高说明用户说的话超出我的意图覆盖范围要补模板或者补意图重复请求率高说明用户不确定操作成没成要改反馈设计。这两个指标能覆盖八成的问题定位。5.4 迭代节奏小步改文案大步改流程语音应用的迭代有个特点改一句话术的效果往往比改一个模型还明显。我一般把迭代分成两个档位。小步迭代只动文案和阈值一周一次风险低、随时回滚大步迭代才动画布结构和意图体系一个月一次必须灰度。灰度这块眼镜产品的用户基数通常不大所以我不做百分比灰度而是按人群灰度先内部十个人再找二十个真实场景的重度用户最后才全量。内部测试重点看崩溃和链路重度用户重点看语料覆盖和场景适配两拨人关注的点完全不同。6. 再往深走一步的两个岔路口6.1 端侧还是云侧取决于你的技能是什么类型所有做眼镜语音的人最终都会碰到这个选择识别和理解放在端上还是云上。这不是一个技术优劣问题是一个场景匹配问题。云侧的优势是模型大、理解准、能随时更新代价是依赖网络、有延迟、有流量和隐私成本。端侧的优势是快、离线可用、音频不出设备代价是模型小、理解能力有限、占用存储和算力。我的判断标准是看技能的输入复杂度。像“记一下买牛奶”这种短指令、词汇量有限的场景端侧规则加小模型完全够用速度快到几乎无感而且断网也能工作。像“帮我找一下上周开会提到的那个预算数字”这种需要长上下文和复杂推理的必须上云。实际产品里通常是混合的端侧做唤醒 高频短指令兜底云侧做复杂理解和内容生成端侧命中就不上云没命中才走云。这个架构我在画布上是用“本地规则节点优先判断”实现的配置层面就能表达不需要改架构。6.2 摄像头不是负担是语音的补充眼镜上那颗摄像头很多人觉得是另一个独立功能。我的看法相反视觉是语音的纠错器。语音最大的弱点是歧义——“记一下这个”“查一下那个”里的指代纯语音是解不了的但配合一次拍照或者看向某处指代立刻明确。实操上我在画布上加了一个很轻的分支当槽位内容里出现“这个/那个/这里/前面”这类指代词时触发一次拍照把图片和语音文本一起送到理解环节。这个改动的成本很低平台一般支持多模态输入节点但把技能能处理的范围扩大了一截。同样的思路可以用在翻译、识物、读标牌这些场景上。不过这里有个度要把握不要让用户为了用语音而被迫做视觉动作。眼镜的摄像头启动有明确的社交信号别人能看出来你在拍在很多场合是不合适的。所以我的原则是“语音能独立完成就不动用摄像头只有指代歧义时才提示一次”而且提示要短——“拍一下”三个字用户点头或者说“好”就触发。最后分享一个我自己反复验证过的小技巧做减法比做加法难但收益高得多。我第一版技能做了七个意图用户测试下来最常用的只有一个。把另外六个砍掉之后识别准确率、响应速度、用户满意度三项全都上升了。AI眼镜这种设备用户对它的耐心大概只有三秒任何一句多余的追问、任何一次多余的确认都会被当成“这东西不好用”。先把一件事做到说一句就成比做十件半吊子的事有价值。
