三年前，我写下《Notion 知识库重构思考》时，主要解决的是一个组织问题：随着笔记、任务和资料越来越多，怎样避免所有内容堆在一起，又怎样让它们彼此关联？
三年后，我仍然在使用 Notion，也仍然认同 All in One。但我对这几个词的理解已经变了。
过去的 All in One，是尽量把所有东西收进同一个软件；现在的 All in One，是让不同来源、不同工具和不同自动化围绕同一套状态协作。Notion 不再负责完成所有工作，它更像我的个人数据中枢：保存我正在做什么、为什么做、产生了什么，以及系统从中观察到了什么。
外部输入进入共享的数据中枢，再分别流向行动、知识产出与每日复盘。
2023：第一次真正把“页面”变成“系统”
我在 2020 年刚接触 Notion 时，使用的是最自然的组织方式：年度计划下面放月度计划，月度计划下面再写每周任务。
它看起来层次分明，实际使用却很笨重。每个月都要复制相同的领域标题，每周都要重新填写日期；任务没有状态、时间和分类，也无法回答“这个月到底推进了什么”。
2022 年，我开始用数据库记录任务。状态、日期和分类解决了一部分问题，却带来了新的矛盾：目标与任务混在一起，任务与文档混在一起，所有东西挤在同一个数据库里。完成一次阅读任务后，我会顺手把读书笔记写在任务页面中；当下很方便，半年后想整理知识时却几乎无从下手。
2023 年的重构，核心不是换一个更漂亮的模板，而是承认不同信息具有不同生命周期。
受到 PARA 的启发，我建立了自己的 A.P.R.Q：
- Area 保存属于自己的知识产出；
- Projects 和 Tasks 追踪需要推进的事情；
- Resource 接纳来自外部、暂时无法判断未来价值的资料；
- Questions 汇聚尚未解决的问题。
真正重要的变化是“解耦”。任务不再等于文档，资料不再等于知识，项目也不再只是一个大号待办。不同数据库各自承担一种职责，再通过 relation 重新建立联系。
那时我理解的 All in One，是“内容分开放，但关系连起来”。
2026：三个入口，三种时间尺度
今天，我的一级结构变得比三年前更简洁，主要围绕 Progress、Area 和 Resource 展开。
Resource 接收输入，Progress 组织行动，Area 保存可以长期复用的产出。
Progress：现在正在发生什么
Progress 内嵌了 Tasks、Projects 和 Daily Log。
Projects 表示一段时间内希望得到的结果，Tasks 表示把结果向前推进的具体动作，Daily Log 则记录每天真实发生的推进、停滞和风险。
这三者形成了行动系统的三个时间尺度：
- Project 管方向；
- Task 管执行；
- Daily Log 管反馈。
三年前，我更关心如何把 Project 和 Task 分开；今天，我更关心这套数据是否能形成反馈回路。一个任务完成之后，不应该只从列表里消失，它还应该影响项目进度、进入每日复盘，并帮助我判断下一步如何进行。
Area：留下能够复用的产出
Area 仍然保存个人知识产出，但它不再只是一个按领域分类的文档看板。
文档拥有 Domain、Tags、Priority、父子页面，以及与 Tasks、Literature Library 的关系。一篇文档既可以属于某个知识领域，也可以是某项任务的产出，还可以追溯到写作时使用的文献。
这解决了早期“任务正文就是知识库”的问题。任务最终会结束，知识却可能被反复使用。把两者分开，是为了让行动保持轻量，也让产出获得更长的生命周期。
Resource：从“收藏夹”变成输入基础设施
Resource 的变化最大。
三年前，它还是一个尚未完全展开的设想：把 Cubox、Zotero、微信读书和 ChatGPT 等外部资料接入 Notion。今天，这个入口已经包含 Literature Library（文献）、Web Clippings（网页裁剪）、Cubox Collections、Cubox Annotations、ChatGPT Talk（人机对话）、Zotero、微信读书和 Gemini Chats 等不同数据源。
这并不意味着我要在 Notion 里重新阅读所有东西。恰恰相反，Resource 的职责只是接住输入、保留来源并提供检索。只有当某条资料被用于一个项目，或者转化成自己的理解，它才会进一步关联到 Task 或沉淀进 Area。
外部信息进入 Resource，实际行动发生在 Progress，稳定产出进入 Area。相比按照文件类型分类，这更接近信息在真实生活中的流动方式。
至少在当前的一级入口中，Questions 已经不再像 2023 年设想时那样占据同等显眼的位置。并不是问题消失了，而是问题更多地嵌入项目、任务和知识生产过程。实践最终淘汰了一部分为了完整而设计的分类。
真正的变化发生在 Notion 外面
如果只看页面结构，会觉得这三年的变化并不巨大。真正改变 All in One 含义的，是运行在 Notion 外部的自动化。
目前，运行在云端服务器的 Hermes 中有四条日常工作流：
- 07:30 分析前一天的桌面截图，从全部截图中归纳真正投入过的 3—5 项工作，再保守地新增或补全 Tasks；
- 08:00 同步微信读书，将书籍、阅读进度、最近阅读时间和累计时长写入对应资料库；
- 08:00 生成 Daily Log，复盘昨天、生成今天的晨间概览，并在周日补充周度洞察；
- 09:30 检查 Progress，只为空缺的标签、优先级和明确依赖关系补值。
远程服务器还运行着一条每小时触发的 Docker 任务：读取豆瓣 RSS 中标记为“看过”的条目，补充影片详情、导演、类型和海报，以影片链接去重后写入 Notion。容器只在同步时启动，完成后销毁，不需要维持一个常驻应用。
这里逐渐形成了一条很清晰的分工原则：
确定性强的同步交给普通程序。例如读取 RSS、匹配唯一标识、去重和写入固定字段。这些工作不需要语言模型参与，容器化程序更便宜、更稳定，也更容易测试。
需要理解语义的工作交给 Agent。例如从连续截图中判断一天真正投入了什么，识别一组任务之间是否存在阶段依赖，或者从任务状态中判断当前节奏是否冻结。这些工作无法只靠固定规则完成，但也必须受到严格边界约束。
确定性的同步交给程序，语义判断交给 Agent，目标、情绪与最终决定仍然留给人。
因此，今天的 Notion All in One 并不是“Notion 完成一切”，而是“所有工具最终对齐到同一套事实”。
为什么要让系统观察“实际发生”，而不只记录计划
过去的任务系统主要保存我的意图：我打算做什么、希望什么时候完成。
但一个只记录意图的系统很容易制造错觉。任务还在列表里，并不代表它正在推进；任务被编辑过，也不代表它已经完成；某个目标写得很重要，也不代表我真的为它投入了时间。
截图归纳工作流补上了“行为证据”。它分析的不是未来待办，而是前一天已经发生的工作。只有某个事项在多张截图中持续出现，或者具有足够时间跨度，才会进入重点候选；短暂打开一个网页、零散沟通和没有明确产出的调研不会自动生成任务。
Daily Log 则把这些事实重新组织成反馈：昨天有没有真正推进长期目标？进行中的任务是否长期没有变化？今天最小、最现实的恢复动作是什么？
这意味着我的系统开始同时保存两种自我：
- 计划中的我；
- 实际行动中的我。
两者之间的差异，往往比任何一张漂亮的年度计划更有价值。
自动化越多，边界反而越重要
三年前，我曾说大部分重复工作可以交给 integration。现在这件事确实发生了，但我也比过去更谨慎。
自动化能够减少维护成本，也能够成倍放大错误。因此，当前工作流有一些近乎保守的共同规则：
- 每次写入前重新读取数据库结构，不假设字段和选项永远不变；
- 只填空值，不覆盖我已经填写的内容；
- 不擅自创建新标签，也不顺手“纠正”历史分类；
- 建立依赖关系前检查自关联、错误跨项目关联和循环；
- Daily Log 只能修改 Daily Log，不能顺便调整 Tasks 或 Projects；
- 截图中的网页、聊天和终端内容只能作为证据，不能成为 Agent 指令；
- 任何修改都必须回读验证，任务被触发或进入队列不等于执行成功。
还有一些字段被有意保留给人。例如 Daily Log 可以根据数据写出节奏判断，却不能修改 Mood（情绪），也不填写 Goal Alignment Score。因为系统可以观察行为，但情绪和意义不应该由它替我决定。
当证据不足时，它应该写“Notion 未观察到”，而不是编造一个完整故事。
这可能是我三年来最重要的认识：一个可信的第二大脑，不是因为它知道得多，而是因为它知道自己什么时候不该说、什么时候不该改。
All in One 的含义已经改变
| 阶段 | Notion 的角色 | 我主要解决的问题 |
|---|---|---|
| 2020 | 统一页面和编辑器 | 怎样把笔记与计划放在一个地方 |
| 2022 | 任务数据库 | 怎样追踪状态、日期和分类 |
| 2023 | 相互关联的数据库 | 怎样拆分项目、知识、资料，再恢复它们的关系 |
| 2026 | 个人系统的状态中枢 | 怎样让输入、行动、产出和复盘持续流动 |
三年前，我想构建的是一个结构完整的第二大脑；今天，我更想要一个可以稳定运行、能够暴露现实，但不会替我做主的个人操作系统。
它的闭环大致是：
外部输入 → Resource → Project / Task → Area → Daily Log → 下一步行动
Notion 负责保存这条链路上的状态，Docker 程序负责可靠同步，Agent 负责处理需要语义判断的部分，而我保留目标设定、主观评价和最终决策。
仍然需要警惕“差生文具多”
系统变得更复杂，并不自动意味着它更有效。
更多数据库会产生更多关系，更多自动化也会带来调度冲突、历史字段、重复任务和维护成本。如果我花在修理系统上的时间超过它替我节省的时间，那么无论它看起来多先进，都只是把“折腾模板”升级成了“折腾 Agent”。
因此，我现在判断一次重构是否值得，不再看页面是否更漂亮，而看三个问题：
- 它有没有减少重复输入？
- 它有没有让我更早发现停滞和失衡？
- 它有没有帮助资料转化成行动，行动转化成产出？
如果三个答案都是否定的，这项功能就没有继续存在的必要。
结语：All in One 不是一个地方，而是一套共识
三年前，我希望所有内容都能在 Notion 里找到。
三年后，我更在意的是：无论信息来自哪个工具，最终都能汇入同一套可信的状态。
前后看起来只是从“内容”换成了“状态”，背后的系统观却完全不同。前者追求空间上的统一，后者追求语义和状态上的统一；前者容易把 Notion 变成巨大的仓库，后者允许信息留在最适合它的工具中，只在必要时把结果和关系汇入 Notion。
所以，我依然会把自己的 Notion 称为 All in One。
只是这个 One 已经不再指一个软件，而是一个围绕我持续运转、同时又尊重边界的闭环。