机器人联调问题排查清单：别让问题变成“各查各的”

适用场景

这份清单适用于机器人整机联调、系统集成测试、样机试运行和现场问题复盘。

典型场景是：底盘、机械臂、传感器、驱动器、控制器、电源、通信、上位机第一次真正合在一起跑，单模块阶段不明显的问题开始集中暴露。

联调真正麻烦的不是“问题多”，而是问题出现后没有明确排查链路。现场容易变成机械、电气、软件、控制、测试各查各的，但系统状态仍然没有收敛。

核心判断

机器人联调不是简单找一个 bug，而是在确认系统从指令、状态、动作、反馈、异常处理到问题关闭是否能走通。

如果系统关系没有画清，接口状态没有定义，日志证据没有留下，测试条件不能复现，联调现场就很容易变成一句话：

我这边看着没问题。

联调现场 7 句话排查表

现场说法

潜在风险

应继续追问

需要记录的证据

联调问题排查链路

一个联调问题出现后，建议至少按下面链路检查：

联调问题记录模板

问题编号：
问题标题：
发现时间：
发现人员：
任务步骤：
现象描述：
上一条关键指令：
硬件状态：
软件状态：
通信状态：
传感器数据：
电源/驱动状态：
安全状态：
日志/波形/截图索引：
初步判断：
责任接口：
负责人：
修改措施：
复测方法：
复测结果：
关闭标准：
关闭时间：

问题关闭标准

联调问题不建议只用“现场好了”作为关闭标准。更稳的关闭条件至少包括：

• 问题现象能描述清楚；

• 触发条件或发生步骤有记录；

• 责任链路已经定位；

• 修改内容有记录；

• 修改后完成复测；

• 关键日志或数据可回溯；

• 相关接口、状态或测试用例已补充；

• 负责人确认关闭。

使用建议

这张表不需要变成复杂流程。它更适合在联调问题卡住时，帮助团队先把链路拉出来：现象在哪一步，指令怎么走，状态怎么变，证据在哪里，修改后怎么证明关闭。

先把链路查清，再讨论归属，联调才不容易变成各查各的。