笔记记了几千条，一次都没回看——不是工具问题，也不是自制力问题。根因只有一个：这些笔记没有消费场景。写的时候想的是"以后可能有用"，用的时候没有任何动作会去翻它。只进不出的仓库既不会变好，也不会被清理。
知识管理的判断链只有四环：为哪个动作而写 → 用什么结构 → 怎么被找到 → 怎么被再次使用。缺任何一环，系统都会退化成收藏夹。
1. 三种失效形态，同一个根因
| 形态 | 表面症状 | 真实原因 | 修复方向 |
|---|---|---|---|
| 只进不出 | 数量涨、打开率跌 | 没有触发回访 | 绑到项目或写作 |
| 找不到 | "我明明记过" | 只记结论，不记问题 | 加触发场景索引 |
| 不敢用 | 引用前要重新核实 | 无来源与时效标记 | 半衰期 + 来源 |
三种失效的共同点是消费端缺席。加标签、换工具、上双链，都是在生产端加码，对消费端没有任何作用。
2. 写下来的三种目的与最小结构
| 目的 | 回答什么 | 最小结构 | 消费场景 |
|---|---|---|---|
| 记录事实 | 谁在何时说了什么 | 结论 + 来源 + 日期 | 引用、复盘、对账 |
| 形成判断 | 我认为怎样、何时不成立 | 结论 + 依据 + 边界 | 决策、评审、写作 |
| 可执行步骤 | 遇到 X 做什么 | 触发条件 + 步骤 + 失败分支 | 排障、上线、交接 |
三者混在一篇里，就会出现"结论在第三段、来源在文末、命令散在中间"——写着顺手，用着取不出来。
---
title: 一句话结论（不是"关于 X 的思考"）
date: 2026-03-01
ttl: 180d # 半衰期，到期复审
source: 一手来源
status: draft|usable|stale
---
结论：是什么、给谁用、解决什么问题
依据：2–3 条可核对事实
边界：什么条件不成立
下一步：可执行动作
字段不多，但 ttl 与 source 决定它未来能否被信任；缺这两个字段，复用前必须重新核实，成本等于重写。
3. 检索的三条路与"搜不到自己写的"
| 路径 | 依赖 | 擅长 | 失效场景 |
|---|---|---|---|
| 按时间 | 日期、日志顺序 | 找回上周的决定 | 记不住时间就无从下手 |
| 按主题 | 目录、标签、双链 | 系统性回顾 | 词与当时不一致 |
| 按触发场景 | 问题索引 | 排障、决策复用 | 要多维护一层索引 |
搜不到自己写的东西，原因几乎总是这四个：用了当时的叫法（后来改名）、只记结论不记问题（搜的是问题，存的是答案）、标签自造同义词（k8s / kubernetes / 容器）、内容留在聊天工具里没进库。
命名约定（比标签更可靠）
2026-03-01 订单超时排查-连接池耗尽.md <- 时间 + 问题 + 关键词
problem-index.md
- 接口 P99 抖动 -> 2026-03-01 连接池耗尽
- 发布后 502 -> 2026-02-18 上游健康检查
按时间命名 + 一份手写问题索引，覆盖"记过但找不到"的多数场景，成本远低于维护标签体系。
4. 原子化的收益与代价
| 维度 | 原子化（一笔记一概念） | 长文（一次写透） |
|---|---|---|
| 连接密度 | 高，易引用 | 低，只能整篇引用 |
| 上下文 | 丢失，读者自己拼 | 完整，自带论证 |
| 组装成本 | 高，需额外组织 | 低 |
| 可维护性 | 单点更新 | 改一处要重读全篇 |
原子化不是目的，是提高被引用概率。判断标准：这条会被两个以上场景引用吗？会就拆，不会就写透一篇。拆得过碎会出现"十二条笔记讲同一件事"，维护成本比长文高一档。
5. 标签与双链的适用面
| 手段 | 解决的问题 | 收敛难点 | 规模化后的噪声 |
|---|---|---|---|
| 标签 | 横向归类、跨目录聚合 | 同义词与层级混乱 | 一条挂七八个标签，等于没分类 |
| 双链 | 表达概念关系 | 无法表达关系类型 | 反链膨胀，重要连接被淹 |
两条判据：标签控制在能记住的范围（数十个量级），新增前先找现成的；双链只连有因果或对比关系的两条笔记，"提到了"不算连接。价值在少而准。
6. 复习：三种触发，性价比差一个量级
| 机制 | 适合 | 成本 | 效果 |
|---|---|---|---|
| 间隔重复 | 事实、术语、命令 | 每日固定 | 牢，仅覆盖记忆类 |
| 主动回忆 | 判断、方法论 | 中，需自测题 | 高于重读，低于真用 |
| 按项目回访 | 工程判断、方案 | 低，搭在流程上 | 最高：检索时顺手修正 |
间隔重复的误用是套在"所有笔记"上：几千条排进队列，两周就放弃了。按项目回访性价比最高——项目需要时去检索，顺手改掉过期内容，消费与维护在同一次动作里完成。
# 回访队列：优先"被引用过 + 临近 ttl"的条目，而不是全部
rows = load_notes() # 解析 front-matter
due = [n for n in rows if n.ttl_due] # 到期复审
hot = [n for n in rows if n.backlinks > 0] # 有入链，说明在用
queue = sorted(due + hot, key=lambda n: n.last_opened)
队列只放两类：到期的、有人引用的。其余条目不进队列——它们的正确归宿是被清理，而不是被复习。
7. 写作即整理与复用的判据
费曼式改写的作用不是"加深理解"，而是暴露结构缺失：能用自己的话讲清结论、依据、边界，它就具备了被引用的形态；讲不清，说明还只是摘录。
| 复用判据 | 满足时的用法 | 不满足说明什么 |
|---|---|---|
| 能直接引用 | 贴进方案、文档、评审 | 缺结论或来源 |
| 能改写到新场景 | 迁移到相邻问题 | 缺边界条件 |
| 能变成可执行步骤 | 排障手册、交接文档 | 缺触发条件与命令 |
三条都不满足的笔记，本质是收藏品。收藏品不是罪，但不要给它维护成本：不打标签、不进复习队列、不建双链，让它安静待着。
# 引用旧笔记前过一遍
- 结论在第一段？ # 否则要替读者提炼
- 来源可点开核对？ # 否则引用即背书
- 边界写清？ # 否则迁移会出错
- status 是 usable？ # draft 不该被引用
8. 半衰期、过期标记与"剪藏等于没读"
| 内容类型 | 半衰期量级 | 复审 |
|---|---|---|
| 版本/API/参数 | 数月（按发布节奏核对） | 标 stale 或重写 |
| 工具用法与配置 | 半年到一年 | 跑一遍验证 |
| 方法论与框架 | 一到数年 | 查反例是否成立 |
| 原理性结论 | 很长 | 不必复审，标来源 |
ttl 把"可能过期"变成自动提醒，而不是靠记忆。没有 status 字段，复用默认动作就是"重新核实"，每条重付一次成本。
剪藏是高发区：原文一字不改、没有一句说明"为什么存它"，这种条目只制造噪声。导入时必须改写：一句话结论 + 为什么需要它 + 它替代了哪个原有认知。做不到就别导入。
9. 团队库与个人库的边界
| 维度 | 个人笔记 | 团队知识库 |
|---|---|---|
| 准入 | 低，允许半成品 | 高，可执行、有 owner |
| 形态 | 判断、草稿、摘录 | 流程、决策记录、手册 |
| 过期 | 自己知道就行 | 复审人与周期 |
| 失败模式 | 收藏夹 | 无人维护的公告栏 |
混用的后果：个人判断进团队库被当规范执行；团队流程塞进个人笔记没人看。分界很简单——别人要照着做的进团队库，自己想明白的留个人库。
10. 度量：哪些笔记真的在被使用
| 指标 | 采集方式 | 说明什么 | 陷阱 |
|---|---|---|---|
| 入链数 | 统计反向链接 | 被笔记依赖 | 自建链接墙虚高 |
| 打开次数 | 编辑器/命令历史 | 实际回访 | 打开≠使用 |
| 被外部引用 | 文档里的链接 | 真实复用 | 需带链接才可测 |
| 无入链且未打开 | 两项都为 0 | 清理候选 | 可能是刚写的 |
# 粗略盘点：无入链且半年未打开
$ grep -rLo "\[\[.*\]\]" notes/ | sort > /tmp/linked.txt
$ ls -t notes/*.md | tail -n +200 | sort > /tmp/cold.txt
$ comm -12 /tmp/linked.txt /tmp/cold.txt
度量的目的不是考核，是清理：无入链、长期未打开的内容占着检索位，拉低信噪比。定期清掉它们，比新增功能有效。
11. 工具选择的判据
| 判据 | 权重 | 为什么 |
|---|---|---|
| 导出（Markdown + 附件 + 链接） | 最高 | 决定五年后能否迁走 |
| 本地文件优先 | 高 | 同步失败仍可读写 |
| 检索速度 | 高 | 库大了只剩这个入口 |
| 链接实现质量 | 中 | 影响连接可用性 |
| 插件生态 | 低 | 插件寿命短于笔记 |
| 云端协作 | 按需 | 团队场景才需要 |
笔记寿命以十年计，工具以三年计。导出能力是唯一能跨过工具更替的东西，功能在换工具那天全部归零。
12. 排错
| 现象 | 原因 | 处理 |
|---|---|---|
| 记了很多但从不回看 | 没有消费动作 | 绑到项目/写作流程，删掉无用途条目 |
| 搜关键词搜不到 | 用词与当时不一致 | 加问题索引，标题写问题而非主题 |
| 同一概念多条笔记 | 拆得太碎 | 合并成一篇，保留双向引用 |
| 标签越加越多 | 无收敛规则 | 设上限，新增前先复用 |
| 不敢引用旧笔记 | 无来源/无时效 | 补 source 与 ttl，标 stale |
| 团队库没人维护 | 无 owner 与复审 | 指定 owner 与周期，或降级为个人库 |
13. 边界：什么时候不需要系统
| 场景 | 更合适 | 理由 |
|---|---|---|
| 笔记量不足几百条 | 全文搜索 + 文件夹 | 结构成本高于检索收益 |
| 纯收集型需求 | 收藏夹 + 定期清理 | 没有消费场景，系统救不了 |
| 一次性项目 | 项目目录内几页文档 | 生命周期短于体系建设周期 |
| 团队知识库与个人笔记混用 | 拆成两个库 | 准入标准冲突 |
| 没有任何输出场景 | 先建立输出，再谈体系 | 无消费端的系统必然退化为仓库 |
知识管理的门槛不是工具，是有没有一个非用不可的动作。没有输出、没有项目、没有交接需求时，最有效的做法是把收藏夹清空，而不是搭一套更精致的体系。
14. 自测
- 笔记"只进不出"的根因是什么？加标签能解决吗？
- 三种写作目的各自需要哪个最小结构字段？
- "我明明记过却搜不到"，最常见的四个成因是什么？
- 什么时候该把一篇笔记拆成原子笔记？判断标准是什么？
- 为什么"按项目回访"的性价比高于间隔重复？
- 选笔记工具时，哪一项判据应该排在功能丰富度之前？