用notion已经好一阵子了，文件体系改了又改，最后搭建了三个db对任务和信息流进行管理。
三个db的主要内容分别是
- 任务：要完成的事情，从生活中的杂事到工作中的项目。
- 文档输出：我写的文档，像是知识点的整理、观点与看法、读后感观后感之类的。
- 文档输入：他人写的，对我可能产生或者已经产生作用的文档。
任务db——Things
基于GTD思想，我将一项任务的处理流程归纳为：
- 收集：将所有可能要做的事情收集起来。
- 判断：判断收集到的事情是否真的需要做。是不是有不需要做的，或者可以交给他人的？尽可能把自己的时间花在可以产生复利的任务上。
- 标签：如果确定要做，就可以给任务添加标签，以便在不同的场景下根据标签检查任务。
- 标签可以依据场所、领域定义。例如有的任务需要在家做，有的需要在办公室做，就可以产生
家办公室的标签。一个任务可以同时打上多个标签，比如整理linux学习笔记就可以打上整理codinglinux家。
每个任务都有了对应的标签，就可以在需要时查看对应的任务。比如说在家就可以查看有哪些任务带有家标签，想要学习时就查看带有学习标签的任务。 - 计划：给任务确定要完成的due date。
在面对有明确deadline的任务时，duedate很好定义，但有的任务并没有明确的完成日期，要怎么定义呢？
如果完成这个任务的时间我可以估计，那就定义在周末或者是肯定有闲暇时间的时间段；
如果是一个无法估计需要多长时间的任务，例如阅读一本教材，我会选择不定义due date，将这个任务当成一个长期任务。 - 去做。
基于以上流程，一项task应该至少拥有名称、状态（做了没做）、标签、预计日四个属性。对任务的视图，也至少应该包括收集箱、各式标签视图、日期视图。
所以，我创建了一个名为 Things 的db（从名词就可以看出，这个db的设计参考了 Things）。
Things的栏位如下，从五个维度定义一项task
部分view如下
每个view根据预计日、tag、status进行筛选，确保我在需要的时候看到相应的任务。
在办公室时就打开@办公室，想阅读的时候就打开阅读，想了解接下来一周就打开upcoming，想知道有什么长期任务就打开someday。
文档输出——Docs
管理文档最重要的是管理它的内容，我选择使用标签而不是文件夹来管理文档。一个文档可以使用多个标签标记，可是无法归属于多个文件夹。
通过标签，我也可以创造多个视图来在不同场景下查看相应的文档。
我将文档输出的db命名为docs，由以下栏位构成
文档使用Last edited time 从新到旧排序，以便找到最新编辑过的文档，进行修修补补。
那久未编辑过的文档难道就要不见天日了吗？不，random 栏位可以制造随机数，间接实现“随机漫步”的效果（详细实现过程参考这里），使老文档重获新生。
tags 即标签，标签的维度包含了主题、类型、状态，以便我在需要的时刻看相应的文档。目前部分标签如下
根据这些tag，我也创造了不同的view。
文档输入——Collections
文档输入其实相当于各个平台的收藏夹，将微信、小红书、知乎、bilibili等收藏内容全部移动到一个地方进行统一管理，我将这个db命名为Collections。依然使用了标签体系对文档标记，管理思路同Docs一致。
db之间
任务、输入、输出，三者之间必定会存在联系，目前的联系有三种：
- 输出对输入的引用
- 任务中提到输出
- 任务中提到输入
对于引用，我使用双向链接处理。这样我可以了解到哪篇输入被大量引用，提醒我这个输入可以常看常新。
对于任务中的提到，我只使用了单向链接。因为我的使用场景是在要完成任务时打开文档，那只需要提供快速过去的路径就够了，不需要从文档那知道和哪些任务挂钩。
最后
在notion之前，我尝试过多种写作和任务管理工具，从他们的设计中受益良多。
比如bears的标签体系、obsidian的双向链接，things的GTD……
相比大部分的工具，初始的notion的确显得简陋。但这也正是notion的特点，尽管没有上述工具的体系，却可以通过使用者本人的习惯搭建属于自己的系统，构建属于自己的第二大脑。