修改一个熟悉的小项目时，人很容易直接动手：改几行配置，替换一个文件，然后刷新页面看一眼。步骤越短，越容易觉得没有必要记录。
但真正需要记录的，常常不是所有过程，而是三个关键点：原来是什么样，打算改变什么，以及用什么结果判断它成功。
先留下可比较的基线
开始之前，保存将要修改的文件，记录相关版本和当前的实际表现。对一个静态网站来说，可能只是首页截图、几个链接的返回结果，以及旧文件的一份副本。
这样，出现异常时就不用靠记忆猜测“以前是不是也这样”。
把验证和预期放在一起
“检查一下”太宽泛。把检查写得具体一点：打开哪个页面，应该看到什么；访问哪个路径，应该得到什么结果；哪些已有功能还需要继续可用。
- 变更
- 替换公开首页
- 预期
- 首页展示新版内容
- 验证
- 首页、文章链接、手机宽度
- 保留
- 现有入口及访问路径
- 恢复
- 还原修改前的静态文件
检查不一定很多，但每一项最好都对应一个实际担心的问题。
一次回答一个问题
同时改动许多不相关的东西，往往让结果难以解释。先完成一个目的明确的修改，观察结果，再决定下一步。出了问题，也更容易缩小排查范围。
记录不是为了把过程写得复杂，而是为了让下次处理更简单。
等修改稳定下来，再留一段简短的完成说明。几句话通常就够：改了哪里，如何验证，旧版本保存在哪。