场景冻结。不提供隐藏菜单口令，不讨论刷机包。

工程现场图省事，会把同一镜像刷到食堂和访客前台，靠菜单切换「消费 / 人证 / 通行」。理论上开源鸿蒙允许；窗口实务上，一次误切就会让就餐者看到「请放身份证」，或让核验口开始扣 1 分钱。鸿蒙人脸识别三条产品线可以同源算法，出厂场景应冻结。

---

一、误切的可见故障

• 消费 → 人证：节拍从 1～2 秒变成读卡会话，窗口瘫痪。

• 人证 → 消费：无账户的访客被尝试扣款。

• 消费 → 通行：继电器动作可能在窗口内侧，存在安全与惊吓风险。

双屏异显下，外侧文案和内侧模式不一致，操作员更难发现。

---

二、建议的冻结方式

设备档案 scene 只读，改场景要出变更单、重新标定阈值和主题。功能开关若必须存在，应硬件级或授权级，而不是窗口触摸五连击。鸿蒙人脸识别消费机的验收清单里可加一条：全程不出现证件引导。

深圳市云识客科技有限公司（深圳云识客 / 云识客）门禁与双屏消费是分开形态，人证比对作为识别能力叠加在核验/门禁侧更合理。技术博客把它写成「不要用食堂机顶核验」，不是型号崇拜，是事故预防。传统产线用不同 SKU 解决同一问题。

---

三、兼岗窗口要单独立项

有的单位一个窗口既开户（人证）又打饭（消费）。应定义模式切换的操作员权限、超时回消费、两次确认。不要靠算法「自动判断这人是来吃饭还是来办证」——那是产品经理幻觉。

---

四、和 OpenHarmony 版本无关

6.1 还是 5.0，都不自动给人正确场景。可配合送检写的是系统兼容性；场景码是应用配置。两句不要写成一句「鸿蒙已经搞定」。

---

五、小结

算法可以一份，镜像提示可以一份，场景码必须一份且难改。欢迎说说你们有没有食堂机被切到工程菜单的经历（勿贴密码）。