文章目录
做饭时最麻烦的不是"不会做"，而是人在厨房里双手经常被占用：正在洗菜、切菜、打蛋、翻炒，很难频繁拿起手机去看菜谱。基于这个非常真实的使用场景，我在 Rokid 灵珠平台上开发了一个面向厨房新手的智能眼镜智能体《厨房教练》。
这个智能体的重点，不是让大模型自由生成菜谱，而是围绕菜谱知识库做稳定的分步引导。用户说出"我要做什么菜、几人份、有什么口味偏好"之后，智能体会优先从知识库菜单中召回对应菜谱，再按照知识库里的步骤一步一步带用户完成做菜过程。
一、为什么我选择做《厨房教练》
在选题阶段，我优先避开了智能眼镜已经具备或高度重合的能力方向，例如实时翻译、提词器、拍照识物、导航、直播、支付，以及纯 AI 问答。因为这类方向要么已有成熟能力，要么很难体现智能体在真实生活场景中的差异化价值。
厨房场景恰好相反。做饭是一个非常适合智能眼镜发挥价值的场景：用户双手忙碌、注意力分散、操作节奏连续，语音输入和近眼显示天然比手机更顺手。所以我希望做的不是一个"什么都能答一点"的 AI 助手，而是一个能在厨房里真正陪用户把一道菜做完的流程型智能体。
二、《厨房教练》的核心其实是"菜谱知识库菜单"
这次作品最核心的设计，不是开放式菜谱生成，而是"知识库菜单驱动"。
我给《厨房教练》建立了一套菜谱知识库菜单。当前首批知识库先收录了三道高频家常菜：番茄炒蛋、青椒土豆丝、可乐鸡翅。这样设计并不是因为智能体只能做三道菜，而是我希望先用三道典型菜，验证厨房场景下"知识召回 -> 分步指导 -> 边界控制"这条链路是否足够稳定。
也就是说，当前菜单范围是首批知识库的收录范围，而不是这个智能体未来的能力上限。只要后续继续向知识库补充新的菜谱内容，这个智能体支持的菜单范围就可以持续扩大。
这也是我这次作品真正想验证的重点：让智能体基于知识库菜单来回答做菜问题，而不是完全依赖模型临场生成。
三、知识库是怎么搭建的
为了让《厨房教练》在厨房场景里回答得更稳，我没有只靠 Prompt 去约束模型，而是把首批菜单做成了结构化的文本知识库。每一道菜都尽量按照统一格式组织，主要包括：
- 适用人数
- 预计总时长
- 食材
- 备菜方式
- 分步骤操作
- 替代建议
- 安全提醒
例如：
- 番茄炒蛋在知识库里固定为 12 分钟
- 青椒土豆丝在知识库里固定为 15 分钟
- 可乐鸡翅在知识库里固定为 25 分钟
除了时长，我还把每道菜拆成了明确的步骤序列。这样用户在做菜过程中继续追问"下一步""重复一下""我做到哪一步了""没有这个食材怎么办"时，智能体就能优先依据知识库里的当前菜谱内容来回答，而不是自由发挥。
所以从产品实现角度看，《厨房教练》的核心能力其实就是：围绕知识库菜单进行召回，再把召回到的菜谱内容转化成适合智能眼镜播报和显示的短步骤提示。
下面是我在灵珠平台里搭建的菜谱知识库页面：
四、为什么要做"边界控制"
在厨房场景里，我认为"边界控制"比"看起来什么都能答"更重要。
如果用户问的是知识库菜单内的菜，例如番茄炒蛋、青椒土豆丝、可乐鸡翅，那么《厨房教练》就按知识库中的步骤、时长、替代建议和提醒来稳定回复。
如果用户问的是当前知识库菜单外的菜，例如鱼香肉丝，那么智能体不会现场乱编一套完整菜谱，而是会明确告诉用户：当前版本先稳定支持知识库里已经收录的菜单，并推荐最接近的一道菜。
这样做不是为了"拒绝用户"，而是为了保证厨房场景中的可执行性。因为用户是真正在下厨，模型如果临场生成一套不稳定、不完整或者前后矛盾的菜谱，会直接影响实际体验。相比之下，先围绕已收录菜单做稳定反馈，再逐步扩充知识库，会更适合这个场景。
所以文章里提到的边界测试，本质上是在验证一件事：这个智能体是否真的围绕知识库菜单工作，是否能够在知识库范围内稳定回答，在知识库范围外保持清晰边界，而不是随意乱答。
五、基于灵珠平台的实现方式
这次开发我主要依赖了 Rokid 灵珠平台的智能体配置能力和文本知识库能力，没有引入复杂的外部服务。整体链路可以概括为：
用户输入做菜需求 -> 智能体识别当前菜名与意图 -> 触发知识库召回 -> 命中对应菜单 -> 按知识库内容分步骤回复
在智能体基础配置方面，我完成了名称、图标、功能介绍、开场白和预置问题等设置，确保用户第一次进入就知道怎么使用。
下面是《厨房教练》在 Rokid Glasses 真机端的开场白显示效果：
下面是《厨房教练》在灵珠平台的智能体配置页面：
在人设与回复逻辑里，我重点强化了知识库调用规则：只要用户提到做菜、步骤追问、食材替代、时长、火候等内容，就优先调用知识库；一旦知识命中，就优先依据知识库内容回答，不随意改写数字、步骤和食材；如果没有命中，就不要输出完整新菜谱，而是明确说明当前知识库菜单范围。
这一步非常关键。它让《厨房教练》从"能回答做菜问题"，变成了"围绕知识库菜单稳定回答做菜问题"。
下面是我在人设与回复逻辑里重点配置的规则截图：
六、调试过程中我重点验证了什么
开发过程中，我重点做了三类验证。
第一类是主流程验证。我分别测试了"我要做番茄炒蛋，两人份，少油""我要做青椒土豆丝，两人份""我要做可乐鸡翅，两人份"，看智能体是否能正确命中知识库菜单，并从第 1 步开始稳定引导。
下面是知识库命中后，根据人数和口味偏好生成首步指导的实际效果：
第二类是步骤连续性验证。我会继续追问"下一步""重复一下""没有这个食材怎么办"，检查它是否能围绕当前知识库菜谱持续推进，而不是跳出当前流程。
继续追问"下一步"时，智能体会沿着当前菜谱流程往下走：
第三类是边界验证。我专门输入知识库菜单外的菜名，例如"我要做鱼香肉丝"，观察它会不会乱编。最终结果符合预期：它会明确说明当前版本先稳定支持知识库中已经收录的菜单，并推荐相近菜，而不是现场自由生成。
下面是知识库外菜品的边界测试截图（鱼香肉丝、油麦菜等场景）：
另外，我也通过知识库命中情况来判断智能体是否真正走了知识召回链路。多轮测试后，知识库命中次数持续增加，这说明智能体并不是只靠模型记忆在回答，而是真的在围绕知识库菜单工作。
七、这个智能体后续怎么扩展
这次作品当前首批只收录了三道菜，但这并不意味着《厨房教练》的菜单范围会一直停留在三道菜。
相反，它的扩展方式非常清晰：继续丰富知识库菜单。
每新增一道菜，只需要继续补充对应的适用人数、总时长、食材、备菜方式、步骤、替代建议和安全提醒，智能体就可以把新的菜加入支持范围。也就是说，这个智能体的扩展，本质上就是知识库菜单的持续扩充。
从这个角度看，《厨房教练》不是一个"固定只会三道菜"的智能体，而是一个已经验证了知识库驱动逻辑、后续可以不断扩展菜单范围的厨房智能体。
八、总结
通过这次开发，我更加明确地感受到：智能眼镜智能体的价值，不一定来自能力堆叠，而更来自场景聚焦与边界清晰。
《厨房教练》这次验证的重点，不只是"做了一个厨房助手"，而是验证了一种更适合厨房场景的开发方式：以菜谱知识库菜单为核心，让智能体在知识库范围内稳定分步引导，在知识库范围外保持清晰边界，并通过持续丰富知识库来不断扩展菜单能力。
对我来说，这也是这次作品最有价值的部分。它证明了智能眼镜场景下，知识库驱动、边界清晰、可持续扩菜单的智能体开发方式，是可以真正落地并持续演进的。