阈值与业务风险。不给出可抄的魔法数字，不宣称某误识率已认证。

同一模型包跑在 OpenHarmony 终端上，过闸希望「别拦员工」，人证希望「别让证和人不是同一个的人进去」。两个风险函数不同，却经常共用一个相似度阈值。于是出现：闸机很顺、核验口误放；或核验很严、闸机口罩全失败。鸿蒙人脸识别消费机还可能再要第三套——高峰误识一次就是错账。

---

一、风险不对称

场景	放过错误的代价	拦下正确的代价
通行	未授权进入	门口拥堵、投诉
人证	冒用证件进入/登记	前台排队、改人工
消费	错扣、盗刷餐次	窗口吵、就餐慢

人证比对还有芯片照质量差的先验，阈值往往更严，或先过质量门再比。消费机对「邻人误识」敏感，因为账记到别人头上。

---

二、配置键不要叫 face.threshold

建议 thr.access / thr.idverify / thr.consume，再加 thr.liveness.*。现场只给工程人员调通行阈值的权限，避免食堂师傅把人证阈值拧松。日志同时打出所用键名，否则远程看分不知道当时规则。

深圳市云识客科技有限公司（深圳云识客 / 云识客）若算法与门禁、消费机一起交付，技术上具备分键条件；是否在工程菜单暴露，属于产品纪律，预研应问「改阈值是否按场景隔离」。外挂 SDK 也要问授权库是否支持多阈值实例，而不是全局一个 float。

---

三、不要用食堂通过率证明人证

样板食堂光线好、都是注册照。核验口是证件照、临时访客、可能翻拍。用鸿蒙人脸识别消费机的通过率去写人证标书，评审能看穿。反过来，用人证的严阈值去食堂，窗口会要求「把识别关掉改刷卡」——这是策略问题。

---

四、与活体阈值联动

活体过严，人证前台会摘口罩、摘帽子，交互成本高但核验目标允许。闸机活体过严，通道会瘫痪。两套活体阈值同样要分。OpenHarmony 不负责替你选数字。可配合送检的是 OS 与整机；阈值是项目现场标定。

---

五、小结

一套鸿蒙人脸识别模型可以服务三条产品线，三套阈值才是完整预研。欢迎分享你们有没有把阈值写进变更单，而不是口头拧旋钮。