做软件时，“好了”是一个很方便、也很容易让人误会的词。
页面做好了，可以说好了；开发者的电脑上跑通了，也可以说好了。等真正使用的人坐下来，接上自己的设备、账号和数据，问题可能才刚开始出现。前面的人没有故意说错，后面的人也不是故意挑剔，只是大家说的“好”，不是同一件事。
做软件、硬件集成和运维时，我比较在意这个区别。自己测试时知道该点哪里、该填什么，也知道哪些步骤暂时绕过去。使用者没有这些默契。开发者心里记得的那条小路，不能算产品的正式入口。
让它离开开发者的电脑
假设做一个设备状态页面，模拟数据在屏幕上跳动，已经能说明页面和数据格式基本配合了。但要交给别人，先得把操作条件写下来：使用的版本、配置、数据起点、操作顺序和应该看到的结果。这样接手的人至少知道从哪里开始。
接上真实设备以后，还要看断网会怎样，数据晚到会怎样，设备重启会不会留下错误状态。每种情况都要尽量写清楚怎样触发、应该看到什么、实际看到了什么。没有条件验证的部分，就留下未验证的记录，不用一句“应该没问题”带过去。
再往后，还有人。看到状态不对的人知道该做什么吗？一条提示是需要马上处理，还是明天查看也可以？如果同事换了班，前面做过的事能不能找到记录？这些问题常常比界面上的颜色更影响日常使用。
我倾向于先把一条具体流程走到底。正常时怎么完成，失败时停在哪里，已经做过的事情会不会重复，这些都写进交接说明。原作者如果只能靠现场口述补上步骤，说明这段还没有真正交接完。
没试过的地方，也写下来
有些检查暂时做不了。设备还没到，外部账号没开，现场网络还没准备好。这时把已经做好的部分交代清楚，也把没试过的部分写明白，后面的人会轻松很多。
比如留这样一句：“目前用模拟数据检查过；真实设备的断网重连还没试，样机到了以后补。”不用写得很正式，但不能只留下一个“通过”。过几周再来看，连自己都未必记得当时省略了什么。
一份交接说明也不用厚。哪个版本、在哪里运行、输入怎么准备、试过什么、遇到什么问题、下一步从哪里开始，这些先说清楚。如果出了问题只能给原作者打电话，那文档大概还有点话没说完。
交接前，最好请接手者独立复现一遍，从空白记录开始走流程，原作者先不在旁边指路。走不下去的地方记下来，再一起看是说明书少了一步，还是系统本身有问题，不能把“在我这能跑”当成完成。
备份也一样。有备份文件，是一回事；能不能恢复，是另一回事。文件安安静静躺在那里，看起来都很可靠，最好还是找合适的环境试一次。
AI 让写代码快了很多，也容易让我们更早产生“做完了”的感觉。一段解释很顺、一页界面很完整，确实让人高兴。但判断它能不能交出去，仍然得回到实际操作。工具帮我省了时间，我也应该拿出一些时间，看看它有没有把难处藏在别的地方。
我希望交出去的软件，不只是能在我面前运行。接手的人能看懂步骤，日常的问题有办法处理，需要继续开发时也找得到起点。这些工作有时不显眼，却决定了一套软件能陪人用多久。
接着读：设备报了警，然后谁去看一眼？；需要核对检查依据时，看证据说明。