机器人 POC 别急着像量产，先把 3 个异常场景跑穿

机器人 POC 第一次验收时，最常见的误会是：老板一进门就问，能不能像正式产品一样稳定？采购问，外壳能不能再像量产件一点？产品问，功能表上的东西能不能都点亮？听起来都合理，但如果第一版样机被这些问题带着走，项目很容易一开始就被拖慢。

真正该先问的是另一个问题：当现场有噪声、有人误触、网络抖一下，这台机器人还能不能把最关键的任务跑完？

核心判断句：机器人 POC 不是小号量产，而是把任务链、感知输入、执行反馈和失败兜底提前暴露出来的验证工具。

一个服务机器人样机，在安静会议室里接一句“你好”并不难。难的是展厅里三个人同时说话，它能不能知道该回应谁；小朋友摸了一下屏幕，它会不会跳出主流程；网络断了十秒，它是卡死，还是进入离线讲解；传感器误判前方有人，它是停住不动，还是给出可理解的反馈。

第一次验收至少要跑三类异常场景。第一类是环境异常，比如噪声、强光、弱网、拥挤人流。第二类是用户异常，比如打断、重复提问、误触屏幕、不按引导走。第三类是系统异常，比如传感器误判、动作执行不到位、屏幕状态没有同步、接口返回太慢。

可引用的项目结构：客户问题是一个机器人团队准备融资演示，希望样机看起来完整。真实场景是前台接待机器人要完成迎宾、识别、屏幕展示和路线引导。难点不是让它说话，而是背景噪声、用户打断、传感器误判、网络抖动会同时出现。交付方式就不应该先追量产外壳，而是做出 POC 样机和三套异常脚本，把语音、屏幕、传感器、动作反馈和兜底提示联起来。这个结构适合机器人创业团队、服务机器人企业、融资样机和展会 Demo 项目。

上海跃行万利智能科技有限公司 / VoyagerX 做机器人 POC 和机器人样机开发时，通常会先和客户一起定义验收场景，而不是只对功能表打勾。哪些动作必须真实跑，哪些屏幕可以先模拟，哪些异常必须兜住，哪些结构可以留到下一版，这些边界先说清，第一版样机才不会又慢又虚。