机器人交易资料里的文件摘要与事实证明：校验相同说明了什么

二手机器人交易资料中，“摘要”可能指一段文字概述，也可能指文件计算得到的哈希值。阅读核验说明时，先分清使用的是哪一种含义。本篇讨论的是后者：文件摘要、来源记录与文件内容中的声明各自回答什么问题。核对摘要有用途，但不能从一次匹配直接推导卖家的身份、文件的形成过程或设备的实际状况。

先问摘要怎样得到，而不是先问它代表谁

NIST 的哈希函数介绍说明，哈希算法把消息映射为固定长度的摘要。这里的摘要是计算结果，不是一位编辑写出的内容提要。因此，看到一串摘要值时，应先确认算法、输入对象与比较方式。它究竟对应整个文件，还是资料中另外定义的一部分？没有这些说明，单独的字符串很难支持明确的核验结论。

交易双方可以记录比较所针对的文件和各自取得参考值的方式。这是本文的资料整理建议，不是声称 NIST 为每笔交易规定了固定流程。记录的目的，是让后来的人能够理解“我们比对了什么”，而不是只看到“校验通过”四个字。参考值本身从哪里取得，也应保持可追查；收到的文件和同时收到的摘要，都可能只是对方提供的材料。

摘要匹配与字节相同之间保留算法条件

NIST 对抗碰撞性的说明涉及这样一种性质：在计算上难以找到不同输入却产生相同哈希的情况。这不是说任何被称为哈希的算法都拥有同样的安全性，更不是说匹配在数学上排除了不同输入。资料里应标明采用的方法，而不要把不同算法、不同输入范围下的比较混在一起。

一个匹配结果可以成为完整性核对的线索，但它不单独识别作者。持有同一个文件的人能够对该文件做计算；计算结果中没有自动附带其身份的证明。同样，发现摘要不同可以提示比较结果不一致，却不说明变化由谁造成、是否经过授权，以及具体哪一项内容发生了变化。这些问题需要另外的记录或内容对照。

来源记录把关系写出来，也留下核验问题

W3C PROV 入门文档介绍实体、活动与代理，用来描述来源关系。用于交易资料阅读时，可以把保存的文件作为一个实体，把导出、整理或交接过程作为活动，再说明负责的主体。这为“哪份材料与哪个过程有关”提供了表达方式。

但是，填写关系不等于已经独立验证关系。若说明中写着文件由某设备导出，读者还可以询问依据是什么、是否指向正在讨论的设备，以及描述覆盖哪个环节。资料没有给出的信息，应保留为待核对事项。阅读本站技术栏目时，也可以沿用这个问题顺序，而不把通用概念介绍视作某次交易的来源证明。

文件中写下的结论需要自己的支持材料

即使确认收到了与某个参考值相匹配的文件，也只是推进了对这份材料的核对。文件正文可能含有设备状态、测试结果或维护情况的声明。那些声明是否得到支持，要看它们引用的观察、条件与材料，而不是看文件有没有摘要。完整地收到一句话，与这句话成立，是两件不同的事情。

可以把阅读笔记分为三行：文件原文声称什么；当前提供了什么支持；还有什么没有核实。这样既不会因为缺少信息就武断认定材料虚假，也不会因为文档格式整齐就自动认可结论。本文不判断任何实际卖家、设备或交易文件的真实性，也不依据摘要作法律效力的结论。

用明确措辞保留已经完成和仍未完成的部分

比起写“资料已证明无误”，更清楚的记录应描述实际完成的动作：比较了哪些输入、观察到什么结果、依据哪份来源说明。若只完成文件层面的比较，就不要替未进行的设备检查写结论。若另有来源证据，也应注明它支持的是身份、过程还是具体内容，不让不同层次的材料互相代替。