一个工程师的笔记库有 3,000 条，标签体系有 40 个。而他说"找不到东西"——不是因为没有记录，而是因为每一条都"看起来有用"，于是"检索"变成了"在噪声里翻"。而他从没删过任何一条。
知识管理的瓶颈几乎从不在"输入"，而在"淘汰"。因为收集是"加法"（低阻力、有即时满足），而淘汰是"减法"（需要判断、会带来"可能有用"的焦虑）。
1. 三个动作的成本不对等
| 动作 | 成本 | 即时反馈 |
|---|---|---|
| 收集 | 极低（一键保存） | 有（"我记住了"） |
| 整理 | 中（分类、标签） | 弱 |
| 淘汰 | 高（要判断价值） | 无（甚至焦虑） |
第三项还有个"沉没成本"成分：收集时花过时间，于是删它像"浪费之前的投入"——而实际上"不删"才是持续浪费注意力。
这个不对等解释了"为什么笔记库只增不减"：收集的反馈是即时的，淘汰的反馈是缺失的。
这个方向转换很重要，因为**"怎么记"已经被工具解决了**（一键剪藏、自动摘要），而"怎么删"至今没有好工具——它仍然是"人做判断"。
所以"知识管理"要解决的不是"怎么记"，而是"怎么让淘汰变得便宜"。
2. 三种"让淘汰便宜"的机制
| 机制 | 说明 |
|---|---|
| 自动过期（按类型） | 到期未回顾即删除 |
| 使用度排序（按访问） | 长期未访问的标记为"候选删除" |
| 一次性归档（不进检索） | 保留但不占用注意力 |
第三项是最实用的折中：**"归档"不等于"删除"**第三项的"心理优势"在于"可逆"：归档的条目还在，只是不出现——于是"决定"变得轻，而"轻的决定"才会被执行。
，它只是"不再出现在搜索结果里"——于是"删除的焦虑"被绕开，而"噪声"被消除。
// 三种处理的差别（对"当时觉得有用"的条目）
保留：占检索结果，每次都要判断"要不要看"
归档：不占检索，需要时能查到（按日期/标签）
删除：不占任何空间，也确实找不回来
// 建议：先归档，半年后仍未被访问 → 删除
3. 什么该保留、什么该归档
| 类型 | 处理 |
|---|---|
| 结论与判据（"为什么要这样做"） | 保留（长期有效） |
| 具体操作步骤 | 归档（工具一变即过期） |
| 链接与出处 | 归档（会失效） |
| 当时的思考过程 | 归档（有情境价值，但少查） |
| 已内化的知识 | 删除（不再需要查） |
第五项的"识别"方式是"看自己"是否还会打开它"：如果一年没打开，而"要做这件事时也不用查"，那它已经内化。
第五项最反直觉："已经会了的东西"不需要笔记。而它恰恰是"笔记最多"的那类——因为"学会时最有动力记"。
判据是"我还会不会查它"：如果"已经完全内化"，查的概率接近零。
"归档"要有可执行的判据，否则"归档"也会变成"再判断一次"：
// 三条自动归档规则（不需要逐条判断）
1 类型为"操作步骤"且超过 90 天未访问 → 归档
2 类型为"链接/出处" → 入库即归档，只保留标题与结论
3 与本条主题重复度 > 0.8 的旧条目 → 合并后归档
// 关键：规则按"类型 + 时间"自动跑，人只处理例外
4. 整理的"最小可持续"形式
| 形式 | 成本 |
|---|---|
| 严格分类体系（40 个标签） | 高（维护不动） |
| 少量入口（3–5 个主题 + 时间） | 低 |
| 只按"项目"归档 | 极低 |
| 只靠搜索 | 零（但噪声大） |
第一项是"整理失败"的典型：标签体系越精细，维护成本越高，于是半年后没人维护第一项的"边际"很容易算：每加一个标签，"新条目的归属"就多一次判断——而判断的成本随"标签数 × 条目数"增长，于是"精确"与"可持续"直接冲突。
，而检索还是靠搜索。
第二项的"少量入口"是可持续的：主题少到"不必想"，加上"时间"作为第二维度即可。
"入口数量"可以按"一个月内用到的主题数"反推：你一个月真正动手做过的主题，通常不超过 5 个——而"5 个主题 + 时间"就是够用的入口。
// 入口设计（5 个主题 + 时间线）
主题：Java/JVM · 数据库/缓存 · 架构/协作 · 学习方法 · 工具与实测
另加：按"月"归档（用于"我当时怎么想"的回顾）
// 反例：40 个标签 → "给新条目选标签"变成一次小决策，于是拖延
5. 复习该怎么安排
| 方式 | 效果 |
|---|---|
| 定期全量回顾 | 不可持续（量大） |
| 按"待复习"队列 | 有效（只看到期的） |
| 用的时候才看 | 最省（但可能忘） |
| 输出时回查 | 有效且自然 |
第四项的"额外收益"是"淘汰"：搜到的条目若与当前需求无关，就顺手标记"可归档"——于是"整理"分散到每次使用时，而不必"专门安排一天"。
第四项最被低估：写东西时回查旧笔记，是"用中学"的自然复习——它不需要"额外安排时间"，而检索本身就强化了记忆。
// 复习的"最小安排"（零额外时间）
每次写文档/做题/排障时：
1 先搜自己的笔记（而不是先搜网络）
2 搜到的条目：用则强化，不用则标记"可归档"
// 收益：检索 + 复习 + 淘汰三件事合并成一个动作
"检索"本身的体验决定了"笔记是否被用"：如果搜自己的笔记比搜网络还慢，那笔记就死了。
// 三个"能被搜到"的要求
1 标题写"问题"而不是"主题"（"如何排查 Full GC" 优于 "JVM 笔记"）
2 正文包含"关键词的自然写法"（不止术语）
3 一条一个主题（长文拆条，便于命中）
// 判据：用自己常搜的 5 个词，能否一次命中
6. 排错：五种"笔记越记越没用"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 找不到东西 | 只增不减 | 归档 + 搜索 |
| 标签太多不用 | 体系过细 | 减到 5 个 |
| 记了不看 | 无"回顾触发" | 用的时候先搜自己的 |
| 重复记录同一件事 | 无去重 | 入库前先搜 |
| 焦虑不敢删 | 无"归档"这一步 | 先归档后删 |
第四项的成本很高：同一件事记三遍，检索时出三条第四项（重复记录）的修法是"入库前先搜 10 秒"：于是"要么找到旧的补充它，要么确认没有才新建"——而它顺手解决了"记录分散"。
——而它们内容略有差异，于是"到底信哪条"又成了新问题。
最后一个"度量"：笔记库的"命中率"——即"打开笔记的次数 / 搜索次数"。
// 两个可自测的数（每月一次，五分钟）
1 搜索次数 vs 打开次数：比值 < 0.3 → 搜了但没找到（噪声太大）
2 最常打开的 10 条：是否覆盖你 80% 的实际需求（是 → 其余可归档）
// 用法：第 2 项很有效——多数人真正反复用的笔记不超过 50 条
7. 边界：什么情况不必管理
| 场景 | 为什么 | 做法 |
|---|---|---|
| 只为一个项目服务 | 项目结束即弃 | 不管理 |
| 纯日志式记录（时间线） | 只增不减合理 | 按时间查 |
| 笔记量很小（< 100 条） | 搜索够用 | 不管理 |
| 已有团队知识库 | 有人维护 | 跟随 |
最后一条与"团队"有关的边界：个人笔记与团队知识库要分开。因为"个人笔记"允许"粗糙、只增不减"，而"团队库"必须"可检索、有人负责淘汰"——两者的管理强度不同。
判断口径一句话："我是否曾经"想找一条笔记但找不到"。有过，就需要淘汰与少量入口；没有（量小、搜索够用），管理本身是浪费。
8. 自测
- 三个动作的成本为什么"不对等"？它如何导致"只增不减"？
- 为什么"归档"是"让淘汰变便宜"的关键？它与"删除"的差别是什么？
- 哪一类笔记最该"删除"？为什么它恰恰是"记得最多"的那类？
- 为什么"40 个标签"的体系会失败？"少量入口"为什么可持续？
- "写东西时回查旧笔记"为什么能同时完成检索、复习与淘汰？
- 判断"是否需要管理"的那个问题是什么？