先承认记不住，再设计流程

我很早就放弃看过就记住这件事了。技术细节太多、版本又一直变，靠脑子存是最不可靠的方案。所以我这套方法不追求记住，只追求两件事：需要时能找得到，找到时看得懂当时的上下文。整个流程就三段，进来、消化、能检索，工具反而是最不重要的部分，这些年换过几轮，流程一直没变。

起点还是 2021 年那次找不到旧结论的懊恼。后来我想明白了，问题不在我记性差，而在我记的时候没带上下文，只剩一句结论，过几个月连它说的是哪个版本都分不清。补上上下文，比换任何笔记软件都管用。

进来：控制入口，不囤积

信息入口我卡得很紧：主力技术栈的官方变更日志用 RSS 单独订阅，几个工程博客按周翻标题，其余一律不订阅。看到好文章不急着收藏，先问这周用得上吗，用不上就放过。以前我收藏夹里堆了几百条以后读，结果一条没读，还平添焦虑，后来全清了，现在长期订阅源保持在十来个。

临时要留的，统一丢进一个叫收件箱的地方，每周清一次：要么消化成笔记，要么直接删，不允许它躺在里面超过两周。入口窄了，后面才不用做大量整理，这条比任何分类技巧都有效。

消化：写成能给三年后自己看的笔记

我的笔记只有一条硬规矩：必须带上下文。版本、环境、日期、错误原文、最后哪条办法真的生效，几样写全，只写结论的笔记等于没写。因为半年后我回来搜的往往不是怎么配置，而是那次那个报错在当时那个版本下是怎么绕过去的。格式不重要，纯文本就行，重要的是能被全文搜到，所以我一直用 Markdown 文件加一个本地索引，不绑死在任何笔记软件上，换工具时文件还在。

写博客是这套流程的出口：当一条笔记被我翻到第三次，或者整理时发现有普遍价值，就扩成一篇文章，补上背景、可复现步骤和别这么做的部分。写清楚的过程会逼着我把模糊的地方弄明白，很多次都是写到一半才发现自己其实没真懂，只好回去把命令再跑一遍。

能检索：靠标题和标签，不靠目录

我几乎不建多层文件夹，找东西全靠搜。标题里一定写进具体问题和技术名，标签只标两三个维度，比如语言、场景、版本阶段，不搞精细分类，分类越细，放进去时越纠结，找的时候越容易猜错层级。每季度我会翻一遍笔记，把已经失效的标上已过时而不是删掉，因为老版本的项目还在跑，那些结论哪天可能又用得上，删了反而要重踩一次。

这套方法没什么巧的，核心就是一句话：别信记性，把上下文写下来，让搜索替你记。工具换过几轮，这句话一直没变。