每次跟 agent 聊完，你把最值钱的东西丢了

每次跟 agent 聊完，你把最值钱的东西丢了

上个月在搞一个 SQLite WAL 模式下的并发写入问题。查文档、试了几种锁策略、跟 Codex 来回几轮，最后找到方案：写操作串行化，加个队列，连接池设成单写多读。前后大概两小时，踩了三个坑。

关掉 terminal。第二天接着干别的。

一周后另一个项目又碰到 SQLite 并发写入。我明确记得解决过，但不记得怎么解决的。重新搜，重新试，重新踩了其中两个坑，又花一个多小时，得出一模一样的结论。

我试过记笔记。Notion 里攒了十几页踩坑记录，记的时候写了一大堆上下文，真要用的时候翻半天，找不到关键那句。记太详细变成负担，记太简略等于没记。后来我想明白：我一直在记录过程，把整个 session 的来龙去脉堆进 Notion。真正该留下的工程结论，反而被上下文淹掉了。

代码有 git，文档有 README，工程判断有什么

做完一个 feature，你其实产出了三样东西，但它们的命运天差地别。

代码有归宿：进 git，CI 替你跑，blame 替你查。

文档有归宿：进 README、进文档，新人 onboarding 时看得到。

判断呢？踩过哪些坑、为什么踩，方案在什么条件下成立，下次遇到类似问题该先查什么——这是密度最高、也最贵的一类产出，却没有任何地方放。它从真实问题里长出来，然后跟着 session 一起关掉了。

反过来想，前两样根本不用你操心。git 替你记了，文档有模板逼着你写。真正该你主动留住的，恰恰是第三样——那些 git 存不了、文档覆盖不到、只在 session 里存在过的判断。可整个工具链里，没有一个容器是为它准备的。

不是每段工作都值得留。改个字段、修个小 bug，过就过了。

值得留的标准只有一个：有没有形成一个非显然的工程结论。

显然的结论文档里就有——这个 API 要传这个参数。

非显然的结论是这样的：文档让你用 X，但你这个场景下 X 会引出 Y，最后得用 Z；根因是默认配置 A 和 B 撞了，下次直接查这两个。

这里得拦一句话。你可能会说：这些搜索引擎不也有吗？WAL 要串行化、单写多读，确实搜得到，是标准答案。

但搜索引擎给你的是终点，不是从你的起点走到终点要踩的那几脚。你那套连接池怎么配的、三个坑分别栽在哪、为什么默认配置在你这儿会撞——这条路径不在任何文档里，只在你刚关掉的那个 session 里。可搜的是解法，不可搜的是你走到这个解法的路径。 不留下来，下次还得从头踩一遍。

怎么让它下次真的被搜到

Notion 死在哪，处方就得长成什么形状。它死在「要用的时候搜不到」。所以这套做法必须正面回答三件事：怎么记、记成什么、下次怎么调回来。

趁 context 还热，让 agent 提炼，而不是你事后回忆。 一个阶段做完，就一句话：把这阶段的非显然结论压成一两百字，写清楚踩了什么坑、根因是什么、什么条件下成立。人事后回忆会丢根因，agent 此刻还握着完整上下文——这是它比你强的地方，过了这个村就没这个店。

存成结论，不存成过程。 一两百字，固定丢进全局 ~/decisions/——跨项目才搜得到，项目内的团队共识再同步进仓库 docs/decisions/。文件名直接写场景关键词——sqlite-wal-并发写入.md，不是 2026-06-03-笔记.md。下次你搜的是「SQLite 并发」，文件名得在那一刻撞上你的搜索词。Notion 栽的就是这一脚：它把可检索的那个词，埋进了正文第三段。

留一个固定的搜索入口。 全部进同一个目录，下次开工前先在这儿 grep 一遍。容器固定、命名可搜、入口唯一——存了才等于调得回来，否则跟 Notion 一样，存了等于没存。

---

SQLite 那个问题，现在记录里躺着的不是「WAL 要串行化」这句谁都搜得到的答案，而是我走到它之前踩的三个坑。朋友问我 WAL 写入的事，我把那条路径发给他，他跳过了我重踩的那一个多小时，十分钟解决。

你的上一个项目里，有没有一个结论，是你花两小时换来的——关掉 terminal 那一刻，就再也没见过它。