写博客工具：怎样记录问题的复查过程
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4df05e823ff7.html
📄
写博客工具：怎样记录问题的复查过程
记录问题的复查过程，核心是把“发现—修改—验证—保留结论”写成可重读的条目，而不是只记一句“已修复”。在写博客工具里，建议为每个问题建一条独立记录，至少包含发现时间、现象、影响范围、修改动作、验证方式、验证结果和复查日期，并让复查日期成为下次打开记录时最先看到的信息。
准备：先确定哪些问题值得复查
不是所有改动都需要长期跟踪。适合建立复查记录的问题通常有三类：一是曾导致页面无法正常显示、链接失效或内容丢失的问题；二是修改后无法当场确认效果的问题；三是同一现象反复出现、原因尚未完全确定的问题。
在写博客工具中，可以先用一个固定字段标记问题状态，例如“已定位”“已修改待验证”“已验证关闭”“观察中”。状态本身不是结论，它的作用是提醒你下一步该做什么。如果工具支持自定义字段，就增加“复查日期”；如果不支持，就把复查日期写在正文第一行，格式统一为年月日。
- 准备检查项一：问题是否有明确的观察对象，例如某篇文章、某个分类页、某段代码或某次发布操作。
- 准备检查项二：修改前后能否用同一方法观察，避免这次看页面、下次看后台，导致结果无法比较。
- 准备检查项三：是否写下了“可能原因”和“已经确认的原因”，两者不要混在一起。
实施：把复查过程写成可执行的记录
最关键的一步，是在修改完成时立刻写下验证方法，而不是等复查当天再想。验证方法应当具体到可以重复执行，例如“重新打开该文章，检查目录锚点是否跳转到对应小节”，而不是“看看有没有问题”。
一条可用的复查记录可以按下面的顺序写：
- 现象：用一句话描述用户或自己看到的结果，例如“文章页脚注编号与正文引用不一致”。
- 影响范围：只影响一篇文章，还是所有使用同一模板的文章。
- 可能原因：列出待排查项，例如手动编号错误、模板重复输出、复制粘贴时漏改。
- 已定位原因：确认后再填写；未确认就保留“待确认”，不要提前下结论。
- 修改动作：写清改了哪里、改了什么，例如“删除模板中重复的编号输出”。
- 验证方式：写清用什么入口、什么操作、看什么结果。
- 验证结果：通过、未通过或部分通过，并附上实际观察到的现象。
- 复查日期：下次需要重新确认的日期，以及复查时重点看什么。
如果写博客工具支持标签，可以给记录加上“待复查”标签；复查完成后改为“已复查”。标签只是辅助，不能替代正文中的日期和结论。
验证：复查时怎样判断问题真的解决了
复查不是重新读一遍修改说明，而是重新执行验证动作。建议按“同一条件、同一观察点、同一判断标准”来做：上次在什么页面、什么操作下发现问题，这次就在相同位置重复一次。
判断结果可以分三种：
- 通过：现象不再出现，且没有引入新的明显异常。此时记录复查日期和结论，再决定是否关闭。
- 未通过：现象仍出现，或出现位置变化。此时不要直接改结论，应补充新的观察，重新区分可能原因。
- 部分通过：主现象消失，但相关位置仍有异常。此时保留记录，把剩余现象拆成新的待查项。
假设一个例子：某篇文章的代码块在修改后显示正常，但复查时发现移动端仍出现横向滚动。这个例子中，桌面端通过不等于整体通过，应把“移动端代码块溢出”作为新的复查项，而不是把原记录直接标为已解决。
维护：让复查记录以后还能用
维护的重点是控制数量和信息新鲜度。每隔一段时间，把已经连续两次复查通过、且没有再出现同类现象的记录归档；把长期“观察中”的记录重新评估，确认是否还有必要继续跟踪。
归档时保留三类信息即可：问题现象、最终确认的原因、验证方式。这样以后遇到相似现象，可以直接搜索旧记录，先看当时的判断依据，再决定是否复用。若写博客工具支持导出，定期导出为纯文本或表格，避免记录只存在于某个界面中而无法整体查看。
下一步，可以打开你正在使用的写博客工具，挑一条最近修改过但还没复查的问题，补上“验证方式”和“复查日期”两个字段。先让一条记录完整走完准备、实施、验证、维护四步，再把这套字段复制到其他问题上。
