企业官网建设流程全解析

戴上眼镜在小区门口取快递，两只手都占着，手机在裤兜里——这时候你才会理解，为什么AI眼镜这类产品从第一天起就把宝押在语音上。它的屏幕要么没有、要么只有一小块单 green 单色显示区；它的触摸区只有镜腿上一小段，冬天戴手套根本按不准；它的电池塞在镜腿里，容量小得可怜。屏幕、手、电，三样都被掐死了，剩下的入口只有嘴和耳朵，也就是从业者嘴里的AIUI（语音用户界面）。我这段时间拿一副双麦克风加骨传导扬声器的AI眼镜做验证，从零搭了三个语音技能，全程没有写业务逻辑代码，靠可视化编排加大模型意图识别跑通。这篇就把完整路径摊开讲：AI眼镜的语音交互到底受哪些约束、零代码平台能覆盖到哪一层、第一个技能怎么一步步拖出来、真机上有哪些必须提前知道的坑。适合三类人看：想快速验证产品想法的、做硬件固件或系统集成需要对接语音能力的、以及做对话设计但不太会写代码的。

1. AI眼镜的交互入口为什么只能是语音

1.1 三类真实场景把界面这条路堵死了

先别急着谈技术，先想清楚人在什么状态下会戴着一副眼镜说话。我梳理下来，真正成立的使用场景只有三类，而且每一类的共同点都是“手被占用、注意力被占用、身体在移动”。

第一类是双手占用型：做饭时手上是油、搬东西、骑车、遛狗、修东西。这类场景下掏手机的成本不是“几秒钟”，而是“必须停下来、必须洗手、必须找地方放东西”。第二类是即时记录型：脑子里突然闪过一个念头、开会时想记个待办、走在路上想起要给人回个消息。这类需求的特点是价值衰减极快，三分钟内没记下来就忘了。第三类是环境查询型：这个东西多少钱、这条路怎么走、前面那个牌子写的什么、这个词什么意思——信息就在眼前，但需要额外解释。

你把这 三类场景和“点开App→找到功能→输入文字→等结果”这条路径对一遍，就会发现一个残酷的事实：手机的交互范式在眼镜上是完全失效的。眼镜的优势不是“把手机搬到脸上”，而是“把一次交互从二十秒压缩到三秒”。三秒能完成什么？一句话加上一个反馈音。这就是AIUI的全部舞台。

反过来看，什么场景不适合语音？需要对比多个选项的（比如挑一件商品比价）、需要输入精确信息的（比如填地址、输密码）、需要长时间阅读的。这些交给手机，眼镜只负责“触发”和“确认”。我在做技能拆解的时候有一条硬规矩：一个技能如果不能让用户在两次说话之内完成，就不该放到眼镜上。这条规矩帮我砍掉了大半的想法。

1.2 硬件约束不是参数表，是设计边界

很多人做AI眼镜应用失败，不是想法不对，是把手机上的交互经验直接平移过来了。我把硬件层面最影响语音体验的几个点列一下，这些是没法绕开的：

• 麦克风位置固定在镜腿/镜框上，离嘴的距离比手机远，而且随头部转动而改变朝向。这意味着信噪比比手机差一截，风噪影响被放大。
• 扬声器是开放式或骨传导，低频几乎为零，外界噪声直接混进来，音量开大了旁边人也能听见，涉及隐私。
• 电池容量只有百毫安时级别，常开麦克风做云端识别，续航会直接崩掉。
• 没有屏幕或只有极简显示，所有反馈必须靠声音和振动，用户“看不见状态”，只能“听出状态”。
• 触摸区极小，只能承担“确认/取消”这类二元操作，不能做菜单导航。

这几条约束推导出三个设计原则，我在每个技能里都会检查一遍。第一，唤醒必须在端侧完成，用低功耗的关键词检测把绝大多数音频挡在门外，只有命中之后才打开上行通道。第二，反馈必须短且分层，一个提示音表示“听到了”，一句话表示“做完了”，出问题才多说两个字。第三，必须有不依赖网络的兜底，地铁、电梯、地下车库这些地方，眼镜最需要工作，恰恰网络最差。

提示：不要把“唤醒词”当成装饰。端侧唤醒检测是AI眼镜续航的生命线，一次误唤醒意味着一次完整的音频上行和一次云端调用，一天多来几十次，电量就肉眼可见地掉。

1.3 语音优先不等于语音唯一：反馈通道要组合使用

我最初做的版本是纯语音的，用户说一句，耳机里回一句。真机跑了两天就发现问题：在嘈杂环境下，用户根本听不清反馈，但他也不知道操作到底成没成。于是用户会重复说，造成重复记录，体验直线下降。

后来我改成了三层反馈，成本几乎为零，但体验差别巨大：

这三层是递进关系，不是并列关系。第一层在拾音结束的瞬间就要响，它的作用是把“等待焦虑”压下去；第二层在动作执行完成的瞬间触发，它是嘈杂环境下唯一可靠的确认信号；第三层才承载信息。把手势（镜腿单击）也接进来，就形成了“语音输入 + 触觉确认 + 手势取消”的闭环，任何一个通道失效，另外两个还能兜住。

2. 零代码平台到底能覆盖到哪一层

2.1 一条语音请求要穿过五个环节

“不写代码”这四个字最容易误导人的地方，是让人以为整条链路都能可视化。实际上一条语音请求从人嘴到人耳，要穿过五个环节，每个环节的技术属性完全不同，能不能拖拽完成也差别很大。

第一个环节是拾音与唤醒：麦克风采集、回声消除、降噪、关键词检测。这一段跑在设备端，依赖芯片和固件，平台层完全够不着，只能通过端侧SDK的参数来调。第二个环节是语音识别（ASR）：把音频流变成文字，需要流式返回、需要端点检测判断用户说完了没有。这一段是云服务或端侧模型的能力，平台提供的是“开关和参数”。第三个环节是意图理解（NLU）：把一句话映射成“用户想干什么 + 涉及哪些关键信息”。这一段是零代码平台真正的主场，可视化配置意图、例句、槽位。第四个环节是对话管理与业务编排：判断上下文、调用接口、处理分支、组装回复。这一段也是可视化编排的核心价值区。第五个环节是语音合成（TTS）与播放：把文字变成声音，还要处理语速、断句、数字读法。

我在搭第一个技能时踩的坑就在这里：我以为“零代码”意味着我在一个画布上从头画到尾，结果发现第一、二、五环节全是配置项，第三、四环节才是画布。认清这条分界线，后面所有工作都会顺很多。

2.2 选工具时我只看四张清单

市面上的可视化对话平台多到挑花眼，每家 demo 都演示得丝滑。我自己的筛选办法是做四张清单，逐条对照，能过三张就可以试用，四张全过才值得投入。

第一张：识别能力清单。是否支持流式返回（决定首字延迟）、是否有远场/噪声场景的模型可选、是否支持热词表（把“记一下”这类高频词加权）、是否支持中英文混说。眼镜场景下远场和热词这两条几乎是刚需，缺一个体验就掉档。

第二张：理解能力清单。是否支持“意图 + 槽位”结构、是否能用模板和正则补充、是否支持同义词词典（“记一下/帮我记/添加一条”要能归到同一个意图）、是否支持置信度阈值设置。置信度阈值非常关键，它决定了“听不懂时是猜还是问”，后面我会专门讲。

第三张：编排能力清单。是否有条件分支、变量与上下文、外部接口调用、超时与异常分支、多轮对话的状态保持。这一张最容易出问题，很多平台单轮很漂亮，一涉及“用户说到一半改口”就崩。

第四张：设备接入清单。是否有面向眼镜/耳机类设备的端侧SDK、是否支持蓝牙音频通道切换、是否提供端侧唤醒词自定义、是否能拿到端侧埋点。这一张是分水岭——不少平台只做手机App和小程序，压根没考虑过眼镜这种“无屏、蓝牙、低功耗”的终端。

2.3 我的实测结论：七成拖拽，三成配置

跑完三个技能之后，我给“零代码”下了一个更准确的定义：业务逻辑零代码，工程配置必须动手。具体拆开是这样：

看清楚这张表，你就不会在“为什么我还要改配置”这件事上浪费时间了。真正需要写业务代码的情况只有两种：平台内置函数覆盖不了的文本处理，以及要对接私有接口时的鉴权。这两种用平台提供的轻量脚本能力写十几行就能解决，不至于把整个项目拖回传统开发。

注意：选平台时一定要问清楚“端侧唤醒词能不能自定义”。有些平台只提供固定的几个唤醒词，而眼镜产品的唤醒词往往是品牌资产的一部分，改不了就得整个换方案。

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 延迟是感知问题，不是数字问题

用户说“这东西反应慢”，实际感受的是三段延迟的叠加，而这三段的“可感知程度”完全不同：

这里有一条反直觉的经验：总时长一样的情况下，先出声的那个体验明显更好。因为人是按“第一个反馈出现的时间”来判断快慢的。所以我把提示音放在拾音结束的瞬间，把合成改成流式首包优先，哪怕整句话要两秒才念完，用户也会觉得“它立刻响应了”。

另外一个细节是接口调用。查天气、查日程这类接口，网络抖一下就是一两秒。我的做法是超时时间设短（比如1.5秒），超时之后立刻播报“没连上，等会儿再试”，而不是死等。用户等三秒没声音，会以为设备坏了；等一秒听到一句解释，反而觉得“这东西挺诚实”。

4.4 断网降级必须提前设计，不能事后补

眼镜最常用的场景——通勤、走路、地下空间——恰好是网络最不靠谱的地方。如果整个技能强依赖云端，那它在最需要的时候就是一块废铁。

我的降级策略分三层。第一层是本地缓存：识别出的文本先在本地存一份，云端不可用时也先回“记下了”，等联网后补同步。这一层对“记录类”技能特别有效，因为用户的核心诉求是别丢，不是立刻同步。第二层是本地意图兜底：把最高频的三五个意图做成端侧的规则匹配（比如以“记一下”开头的句子直接归到创建记录），不走云端理解。第三层是明确的失败反馈：真做不了的时候，用一句人话说清楚，并给出替代方案（“没网，先存着，联网再同步”）。

这三层里，第一层的实现成本最低、收益最高。我在画布上就是加了一个条件分支：接口返回失败 → 走本地存储节点 → 播报“先存着”。整个改动花了不到十分钟，但真机体验提升非常明显。

5. 语料、走查与上线之后的迭代

5.1 自己攒语料，两百条起步

零代码平台一般会提供一些通用语料，但眼镜场景的表达方式很特殊——句子短、语气词多、经常省略主语、经常边说边改口。这些通用语料是覆盖不到的。

我的办法是攒一个“真实说法库”，规模不用大，两百到五百条就够用。来源有三个：自己和同事在真实场景下随口说的话（拿手机录下来转文字）、对身边不熟悉这个产品的人做快速测试时的原话、以及把核心意图的每种表达方式做交叉组合生成的变体。

攒完之后要做的是分类标注：哪些是标准表达、哪些是省略表达、哪些是带噪声的、哪些是用户改口的。改口这一类特别值得单独拎出来，比如“记一下——不对，改成买酸奶”。这种句子如果直接整句当内容存，就废了。处理办法是在预处理阶段识别“不对/改成/说错了”这类修正词，取最后一次的内容。

5.2 真机走查清单，我每次都照着过一遍

功能在办公室跑通，只完成了三成。剩下七成靠走查，我固定按这张清单走：

最后一项容易被忽略，但对眼镜产品很关键。骨传导和开放式扬声器在安静环境下的漏音是实实在在的隐私问题，播报内容里如果有具体的人名、地点、金额，旁边人是能听到的。我的处理办法是把播报里涉及隐私的部分做模糊化，比如“记下了”而不是“记下了，明天下午三点跟某某开会”。

5.3 上线看什么指标，别看总数看分层

技能上线之后，最容易犯的错是只看一个总成功率。这个数字对优化毫无指导意义，因为它把所有失败原因混在一起了。我埋的指标是分层拆开的：

• 唤醒层：日唤醒次数、漏触发率（用户重复说同一句的比例）、误触发次数（无后续指令的唤醒占比）
• 识别层：字错率（抽样人工比对）、空结果率、平均识别耗时
• 理解层：意图命中率、兜底触发率、槽位置信度分布
• 交互层：平均对话轮次、中途放弃率、重复请求率
• 结果层：任务完成率、用户主动撤销率

这五层指标里，我最看重的是兜底触发率和重复请求率。兜底触发率高，说明用户说的话超出我的意图覆盖范围，要补模板或者补意图；重复请求率高，说明用户不确定操作成没成，要改反馈设计。这两个指标能覆盖八成的问题定位。

5.4 迭代节奏：小步改文案，大步改流程

语音应用的迭代有个特点：改一句话术的效果，往往比改一个模型还明显。我一般把迭代分成两个档位。小步迭代只动文案和阈值，一周一次，风险低、随时回滚；大步迭代才动画布结构和意图体系，一个月一次，必须灰度。

灰度这块，眼镜产品的用户基数通常不大，所以我不做百分比灰度，而是按人群灰度：先内部十个人，再找二十个真实场景的重度用户，最后才全量。内部测试重点看崩溃和链路，重度用户重点看语料覆盖和场景适配，两拨人关注的点完全不同。

6. 再往深走一步的两个岔路口

6.1 端侧还是云侧，取决于你的技能是什么类型

所有做眼镜语音的人最终都会碰到这个选择：识别和理解放在端上还是云上。这不是一个技术优劣问题，是一个场景匹配问题。

云侧的优势是模型大、理解准、能随时更新，代价是依赖网络、有延迟、有流量和隐私成本。端侧的优势是快、离线可用、音频不出设备，代价是模型小、理解能力有限、占用存储和算力。

我的判断标准是看技能的输入复杂度。像“记一下买牛奶”这种短指令、词汇量有限的场景，端侧规则加小模型完全够用，速度快到几乎无感，而且断网也能工作。像“帮我找一下上周开会提到的那个预算数字”这种需要长上下文和复杂推理的，必须上云。

实际产品里通常是混合的：端侧做唤醒 + 高频短指令兜底，云侧做复杂理解和内容生成，端侧命中就不上云，没命中才走云。这个架构我在画布上是用“本地规则节点优先判断”实现的，配置层面就能表达，不需要改架构。

6.2 摄像头不是负担，是语音的补充

眼镜上那颗摄像头，很多人觉得是另一个独立功能。我的看法相反：视觉是语音的纠错器。语音最大的弱点是歧义——“记一下这个”“查一下那个”里的指代，纯语音是解不了的，但配合一次拍照或者看向某处，指代立刻明确。

实操上，我在画布上加了一个很轻的分支：当槽位内容里出现“这个/那个/这里/前面”这类指代词时，触发一次拍照，把图片和语音文本一起送到理解环节。这个改动的成本很低（平台一般支持多模态输入节点），但把技能能处理的范围扩大了一截。同样的思路可以用在翻译、识物、读标牌这些场景上。

不过这里有个度要把握：不要让用户为了用语音而被迫做视觉动作。眼镜的摄像头启动有明确的社交信号（别人能看出来你在拍），在很多场合是不合适的。所以我的原则是“语音能独立完成就不动用摄像头，只有指代歧义时才提示一次”，而且提示要短——“拍一下？”三个字，用户点头或者说“好”就触发。

最后分享一个我自己反复验证过的小技巧：做减法比做加法难，但收益高得多。我第一版技能做了七个意图，用户测试下来最常用的只有一个。把另外六个砍掉之后，识别准确率、响应速度、用户满意度三项全都上升了。AI眼镜这种设备，用户对它的耐心大概只有三秒，任何一句多余的追问、任何一次多余的确认，都会被当成“这东西不好用”。先把一件事做到说一句就成，比做十件半吊子的事有价值。