把「买牛奶」和「机器学习论文」放在同一个 vault 里——这才是你信息管理崩溃的真正原因

把「买牛奶」和「机器学习论文」放在同一个 vault 里——这才是你信息管理崩溃的真正原因

不是你太懒，是你用同一套逻辑管理了本质不同的四种信息

我先问你一个问题。

如果你家里的药箱和厨房刀具放在同一个抽屉里——急救药、创可贴、菜刀、剪刀、温度计全部混在一起——你会怎么评价这个设计？

你会说：这个人太懒了，不会整理。

或者你会说：这个抽屉的设计逻辑，从根本上就是错的。

现在打开你的 Obsidian Inbox，或者你的 Notion 收件箱，或者你手机里的备忘录。

里面有什么？

我猜，可能同时有：

「周五前给王总发季度报告」

「Attention Is All You Need 论文精读笔记」

「明天早上 9 点牙医，地址：XXX」

「为什么复利是世界第八大奇迹——查理·芒格」

「妈妈说冰箱里的剩饭不要超过三天」

「关于 AI Agent 架构的三个核心问题」

「下周一组会要用的 PPT 模板」

「『痛苦 × 反思 = 进步』——Ray Dalio」

你的 Inbox，就是那个混乱的抽屉。

菜刀和创可贴放在一起。

不是因为你懒，而是因为没有人告诉你：这些东西，从本质上就是不同种类的存在，不应该被同一套逻辑处理。

一、一个让我想了很久的问题

在上一篇，我提到了一个 Karpathy 的 LLM Wiki 系统没有解决的矛盾：

如果把所有生活信息都扔进同一个 Wiki，它会被「买牛奶」淹没；但如果每个方面单独建一个 Vault，切换起来又极度麻烦。

在我认真思考这个矛盾的过程中，我意识到问题的根源更深。

不是「用哪个工具」的问题。

不是「怎么建文件夹」的问题。

而是：我们从来没有认真区分过，涌入我们生活的这些信息，在本质上属于几种完全不同的东西。

这个认知盲区，才是一切混乱的起点。

我开始做一件事：把过去一个月里进入我 Inbox 的所有内容，按照「信息的本质」重新分类，不按主题，不按重要性，而是按照一个简单的维度：

这条信息，天然的生命周期是多长？

分类完之后，我愣住了。

二、信息的四种本质

我发现，所有涌入我生活的信息，不管内容是什么，都可以归入四种本质类型之一。

这四种类型，不是我发明的分类系统，而是信息本身天然具有的属性——就像水、火、土、气四种元素，不是人为规定的，而是自然存在的。

第一种：会消失的信息（Ephemeral）

天然生命周期：几小时到几天

这类信息有一个特征：完成之后，它就没有存在的意义了。

「明天上午 10 点和李总的电话」——电话打完了，这条信息的使命结束了。

「买：牛奶、鸡蛋、洗发水」——买完了，这条信息死亡了。

「今晚记得充电宝」——充完了，这条信息应该消失了。

「快递已发货，单号 xxxx」——收到了，这条信息变成垃圾了。

这类信息的正确处理方式，是用完即弃。它不应该被归档，不应该被整理，更不应该被「编译」进任何知识库。

但你的系统里有多少这类信息在占据空间？

打开你的 Obsidian，搜索一下有多少「已完成的任务」还躺在某个角落，从未被清理——它们就像用完的纸巾被整齐地叠放收好，占着地方，营造着一种「我的系统很充实」的幻觉。

第二种：有时效的信息（Operational）

天然生命周期：一个项目的周期，几天到几个月

这类信息有一个特征：在某个项目或目标完成之前有价值，完成之后价值大幅下降，甚至为零。

「Q3 产品发布会的策划方案」——发布会结束后，这份文档的使命完成了。

「和设计团队关于新 UI 的讨论记录」——版本上线后，这段历史还重要吗？

「这次融资路演的 20 个问题准备」——融资完成后，这些问题还需要随时翻阅吗？

「申请研究生的文书草稿」——录取之后，它还是你需要维护的「活跃内容」吗？

这类信息的正确处理方式，是项目期间全力维护，项目结束后归档或删除。

它值得认真整理，但它不是「知识」，它是「操作文档」。把它当知识来管，是巨大的浪费；忽视它，又会在项目进行中因为信息混乱而付出代价。

第三种：持续有效的信息（Reference）

天然生命周期：数月到数年，主题明确，持续有参考价值

这类信息有一个特征：和特定事件无关，只要这个领域还重要，它就持续有价值。

「Transformer 架构的核心原理」——六个月后你还可能用到。

「个人财务管理的核心方法论」——三年后还是有效的。

「如何做高质量用户访谈的方法」——跨项目通用。

「这家投资机构的投资偏好和决策风格」——只要你还可能和他们打交道，就值得保存。

这类信息的正确处理方式，是主动编译，建立结构，持续更新。

这就是 LLM Wiki 应该处理的东西。不是随手记录，不是完成即弃，而是持续沉淀，越用越值钱。

第四种：永久有效的信息（Evergreen）

天然生命周期：永久，跨越具体场景，普遍适用

这类信息有一个特征：它不依附于任何具体的主题或项目，它是你认知世界的底层框架。

「第一性原理思维：回到事物的本质，而不是从类比推理」——Elon Musk 的这个思维框架，今天有用，十年后还有用。

「痛苦 + 反思 = 进步」——Ray Dalio 的这个公式，在职场有用，在生活里有用，在任何需要成长的地方都有用。

「复利的本质：系统性地让好结果再产生好结果」——这不是投资原则，这是一个普遍规律。

「完成比完美更重要」——简单的七个字，但它在你拖延的每一刻都值得被想起。

这类信息的正确处理方式，是放在最显眼的地方，反复回顾，内化成直觉。

它不需要「查询」，它需要「成为你的一部分」。

三、用一张表，把差异说清楚

让我把这四种类型放在一起对比，你就能看出它们有多不同：

text

┌──────────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│              │  Ephemeral   │ Operational  │  Reference   │  Evergreen   │
│              │  （会消失的）  │  （有时效的） │（持续有效的）  │ （永久有效的）│
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 典型例子     │ 买牛奶       │ 项目方案     │ 技术原理     │ 思维框架     │
│              │ 明天牙医     │ 会议记录     │ 领域知识     │ 人生原则     │
│              │ 快递单号     │ 活动策划     │ 人物背景     │ 核心方法论   │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 生命周期     │ 小时～天     │ 周～月       │ 月～年       │ 永久         │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 完成后价值   │ 归零         │ 大幅下降     │ 持续保持     │ 可能增加     │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 正确处理方式 │ 用完即弃     │ 项目内管理   │ 编译进 Wiki  │ 内化成直觉   │
│              │ 不需要整理   │ 结束后归档   │ 持续更新     │ 定期回顾     │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 放进 Wiki 的 │ 产生噪声     │ 污染知识库   │ 正确用法     │ Wiki 的核心  │
│ 后果         │ 毫无意义     │ 信息过期     │ 越用越值钱   │ 反复引用     │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 不管理的代价 │ 遗忘任务     │ 项目混乱     │ 知识碎片化   │ 没有原则感   │
│              │ 错过截止日   │ 信息找不到   │ 重复学习     │ 决策摇摆     │
└──────────────┴──────────────┴──────────────┴──────────────┴──────────────┘

你看出问题了吗？

这四种信息，需要四种完全不同的「容器」，四种完全不同的「处理逻辑」，四种完全不同的「生命周期管理」。

但我们一直以来做的事情是：用同一个容器（Inbox），用同一套逻辑（存进来再说），把这四种完全不同的东西混在一起。

然后我们抱怨系统太混乱，抱怨自己找不到东西，抱怨维护成本太高。

四、混在一起，会发生什么

我想用三个具体的场景，描述这种混乱是怎么产生的。

不是极端案例，是你可能每周都在经历的日常。

场景一：LLM 把「买牛奶」当知识编译了

假设你把所有的 Inbox 内容直接交给 AI 处理，让它往 Wiki 里编译。

你知道会发生什么吗？

「明天下午 3 点牙医，地址：某某街 5 号」会被提取出几个实体：「牙医」「时间管理」「地址信息」。

它可能会在你的 Wiki 里创建一个叫「牙医」的实体页，里面记录了你的就诊时间和地址。

下周，当你试图问 Wiki「帮我总结一下口腔健康的维护方法」，它会找到这个实体页，然后把「2024 年 3 月某天下午 3 点的就诊地址」当作「口腔健康知识」提供给你。

这不是 AI 蠢。这是你给了它不应该处理的原材料。

垃圾进，垃圾出。

Ephemeral 信息进入 Wiki，Wiki 就开始腐烂。每一条无效信息都是一粒沙子，足够多的沙子进入，精密的机械就会停转。

场景二：用 GTD 系统管理一篇机器学习论文

反过来想。

如果你用任务管理系统来处理「Attention Is All You Need 论文精读笔记」——

你会给它设一个截止日期吗？「该笔记必须在本周五之前完成」？

你会在看完论文之后把它标记为「已完成」然后归档吗？

你会在一年后回顾任务列表的时候，把它当作一个「已完结的老任务」翻出来吗？

当然不会——因为这篇笔记不是一个任务，它是一个「持续有效的参考资料」。它的价值不在于「被完成」，而在于「被调用」。

用错了容器，价值就永远无法被释放。

你存进去的那篇精读笔记，在任务系统里只是一个「已完成 ✓」的条目，永远不会变成你构建知识时可以调取的砖块。

场景三：三年后翻到了一份「明日事项清单」

我在整理旧 Obsidian 文件的时候，曾经翻到过一个笔记。

标题：「明日待办」

创建日期：2021 年 11 月某天

内容：

• 给房东发邮件问续租的事
• 买一双冬季跑步鞋
• 和小林确认下周开会时间
• 研究一下 Zettelkasten 方法

这个笔记安静地躺在我的 Obsidian 里，将近三年。

那个房东的事早就解决了。那双跑步鞋也买了、穿了、扔了。小林的会议早就开完了。Zettelkasten 我研究了三周然后放弃了。

这四条信息，在 2021 年 11 月某天晚上存在了几个小时的价值。三年后，它们是纯粹的噪声。

但它还在我的 Vault 里，就像一具没人清理的骸骨，堂而皇之地占据着一席之地。

Ephemeral 信息如果没有被正确处理（用完即弃），会在你的系统里永远积累，直到你的 Vault 变成一个过期信息的坟场。

五、为什么我们从来没有认真区分过这四种信息

你可能会问：这个道理听起来挺显然的，为什么大家都没有想到？

因为所有的笔记 App，都在鼓励你「先存进来」。

Web Clipper 让你一键保存网页——存进来再说。

iOS 的「分享到 App」让你随手就能把任何东西导进去——存进来再说。

语音备忘录让你随时录音——存进来再说。

「先存进来，以后再整理」这个逻辑，是整个笔记产品行业的默认假设。

但没有人告诉你「以后再整理」的时候，你面对的其实是四种本质不同的东西，需要四种完全不同的处理方式。

你用一套「通用整理逻辑」去处理四种不同性质的信息，就像用同一个洗衣程序洗羊毛衫、牛仔裤、白衬衫和羽绒服——

不是洗衣机不好，是你没有按材质分类。

还有另一个原因，更微妙。

捕获行为，会伪装成价值创造。

你把一篇文章存进 Obsidian 的那一刻，你的大脑会产生一种「我已经获取了这个知识」的满足感。

就像买了一本书，会让人产生「我已经拥有了这本书里的智慧」的错觉一样。

买书不等于读书，读书不等于理解，理解不等于能用。

存进 Inbox 不等于分类，分类不等于处理，处理不等于真正变成了可用的知识。

但捕获行为产生的满足感，掩盖了后面所有步骤的缺失。

于是 Inbox 越来越满，满足感越来越少，焦虑越来越多，系统越来越难以维护，最终走向死亡——我们在第一篇里说的那三种死法。

六、四种信息，需要四种容器

现在我们来说解法的轮廓。

既然四种信息的本质不同，它们就需要四种不同的容器，装载不同的内容，遵循不同的处理逻辑。

text

Ephemeral（会消失的）
    ↓
    容器：任务管理层
    逻辑：捕获 → 执行 → 完成即归档/删除
    核心特征：有截止日期，完成后清理，不进入知识库

Operational（有时效的）
    ↓
    容器：项目管理层
    逻辑：项目创建 → 活跃维护 → 项目结束即归档
    核心特征：与特定项目绑定，项目结束后降级处理

Reference（持续有效的）
    ↓
    容器：LLM Wiki 子库
    逻辑：原料进入 → AI 编译 → 持续更新 → 长期可查
    核心特征：主动编译，越积累越有价值

Evergreen（永久有效的）
    ↓
    容器：核心原则库（Wiki 的最高层）
    逻辑：谨慎筛选 → 精心表达 → 定期回顾 → 内化使用
    核心特征：数量少但质量高，是你思维的底层操作系统

你可能注意到了：

Inbox，不在这四个容器里。

Inbox 不是容器，Inbox 是路由站。

信息进入 Inbox 的唯一目的，是等待被判断类型，然后被送进正确的容器。

Inbox 里的东西停留越久，系统就越混乱。

理想状态下，Inbox 应该是空的——不是因为你把东西全删了，而是因为每一条信息都已经找到了它应该去的地方。

七、那个「判断类型，送进正确容器」的工作，谁来做

你现在可能想到了一个现实问题：

如果每条进入 Inbox 的信息都需要我来判断「这是哪种类型，应该进哪个容器」——

这不就是另一种形式的「整理负担」吗？

这是一个好问题。

如果这件事要人工完成，这套框架就没有解决任何问题——它只是把「整理笔记」换成了「分类信息」，负担并没有减少。

但这恰恰是 AI 最擅长做的事之一。

判断一条信息「天然的生命周期有多长」「主题是什么」「应该进哪个容器」——这不需要创造力，不需要价值判断，需要的只是模式识别和规则执行。

而这，正是 LLM 在几乎零成本下能够做到的事情。

你只需要往 Inbox 里扔东西。

类型判断、路由分发、送进正确容器，AI 来做。

这不是幻想。这是我在过去一年里实际运行的系统的核心机制。

一个叫 /triage 的 AI 技能，每次运行时扫描我的 Inbox，判断每条信息的类型，自动路由到正确的位置。

「买牛奶」进任务层，两天后自动清理。

「机器学习论文」进 Wiki 的 raw 文件夹，排队等待编译。

「和王总明天的会议」进项目文件，带上截止日期。

「复利的本质」进 Evergreen 页面，等待被打磨成精确的原则表达。

你扔进去，AI 分拣，信息流向正确的去处。

八、但还有一个更大的问题

好，现在你可能已经接受了「四种信息需要四种容器」这个框架。

但这里有一个我还没有解决的问题：

这四种容器，放在哪里？

如果你为每种容器单独建一个 App——任务用 Todoist，项目用 Notion，知识用 Obsidian，原则用 Apple Notes——

你会回到工具碎片化的老问题：信息孤岛，切换成本，无法交叉引用。

但如果把四种容器都放进同一个工具里，这个工具的设计必须能够：

1. 支持四种不同的信息处理逻辑
2. 让 AI 能够读取所有容器，做出跨容器的决策
3. 在容器之间保持灵活的关联（一个项目可以引用 Wiki 里的知识，一条 Evergreen 原则可以出现在日记里）
4. 同时不让四种容器互相污染

这是一个非常具体的架构设计问题。

它不能靠选择「正确的 App」来解决。

它需要一套经过深思熟虑的系统设计。

下一篇，我来拆解这套设计的完整逻辑。

不是工具的使用教程，而是架构的设计思路——

为什么是这样的结构，每一个设计决策背后的理由是什么，以及当你理解了这套逻辑之后，整个系统应该怎么在你的 Obsidian 里长出来。

但在我讲那个之前，我想先留给你一个问题，认真想一想：

你现在的 Inbox 里，四种类型的信息各占多少比例？

如果你愿意，现在就打开你的 Inbox 或者备忘录，随机抽 10 条内容，数一数：

有几条是「完成之后价值为零」的 Ephemeral？

有几条是「和某个项目绑定」的 Operational？

有几条是「主题明确、持续有效」的 Reference？

有几条是「普遍适用、永久有价值」的 Evergreen？

这个比例，会告诉你很多关于「你的信息管理系统为什么现在是这个样子」的事情。

在评论里告诉我你的结果。

我猜 Ephemeral 会占大头——超过 50%。

如果我猜对了，那意味着：你的系统一直在用知识管理的逻辑，处理本质上是任务管理的内容，这个错位每天都在消耗你的注意力。