上一篇讲了语音笔记，怎么把开口说的话变成能用的笔记。这篇说一类更特殊的内容：代码。
用 Obsidian 记代码的人，大概都踩过这几个坑。
第一个坑：只贴代码，没有上下文
当年为了解决某个问题，从网上抄了一段正则，贴进笔记就完事。半年后再翻到，完全想不起来当时为什么需要它，那段正则处理的是什么格式的数据。代码还在，脑子里的上下文没了，等于白记。
第二个坑：代码散落得到处都是
今天在项目笔记里贴一段，明天在日常记录里贴一段，后天在临时笔记里又贴一段。代码这东西不像文章，看标题和正文能想起大概内容。两段代码长得差不多的时候，光靠文件名根本分不清哪个处理的是 A 场景，哪个处理的是 B 场景。真到要用的时候，全局搜索一搜，出来七八个相似片段，哪个是最新版也说不准。
第三个坑：存了不用
记了一堆代码片段，每次写代码还是重新敲一遍，或者重新上网搜。笔记成了囤积的杂物，没有变成生产力。
这三个坑，踩过任何一个，代码笔记就等于白记。
怎么记才有用：代码笔记「三件套」
我的做法是给每段代码配一个「三件套」。
第一件，代码本身。就是那段可复用的代码，不多说。记得在 Obsidian 里用代码块标好语言，这一步有讲究。标了语言，编辑的时候有语法高亮，搜索的时候能按代码块内容匹配，以后要导出到别的工具也不容易乱。三个好处，只花五秒钟。
第二件，上下文。这是最容易被忽略、也是最值钱的部分。用一两句话写清楚：这段代码解决什么问题，为什么这么写，有没有坑。上下文是半年后还能看懂的钥匙。
第三件，怎么用。写一个最小可用的调用示例，或者说明入口在哪里。让「存下来」和「用起来」之间只有一步。
一个例子：带重试的请求
我有一段「带重试的请求」代码，笔记是这样记的：
def request_with_retry(url, max_retries=3):
for i in range(max_retries):
try:
return requests.get(url, timeout=10)
except (requests.ConnectionError, requests.Timeout):
if i == max_retries - 1:
raise
time.sleep(2 ** i)
上下文：第三方接口偶尔抽风，网络抖动会让请求失败。重试 3 次，间隔按 2 的幂次递增，最后一次失败直接抛异常，不吞错。
怎么用：原来调 requests.get 的地方，直接换成 request_with_retry，其它参数不变。
这段笔记不到十行，但半年后翻到，三秒钟就能重新用起来，比重搜一遍网快多了。
组织上：集中放，标好语言
代码片段要集中放，不要散在项目笔记里。建一个「代码片段」目录，按语言或者按用途分。目录层级不要超过两层，代码是查的，不是翻的，层级越深越没人看。每条笔记的 frontmatter 里标上语言和标签。
语言标签是搜索的关键。记的时候花五秒钟标上 Python、Shell、SQL，搜的时候直接搜 language:Python 重试，结果一下就精准了。没有语言标签，搜「重试」会出来一堆不相关的东西。
命名用主题，不用类型。不要叫「Python代码1」「脚本备份2」，叫「请求重试函数」「数据库每日备份脚本」。名字里带上它解决什么问题，找起来才顺手。
复用这一步，很多人忽略。记了代码，就要让「用」这件事足够简单。常用的片段做成模板或者快捷命令，写笔记、写方案的时候一键插入。不常用的，保证能搜到就行。
说到底，这套方法不限于程序员。脚本、命令、SQL、公式、配置片段，凡是「一段可以反复用的东西」，都值得用三件套来记。知识库的价值不在存了多少，在能调出多少。
前几篇讲了闪卡、语音笔记、文件命名。系列还剩一个有意思的话题：知识库怎么和 AI 配合，把记下来的东西变成真正的产出。下一篇来说说。