指纹挪到侧边之后：生物识别换个位置，验收整套重做
一、口碑不佳的技术解释：位置换了，姿势就换了
据公开报道，海外首批评测对某款折叠机型的侧边按键式指纹给出多数偏负面的体验反馈，认为不如原有的面部方案。评测分数、媒体名单与机型参数来源都没给，本篇不补；也不去比哪种识别方式更先进——那不是这件事的重点。重点是一条很朴素的因果链，它对企业 App 的登录设计有直接后果：
位置变化，导致姿势变化，导致失败模式变化。
同一枚采集器件，放在正面时手指是向下按压，接触面接近垂直、受力方向稳定；挪到侧边后，设备是握在手里，拇指要横着搭过去，接触角度、按压力度、接触面积全都换了，而且和握持方式绑在了一起：左手右手、单手双手、设备放在桌上还是悬在空中，每一种组合的接触条件都不一样。原来那套可用性数据是在另一种姿势下测出来的，它不是”稍微有点偏差”，它测的是另一件事。
所以真正的教训不是”这个位置不行”，而是：任何让使用姿势发生变化的改动，等同于换了一个待验收对象。这类改动在产品评审里常常被归到”外观/结构变更”，走一个轻量流程就过了，而它应当走的是重新验收。
二、位置带来的新变量，要在用例里逐个占一行
要把这件事做扎实，先把新变量列出来，并且每个变量都要能说清它改变的是哪一类失败。
| 变量 | 改变的是什么 | 采集与记录时要做的动作 |
|---|---|---|
| 握持角度 | 接触面与器件法线的夹角，影响成像质量与有效面积 | 用例里按角度分档，不要只写”正常握持” |
| 拇指可达区 | 是否要调整握法才够得着，影响按压是否完整 | 记录左右手、单手双手各自的完成路径 |
| 按压方向 | 侧向推力可能带来源位移，让采集到的图与注册图错开 | 增加”斜着按””推着按”两条用例 |
| 单手操作 | 另一只手扶不住设备，会出现抖动与中途改握 | 加入悬空与桌面两种支撑条件 |
| 湿手与戴手套 | 表面反射与导电特性变化，直接影响能否成像 | 条件矩阵里独立成项，不与”手指干燥”合并 |
| 暗光与逆光 | 若链路里有光学辅助环节，环境光会改变可用性 | 现场条件要写进测试环境记录 |
| 误触 | 侧边按键与握持接触重合，抓握本身就是一次触发 | 单独测”拿起设备”这一动作触发了几次识别 |
最后一项常被忽视，但它在企业场景里最要命：握持即触发会带来大量无效识别请求，进而把后面的失败计数、锁定策略与用户感知全部搅乱。不测这一项，所有阈值调优都是在噪声上调出来的。
三、误识与拒识的取舍要按场景分档，不能共用一个阈值
生物识别的取舍从来是双向的：判得松，误识风险上升；判得紧，拒识概率上升。企业 App 里最容易犯的错是全局设一个”严格程度”，然后在所有入口共用。三个场景的代价结构完全不同。
| 场景 | 一次误识的代价 | 一次拒识的代价 | 取舍方向 | 配套要求 |
|---|---|---|---|---|
| 门禁刷卡 | 无关人员进入受控区域，事后难追溯 | 员工被拦在门外，现场找管理员 | 偏紧，宁可多问一次 | 身份与凭证要一一对应，进出记录独立留存 |
| 支付确认 | 直接产生资金损失，且难撤销 | 用户当场烦躁，但可重来 | 最紧，且必须逐次 | 不允许任何形式的免确认窗口 |
| 普通解锁 | 设备落在他人手里时的数据暴露面 | 高频打断，体验损失最明显 | 适度，但要留快速替代路径 | 失败计数与降级路径必须清晰 |
具体的严格程度取值属于产品与风控的决策，不在这里给数值。要做的是把这三档做成显式配置项，每一档记下：适用入口、判定依据版本、调整人与调整原因。没有这张配置表，运营就会在一次投诉之后随手把全局调紧，然后在另一个场景里付出代价。
还有一点要写进设计约束：三档之间不能互相稀释。同一个会话里从”普通解锁”进到”支付确认”时，前者建立的信任状态不应自动升级成后者的授权，这和屏幕位置无关，是链路语义。
四、把”识别失败之后的路”当一等公民设计
位置一变，拒识率就会变，因此失败路径不能是补丁，它得是主设计。四件事各自都要有明确答案：
- 备用口令：能不能设、强度要求、多久轮换、以及在识别不可用时多久内可以凭口令进入。企业场景还要加一条：备用口令不得成为绕过设备绑定的通道。
- 超时降级：识别请求卡住或无响应时，等待多久放弃、放弃后落到哪条路（口令、重新触发、还是提示用户换个姿势）。超时必须定义到一个具体数值上，”看情况”不是设计。
- 锁定策略：连续失败多少次锁定、锁定多久、能否由管理员解锁、锁定是否区分场景（支付锁了不该顺带把只读浏览也锁掉）。
- 失败原因的表达：这一条最容易被做错。系统内部要知道的原因（接触面积不足、按压角度偏、图像质量低、无匹配）和用户看到的提示必须分开设计：能指导用户改变动作的原因要回显，涉及判定阈值的原因只进日志。告诉用户”手指出点汗再试”有用，告诉他”匹配分数低于阈值”既没用又泄露判定线。
回显与日志的分界要落成一张映射表，每个内部原因代码对应一条对外文案和一个是否进日志的标记。有了这张表，客服口径和研发口径才可能对得上。
五、三类变更必须重跑用例表，不重跑就等于没有数据
我们把”重新验收”触发条件写死成三类：换设备形态、换识别模组、换系统版本。任意一类发生，下面这几张矩阵全部重跑，不接受”只改了外观”或者”只升了系统”的理由跳过。
- 姿势矩阵：单手、双手、悬空、桌面四种支撑与握法，乘以左手与右手。
- 条件矩阵：干手、湿手、戴手套、暗光、逆光，各与姿势矩阵的关键组合交叉一轮，而不是各测各的。
- 对抗矩阵：遮挡、重复按压、误触（拿起即触发）、中途改握、按压过轻与过重。
执行时有三条纪律，缺一条结果就不可比：
- 同一批人在同一批条件下跑，人群分组要记录手型大小、是否戴手套习惯这类变量；换人群就重测，不能混着算。
- 每一格记录完成路径而不是只记成功失败，即”一次通过”还是”重试几次后通过”。用户抱怨的多半是后者，它不体现在成功率里。
- 环境条件（现场光照、温湿度、网络状态）与用例版本一起写进记录，否则两次结果对不上时无从解释。
跑完之后要产出的是一个可比对的基线：每个场景档位的重试次数分布与失败原因构成，供后续判定”这次变更是不是让某一档变差了”。没有基线的验收等于走个过场。
六、把”连续拒识次数”做成上报指标，不要等投诉
为什么等投诉不够？因为拒识的多数后果是用户自己换个方式进去了——多按两次、改用口令、或者干脆少登录一次。这些行为不会变成工单，只会变成体验劣化和一堆查不清的流失。洹拓给客户做登录链路的观测时，把这几个量做成客户端上报的一等指标：
- 连续拒识次数分布：同一次登录会话内连续失败的次数，看分位数而不是均值，问题都藏在尾部。
- 失败后的替代路径占比：重试通过、改口令、放弃登录各占多少。改口令占比上升，往往先于任何投诉出现。
- 原因代码构成：按第四节那张映射表的内部原因分类统计，能直接指出是接触条件问题还是判定问题。
- 场景标签：与第三节的三档配置对齐上报，否则不同入口的数据混在一起，调紧一档就会让整体指标看起来变差，没人敢做该做的调整。
上报要有边界：不带原始图像与任何可直接还原的生物特征数据，只带计数、原因代码与形态标识（机型、器件位置、系统版本这一类），并且要按最小必要原则写明采集目的。这一条不写清，可用性观测自己就变成了新的合规问题。
指标定完，变更流程也就有了硬判据：形态、模组、系统任一变化未带新的矩阵结果与上报基线，登录链路的需求不进入发布。位置一挪，原来那份可用性报告就只是档案，不是依据。