机器人交付前，经常会出现这样一个场面。

研发人员站在控制台旁边，机器人顺利启动、完成任务、回到结束位置。动作没问题，流程也跑通了，现场看起来已经离交付不远。

接下来，现场人员第一次自己操作。

机器人没有坏，任务也没有立刻失败，但人停在了一个状态提示前：

“这个提示是什么意思？现在应该继续，还是先停下来？”

研发人员走过去看了一眼，很快处理完，机器人继续运行。

问题似乎解决了。

可这一刻也暴露出一个更重要的问题：此前反复验证的，是熟悉系统的人能不能把机器人跑起来；现场交付要面对的，却是不熟悉系统的人能不能独立使用。

演示结束以后，操作的人、判断的标准、异常的处理方式和后续维护责任都开始变化。很多项目真正暴露交付问题，也正是从研发人员第一次准备松手开始。

研发人员一松手，操作问题才真正出现

演示时，最熟悉系统的人通常就在旁边。

他知道启动后应该等多久，哪个提示只是过程状态，哪个报警需要先复位。流程有一点不顺，也能凭经验把任务继续往下带。

这些动作做得太自然，团队很容易忽略：机器人之所以跑得顺，有一部分能力其实在研发人员身上。

换成现场人员以后，那些没有写进界面、步骤和提示里的经验，就会突然变成问题。

交付前，最好让没有参与研发的人独立跑一遍。研发人员先不要在旁边提醒，只观察他在哪里停下来、看不懂什么、遇到异常时先做了什么。

这一步不是考现场人员会不会操作，而是在检查系统有没有把使用条件说清楚。

操作问题只是第一道交接。任务真正进入验收以后，第二个分歧很快就会出现：大家对“跑通”的理解并不一样。

验收一开始，“跑通”就有了不同解释

研发人员完成的是一条提前准备过的任务链路。

路线怎么走，物料怎么放，什么时候开始，什么时候结束，团队心里都有数。

到了验收环节，现场关心的问题却变了。

任务中途需要人工调整一次，还算不算通过？

出现报警后恢复运行，这次结果是否有效？

连续运行中有一次失败，应该看单次结果，还是看整段任务？

研发团队觉得“功能已经跑通”，现场可能觉得“还不能独立使用”，测试人员则发现通过条件没有说清。

争议不是因为谁故意提高要求，而是大家此前看到的是同一场演示，心里记住的却不是同一个交付标准。

所以演示通过以后，不能只是把同一套动作再跑一遍。还要把它变成现场人员能够执行、交付双方能够共同判断的验收条件。

什么工况下运行，做到什么程度算通过；允许多少人工介入，失败和恢复又怎样记录。

演示回答的是“这条任务链能不能走完”。

验收回答的是“在什么边界下，大家都承认它走完了”。

第一次异常出现，现场才知道自己能不能接住

演示会尽量展示机器人正常工作的一面。

场地提前整理，网络和电源提前确认，任务流程预先跑过，研发人员也在旁边盯着。这很正常，演示本来就应该让大家看到系统的正向能力。

但交付不能只留下成功路径。

当通信短暂中断、识别失败、任务暂停或者急停被按下，现场马上会遇到另一组问题：当前状态是否安全，能不能直接重试，需要先复位什么，恢复以后从哪里继续。

很多机器人不是因为不会运行而卡住，而是在异常以后，现场没人知道下一步应该做什么。

这时最容易听到的一句话是：

“机器人不是不能跑，但研发不在旁边，我们不知道该怎么恢复。”

如果每次异常都要等研发人员接手，演示里的顺利运行就还没有变成现场的使用能力。

交付前不必把所有故障都演一遍，但至少要选择几种可能影响任务或安全的异常，让现场人员真正处理一次，并确认他们知道何时停止、怎样恢复、需要留下什么信息。资料里写着“支持异常处理”，和现场人员真的处理过一次，是两回事。

研发人员准备离场，维护问题才冒出来

演示前，设备通常已经被准备到较好的状态。

线束整理过，电池充好了，标定确认过，软件版本也有人盯着。

研发人员准备离场时，现场人员又问了一句：

“这根线以后如果换过，装回去以后怎么确认机器人状态有没有恢复？”

这时团队才发现，演示前一直由研发人员准备设备，现场真正需要接手的却不只是启动和操作。

机器人进入长期使用以后，清洁、检查、换件、复装、重新标定和问题反馈，都会逐渐变成日常工作。

这时候现场才会继续追问：哪些部件可以更换，拆开以后怎么装回去，复装后怎样确认状态恢复，问题反馈给谁，需要带上哪些记录。

这些问题不一定在交付当天全部出现，却决定了研发人员离场以后，机器人还能不能继续运转。

如果每次换件、复装或版本更新都要把原团队叫回来，设备虽然已经放到现场，交付压力却只是被推迟了。

交付不能只安排“怎么开始使用”，还要留下“以后出了问题怎么继续使用”的入口。

演示结束后，交付才真正开始

回头看这个常见的交付过程，机器人始终没有出现一个足以证明方案完全失败的大故障。

真正让交付变难的，是研发人员一松手，原来被经验补上的问题开始逐个出现：现场人员不确定怎么操作，双方对通过标准理解不同，异常恢复仍然依赖研发，维护也还没有明确接手方式。

演示证明的是，机器人在一组受控条件下能够完成任务。

交付要回答的却是：研发人员离开以后，现场还知不知道怎么操作、怎么判断、怎么恢复，以及出了问题以后该把什么信息交回来。

真正的交付，不是研发人员把机器人跑完最后一次，而是研发人员不再站在旁边时，现场仍然能够把它继续用下去。