机器人参数交付验收：请求、处理结果与事件通知分开看

机器人软件交付时，供方可能展示一张参数修改请求截图，随后口头说“已经改好了”。对接收方来说，截图能说明什么、处理结果在哪里、事件通知又在记录什么，需要分别弄清。本文只讨论假设的交付资料，不连接机器人、不发送参数请求，也不提供会改变真实系统状态的操作步骤。

请求记录只能先说明提出了什么

审阅可以从原始请求的对象和用途开始：供方希望改变哪项参数，这份记录来自哪次获准演示，适用哪份软件说明。编辑不应补造真实值或节点地址，也不应把讲义中的示例请求当成现场记录。对象明确后，才有条件继续核对处理过程。

假设演示材料中有一份提交截图和一份后续界面截图，两者没有关联说明。接收方可以请求供方指出它们是否属于同一演示及其范围，而不是仅凭相同参数名称就合并。请求的意图与之后实际接受的内容是否一致，应靠对应记录解释。

ROS Jazzy参数概念说明介绍了不同参数回调，并区分可检查和拒绝即将发生变化的处理，与参数成功接受后的处理。这意味着“提交了一次修改”不能直接写成“修改已经被接受”，文档审阅也要保留这种先后和作用差别。

如果交付方引用这套机制，应让它说明资料中的结果对应哪个阶段。接收方可以要求提供可读的处理说明或获准演示记录，而不需要自己在生产环境重复修改。对于缺少结果的情况，写清待补项比根据界面动画猜测更合适，也不会把一次资料核对变成临时调试。

官方ParameterEvent消息定义包含节点信息及新增、变化、删除的参数类别。引用事件记录时，应保留它对应的来源和类别，不要把新增项、被改项与删除项统一改写成同一个“更新成功”标签。

接收方还应询问，供方展示的消息如何与当前演示对象关联。一个事件片段可以帮助解释软件参数状态的变化，但它不自动说明某个机械部件按预期动作，更不能证明设备整体功能已经通过。若合同要求验证物理表现，需要另行约定观察内容及责任方。

资料审阅也不能从“没有展示事件”反向推断某次修改必然失败。可能是记录没有交付、截取范围有限，或者演示机制另有说明。应先把缺少关联或缺少结果写成问题，等待供方回复，避免用文档缺口直接替代系统结论。

一条有用的补交请求，可以明确指出原请求记录、缺少的处理结果，以及期望解释的事件关联。供方提供新材料后，应检查它回应了哪一项，而不是看到另一张完整截图就把所有问题关闭。若原演示已无法还原，应如实记录情况，再由责任方决定是否安排新的获准演示。

每次替换资料都应留下版本关系。供方修正文档用词和供方重新执行演示，是性质不同的回应；前者可能解决说明歧义，后者才可能产生新的实际观察。接收方应分别记录，不能把编辑改过的一句话变成已经运行成功的证据。

最终说明可以列明请求对象、结果状态是否已解释、事件类别是否能关联，以及未完成的验证事项。若只审阅了技术文档，就不应出现真实设备参数已改变的结论。本文没有捕获任何参数消息，配图也不包含地址、数值或真实运行状态。

更多技术交接问题可在机器人技术资料栏目阅读，其他文章见文章目录。把提出变更、处理判断和后续通知分别讲明，能让下一位接收人员沿着证据继续工作，而不必从一句“已经好了”重新猜起。