XR 培训与仿真应用

三者的工程差异：
  演示：交互可以简化，重点在视觉
  培训：流程必须与真实一致，重点在正确性与可测量
  推演：状态空间大、分支多，重点在仿真模型与评估

任务建模的三层结构：
  1. 任务（Task）：一次完整的培训目标
     例：更换某设备的液压泵

  2. 步骤（Step）：任务的组成单元，有序或可分支
     例：断电 → 泄压 → 拆卸管路 → 拆泵 → 装新泵 → 复原

  3. 动作（Action）：步骤内的具体操作，可判定
     例：扳手拧到指定扭矩、按顺序关闭 3 个阀门

每个动作要有明确的：
  □ 前置条件（什么状态下才能做）
  □ 完成判据（怎样算做对了）
  □ 错误判据（哪些做法算做错）
  □ 评分权重（对总体评分的贡献）

{
  "task": "hydraulic_pump_replacement",
  "steps": [
    {
      "id": "s1",
      "name": "断电",
      "precondition": ["power_on"],
      "actions": [
        { "id": "a1", "type": "toggle_switch", "target": "main_breaker",
          "expect": "off", "score": 10, "critical": true }
      ]
    },
    {
      "id": "s2",
      "name": "泄压",
      "precondition": ["s1.done"],
      "actions": [
        { "id": "a2", "type": "rotate_valve", "target": "relief_valve",
          "expect": { "turns": 3, "direction": "ccw" }, "score": 15,
          "error_if": "pressure_gt_zero" }
      ]
    }
  ]
}

建模的两个关键决策：
  1. 步骤的严格程度
     严格顺序：适合安全规程（断电必须第一步）
     任意顺序：适合无强制顺序的操作，降低挫败感
  2. 判据的松紧
     过严：学员做出正确结果但方式不同也被判错
     过松：错误操作也能通过，训练失去意义
  经验：安全相关的步骤严格，其余步骤给替代方案。

提示的层次（由弱到强）：
  1. 环境提示（Ambient）
     高亮当前该操作的部件，不说明怎么做
  2. 视觉引导（Visual）
     用箭头、虚线、动画演示操作方式
  3. 文字/语音说明（Instructional）
     用文字或语音描述步骤
  4. 强制引导（Forced）
     直接把学员的手/工具引到正确位置

设计原则：
  提示强度应随学员的熟练度与错误次数「按需升级」。
  新手用强提示，熟练后自动降级，避免形成依赖。

// 按错误次数动态调整提示强度
enum HintLevel { None, Ambient, Visual, Instructional }

HintLevel DecideHint(int wrongCount, float idleTime) {
    if (wrongCount >= 3 || idleTime > 15f) return HintLevel.Instructional;
    if (wrongCount >= 1 || idleTime > 6f)  return HintLevel.Visual;
    if (idleTime > 3f)                      return HintLevel.Ambient;
    return HintLevel.None;
}

提示系统的量化目标：
  □ 首次独立完成率 > 80%（无提示情况下）
  □ 平均提示次数随练习次数下降（学习曲线）
  □ 卡顿时间（idleTime）持续下降
  如果提示次数不下降，说明提示系统在「包办」而非「教学」。

三类错误：
  1. 操作错误（Wrong Action）
     做了不该做的操作 → 判定为错误，给出反馈，允许纠正
  2. 顺序错误（Wrong Order）
     步骤顺序不对 → 按严格程度决定是否判定错误
  3. 危险操作（Critical Error）
     可能导致事故 → 立即中断，强反馈，要求重做

容错的边界：
  允许犯错，但不允许「错到无法继续」。
  例如拧坏了螺栓，应提供「更换螺栓」的路径，
  而不是让任务彻底卡死。

错误的反馈设计：
  □ 即时（100 ms 内）：让学员立刻知道错了
  □ 明确（说清错在哪）：不要只显示「错误」
  □ 非惩罚性（不批评）：培训是学习，不是考核
  □ 可回退（能重试）：提供「撤销」或「重做本步」

常见反模式：
  ✗ 错误后直接跳到下一步（学员不知道自己错了）
  ✗ 错误后强制从头开始（挫败感强，浪费时间）
  ✗ 只显示红叉不给原因（学员无法学习）

角色划分：
  学员（Trainee）：执行操作
  教官（Instructor）：观察、指导、设置故障
  旁观者（Observer）：观看，用于复盘

教官端的核心能力：
  1. 上帝视角：自由飞行观察整个场景
  2. 学员状态：实时看到每个学员的步骤进度与错误
  3. 故障注入：动态插入故障（如「管路泄漏」）考验应变
  4. 暂停与讲解：暂停场景，走到学员身边讲解
  5. 语音指导：单向或双向语音

多人协同的同步需求（与社交 VR 类似但有差异）：
  □ 位姿同步：与社交 VR 同（见虚拟形象篇）
  □ 场景状态同步：工具位置、设备状态必须一致
  □ 权威性：教官的操作优先，学员操作需校验
  □ 一致性：所有人看到的设备状态必须相同，否则训练无效

场景状态同步的关键：
  设备状态（阀门开合、开关位置）必须由服务端权威管理，
  学员客户端只发「意图」，服务端校验后广播结果。
  否则两个学员看到不同状态，训练逻辑立刻崩坏。

要采集的数据（分层）：
  1. 行为数据
     每一步的耗时、操作次数、错误次数、提示次数
  2. 结果数据
     任务完成率、完成时间、最终评分、关键错误数
  3. 过程数据：视线轨迹（看哪里）、手部轨迹（怎么操作）
  4. 主观数据：学员自评（NASA-TLX 负荷量表）、教官评价

评估的核心指标：
  □ 首次通过率（First-pass Rate）
  □ 任务完成时间（Time on Task）
  □ 关键错误率（Critical Error Rate）—— 最重要
  □ 学习曲线（随练习次数的改善）

「迁移测试」是评估的金标准：
  在虚拟环境中训练后，到真实设备上测试表现。
  如果虚拟训练没有提升真实操作水平，
  再漂亮的 XR 也只是「昂贵的演示」。

对比设计：
  对照组（传统培训）vs 实验组（XR 培训），
  比较上岗周期、错误率、培训成本。

埋点数据的两个用途：
  1. 评估培训效果（对管理层汇报）
  2. 优化培训内容（哪一步错误率最高 → 该步需要改进）

注意隐私：视线与手部轨迹属行为数据，
企业场景下需与员工知情同意，避免变成「监控」。

需要的仿真层次：
  1. 刚体物理：零件掉落、碰撞、堆叠（通用引擎能力）
  2. 关节与约束：阀门的旋转限位、管路的连接约束
  3. 流体/电气行为：压力变化、电流通断（简化的状态机）
  4. 故障行为：泄漏、卡滞、失效的模拟

关键判断：多数培训不需要「物理精确」，
只需要「行为正确」。
  例：不需要真的解流体方程，
      只需要「关闭阀门 → 压力在 2 秒内降到 0」。

// 简化的设备状态机（比物理仿真更可靠、更可控）
public class Valve : MonoBehaviour {
    public bool isOpen;
    public float pressureDownRate = 0.5f;   // 每秒降压比例
    public PressureSystem system;

    public void Turn(bool toOpen) {
        isOpen = toOpen;
        system.OnValveChanged(this);
    }
}

public class PressureSystem : MonoBehaviour {
    public float pressure = 1.0f;
    void Update() {
        if (AllValvesClosed()) pressure -= pressureDownRate * Time.deltaTime;
        pressure = Mathf.Clamp01(pressure);
    }
}

「行为正确优先于物理精确」的原因：
  1. 物理仿真成本高、稳定性差（抖动、穿透）
  2. 培训关注的是「操作与结果的关系」，不是物理细节
  3. 状态机可控、可预测，便于判定与评分
例外：需要训练「手感」的场景（如装配力感），才需要较真实的物理与力反馈。

数字孪生的三个层次：
  1. 静态孪生：几何与外观一致（3D 模型）
  2. 行为孪生：操作逻辑一致（状态机 + 流程）
  3. 实时孪生：与真实设备数据联动（IoT 接入）

实时孪生的价值：
  用真实设备的实时数据驱动虚拟模型，
  学员看到的是「真实设备此刻的状态」，
  培训与运维（监控、诊断）可以合一。

实时数据接入的架构：
  真实设备（PLC / 传感器）
    → 工业协议（OPC UA / Modbus / MQTT）
    → 网关（协议转换 + 数据清洗）
    → 数据服务（时序数据库 + 推送）
    → XR 应用（订阅数据，更新虚拟模型状态）

关键工程问题：协议异构需网关统一；传感器 10~100 Hz 而 XR
只需 10~30 Hz；断连时虚拟模型的行为（冻结还是报错）；
生产网与 XR 设备网络必须隔离。

编辑能力的分级：
  1. 代码级：工程师在引擎里开发（灵活但慢，改动要发版）
  2. 配置级：流程与参数用 JSON/表格配置（工程师准备框架）
  3. 低代码：教官/业务人员用图形界面搭建流程（无需编程）
  4. 无代码：拖拽预制模块组合

现实路径：
  工程师搭「框架 + 预制动作模块」，
  业务人员用配置或低代码界面组装具体培训。

低代码编辑器的核心能力：
  □ 流程编排：拖拽步骤，连线定义顺序与分支
  □ 动作库：预制「拧螺丝」「开关阀」「读数」等动作
  □ 条件与判据：图形化配置前置条件、完成判据、错误判据
  □ 提示配置：为每步配置提示文案、语音、视觉引导
  □ 预览与试玩：编辑即预览，快速验证
  □ 版本与发布：培训内容独立版本管理，不影响应用主程序

关键架构决策：
  培训内容「数据化」——把流程、判据、提示都存为数据，
  应用只做「执行引擎」。
  这样内容更新不需要重新发版，
  与资产管线同理（见 XR 资产管线篇）。

部署方式：
  1. 企业 MDM（移动设备管理）：批量配置、推送、锁定设备
  2. 私有分发：不上公开商店，通过 MDM 或侧载安装
  3. Kiosk 模式：锁定为单应用，防止学员退出
  4. 多设备同步：多台头显的内容与状态保持一致

运维的现实问题：
  □ 设备数量多、固件版本不一 → 需要统一的设备管理
  □ 卫生与损耗：多人共用头显的面罩卫生、线缆损耗
  □ 充电与收纳：批量充电柜、收纳方案
  □ 现场支持：培训现场的快速排障能力
  □ 内容更新：如何批量推送到所有设备

Kiosk 模式的必备能力：
  □ 自动启动：开机即进入培训应用
  □ 会话管理：一次培训结束后自动重置，下一位学员直接用
  □ 防退出：屏蔽系统菜单，或需要密码才能退出
  □ 状态复位：所有设备状态回到初始值
  □ 结果上传：每次培训的成绩自动上传到管理后台

任务建模：
  □ 任务拆成步骤与动作，每个动作有前置条件与判据
  □ 安全相关步骤标记 critical，做错立即中断
  □ 顺序严格程度按场景区分（安全严格、其余灵活）

引导与容错：
  □ 提示强度按错误次数与卡顿时间动态升级
  □ 监控「提示次数随练习下降」这一学习曲线指标
  □ 错误反馈即时、明确、非惩罚、可回退

协同与评估：
  □ 设备状态由服务端权威管理，避免状态不一致
  □ 教官端支持上帝视角、故障注入、暂停讲解
  □ 埋点覆盖行为、结果、过程、主观四类数据
  □ 做迁移测试验证虚拟训练对真实操作的提升

仿真与部署：
  □ 设备行为用状态机，行为正确优先于物理精确
  □ 实时孪生的成本重点评估工业数据接入
  □ 培训内容数据化，支持低代码编辑与独立更新
  □ Kiosk 模式 + 会话自动重置 + 结果自动上传