机器人项目里，改需求、改方案、改结构、改参数都不稀奇。
现场条件会变，器件供应会变，线束空间会变，软件逻辑会补，测试结果也会推动方案调整。
真正麻烦的，往往不是“改了”，而是改完以后，项目里的其他人、其他文件、其他验证条件都没有跟上。
有一种联调现场很典型。
机器人前几天还能稳定跑，今天突然开始偶发掉线。不是每次掉，也不是一上电就掉，问题大多出现在机械臂转到某个姿态以后，但不是每次都会复现。
软件先去看日志，电气去查线束，结构去看安装，测试去翻记录。每个人都能查出一点现象，但谁也说不清问题从哪开始。
查到后面，才有人想起来：
“前两天为了避让结构件，好像把那段线束固定点往里挪了一下。”
这个改动当时看起来很小。
原来的位置可能会擦到结构边缘，现场把固定点挪一下，线束不干涉了，机器人也还能继续跑。大家自然会觉得，这不是一次大改动，只是现场处理一下。
但问题恰恰从这里开始。
固定点一变，线束弯折半径变了，运动姿态下的受力变了，连接器姿态可能也变了。更麻烦的是，图纸没有更新，装配说明没有同步，测试记录里也没有标明状态变化。
这个改动是不是根因，还要继续复现。但至少到这里，团队终于找到了一项此前没有进入记录、却可能改变触发条件的系统变化。
后面再查问题时，软件以为运行条件没有变化，电气以为自己在查同一套线束，结构以为安装状态没有变化，测试以为复现条件和前几天一样。
所有人都以为自己还在查同一个系统，实际上大家手里的系统已经不是同一个状态。
项目不是不能改
机器人项目不可能从一开始就什么都定死。
传感器安装位置可能要调整，线束走向可能要调整，驱动参数可能要调整，软件状态机也可能要补逻辑。这些都正常。
真正的问题是，改动有没有进入项目状态。
如果一次改动只停留在现场一句“我先改一下”，后面就很容易变成几个麻烦：这台机器现在和图纸不一样，测试用例还按旧条件跑，软件版本和现场状态对不上，后面的人不知道为什么这么改，问题复现时也不知道该按哪个状态复现。
这不是谁工作不认真，而是机器人系统本来就牵一发动全身。
一个看起来很小的变化，可能会同时影响结构空间、线束姿态、电气连接、软件状态、测试条件和维护动作。
所以项目不是不能改，而是不能让改动只停留在某个人的嘴里、脑子里或者现场临时动作里。
“没人知道”不是没人收到消息
很多时候，并不是完全没人听说过这个改动。
可能群里说过一句，会议里提过一次，现场有人看见过，甚至当时大家还都觉得“这个问题不大”。
但工程上真正的“知道”，不是听说过，而是后面能查得到、复现得到、验证得到。
图纸是否更新？
版本是否标清？
测试条件是否同步？
后续维护和复现问题的人是否能查到原因？
如果这些对象没有同步，那这个改动就只是停留在人的记忆里。人的记忆一变，项目状态就开始变乱。
很多项目越到后面越难查，不是因为问题突然变复杂了，而是系统状态已经被一次次小改动改散了。
改动不可见，问题就会伪装
变更失控最麻烦的地方，是它不会一开始就告诉你“我失控了”。
它通常会伪装成掉线、误报警、偶发停顿、测试结果不一致、现场难复现。
线束固定点变了，最后可能表现成通信不稳定。
一个超时阈值改了，最后可能表现成问题暂时不出现。
一个接插件换了，最后可能表现成维护复装以后状态不一致。
一个软件分支补了逻辑，最后可能表现成测试结果和旧版本不再可比。
如果这些改动没有被记录，后面再查问题时，团队就会不断误判。
大家以为问题是偶发，实际上只是触发条件变了。大家以为这次复现不了，可能只是复现时用的已经不是当时那台机器的状态。
所以，很多后期难查的问题，并不是突然变复杂了。
只是系统被一次次小改动推到了不同状态，而团队还以为大家手里是同一版。
发现有人改过，先别继续猜
这篇不展开完整变更流程，只先把现场要收住的四件事放出来。
第一，这次到底改了什么？
第二，影响了哪些对象？
第三，哪些验证要重新做？
第四，以后从哪里能查到这次改动？
这四个问题能回答，改动才算进入项目状态。
回答不了，它就还只是一次现场临时动作。
一次临时动作，短期看可能解决了眼前问题；但如果没有被同步、验证和追踪，后面就可能变成新的问题来源。
改动本身不可怕，不可见的改动才可怕
真正可怕的是，系统已经变了，图纸、版本、测试和后面接手的人却还不知道。
这类问题最容易在后期集中爆出来：联调时查不到版本，测试时对不上条件，交付时说不清状态，维护时不知道为什么当初这么接、这么装、这么设。
变更记录不是为了增加流程感，而是为了让项目在后面查问题时少一点猜测。
前面改动透明一点，后面联调、测试和交付就少一点扯不清。
下一篇继续聊：一个改动发生以后，哪些版本、文件和验证必须一起跟着变。
我是「机器人落地派」。
欢迎留言聊聊：你见过哪些“改的时候觉得很小，后面查起来很麻烦”的改动？
