同一种报警又出现了。

团队先翻问题单。上一次的记录只有两句：

已处理。 > > 测试正常。

再找当时的测试报告，能看到“通过”，却看不到问题在哪种条件下出现，也看不到中间改过什么。

有人想起，这个问题以前确实解决过。

于是讨论绕了一圈，最后还是落到一句话：

“问一下当时处理的人。”

问题发生过，工程师也处理过，但项目没有因此变得更会解决这个问题。

问题消失了，项目的做法却没有改变

现场处理问题时，第一目标当然是尽快恢复运行。

工程师可能换过连接器、调整过参数、重新固定线束，也可能只是改变了操作顺序，问题就不再出现。

在当时，这个结果足以让工作继续。

可如果留下来的只有“已经恢复”，后来的人就无法知道：最初看到了什么，中间改变了什么，现象随哪些变化发生了变化，其中哪些关系已经得到验证，最后的正常又覆盖了哪些条件。

结果是，问题虽然被解决了一次，后续装配、调试和测试的做法却没有因此改变。

下一次相似现象出现时，大家能找到结论，却不能直接从上一次已经确认的地方继续。

一次解决，没有改变下一次的起点

一个问题有没有真正留下价值，不能只看当时是否恢复，还要看下一次工作是否因此少走了一段弯路。

解决一次，是当下有了结果；改变下一次工作的起点，才是项目真正学会了。

两者之间的差别，不在于有没有写一份复盘，而在于上一次已经确认的内容有没有进入下一次执行。

如果下一台机器仍会重复同一种装配偏差，如果测试仍然漏掉已经暴露过的条件，如果相似异常出现后仍要从所有可能性重新排起，那么问题单虽然关闭了，过程本身并没有学到东西。

沉淀不是存档，而是让下一次少走一步

有价值的沉淀，不是把聊天记录、日志和报告全部存进一个文件夹。

它应该让下一次工作发生变化。

曾经遗漏的条件，进入后续测试；已经确认的装配差异，进入共同执行依据；临时修改过的参数，有了明确状态；再次出现相似现象时，团队知道先核对哪些关系，也知道哪些旧结论不能直接套用。

这时，上一次问题带来的变化才真正进入下一次装配、调试、测试和问题判断。

它未必表现为一份很厚的文档，甚至可能只是一个被补清楚的要求、一条能追溯的关联，或者一项后来可以直接执行的新约束。

关键是：原来只存在于个人记忆里的东西，开始改变项目以后怎样工作。

真正危险的不是忘记，而是以为团队已经知道

经验留在人脑里，最麻烦的地方不是某个人有一天忘了。

而是大家一直以为“这个问题我们处理过”，直到换人、换机器或换现场以后，才发现团队真正拥有的只有一句结论。

机器人项目不可能没有问题。

但同一个问题第二次出现时，项目不应该还站在第一次排查的起点。

问题解决一次，只恢复了当下。

让后来的人不必重新猜，才说明这次经验真正留在了项目里。