用来源模型整理报修记录：把现象、人员与设备过程分开写

在机器人故障报修与维护记录的实际工作里，一条可用的记录不能只写“设备坏了”或“提示异常”。真正能支撑后续诊断、责任划分与复查的记录，需要把“发生了什么现象”“谁在什么时间做了什么”“涉及哪台设备与哪个部件”“依据什么来源形成判断”分开表达。本文结合 W3C 的两份参考文档所提供的模型思路，说明如何在本站的报修场景中组织事实、日期、适用范围与编辑推断，避免把现场描述、维护动作和来源证据混为一谈。

把“现象”当作被记录的实体，而不是结论

PROV 模型入门文档提出，来源信息描述的是产生某件事物或数据所涉及的实体、活动、人员与过程。参见 PROV Model Primer。在机器人报修中，“温度提示”“通信异常”“制动系统提示”首先应被当作被观察的实体或状态，而不是已经定性的故障结论。例如现场人员看到控制面板给出某类提示，应先记录提示文本、出现时间、任务阶段与运行环境，再将其归入具体的设备类型页面，如 /type/14.html 所覆盖的类别下，便于按设备族检索。把现象和结论分开，能防止后续维护人员把初始提示误当作最终根因。

区分活动、使用与生成：谁动了设备、用了什么工具

PROV 还区分“活动”“使用”与“生成”。放到维护场景里，巡检、复位、更换模块、导出日志都是活动；使用的工具、备件、检测仪器是被使用的实体；而新的日志、维修工单、测试结果是活动生成的数据。编辑在整理记录时，应写明某次维护活动由谁执行、起始与结束时间、调用了哪种检测方式、产生了哪些新记录。这样整理出的时间线不是单纯按报警时间排序，而是把动作链条写清楚。若某次操作涉及底盘或移动相关类型，可在记录中关联 /type/25.html 的分类说明，让动作与设备范围对应。

用目录词汇描述“维护记录集合”的适用范围

DCAT 第三版是用于在网络上描述数据集与数据服务的 RDF 词汇，它让不同目录之间能够用标准模型交换元数据。参见 Data Catalog Vocabulary (DCAT) - Version 3。本站虽然不是通用数据目录，但“故障报修与维护记录”本身可被视为一种受管理的数据集合：每条工单、每次保养、每批日志导出都有自己的适用范围，例如仅适用于某类机型、某个时间段或某个现场条件。用类似 DCAT 的思路去声明“这份记录覆盖哪些设备、不包含哪些情况”，可以减少读者把单条经验误用为全局规则。对于传感器或环境相关类别，可指向 /type/17.html 的说明页面，限定适用边界。

日期与版本：记录何时形成、何时修订

PROV 入门文档强调时间在来源模型中的作用，而 DCAT 3 也加入了版本、前一版本、当前版本等属性来描述数据集演变。维护记录同样需要区分“现象发生时间”“报修提交时间”“记录最后修订时间”。三者不一致是常态：现场先看到异常，几小时后填写工单，复查时又补充诊断结论。编辑应在片段中标注日期，并说明该日期属于哪一类。若记录后续被更新，应保留旧版本指向，而不是直接覆盖，使复查者能看到信息如何变化。这里不提供具体事故数据，仅说明整理方法：每条记录至少要有现象时间、录入时间和修订标记三个层次。

把来源证据与编辑推断明确分开

本站栏目定位要求把事实、日期、适用范围和来源与编辑推断分开。W3C 的来源模型提醒我们，判断信息是否可信需要知道它如何产生；DCAT 则要求声明目录与数据集的元数据以便消费。对应到写作中，凡是来自现场输入、设备输出、工单字段的内容，应标为事实层；凡是整理者补充的“可能原因”“建议检查顺序”“归类方式”，必须写为推断层。举例来说，不能写“通信异常就是某模块损坏”，而应写“现场记录到通信异常提示；编辑推断需进一步核对代码与涉及设备，参见设备类型整理”。这样既不虚构根因，也不把推断伪装成原始证据。

建立可交接的记录结构：从单条报修到可检索集合

维护资料交接常遇到的问题是：诊断需要细节，但访问范围又受权限约束。参考 PROV 对实体、活动、代理与责任的划分，以及 DCAT 对数据集可发现性的设计，本站建议每条报修片段包含：设备类型链接、现象描述、时间三元组、执行活动、生成结果、来源标记与推断标记。多个这样的片段再通过 /type/14.html、/type/25.html、/type/17.html 等内部分类聚合，就能形成既能按机型检索、又能保留原始上下文的集合。假设示例：某 hypothetical 维护记录写“2026-10-28 录入，现象时间早于录入，适用于某类移动底盘巡检场景，非全部机型”，这便是把日期层次与适用范围写清的示范，而不是泛泛而谈“设备请注意”。通过这种方式，故障报修与维护记录才能既服务当下诊断，也支持后续复查与责任追溯。