这篇更适合作为一份联调前自查清单。
很多机器人整机联调问题，并不是联调当天才产生的，而是前期需求、系统设计、系统图、接口定义、物理连接和验证方案没有提前说清，最后在整机联调时集中暴露。
核心判断：联调不是只在解决新问题，也是在检验前面有没有把任务、状态、异常、验证和责任关系闭合。
1. 五类常见联调债
|
需求边界债 |
场景、任务、异常、验证口径没说清 |
各专业对“做到什么程度”理解不同 |
是否定义任务成功、失败、异常处理、验证条件 |
|
系统设计债 |
协同关系不清 |
各查各的，局部都没错但系统不通 |
谁发起、谁判断、谁执行、谁反馈、谁留证据 |
|
系统图债 |
只画模块，不画关系 |
图能汇报，但不能指导排查 |
是否表达能量、控制、数据、安全、责任关系 |
|
接口债 |
只写连接，不写协作 |
“我这边按文档做了”反复出现 |
初始化、状态、超时、恢复、关闭证据是否定义 |
|
物理连接债 |
线束连接器当收尾 |
偶发报警、不稳定复现 |
运动、振动、温升、插拔、维护复装是否验证 |
2. 联调前重点检查五类关系
2.1 任务关系
-
任务从哪里发起？
-
谁判断任务条件满足？
-
谁执行动作？
-
谁确认完成？
-
任务失败以后如何处理？
2.2 状态关系
-
每个模块的“正常”定义是否一致？
-
状态字、故障码、反馈信号是否有统一解释？
-
系统状态和模块状态是否有映射关系？
-
恢复后是否需要状态同步？
2.3 异常关系
-
掉线、超时、丢包、急停、供电异常分别怎么处理？
-
谁先动作？
-
谁保持状态？
-
谁允许恢复？
-
是否允许自动继续任务？
2.4 验证关系
-
问题复现条件是什么？
-
根因证据是什么？
-
修改后如何复测？
-
复测成功几次算关闭？
-
是否需要回归测试？
2.5 责任关系
-
哪个环节负责判断？
-
哪个专业负责修改？
-
哪个角色确认关闭？
-
关闭证据存在哪里？
-
变更以后影响哪些接口和验证用例？
3. 联调前建议补齐的文档
|
需求边界说明 |
明确任务、场景、异常和验收口径 |
|
系统设计说明 |
明确架构、协同链路和职责 |
|
系统关系图 |
暴露能量、控制、数据、安全、责任关系 |
|
接口定义 |
说明连接、状态、时序、异常和恢复 |
|
线束连接器评审记录 |
说明布线、固定、随动、维护和验证 |
|
验证方案/测试矩阵 |
说明如何证明问题关闭 |
4. 一个实用判断
如果联调现场反复出现这些话，就要警惕前面有关系没有闭合：
-
“我这边看着没问题。”
-
“我这边是按文档做的。”
-
“指令已经发出去了。”
-
“重启一下就好了。”
-
“这个问题后面再看。”
这些话不一定错，但它们通常说明：团队还没有把任务、状态、异常、验证和责任关系拉通。
5. 一句话总结
联调不是简单找 bug，而是在验证一套系统关系是否真的走得通。
前期没有显性化的关系，最后都会以联调问题的形式回来。
