戴上眼镜问一句“附近有什么吃的”？我用Rokid灵珠AI平台做了一个美食侦探智能体

引言

2025年被称为AI眼镜的元年，这一年我们见证了太多从概念到落地的产品。当大家还在讨论AI眼镜到底能不能取代手机时，Rokid已经带着灵珠AI平台和Rokid Glasses，把“下一代移动计算平台”的愿景实实在在地推到了开发者面前。作为一名常年关注AR/VR的开发者，我一直在想：AI眼镜上到底什么样的应用才是有价值的？

春节前，Rokid开发者社区推出了“马上分享”有奖征文活动，要求围绕春节场景或日常生活，基于灵珠AI平台或SDK开发应用。恰好那几天我和朋友聚会，大家经常为“吃什么”纠结，掏出手机翻半天大众点评。我突然想到：如果戴着眼镜，直接问一句“附近有什么好吃的”，就能听到语音推荐，那该多方便！ 这不就是AI眼镜“解放双手”的典型场景吗？

于是，我决定开发一个“附近美食侦探”智能体，全程使用Rokid灵珠AI平台的可视化工作流，无需编写代码，15分钟就能完成配置——这是平台宣传的口号，但我实际做下来，确实如此，而且效果超出预期。下面，我将详细分享整个开发过程、技术方案和最终的应用效果，希望能给其他开发者一些启发。

一、为什么选择“美食侦探”这个场景？

在动工之前，我先梳理了用户需求和使用场景：

• 痛点：聚餐时选择困难，掏出手机查餐厅体验割裂，眼镜端需要更自然的交互。
• 高频场景：逛街、旅游、下班路上，随口一问就能得到推荐。
• 语音交互特点：信息要简洁、重点突出，不适合长篇大论。
• 技术可行性：初期可以不接入真实LBS API，用预置数据模拟周边餐厅，快速验证体验。

基于这些考虑，我确定了智能体的核心功能：

1. 附近餐厅查询：默认推荐综合评分最高的几家。
2. 按口味筛选：支持川菜、粤菜、日料等常见分类。
3. 餐厅详情查看：对感兴趣的那家进一步了解。
4. 换一批：不满意当前推荐可以刷新。

这些功能完全可以在灵珠AI平台通过工作流、知识库和简单的逻辑节点实现，无需后端开发。这正是我选择灵珠平台的原因——低代码甚至零代码，让想法快速落地。

二、整体技术方案：灵珠AI平台的工作流之美

Rokid灵珠AI平台（rizon.rokid.com）为开发者提供了从智能体创建、知识库管理、工作流编排到插件扩展的一站式工具。我的技术方案完全基于平台能力：

• 智能体角色：定义人设、回复风格、触发关键词。
• 知识库：预置餐厅数据，支持按类别筛选。
• 工作流：串联意图提取、条件判断、知识库检索、结果拼接等步骤，实现完整对话逻辑。
• 插件（可选） ：模拟定位和距离计算，让推荐更真实。
• 测试与发布：平台内置调试工具，支持直接推送到Rokid Glasses体验。

整个方案没有写一行代码，全部通过可视化界面配置完成。但为了达到良好的交互效果，我在逻辑设计和数据组织上花了不少心思。下面一步步拆解。

三、详细开发步骤

3.1 创建智能体：定义“美食侦探”的身份

登录灵珠AI平台后，点击“创建智能体”，首先填写基本信息：

• 智能体名称：附近美食侦探（朗朗上口，功能一目了然）
• 类别：生活服务·美食推荐
• 功能介绍：当你不知道吃什么时，只需问一句“附近有什么好吃的”，即可快速推荐周边餐厅，包括餐厅名称、距离、人均价格和招牌菜，支持按口味筛选（川菜/粤菜/日料等），做你的随行美食向导。

接下来是关键的人设与回复逻辑配置。这里我输入了一段详细的提示词，告诉大模型应该如何表现：

# 角色
你是用户的“附近美食侦探”，一个熟悉周边餐厅、幽默风趣的美食向导。你的目标是帮用户快速找到想吃的餐厅，推荐精准、回复简洁。

# 核心能力与触发规则

## 1. 附近餐厅查询（核心功能）
- **触发关键词**：附近有什么吃的、推荐餐厅、饿了、美食、吃饭、附近好吃的、附近有什么
- **处理逻辑**：
  1. 用户提问后，先判断是否指定了口味（如“川菜”“辣的”“清淡”）
  2. 若无指定，默认推荐综合评分最高的3家餐厅
  3. 若用户说“换一批”，推荐另外3家
  4. 若用户说“第一个”或具体餐厅名，提供该餐厅的详细信息和一句幽默点评

## 2. 餐厅详情查询
- **触发关键词**：第一个、这家怎么样、具体信息、有什么菜
- **处理逻辑**：提供用户选中餐厅的详细信息（招牌菜、人均、距离、一句话推荐理由）

## 3. 口味筛选
- **触发关键词**：川菜、辣的、粤菜、清淡、日料、火锅、烧烤
- **处理逻辑**：按用户指定的口味，从餐厅库中筛选对应类别进行推荐

# 回复风格
- 语气活泼，偶尔带点幽默（如“这家店连隔壁的猫都馋哭了”）
- 每条推荐控制在3句话以内，适合眼镜端语音播报
- 信息顺序：餐厅名 → 距离 → 人均 → 招牌菜 → 一句趣味点评

这段配置相当于给智能体赋予了“灵魂”。后续工作流会接管具体的逻辑执行，但人设决定了回复的基调和风格。我特意加入了幽默元素，让语音播报更有趣，避免机器感。

3.2 准备知识库：模拟餐厅数据

没有真实API，就用预置数据。在平台左侧“资源”->“知识库”中，我创建了一个名为“周边餐厅库”的知识库，并以表格形式录入了6家示例餐厅。这些数据涵盖了不同菜系、价格和距离，足够模拟真实场景。

餐厅名称	类别	距离(km)	人均(元)	招牌菜	趣味点评	区域
川味江湖	川菜	0.3	68	水煮鱼、辣子鸡	辣得你直呼过瘾，米饭都能多吃两碗	商圈A
粤点轩	粤菜	0.5	85	虾饺、烧鹅	一口下去仿佛到了广州，排队也值	商圈A
松叶日本料理	日料	0.8	120	三文鱼刺身、鳗鱼饭	老板是日本人，味道相当地道	商圈A
老北京涮肉	火锅	0.4	95	手切羊肉、麻酱	铜锅炭火，冬天不吃这家算白过	商圈A
必胜客	西餐	0.2	55	超级至尊披萨	不知道吃啥时选它准没错	商圈A
西贝莜面村	西北菜	0.6	75	莜面、羊肉串	闭眼点都不会踩雷的西北菜	商圈A

关键设置：在知识库字段配置中，我将“类别”设为筛选字段，“区域”设为筛选字段。这样在工作流中就可以根据用户指定的口味（如“川菜”）快速过滤数据。

数据量虽小，但足以覆盖常见查询。如果需要更丰富，可以再添加一些餐厅，但初期6家足够测试。

3.3 设计工作流：可视化编排对话逻辑

工作流是智能体的“大脑”。我创建了一个名为“餐厅推荐工作流”的可视化流程，包含7个节点，覆盖从接收用户输入到输出结果的全过程。

节点1：开始节点

• 配置：接收用户输入的语音文本，作为整个工作流的入参。不需要额外设置。

节点2：意图提取节点

• 节点类型：大模型节点
• 配置：使用平台内置的大模型，提取用户意图的关键信息。我给出的指令是：

从用户输入中提取以下信息：是否指定了口味（如“川菜”“辣的”“清淡”），返回口味名称；是否要求“换一批”；是否询问具体餐厅（如“第一个”或餐厅名）。如果都没有，则默认为附近餐厅查询。

• 输出：生成一个JSON对象，包含taste、is_change、specific_restaurant等字段。这个节点非常强大，无需自己写NLU，大模型直接理解自然语言。

节点3：条件判断节点

• 配置：根据节点2的输出，判断走哪个分支：

  • 如果specific_restaurant不为空，走“餐厅详情”分支（节点6）
  • 如果is_change为true，走“换一批”分支（节点5）
  • 否则走“附近餐厅查询”分支（节点4）

这个分支结构清晰，覆盖了所有用户意图。

节点4：知识库检索节点（附近餐厅查询）

• 配置：选择“周边餐厅库”知识库。
• 筛选条件：如果节点2提取了taste（例如“川菜”），则添加筛选条件：类别等于taste；否则不筛选，默认返回所有餐厅。
• 排序与数量：平台知识库支持按字段排序，我设置默认按综合评分降序（虽然数据里没评分字段，但可以预留）。返回数量设为6，因为后续“换一批”需要分页。
• 输出：返回匹配的餐厅列表（最多6条）。

节点5：变量操作节点（换一批逻辑）

• 配置：这里用到了平台的工作流变量。我在工作流开始处定义了一个全局变量batch_index，初始为0。每次执行“换一批”时，将batch_index加1，然后从知识库中取第batch_index*3到batch_index*3+2条数据（即每批3家）。这个节点是一个脚本节点，用简单的表达式操作变量，不需要写复杂代码。

节点6：信息拼接节点

• 节点类型：文本拼接/大模型生成
• 配置：将检索到的餐厅列表（最多3家）按指定格式拼接成自然语言。我使用了大模型提示词：

根据以下餐厅信息，生成一段活泼的推荐语，包含餐厅名、距离、人均、招牌菜和一句趣味点评。每段推荐不超过3句话。

• 如果是单家餐厅详情（来自“餐厅详情”分支），则生成详细介绍。
• 如果是多餐厅推荐，则逐家生成，并用“第一”、“第二”区分。

节点7：结束节点

• 配置：将节点6生成的文本作为最终输出，返回给智能体播报。

整个工作流逻辑清晰，可视化拖拽即可完成。让我印象最深的是大模型节点和变量操作的灵活性，几乎可以满足所有自定义需求。

3.5 智能体与工作流绑定

在智能体编辑界面的“能力配置”模块，我点击“添加工作流”，选择了刚才创建的“餐厅推荐工作流”。然后设置了触发关键词，尽量覆盖用户可能说的各种问法：

附近有什么吃的、推荐餐厅、饿了、美食、吃饭、川菜、辣的、粤菜、日料、火锅、第一个、换一批……

这些关键词会触发工作流执行，否则智能体会用默认的大模型回复（但因为我绑定了工作流，大多数美食相关的问题都会进入工作流）。

3.6 开场白配置

一个友好的开场白能降低用户的使用门槛。我这样写：

你好呀！我是你的附近美食侦探～ 🕵️♂️

不知道吃啥的时候，问我准没错！

我可以帮你：

• 🍜 推荐附近餐厅（直接说“附近有什么吃的”）
• 🌶️ 按口味筛选（比如“川菜”“清淡的”“日料”）
• 🍣 查看餐厅详情（说“第一个”或直接问店名）
• 想试试哪家？随时问我～

配上表情符号，在眼镜端显示时会更生动。

3.7 测试与发布

平台提供了两种测试方式：

• 工作流调试：在工作流编辑界面点击“试运行”，输入测试文本，查看每个节点的输出。我测试了“附近有什么吃的”、“推荐川菜”、“第一个”、“换一批”等多种情况，确保逻辑正确。
• 智能体调试：在智能体编辑界面右侧的对话窗口直接输入语音文本，模拟真实对话。这里我发现了几个问题，比如“辣的”应该映射到“川菜”，但大模型有时会提取成“辣味”，导致知识库过滤失败。于是我在意图提取节点加了提示：“如果用户说辣的，提取为川菜”。调整后就好了。

一切顺利后，点击“发布”，权限设为“仅自己可见”（因为是测试）。然后在Rokid AI App的“开发者->智能体调试”中找到“附近美食侦探”，就可以在眼镜上体验了。

四、关键技术点解析

4.1 意图提取的大模型提示工程

在节点2中，我使用了平台的大模型进行意图提取。这比传统的关键词匹配更智能，比如用户说“想吃点辣的”，大模型能理解“辣的”是指口味，并提取为“川菜”（通过提示词映射）。但提示词需要精心设计，避免歧义。我迭代了几次：

• 第一版：只提取口味关键词，结果“辣的”没匹配上。
• 第二版：加入“辣的→川菜”的映射规则。
• 第三版：增加“如果用户说具体菜名，直接使用”。

现在大模型对自然语言的理解已经非常强大，只要提示词给得足够清晰，就能得到准确的结构化数据。

4.2 分页与“换一批”的实现

“换一批”是用户高频需求。我的方案是：

• 知识库一次返回6家（足够两批）。
• 全局变量batch_index记录当前批次，初始0。
• 当用户说“换一批”时，batch_index++，然后从知识库结果中取[batch_index*3, batch_index*3+2]的三家。
• 如果batch_index超出范围，则重置为0或提示“没有更多了”。

这个逻辑在节点5中用变量操作实现。平台支持在变量中存储列表，并对列表切片，非常方便。

4.3 知识库的筛选字段

将“类别”设为筛选字段，使得在知识库检索节点可以直接用类别 = taste过滤。如果没有设为筛选字段，则需要在大模型节点后自己写脚本过滤，增加了复杂度。所以提前规划知识库结构很重要。

4.4 语音播报的简洁性

眼镜端语音播报不宜过长。我强制每条推荐不超过三句话，并且按照“餐厅名→距离→人均→招牌菜→点评”的顺序，用户能快速获取关键信息。趣味点评是点睛之笔，让播报更有温度。

五、实际体验与对话示例

完成后，我实际调试测试，以下是几个典型对话：

用户：“附近有什么吃的？”

眼镜播报：

“为您推荐三家餐厅：

第一，川味江湖，距离您300米，人均68元，招牌菜水煮鱼。这家店辣得你直呼过瘾，米饭都能多吃两碗！

第二，粤点轩，距离您500米，人均85元，招牌菜虾饺烧鹅。一口下去仿佛到了广州，排队也值！

第三，松叶日本料理，距离您800米，人均120元，招牌菜三文鱼刺身。老板是日本人，味道相当地道！”

用户：“有没有川菜？”

眼镜播报：

“为您推荐川菜馆：川味江湖，距离您300米，人均68元，招牌菜水煮鱼、辣子鸡。辣得你直呼过瘾，米饭都能多吃两碗！”

用户：“第一个怎么样？”

眼镜播报：

“川味江湖，川菜馆，距离您300米，人均68元。招牌菜有水煮鱼和辣子鸡。这家店连隔壁的猫都馋哭了，辣味十足，适合无辣不欢的你！”

用户：“换一批”

眼镜播报：

“再给您推荐另外三家：

老北京涮肉，距离您400米，人均95元，招牌手切羊肉。铜锅炭火，冬天不吃这家算白过！

必胜客，距离您200米，人均55元，招牌超级至尊披萨。不知道吃啥时选它准没错！

西贝莜面村，距离您600米，人均75元，招牌莜面羊肉串。闭眼点都不会踩雷的西北菜！”

整个过程流畅自然，语音播报清晰，完全没有等待感。朋友试了都说：“这眼镜要是上市了，我吃饭就不用纠结了！”

六、开发心得与避坑指南

6.1 平台优势：零代码也能玩出花

以前开发一个语音助手需要写后端、训练NLU、对接地图API，至少一周。而灵珠AI平台让我在半天内就完成了从构思到可运行的应用，而且完全可视化。工作流节点丰富，大模型能力强大，知识库管理直观，非常适合快速验证创意。

6.2 遇到的坑与解决办法

• 坑1：意图提取不准确。一开始我让大模型自由提取，结果“辣的”有时变成“辣味”，导致知识库过滤失败。后来在提示词中明确“如果用户说辣的、辣的菜、辣的口味，提取为川菜”，问题解决。
• 坑2：换一批的索引越界。当用户多次换一批时，批次索引可能超过数据总量。我在变量操作中加了判断，如果索引超出，则重置为0并提示“没有更多了，重新为您推荐”。
• 坑3：知识库筛选字段未设置。第一次忘了将“类别”设为筛选字段，结果检索节点无法按口味过滤，只能返回所有数据。后来重新编辑知识库，勾选了筛选字段，问题解决。

6.3 数据预置的局限性

目前用的是静态数据，只能模拟固定位置的餐厅。真实场景需要接入地图API获取实时数据。不过灵珠平台支持自定义插件，可以轻松对接高德或百度地图。下一步我打算开发一个“真实定位插件”和“地图API插件”，让这个智能体真正落地。

七、未来展望与扩展思路

这个美食侦探智能体只是一个起点。基于灵珠AI平台，我可以轻松扩展更多功能：

• 接入真实LBS：通过插件获取用户实时位置，调用地图API搜索周边餐厅。

• 支持更多筛选：如价格区间、评分、距离远近。

• 个性化推荐：结合用户历史偏好，用大模型生成定制推荐。

• 多轮对话：目前只支持单轮查询，可以增加上下文记忆，比如用户说“再推荐一家便宜的”。

• 视觉增强：Rokid Glasses有摄像头，未来可以识别菜单、菜品，甚至AR叠加餐厅信息。

八、总结：AI眼镜应用开发的黄金时代

通过这次开发，我深刻体会到AI眼镜+低代码平台的巨大潜力。 “附近美食侦探”虽然简单，但它解决了真实痛点，而且完全可以通过语音交互在眼镜端无缝使用。 这正是AI眼镜区别于手机的核心价值——信息随手可得，无需掏出设备。

2026年是马年，也是AI眼镜从“元年”走向“普及”的关键一年。Rokid灵珠AI平台大大降低了开发门槛，让更多像我这样的开发者能快速将想法变为现实。如果你也有创意，不妨马上动手，戴上眼镜，用语音改变生活。

最后，感谢Rokid开发者社区的活动激励，让我完成了这个小作品。希望我的分享能给大家带来启发，一起“马上分享”，解锁更多AI+AR新应用！