机器人已经运到现场，大家以为接上电就能开始交付。真正准备开机时，却发现电源位置和方案不一样，网络还没有接通，工装没有到位，任务区域也没有按实际尺寸整理出来。机器人本身没有坏，但当天的联调就是跑不起来。这类情况很容易被当成“现场准备不充分”。可如果机器人到了现场才第一次发现这些条件没有准备好，问题就不只是现场配合慢，而是交付前根本没有把真实运行条件接上。电源、网络、工装和任务区域，不是机器人之外的辅

交付前最后一轮联调，机器人在研发人员手里顺利完成了任务。动作没问题，流程也走完了，大家很容易把这次运行当成“可以交付”的证明。但真正要把机器人交到现场，不能只问“还能不能再跑一遍”。还要确认下面 7 个问题，现场有没有明确答案。这 7 项可以用于发货前、现场验收前和研发人员正式撤场前的关键交付检查。

机器人交付前，经常会出现这样一个场面。研发人员站在控制台旁边，机器人顺利启动、完成任务、回到结束位置。动作没问题，流程也跑通了，现场看起来已经离交付不远。接下来，现场人员第一次自己操作。机器人没有坏，任务也没有立刻失败，但人停在了一个状态提示前：“这个提示是什么意思？现在应该继续，还是先停下来？研发人员走过去看了一眼，很快处理完，机器人继续运行。问题似乎解决了。可这一刻也暴露出一个更重要的问题：此

一张现场调试记录，最后可能只剩下四行：调整线束固定方式。放宽通信超时阈值。临时屏蔽一个输入判断。重新启动后，机器人恢复运行。这四行每一句都是真的，却回答不了一个关键问题：到底是哪一步改变了结果？如果每次改动之后都没有单独观察，最后只能知道“几个动作做完以后，机器能跑了”，却无法判断哪一个因素和原问题有关。这不是简单的记录缺失。真正丢掉的，是临时改动与故障现象之间的因果证据。

一个器件，关键参数满足，典型应用也能对应上，单板验证没有发现明显问题。可放进机器人整机以后，偶发异常还是出现了。单独检查器件，好像没有超出规格；重新翻规格书，也找不到明显错误。现场最容易冒出一个问题：“是不是这个器件选错了？但真正需要重新检查的，可能不只是器件本身。规格书证明了它在规定条件下能做到什么，单板测试证明了它在当前测试环境里可以工作。至于它进入整机以后，能不能接住真实供电、负载变化、线束

机器人项目里，第一台样机调顺以后，团队很容易松一口气。动作能跑了，报警少了，任务也能走完。看起来，原来的问题已经解决。可第二台机器刚开始运行，第一台已经消失的问题又出现了。现场最容易冒出一句话：“第一台不是已经解决了吗？为什么第二台又回来了？但在照着第一台重新调一遍，或者推翻方案之前，团队要先把两台机器放在一起做差异对照。

机器人项目里，很多问题并不是没有记录。软件有更新日志，电气有替代记录，结构有图纸修改，测试有问题单，现场群里也能翻到当时的调试说明。单独看，每一条记录好像都在。但过了几个月，问题又出现时，团队还是会卡住。比如一台机器人又开始偶发掉线。软件翻到一条记录：“优化通信稳定性。电气翻到一条记录：“连接器由原方案替换为新方案。结构记录里写着：“调整线束固定方式。测试问题单显示：“连续运行通过，问题未复现。现

变更闭环不是为了增加流程感，而是为了让机器人项目在系统发生变化后，仍然能够回答三个问题：改动能不能追踪？当前状态能不能还原？工程结论有没有证据？只有这三件事收住，“已经改了”才真正接近“已经闭环”。

机器人项目里，小改动不一定需要完整的大变更流程，但不能没有影响分析。一句“影响不大，先上吧”不能替代工程记录。真正要确认的是：改了什么、为什么改、影响了哪些对象、谁必须同步、哪些验证要重做、能不能回退和追溯。

只有记录变化、分析影响、完成验证、明确去向以后，才会重新回到项目状态。最危险的是第四种状态：没有回退、没有限定试用、也没有正式固化，但现场长期按临时状态运行。工程上真正要避免的，不是“现场临时处理”，而是“现场状态和项目文件分叉”。它可以帮助团队恢复运行、缩小范围、验证假设。最近是否有人临时改过线束、参数、结构、接插件、测试条件或软件判断？限定设备/版本/现场/工况、责任人、观察期限、退出条件。图