遇到问题先怎样记录：事实、猜想与验证分开写

傍晚的光线变黄时，屏幕上的问题看起来比中午更急。页面空白、表对不上、钥匙找不见、水尺的读数和昨天差了一大截，人的手头会先去拧、去刷新、去翻箱。拧过之后，现场变了，你却说不清刚才看见的到底是什么。记录若等解决之后再补，补出来的往往是一个顺的故事。顺的故事好听，下次却用不上。

我把问题笔记分成三块：事实、猜想、验证。三块可以写在同一页，但句子不能混。混的标志很明显：事实里出现了「可能」「应该」「大概」，猜想里出现了已经看见的报错原句，验证里只有「试了不行」而没有预期。分开写，不是为了显得有条理，是为了让下一小时的你不必重新经历这一小时的混乱。

先占住现场，再谈原因

问题出现的头几分钟，只做两件事：让现场不要继续被破坏，以及把已经看见的抄下来。能暂停操作就暂停。必须操作才能避免更大损失时，先把操作前的样子记下来，哪怕只有一行：时间、你看见的原句、你即将做的动作。

事实这块只收已经发生、可以被另一双眼睛核对的内容。时间写到分钟。环境写能影响结果的那些：哪台设备、哪个浏览器、哪一个文件版本、人在现场还是在远处、天气若与读数有关就写天气。不写心情。慌、烦、觉得自己很蠢，都先留在笔记外面。它们会促使你把猜想写成事实。

原句照抄，不翻译。屏幕上写「无法找到资源」，就不要记成「图片挂了」。翻译里已经混进了猜想。路径、数字、单位照抄。水尺上的 1.84 不要记成「差不多 1.8」。差不多在下一次比较时无法使用。

已经做过的动作，若改变了现场，也写成事实，不要写成验证。验证需要预期。当时如果只是顺手刷新了一下，就写「19:06 刷新一次，页面仍空白」。不要写「排除了缓存问题」。你还没有排除任何东西。

事实栏里具体放什么

我用同一组问题帮自己收束，不把它们印成表格贴在墙上，只是在空白页上逐项看有没有漏。

何时发现，何时开始记。两个时间可能不同。发现后若已经拧过几下，就把这段间隔写明。「19:02 发现空白，19:07 才开始记录，中间刷新过一次。」间隔本身是事实。它提醒你，记录之前的状态是不完整的。

何地、何物。文章预览、某一份表、某一个文件夹、河岸上的哪一根水尺。对象用文件名或地点的固定叫法，不用「那个东西」。

可见的症状。空白是全白还是留着标题；表是某一列空着还是全部错位；读数是缺失还是跳变。症状用否定句也要具体。「没有报错弹窗」是一条有用的事实。「不太正常」不是。

范围。别的页面是否正常，别的表是否正常，上游水尺是否也跳。范围能防止你把局部写成全局。我写过一次「网站挂了」，后来事实只是这一篇文章的配图路径指向了不存在的目录，其余页面都在。那句「网站挂了」如果留在事实栏，后面的猜想会全部偏到服务器上去。

近期的改变。昨晚改过模板、今早挪过文件夹、下午有人清过浏览器、昨天晚上下过雨。改变先作为事实列出，不要立刻说它们就是原因。近期没有改变，也写一句「自昨日 18:00 的记录之后，未改模板」。没有改变，本身可以否定一批猜想。

你还没有做的检查，不要写成「应该没问题」。没检查就是未知。未知留空，比填一个安慰自己的句子干净。

猜想要单独成行，并写上什么能否定它

事实收完，再写猜想。每一个猜想单独一行，前面加上「猜想」两个字，避免语气又滑回事实。一行只放一个原因。两个原因写在一行里，验证时会不知道自己在验证哪一个。

每个猜想后面跟一句否定条件。否定条件是你可以观察到的结果，不是另一句感想。「若模板语法有错，另一篇使用同一模板的文章也会失败。」这是可观察的。「若是模板问题，那我就得重写」不是否定条件，那是对后果的担心。

猜想可以来自经验，但经验不是事实。你以前见过缓存造成的空白，可以写进猜想。不要写成「肯定又是缓存」。肯定这个词一出现，验证就会变成走过场：你只做能证明它的那一步，对反面证据视而不见。

猜想的顺序按「哪一个最容易被观察否定」来排，不按「哪一个听起来更深刻」来排。先看是不是路径写错，再看是不是服务没开，再看是不是更底层的故障。这个顺序是为了少改动现场。先做会大改现场的验证，事实会被你自己毁掉。

允许有一条叫「暂无更多猜想」。写上它，是为了防止空白处诱使你编造。编造的猜想也会占用验证时间。你为了填满页面去验证一个自己也不信的原因，晚上就这样过去了。

不要在猜想里写谁的过失。「同事又把路径改错了」既是猜想，又是指控。改成「配图路径与现行目录不一致，可能由昨晚的移动造成」。人或动作若要出现，放到事实里，并且只写你核对过的：文件修改时间、修改者字段。没有核对过的名字，不写。

验证写下预期、动作、结果和时间

验证不是「我试了」。验证是一组很小的记录：此刻要检验哪一条猜想，预期看见什么，实际做了什么，实际看见什么，时间，现场因此留下了什么变化。

格式可以很笨：

• 猜想：配图路径指向了不存在的目录。
• 预期：打开稿子里的图片地址，磁盘上没有对应文件；把地址改成现存文件后，预览不再全白。
• 动作：19:18 核对路径 images/old-bridge.png，目录中无此文件。19:22 改为现存的 images/2026-09-18-旧桥-石阶.png 后刷新。
• 结果：预览出现图片，标题和正文同时可见。
• 现场变化：稿子里的路径已被改动，旧路径只留在这条笔记里。

有了预期，结果才有意义。没有预期的操作，成功了也不知道说明什么，失败了更不知道排除了什么。很多人重复刷新，是因为刷新没有预期。刷新一次可以是事实，刷新十次不是验证。

一次验证只动一个因素。你若同时改路径、清缓存、换浏览器，页面恢复了，你仍不知道是哪一个因素起了作用。下次还会三件事一起做，并且在笔记里写成一个含混的「处理好了」。处理好了无法迁移到下一个晚上。

结果若与预期相反，把猜想标成「被这一次观察否定」，不要删掉。删掉的否定，下周会再长出来。被否定的猜想留在原地，比留下一个光秃秃的正确答案更有用。正确答案往往只在当前条件下成立。

结果若与预期部分相符，不要升级成「已经确认」。写「这一次观察支持该猜想，尚未排除其他可能」。支持不是结束。若时间不够，就写明停在哪里，下一步的验证是哪一个动作。停下来，也是记录的一部分。

一次空白页面的笔记会是什么样子

下面是压缩过的例子。它比真实的晚上短，但三块的边界和真实情况一致。

事实：

• 19:02，本机浏览器打开澄湾稿预览，全白，无弹窗，无可见标题。
• 同一浏览器打开另一篇旧稿，标题和正文正常。
• 19:04，预览工具的窗口标题仍是澄湾稿的文件名。
• 昨日 21:40 到今日 19:02 之间，改过澄湾稿的配图路径；模板文件的修改时间仍是上周。
• 19:06 刷新一次，仍全白。当时未记录路径原句，现已无法从屏幕找回刷新前的状态。这一点是后补的限度。

猜想：

• 猜想 A：这一篇的配图路径指向不存在的文件，预览因此中断。否定条件：路径所指文件存在，或改回已知可用的图片后仍然全白。
• 猜想 B：模板语法有错。否定条件：使用同一模板的旧稿也失败。旧稿正常，故这一条在 19:10 被否定。
• 猜想 C：预览服务没有运行。否定条件：旧稿也无法打开。旧稿能打开，这一条同时被否定。

验证：

• 针对 A。预期：稿内图片地址在磁盘上不存在。19:18 核对，images/old-bridge.png 不存在，目录里实际文件名为 images/2026-09-18-旧桥-石阶.png。
• 19:22 只改这一处路径并刷新。预期：预览恢复。结果：恢复。现场变化：稿子路径已替换，旧路径记在本页。
• 未做的事：没有清缓存，没有改模板，没有重启机器。因此这次笔记不能用来谈论缓存。

这个例子里，真正起作用的不是「我想到了路径」，而是旧稿正常这一事实一次性否定了两条更大的猜想，以及改动时只动了一个因素。若当时又清了缓存，恢复之后我会一直怀疑是缓存，并把一个错误的做法带到下一篇稿子上。

验证会破坏现场时，更要先写

有的动作不可逆。覆盖文件、重启之后日志消失、把水尺附近的淤泥踩乱、把对话记录清空。这些动作若可能成为验证手段，先把动作前的事实抄走，能复制的先复制到旁边，再动手。

复制出来的那一份，名字按日期和「原样」来叫，不要叫「备份」。备份会越积越多，分不清哪一份是故障当时的原样。原样只有一份，后续改动另存。这一点和日常的文件命名是同一件事：你以后要找的是「故障当时」，不是「我处理过」。

若问题涉及别人正在使用的东西，先说明你要做会改变现场的验证，再做。不说明就重启、就覆盖，事实会在你的笔记之外被别人的工作改写。回来对账时对不上，你容易把对不上再猜想成新的故障。

读数类的问题也一样。你怀疑水尺被漂浮物挡住，准备拨开。拨开之前先写下拨开前看见的数字、遮挡的位置、时间。拨开后的数字是新事实，不是对旧事实的替换。两个数字都要留。只留拨开后的，你会在笔记里得到一个干净的、却不是当时读到的数。

解决之后，笔记还要收一个尾

页面恢复、钥匙找到、数字对上，这时最容易把笔记扔掉。扔掉之前加一个很短的结尾，仍然按三块的纪律来，不另起一套「经验总结」。

事实补上：问题不再出现时的时间和条件。「19:26 预览恢复，只改过图片路径。」猜想补上状态：A 被这一次支持，B 和 C 被否定。验证补上未做的项目，防止以后把未做的说成已排除。

然后写一行「若再出现，先看什么」。这一行不是新的理论，是把这次最有区分力的观察提前。例如：「再出现全白，先看这一篇的图片路径是否存在，并同时打开一篇旧稿。旧稿正常则先不重启。」行数不要多。多了就变成手册，手册在下次故障的头几分钟不会被阅读。

若这次没有解决，结尾就写停在哪一条猜想、现场现在是什么状态、下一步验证的动作和时间。不要用「明天再看」结束。明天再看不是动作。动作是「明早 9:10 核对归档日志的哪一段」。

失败的验证同样收尾。预期没有出现，就写没有出现。不要为了让笔记看起来有进展，把无关的小调整写成收获。没有进展，是可以记录的状态。

笔记放在找得到的地方

问题笔记若写在随手的纸上，解决之后纸会进废纸。我把它放进对应项目的目录，名字带日期和症状短词，例如 2026-09-28-1930-预览全白。症状用你当时看见的，不用你最后认定的原因。用原因当名字，下次症状相同但原因不同时，你会错过这页。

同一症状再次出现，新开一页，在开头写上一页的路径。不要在旧页中间继续涂改。旧页的猜想状态是当时的。涂改会把两次故障并成一次，验证的时间顺序也会乱。

笔记里引用的截图、日志片段，跟笔记放在一起，命名与笔记对应。截图若只存在剪贴板里，关机就没了。没了的截图，笔记里要注明「当时未保存」，以免以后以为自己还有证据。

别人需要接手时，交出事实和未完成的验证，不必交出你的挫败。接手的人需要原句、版本、已做的动作和现场是否被改变。你的猜想可以给，但要带着否定条件，并标明哪些已被否定。不要只给一个你偏爱的猜想，让别人沿着它继续消耗时间。

分开写，并不能代替判断

三块写清之后，仍然要有一个判断：下一动作做不做、做哪一个。判断可以用笔记里的一句话表达，但不要倒灌进事实。「所以就是路径的问题」可以写在验证结果之后，作为这一次的结论，并带上限度：「在未清缓存的条件下，改路径后恢复。」限度丢失，结论会变成过大的信念。

有的问题没有单一原因。笔记不要强迫自己选出一个。两个因素都有观察支持，就两个都留下，写明各自的证据。勉强合并成一个故事，会在下次只检查其中一半。

也有的问题不值得继续验证。花费已经超过事情本身的分量时，把这个决定写成事实和判断：「20:10 停止。未验证缓存。判断：这一篇今晚不必发出，明天用旧稿流程重做配图。」停止是清醒的记录，不是半途而废的遮羞。遮羞才会写成「基本解决」。基本解决无法在明天执行。

山里若起了雾，先记下能看见的那几步，再猜雾有多厚。雾有多厚，要走一步看一步。问题笔记做的就是这件事：看见的放在事实，猜测放在猜想，走出的每一步放在验证。三块没有混在一起的时候，即使今晚没有走出去，明天也可以从停下的地方接上，而不必从情绪重新开始。