上周四晚上十一点半，我盯着屏幕上那个 sqlite3.OperationalError: database is locked 看了两分钟。报错本身倒没什么，烦的是它是我让 AI 写的脚本抛出来的，而脚本已经跑了四十多分钟。
背景简单说：我 2017 年刚开始做技术博客那阵，攒了个小站，里面一万多条东西，全是 sqlite 存的……其实也不算东西，是我当年记的选题库，还有一堆没写完的草稿。退网那年我整个站打包成一个 tar，扔在硬盘角落里，前几天翻出来，想着导成 markdown 存一份，省得哪天硬盘挂了。
这种活以前我自己写，一个下午，边查 sqlite 的 API 边骂人。这次我直接把 tar 包丢给 AI，跟它说表结构在 schema.sql 里，让它写个导出脚本，带上 front matter。
它给的比我预期好。第一版就跑通了，字段映射基本对——它甚至看出来我当年 created_at 存的是 Unix 时间戳、单位是秒，而 updated_at 存的是字符串，还顺手给我写了转换。我承认那一下有点爽。真的，那种爽不是“AI 好厉害”的爽，是“这下不用我自己翻文档”的爽。三步就能——打住，差点又开始列步骤了。这活没什么步骤好列。
然后我让它加个容错，说有脏数据跳过就行，别整批崩掉。
它加了。加得特别好，好到我第二天上午才发现问题。
它把所有异常都吞了。except Exception: continue，就一行。整批跑完没报一个错，进度条漂亮的走完，最后打印“导出完成，共 9987 条”。我当时还挺满意，甚至跟人说这活 AI 干得比我干净。
第二天我随手翻导出的目录，觉得数量不对。回原库 count 了一下，一万一千多。少的两千多条，全是时间戳解析失败被静悄悄跳过的——我有一批早期数据的时间字段是 '2017/3/5' 这种格式，fromtimestamp 当然炸。
让我气的不是它写错了。是我让它“跳过”，它就真的一句不吭跳过去，连个日志都不留。它明明能打一行 warning，但它选了最省事的写法，因为我原话就是“跳过就行”。这是我的锅。说句实话，这跟我当年写课一个道理——学员说“有个地方没讲清”，我就在群里补一句，课件不改。省事的逻辑是相通的，只不过这次省事的是机器。
后面改也不难，让它把异常捕获收窄，失败的行连原始 id 一起写进 errors.log。十分钟的事。但它提醒我一件事：AI 干活的质量，很大程度取决于你有多懒。你懒的地方它一定更懒，你含糊的地方它比你更含糊。它不会替你把关，只会顺着你的话往下溜。
（顺便说一句，看到有人拿类似的事发推，配文“AI 全自动重构”，我看了两眼就划走了。不想说，说了像蹭。就这样。）
现在那批数据躺着，一万一千多条，我大概永远不会再看第二眼。但存着吧。
就说到这。