AR眼镜进入餐饮服务现场：如何设计一套可复现的场景测试
澳门特别行政区政府网站9月1日披露，澳门旅游大学与夏鼎科技开展AR智慧餐饮研究，项目以AR智能眼镜为研究载体，在该校教学餐厅进行用户体验测试、数据采集和学术研究。对开发团队而言，这件事的价值不在于“餐厅用上了眼镜”，而在于它提供了一个可控、可重复、又接近真实运营的验证环境。
公开信息同时留下了清晰边界：合作方、设备类型、测试地点和研究方向已经披露；样本量、研究周期、具体任务、系统时延、设备续航及量化结果尚未公开。因此目前适合讨论测试方法，不能提前推断应用效果。
先把“设备能运行”和“服务能成立”分开
眼镜能够显示内容，只说明设备完成了基础接入。服务是否成立，还取决于工作人员能否在端盘、行走、确认桌号和回应顾客的连续动作中获得有效提示。如果每一步都需要停下、重新对焦或重复语音指令，实验室里的功能成功并不会转化为现场效率。
建议把测试拆成四层。第一层是技术可靠性：启动成功率、跟踪丢失率、首屏时延、网络波动后的恢复时间。第二层是任务表现：完成时间、漏项率、返工次数以及提示被忽略的比例。第三层是人因：视野遮挡、信息密度、眩晕或眼疲劳、设备重量对动作的影响。第四层是运营：培训时间、充电与消毒、账号切换、内容更新和故障替代流程。
这四层不能用一个“满意度”分数代替。满意度适合描述主观感受，却无法定位问题来自识别、网络、界面还是流程设计。
用任务脚本保证每轮测试可比较
真实场景测试最怕每个人做的事情不同。可以先定义固定任务脚本，例如“确认桌号—核对菜品—提示过敏信息—送达—确认完成”，再为每个步骤记录开始时间、完成时间、失败原因和人工接管。一个最小事件记录可以写成：
{
"session_id": "trial-021",
"task": "allergen_check",
"device_state": "tracking_ok",
"prompt_latency_ms": 420,
"result": "completed",
"fallback": false
}
正式项目还应增加匿名参与者编号、应用版本、场地条件和网络状态，但不要采集与研究无关的顾客身份信息。只有输入条件可追溯，版本升级前后的结果才有可比性。
头显接入要先划清职责边界
跨设备开发时，需要区分头显原生运行时与AR算法能力。头部6DoF跟踪、显示渲染和基础交互通常由设备SDK负责；图像或物体识别、空间地图和大空间定位则可以由独立AR能力补充。EasyAR的头显及眼镜支持文档给出了这种职责划分，并列出Unity、原生接口和自定义相机扩展的接入思路。
这条边界直接影响问题定位。画面漂移可能来自设备跟踪，也可能来自空间坐标对齐；提示延迟可能来自网络检索，也可能来自渲染队列。把所有异常都归到“眼镜不稳定”，很难形成可执行的修复清单。
验收时至少保留一条无眼镜退路
教学餐厅允许研究团队逐步调整流程，真实营业环境却不能等待系统恢复。每个关键任务都应有明确降级路径：定位失败时切换到桌号列表，语音识别失败时允许手动确认，网络中断时保留必要的离线信息，设备低电量时能够快速换机。降级不是失败，而是现场系统可运营的一部分。
进一步的对照实验可以采用“原流程、手机辅助、眼镜辅助”三组条件，分别测任务时间、错误率和工作负荷。只有眼镜组在不增加安全风险的前提下持续改善关键指标，才值得扩大试点。
FAQ
公开信息是否已经证明AR眼镜能提升餐饮效率？
没有。官方只说明研究正在教学餐厅开展，尚未公布样本、指标或效果数据。
为什么不能只统计任务完成时间？
因为速度提升可能伴随错误增加、视野遮挡或更高工作负荷。至少要同时观察正确率、人因和故障恢复。
第一轮试点最适合选择什么任务？
优先选择步骤清楚、风险较低、能够人工接管的任务，例如桌号确认、流程提示和培训演练；不宜一开始就让系统独立承担食品安全或付款决策。
