同一种报警又出现了。团队先翻问题单。再找当时的测试报告，能看到“通过”，却看不到问题在哪种条件下出现，也看不到中间改过什么。有人想起，这个问题以前确实解决过。问题发生过，工程师也处理过，但项目没有因此变得更会解决这个问题。

测试记录不是越长越好，也不是把日志全文贴进去。真正需要保留的是事实层和判断路径：发生了什么、有没有偏离、是否人工介入、为什么仍然通过、证据在哪里，以及这个结论的边界停在哪里。

测试用例表里，功能项、操作步骤、预期结果一个不少。可真正执行时，问题还是会冒出来：现场条件和用例不一样，还要不要继续？中间人工复位了一次，结果还算不算？机器人停在等待状态，是正常流程还是测试失败？用例并不是没有。真正没有写清的，是不同的人应该怎样执行，又凭什么得到同一个判断。测试用例评审时，至少要追问下面 7 件事。

接着往下问：测的是哪台机器？当时是什么版本？用了什么负载？跑了多久？中间有没有报警、重启或人工介入？回答却开始变得模糊。“当时测试没问题”可能完全真实，也不是在否定测试人员。但当测试对象、条件和证据已经说不清时，这句话几乎无法支持下一步判断。

第一台机器人总装完成后，第一次上电，结构、电气、软件和测试人员往往都围在旁边。动作停了一下，有人知道先看哪个状态；传感器数据不对，有人能马上判断是安装、参数还是标定；任务没有走完，也有人知道下一步该改哪里。在这些熟悉项目的人共同盯守下，第一台终于跑顺了。接下来做小批量时，现场很容易说一句：“后面照着第一台做就行。可真正的问题是：做到第十台时，原来那几个人还能不能继续守在每一台机器旁边？

机器人现场换完一个部件，报警消失，任务也重新跑通。新件留在机器人上，换下来的旧件被顺手装进袋子，放到一旁。有人问了一句：“这个已经确认坏了吗？现场常见的回答是：“换完以后正常了，应该就是它。可过几天再打开那个袋子，问题往往更多：它从哪台机器人、哪个位置拆下来？当时是什么现象？有没有单独确认过？现在是故障件、待分析件，还是还能继续使用的备件？如果这些都说不清，它就会变成一个只知道“被拆下来”，却不知

机器人出现偶发掉线，现场怀疑线束，于是换了一根新线。换完以后，通信恢复，机器人也能继续运行。可再跑一段时间，现象却变了：原来只在某个姿态掉线，现在另一段动作也会报警；原来重启后能稳定很久，现在问题出现得更频繁。但这个结论可能下得太早。因为现场说“换了一根线”，实际往往同时做了几件事：重新插拔连接器，改变走线路径，调整固定点和预留长度，再让机器人重新运行。换线看起来只替换了一个零件，实际往往同时改变

复装后检查什么最低确认结果线束路径走向、固定、受力和运动余量明确连接器接口、锁止、接地和尾部受力确认结构关系位置、间隙、防护和运动空间仍然成立标定关系原标定前提仍成立，或已重新确认配置状态当前实物实际加载的配置明确复测范围原问题触发条件和拆装差异得到覆盖这张表不是要求所有状态必须恢复原样。维修过程中可能使用新的部件、走线方式、参数或处理方案。真正要确认的是：哪里发生了变化，为什么可以继续使用，以及

机器人修完当天，一切正常。换上部件，重新上电，报警消失，动作也恢复了。可过了几天，机器人又在另一种姿态或连续运行时出现异常。这次的现象和原来的故障还不完全一样，排查反而更难了。大家的第一反应通常是：“上次是不是根本没修好？但还有一种可能更容易被忽略：原来的故障确实已经处理，维修动作却同时改变了机器人后续运行所依赖的一些条件。现场确认了“现在能跑”，却没有说清“修完以后，它和维修前到底哪里不一样”。

交付收尾会。测试报告、培训记录、验收表和操作说明都摆在桌上。会议室突然安静下来。功能已经跑通，资料也发过，现场人员还参加了培训。但继续往下问，答案并不轻松：现场工装换一种摆法还能不能跑，操作人员不确定；出现某个报警能不能自行恢复，没人敢确认；换过一根线以后怎样判断状态恢复，仍要找研发。机器人已经到了交付节点，真正需要交出去的能力却还留在原团队手里。交付不是把一台能跑的机器人推过终点线，而是把它继续