智能眼镜助手：人脸识别秒记日程

项目简介本地服务 github 链接d32gang-steel/Recallens设计初衷在日常办公、商务社交及高频人际交往场景中人们常常面临一个普遍的痛点——短时记忆过载。在与人接触的瞬间大脑往往难以即时、准确地检索出眼前人的背景信息、历史交集以及与其相关的待办事项例如“我和他约好今天要确认什么”或“上次见他时留下了什么未完成的工作”目前常见的的智能眼镜方案或视觉分析技术往往仅停留在单纯的身份识别阶段未能将身份与用户的工作流打通导致识别出的静态信息无法直接转化为即时信息提示未能充分利用了智能眼镜的实时信息辅助能力。为了解决这一痛点我们开发了 GPASS 智能眼镜人脸助理。该系统不仅能在第一视角帮用户快速“记住谁是谁”更重要的是建立起了“人脸”与“日程上下文”的即时关联。当用户面对某人时系统能自动检索并调阅出与其深度绑定的时间线和备忘录实现场景化、情境式的信息唤醒将用户从繁重的人际短时记忆压力中解放出来。技术文档功能简介本系统围绕眼镜“随身佩戴、第一视角”的硬件特性开发了以下五个高完备度的核心应用功能第一视角静默人脸建档当眼镜端捕获到未知面孔时系统会在后台静默完成人脸提取。根据当前已登记的面孔数量自动为其赋予类似于“新面孔_X”的临时标识并完成本地注册。这使得设备能够在零输入交互的前提下快速建立初步的人物索引。延时人镜协同主动唤醒针对眼镜在公共场合语音交互的社交瓶颈系统创新性地开发了延时主动交互机制。当眼镜捕获到新面孔后并不会在人际交往的敏感当下强迫用户说话而是将其暂存入后端的“单次读取销毁历史库”中。当用户回到私人空间、下一次重新进入眼镜对话时智能体会主动、温和地唤醒“刚才你见到了熟人需要我们添加日程吗” 实现了极具人文关怀的“延时主动陪伴”。多模态上下文日程调阅当眼镜再次比对并识别出已知联系人时系统会自动调取与之绑定的近期日程。接口会按照时间升序排序精简返回时间最近的前 3 条日程。大模型会配合语音合成TTS直接对佩戴者进行关键性日程提醒。云端 NLU 自动日程解析为了彻底解放双手用户可以直接对眼镜说出极其口语化的日程。例如“安排我们两个明天吃一顿中午饭。” 后端通过调用大模型 NLU 引擎会自动结合系统当前的基准时间精准计算出“明天”的具体日期并自动提取出对应人脸进行后台日程创建与自动绑定。双端协同 React 异步管理中心系统提供了一个 React Tailwind CSS 管理控制台。用户在闲暇时可以打开电脑将眼镜自动生成的“新面孔_1”重命名为真实姓名直接手动导入本地照片进行人脸特征录入或者对绑定人物的日程时间线进行高效率的增删整理。工作流设计1. 穿戴式无感注册与临时代号生成当眼镜端捕获到未知面孔时系统会自动在后台完成人脸特征提取。系统根据当前用户已登记的面孔数量自动为其赋予类似于“新面孔_X”的临时标识并完成本地注册。这使得设备能够在零输入交互的前提下快速建立初步的人物索引。2. 视觉触发的上下文日程检索当用户再次面对已登记的人物时眼镜端完成比对后智能体会自动作为中介向日程模块检索与该人绑定的近期规划例如会议、会谈要点、待办备忘并通过语音将这些信息即时反馈给佩戴者提供即时决策支持。3. 多终端异步管理中心系统提供了一个轻量且现代的 Web Dashboard供用户进行异步的数据纠偏和深度管理人脸档案转正用户可在网页端将眼镜自动生成的“新面孔_X”一键重命名为真实姓名如“合作方张总”更名后系统内的日程关联关系和眼镜端的语音识别结果将实时同步。本地辅助录入支持通过网页直接导入本地照片进行 AI 脸部特征注册。日程深度绑定提供时间线式的日程管理允许用户新建日程并将其与特定的人脸档案进行绑定。4. 延迟人镜协同主动唤醒针对智能眼镜在公共场合语音交互的社交瓶颈系统创新性地开发了延时主动唤醒工作流。当眼镜捕捉到人脸时系统不会在人际交往的当下强迫用户进行尴尬的语音输入而是将上一次看到的人脸信息暂存在后端的历史队列中。当用户回到私人空间、下一次重新进入眼镜对话时智能体的初始化节点会检测到这一未处理状态自动打断常规的日常问候并主动分流至追问分支询问用户是否需要为刚才见到的人添加日程。该状态一经读取即自动复位在确保温和、无感陪伴的同时避免了重复打扰。5. 语义自动解析与日程自动绑定在被动或主动唤醒状态下用户可以直接对眼镜说出极其口语化的日程描述如“明天一起吃中午饭”。工作流会将用户的语音文本、当前的系统基准时间以及刚刚锁定的面孔名称打包推送至后端 AI 接口。接口通过大模型自然语言解析自动将口语词如“明天”转化为绝对日期并提取出核心待办生成日程自动与该面孔名字完成绑定与存盘最终将更新后的最近三条日程返回由眼镜端重新渲染并进行闭环播报。技术实现技术栈是实现业务愿景的工具。为了保证智能眼镜和云端智能体之间的高效协同我们设计了以下轻量、解耦的技术架构1. 边缘-云端协同网络整个系统由三部分协同工作智能眼镜端侧输入负责第一视角的图像采集与身份标识user_id透传并通过 TTS 向用户反馈结果。云端智能体平台作为中枢大脑负责工作流的分支路由并调用相应的底层服务插件。服务端部署服务承载核心 AI 计算判断是否有人脸、是否为熟人、静态文件托管和内存数据库。2. 轻量化 AI 检测与比对方案在本次黑客松的人脸识别能力开发中我们采用了轻量高效的 AI 方案部署在开发团队本地计算机上并通过穿透基础进行临时的公网开放。具体人脸识别模型实现方案如下人脸检测采用基于 ONNX 框架的 YuNet模型。该模型专门针对轻量级设备优化对侧脸、低头等眼镜拍摄中常见的不标准角度有良好的检出率且完全避开了重型框架的本地编译依赖。特征验证采用 VGG-Face 算法提取高维特征向量进行余弦相似度比对。容错机制在识别阶段关闭了硬性人脸强制检出避免由于运动模糊导致服务崩溃改由状态码温和地引导用户调整角度确保了系统的健壮性。3. 模块化服务设计后端服务完全采用模块化设计将配置、数据结构、人脸计算路由和日程路由进行解耦。这种设计保证了高内聚低耦合无论是后续将内存数据库升级为持久化关系数据库还是为眼镜端接入更多的传感器指标都可以在不影响主干服务的前提下快速完成平滑升级。开发前景如果我们把眼光放得更长远一些从“主动交互”和“无感收集”的角度来看这款智能眼镜人脸助理的进化空间是极其巨大的。这次黑客松由于百宝箱平台在实时音频流获取上的技术栈限制我们遗憾地未能实现声纹识别。但在我们的设想中人脸识别 声纹识别的双模态融合才是智能眼镜在人际辅助场景下的终极形态。如果未来这一技术限制被突破我们可以在主动交互的框架下实现以下三个极具想象力的应用前景多模态无感信息收集现在的系统完全依赖眼镜“看”到的人脸这在人群密集或视线受阻时会存在局限。如果加入声纹识别眼镜就可以在后台默默地“听”并区分声音。即使对方不在视野正中央系统也能通过声纹特征完成身份锁定甚至在多人交谈时通过声纹分离技术精准记录是谁说了什么。对话流中的自动任务提取当前的日程绑定依然需要用户在网页端手动创建。而一旦实现后台音频流收集与声纹识别眼镜大模型就可以化身为“隐形秘书”。比如当眼镜听到交谈对方说“那我们下周二下午两点碰一下方案。”系统就可以自动在后台提取关键的时间和意图无需任何人掏出手机自动在对方的档案下新建一条“下周二14:00碰方案”的日程实现“对话即交互”。人际关系的自动沉淀与社会图谱构建基于第一视角的实时陪伴优势系统可以统计用户与不同面孔/声纹的接触频次、单次交流时长、甚至谈话的核心关键词。无需用户手动记录系统就会在后台自动沉淀出用户专属的人际关系图谱。眼镜能主动在合适的时候提醒你“你已经两个月没和朋友联系了上次你们聊到了智能硬件要打个招呼吗”对于智能眼镜这种贴身硬件来说真正的智能不应该是让用户频繁去对它说话而是它能在后台默默为用户整理世界。通过人脸与声纹的主动双重锁定系统将从一个被动的“人名查询工具”彻底蜕变为一个能自动安排任务、自动沉淀人际关系的主动式个人认知外脑。开发感悟“百宝箱”平台这次黑客松我们的应用逻辑主要跑在支付宝“百宝箱”平台上。在开发过程中我们觉得这个平台优缺点都非常鲜明其拖拽式的开发模式在带来便利的同时也给深度定制带来了一些不可忽视的门槛极其便利的软硬件高耦合百宝箱最大的优势在于它和智能眼镜硬件的联动做得非常丝滑。对于开发者来说部署和联调的成本极低。我们可以快速把云端的智能体逻辑直接投射到眼镜端极大地缩短了闭环验证的时间这对黑客松这种限时高压开发来说是个不小的加分项。缺乏 CLI 版本限制了 AI 辅助编程的上限百宝箱目前只有图形化的网页拖拽模式没有提供 CLI命令行工具版本。这就意味着我们无法直接用代码来生成或转化智能体的工作流。在如今这个“大模型辅助编程”的时代这在很大程度上限制了 AI 帮我们写代码、建工作流的能力开发者只能手动去连线和配置稍微有点影响开发生产力。gPass 触摸交互 API 封装粒度较粗在硬件接口的封装上gPass 存在一些细节上的遗憾。比如对于眼镜侧边的触摸板平台目前只能判断用户“有没有输出开发者指定的那种动作”返回是/否而不是向开发端输出“用户具体进行了哪种动作”。这导致我们无法在同一个交互节点内根据用户不同的手势输入进行动态逻辑分流例如我们无法实现“用户前滑时确认、后滑时放弃”的双向选择大大限制了条件分支交互的设计自由度。智能眼镜硬件首先要感谢 Rokid 方面为这次黑客松给予我们的便利实际上我觉得 Rokid 是很努力想要吧 Developer Relationship 做好的可以从以下三点切身感受到慷慨的硬件借用支持为了推广智能眼镜在这次黑客松中 Rokid 为我们提供了大量的实体眼镜借用。这也是为什么我们团队有机会真正摸到实体硬件并且最终获得关于智能眼镜这种贴身智能硬件的切身理解。没有设备一切想法都是空谈这一点 Rokid 做得非常大气。多样的技术栈选择除了我们这次比赛使用的基于支付宝生态的“百宝箱”平台 Rokid 还有自己的灵珠智能体平台。同时传统技术栈有利用 Rokid App 的 AIUI 技术栈和手机端 SDK在更基础的层面上还有眼镜原生 SDK。这让不同背景的开发者都能找到顺手的工具。技术支持全程在线在整个开发期间Rokid 的技术支持人员一直在参赛选手群中解答大家的问题。对于那些我们作为个人开发者难以解决的平台和底层 Bug他们也会伸出援手。让我印象最深刻的就是由于我们无法在百宝箱平台开发适配眼镜的卡片他们提出可以让我们投稿截图或代码帮忙实现。在获得了这次珍贵的智能眼镜硬件体验机会后结合实际的测试我们坚信贴身智能硬件如眼镜的灵魂在于“主动交互”而非“被动响应”。原因有以下三点单次交互的信息呈现量极低眼镜这种较小的设备体积和显示区域限制了它单次能呈现的信息量上限。它不像手机大屏可以滑动浏览海量信息眼镜的反馈必须是“点到为止”的。这就要求眼镜和用户之间有一种“心照不宣”的默契它得在合适的时候主动推最关键的信息而不是等用户繁琐地去问。语音交互在现实中存在瓶颈虽然在 Rokid 的交互设计中语音被认定为第一交互方式触摸板是次要的。但在真实的日常使用中我们发现可以“不尴尬地”和智能眼镜进行语音对话的场景其实非常局限。在安静的办公室、地铁或街头用户很难旁若无人地频繁对眼镜发号施令。随身佩戴的优势贴身硬件牺牲其本身的性能换来了最大的优势就是长时间的陪伴。它能在平时默默地收集环境信息进行高频、低感的“主动交互”而不是寄希望于用户在某一次主动对话中迅速去完成一件复杂的任务。从上述的洞察出发我们觉得 Rokid 目前在百宝箱平台对开发者的支持上还有更进一步的空间应该尝试让语音交互变成一种“后台信息收集机制”而不是“实时的被动交互机制”。用户其实没那么方便随时随地和眼镜智能体对话但眼镜的收音和环境感知能力其实很强。因此目前百宝箱智能体和智能眼镜耦合中采取的持续语音识别并以文本输入智能体的方式其实往往会给正在进行中的智能体工作流引入混乱。例如我们就注意到如果在智能体工作流执行时智能眼镜将杂音识别为用户指令的情况。更好的做法是让眼镜在后台进行流式音频的无感收集与分析就像 AIUI 技术栈那样。如果百宝箱未来能开放让开发者获取实时音频流的能力以我们这次的项目为例我们就可以在人脸识别的基础上加上声纹识别。这样一来眼镜不仅能识别到眼前人的脸将其声纹加入感知并于人脸绑定从而实现声纹 人脸的双重精准判定和全自动、无感地给面孔绑定任务与日程。这才是我们心中最理想的智能眼镜助理形态。