交付前最后一轮联调，机器人在研发人员手里顺利完成了任务。

动作没问题，流程也走完了，大家很容易把这次运行当成“可以交付”的证明。

但真正要把机器人交到现场，不能只问“还能不能再跑一遍”。还要确认下面 7 个问题，现场有没有明确答案。

这 7 项可以用于发货前、现场验收前和研发人员正式撤场前的关键交付检查。

1. 现场条件，是否已经进入验证范围？

演示环境通常被提前整理过，现场却会有真实的地面、光照、空间、电源、网络、障碍物、人员走动和任务节拍。

不需要把所有现场变化都提前猜完，但要把会影响任务的条件列出来，至少在接近真实的工况下跑过一次。

如果机器人只在干净、固定、有人照看的条件下通过，就还不能证明现场真实条件已经进入验证范围。

交付前先确认：这次验证覆盖的，究竟是演示环境，还是现场真正会遇到的环境？

2. 现场人员，能不能独立完成一次任务？

研发人员会操作，不等于现场人员可以接手。

现场人员是否知道启动顺序，能不能看懂状态提示，报警后知道先停在哪里，任务暂停后知道怎样恢复？这些都不应只靠研发人员口头提醒。

交付前，让没有参与研发的人独立完成一次启动、任务执行、暂停和恢复。研发人员只观察，不口头提醒，把停顿点、误操作点和看不懂的提示记下来。

3. 验收条件，能不能让双方按同一个口径判断？

“功能正常”不能直接当成验收标准。

至少要说清楚：什么工况下运行，谁来执行，用什么方法判断，做到什么程度算通过，允许多少人工介入，失败和恢复怎样记录。

这些内容如果只停留在会议上的口头约定，研发、测试和现场很容易各自记住一套标准。

交付前要确认的，不是有没有验收文件，而是现场人员能否执行，交付双方能否按同一个口径判断。

4. 异常出现后，现场知道先停、怎么恢复吗？

现场不会只跑成功路径。

通信中断、识别失败、误报警、任务暂停和急停，都可能让机器人停在一个需要判断的状态。

交付前不必把所有故障都演一遍，但至少要选几种可能影响任务或安全的异常，让现场人员真正处理一次，并确认何时停止、怎样恢复、恢复后从哪里继续。还要说清哪些异常可以自行恢复，哪些情况必须停止任务并升级确认。

资料里写着“支持异常处理”，和现场人员真的处理过一次，是两回事。

5. 问题发生后，留下的信息够不够后方继续判断？

现场最容易留下的一句话是：

“刚才确实异常了一下，但现在又好了。”

如果没有时间点、任务状态、软件和参数版本、操作动作以及恢复结果，后方团队很难判断到底发生过什么。

交付前要确认：现场遇到问题时，能不能留下足以让后方团队继续判断和定位的最小记录。最小记录的标准，不是“现场写过了”，而是后方团队拿到以后还能继续判断。

6. 维护和复装，现场能不能独立完成？

机器人交付以后，清洁、检查、换件、复装、重新标定和问题反馈都会变成日常工作。

先要说清哪些部件允许现场检查或更换，哪些情况必须停止处理并联系研发或专业维护人员。

还要看关键部件能不能接近，连接器能不能安全插拔，线束复装有没有明确要求，维护后有没有简单而可靠的复测方法。

如果每次处理问题都要临时拆装，或者复装后只能等研发回来确认，设备虽然到了现场，维护能力却没有交过去。

7. 资料和现场实物，是不是同一个状态？

图纸、BOM、软件版本、参数、测试记录、操作说明和维护说明，必须和现场实际状态一致。

最麻烦的不是资料少，而是资料之间互相对不上：现场按旧说明操作，测试按旧条件验收，维护按旧图纸拆装，研发再拿另一套版本判断问题。

交付前最后要核对的，是资料能不能指向现场这台机器人，而不是文件夹里有没有资料。

七项检查结束后，最低要留下什么？

检查项	交付前最低要留下什么
现场条件	已验证工况、未覆盖条件和关键环境边界
独立操作	操作结果、停顿点、误操作点和待补说明
验收条件	工况、执行方法、通过标准和人工介入边界
异常恢复	停止条件、可自行恢复的范围、必须进一步确认的情况、恢复步骤和任务起点
问题回溯	时间、任务状态、版本、操作动作和恢复结果
维护复装	可维护对象、复装要求和维护后的复测方法
资料状态	现场实物版本、对应资料版本和未关闭差异

功能跑通，只是交付准入的一部分

回到最开始那次联调：机器人在研发人员手里跑完任务，只能证明一条受控路径成立。

真正接近交付，还要看现场条件、操作者、验收口径、异常恢复、问题回溯、维护入口和资料状态能不能接上。

这 7 项不是为了增加一套复杂的交付流程，而是帮助团队在发货、验收或研发撤场前，确认最基本的现场使用条件已经具备。

研发人员不在旁边时，现场是否仍然能够使用、判断、恢复和反馈？

我是「机器人落地派」。机器人交付前，你最常遇到的是哪一项没有被接住？