离职前三个星期都在交接。第一版文档写得快，两天二十多页，从系统怎么搭起来讲到每个部分干什么，自己读一遍挺满意。
接手的人过了半小时回我一句看不太懂。我跟他对着文档走了一遍，才看清问题在哪。我写的是我知道什么，不是他要做什么。满页都是名词和状态，有几个服务，也就是一直开着的程序。看完这些，他要重启一次线上服务，还是不知道从哪儿下手。
第二版我换了写法，先在开头定下一个目标：一个没参与过这套东西的人，只靠这份文档，能不能独立做一遍最常规的操作。我挑了两个动作，发一次版本，重启一次服务。发版就是把改动推上线，重启就是停掉再拉起来。这两个写不通，别的都是空谈。
顺序也跟着变了。先说这套东西怎么起来，需要装什么，然后说日志在哪个目录。接着是配置在哪，改之前注意什么，改完怎么生效，配置就是不改代码也能调的东西，比如超时时间、开关。再往下是常见故障，列了九条，每条写清楚看到什么现象、先查哪一步、什么情况下找谁。这部分最细，接手的人前两周只会遇到这些。
有一块我原来没写，哪些地方看起来能改其实不能改。
对账任务里有个排序参数，谁看都觉得是随手写的。但那个值是当年跟上游对齐过的，改了数字会错，而且只在跨月那几天错。对账就是每天把两边的数字比一遍。类似的地方我列了七条，每条都写了当初为什么这么定，改坏了会从哪里先露出来。
这类知识最容易丢。它不在代码里，只在做过这件事的人脑子里。写出来是唯一能留住它的办法。
关键决定的理由我也补了。为什么拆成两个服务而不是一个，为什么那张表多加了一个看着多余的字段。答案都不优雅。那个字段为了兼容一个月底就下线的老系统，本来打算用三个月，用了两年。
收尾我还加了一页验收清单，五行，写的都是动作。谁接手谁照做一遍，做不下来的地方就是该补的地方。
后来接手的人跟我说，他入职第三周发那个版本就是照着文档走的，中间停了一次，因为我漏写了发版前要手动导一次数据。
文档的验收标准就一条，一个没参与过的人能不能只靠它做完一次常规操作。做不到这一条，写多少页都是给自己看的。花时间的地方不是写下已知的东西，是去查那些你默认别人知道、其实只有你知道的部分。
