一份给未来自己的问题记录

问题解决以后，最容易省略的工作就是记录。刚刚完成排查，所有细节都很清楚，于是觉得没有必要再写一遍。

然而，过了几个星期，“当时为什么这样改”可能比“改了什么”更难回忆。

先写清楚现象

记录可以从最具体的观察开始，而不是直接给出结论。

“页面打不开”太宽泛；“启动服务后，首页正常，文章页返回不存在”则提供了一个能够再次检查的范围。还可以补充发生时间、操作顺序，以及预期结果。

留下排除过的方向

每一步都写成长篇过程没有必要，但重要的尝试值得保留。特别是那些看起来合理、最后却没有帮助的判断。

方向	观察	下一步
服务是否运行	健康检查有响应	检查具体页面
内容是否保存	草稿可以重新打开	检查发布状态
页面是否生成	发布前文章页不存在	发布后再次验证

这只是一个示意。真实记录里，应当写入实际观察，避免把推测当成证据。

把重复步骤写成小脚本

对于反复进行的整理工作，几行简单代码有时比一段操作说明更直接。下面这个独立示例按日期排列条目：

const notes = [
  { title: "记录问题", date: "2026-10-04" },
  { title: "补充验证", date: "2026-10-08" },
];

const newestFirst = [...notes].sort((a, b) =>
  b.date.localeCompare(a.date)
);

console.log(newestFirst.map(note => note.title));

脚本应当足够小，能一眼看清它读取什么、改变什么。记录里也要说明它用于哪一种输入。

写下验证方式

最终答案后面，还可以加一句“如何确认已经解决”。重新执行导致问题的操作，检查结果，再确认相关的正常路径没有受到影响。

下一次看到这份记录时，就不必仅凭一句“已经修好”来判断。