记忆
放在哪里

第一个坑：读得越多，越糊涂

最直觉的做法是把所有记录都塞给它读。结果有两个：一是成本——每次开工都在烧一遍全部历史； 二是质量——大量无关信息混进来，它的判断反而会变差。这一点我们在自己身上验证过： 同一件事，给它看三条相关记录时判断很准，给它看三十条混杂记录时开始跑偏。

第二个坑：载体选错，等于白写

写在哪儿比写什么更影响命运。我们的结论很干脆：纯文本文件，配合一个索引。

我们这台机器上，那次「应用状态库整个重建」的事故正好证明了这一点： 同一个晚上，应用自己的数据库被清掉重建，而放在纯文本里的记忆毫发无损。

我们的三层结构

索引只写「去哪找」，不写内容；内容按「什么时候会用到」分三层：

这套结构还有个副作用是好的：整理变成了定期动作——把 L2 里过期的内容压成一句结论、 把结束的项目挪进 L3，知识库就能一直用下去而不会越长越乱。

第三个坑：写完就不管，比不写更危险

这点我们是用自己的脸撞出来的。某天要查一个环境配置，翻开记录—— 整份说明还是上一台机器的内容：旧的路径、旧的工具版本、旧的限制条件。 而新机器的实情散在另外几处。载体是对的，内容在慢慢烂。

一份过期的说明书比没有说明书更危险，因为它会被相信。所以我们给自己加了一条： 凡是要照着做的记录，写的时候顺便写清「什么时候核过的」； 核对的时候以现场为准——程序报的版本、文件系统里的路径、命令的真实返回值，而不是文档里那句旧话。

可以直接抄走的四条

最后一句心得：记忆这件事，写的成本很低，校对的成本才是主要的。 写下一个结论一分钟，确认它今天还成立可能要十分钟——但只有后者能救明天的你。