企业官网建设流程全解析

做AI眼镜的语音交互，最尴尬的不是技术不够，而是你打开手机上的开发工具，发现整个项目里写代码的时间只占两成，剩下八成全耗在"这句话在嘈杂的马路边能不能被听清""卡片在单目绿色屏幕上会不会糊成一团""用户说完话到耳机出声之间那 1.8 秒他会不会以为死机了"。我去年接手一个单目波导眼镜的语音助手改造，团队一共三个人，两个不懂编码，最后靠零代码的对话编排平台，把一套六意图的语音应用从需求到真机灰度跑完了全程。这篇就把整个路径摊开讲：为什么眼镜上的语音交互不能照搬手机 App、零代码平台到底能覆盖到哪一层、意图地图怎么画、话术怎么写才"抗造"、延迟预算怎么算、小屏幕上那张卡片怎么排版才不会让人眯眼，以及我踩过的那些坑。适合做硬件产品的、做交互设计的、独立开发者，还有想给自己眼镜项目加个语音入口但完全不想碰代码的人。

1. 先把"眼镜上的语音"这件事想清楚

1.1 眼镜的物理约束，决定了你不能照搬手机 App

手机能做语音助手，是因为它有一个 6 英寸的屏幕可以兜底：听错了，用户低头看一眼就纠正了。眼镜没有这个兜底条件。主流单目波导方案的有效显示区域大概等效于两米外的一块 25 到 30 英寸屏幕，视场角 20 到 30 度，颜色常常只有单绿，分辨率折算下来 640×480 这个量级。这意味着你屏幕上最多放三行字，而且这三行字必须在用户走路、骑车、切菜、开会的时候被"扫一眼"读懂。

再加上输入方式极其贫瘠。镜腿上的触摸条基本只能做一维操作：前后滑、点一下、长按，有的方案还加了点头和摇头的姿态识别，但精度和误触都很一般。抬手去摸镜腿这个动作在骑行、拎东西、手上沾油的时候根本做不出来。所以语音不是眼镜的"附加功能"，而是它的主入口，视觉只是确认和补位。

这个判断会反过来影响你的整个设计取向：能用一句话解决的，绝不让用户滑两下；能靠播报说清楚的，绝不往屏幕上堆字；需要用户做选择的场景，选项不能超过三个。我在第一版里给"待办清单"做了个能上下滑动的列表，真机一测，测试者平均要滑四次才能找到目标条目，全部放弃。这不是审美问题，是物理约束。

1.2 AIUI 和传统 GUI 的本质差别：意图优先，界面兜底

行业内现在把这种交互叫 AIUI，即以意图为中心、多模态融合的界面。听起来玄，落到实处就一句话：用户不关心你的功能层级，他只说他想要什么，系统负责把这句话翻译成动作，界面只在必要的时候出现，说完就消失。

举个具体对比。手机 App 的逻辑是"你点开清单 → 点加号 → 输入文字 → 选时间 → 保存"，五步。眼镜上的逻辑应该是"用户说'提醒我六点交电费'"→ 系统识别意图是创建待办，槽位是时间 18:00 和事项"交电费"→ 直接建成 → 回一句"好，六点提醒你交电费"→ 屏幕上闪一张两行的确认卡，8 秒后自动消失。一步。

这里有个容易被忽略的设计点：AIUI 里"沉默"也是输出。屏幕上什么都没有，往往比显示一个"正在处理"的转圈动画更好，因为前者不打断用户对环境的注意力。但沉默不能超过 1.5 秒，超过用户就会怀疑设备坏了。所以你的设计必须精确到毫秒级地规划"什么时候说话、什么时候闭嘴、什么时候上屏"。

多模态融合的价值也在这里。语音负责表达意图，视觉负责承载"列表、数字、确认"这类不适合听的信息，姿态和触摸负责在嘈杂环境下做快速纠错。三者不是并列的，是有优先级的：语音永远第一，视觉永远第二，触摸和姿态是应急通道。

1.3 零代码方案的能力边界在哪

先说清楚"零代码"在眼镜语音项目里到底指什么。它指的是：意图定义、训练语料录入、对话流程编排、槽位配置、回复话术、卡片样式、日志分析这些环节，全部在可视化界面里点出来，不写业务代码。但它不覆盖三件事：设备端音频链路集成、唤醒词模型烧录、卡片渲染协议的端侧实现。这三块要么由硬件方案商提供 SDK，要么得有人写代码。

我把这个边界讲得直白一点：零代码平台管"大脑"，SDK 管"耳朵和嘴"。你的项目里如果已经有能跑通的音频通路（麦克风采集、蓝牙传输、扬声器播放），那剩下的对话逻辑基本可以全在平台上完成。如果没有，先解决音频通路，别急着搭对话。

这个边界认知非常重要，因为它决定了你的排期。我见过有团队花两周在平台上调意图识别率，结果发现根本问题是耳机麦克风在风噪下信噪比太差，怎么调都没用。方向错了，努力全是成本。

提示：开工前先做一次"裸链路测试"，不接任何对话逻辑，只测"说一句话，设备能不能完整录到并回放"。这一步过了，再谈上层。

2. 开发前的方案选型与整体架构设计

2.1 端-管-云三段式架构拆解

大多数 AI 眼镜的语音方案不是"眼镜直连云端"，而是"眼镜 → 手机伴侣 App → 云端"。原因是眼镜的电池容量通常只有 200 到 300 毫安时，撑不住长时间的无线传输和音频编解码，手机天然是个中转站和算力补给。所以你的架构图实际是三段：

端侧负责唤醒词检测、音频采集、降噪和回声消除、卡片渲染、触摸与姿态事件上报。唤醒词检测一定要放在端侧的低功耗 DSP 上，因为如果把原始音频一直往上传，功耗和隐私都扛不住。

管侧（手机伴侣 App）负责音频流转发、网络状态管理、断线重连、把云端返回的卡片数据转成端侧能识别的协议。这一层最容易被低估，实际上它决定了你的稳定性上限。

云侧负责语音识别、意图理解、对话管理、语音合成，以及你自己的业务逻辑（存待办、查天气、调日程）。零代码平台通常落在这一层。

我建议在画架构图的时候，把每一段的延迟预算也标上去，因为后面调优的时候你会反复回来看这张图。蓝牙音频从眼镜到手机的单向延迟，实测在 100 到 200 毫秒之间，这个数字是硬成本，砍不掉，只能靠别的地方省回来。

2.2 零代码平台选型的六个硬指标

市面上做对话编排的可视化平台不少，但能撑住眼镜场景的不多。我按实战优先级排了六个硬指标，选型的时候可以当验收清单用：

这六条里，我最看重的是"打断"和"流式合成"。前者直接决定体验是否自然，后者直接决定用户觉得你"聪明"还是"迟钝"。很多平台在演示环境里表现很好，一上真机就露馅，原因就是这两块做得不扎实。

2.3 延迟预算怎么算：一张表把 2 秒砍到 1.3 秒

延迟是语音交互的生死线。行业内的经验值是：端到端 1.2 秒以内算"自然"，1.5 到 2 秒算"能用但有点慢"，超过 2.5 秒用户会开始重复说话，超过 3 秒基本判定失败。所以你要做的是把整条链路拆开，一段一段掐。

我第一版实测的预算是这样的：

初版加起来 2430 毫秒，用户体感就是"这玩意儿反应好慢"。优化后 1430 毫秒，压到了可接受区间。这里面最大的两块红利来自"端点检测尾点"和"业务调用"。端点检测从 700 毫秒砍到 400 毫秒，靠的是加入语义端点判断——用户的语气如果是明显收尾的降调，就提前切断；业务调用从 600 毫秒降到 250 毫秒，靠的是把"存待办"和"生成回复话术"这两个动作并行执行，而不是串行等待。

有一点要提醒：端点检测的尾点不能无脑往下压。压到 300 毫秒以下，用户在句子中间换气、思考、说"那个……"的时候就会被切断，识别结果变成半截话，反而更糟。400 到 500 毫秒是实践中比较稳的区间，配合语义端点做动态调整效果最好。

注意：延迟测试一定要在真实网络下做，别在办公室 Wi-Fi 里测完就宣布达标。移动网络下的抖动会让你的 P95 延迟比平均值高出 40% 以上，而用户记住的永远是那几次卡顿。

3. 动手：从零搭一个"随身清单"语音应用

我拿"随身清单"当示例，因为它麻雀虽小五脏俱全：有增删改查，有多轮澄清，有列表展示，还有时间这种难处理的槽位。把它跑通，其他应用基本都是换皮。

3.1 第一步：画意图地图，把需求收敛到六个意图

新手最容易犯的错是一上来就开平台，边搭边想。这样做的结果是意图越加越多，最后三十几个意图互相打架，识别率一路下滑。正确做法是先画意图地图，把用户可能说的话归成有限的几类。

我的收敛结果是这样：

六个意图，覆盖了九成以上的真实表达。这里有个取舍：我砍掉了"按分类查询""按优先级排序"这类听起来很合理但实际极少用的功能。眼镜是碎片场景设备，用户不会站在路口思考"我要按项目维度筛选待办"。意图数量控制在十以内，识别准确率和维护成本都会好看很多。

每个意图还要配一个"负样本"集合，也就是长得像但不属于这个意图的说法。比如"交电费多少钱"看着像查询待办，实际是问费用，得排除掉。负样本不用多，每个意图配五到八条，效果提升很明显。

3.2 第二步：写训练话术，越"糙"越准

这一节是我认为整个项目里最值得花时间的地方。平台给了你录入训练语料的功能，很多人就写几句标准句交差，比如"创建一条待办事项""查询今日待办列表"，结果真机一测，用户说"帮我记一下明天要还书"，识别不出来。

原因很简单：书面语和口语的表达分布差得太远。我的做法是每个意图写 20 条以上，并且刻意覆盖六种"脏"情况：

• 短句和长句混合：既有"记一下买菜"，也有"那个我想想啊，你帮我记一下明天下午去趟超市买点菜回来"
• 带语气词和口头禅："嗯""那个""就是""帮我""给我""麻烦"
• 带方言口音的表达：不用刻意写方言词，但要包含常见的语序倒装和省略，比如"电费六点提醒"
• 带否定和修正："不是明天是后天""我说的是八点不是六点"
• 在噪音环境下的可能听错形式："待办"可能被识别成"代办""呆办"，把这些变体也加进去
• 数字的多种表达："六点""六点半""18 点""晚上六点""快六点的时候"

写完之后还有一步很关键：自己念一遍。不是默读，是出声念，模拟在走路、手里拿着东西、语速偏快的情况下说。念的时候你会发现很多写下来很顺、说出来很别扭的句子，这些就是需要改的。我第一版有一半的语料在念完之后被重写了。

心得：语料的质量比数量重要。200 条精心覆盖各种口语变体的语料，效果远好于 1000 条句式雷同的模板句。

3.3 第三步：流程编排，槽位、澄清与兜底

流程编排是把意图串起来的地方。一个标准的创建待办流程大概长这样：唤醒 → 语音识别 → 意图判定 → 槽位抽取 → 判断槽位是否齐全 → 齐全则调业务接口 → 生成回复话术 → 语音合成播报 → 推送卡片 → 结束。

关键是"槽位不齐全"这个分支怎么处理。我的原则是：一次只问一个槽位。用户说"帮我记一下"，缺事项和时间，你千万别问"请问您要记录什么事项、什么时间提醒"，这种一次性追问两个槽位的做法在语音场景里几乎必然失败，因为用户回答完第一个就忘了第二个。

正确做法是先问最重要的那个："记什么？"用户答完，再问"什么时候提醒？"虽然多一轮，但成功率高出很多。

还有一个细节：连续两次没听清，就要降级。我的降级策略是三级——第一次没听清，重问一遍并给个示例（"没听清，你可以说'提醒我六点交电费'"）；第二次没听清，把候选列出来让用户选（"你是想说交电费，还是买菜？"）；第三次还不行，直接上屏一张手动编辑卡，把语音输入的内容预填进去，让用户用触摸条确认或微调。这个兜底路径能救回相当一部分失败会话，别省。

兜底话术也要写得像人话。平台默认的"抱歉，我没有理解您的意思"是典型的机器腔，我改成"这句我没接住，你换个说法试试"或者"这个我还不会，要不你换个问法"。测试用户对这个改动的反馈是"感觉它没那么笨了"，虽然能力完全一样。

3.4 第四步：小屏幕上的视觉卡片怎么设计

前面说过，单目波导的显示区域很有限。我按实际佩戴体验定了几条硬规矩：

信息密度：一屏最多三行，每行不超过 12 个汉字。超了就截断加省略号，或者分页但必须能用一句话切页（"下一个"）。

字号：等效视角不小于 0.6 度。换算下来，如果你把显示画面当成两米外的一块屏幕，标题行的高度至少要有 40 像素。低于这个值，用户在走动状态下基本读不清。

配色：单绿方案只有明暗两级，所以不能靠颜色区分信息层级，只能靠亮度对比和字号。主信息用最亮，辅助信息降到 60% 亮度，弱化信息降到 40%。三档足够了，再多就乱。

停留时长：确认类卡片 3 到 5 秒自动消失，列表类卡片 8 到 10 秒。用户如果在这期间说了新指令，卡片要立即消失，不能语音和画面打架。

平台输出的卡片数据结构通常是一段配置，我实际用的字段大概是这样：

{ "cardType": "list", "title": "今天还有 2 件事", "items": [ { "id": "t1", "main": "交电费", "sub": "18:00" }, { "id": "t2", "main": "取快递", "sub": "20:30" } ], "maxLines": 3, "autoDismissMs": 8000, "align": "left", "brightnessLevel": 3 }

这不是写代码，是填配置，零代码平台一般会提供表单式的可视化编辑器，你需要理解的是每个字段背后的显示逻辑，而不是语法本身。比如maxLines和autoDismissMs这两个字段，就对应着"眼球扫读的时间"和"信息量的上限"，它们的取值要以真机实测为准，别照抄。

3.5 第五步：真机联调与灰度

平台上的模拟器永远比真机乐观。模拟器里没有风噪、没有蓝牙抖动、没有用户突然改口。所以真机联调是绕不过去的一关，我建议至少做三轮：

第一轮，功能贯通。就在安静办公室，一个人操作，把六个意图的全链路跑一遍，确认没有断路、没有死循环、卡片能正常渲染。

第二轮，场景模拟。换到嘈杂环境，边走边测，手上拿着东西测，戴帽子测（影响麦克风拾音），边走边说话测。这一轮会暴露大量问题，我的记录里超过一半的 bug 都是这轮发现的。

第三轮，陌生人测试。找完全没参与过设计的人来用，只给一句"你试着让它帮你记件事"，不教任何话术。这一轮看的是"可发现性"——用户能不能自然地想到该怎么说。我第一轮陌生人测试的结果很打脸：一半的人第一句话是"你好"，而我没设计唤醒后的欢迎语，直接卡住。

灰度阶段建议先放十到二十个人，用一周，把日志收上来。日志里最值得看的是三类：未识别语句、澄清次数超过两次的会话、中途放弃的会话。这三类就是你的优化清单。

4. 上线前后最容易踩的六个坑

4.1 识别不准，先别急着换模型

遇到识别率低，多数人的第一反应是换更强的模型或者加更多语料。但我的经验是，先排除三个更基础的问题，往往比换模型有效得多。

第一是麦克风位置与信噪比。眼镜的麦克风通常装在镜腿末端，离嘴有 15 到 20 厘米，还经常被头发、帽子、衣领遮挡。这个距离下，环境噪音和风噪的影响被放大得厉害。判断方法很简单：把设备录到的原始音频导出来听一遍，如果人耳听着都费劲，模型再怎么调也没用，得从结构或者降噪算法上解决。

第二是端点检测切得太早。前面提过，尾点压得太短会把句子切半，导致识别结果缺头少尾。判断方法：看日志里识别结果是不是经常只有后半句，或者只有前半句。

第三是语料分布偏差。你的训练语料如果全是安静环境下标准普通话，真机上的口音、语速、噪音就会让识别率断崖式下跌。这个只能靠补充真实场景语料解决，而且最好用真实录音，不是文本改写。

这三条排除完还不行，再考虑换模型。实际项目里，前三条能解决七成以上的"识别不准"投诉。

4.2 延迟忽高忽低，八成是音频链路

延迟问题分两种：稳定偏慢，和忽快忽慢。前者是架构问题，靠优化预算表解决；后者是链路问题，更烦人。我踩过一次，表现是同样的话，有时候 1.2 秒出结果，有时候 3 秒还没动静，重试一次又正常了。

排查过程是这样的：先在每一段打时间戳，把"音频开始采集""识别首字返回""业务接口返回""合成首包到达""开始播放"这五个点记录下来，跑了五十次，画成散点图。结果很清楚：稳定偏慢的是业务接口那一段，波动大的是"音频开始采集"到"识别首字返回"这一段。

波动大的原因最后定位到蓝牙音频的缓冲策略。手机端为了省电，会在音频流空闲时把缓冲降下来，重新激活时需要时间重新协商，这个协商在弱信号下能拖到几百毫秒。解决方法是让音频通路保持一个"轻量心跳"，不要完全空闲。改完之后 P95 延迟从 2.9 秒降到 1.6 秒。

提示：延迟问题一定要看 P95 和 P99，不要看平均值。平均值 1.3 秒听上去很美，但如果每二十次就有一次超过 3 秒，用户的印象就是"这东西经常卡"。

4.3 多轮对话"串味"和"失忆"

多轮对话有两个经典毛病。失忆是用户说完一轮之后，系统把上下文忘了，下一句"改成八点"就不知道要改什么。串味更隐蔽，是上一轮的槽位污染了下一轮，比如用户先查了"交电费"，接着说"再加一个买菜"，系统把"买菜"的时间误填成了交电费的时间。

失忆的常见原因是会话超时设得太短，或者平台的多轮上下文默认关闭。检查方法：在流程里显式引用上一轮的意图和槽位，看能不能取到。我一般把会话超时设成 30 秒，用户在这个窗口内说话都算同一轮对话，超过就重置。

串味的根因是槽位没有随意图重置。我的做法是每进入一个新意图，先把不属于该意图的槽位清空，只保留跨意图共享的会话级变量（比如"当前正在操作的那条待办"）。这个动作在可视化平台里通常就是一个"重置变量"节点，别偷懒不加。

还有一种情况值得单独说：用户中途改主意。比如"提醒我六点交电费……算了改成八点"。这时候正确做法是识别出这是修正，直接更新槽位，不要走"先创建再修改"的两步流程。这需要在话术里显式覆盖"算了""不对""改成"这类转折词，让意图识别能接住。

4.4 播报难听、太长、打断不了

语音合成的自然度是一方面，但更影响体验的是长度和节奏。我定了几条规矩：

单次播报控制在 8 秒以内。按每秒 4.5 个字的语速算，8 秒大概是 36 个字。超过这个长度，用户会走神，尤其在他走路的时候。如果信息确实多，拆成两次播报，中间留一个自然的停顿，或者干脆只播最关键的，剩下的上屏。

句尾不要用机械的降调。很多默认音色每句结尾都是同一个调，连着播三句就格外假。选音色的时候，试听要连着听三句以上，听的是句间衔接，不是单句。

必须支持打断。用户说到一半想插话，播报要立即停。这个功能端侧要做回声消除，不然设备会把自己的声音录进去。测试方法：播报过程中说"停"，看响应时间是否小于 300 毫秒。我见过有的方案要等一整句播完才响应，那体验基本等于没有。

数字和专有名词要单独处理。"18:00"读成"十八点"还是"下午六点"，"6"读成"六"还是"六百"，这些都要在文本规范化阶段处理。平台一般有数字读法配置，别用默认值，逐条测。

4.5 常见问题速查表

把上面这些整理成一张表，出问题的时候可以直接对号入座：

这张表我贴在工位上贴了两个月，出问题先扫一眼，能省掉大量瞎猜的时间。

5. 让应用越用越顺：数据回流与迭代节奏

5.1 该埋哪些点，别埋一堆用不上的

零代码平台一般自带日志，但默认埋点往往不够用。我实际加了这么几类，都不需要写代码，在流程节点上勾选就行：

未识别语句全量留档。这是最有价值的数据，每周看一次，能直接告诉你用户到底在说什么、你的意图地图缺了哪块。我上线第一个月从这里面发现了一个完全没设计过的意图——用户反复说"我还有什么事没做"，本质是查询待办的另一种说法，但当时的语料没覆盖。

澄清轮次统计。每个会话记录它触发了几次澄清。超过两次的会话要单独抽样听，这些是最典型的体验断点。

中途放弃率。用户说了第一句之后再也没有第二句，就算放弃。这个指标比识别率更能反映真实体验，因为它包含了"识别对了但回复太慢""回复了但听不清"等各种隐性失败。

打断频率。用户主动打断播报的次数，如果某个场景下打断率特别高，说明那里的播报内容太啰嗦或者不相关。

埋点不用贪多，这四个维度足够支撑大部分迭代决策。数据量小的时候（比如日活不到一百），别做复杂的漏斗分析，直接抽二十条会话录音人工听，比任何报表都直观。

5.2 迭代节奏：先修体验，再扩能力

上线之后最容易犯的错是急着加功能。我的建议是前两个月只做减法不做加法，把所有精力放在"现有六个意图的体验打磨"上。

具体节奏大概是这样的：第一周集中修阻断性问题，就是那种一出现用户就完全用不了的；第二到四周修高频问题，按出现频次排序，一次修三到五个；第五周开始做话术和语料的持续补充，每周把未识别语句里排名前二十的说法加进训练集，重新训练一次；第八周之后，如果放弃率降到 15% 以下，再考虑扩意图。

扩意图也有讲究，一次只加一个，加完观察两周。加太快会导致意图之间的边界变模糊，老意图的准确率反而下降。我吃过这个亏，一次性加了四个意图，结果原本很稳的"创建待办"准确率掉了七个点，回头查了半天才发现是新意图的语料和它重叠了。

心得：语音应用的迭代像调音，不是像搭积木。每动一处都要回头听听整体还准不准。

最后分享一个我自己用下来最有效的小技巧：每周找一个人，不给他任何提示，让他用这个应用完成一件真实的事，比如"让它提醒你晚上八点给家里打个电话"。你在旁边什么都不说，只记录他说的每一句话、每一次停顿、每一个皱眉。二十分钟的观察，胜过你看一周的报表。真实用户在真实场景下的那点犹豫和改口，是任何数据都还原不出来的东西。