交付收尾会。测试报告、培训记录、验收表和操作说明都摆在桌上。

项目负责人问了一句：

“研发下周撤场，现场自己运行，还有哪些事离不开你们？”

会议室突然安静下来。

功能已经跑通，资料也发过，现场人员还参加了培训。但继续往下问，答案并不轻松：现场工装换一种摆法还能不能跑，操作人员不确定；出现某个报警能不能自行恢复，没人敢确认；换过一根线以后怎样判断状态恢复，仍要找研发。

机器人已经到了交付节点，真正需要交出去的能力却还留在原团队手里。

交付不是把一台能跑的机器人推过终点线，而是把它继续运行所需要的条件、判断、操作和支持，交到现场手里。

这些能力不是交付现场临时增加的工作，而应从需求阶段开始定义，在设计、验证和交付过程中持续确认。走到研发撤场这一步，至少有这 5 条线需要现场接住。

第一条：场景条件线，要把“在哪里能跑”交清楚

需求里写“现场使用”，研发阶段却可能一直在固定电源、稳定网络、标准工装和熟悉人员的条件下验证。

到了交付现场，位置、物料、负载、任务区域或接口方式一变，原来的功能结论就可能需要重新确认。

所以这条线交出去的，不只是一份环境要求，而是三个结果：哪些真实条件已经验证，哪些差异可以接受，哪些条件仍未覆盖。

只有让现场知道机器人在什么边界内可以完成任务，才不会把一次演示成功理解成所有条件下都能运行。

第二条：验收证据线，要让同一个结果得到同一个判断

机器人完成了任务，研发说通过，现场却认为人工介入以后不能算。问题往往不在机器人有没有动作，而在各方依据的不是同一套判定规则。

验收证据线要把需求里的目标，一直连到现场能够共同确认的结果：在什么工况下执行，谁来操作，怎样算通过，异常或人工介入以后原结果是否有效。

交付时不能只留下“测试通过”四个字。还要让后来的人能够看懂：当时按什么条件测、得到了什么结果、出现过哪些偏差，以及为什么作出这个结论。

证据不是为了把报告写厚，而是为了让交付结论不随解释的人变化。

第三条：操作交接线，要把个人经验变成现场能力

研发人员能把机器人跑起来，可能依赖很多没有写出来的判断：看到哪个状态可以继续，遇到什么提示先等待，哪一步可以复位，哪种情况必须停下来。

这些判断如果只存在于熟悉系统的人脑中，培训结束也不代表交接完成。

更直接的验证，是让没有参与研发的人按照现有资料独立完成一次任务。研发人员先不站在旁边提醒，也不替操作者补充下一步。操作者停在哪里、误解了什么、哪一步必须靠口头补充，都会暴露能力还留在谁手里。

操作交接线真正要交出去的，是现场能够看懂当前状态、知道下一步能做什么，也知道什么时候不能继续。

第四条：异常接管线，要让现场知道“出事以后怎么办”

成功路径通常演示很多遍，异常路径却容易留到交付以后再处理。

机器人一旦暂停、报警或任务中断，现场最先需要的不是完整根因分析，而是几个明确边界：什么时候必须停止，哪些情况可以自行恢复，哪些情况需要升级确认，恢复后从哪里继续。

同时，现场还要能把时间点、任务状态、版本、操作动作和恢复结果传回后方。否则研发接到的仍然只有一句“刚才不动了，现在又好了”。

异常接管线不是要求现场解决所有故障，而是让问题发生后有人能先稳住现场、保留信息，并把超出能力范围的问题交给正确的人。

第五条：维护支持线，要让设备离开研发后还能继续用

异常接管解决的是问题刚发生时现场怎样稳住；维护支持继续回答设备后续怎样处理、恢复并长期使用。

交付以后，清洁、检查、换件、复装、配置更新和状态确认会逐渐变成日常工作。

现场要知道哪些对象允许处理，从哪里获得状态信息，处理完成后怎样确认机器人重新具备运行条件。超出现场能力时，也要有明确的支持入口，而不是临时翻通讯录寻找某个熟悉设备的人。

维护支持线交出去的不是“以后有问题再联系我们”，而是一条可以持续使用的路径：现场先看什么、能处理到哪一步、需要带着什么信息寻求支持、处理后怎样确认恢复。

五条线，不是五份文件

这 5 条线很容易被做成五类资料，最后继续留在文件夹里。

更有效的做法，是在研发撤场前画一张简单的“交付接管图”。每条线只回答三个问题：

1. 这项能力最终由谁接住？

2. 现场凭什么判断自己可以继续？

3. 目前没有接住的部分，准备调整现场、补充验证、限定运行，还是暂缓交付？

如果某一行仍然只能写“问研发”，它就还没有真正交出去。

交付不等于所有问题都已经消失，而是已知边界有人判断，剩余问题有人接管。真正重要的是，正常运行有人会用，验收结果有人会判，异常发生有人能接，维护以后有人能确认，超出边界的问题也知道交到哪里。

一台机器人真正交到现场，不是因为研发完成了最后一次演示，而是研发离开以后，这 5 条线仍然有人接得住。

我是「机器人落地派」。

研发准备撤场时，你们最容易发现哪条线还没人接住？