Rokid Glasses AIUI开发实战：从零搭建“今天吃什么”语音助手

1. 从一副眼镜说起：为什么要在 Rokid Glasses 上折腾 AIUI

第一次拿到 Rokid Glasses 的时候，我脑子里冒出来的第一个念头其实特别朴素——这玩意儿能不能帮我决定中午吃什么。别笑，这大概是每个打工人每天都要面对的灵魂拷问。而“今天吃什么”这个看似无聊的需求，恰好是检验一套 AIUI 开发流程是否跑得通的最佳试金石：它需要语音输入、需要调用大模型做决策、需要把结果以合适的方式呈现在眼镜上，还要考虑交互的自然度。麻雀虽小，五脏俱全。

Rokid Glasses 是 Rokid 推出的一款 AR 智能眼镜产品，它把显示、语音、传感器、算力整合在一副看起来还算正常的眼镜里。而 AIUI 是 Rokid 为这类设备打造的一套智能交互框架，核心思路是让开发者用自然语言和少量配置就能定义一套完整的语音交互流程，而不是像传统开发那样一行行写状态机。AIUI Studio 则是配套的可视化开发工具，你可以把它理解成一个专门为眼镜端交互设计的低代码工作台。

这套东西解决的核心问题是：把“想法”到“能跑的原型”之间的距离压缩到极致。以前你想在智能硬件上做一个语音助手，得先搭环境、写唤醒词逻辑、接语音识别、接大模型、处理多轮对话、再做 UI 渲染，一套下来没个三五天根本跑不起来。而 AIUI 的思路是，你只需要描述清楚“用户说什么、你回什么、什么时候触发什么动作”，剩下的交给框架。

这篇内容适合谁看？如果你是对 AR 眼镜开发感兴趣但完全没接触过 AIUI 的新手，或者你手上有 Rokid Glasses 想试试能不能自己搞点小工具，再或者你是个产品经理/设计师想快速验证一个语音交互 idea，那这篇从零到一的实操记录应该能帮你省下不少查文档和踩坑的时间。我会用“今天吃什么”这个完整案例，把 AIUI Studio 的安装、项目创建、意图配置、大模型接入、真机调试整个链路走一遍，中间该注意的地方、我踩过的坑、以及一些文档里不会写的经验，都会一并交代。

2. 动手之前的准备：环境、账号与核心概念对齐

2.1 你需要准备的东西清单

在正式开始之前，先把该装的东西装好、该注册的账号注册好，不然做到一半发现缺东西会很打断节奏。下面是我实际用到的完整清单：

• Rokid Glasses 设备一台：这是最终运行载体，没有真机的话可以用 AIUI Studio 自带的模拟器先跑逻辑，但语音唤醒和显示效果还是真机最准。
• AIUI Studio 开发工具：从 Rokid 开发者官网下载，支持 Windows 和 macOS，我用的 macOS 版本，整体比较稳定。
• Rokid 开发者账号：用来登录 AIUI Studio 和绑定设备，注册流程很简单，邮箱验证即可。
• 一台电脑：建议内存 16G 以上，因为 AIUI Studio 本身加上模拟器和浏览器调试窗口，8G 的机器会有点吃力。
• 稳定的网络环境：因为涉及到云端大模型调用和资源下载，网络不稳定会导致项目同步失败。
• 手机一部：用于扫码绑定眼镜设备和查看调试日志，Android 和 iOS 都支持。

注意：AIUI Studio 的版本更新比较频繁，建议下载时直接选最新稳定版，不要用网上教程里提到的旧版本，否则界面和 API 可能对不上。

2.2 AIUI 的核心概念：意图、技能与卡片

在打开 AIUI Studio 之前，有几个概念必须先搞清楚，不然你会在各种配置面板里迷路。我用最直白的话来解释：

意图（Intent）就是“用户想干什么”。比如用户说“今天吃什么”，他的意图就是“获取午餐建议”。在 AIUI 里，你需要定义一个意图，并给它配上一些“说法”（也就是用户可能说的各种句子），框架会根据这些说法去匹配用户的语音输入。

技能（Skill）是意图的容器。一个技能可以包含多个意图，比如你可以建一个“午餐助手”技能，里面放“获取午餐建议”“查看附近餐厅”“记录饮食偏好”三个意图。技能是项目的基本组织单元。

卡片（Card）是眼镜上显示的内容模板。AIUI 提供了一套预置的卡片样式，比如纯文本卡片、图文卡片、列表卡片等。你不需要自己写渲染代码，只需要把数据填进卡片的槽位里，框架会自动处理显示。

大模型接入（LLM Integration）是 AIUI 比较新的能力，允许你把意图的处理逻辑交给大模型来做。比如用户说“今天吃什么”，你可以直接把这句话丢给大模型，让它生成一个建议，而不是自己写一堆 if-else 去匹配菜名。

把这四个概念串起来就是：用户说话 → AIUI 匹配到某个技能下的某个意图 → 意图的处理逻辑（可能是本地脚本，也可能是大模型调用）生成结果 → 结果填充到卡片 → 眼镜显示。

2.3 关于 Vibe Coding 的一点个人理解

最近 Vibe Coding 这个词挺火，大意是指用自然语言描述需求、让 AI 帮你生成代码的一种开发方式。在 AIUI 开发里，这个思路其实特别契合，因为 AIUI 本身就是高度声明式的——你描述“要什么”，而不是“怎么做”。我在做“今天吃什么”这个项目时，很多配置项就是直接写一句自然语言描述，比如“当用户询问午餐建议时，随机从以下菜品列表中选一个并附上一句推荐语”，AIUI 的智能配置面板能直接理解并生成对应的处理逻辑。

但这里要泼一盆冷水：Vibe Coding 不是万能的。对于简单的逻辑，它确实能省很多事；但一旦涉及到复杂的条件分支、外部 API 调用、数据持久化，你还是得老老实实写代码或者做详细的手动配置。我的建议是，把 Vibe Coding 当成一个加速器，而不是替代品。

3. 从零搭建“今天吃什么”AIUI 项目

3.1 创建项目与基础配置

打开 AIUI Studio 后，第一步是新建项目。点击“创建项目”，填写项目名称，我直接用了“WhatToEatToday”，项目类型选“Rokid Glasses”，模板选“空白项目”。这里不建议选那些预置模板，因为模板里往往带了很多你用不上的配置，反而会增加理解成本。

项目创建完成后，你会看到左侧的项目结构树，大概长这样：

WhatToEatToday/ ├── skills/ # 技能目录 ├── cards/ # 卡片模板目录 ├── resources/ # 资源文件（图片、音频等） ├── config.json # 项目全局配置 └── main.aiui # 主入口文件

接下来要做的是绑定设备。在“设备管理”面板里点击“添加设备”，然后用手机上的 Rokid App 扫描弹出的二维码，按照提示完成绑定。绑定成功后，设备状态会显示为“在线”，这时候你就可以把项目直接推送到眼镜上运行了。

实操心得：绑定设备时，确保眼镜和电脑连的是同一个 WiFi 网络，否则推送会失败。我第一次做的时候电脑连的是 5G 频段、眼镜连的是 2.4G 频段，结果死活推不上去，排查了半天才发现是网络隔离的问题。

3.2 定义“今天吃什么”技能与意图

在项目结构树里右键点击skills目录，选择“新建技能”，命名为LunchHelper。然后在LunchHelper下新建一个意图，命名为GetLunchSuggestion。

意图创建好后，需要配置“用户说法”。这是 AIUI 匹配用户语音的关键。我添加了以下几种说法：

• “今天吃什么”
• “中午吃啥”
• “给我推荐个午饭”
• “午饭吃什么好”
• “帮我决定午餐”

这里有个技巧：说法要尽量覆盖用户可能的各种表达方式，但也不要无脑堆砌。AIUI 的匹配是基于语义相似度的，所以意思相近的句子加个两三条就够了，加太多反而可能引入噪声。我实测下来，上面这五条已经能覆盖绝大多数情况了。

接下来配置意图的“槽位”。槽位是指从用户话语中提取的关键信息。对于“今天吃什么”这个场景，其实不需要提取额外信息，因为用户的需求就是“给我一个建议”。但如果你想做得更细，可以加一个“口味偏好”槽位，让用户说“今天吃什么辣的”时能识别出“辣的”这个偏好。我这里为了保持简单，先不加槽位。

3.3 接入大模型生成午餐建议

这是整个项目最核心的部分。AIUI 提供了两种方式来处理意图：一种是本地脚本，一种是调用大模型。本地脚本适合逻辑固定的场景，比如“从预设列表里随机选一个”；大模型适合需要生成自然语言回复的场景，比如“根据用户的口味偏好和当前时间生成一句有温度的推荐语”。

我两种都试了，最后选的是混合方案：用本地脚本维护一个菜品列表，然后调用大模型基于选中的菜品生成推荐语。这样既有可控性，又有自然度。

具体操作是在意图的“处理逻辑”面板里，先添加一个“本地脚本”节点，写入以下逻辑：

// 菜品列表 const dishes = [ "兰州拉面", "黄焖鸡米饭", "沙县小吃", "麻辣烫", "盖浇饭", "螺蛳粉", "寿司", "汉堡", "沙拉", "炒饭" ]; // 随机选一个 const picked = dishes[Math.floor(Math.random() * dishes.length)]; // 输出到上下文，供后续节点使用 context.set("pickedDish", picked);

然后在后面接一个“大模型调用”节点，配置如下：

• 模型选择：选默认的通用对话模型即可，不需要选太贵的。
• 提示词模板：用户问你今天吃什么，你推荐了${pickedDish}。请用一句轻松幽默的话把这道菜推荐给用户，不超过30个字。
• 输出变量：recommendation

最后接一个“卡片渲染”节点，把recommendation的内容填充到文本卡片里。

注意事项：大模型调用是有延迟的，实测下来大概 1-2 秒。如果你的场景对响应速度要求很高，建议把提示词写短一点，或者直接用本地脚本生成固定话术。另外，大模型调用是按量计费的，调试阶段建议设置一个每日调用上限，免得调试时反复触发把额度用光。

3.4 设计眼镜端的显示卡片

卡片的设计直接影响到用户体验。Rokid Glasses 的显示区域有限，所以信息要极度精简。我设计了两张卡片：一张是“思考中”的过渡卡片，一张是“结果”卡片。

过渡卡片很简单，就一行字：“让我想想...”。这张卡片在用户说完话后立即显示，用来填补大模型调用的那 1-2 秒空白，让用户知道系统在干活。

结果卡片包含两部分：主标题是菜品名称，副标题是推荐语。字体大小用默认的就行，颜色用白色，背景用半透明黑色，这样在户外也能看清。

在 AIUI Studio 的卡片编辑器里，你可以直接拖拽组件来布局，也可以用 JSON 来定义。我习惯用 JSON，因为更可控：

{ "type": "text", "title": "${pickedDish}", "subtitle": "${recommendation}", "style": { "titleSize": 24, "subtitleSize": 16, "titleColor": "#FFFFFF", "subtitleColor": "#CCCCCC", "background": "rgba(0,0,0,0.7)" } }

实操心得：眼镜上的文字不要超过两行，超过两行用户就得转头才能看全，体验很差。如果推荐语太长，可以在大模型提示词里限制字数，或者在卡片渲染前做一个截断处理。

4. 真机调试与效果验证

4.1 推送项目到眼镜

项目配置完成后，点击工具栏上的“推送”按钮，AIUI Studio 会把项目打包并推送到已绑定的眼镜设备上。推送过程大概需要十几秒，取决于项目大小和网络速度。

推送成功后，眼镜上会显示一个启动提示。这时候你对着眼镜说“今天吃什么”，应该就能看到过渡卡片出现，然后 1-2 秒后结果卡片显示出来。

我第一次跑通的时候，看到眼镜上真的显示出“黄焖鸡米饭”和一句“今天就让黄焖鸡来拯救你的胃吧”，那种成就感还是挺足的。虽然是个很小的功能，但整个链路是完整的。

4.2 调试日志的查看方法

调试阶段最常用的功能是日志查看。AIUI Studio 提供了实时的日志面板，可以看到语音识别的结果、意图匹配的情况、脚本的执行输出、大模型调用的请求和响应。这些信息对于排查问题非常关键。

比如你发现用户说“中午吃啥”没有被正确匹配，就可以在日志里看到语音识别出来的文本是什么、匹配到了哪个意图、相似度分数是多少。如果分数很低，说明你的“用户说法”配置得不够好，需要补充或调整。

日志面板还支持过滤和搜索，调试复杂项目时很有用。我一般会开两个窗口，一个看日志，一个改配置，改完直接推送，形成快速迭代的循环。

4.3 实测效果与响应时间分析

经过几轮调试，最终的效果是这样的：

2-3 秒的总延迟在可接受范围内，但如果你追求更快的响应，可以把大模型调用去掉，直接用本地脚本生成固定话术，这样总延迟能压到 1 秒以内。代价就是推荐语会显得比较机械，每次都是“今天推荐你吃XXX”这种句式。

我个人的选择是保留大模型调用，因为那 1-2 秒的等待被过渡卡片填补了，用户感知上并不会觉得很久。而且推荐语的自然度提升是值得这点延迟的。

5. 踩坑记录与常见问题排查

5.1 意图匹配不准怎么办

这是新手最容易遇到的问题。用户说的句子明明意思很接近，但就是匹配不上。原因通常有两个：一是“用户说法”配置得太少或太偏，二是相似度阈值设得太高。

AIUI 默认的相似度阈值是 0.7，意思是用户说的话和配置的说法相似度达到 70% 才触发。如果你的说法配置得比较书面化，而用户说话比较口语化，就可能达不到阈值。解决办法是把阈值调到 0.6，同时补充一些口语化的说法。

但阈值也不能调太低，否则会误触发。我试过调到 0.5，结果用户说“今天天气怎么样”也会触发“今天吃什么”，这就很尴尬了。所以阈值调整要配合说法优化一起做，不能只调一个。

5.2 大模型调用失败的排查思路

大模型调用失败的原因比较多，我整理了一个排查顺序：

1. 检查网络连接：AIUI Studio 和眼镜设备都需要能访问外网，如果公司网络有防火墙限制，可能会失败。
2. 检查 API 额度：登录 Rokid 开发者后台，看看大模型调用额度是否用完。
3. 检查提示词格式：提示词模板里的变量引用语法是${变量名}，如果写错了会导致请求体格式错误。
4. 检查超时设置：默认超时是 5 秒，如果网络慢可能会超时，可以在配置里调到 10 秒。
5. 查看详细错误日志：日志面板里会显示具体的错误码和错误信息，根据错误码去查文档。

避坑技巧：调试大模型调用时，建议先在“测试”面板里单独测试提示词，确认能正常返回结果后，再接入到完整流程里。这样可以把问题隔离在最小范围内。

5.3 卡片显示异常的常见原因

卡片显示异常通常表现为：文字不显示、布局错乱、背景色不对。我遇到过的原因包括：

• 变量未正确传递：比如${pickedDish}在卡片渲染时是空的，说明前面的脚本没有正确设置这个变量。检查context.set的变量名和卡片里的引用名是否一致。
• 字体大小超出显示区域：眼镜的显示区域有限，如果标题字号设得太大，文字会被截断。建议标题不超过 28，副标题不超过 18。
• 背景透明度设置不当：在强光环境下，如果背景太透明，文字会看不清。建议背景透明度不低于 0.6。

5.4 常见问题速查表

6. 后续可以怎么玩：从“今天吃什么”扩展出去

这个项目虽然简单，但它是一个很好的起点。把“今天吃什么”跑通之后，你可以沿着几个方向继续扩展。

第一个方向是增加个性化。比如记录用户的历史选择，如果用户连续三天都选了面食，第四天就优先推荐米饭类。这需要在本地脚本里加一个简单的数据存储逻辑，AIUI 提供了storageAPI 可以做本地持久化。

第二个方向是接入外部数据。比如调用天气 API，如果今天下雨就推荐热汤类，如果天热就推荐凉菜。这需要在 AIUI 里配置 HTTP 请求节点，把天气数据拉进来作为大模型提示词的一部分。

第三个方向是多轮对话。现在用户说“今天吃什么”就直接出结果了，你可以改成先问“想吃辣的还是不辣的”，根据用户回答再推荐。这需要在意图里配置多轮交互流程，AIUI 的对话设计器支持拖拽式的流程编排。

第四个方向是语音反馈。现在结果只显示在眼镜上，你可以加上 TTS（语音合成），让眼镜直接把推荐语念出来。这样用户连看都不用看，更适合走路或骑车时使用。

我个人的体会是，AIUI 这套框架的上手门槛确实低，但天花板也不低。简单场景可能半小时就能跑通，但要做得好、做得自然，还是需要花时间打磨细节。尤其是提示词的设计、卡片的布局、意图的覆盖度，这些都需要反复调试和实际使用才能找到最优解。

最后分享一个小技巧：调试阶段可以先把大模型调用关掉，用本地脚本返回固定结果，把整个链路跑通后再接入大模型。这样可以把问题分阶段隔离，避免一开始就面对太多变量。等链路稳定了，再逐步替换成真实的大模型调用，整个过程会顺畅很多。