验证确认新设计在真实工况下是否达成安全目标
别名: 人因验证确认 · HFE V&V · operational validation
概念解释
人因工程验证与确认（human-factors verification and validation, HFE V&V）是两个经常被混用、但问的其实是不同问题的活动。验证（verification）问的是"我们把它做对了吗"——设计是否按规格说明构建、是否满足已列出的人因要求；确认（validation）问的是"我们做的是对的东西吗"——整合后的系统在代表性运行条件下能不能真正支持人员完成安全功能。它不是界面"好不好用"的单次主观评审。
机制
这两个问题之所以要分开问，是因为一个界面完全可能通过验证却在确认上失败。规格说明本身是人写的，写规格的人不可能预见到所有会在真实操作场景中暴露出来的交互问题——某个字段的位置、某个告警的措辞、某种操作顺序，逐条对照规格都合规，可组合起来放进一次真实的换班交接或异常处置里，就会让操作员做出错误判断。这不是实现出了错，而是规格本身在制定时就没有覆盖到那个真实工况。验证只能检验"实现是否忠于规格"，检验不了"规格是否忠于真实使用"；这道缝隙只有靠确认，把人、技术、任务和环境重新放回完整的运行链条里去找，才能补上。反过来，只做确认而不做验证也有问题：如果没有先确认实现和要求是一一对应的，确认阶段发现的问题就说不清是设计缺陷还是实现偏差，无法定位到该改规格还是改代码。
怎么研究
依据任务分析与风险分析定义可观察、可判定的成功判据，而不是让评审员凭印象打分。在高可信度还原的场景中——尽量贴近真实设备、真实程序、真实时间压力——记录错误、操作时序、工作负荷、团队沟通与从错误中恢复的过程，并把每一个缺陷追溯回具体的要求条目或设计决策，而不是笼统记成"用户体验不佳"。样本和场景的选取需要覆盖目标岗位的实际分布；"所有参与者最终都完成了任务"这句话本身不能作为通过的证据，因为它可能掩盖了过程中给出的提示、教练的介入、以及一次危险的临场恢复——这些如果被平均掉，看到的就只是一个虚假的"通过"。
边界
仿真和台架测试不能穷尽所有真实工况的组合，因此 V&V 通过不等于零风险认证，只是把已知的、可行的风险降到了可接受范围。设计、程序或系统构型发生显著改变之后，先前跑过的验证与确认证据可能整体失效——它们证明的是那个旧构型下的结论，不能自动套用到新构型上。此外，人因工程的法规与验收要求在不同行业之间差异很大，不宜把某个行业的一套通过阈值直接搬到另一个行业里当作普适标准。
怎么落地
- 建立"安全功能—人员任务—人因要求—测试证据"的双向追溯链，任何一条测试结果都能回溯到具体要求。
- 在测试开始之前就冻结场景脚本、成功判据和允许给出的提示种类，避免事后按结果调整标准。
- 对每个缺陷先评估它对安全的实际影响，再决定是否需要修复设计并回归测试，而不是用"加强培训"来解释掉一个设计缺陷。
- 明确区分"验证未通过"与"确认未通过"两类记录：前者指向要具体修哪一条规格或实现，后者指向要重新审视任务分析或场景假设。