事情要从我浏览器书签栏里那七千多条收藏说起。某天想找一篇半年前读过的关于分布式事务的文章，翻了三个子目录，点坏了不知道多少下滚轮，最后打开的那篇，标题眼熟、内容陌生——我明明把它存了下来，却等于从没见过。那一刻我算是彻底想明白了：收藏夹不是知识库，它是焦虑仓库。

那段时间某小组一位同事跟我聊过一个问题，扎心得很：你上周读的那二十几篇文章，现在能说出任何一篇的核心观点吗？能往前再走一步，说出哪个观点影响了你本周做的某个决定吗？我沉默了。浏览器会重装，订阅会过期，PDF 放三个月再打开跟新文件没有区别。多读并不能解决这个问题——问题不在输入量，而在输入和输出之间一直缺了一个"消化"环节。

于是就有了这个叫 rea 的项目。名字没有任何神秘含义，就是把处理知识的三步各取一个动词的首字母：Read、Extract、Apply。目标很朴素：把"我读过"变成"我提取过、用得上、找得到"。这篇就讲清楚这三步怎么落成一套能照抄的本地流程，包括具体格式、脚本逻辑、复盘节奏，以及我踩过的坑。适合的人群也很明确：平时大量阅读技术资料、行业报告、深度长文，却总觉得看了就忘的人。

1. Read阶段：先堵住"收藏就是学会"的幻觉

1.1 十分钟原则：进库之前先过一道安检

rea 的第一步不是做笔记，而是设门槛。我给自己的规定非常简单：任何内容，如果明知自己以后不会主动重读，或者打开之后需要超过十分钟才能进入状态，就不要放进 rea。十分钟不是拍脑袋定的数，它来自一个朴素的经验——零散的资讯如果十分钟内读不完，要么说明它是需要整块时间对付的长文，要么说明它根本就是噪音。长文应该进待读队列，噪音应该直接删。

这条规则的真正作用不是限制阅读量，而是逼着我在"点击收藏"的那几秒回答一个问题：我想从这篇东西里得到什么？是为了解决手头某个具体问题，还是单纯觉得题目有趣？前者才配进入 rea 的流程，后者只是消遣。前面提到的那个同事把这个门槛叫"入口保安"，后来事实证明保安比我想象的重要——它至少拦下了收件箱里一半的无效内容。没有这道拦截，后面再勤快的提取都是在替垃圾做整理。

1.2 六字段的最小捕获格式

过了门槛之后，内容怎么进库？我观察过不少人的笔记系统，最后都死在"自由放养"上：今天存一段纯文本，明天填一个表格，后天粘一张思维导图截图，等真要搜的时候什么都找不着。rea 的做法是给自己定了一张死板到有点无聊的最小格式：每一条捕获记录就是一个独立的 Markdown 文件，放进统一的收件箱目录里，头部固定六个字段：

这份表格最初只有三个字段，后来补上 intent 和 priority。为什么补？真实使用中你会很快发现：没有 intent 的记录，到了提取阶段根本不知道该提取什么，打开看一眼就扔回去了；没有 priority 的收件箱，会被随手转存的东西快速塞满。字段一旦确定，习惯就定型了。一条典型记录长这样：

--- date: 2025-01-14 type: article source: newsletter intent: 解决消息队列堆积问题 priority: high --- 消费者吞吐量上不去，先看这六个指标

别小看这几行结构，它能配合后面的脚本做自动校验：日期缺失、priority 不在枚举值里、intent 为空，脚本一律标红。人很容易骗自己"这篇以后再说"，脚本不会。这正是整个 rea 系统里我认为最值得先抄走的部分——不是工具多高级，而是格式纪律有人替你盯。

2. Extract阶段：把笔记加工成观点

2.1 意外、冲突、验证：提取三问

捕获只是把原料搬进仓库，真正的价值发生在提取。可绝大多数人的笔记都只做到摘抄：把作者的话换了个颜色粘到自己的文档里，回看时大脑还要重新处理一遍，这等于没提取。rea 的提取模板只有三个问题：第一，这条内容里什么东西让我意外；第二，它和我原有的判断冲突在哪；第三，我能用什么方式去验证或者反驳它。

意外、冲突、验证是刻意选的词。意外保证你不是在重复已知信息，如果我读一篇文章全程都在点头，那它对我最多是个确认，不产生增量；冲突逼我刷新旧有的心智模型，这是知识更新发生的时刻；验证让观点落地而不是飘着。如果一条提取三问一个都答不上来，说明这条内容本来就不值得提取，当初就不该放进收件箱。我用这个标准复查过历史记录，结果砍掉了一大半早期卡片，一点没觉得可惜。

2.2 提取落盘的流程与那个两百行脚本

提取不能只在脑子里完成，必须落盘。我的习惯是：每周末把收件箱里的记录批量移动到一个已完成目录，逐条去填三问，然后运行一个本地 Python 脚本做三件事——生成索引文件、统计提取数量与主题分布、把所有"未完成提取"的记录拉成待办清单。

脚本本身不复杂，核心就是一个元信息解析再配一个汇总输出，去依赖库，全部跑在本地。下面是最简版本的片段，做的事情就是扫描目录、解析 Markdown 头部的键值对、校验必填字段、列出残缺记录：

import pathlib, re INBOX = pathlib.Path("rea/inbox") DONE = pathlib.Path("rea/done") REQUIRED = ["date", "type", "intent", "priority"] def parse_front_matter(text): fields = {} for line in text.splitlines(): match = re.match(r"^([a-z]+):\s*(.*)$", line.strip()) if match: fields[match.group(1)] = match.group(2).strip() return fields def collect(directory): items = [] for path in directory.glob("*.md"): fields = parse_front_matter(path.read_text(encoding="utf-8")) items.append({"file": path.name, **fields}) return items def show_broken(items): broken = [it for it in items if any(k not in it for k in REQUIRED)] print("待补全记录数:", len(broken)) for it in broken: print("-", it["file"]) if __name__ == "__main__": all_items = collect(INBOX) + collect(DONE) show_broken(all_items)

这段代码没有任何魔法痕迹，日常使用中我还会让它顺手输出当月主题词频率。这里想强调的不是代码本身，而是它背后的原则：自动化的目的是守住格式纪律，而不是替你思考。脚本只负责检查"有没有写完整"，不负责判断"写得有没有价值"——后者一旦交给机器，提取就变味了。

2.3 为什么坚持纯文本而不是某个笔记软件

一定有人问，这些功能市面上成熟的笔记软件不都有吗？为什么要费劲用纯文本加脚本？我的理由有三条，每条都是实际迁移过程里换来的。先说搜索：纯文本目录可以被任何命令行工具任意裁剪、统计、管道串联，不需要等待某个客户端提供新功能；再说持久性：纯文本没有厂商绑定，十年后打开文件夹依然是这些文件，格式不会悄悄变；最后一条可能有点反直觉——纯文本的存储方式天然不带"排版诱惑"。用花哨的编辑器写笔记，时间往往会花在调字号、配颜色、整理层级上；用纯文本，时间只能花在内容上。这个取舍很个人，但对我这种意志力一般的人来说，反而更容易长期坚持。

3. Apply阶段：每周五的三条上限

3.1 复盘仪式：从卡片里挑出三条，不许贪多

提取完还不算结束，如果只是把卡片整整齐齐存好，那它们依然是漂亮的尸体。rea 的第三步在每周五下午固定执行：从本周提取的卡片里挑出三条——注意，只有三条——逐条回答一个追加问题："我下一次做哪一类事情时，可以用到这条内容？"然后把答案写进卡片下方的 application 字段。这个字段就是 rea 和普通笔记本最大的分水岭。

为什么硬性规定三条？因为贪婪是复盘的头号敌人。我第一次试的时候一口气挑了十七条，结果一条都没真正落地，反倒自我感动了一整个下午。后来强制改成三条，每条必须写清楚具体的使用场景，比如"下次设计限流方案时，先检查消费端最大重试次数，再谈扩容""下次评审存储选型前，先要求对方说明备份恢复的演练时间"——十周以后再回看，真正发挥作用的反而是这些带着场景的短句子。那位同事把这一步叫"给知识装上使用说明书"，我觉得这个比喻很准确。

3.2 一条知识接上真实项目的现场

说一个印象最深的实际例子。某次团队讨论缓存降级方案，好几个人的第一反应是"加一层缓存先把流量扛住"。但我在 rea 里恰好提取过一篇讲缓存击穿的文章，application 字段里写的是"接入新缓存前，必须先明确缓存失效后的回源链路，否则只是把问题往后挪"。开会时我直接把这条记录调出来投到屏幕上，讨论节奏立刻从"怎么加一层缓存"变成了"怎么设计降级路径"。

这件事给我一个很具体的启发：知识发挥作用靠的不是"我记得这篇讲什么"，而是我在提取时就替它想好了"这个结论在什么场景里能用"。真正有价值的复述，不是把文章观点告诉别人，而是把"文章观点到我们当前决策"之间的桥梁搭好。会后我把这条卡片关联进了会议纪要，它的作用半径就超出了我个人的笔记本。

3.3 应用率：用数据戳破自我感动

光靠感觉，人特别容易高估自己的复盘率。rea 给我的第二个回报是提供了一组可量化视角：脚本每月跑一次统计，把"带 application 字段的卡片数"除以"提取卡片总数"，算出一个应用率。我的数据最开始时只有三成左右，慢慢爬到六成，中间一度跌回四成——因为那段时间收件箱突然被资讯类内容塞满了，读得多、提取得也快，但全是顺手一记，根本没有能落地的场景。

数据不会骗人，它能帮你定位知识流到底断在哪一环：如果提取率正常但应用率很低，问题多半出在捕获环节混进了太多不该进的东西；如果提取率本身就上不去，说明 Read 阶段的门槛还不够高，或者收件箱里堆了一批自己根本不想读的存货。每次看到数字下滑，我都会回去调流程参数，而不是再给自己打两管鸡血。

4. 我踩过的三个坑：自动化、膨胀、日记化

4.1 坑一：自动化膨胀，差点把工具改废

第一个坑是过度自动化。有段时间我沉迷给脚本加能力：标签联想、自动摘要、内容评分、主题聚类，代码从两百行膨胀到上千行。结果是系统变得脆弱也复杂，两周不碰就开始报错，最后连我自己都不想打开它。后来推倒重来，只保留校验、索引、统计三件事，其余的统统砍掉。这条教训我现在逢人就讲：个人工具的寿命取决于维护成本足够低，而不是功能足够多；每增加一项自动化，都意味着未来多一份要维护的复杂性。

4.2 坑二：捕获膨胀，收件箱变成垃圾中转站

rea 运转到第二个月时，收件箱数据突然暴涨，我查了一下来源，一大半是订阅邮件和社交媒体的碎片内容，读完即忘，却照样占用了宝贵的复盘时间。解决办法是在 Read 阶段加了一道来源白名单：只有技术文档、深度分析、教材类内容允许直接进收件箱；其余的必须先在草稿区写三行自己的转述，写不出来就说明它根本没价值，直接丢弃。这个补充规则起效很快，几周后提取率和应用率双双回升。捕获的成本越低，越需要额外的准入控制来对冲，这是我后来才想明白的道理。

4.3 坑三：提取日记化，卡片没有观点

第三个坑是提取时候悄悄写成了日记。翻早期卡片，很多都长一个样：今天的主题是什么、作者说了什么、我感觉不错——唯独没有"我判断它哪里对、哪里可疑"。排查下来，问题出在我把三问回答得太宽松，尤其把"什么让我意外"写成了"什么我觉得有意思"。后来我给自己加了一条硬约束：写不出验证方式的卡片宁可作废，也不能入库。记日记不是错，错的是把日记和知识混在同一条流水线里，两种内容的生命周期完全不同，混在一起就会让整个系统都失去重点。

5. rea 的边界：它不打算替你做什么

5.1 它不是官方文档的替代品

讲清楚 rea 不做什么，和讲清楚它做什么同样重要。它不替代任何一手资料：文章里提到某个协议的细节、某个接口的参数，我不会指望藏在 rea 里就够了。真到要用的时候，还是要回官方文档核对。rea 的作用是保留一个"我当时消化过什么、形成了什么判断"的索引，让你知道该去哪里再确认，而不是直接变成一个静态的知识仓库。把它当替代品来用，迟早会在某个关键细节上翻车。

5.2 它不是团队知识库

rea 也不是团队的文档系统。团队的知识仍然放在公开的线上文档里，它有版本、有评审、有共享义务。rea 完全是个人视角的过滤器，里面全是我的判断和偏好，不适合也不应该直接成为团队资产。如果要协作，需要的是一套更正式的数据规范和历史记录机制，那超出了这个轻量项目的范围。个人的东西保持个人，团队的东西保持团队，两边互不混淆，反而都轻松。

5.3 它甚至不是记忆系统

最后一条边界：rea 不是记忆工具，它不追求让你背下来。我对自己的定位非常明确——我不可能记住每一篇读过的技术文章，也不需要。我需要忘记，只需要保留"我消化过它，使用时可顺着线索找回"这个事实。把 rea 当闪卡去背诵，方向就歪了。理解这几条边界之后，你会对这个轻量工具少很多不切实际的期待，也就不会因为它的朴素而半途放弃。

6. 想复刻的人，照这条最短路径走

6.1 最小配置只要三样东西

把这套东西压缩到最小可行形态，你真正需要的只有三样：一个目录结构、一张模板、一个脚本。目录就分收件箱和已完成两个区；模板就是前面那张六字段表加三问区域；脚本用我贴的最简版本足够撑很久。工具方面只需要一个能编辑 Markdown 的编辑器加系统自带的文本搜索，零额外依赖。第一次把流程跑通，正常不超过一小时，剩下的时间都是在和自己过去的习惯做斗争。

6.2 前五周的节奏安排

第一周只做捕获，不提取，重点养成"进收件箱前先写下意图"的手感；第二周开始第一轮提取，让自己适应三问模板的约束；第三周加入每周复盘，强制挑三条写应用场景；第四周看统计，定位自己是断在捕获、提取还是应用环节；第五周之后，再根据真实痛点决定要不要加东西。这样排期的核心是避免刚开始就给自己叠加太多仪式感，先把最基础的动作稳定下来，工具才不至于躺在收藏夹里吃灰。

6.3 什么时候升级、什么时候保持朴素

我的经验是：文件量到两三千条，纯脚本索引开始吃力时，可以引入更强的检索方案；如果哪天几个人一起共用这套流程，就需要统一数据规范和历史记录能力；但如果是个人使用，我倾向于一直保持现在的朴素程度。根据我这几轮迭代的体会，rea 带给我最大的收益根本不在检索速度上，而是它硬生生把我改造成了一个"慢性子读者"：打开任何文章之前，先想清楚我为什么要读；读完以后，先想清楚它到底改变了我的什么判断。工具早晚会被更好的方案替代，这个习惯一旦养成，会在每一项工作里持续兑现。