机器人项目里，很多故障第一次被记录下来时，描述都很像：“偶发掉线”“运行中停了一下”“刚才报了个错，重启后好了”“不知道是不是现场干扰，后面又正常了”。
这些描述不是没有价值。它至少说明问题确实发生过，现场也确实看到了异常。
但从工程排查角度看，这还不够。
因为它只记录了“发生过”，没有记录“在什么条件下发生”。而机器人系统里的很多问题，恰恰不是单独由某一个时间点触发的，而是和任务步骤、系统状态、环境条件、供电通信、人工操作、历史变更一起叠加出来的。
所以故障复现最怕只问一句：
“什么时候坏的？”
时间当然重要，但只知道时间点，很容易把系统问题看成单点故障。更关键的是要问清：当时机器人正在做什么，系统处于什么状态，前后发生过什么操作，外部环境有没有变化，供电和通信有没有波动，日志证据能不能对上，最近有没有改动。
我现在看偶发故障记录，会重点追问下面 7 个条件。
第一，任务走到哪一步？
先不要急着判断是机械、电气、软件还是控制问题。要先问清楚：故障发生时，机器人正在执行什么任务？任务走到了哪一步？
是在启动、识别、导航、避障、抓取、放置、返回、暂停，还是恢复？上一条指令是什么？下一步原本应该发生什么？异常是出现在动作开始前、执行中、状态切换时，还是任务结束后？
很多机器人故障并不是完全随机出现，而是藏在某个任务步骤、某个状态切换，或者某个动作衔接里。如果任务步骤说不清，后面很容易只剩一句“跑着跑着就停了”。这句话对现场描述有用，但对复现和定位帮助有限。
第二，各模块当时是什么状态？
复现故障时，不要只问“有没有报警”，还要问系统当时认为自己处于什么状态。
硬件状态是什么？软件状态是什么？控制状态是什么？任务状态是什么？安全状态是什么？这些状态是否一致？
机器人联调里，很多问题不是某个模块完全坏了，而是系统状态不同步。比如软件认为任务还在执行，控制侧已经进入等待；控制器认为驱动准备好了，驱动侧实际还在故障恢复；上位机显示任务暂停，但底层还有模块没有完成状态切换。
每个模块单独看都可能说得通，但放到系统里，状态已经不一致了。所以复现故障时，要特别关注一个问题：
当时各模块说的“正常”，是不是同一个正常？
第三，故障前后发生过什么操作？
很多偶发故障不是凭空出现的，而是和“刚刚发生过什么”有关。
比如刚刚急停过，刚刚恢复过，刚刚重启过某个模块，刚刚插拔过连接器，刚刚换过参数，刚刚切换过任务模式，刚刚人工拖动过机构，刚刚换过工装或负载。
这些操作如果没有记录，故障看起来就像突然出现。但往前追，可能是前一个状态没有清干净，恢复流程没有闭合，某个模块重启后状态没有同步，或者人工操作改变了机器人当前条件。
尤其是“重启后好了”“复位后正常”“重新插拔后恢复”这类现象，更要谨慎。它可能说明问题暂时消失了，也可能说明关键证据已经被清掉了。
第四，环境条件有没有变化？
机器人问题不能只在软件日志里看，还要放回真实环境里看。
地面是否平整，光照是否变化，有没有遮挡，温度湿度是否变化，电磁环境是否复杂，人员是否频繁走动，空间是否狭窄，负载是否变化，周围设备是否同时启动，这些都可能影响系统表现。
有些问题在实验室里复现不了，到了现场却反复出现，不一定是现场“玄学”。更常见的情况是，复现条件里少了环境变量。
如果环境条件没有被记录，团队很容易把现场问题误判成软件不稳定，或者把真实环境差异当成偶发现象。
第五，供电和通信有没有波动？
偶发故障出现时，很多团队会先看软件日志。软件日志当然要看，但不能只看软件日志。
机器人系统里，很多“软件看起来异常”的问题，源头可能在供电、接地、线束、连接器或通信链路。
要问清楚：电源有没有瞬时跌落？驱动有没有短暂报警？通信有没有超时、丢包、重连？网络延迟是否突然变大？总线负载有没有变化？某个动作发生时，负载是不是突然上来了？
尤其是“低速正常，高速异常”“空载正常，带载异常”“实验台正常，装进整机异常”这类问题，更不能只看上层日志。上层日志看到的可能只是结果，底层供电和通信波动才是触发条件。
第六，日志和证据能不能对上时间？
有日志，不等于有证据。
关键要看这些记录能不能对上同一条时间线。机械、电气、控制、软件、传感器、上位机、测试视频，各自有没有时间戳？时间戳是否同步？故障发生前后，能不能看出谁先异常、谁后报警、谁切了状态、谁执行了恢复？
排查方向往往取决于先后顺序。到底是传感器数据先跳变，还是控制指令先超时？到底是驱动先报警，还是软件先切状态？到底是通信先掉线，还是电源先波动？这些判断不清，团队就只能靠经验猜。
很多偶发问题之所以难查，不是完全没有日志，而是日志之间对不上时间。每个系统都有记录，但拼不成一条完整证据链。
第七，最近有没有改动？
复现故障时，最近有没有变更，是很值得单独追问的一项。
软件版本有没有变？参数有没有变？线束固定方式有没有变？连接器有没有换过？传感器安装位置有没有调整？结构件有没有改动？驱动器配置有没有更新？测试场景有没有变化？操作流程有没有被临时调整？
很多问题不是“突然出现”，而是某个小改动改变了系统边界。
这些改动单独看都不大，但机器人是多学科耦合系统，小改动很容易牵出一串影响。如果没有变更记录，后面很容易把“改动引入的问题”，当成“系统随机出现的问题”。
一张简单的复现记录清单
故障复现不一定一开始就能找到根因，但至少要把条件记录完整。
如果要把这篇压缩成一张现场检查表，可以先用下面这张。
这张表不一定能立刻定位问题，但它能让团队少走很多弯路。复现的本质，不是碰运气等同一个故障再出现，而是把触发条件一步一步收回来。条件越清楚，复现越有方向；证据越完整，定位越少靠猜。
写在最后
故障复现别只问“什么时候坏”。机器人问题越偶发，越不能只记录一句现象。“运行中停了一下”“偶发掉线”“重启后好了”，这些都只是起点，不是结论。
真正有用的复现记录，至少要能回答三个问题：它在什么条件下出现，可能沿哪条链路触发，修改以后怎么证明问题真的关闭。
我是「机器人落地派」。这里持续记录机器人硬件系统、可靠性、联调和工程落地相关的思考。
欢迎收藏这 7 个条件，也欢迎留言补充：你们现场最常漏记的一项是什么？