上一篇聊了决策记录，说的是选了什么、为什么这么选。这篇说另一类同样值钱、却最没人愿意写的东西：没做成的事。
库里存的大多是成事之后的总结。方案落地了，文章写完了，工具装好了，都能留下一笔。没做成的那些，往往是当天骂两句、把半成品删掉，就当没发生过。
但真正省事的偏偏是这些记录。同一个坑踩第二遍，同一个方案半年后又被提出来，接手的人把去年试过的东西重试一遍。这些浪费，库里缺一份失败记录就躲不掉。
还有一件事很要命：人记得结论，忘了原因。去年那个方案为什么被否掉，是技术走不通、是当时人手不够、还是外部条件没谈拢？一年后脑子里只剩一句模糊的「好像试过，不行」。
一份记录写清三件事
格式不用复杂，三件事写清就够。
想做什么。一句话，说清要解决的问题和当时的约束，时间、预算、人手。
卡在哪。写具体的卡点，技术走不通、外部条件不允许、成本算不过来，都行。别写「效果不好」这种，要写清楚不好在哪。
后来怎么处置。绕过去了，彻底放弃了，还是留着等条件变。这一段决定这份记录是活的还是死的。
跟决策记录的分工
决策记录记的是几条路里选了哪条，失败记录记的是哪条路走不通。一个偏正面，一个偏反面，互相引一句就够。
格式直接照抄决策记录那套。固定一个文件夹，就叫 failures 或者「失败记录」，所有走不通的路都往里放，别散在各自项目目录里。文件名带日期和主题，比如 2026-09-19-采集脚本改本地清洗卡在权限。frontmatter 三个字段：date、status、domain。status 只用三个值，已绕开、已放弃、待重试。标签只加一个「失败」，靠字段筛比靠标签猜准。
什么时候写
失败当天，或者放弃的决定刚定下来那会儿。细节还在，写起来不费劲。等季度复盘再补，能记住的只剩「那个东西不行」。
写的时候不必给自己定性成「失败」，就是一份「此路不通」的记录。换个说法，心里负担小，反而写得下去。
怎么用
主要用在两个地方。一是新项目启动前搜一遍同类关键词，看看有没有人、哪怕是半年前的自己，已经试过。二是每季度拉一张「待重试」的清单，看看当时的卡点现在还在不在。人多了、预算够了、工具成熟了，去年走不通的今年可能就通了。
用 Dataview 拉表，按 domain 分组，一眼能看到哪些还挂着。
三个坑
第一个坑，写成情绪宣泄。记录里只留事实和约束。想说方案糟糕，换成「当时用了三台机器还是没扛住」，这样过两周还有人看得懂。
第二个坑，只记失败，不记绕过去的路径。最后怎么绕开的，往往比失败本身更值得留。
第三个坑，堆成坟场从不回看。攒了几百条一次没打开过，跟没记一样。靠季度那张待重试清单把它盘活。
收尾
失败记录冷门，复用率却不低。库里别人的成功经验一大堆，唯独自己栽过的跟头，只有自己存得下来。
决定记了，失败也记了，还有一类笔记一样稀少：那些还没想明白的问题。想不通的、拿不准的、留着以后再看的，值得单独开一类。下一篇说说知识库里的开放问题清单。