Distill：我用"三层高亮法"让笔记从"存过"变成"拿来就用"
一只阿木木约 16 分钟Distill：我用"三层高亮法"让笔记从"存过"变成"拿来就用"
上周发生了一件很尴尬的事。
老板让我出一份"数据中台技术选型建议"，给 CTO 汇报用。
我打开 Obsidian，搜索"数据中台"——搜到了 7 条相关笔记。
按理说，我应该很开心：经过这两个月的知识管理实践，我的 PARA 目录井井有条，Inbox 每周清零，相关资料都能搜到。
但我打开那 7 条笔记后，傻了。
第一条：一篇技术文章的全文摘录，1800 字，密密麻麻。我需要重新从头读一遍才能找到关键结论。
第二条：一段会议讨论记录，写了"讨论了 Lambda 架构和 Kappa 架构的优劣"，但没有写结论是什么。
第三条：一个收藏的链接，标注了"不错的对比文章"，但没有任何提炼。我点开链接——404 了。
第四条：倒是写了一句我自己的批注——"ClickHouse 适合 OLAP 场景"。但这句话太笼统了，我记不清当时的分析逻辑了。
剩下三条大同小异：有存，有组织，但没有"提炼"。
结果：我面对 7 条笔记，却几乎无法直接引用其中任何一条。我还是得重新搜索、重新阅读、重新思考。
这就像我建了一个数据仓库，数据都入库了，但没有做聚合、没有建宽表、没有写报表。原始数据堆在那里，要用的时候还得现跑 SQL。
这时候我才真正理解了 CODE 四步中第三步 Distill（提炼） 的意义：
Capture 解决的是"有没有"的问题。
Organize 解决的是"找不找得到"的问题。
Distill 解决的是"拿起来能不能直接用"的问题。
前两步做得再好，没有 Distill，你的知识库就是一堆"原始数据"——有价值，但提取价值的成本太高。
今天这篇，我来讲我是如何用**"三层高亮法"**把笔记从"存过"变成"拿来就用"的。
一、先理解 Distill 的本质：把"整篇笔记"压缩成"一眼能用"
Tiago Forte 在《打造第二大脑》里提出了一个核心概念叫 Progressive Summarization（渐进式总结）。
这个概念翻译成人话就是：
不要一次性把笔记整理成"完美状态"。而是每次接触这条笔记时，多做一层提炼——让它逐渐从"原始信息"变成"浓缩精华"。
为什么是"渐进式"？
因为你在 Capture 的时候，不知道这条笔记以后会怎么用。如果当场花 30 分钟写一篇精炼总结，很可能这条笔记以后根本用不到——那 30 分钟就白费了。
但如果你完全不提炼，等真正要用的时候再来整理，你已经忘了原文在讲什么——又要花 30 分钟重新理解。
渐进式总结的策略是：每次多花一点点时间，逐层提炼。
第一次接触（Capture）：存原文要点 + 一句话批注 → 1 分钟 第二次接触（Organize/Distill）：加粗关键句子 → 2 分钟 第三次接触（Distill/Express）：写出自己的总结 → 5 分钟
不是每条笔记都需要走完三层。只有被反复使用的笔记才值得深度提炼。
这就是"渐进"的含义：让笔记的"提炼深度"跟它的"使用频率"自然匹配。常用的自然越磨越精，不用的就停留在第一层，不浪费时间。
程序员类比：这就是 JIT 编译（Just-In-Time Compilation）。不是提前把所有代码都编译成机器码（AOT），而是运行时哪段代码被频繁执行（热点代码），才对它做深度优化。冷代码保持原样，不浪费编译资源。
二、三层高亮法：我在 Obsidian 里的具体做法
我把渐进式总结落地成了一套可操作的"三层高亮法"。每一层对应一个操作动作，层层递进。
Layer 0：原始状态（Capture 阶段已完成）
这是笔记刚进入 Obsidian 时的样子——有内容，有批注，但没有任何视觉层次。
示例：一条关于"CQRS 架构模式"的笔记
# CQRS 架构模式> 来源：技术评审会讨论 + 文章阅读
> 日期：2024-05-10
> 关联：[[P-订单系统重构]]
CQRS 全称是 Command Query Responsibility Segregation，
即命令查询职责分离。核心思想是把系统的读操作和写操作
分离到不同的模型中处理。
传统的 CRUD 模式中，读和写共享同一个数据模型。当业务
复杂度增加时，一个模型很难同时满足复杂查询和复杂写入
的需求。CQRS 通过分离来解决这个矛盾。
Command 端（写）负责处理业务逻辑、校验规则、状态变更。
Query 端（读）负责提供查询视图，可以使用独立的读库、
缓存或搜索引擎来优化查询性能。
适用场景：读写比差异大的系统（如读多写少的电商商品页）、
读写模型差异大的系统（如订单系统写入复杂但查询简单）。
不适用场景：简单的 CRUD 系统、读写量差不多的系统。
引入 CQRS 会增加系统复杂度（需要维护两套模型和数据同步）。
CTO 在评审会上说了一句话："不要为了架构优雅引入团队
驾驭不了的复杂度。"决定先在订单模块试点，不全面推广。
💡 我为什么存：订单重构正在选型，CQRS 是候选方案之一。
📌 可以用在：P-订单系统重构 的技术方案文档。
这是一条"合格"的笔记——有来源、有内容、有批注。但如果三个月后我要快速引用它，我需要重新读这一整段文字才能提取出关键信息。
Layer 1：加粗关键句（第一次提炼，耗时 2 分钟）
触发时机： 当我第二次打开这条笔记的时候（比如在 Organize 阶段把它从 Inbox 移到 Projects 时，或者在写方案时搜索到它时）。
操作： 通读一遍，把最关键的句子加粗。标准是：如果你只能读这条笔记中的 3 句话，你会读哪 3 句？
# CQRS 架构模式> 来源：技术评审会讨论 + 文章阅读
> 日期：2024-05-10
> 关联：[[P-订单系统重构]]
CQRS 全称是 Command Query Responsibility Segregation，
即命令查询职责分离。**核心思想是把系统的读操作和写操作
分离到不同的模型中处理。**
传统的 CRUD 模式中，读和写共享同一个数据模型。当业务
复杂度增加时，一个模型很难同时满足复杂查询和复杂写入
的需求。CQRS 通过分离来解决这个矛盾。
Command 端（写）负责处理业务逻辑、校验规则、状态变更。
Query 端（读）负责提供查询视图，可以使用独立的读库、
缓存或搜索引擎来优化查询性能。
**适用场景：读写比差异大的系统、读写模型差异大的系统。**
不适用场景：简单的 CRUD 系统、读写量差不多的系统。
引入 CQRS 会增加系统复杂度（需要维护两套模型和数据同步）。
**CTO："不要为了架构优雅引入团队驾驭不了的复杂度。"
决定先在订单模块试点，不全面推广。**
💡 我为什么存：订单重构正在选型，CQRS 是候选方案之一。
📌 可以用在：P-订单系统重构 的技术方案文档。
现在你快速扫一眼这条笔记，30 秒就能抓到核心：分离读写 / 适用于读写比差异大 / CTO 说先试点不全推。
不用逐字阅读，只看加粗部分就够了。
Layer 2：写出"我的总结"（第二次提炼，耗时 5 分钟）
触发时机： 当我真正要使用这条笔记的时候（比如写技术方案、准备汇报、或者向别人解释这个概念时）。
操作： 在笔记顶部新增一个 ## 我的总结 区块，用自己的话写出核心结论。这段总结的标准是：如果有人只看这段总结就能理解要点，不需要再看下面的原文。
# CQRS 架构模式> 来源：技术评审会讨论 + 文章阅读
> 日期：2024-05-10
> 关联：[[P-订单系统重构]]
## 📝 我的总结（Layer 2）
CQRS 的本质是"读写分家"：写的时候走复杂的业务逻辑，
读的时候走独立的查询优化（可以用 ES、Redis、宽表等）。
适合我们订单系统的原因：
1. 订单写入逻辑复杂（校验库存、优惠、支付），但查询简单（列表+详情）
2. 读写比约 10:1，读远多于写
3. 可以只在订单模块试点，不影响其他系统
风险提醒：
- 引入了"读写数据同步"的额外复杂度
- 团队没有 CQRS 经验，需要预留学习成本
- CTO 原话："不要为了架构优雅引入团队驾驭不了的复杂度"
→ 结论：适合试点，不适合全推。写进方案时用"渐进式引入"的策略。
---
（以下为原始笔记内容，供查阅）
......
现在这条笔记的结构变成了：
┌─────────────────────────────────────┐
│ 📝 我的总结（30秒读完，直接引用） │ ← Layer 2
├─────────────────────────────────────┤
│ 加粗关键句（1分钟扫读，快速回忆） │ ← Layer 1
├─────────────────────────────────────┤
│ 原始内容（需要时深入阅读） │ ← Layer 0
└─────────────────────────────────────┘
它变成了一个"分层"的结构。
时间紧的时候：只看 Layer 2 的总结，30 秒搞定 需要回忆细节：扫一眼 Layer 1 的加粗部分，1 分钟搞定 需要深入查阅：读 Layer 0 的原始内容
程序员类比：这就是缓存的三级架构。
Layer 2（我的总结）= L1 Cache（CPU 一级缓存，最快，容量最小）
Layer 1（加粗关键句）= L2 Cache（二级缓存，较快，容量中等）
Layer 0（原始内容）= 主存/磁盘（最慢，容量最大）
大多数场景下你只需要命中 L1 Cache（看总结）就够了。只有 Cache Miss 的时候才需要往下查。
Layer 3（可选进阶）：提炼成"原则卡"
触发时机： 当某条笔记被我在 3 个以上不同场景中使用过时。
操作： 把核心经验抽象成一条"可跨场景复用"的原则，独立成一条新笔记，放入 Areas。
示例：从 CQRS 笔记中提炼出的原则卡
# 架构决策原则：渐进式引入> 来源：[[CQRS架构模式]] [[微服务拆分复盘]] [[消息队列选型]]
> 领域：[[A-后端技术]]
## 原则
> 引入新架构模式时，不要全面推广，先在一个模块试点。
> 试点成功后再逐步扩展。
## 适用场景
- 团队没有该技术的实战经验
- 新技术引入会增加系统复杂度
- 业务不允许大面积重构
## 反面案例
- 我们 2023 年直接全量引入 DDD，
结果团队理解不一致，代码风格混乱，反而更难维护
## 一句话版
> "不要为了架构优雅引入团队驾驭不了的复杂度。"—— CTO
注意这条原则卡的特点：
脱离了原始场景——它不再是"CQRS 的笔记"，而是一条通用的"架构决策原则" 可跨场景复用——下次做任何技术选型时都能参考 有正面和反面案例——不是空洞的道理，是有证据支撑的经验
这就是知识从"信息"到"智慧"的跃迁。
程序员类比：Layer 0-2 是"具体实现"，Layer 3 是"接口抽象"。当你把具体经验抽象成通用原则，它就可以被不同的"业务场景"调用了——就像一个 interface 可以有多个 implementation。
三、完整的三层高亮法流程图
一条笔记的提炼之旅
═══════════════════════════════════════════════Layer 0（Capture 阶段）
┌─────────────────────────────────────┐
│ 原始内容 + 一句话批注 │
│ 耗时：1分钟 │
│ 状态：能搜到，但需要重新阅读才能用 │
│ 触发：Capture 时自动完成 │
└────────────────┬────────────────────┘
│
第二次打开这条笔记时
│
▼
Layer 1（加粗关键句）
┌─────────────────────────────────────┐
│ 通读一遍，加粗 3-5 个关键句 │
│ 耗时：2分钟 │
│ 状态：扫一眼就能回忆起要点 │
│ 触发：Organize 移动时 / 偶然翻到时 │
└────────────────┬────────────────────┘
│
真正要使用这条笔记时
│
▼
Layer 2（写我的总结）
┌─────────────────────────────────────┐
│ 在笔记顶部用自己的话写核心结论 │
│ 耗时：5分钟 │
│ 状态：30秒读完总结就能直接引用 │
│ 触发：写方案 / 写文章 / 汇报准备时 │
└────────────────┬────────────────────┘
│
被3个以上不同场景复用时
│
▼
Layer 3（提炼原则卡）[可选]
┌─────────────────────────────────────┐
│ 抽象成跨场景通用原则，独立成新笔记 │
│ 耗时：10分钟 │
│ 状态：成为你的"个人方法论" │
│ 触发：发现同一条经验被反复使用时 │
└─────────────────────────────────────┘
注意：
→ 不是每条笔记都要走到 Layer 3
→ 大部分笔记停留在 Layer 0 或 Layer 1 就够了
→ 只有"被反复使用"的笔记才值得深度提炼
→ 提炼是"按需触发"的，不是"批量执行"的
四、哪些笔记值得 Distill？80/20 法则
讲完了"怎么做"，接下来讲一个同样重要的问题："做不做"。
因为如果你对每条笔记都做三层提炼，你会累死。
实际数据： 在我的 107 条笔记中：
只有 16% 的笔记被深度提炼过。但恰恰是这 16% 的笔记，贡献了我 80% 以上的"直接引用"。
这就是典型的 80/20 法则（帕累托原则）。
所以你不需要纠结"每条笔记要不要提炼"。只需要掌握一个判断标准：
当你第二次打开一条笔记时，才值得做 Layer 1。
当你要在某个交付物中引用它时，才值得做 Layer 2。
当你发现自己反复引用同一条经验时，才值得做 Layer 3。
如果一条笔记从存下来到现在你一次都没有打开过——不用提炼，让它安静地躺着就好。
程序员类比：这就是 LRU 缓存策略。不是所有数据都需要被缓存。最近被访问过的、频繁被访问的数据才放进缓存。其他的留在磁盘里，需要的时候再加载。
五、一个完整案例：20 条碎片 → 1 条原则卡
理论讲完了，来看一个从头到尾的真实案例。
背景： 在做"Q2 用户分层营销"项目的过程中，我在不同时间点 Capture 了大量碎片信息。项目做完后，我做了一次集中的 Distill，把碎片"蒸馏"成了可复用的原则。
第一阶段：散落的碎片（Layer 0）
在项目推进的 6 周里，我在不同地方存了这些笔记：
P-Q2用户分层营销/
├── RFM模型理论笔记.md → 一篇文章的摘录
├── RFM电商案例.md → 另一篇文章的摘录
├── 竞品用户分层调研.md → 3个竞品的截图和链接
├── 跟产品讨论纪要0503.md → 会议记录
├── 跟产品讨论纪要0510.md → 又一次会议记录
├── 跟产品讨论纪要0520.md → 又一次会议记录
├── 数据分析-用户活跃度分布.md → SQL 查询结果和图表
├── 数据分析-付费用户特征.md → 另一组数据分析
├── RFM指标定义讨论.md → 跟数据团队的讨论
├── 分层方案v1.md → 第一版方案（被否了）
├── 分层方案v2.md → 第二版方案（通过了）
├── 分层方案v2-评审纪要.md → 评审会议记录
├── 人群包SQL代码.md → 实际跑数的 SQL
├── 投放素材A版.md → 营销素材记录
├── 投放素材B版.md → 营销素材记录
├── ABTest结果0601.md → 第一轮测试结果
├── ABTest结果0615.md → 第二轮测试结果
├── ROI数据汇总.md → 最终效果数据
├── 老板反馈记录.md → 汇报后的反馈
└── 项目复盘会纪要.md → 复盘会议记录共 20 条笔记
这 20 条笔记记录了一个项目的完整过程。但如果你让我回答"下次做用户分层应该怎么做"，我需要把这 20 条全翻一遍才能拼凑出答案。
第二阶段：选择性提炼（Layer 1 + Layer 2）
项目结束后，我花了一个小时对这 20 条笔记做了一次"选择性提炼"。
不是每条都提炼。我只对"未来可能被复用的"笔记做处理：
20 条笔记中，我只对 7 条做了提炼。其余 13 条保持原样直接进入 Archives。
第三阶段：蒸馏为原则卡（Layer 3）
在提炼的过程中，我发现了 3 条"跨项目可复用"的经验。我把它们独立成了原则卡，放入 Areas。
原则卡 1：用户分层的"指标适配"原则
# 原则：用户分层模型必须做"指标适配"> 来源：[[P-Q2用户分层营销/复盘]]
> 领域：[[A-数据与增长]]
> 被验证次数：1（首次总结，待后续验证）
## 原则内容
> 经典模型（如 RFM）不能直接照搬，
> 必须根据自身业务特征替换指标定义。
## 我们的适配方案
| RFM 原始指标 | 电商定义 | 我们的定义（SaaS） | 替换原因 |
|---|---|---|---|
| R（最近交易时间） | 最近一次购买 | 最近一次登录 | 我们不是交易型产品 |
| F（交易频率） | 购买次数 | 核心功能使用频次 | 使用深度比购买次数更能反映活跃度 |
| M（交易金额） | 消费总额 | 当前订阅套餐金额 | SaaS 是订阅制，不是单次消费 |
## 教训
- v1 方案失败就是因为直接套用了电商的 RFM 定义
- v2 成功是因为跟产品+数据一起重新定义了每个指标的业务含义
## 一句话版
> 别抄别人的指标，先问自己：这个指标在我的业务里代表什么？
原则卡 2：AB测试的"先跑小样本"原则
# 原则：AB测试先用 5% 流量跑 3 天> 来源：[[P-Q2用户分层营销/ABTest总结]]
> 领域：[[A-数据与增长]]
## 原则内容
> 不要一上来就 50/50 分流。先用 5% 流量跑 3 天：
> ① 验证埋点数据是否正常
> ② 观察是否有严重负面效果
> ③ 确认样本量预估是否合理
> 通过后再放大到 50/50。
## 来源经验
- 第一轮 ABTest 我们直接 50/50，结果发现埋点有 Bug，
3天的数据全部作废，浪费了一周时间
- 第二轮先跑了 5% 小样本，提前发现了推送文案的一个歧义，
及时修改后再放量，数据干净很多
## 一句话版
> AB测试的前3天是"验证实验本身"，不是"验证假设"。
原则卡 3：跨团队项目的"术语对齐"原则
# 原则：跨团队项目第一周先做"术语对齐"> 来源：[[P-Q2用户分层营销/复盘]] [[P-订单系统重构/复盘]]
> 领域：[[A-产品思维]]
> 被验证次数：2
## 原则内容
> 跨团队协作的第一步不是排期，是让所有人对核心概念的定义达成一致。
## 案例
- 用户分层项目中，产品说的"活跃用户"是"30天内登录过"，
数据团队理解的是"7天内有操作行为"，运营理解的是"参与过活动"。
前两周大家各做各的，最后发现数据对不上。
- 订单重构项目中同样遇到过：
"订单"在交易、物流、财务三个团队的含义完全不同。
## 落地方法
- 项目启动第一周，输出一份"术语表"文档
- 包含：术语名称 / 定义 / 计算口径 / 负责团队
- 所有人签字确认后再开始排期
## 一句话版
> 80%的跨团队扯皮，源于大家在用同一个词说不同的事。
蒸馏前后对比
Before（20条散落的笔记）：
┌──────────────────────────────────────┐
│ 📄📄📄📄📄📄📄📄📄📄 │
│ 📄📄📄📄📄📄📄📄📄📄 │
│ │
│ 总计 20 条 │
│ 阅读时间：全部读完需要 2-3 小时 │
│ 能直接引用的：0 条 │
│ 能跨项目复用的：0 条 │
└──────────────────────────────────────┘After（结构化分层后）：
┌──────────────────────────────────────┐
│ 🏆 3 条原则卡（Layer 3，30秒可引用） │
│ 📋 7 条深度提炼笔记（Layer 2，1分钟） │
│ 📄 13 条原始笔记（Layer 0，归档） │
│ │
│ 提炼耗时：约 1 小时 │
│ 未来每次复用节省：1-2 小时 │
│ 3 条原则卡的预期复用寿命：1-3 年 │
└──────────────────────────────────────┘
1 小时的提炼投入，产出了 3 条可以用 1-3 年的原则卡。这就是 Distill 的 ROI。
六、我在实践中总结的 5 条 Distill 规则
规则 1：不要批量提炼，按需触发
❌ 错误做法：专门拿出一个下午"把所有笔记都提炼一遍"
✅ 正确做法：在使用某条笔记时，顺手多花2-5分钟做提炼为什么？
→ 提炼的质量取决于"你当下的理解深度"
→ 如果你没有在用这条笔记，你提炼不出有价值的总结
→ 只有在"被使用"的上下文中，你才知道哪些是真正的关键信息
程序员类比：不要在没有需求的时候重构代码。重构的最佳时机是你正在修改那段代码的时候——你对上下文最了解、修改成本最低。
规则 2：用自己的话写，不要复制原文
❌ "CQRS 是 Command Query Responsibility Segregation 的缩写，
它将应用程序分为命令端和查询端……"（复制粘贴）✅ "CQRS 说白了就是读写分家。写的时候走复杂的业务逻辑链，
读的时候用独立的优化方案（ES/缓存/宽表）。
我们订单系统读写比 10:1，很适合。"（自己的话）
区别：
→ 前者是"搬运"，三个月后你读到它跟读陌生人的文章没区别
→ 后者是"内化"，三个月后你读到它能瞬间回忆起当时的思考脉络
规则 3：总结要面向"未来的自己"写
写总结时，想象三个月后的你打开这条笔记。
他忘了所有细节，只有 30 秒时间快速获取关键信息。问自己：
- 他最需要知道什么？
- 他可能在什么场景下打开这条笔记？
- 怎么写才能让他30秒内获得足够的信息去做下一步行动？
好的总结 = 给未来的自己写的"备忘录"
实际对比：
❌ 模糊的总结："CQRS 有优缺点，适合某些场景。"
→ 三个月后的你：所以到底适不适合我们？优缺点是什么？还是得重新看原文……✅ 具体的总结："CQRS 适合我们订单系统。原因：读写比10:1，写入复杂但查询简单。
风险：团队没经验。策略：先在订单模块试点。CTO已同意。"
→ 三个月后的你：秒懂。直接引用。
规则 4：一条笔记只说一件事
不要在一条笔记里塞太多内容。❌ "CQRS+DDD+事件驱动+微服务拆分策略+团队管理思考"
→ 这不是一条笔记，这是一本书
✅ 一条笔记 = 一个概念 / 一条经验 / 一个决策 / 一个案例
如果一条笔记超过了 500 字还在讲不同的主题，
考虑拆成多条。
好处：
→ 颗粒度越细，越容易被搜索命中
→ 颗粒度越细，越容易跟其他笔记建立链接
→ 颗粒度越细，越容易在不同项目中被复用
程序员类比：单一职责原则（SRP）。一个类只做一件事，一个函数只完成一个功能，一条笔记只说一个观点。
规则 5：用"双向链接"连接相关笔记
这是 Obsidian 最强大的功能之一，也是 Distill 阶段最值得花时间的动作。操作：在写总结的时候，遇到跟其他笔记相关的内容，
用 [[]] 语法建立链接。
示例：
在 CQRS 笔记的总结里写：
"CTO 说的这句话跟 [[架构决策原则：渐进式引入]] 是一致的"
"这个读写分离的思路跟 [[Redis 缓存策略]] 有关联"
好处：
1. 笔记之间形成网络，而不是孤岛
2. 在 Obsidian 的"关系图谱"里能看到知识的连接
3. 未来搜索一条笔记时，能顺藤摸瓜找到相关笔记
双向链接的最大价值不是"整理时建的那一刻"，而是"三个月后搜索时发现原来这两个概念是相关的"。
程序员类比：双向链接 = 数据库的外键关联。有了外键，你可以做 JOIN 查询，从一张表跳到另一张表。没有外键，每张表都是孤岛，只能一张张翻。