一个工程师的笔记按"日期"组织：2026-03-12.md、2026-05-08.md。半年后有 80 个文件，而他找"如何排查死锁"时，只能"逐个打开搜"——因为"死锁"这件事没有"自己的位置"，它散落在三个日期里。
线性记录（按时间）是"最省事"的，而它把"检索"的成本推迟到"需要的时候"。这个"聚在一起"的价值随时间增长：记录时多花 10 秒想"放哪"，检索时省 10 分钟翻文件——而它只在"你会回来查"时成立。
而"结构"的价值不在于"整齐"，而在于"让同一主题的东西聚在一起"。
1. 三种组织方式的成本
| 方式 | 记录成本 | 检索成本 |
|---|---|---|
| 按时间（日记式） | 最低 | 最高 |
| 按主题（一个主题一个文件） | 中（要想"放哪"） | 低 |
| 双维（主题 + 时间内的条目） | 中高 | 最低 |
第二项的"中"是"决策成本"：**每次记录要判断"这属于哪个主题"**第二项的"决策成本"常被高估：多数记录"一看就知道放哪"（"死锁"→排查·并发），真正难判的不到 10%——于是"想不出放哪"时，用一个"暂存"文件兜住即可。
——而它恰恰是"检索友好"的来源。
2. "按时间记"失效的三个时刻
| 时刻 | 表现 |
|---|---|
| 找一个"方法" | 只记得"当时解决过"，不记得哪天 |
| 做"主题复盘" | 材料散在十几个文件里 |
| 交接/分享 | 只能"给整个目录" |
第一项的"机制"是"时间不是线索，事件才是"：你记得"那是死锁"，而不是"那是三月"——于是"按时间组织"等于"按一个你不会记得的键组织"。
第一项最典型："哪天"是最难回忆的维度——而"主题"是最好回忆的（"那是关于死锁的"）。
"归档"是"长期可维护"的必要动作，而它的判据是"条目数"：
// 三种"归档"触发（按条目数）
< 50 条：不归档（打开还不慢）
50–200 条：半年归档一次（旧条目移到 archive/）
> 200 条：按年分文件（concurrency-2025.md、concurrency-2026.md）
// 判据：打开文件时"要不要滚动很久"才找到最新的
3. "主题"该怎么切
| 切法 | 问题 |
|---|---|
| 按技术栈（Java/DB/前端） | 太粗，一个文件几百条 |
| 按问题（排查/设计/学习） | 好（与"何时会查"对齐） |
| 按项目 | 项目结束即废 |
第二项是"最实用"的：它按"你什么时候会来看"切第二项的"四类"基本够用：排查（出事时）、设计（动手前）、学习（成长时）、工具（配置时）——而"分类超过五类"就会"每次都要想"。
——"排查"是"出事时看"，"设计"是"动手前看"。
"文件命名"本身就是"结构"，而它比"目录层级"更容易维护：
// 三种命名（从差到好）
notes/2026-05-08.md ← 按时间，检索最差
notes/java/deadlock.md ← 按技术栈，主题太粗
notes/troubleshoot/concurrency.md ← 按"何时会查"，推荐
// 判据：文件名能否"回答'我什么时候会打开它'"
4. "双维"的落地形式
| 形式 | 说明 |
|---|---|
| 一个主题一个文件，内部按时间倒序 | 最简单（推荐） |
| 一个主题一个目录，每条一个文件 | 适合"条目多" |
用标签（#deadlock）跨文件 |
需"检索工具"支持 |
第一项的"代价"是"文件会变长"：一个主题积累 200 条时，"打开就卡"——于是它需要"半年一归档"（旧条目移到 archive/）。
第一项是"零工具依赖"的：文件开头是"最新的一条"，往下是旧的——于是"打开就看到最近的"。
// 一个"可检索"的主题文件（结构）
// 排查 · 并发
## 2026-05-08 死锁：jstack 里"循环等待"的三种形态
结论：先看 "waiting to lock"，再看持有者
## 2026-03-12 线程数暴涨：先看 pool 配置
结论：默认池可能 200，先确认再改
// 关键：标题里含"主题词 + 结论"，于是"搜文件"就能命中
"一条记录"的最小结构是三段，而它比"随手写"多花 15 秒：
// 三段式（标题 / 现象 / 结论）
## 死锁：jstack 里"循环等待"
现象：请求卡在 waiting to lock，且两个线程互为持有者
结论：先定位持有者，再看"加锁顺序"是否相反
// 收益：三个月后"只看标题与结论"就能复用，不必读过程
5. "标题"决定可检索性
| 标题写法 | 可检索 |
|---|---|
| "今天的收获" | 不可 |
| "死锁排查" | 可 |
| "死锁：jstack 三种形态 + 结论" | 最好 |
第三项把"结论"也写进标题：于是"搜关键词"直接看到"答案的方向"第三项的"写法"要短："死锁：先看 waiting to lock"比"关于死锁的一些思考与总结"好用——前者是"可搜的"，后者是"可读的"。
，不必"打开再读"。
"入库前先搜"能解决"重复记录"，而它只要 10 秒：
// 三步入库（10 秒）
1 搜关键词（同义词也算）：deadlock / 死锁 / 循环等待
2 命中 → 在旧条目"追加"（带新日期），而不是新建
3 未命中 → 新建，放到"何时会查"的目录下
// 收益：同一主题"始终一条主线"，而不是"散在五处"
6. 排错：五种"笔记结构问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 找不到 | 按时间组织 | 改主题 |
| 一个文件几百条 | 主题太粗 | 再切 |
| 记了不知道放哪 | 没有"问题维度" | 用"何时会查"切 |
| 同一件事记多处 | 无"先搜再记" | 入库前搜 |
| 换了工具全乱 | 依赖标签/工具 | 用文件结构 |
7. 边界：什么情况"按时间"就够
| 场景 | 为什么 | 做法 |
|---|---|---|
| 日志式的"每日小结" | 本来就按时间看 | 按时间 |
| 短期项目（< 1 个月） | 条目少 | 按时间 |
| 只记"结论"（不记过程） | 一条一句 | 一个文件 |
| 已有"全文检索"很强 | 结构不重要 | 随意 |
最后一条与"迁移"有关的边界：从"按时间"迁到"按主题"不必重写：先把"最近三个月"的条目按主题重排，旧文件不动——于是"新结构"立刻可用，而"旧结构"留在原地当历史。
判断口径一句话："我会按"什么时候"去找，还是按"什么问题"去找"。按问题找（"死锁怎么排查"），就必须"主题结构化"；按时间找（"上个月做了什么"），时间线更合适。
补一个"检索"的实操：给每个主题文件加一行"索引"——文件开头列 5–10 个"最有用的条目"（带链接锚点），于是"打开就看到目录"，而不必滚动。这条对"200 条以上"的文件尤其有效，且它比"改用数据库"便宜得多。
再补一条"边界"："结构"不该成为"记录的门槛"——如果"想放哪"卡住了 30 秒，就先记到"inbox.md"，每周清一次。先把"记下来"做完，结构可以补；反之则会"因为没结构而不记"，那才是最大的浪费。
最后一个"团队"视角：个人笔记可以"只对自己友好"，而团队知识库必须"对新人也友好"——前者允许"inbox 兜底、结构松散"，后者要求"命名统一、索引齐全、有归档规则"。把两者混在同一个仓库里，通常的结果是"个人部分杂乱、团队部分过时"；分开之后，各自都能按"自己的成本"演化。
这条分界也解释了"为什么笔记工具换来换去体验没变"：变的是工具，没变的是"组织方式"——而后者才是检索快慢的真正变量。
8. 自测
- 三种组织方式的"记录成本/检索成本"分别是什么关系？
- 为什么"按时间记"在"找一个方法"时失效？"日期"为什么难回忆？
- "按问题切"为什么"与何时会查对齐"？
- "双维"的最简形式是什么？为什么它"零工具依赖"？
- 为什么"标题里写结论"能提升可检索性？
- 判断"该按时间还是按主题"的那个问题是什么？