卡住 15 分钟，就对付一只鸭子

上周四晚上，一个爬虫任务卡在第三步，报错说文件不存在。我盯着代码看了二十分钟，换了个变量名、重启、又改路径，全没用。最后我打开一个空白文档，逼自己把问题写成一句话："任务从 /data/inbox 读文件，而这个文件昨天被批处理任务挪走了，没人记档。"写完那一刻就发现了——不是代码有 bug，是我上周改了路径没同步配置。

这就是橡皮鸭调试（rubber duck debugging）。名字来自程序员的传说：在桌上放一只橡皮鸭，卡住时它面前把问题从头讲一遍。其实不需要鸭子，一段语音、一块白板、一个空白文档都行。

**为什么有用**

卡住大多不是"问题难"，而是你在脑子里翻来覆去，记忆里的"我以为"和屏幕上的"实际"对不上。讲出来这件事强迫你做两件事：

1. 排序。把现象、动作、预期按顺序排开，bug 就藏在顺序的断点里。

2. 验证假设。你说"文件应该在"的时候，手会不自觉去 `ls` 一下——八成这时候就发现不在了。

**什么时候用**

- 同一个问题盯了 15 分钟没有任何进展。15 分钟是阈值，不到 15 分钟继续想，别急着走流程。

- 报错很模糊，"something went wrong"、"invalid value"，连从哪下手都不知道。

- 你已经改了很多东西，但报错纹丝不动——这时候最该怀疑的是因果判断错了，而不是再改一次。

- 你隐约觉得"我想到了一个"，但说出来又说不清。这是橡皮鸭的上场信号。

**什么时候别用**

- 还没收集证据。日志没看、任务没跑，就开始对着鸭子讲，那不是调试，是自己跟自己开会。先拿证据，再讲故事。

- 一行就能修的问题。查询语法错、变量名打错，直接改，别走流程。仪式救不了 typo。

- 依赖别人的问题。确认是上游坏了，直接找那个人。鸭子不能替你沟通。

**五分钟的 checklist**

1. 一句话讲现象：输入 → 预期输出 → 实际输出。说不清一句话，说明你卡住的地方不是代码，是理解。

2. 列出已尝试项，每项带结果。"试了七八次"不是信息，"改了 A、报错从 X 变成 Y"才是。

3. 写出最小能复现的输入，把别的干扰全砍掉。

4. 找出一个反直觉的线索：报错最醒目的那一行常常是果不是因，真正的根因在时间线上更早——也就是"在 A 之前发生了什么"。问自己这句话，往往比继续读报错有用。

5. 设一个 10 分钟的结界：讲完还没有头绪，停。把现状和下一步写进文档，换任务，明天早上带着上午的脑子回来。

**三个坑**

- 鸭子没有格式就行：随便嘟囔两声和"一句话 + 最小复现"的要求是两回事，没格式的版本基本等于没做。我强迫自己写成文档，就是这个原因。

- 别把"讲通了"当成"修好了"。讲完之后感觉"应该就是这样"，仍然要用最小复现验证一次，否则不过是一次幸运的猜测。

- 别为了鸭子开全员会。这是单人技能，文档比人便宜；真需要第二双眼睛时再喊人，把文档丢过去，三个人十分钟能看完。

橡皮鸭的价值不在鸭子，在"被强制完整说一遍"这件事。它是免费的诊断工具：不报错、不背锅、不用请人吃饭。卡住的时候，先去喂鸭子。