Capture 不是"都存下来"：我用 3 条规则把信息噪音降低了 80%
一只阿木木约 14 分钟先讲一件让我很不好意思的事。
上周我翻看了自己半年前的 Flomo 记录，发现有一天我连续存了 23 条碎片信息：
#素材 看到一篇讲微服务拆分的文章，不错
#素材 这个 AI 提示词模板可以收藏
#想法 是不是应该学一下 Rust
#素材 某大佬的知识管理分享，链接：xxx
#想法 明天要记得查一下 K8s 的亲和性调度
#素材 这个增长案例很有意思
#素材 RFM 模型的另一种变体
#想法 应该整理一下 Redis 的八股文
#素材 好文：如何写技术方案
#素材 一个开源项目，star很多
......
（还有 13 条，省略）
23 条。一天。
你猜这 23 条后来怎么样了？
我去翻了一下后续记录——一条都没有被整理过，一条都没有进入 Obsidian，一条都没有变成任何产出。
它们静静地躺在 Flomo 里，跟其他几百条碎片混在一起，再也没被打开过。
这就是我犯过的最大的错误：把 Capture 等同于"看到就存"。
存了很多，有用的为零。
前四篇文章，我们搭好了仓库（PARA）、打通了入口（统一收集通道）。从今天开始，正式进入 CODE 四步流程的第一步——Capture（获取）。
但我要讲的不是"怎么存更多"。
恰恰相反，我要讲的是"怎么存更少"。
一、Capture 的本质不是"保存"，是"过滤"
我们先来理清一个概念。
大多数人理解的 Capture 是这样的：
❌ "Capture = 把看到的好东西都存下来，以后可能用到。"
Tiago Forte 在《打造第二大脑》里对 Capture 的定义是这样的：
✅ "只保存那些与你的项目、目标、兴趣产生共鸣（Resonance） 的信息。"
注意关键词：共鸣。
不是"觉得有用"，不是"好像不错"，不是"万一以后用到呢"——是此刻读到这条信息时，你的大脑产生了某种反应。可能是兴奋、可能是"原来如此"的顿悟、可能是"这不就是我正在纠结的问题的答案吗"。
如果你读完一条信息没有任何感觉，只是觉得"应该存一下"——那就不要存。
用程序员的话说：
Capture 不是
SELECT *，是SELECT ... WHERE resonance = true。
你不需要把整个互联网的信息都 INSERT 到你的知识库。你需要的是一个高质量的 WHERE 条件，把真正有价值的信息筛选出来。
数据库里灌满垃圾数据，查询性能只会越来越差。知识库也是一样。
二、我的 3 条 Capture 规则
经过半年的试错，我把自己的 Capture 行为压缩成了 3 条规则。它们帮我把每天的信息输入量从 15-20 条降到了 3-5 条，但信息的"转化率"（最终变成产出的比例）反而从不到 5% 提升到了 60% 以上。
规则一：12 秒共鸣测试
当你看到一条信息想要收藏时，停下来 12 秒，问自己一个问题："如果我不存这条信息，我会后悔吗？
具体来说，我的哪个项目、哪篇文章、哪个决策会因此受到影响？"
如果 12 秒内你能说出具体的项目或场景 → 存
如果 12 秒内你只能说出"可能以后有用" → 不存
为什么是 12 秒？
太短了（3秒）你来不及思考，太长了（30秒）会打断你的阅读节奏。12 秒大概是"想一个问题并给出初步回答"的最小时间单元。
我自己的执行实例：
P-订单系统重构 | ||
P-会员体系V2 | ||
A-写作与表达/Obsidian技巧 |
每次做12秒测试，大约有 60-70% 的内容会被我过滤掉。
这不是损失，是净化。
程序员类比：这就是消息队列前面的"过滤器/路由规则"。不是所有消息都需要被消费，只有符合路由规则的消息才进入后续处理。
规则二：Capture 的同时必须写"一句话批注"
每一条存下来的信息，必须附带一句你自己写的话。格式：
- 我为什么存它：___________
- 它可以用在：___________
不需要长篇大论，一句话就够。
但这句话不能省。没有批注的收藏，等于没有索引的数据——存了也白存。
为什么这一步如此关键？
因为三个月后你回来看这条笔记的时候，你已经完全忘了当时为什么存的。
没有批注的笔记长这样：
# Redis分布式锁
https://xxxxx.com/redis-distributed-lock
三个月后你看到这条，反应是："这篇文章讲了什么来着？我为什么存的？"然后你要重新打开链接、重新阅读、重新理解。如果链接失效了，这条笔记直接报废。
有批注的笔记长这样：
# Redis分布式锁> 来源：https://xxxxx.com/redis-distributed-lock
> 💡 我为什么存：文章里提到 Redisson 看门狗在主从切换时会失效，
> 这正是我们线上那个超卖 Bug 的根因。
> 📌 可以用在：P-订单超卖修复 的技术方案文档里，作为"方案选型依据"。
三个月后你看到这条，不用打开原文就知道核心信息和使用场景。
这句批注平均只要花 15 秒，但它把这条笔记的"保质期"从 3 天延长到了 3 年。
程序员类比：这就是代码注释。没人规定一定要写注释，但三个月后看到没注释的代码，你会骂当时的自己。存笔记不写批注，跟写代码不写注释是同一种罪过。
规则三：每周 Capture 上限 —— 不超过 25 条
给自己设一个"硬性上限"：
每周新增笔记（包括 Flomo 碎片 + Obsidian 直接记录）不超过 25 条。不是"至少 25 条"，是"最多 25 条"。
如果某天已经存了很多，后面几天就要更严格地过滤。
为什么要设上限？
因为 Capture 有一个隐藏的陷阱：收集本身会给你"学习了"的错觉。
每存一条信息，大脑就会分泌微量多巴胺——"太好了，这个知识我收下了"。但实际上你什么都没学到，你只是移动了一条数据。
存 100 条但一条都没整理，不如存 5 条但每条都经过 Distill 提炼。
设上限的好处：
强迫你提高过滤标准——名额有限，只存最好的 倒逼你做 Organize 和 Distill——如果 Inbox 里积了 20 条未整理的，你会有紧迫感去清空它 心理减负——"我今天可以不收藏"是一种被允许的轻松
我最近四周的实际数据：
趋势很明显：Capture 越少，转化率越高。
因为当你知道名额有限，你存的每一条都是经过深思熟虑的——它从一开始就有更高的概率被整理和使用。
三、不同类型的信息，怎么 Capture？（5种场景���操）
规则讲完了，但不同类型的信息在操作上差异很大。下面我按五种最常见的场景，分别演示我的 Capture 方法。
场景 1：阅读一篇技术文章
错误做法（之前的我）：
看到一篇好文章 → 点"收藏" → 结束。
现在的做法：
第一步：用 12 秒测试判断要不要存
第二步：如果要存，不是存"链接"，而是存"我从中获得的信息"具体操作：
1. 读完文章（或读完关键段落）
2. 在 Obsidian Inbox 里新建一条笔记：
---
标题：[文章关键词] + 我的理解角度
来源：原文链接
日期：2024-xx-xx
状态：待整理
关联：[[P-xxx]] 或 [[A-xxx]]
---
## 原文核心观点（用自己的话复述，不要复制粘贴）
1.
2.
3.
## 我的想法 / 我不同意的地方
-
## 可行动的点
- [ ]
3. 整个过程控制在 5 分钟以内
重点：不要复制原文。用自己的话写。
复制粘贴的东西不会进入你的大脑。用自己的话复述的过程就是理解和内化的过程。
你甚至可以写错、写得不完整——没关系。三个月后让你记住的，是你自己写的那句歪歪扭扭的总结，而不是原文里优美但遗忘了的段落。
实际案例：我 Capture 一篇"DDD领域驱动设计"的文章
# DDD 的核心不是分层，是语言> 来源：https://xxxxx.com/ddd-core-concept
> 日期：2024-05-12
> 关联：[[P-订单系统重构]] [[A-后端技术]]
## 原文核心观点
1. DDD 最重要的概念不是"六边形架构"或"洋葱架构"，
而是"统一语言"（Ubiquitous Language）
——让开发和业务用同一套词汇沟通
2. 界限上下文（Bounded Context）的本质是：
同一个词在不同场景下含义不同，所以要划定边界
3. 实体和值对象的区分标准是"是否需要唯一标识"
## 我的想法
- 我们订单系统重构时，"订单"这个词在交易、物流、
财务三个团队的含义完全不同。这不就是 Bounded Context 吗？
- 之前跟产品沟通需求总觉得鸡同鸭讲，可能就是缺少"统一语言"
## 可行动的点
- [ ] 在重构方案里加一章"术语表"，跟产品对齐核心概念的定义
注意：这条笔记没有复制原文一个字。全是我自己的理解和关联。
所以即使原文链接失效了，这条笔记依然完整可用。
场景 2：解决一个技术问题 / Bug
这是程序员最高频、也最容易遗忘的 Capture 场景。
每个程序员都有过这种经历：花了一整天排查一个 Bug，最后发现是一个很隐蔽的原因。当时觉得"这么简单的事，不用记"。三个月后遇到类似问题，又花了一天。
我的 Capture 规则：任何排查超过 30 分钟的问题，必须写一条踩坑记录。
# [踩坑] MySQL 死锁导致接口超时> 日期：2024-05-15
> 关联：[[P-订单系统重构]] [[A-后端技术]]
## 现象
订单创建接口偶现超时，监控显示 MySQL 出现死锁告警
## 排查过程
1. 看慢查询日志 → 发现两条 UPDATE 语句互相等待
2. 分析事务逻辑 → 两个事务以不同顺序更新 order 表和 inventory 表
3. 根因：事务内多表更新顺序不一致导致死锁
## 解决方案
统一所有事务的表更新顺序：先 inventory 再 order
## 可复用的规则
> 下次遇到多表更新的事务时，先约定全局统一的表更新顺序，
> 写在代码规范里，CR时检查。
## 耗时
排查：4小时 修复：30分钟 本可以：如果有规范，0分钟
最后那行"耗时"是我后来加的习惯。它能量化"不做 Capture 的代价"——下次你懒得记的时候，想想这 4 小时。
场景 3：一次会议或技术讨论
大多数人的会议纪要 = 流水账。而真正有价值的不是"讨论了什么"，而是"决定了什么"和"我学到了什么"。
我的 Capture 规则：会议中只记 3 样东西。
text
① 决策（Decision）：今天做了什么决定？谁做的？为什么？
② 行动（Action）：谁要在什么时间前做什么事？
③ 洞察（Insight）：这次讨论中我听到的、让我"哦！"的点
实际案例：一次技术方案评审会的 Capture
# 会议：订单系统重构方案评审> 日期：2024-05-10
> 参会人：技术负责人、后端组、DBA
> 关联：[[P-订单系统重构]]
## 决策记录
| 决策 | 决策人 | 原因 |
|------|--------|------|
| 采用 CQRS 模式拆分读写 | CTO | 读写比 10:1，写入逻辑复杂但查询简单 |
| 暂不引入 Event Sourcing | 架构师 | 团队经验不足，风险大于收益 |
| 数据迁移用双写过渡 | DBA | 大表迁移停机时间不可接受 |
## 行动项
| 行动 | 负责人 | 截止日期 |
|------|--------|---------|
| 输出 CQRS 详细设计文档 | 我 | 05-17 |
| 准备双写方案 POC | DBA | 05-20 |
## 我的洞察
- CTO说的一句话很有启发："不要为了架构优雅引入团队驾驭不了的复杂度"
→ 这条可以沉淀为一条技术决策原则
- CQRS 的本质是"读写关注点分离"，
跟 PARA 里"Projects(写) vs Resources(读)"的逻辑类似（有意思的跨域联想）
注意"我的洞察"这一栏。
这一栏不是会议本身的内容，而是我在会议中产生的想法。这些想法如果不当场记下来，散会后五分钟就忘了。而它们往往是最有价值的——因为那是你自己的思考，不是别人的输出。
场景 4：一个产品/营销灵感
产品和营销的灵感来源非常多：竞品体验、用户反馈、朋友聊天、刷抖音看到的广告……
这类信息的特点是"极度碎片化"且"稍纵即逝"。
我的 Capture 规则：用"刺激-反应"格式记录。
格式（Flomo 里直接写）：[刺激] 我看到/听到/体验了什么？
[反应] 我的第一反应是什么？为什么触动我？
[行动] 我可以怎么用？
#想法 #关联领域
实际案例：体验某产品的付费引导后产生的灵感
[刺激] 体验了XX产品的会员开通流程：
选择套餐页面只展示2个选项（月卡/年卡），
年卡旁边标了"省58%"和"89%的用户选择"[反应] 这个"89%的用户选择"是社会认同效应。
而且只给2个选项减少了选择困难。
我们的会员页面有4个套餐，用户总是犹豫。
[行动] Q3做会员体系时可以参考：
1. 套餐精简到2-3个
2. 加社会认同标签
3. 用锚定效应突出推荐套餐
#想法 #产品设计 → [[P-会员体系V2]]
这条 Flomo 碎片，在周末整理时被我迁入了 Obsidian 的 P-会员体系V2/竞品灵感.md，后来真的写进了方案里。
场景 5：读书时的触动
读书不需要逐字逐句记笔记。只 Capture "让你停下来"的地方。
我的 Capture 规则：只记"让我划线"的句子 + 我的即时反应。
格式（直接在 Obsidian 的读书笔记里追加）：> 原文金句 —— 《书名》p.xx
💭 我的反应：___________
🔗 这让我想到了：[[]]
实际案例：读《打造第二大脑》时的一条 Capture
> "你的笔记不是为了记录过去，而是为了服务未来的项目。"
> —— 《打造第二大脑》p.87💭 我的反应：这句话解释了为什么我之前的笔记都是"死的"
——因为我是在记录"这篇文章说了什么"，
而不是在记录"这个信息将来能用在哪里"。
面向过去 vs 面向未来，视角完全不同。
🔗 这让我想到了：[[A-写作与表达/公众号写作SOP]]
→ 我写文章时也应该"面向读者的下一步行动"而不是"面向我想说什么"
注意这条笔记最后的跨域联想——从"知识管理"联想到了"写作"。
这种联想是知识管理最珍贵的产物。它不会凭空出现，只会在你"用自己的话重新表述"的过程中自然涌现。
四、不该 Capture 的 5 类信息（做减法比做加法更重要）
光知道"该存什么"还不够。明确"不该存什么"同样关键。
以下五类信息，我现在会主动跳过：
❌ 不存第一类：搜索引擎随时能找到的
反例：
- "Python 字符串转日期格式"的代码片段
- "MySQL GROUP BY 语法"
- "Obsidian 快捷键大全"为什么不存？
→ 这些信息在 Google/百度里搜 5 秒就能找到，
而且官方文档永远比你的摘抄更准确、更完整。
唯一例外：
如果你在这个基础语法上踩过坑（比如时区导致的日期转换Bug），
那条踩坑记录值得存——因为搜索引擎不会告诉你"你的业务场景下"的坑。
程序员类比：不要把 API 文档复制到本地。文档是"在线查询"的，不是"离线存储"的。你的知识库里应该存的是"文档没写但你用血泪换来的经验"。
❌ 不存第二类：纯粹的"FOMO收藏"
什么是FOMO收藏？
FOMO = Fear Of Missing Out（害怕错过）典型表现：
"2024年必读的100篇AI论文"
"程序员必须知道的50个开源项目"
"年度最佳XX合集"
这类内容你存了之后会做什么？
→ 什么都不做。你只是通过"收藏"这个动作缓解了焦虑。
判断标准：
如果你存一条信息的动机是"别人都在看/都在存"，而不是"我正在做的事需要它"
→ 不存。
❌ 不存第三类：你不打算行动的"以后再说"
反例：
"以后有空学一下 Rust"
"以后想研究一下区块链"
"以后应该考一个PMP"如果这个"以后"没有对应一个具体的项目或截止日期 → 不存。
因为你的 Areas 和 Resources 已经定义了你"长期关注的领域"。
不在这些领域里的"以后再说"，本质上是"永远不会做"。
承认这一点，反而是一种解脱。
❌ 不存第四类：负面情绪向的碎片信息
反例：
"今天被领导骂了，记录一下"
"这个项目太烂了，谁设计的"
"这个同事太难合作了"为什么不存？
→ 知识库的目的是"服务未来的产出"。
纯粹的情绪宣泄不会产生任何可复用的价值。
但如果你能把情绪转化为"可复用的经验" → 可以存：
✅ "跟领导沟通的踩坑：下次汇报先说结论再说过程"
✅ "跨部门协作原则：先确认交付标准再开工"
❌ 不存第五类：别人整理好的"完美体系"
反例：
直接复制别人的 PARA 目录结构
直接搬运别人的"知识管理完整指南"
直接下载别人的 Obsidian 模板库（几百个模板）为什么不存？
→ 别人的体系是基于他的项目、他的领域、他的工作流建立的。
直接搬过来，你不理解每个文件夹存在的原因，一周后就会崩塌。
正确做法：
→ 看别人的体系，理解他的原则（Why），
然后自己从零建一套适合自己的结构（How）。
这也是我这个系列在做的事——我不给你"我的模板"，
我给你"我建模板时的思考过程"。
五、Capture 工作流全景图：从触发到落库
把上面所有内容整合，画出完整的 Capture 流程：
┌──────────────────────────────┐
│ 你遇到了一条信息 │
│ 文章/对话/Bug/灵感/书中一句话 │
└──────────────┬───────────────┘
│
▼
┌──────────────────┐
│ 12秒共鸣测试 │
│ "我的哪个项目/ │
│ 领域需要它？" │
└────────┬─────────┘
│
┌──────┴──────┐
▼ ▼
有明确 说不清楚
关联 "可能有用"
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ 存！ │ │ 不存。 │
│ │ │ 放过它。│
└────┬────┘ └─────────┘
│
▼
┌─────────────────┐
│ 写一句话批注 │
│ "我为什么存它" │
│ "可以用在哪里" │
└────────┬────────┘
│
┌──────┴──────┐
▼ ▼
手机端 电脑端
Flomo Obsidian
(碎片速记) (深度记录)
│ │
└──────┬──────┘
│
▼
┌──────────────────┐
│ 0-Inbox │
│ 快速捕获.md │
│ │
│ 每天或每周清空 │
│ → 按 PARA 归位 │
└──────────────────┘
│
▼
┌──────────────────┐
│ 检查本周额度 │
│ ≤ 25条？ │
│ │
│ 超了 → 提高标准 │
│ 没超 → 继续 │
└──────────────────┘
六、一个完整案例：从一次线上事故到 3 条可复用经验
最后，我用一个真实的工作案例，完整演示 Capture 的全过程。
背景： 某天凌晨，线上订单服务出现大面积超时，我参与了排查和修复。
第一时间（事故发生中）—— 碎片 Capture
凌晨排查的时候，我不可能打开 Obsidian 认真写笔记。我用 Flomo 快速记了几条：
#踩坑 凌晨2:15 订单服务大面积超时
监控看到MySQL连接池打满 CPU 90%+ #待办 事后复盘#踩坑 排查发现是慢查询导致的 有一条SQL没走索引
explain看了一下是全表扫描 数据量上来之后就炸了
#踩坑 DBA说这个表上周刚做了字段变更
索引被意外删掉了 变更审核流程有漏洞
这三条碎片记录加起来花了不到2分钟。它们不完整、不规范，但保留了最关键的信息。
第二天（事故修复后）—— 整理 Capture
第二天我把 Flomo 里的碎片整理成了一条 Obsidian 踩坑记录：
# [踩坑] 订单服务大面积超时事故> 日期：2024-05-08 凌晨
> 关联：[[P-订单系统重构]] [[A-后端技术]]
## 现象
凌晨 2:15 监控告警，订单服务响应时间从 50ms 飙到 15s，
MySQL 连接池打满，CPU 90%+
## 排查过程
1. Grafana 看到 MySQL 连接数异常 → 定位到数据库层
2. 慢查询日志发现一条全表扫描 SQL → explain 确认没有走索引
3. 联系 DBA → 上周做表结构变更时，索引被意外删掉了
4. 紧急加回索引，服务恢复
## 根因
1. DDL变更流程没有"索引检查"环节
2. 变更后没有跑SQL执行计划验证
3. 监控只看了服务层，没有MySQL层的索引变更告警
## 可复用的 3 条规则
> 规则1：任何 DDL 变更后，必须用 explain 验证核心查询的执行计划
> → 写入团队代码规范
> 规则2：建立"索引变更"监控告警
> → 提需求给 DBA 团队
> 规则3：线上事故排查顺序标准化：
> 应用层 → 中间件层 → 数据库层 → 基础设施层
> → 写入 [[A-后端技术/线上排障手册]]
## 耗时
排查：3小时 修复：10分钟 复盘记录：20分钟
如果有规则1，这次事故可以被预防。
后续发酵——这条笔记被复用了 3 次
一次事故，3 条规则，复用 3 次。这就是 Capture 的复利。
如果当时凌晨我没有花那 2 分钟在 Flomo 里速记，这些经验就永远消散了。两个月后遇到类似问题，我又会花 3 小时排查。