审阅 Finding 并记录反馈
设备 Finding 是将受治理证据集中到同一审阅流程的客户可见运营记录。它不是原始模型事件、确定性故障诊断或故障概率。
使用 Finding 详情页理解发生了什么、为什么值得关注、哪些证据支持或限制结论、需要检查什么,以及如何记录人工判断。
入口和权限
| 任务 | 入口 | 权限 |
|---|---|---|
| 列出并打开 Finding | /pdm/anomalies 和 /pdm/findings/:alertId | pdm:read |
| 打开关联设备 | Finding 详情 | pdm:read |
| 记录首次判断 | Finding 详情 | pdm:write |
| 更正既有判断 | Finding 详情 | system.config |
| 打开维护建议 | /pdm/advisory/inbox | 当前动作对应的 PdM 读写权限 |
Finding 查询按租户隔离。来自其他租户的链接不应泄露该标识是否存在。
审阅流程
先检查证据时间和数据质量。基于过期、缺失、可疑或非运行数据的精确分数,不是有效的当前结论。
发生了什么
摘要区说明:
- 受影响设备和目标;
- 关注等级和 Finding 状态;
- 首次和最后观测时间;
- 异常和恢复持续窗口;
- 数据截至显示的数据截止时间。
关注等级和生命周期状态回答不同问题:
| 字段 | 值 | 含义 |
|---|---|---|
| 关注等级 | OBSERVE、INVESTIGATE、URGENT | 工程审阅需要多快介入。 |
| 状态 | OPEN、ACKNOWLEDGED、RESOLVED | Finding 当前所处运营流程阶段。 |
紧急 Finding 仍需审阅证据并遵守安全维护流程。关注标签不会自动授权现场动作。
审阅四层证据
1. 标准或规则证据
本层展示适用 criterion、grade、观测值和 threshold,代表受治理标准或规则结果。
模型不能改写或替代强制标准结论。标准和模型不一致时,两类证据都应保留并展示。
2. 设备基线证据
本层将当前运行区间与设备自身基线分布比较。需要查看:
- 基线判断;
- 当前水平和分段基线;
- drift;
- 分段天数;
- 对比使用的运行工况。
当区间不可比或历史不足时,基线可以 abstain,不强行给出判断。
3. 模型证据
本层展示执行模式、模型版本、score、score 含义和 runtime 观测时间。
模型 score 是判定信号,不是故障概率。除非另有受治理的概率校准明确支持,不要把 0.8 写成“80% 故障概率”。
SHADOW 模型证据只用于对比,不能创建或修改客户可见告警、健康分、维护建议或 Finding。
4. 数据质量证据
| 状态 | 含义 | 审阅动作 |
|---|---|---|
EVALUABLE | 当前证据满足评估要求。 | 继续工程审阅。 |
NOT_RUNNING | 设备没有处于所需运行状态。 | 不要根据缺少运行证据推断健康。 |
COVERAGE_GAP | 必要数据覆盖缺失。 | 修复或等待缺失区间。 |
SENSOR_SUSPECT | 传感器证据可能不可靠。 | 检查传感器、映射、单位或安装位置。 |
STALE | 最新数据超过允许决策窗口。 | 恢复采集后再把 Finding 当作当前证据。 |
INSUFFICIENT_HISTORY | 基线或持续窗口缺少足够历史。 | 继续采集有效运行历史。 |
UNKNOWN | 服务无法确定质量。 | 按不可评估处理并调查数据源。 |
这些状态不代表健康或零风险。

执行建议检查
Finding 可以保存有限的检查清单,例如:
- 检查轴承和振动测点;
- 检查冷却、润滑和温度传感器;
- 检查受影响测点和运行工况。
这些是审阅步骤,不是根因证明。开展现场工作前,遵守站点安全、许可、隔离和维护流程。
如果没有保存建议检查项,请结合设备档案、信号历史、适用 SOP、近期工作和维护负责人确定下一安全步骤。AI 助手不得编造缺失事实、根因或动作。
将 Finding 连接到行动
在 Finding 详情中,用户可以:
- 打开设备档案;
- 在存在关联记录时打开维护建议;
- 进入巡检或维护流程;
- 记录对 Finding 的人工判断。
维护建议和 Finding 作用不同。Finding 保留证据和关注状态,维护建议记录拟议动作及其运营流程。
记录人工判断
首次反馈事件记录:
| 字段 | 作用 |
|---|---|
| Outcome | 从受治理词表中选择审阅结果。 |
| 判断角色 | 判断来自设备所有者还是服务提供者视角。 |
| Confidence | 审阅人员对人工判断的信心。 |
| Reason | 结构化解释分类。 |
| Note | 补充事实背景,不要添加没有证据的诊断。 |
提交反馈会创建 append-only 事件,不会改写已保存的标准、基线、模型、数据质量或生命周期证据。

请求具有幂等性。使用同一 idempotency key 重复同一请求,不应创建重复反馈。
只有在明确需要时才同步 Transition Evidence
“将判断应用到选中的 transition evidence”默认关闭。
只有当审阅人员明确选择了该判断所支持的待处理设备 transition 时才启用。未选择的 transition 保持不变。一般 Finding 判断不能静默标记所有待处理模型 transition。
更正既有判断
具有 system.config 的用户可以更正之前的判断。更正:
- 需要最新反馈版本;
- 创建新的 append-only 事件;
- 保留原始事件和操作人;
- 记录更正操作人和时间;
- 只对明确选择的 transition 应用变更。
如果保存前 Finding 已发生变化,界面会报告冲突。重新加载最新 Finding 和反馈,审阅新状态后再次提交,不要覆盖其他审阅人员的事件。
没有出现新 Finding 时
没有新 Finding 不自动表示模型没有运行,也不表示设备健康。
按以下顺序检查:
- 打开模型使用详情,检查是否有新鲜
ACTIVE运行证据。 - 确认数据质量状态为
EVALUABLE。 - 检查标准、设备基线和模型证据是否满足受治理融合条件。
- 审阅持续性、滞回和 cooldown 行为。
- 确认目标设备范围已启用 Finding 创建。
- 检查是否更新了已有开放 Finding,而不是创建重复记录。
SHADOW 证据不产生客户可见 Finding,属于正常情况。
故障处理
| 现象 | 检查项 |
|---|---|
| Finding 链接返回不存在 | 当前租户、权限,以及该 Finding 是否仍存在于当前租户。 |
| Finding 无法加载 | 证据服务可用性。重试,但不要把无响应当成健康。 |
| 证据版本不受支持 | 使用兼容客户端或申请平台升级,不要推断健康结论。 |
| 证据不可评估 | 数据质量状态、源新鲜度、运行态、样本数量和最低历史要求。 |
| 无法提交判断 | pdm:write,以及是否已经存在反馈。 |
| 无法更正判断 | system.config 权限。 |
| 保存反馈时报告冲突 | 重新加载并审阅最新反馈版本后再提交。 |
| 同一情况重复出现 | 已有开放 Finding、去重键、持续窗口、cooldown,以及维护结果是否已记录。 |
验证清单
- 设备、目标和租户上下文正确。
- 数据截至足够新鲜,能够支持当前决策。
- 标准、基线、模型和数据质量证据保持分层。
- 没有把模型 score 写成故障概率。
- 没有把缺数或停机写成健康。
- 建议检查被当作审阅步骤,而不是确定根因。
- 人工判断记录事实反馈并保留历史。
- 只有明确选择时才变更 transition evidence。
- 已接受工作进入有负责人的维护或巡检流程。