【交叉评测】SafeOpera 已具备人工在环闭环，但模拟数据时效、状态一致性与复核反馈仍需加强 #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
1. 项目理解
我了解到SafeOpera 是一个面向工程作业场景的、以人为中心的疲劳感知和安全调度系统。项目尝试建立完整闭环：监测工程人员状态，汇总 HRV、EDA、皮温、运动强度等数据，结合个体基线、趋势和 Borg RPE 评估疲劳，输出风险告警与调度候选，再由主管人工确认或标记误判，最后生成决策单、班次摘要和详细报告。
页面明确说明系统只提供辅助分析，不自动执行调度，也不构成医疗诊断。这个边界设计合理。
2. 项目优点
2.1 产品流程完整
Demo 覆盖开始监测、现场即时复测、暂停监测、重置数据、人员状态矩阵、个体实时证据、评估智能体与证据流、主管待办、人工确认/标记误判、反思记录、监控快照、班次详细报告和实时分析助手，基本覆盖“监测—评估—调度建议—人工复核—报告”的产品链路。
2.2 数据维度丰富
个体详情展示 HR、HRV、EDA、皮温、运动强度、信号质量、环境温度、EDA/HRV/SKT 5 分钟窗口、30 分钟趋势、个体基线、当前工况和技能，并结合 Borg RPE、自报信息、现场事件和调度候选，证据链比单一疲劳分数更利于主管复核。
2.3 人工在环设计清晰
主管待办提供“确认准确”“标记误判”“运行反思”和正常样本抽查队列。系统没有把自动判断直接当作最终调度决定，保留人工确认和纠错环节。
2.4 报告和追溯入口较完整
报告中心提供在线查看、Markdown、打印/PDF；评估流提供证据和追溯入口，符合安全生产系统对决策依据和报告输出的要求。
2.5 助手能够表达不确定性
选择曹雨辰 / W011，并请求生成当前状态摘要后，助手返回重度疲劳、约 0.817 置信度、EDA 高于基线 3.0σ、HRV 低于基线 3.0σ、SKT 高于基线 1.8σ、Borg 估计 18.49，生成 3 名 pending 调度候选并提示需要人工复核。助手还指出指标与活动状态存在冲突。这种不确定性表达值得保留。
3. 当前问题
3.1 数据时间明显落后于当前服务时间
助手返回数据时间戳为 2026-07-29，而当前服务时间为 2026-08-06。页面显示系统在线、监测运行中，但引用的评估数据至少落后一周。过期数据可能被误认为当前状态，进而生成不适用的调度建议。
建议明确展示数据采集时间、进入系统时间、最近同步时间、数据延迟、数据是否过期及过期后的策略。数据超过阈值时应标记为“过期数据”，禁止直接生成调度建议，或要求重新采集/人工确认。
3.2 “系统在线”“监测运行中”和“模拟数据”层级不清
页面同时显示系统在线、监测运行中、真实时间采样刷新、数据源为本地模拟数据；助手返回来源为 fallback/simulated。用户容易误以为已接入真实传感器或实时后端。
建议拆分显示：服务状态、监测状态、数据源、数据新鲜度、评估模式、调度执行状态，并在页面顶部持续显示“演示数据/模拟数据”。
3.3 重度疲劳判断与活动状态冲突，但主页面提醒不足
W011 同时出现重度疲劳、82% 置信度、HRV 低于基线 3.0σ、EDA 高于基线 3.0σ、SKT 高于基线 1.8σ、Borg 18.49、运动强度约 0.42、当前状态为空闲、班次时长仅 0.1H。助手明确指出指标与活动状态存在明显冲突，但主界面仍把重度疲劳和调度候选放在普通待办列表中。
建议对“高风险结论 + 低活动量/短班次”增加显著冲突告警；主管待办直接显示“指标冲突，必须复核”；将需要复核与确认准确分开；未经复核不得进入可执行状态；同时展示传感器异常、基线不准、历史数据、数据延迟和佩戴问题等可能原因。
3.4 fallback 数据仍继续生成高风险结论和调度候选
助手说明数据来源为 fallback/simulated，但系统仍输出重度疲劳、82% 置信度、3 名调度候选和调度决策单。真实产品需要明确 fallback 安全策略。
建议区分 live、mock、fallback、stale。mock 仅允许演示；fallback 仅供参考并强制人工复核；stale 不允许直接触发调度。fallback/stale 时应降低置信度上限、显示来源、禁止自动生成可执行调度，并在报告中写入降级原因和数据时间。
3.5 置信度与数据质量、数据冲突关系不明确
82% 置信度与陈旧数据、活动状态冲突、fallback/simulated 来源同时出现。用户无法判断置信度代表模型分类、数据质量、证据一致性还是调度建议可信度。
建议拆分显示信号质量、数据新鲜度、模型判断置信度、证据一致性和调度建议可信度，不要用单一百分比概括所有不确定性。
3.6 主管确认后的状态变化不够明显
点击主管待办中的“确认准确”后，页面仍保留大量待确认项目，人工闭环计数和列表变化不够直观。
建议确认后立即显示已确认、确认人、确认时间、确认前后状态、后续动作和审计记录链接；明确是否写入反思记录、改变报告状态、影响 KPI、改变调度候选状态、支持撤销，以及哪些操作只是本地模拟。
3.7 监测时间和数据时间缺少一致性校验
页面监测过程显示“第 44 分钟”，但决策流仍显示 08:05，报告时间也与当前浏览时间不完全一致。
建议统一展示 Demo 当前时间、模拟班次时间、数据采集时间、评估时间窗、报告生成时间和服务端时间，避免历史演示数据被误认为当前真实班次。
3.8 “现场即时复测”缺少验证结果展示
按钮存在，但应明确展示重新采样状态、采样完成时间、新旧数据对比、风险等级变化、置信度变化、是否重新生成调度候选和失败原因。建议增加复测前后对比卡片。
3.9 报告需要明确时间、来源和决策状态
报告应包含数据源、采集时间、数据延迟、fallback 状态、模型版本、规则版本、评估窗口、主管确认状态、是否执行调度、证据列表、不确定性和冲突项，并区分数据时间与报告时间。
3.10 健康数据治理说明不足
系统涉及 HRV、EDA、皮温、疲劳等级、员工姓名/工号、主管判断和调度建议。README 和 Demo 应补充数据是否真实/模拟、保存期限、访问权限、脱敏、员工同意、误报漏报处理、员工查看/撤回数据方式，以及报告中的敏感信息范围。
4. 建议优先级
P0：安全和时效性
P1：人工闭环
P2：可复现性和文档
5. 综合评价
SafeOpera 已具备较完整的产品叙事和交互闭环，证据链、人工在环、主管复核和报告输出尤其完整。本轮操作证明 Demo 可以启动监测、选择人员、查看个体指标、确认主管告警，并由助手生成带证据链和不确定性说明的状态摘要。
当前最需要加强数据可信度和安全边界。过期 fallback 数据仍参与高风险判断和调度候选生成，指标冲突也未在主流程中足够突出。建议优先解决数据时效、来源标识、冲突告警和确认审计。
感谢 RECHTAN 的完整操作评测，尤其感谢对数据时效、状态一致性、冲突提示和主管复核反馈的逐项检查。收到评测后，我们重点完成了以下修改：
上述修改已合入 v0.2.1 / e787dd2。再次感谢这次细致评测，对我们完善安全边界和人工闭环非常有帮助。