我如何改造 Obsidian｜模板开发日志（三）

前情提要

• Obsidian 模板开发日志（一）：下定决心
• Obsidian 的三个问题｜模板开发日志（二）

本文是 FLO.W Obsidian 正式发布前的最后一篇开发日志，随后我将进行一轮 Beta 测试，如果你感兴趣的话可以通过下方链接，加入飞书交流群。

加入 FLO.W Obsidian 飞书交流群

另外，本文真的非常长，理智告诉我应该拆成三篇四篇去发，但我还是固执地用一篇写完，实在不想让连贯的思路断链，因此也接受超低的完读率，和可能劝退用户购买的反效果。

我坚定地相信，只有把思想转化为文字，思考才算真正完成。倘若不把这半年来的全部探索和执念，完完整整地呈现在这里，这一场漫长的开发在我心里就无法划下句号。

好在我也有相同的自信，如果你是对知识管理感兴趣的人，或者你正在开发自己的笔记软件，那么本文所写的种种探索，你或许也只能在这里看到了。

开发背景

外部世界对我来说是不可预测的，任务会突然涌现、灵感会转瞬即逝、计划会被随时打乱，这种失控感是我焦虑的根源。

所以我总是期待能有一个地方可以收纳所有的不确定，将其规整、量化，并转换为明确的下一步动作，让时间可以被妥善地安排，让目标带给我持久的进步和产出。

我由衷地希望这个工具可以让我每天睡觉前，都感觉这一天充实圆满，并对第二天的到来充满期待。

一年前通过对 FLO.W Notion 模板系统的开发，我几乎圆满地兑现了这一份期待，也满足了超过 1600 名 Notion 用户和我一致的诉求。

同时私信里也持续不断地出现 Obsidian 用户的声音，因此在持续开发了半年之久后，今天我终于能把属于 FLO.W 的同一套底层逻辑，从 Notion 带到 Obsidian，让已经验证可行的规则继续在本地文件系统里落地生根。

并且我必须承认，曾经我认为的「Obsidian 只有落后的分类逻辑」的印象是刻板落后的，尤其是一度被我评价为半成品的 Base 功能，现在我也已经解锁了它的全部潜力，相信也一定能给你惊喜。

产品定位

AI 时代纯粹的知识管理已经不再必要。

人们应当真正关注的，是在长期工作中产生的信息、知识、目标与行动，该如何和谐有序地进入统一的系统内持续运转，让人专注于判断与选择，让 AI 承担繁琐的执行，在同一套上下文里协同推进。

FLO.W 是基于这个使命所构建的，一套能衔接思考与行动的 Obsidian 工作系统。

它以 Obsidian 为基础，包含配套的模板库和定制的插件系统，能帮你快速捕捉每天的思绪、行动和好奇心，将高价值的信息存进一个结构清晰、人和 AI 都能高效处理的工作台，让行动更敏捷、让思路更顺畅。

基于 Obsidian File Over App 的产品哲学，FLO.W 可离线、可买断、不对 Markdown 文件做过多侵入式修改，帮你从今天起搭建一个 50 年后依然清晰可读的个人数字保险库。

倘若有一天 FLO.W 出于某些意外必须终止维护，我会将产品开源，以保证必要的存续条件。

设计思路

整齐的秩序能给人带来掌控感，有效的链接才不会让信息沉底，切实行动才能带来真实收益，复盘校准才能迭代出正确方向。

基于对秩序、链接、行动、以及校准的四个核心追求，我构建了 FLO.W 这套系统，即 Foundation、Link、Operate、Watchtower。

接下来我会逐一拆解它们在 Obsidian 里的实现方式，首先要面对的，就是大多数人最容易开始、也最容易失败放弃的分类体系搭建。

秩序

传统的笔记秩序依赖人的整理，需要自己把东西放到该放的地方。

但整理依赖记忆和自觉，而这两样都会衰减，记忆会遗忘，自觉会偷懒，所以依赖文件夹和标签的分类方式必然渐进式崩坏。

全盘丢给 AI 归类和查找看似省事，但这只会让你的笔记库变成一个人类难以阅读和操作的黑盒。

因此 FLO.W 通过预先设定好以下四条规则，让用户（以及用户的 AI）能在一套逻辑自洽的有限空间内自由生长。

用有限对象简化分类逻辑

文件夹陷阱

在我有限的人生里，从来不见有人可以真正用好文件夹，当你用主题、场景、或是来源的方式去做分类，你就落入了文件夹的陷阱。

一个文件只能同时存在于一个文件夹，当你选择了其中一个，你只能选择表达这个文件的某一个面而放弃其他属性。当你希望表达更多的时候，你就会增加更多的文件夹或标签，然后管理成本就越来越高。

你当然可以选择全盘交给 AI，不再手动维护任何文件夹，但对依然在坚持手搓文章和笔记的我（或者某一类用户）来说，保持文件夹的人类可读性和可操作性，依然是我所追求的一个最低标准。

最简化结构

在长久的实践中，我逐渐摸索出了一种与「主题式笔记分类」不同的分类逻辑，它的核心灵感来源于 Tiago Forte 的 PARA 方法论，意在用信息与行动之间的关系将信息分成四类：

• Project
• Area
• Resource
• Archive

但在 PARA 中「资源 Resource」的定义非常模糊，而「归档 Archive」则更像是一种信息的状态而非类型，因此 PARA 对我来说并非最优解。如果你比较关注这个圈子的话，应该也曾看过很多基于 PARA 的变体。

我采纳了 Area 和 Project 的广泛定义，并结合我的个人实践，提炼了四种我认为最重要的元信息类型，它们分别是：

这四种信息类型首先是可以自上而下拆解的树状结构，一个领域下会有多个项目，每个项目都可拆分成若干任务，每个任务在执行过程中都可能产生各种有价值的笔记。

接下来，其他所有看似繁杂的细分需求，都可以从这四个基础对象中自然生长出来。

比如会议纪要、灵感闪念或是读书心得，你不需要再去新建额外的文件夹，它们本质上都只是这四种元对象补充了特定属性、再配合 Base 筛选后的不同「视图」。

所以原则上 FLO.W 只设定了最基础的 4 个顶层文件夹：

• 任务
• 笔记
• 项目
• 领域

当然仅凭这条规则还无法承载更复杂、更个性化的信息分类需求，因此接下来就需要用到「字段属性」这一工具，才能为不同的信息对象扩展它可承载的深度和广度。

用笔记属性承载关键事实

标签的陷阱

标签其实就是另一种形式的文件夹，因此文件夹存在的所有问题，在标签这个工具里同样存在，甚至更糟糕。

你可以在一句话之中、一个段落的末尾、甚至是一篇文章的开头或结尾打上标签，这使得标签的创建速度更快，限制更少。并且标签的语义更加是即兴且模糊的，比如灵感和想法、资源和参考、方案和规划，只要意义有所重叠，就会在你需要调用标签进行分类的时候造成困扰。

更大的问题是，当你希望在 Obsidian 的 Tags 属性菜单中找到曾经用过的标签，那么不同类型的标签就会杂糅在一起，有的是任务状态标签，有的是主题分类标签。

这个查找的过程会非常发散和烦人，容易让人陷入选择困难的境地，或者因为找不到想要的标签，于是又随手创建了一个新的，最终往往只能痛定思痛地留下「标签无用」的结论。

属性的解法

笔记属性其实就是预先分组、且自我设限的标签，它的位置是固定的，它的选项是预设且有限的，虽然降低了自由度，但也显著降低了选择的成本。

在 FLO.W 中，每一个 Markdown 文件通过填写笔记属性 FLO.W 的方式去回答，它属于哪一种元信息类型？

当它是笔记时， FLO.W = Note ；当它是任务时 FLO.W = Task 。如此便规定了每一个新建文档的基本用途和用法。

接下来所有的新增字段，都是基于 FLO.W 这个地基字段进行扩建。

因为 Task 是用于追踪某个需要被完成的动作，所以它可以增加 Status、开始日期、结束日期、完成时间 等用于描述进度的字段；因为 Note 是用于记录需要被反复调用的信息，所以它可以增加 笔记类型、关联领域、关联项目 等字段。

有限的笔记属性确定后，属性的值域也应该是受限的。

在默认预设下，Status 仅设定 Todo、Doing 和 Done 三种元状态，笔记类型仅预设 Log、Ask、Exp、How 和 Idea 五种元类型，如非慎重思考后的结论，否则一般不再增加更多选项。

基于这种方案，我们既可以实现标签的基本用法，也可以消解传统标签会带来的分类难题。

你无法在一句话里随手打上一个笔记属性，因为它只存在于文档的头部位置；你也不需要再面对即兴语义的困扰，因为每一个笔记属性的值都已经预先定义；你更不需要面对不同类型的标签杂糅在同一个下拉菜单里的情况，因为状态、类型、以及关联等字段都是各自独立的。

到这里我们只剩下最后一个问题需要解决。

标签除了标记文本特征这一功能，还有一个用处就是可以起到聚合文档的作用，所以我说标签其实是另一种形式的文件夹。但标签的聚合虽然快速，聚合的结果却是笼统的，你总不能期望用模棱两可的定义去获得精确的结果。

但在 FLO.W 中，信息的聚合检索可以做到更智能、更高效、更精准，那就是基于笔记属性的 Base 聚合检索。

用动态表格实现更优检索

传统表格的局限

对我来说，表格就是秩序的象征，它可以排序、可以筛选、可以从全局视角俯瞰，也可以聚焦某个局部观察。横平竖直、整齐有序，只要信息精确完备，就能够给人一种「信息被照顾妥当」的安全感。

但传统表格所呈现的只是交织在行和列里的单元格，这些单元格只能体现一条信息的关键特征。

所以 Notion 数据库的创新是让每条记录都可以被打开为一个独立的文档，并且文档内还可以继续内嵌文档和数据库，即便递归也被允许。

所以 Obsidian 能实现这样的效果吗？

我曾经认为 Obsidian 的 Base 只是一个赶趟上架的半成品，但事实证明，当我给所有的文档都分配了 FLO.W 这一笔记属性后，Base 几乎可以看作是青春版的 Notion 数据库了。

动态透视的解法

在 FLO.W 的基本框架里，有限的文件夹与 4 种对象类型严格绑定。

当你在「任务」、「笔记」、「项目」或「领域」文件夹中新建文件时，头部的 FLO.W 属性会被 FLO.W Core 插件自动赋予对应的 Task、Note、Project 或 Area 的值，不需要你手动填写。

这在目录层面完成了文档的第一层分类，每篇文档在创建的瞬间就被标记了它的元信息类型。

但单一的顶层文件夹无法回答更具体的场景，例如哪些是即将过期的任务、哪些是上个月完成的项目、哪些是最近半年写过的经验笔记？

如果为了这些场景去不断新建子文件夹，我们又会重新陷入文件夹层层嵌套的陷阱。

Base 能用动态过滤的方式解决这个问题，但前提是被过滤的文档必须有标准、可被计算的笔记属性。所以我们让 4 种基本的元信息类型作为主干，向下分叉出受限、可控的笔记属性，如状态、笔记类型、关联项目等。

然后你就能随时从有限的文件夹里切分出清晰的功能视图，比如所有的 How 笔记.Base、所有进行中的任务.Base、或是某个领域下的所有关联项目.Base。

而且 Base 所聚合的每一个文档，实际上都是一条超链接。

打开链接后你得到的不只是一篇文档，还是一个容器，因为文档之内同样可以再内嵌 Base，而这个新的 Base 又可以动态过滤整个 Vault 之内的任意对象。

于是打开项目页面，你可以看到的它聚合了这个项目下所有任务；打开任务页面，又能看到属于它的所有笔记。

记录、透视、打开、内嵌，递归，与 Notion 数据库的基本效果如出一辙。

当然 Notion 数据库的各种高级自动化与丰富视图，目前在 Obsidian 里仍有巨大差距，这一点读者们还是应当抱有正确的期待。

所以到这一步，我们通过 FLO.W 的四种元信息，加上衍生的笔记属性以及 Base 的聚合检索，就可以实现用有限的文件夹去管理几乎无上限的分类场景。

Base 里的视图（View）是可以随时创建、随时删除的动态观察窗口，不论如何操作，归档在文件夹之类的文件都不会受到任何影响。

并且 Base 还有个特性可能会让你觉得它比 Notion 数据库更好，那就是 Base 的检索是覆盖整个笔记库的，而 Notion DB 的数据源是固定受限的。

如何理解呢？

Notion 是先有数据库，再有库里的 Page。而 Obsidian 一般是先有 Page 再有 Base。这意味着，如果你想在「笔记库」里新增一条笔记，Notion 会要求你先找到这个数据库再去做新增的动作。

而 Obsidian 只需要将任意一篇文档加上 Note 的字段，它就能立刻出现在对应的 Note.Base 之中。因此理论上在 Obsidian 中你不需要设置任何文件夹，只需要设定好字段，然后再利用 Base 去全局检索和管理即可。

但这显然违背了我们「人类可读、可操作」的初衷，所以为了避免这个笔记库变得杂乱不堪，我为 FLO.W 开发了一个名为「自动路由」的核心功能，它其实是我构建整套系统的起点。

用自动路由实现自动整理

Notion Database 和 Obsidian Base 都有一个特性就是，如果在带筛选条件的视图中新建页面，则新页面就会自动继承视图的筛选条件。

例如在 Status = Doing 的视图里新建，则新页面的 Status 会被自动设置为 Doing，这样才能满足让它出现在当前视图里而不被过滤掉的条件。

Notion 因为数据库的源已经确定，所以不论再怎么在数据库内创建 Page ，这个新的 Page 都不会污染其他的 Page 或者 DB。

但 Obsidian Base 的问题在于，当你点击 Base 右上角的新建按钮，系统会将新建的文档默认放置在「新建笔记的文件夹」这个设置所指定的位置。

所以通过 Base 创建文档之后，你只能再手动去修改这个文档的位置，或者干脆不改了就那么放着。

为了解决这个问题，我开发了「自动路由」这个功能，可以实现以下自动化流程：

• 填入特定字段，文件自动移动到对应目录
• 建在特定目录，文件自动写入对应的字段

例如当你在「笔记」这个文件夹内新建文档，则 FLO.W 这个笔记属性会被自动写入 Note 的值；当你将「任务」文件夹里的文档拖动到「笔记」文件夹，FLO.W 的属性值也会从 Task 变成 Note。

此外，当你为任意文档添加 FLO.W = Note 的属性值，不论这个文档当前处于什么位置，自动路由都会将它移动到「笔记」文件夹，当你再给它添加 笔记类型 = Log 的属性值，则它还会被自动移动到 笔记/Log 的子级文件夹里。

在自动路由的维护下，你在各个 Base 里新建的文件，都会自动获得对应的属性与存档位置。

4 种基本的元信息划定分类边界，受限的属性和值域定义信息的特征，Base 负责覆盖整个笔记库的动态切片，自动路由负责兜底的位置对齐，这套规则可以在不依赖 AI 的前提下，有效降低人工整理的成本，让本地文件系统始终保持在整齐有序、清晰可读、可操作的状态。

链接

过去 PKM 生态常见且被大多数人接受的观点是，你必须主动建立链接，知识网络才会逐渐形成。

但如今 AI 在发现潜在关系这件事上，一个 grep 命令就让多少双向链接显得不再必要，因为我们随时可以根据当前的上下文将其立刻计算出来。

但链接的价值并未消失，只不过我们需要将链接的目的从「检索」转变为「约束」，也就是用链接关系去明确那些，只有人作为主体才能确认和负责的事实。

比如，任务 A 属于项目 B、项目 C 的负责人是 D、最终方案写在了笔记 E，F 的结论来自笔记 G，改变了前提 H 则结论 I 就会受到影响...

AI 当然可以将这些信息猜得八九不离十，但猜测和事实是不同的两件事。

你可以不用再穷举信息之间可能存在哪些关联，但仍然必须定义什么对自己是真的、什么对自己是重要的、接下来允许发生什么，以及你更希望行动以怎样的路径去推进。

而以上一切，在 FLO.W 中都可以用合适的「链接」去表达。

让关联表达意图

当你设定好了每一种元信息类型的用途和用法，那么它们之间的关联将自然带有明确的意图，这可以解决过去双向链接只能表示有关系，但解释不了到底是什么关系的问题。

FLO.W 的三种信息对象首先具备明显的树状层级，展示的是包含与被包含的关系：

领域 A
└── 项目 A
    ├── 子项目 A1
    │   ├── 任务 1
    │   │   ├── 子任务 1.1
    │   │   └── 子任务 1.2
    │   └── 任务 2
    └── 子项目 A2

它直观展现了一条从长远愿景到具体动作的推进路径：

领域：锚定一部分人生愿景
└── 项目：实现这一愿景的阶段性规划
    └── 任务：实现这一规划的分解动作

在执行层面很容易理解这种拆解动作，先把大目标拆解为小目标，小目标再逐个击破，最终实现大目标的完成。

接下来，「笔记」这个对象还会被进一步拆分为 5 种预设的「笔记类型」：

• Log ：真实发生的过程与事实
• Ask ：等待解答的疑问与困惑
• Exp ：实践沉淀的经验与心得
• How ：可供复用的方法与步骤
• Idea：有待探索的灵感与假设

那么当 Task、Project 或者 Area 与不同类型的笔记相关联时，就可以让这层关联展现更多的信息量，例如：

在一般 Obsidian 用法中，表达这类关联最习惯的做法，就是在正文里随手敲一个 [[双向链接]]。

但这种正文里的双向链接，往往只有链接的发起方才具备完整的上下文。

比如你可能习惯在日记里随手引用今天完成的任务，在项目里随手关联相关的参考资料，站在当前这篇文档（链接发起方）的视角来看，关联的意图非常清晰，你写的时候当然知道自己为什么提到了它。

但这种清晰只是单向的，一旦你把视角切换到那个被链接的[[目标页面]]时，问题就会出现。

无论是你随手打的一个词、一篇严谨的参考文献、一个需要执行的待办，还是一个从属的子主题，在反向链接面板里长得完全一样，没有任何语义和轻重的区分。

为了让关联能显示更明确的意图，在 FLO.W 中，关联是直接写入文档头部的笔记属性区域的，如果你曾是 Notion 用户的话，应该很容易理解这种类似 Relation 的用法。

在属性里写下 关联项目 = [[项目 A]]，原本潜藏在字里行间的关联意图，就可以转变成 Base 可读、可筛选的结构化数据。

而且在实际操作中，你完全不需要手动给每一篇文档逐个填写这个字段。

当你在某个项目页面的 关联任务 Base 点击新建页面按钮，这个新任务会因为当前 Base 视图的筛选规则，在创建的瞬间就自动具备 关联项目 这个笔记属性，并将当前项目的名称自动填入字段中。

当你将 10 个任务关联到了 1 个项目里，这个项目就顺理成章地成为存放和管理这 10 个任务的容器。

让页面成为容器

在 Obsidian 的早期探索中，人们习惯用 MOC（内容地图）的方式来扮演容器的角色，首先创建一个核心的主题页面，然后在页面里打上一长串 [[双向链接]] 作为索引。

但这种静态容器并不能真正创建页面之间的从属关系，你当然可以在 MOC 里看到索引笔记的不同层级，但是进入被索引的笔记页面，你只能读到「有关系」而不能读到到底是哪一层的关系。

并且你在其他地方创建的新笔记，无法自动汇入这个 MOC，你只能手动添加一条索引。或者如果你是通过 MOC 内链的方式去创建新的笔记，则这条笔记又无法被放到正确的文件夹位置。

而在 FLO.W 中，页面中的 Base 可以成为动态过滤的容器，整个笔记库内，所有符合筛选条件的内容，都会实时呈现在 Base 之中：

• 打开领域，Base 聚合属于它的所有项目
• 打开项目，Base 聚合属于它的所有待办
• 打开任务，Base 聚合属于它的所有笔记

这种包含关系还可以向下递归，任务页面可以内嵌子任务 Base，项目页面可以内嵌子项目 Base，笔记页面也可以内嵌子笔记 Base，从而实现更细分的层级管理。

还是以《咖啡》主题为例，在 FLO.W 中，每一个页面都可以借助内嵌的 Base，成为一个具备「收纳与展示」能力的容器：

Base 里的页面再内嵌 Base，知识的收纳与展示就有了无限递归的可能。

每一层容器都只负责展示与当前主题直接相关的内容，同时又自然成为通向下一层子主题的入口。你不需要小心翼翼地在单篇文档里手动维护那张容易混乱的 MOC 索引，每一篇新笔记在被创建时，就可以被「自动路由」功能存放到合适的位置。

行动

我们常常习惯用待办清单来管理行动，先把要做的事记下来，然后祝愿执行力可以督促自己完成任务。

但冒出一个念头很容易，到底要怎么做却又不是那么清楚。又或者其实事情本身并不难，甚至很简单，因此你懒得去沉淀流程与模板，总习惯于每次都是重新开始，忽略了积少成多的隐形支出。

我相信会阅读本文，甚至还能读到这个部分的读者，执行力一定已经远超常人，但拖延问题定然在所难免，这并非主观懒惰导致。

原因在于，意志力是有限的资源，尤其在今天我们更多的是扮演向 AI 发号施令的指挥，如果你的精力都被执行前的琐事摩擦消耗掉了，你甚至连给 AI 下达正确判断的心力都没有。

所以 FLO.W 有一整套承上启下、逻辑自洽且验证有效的行动体系，可以尽量消除每一次行动之前的摩擦。

• 按钮 → 解决高频触发问题
• 模板 → 解决重复搭建问题
• 目录 → 解决进度流转问题
• 视图 → 解决信息过载问题

用快捷按钮封装高频操作

之前在 Notion 里使用 Button 功能时，每次都有种莫名的爽感，因为你可以将复杂或麻烦的操作流程封装到一个按钮里，每按一次就感觉你好像从哪里偷到了十几秒的时间，所以我觉得按钮是一个好文明。

在 Obsidian 中，快捷方式其实也不少见，但不论是官方功能还是各种流行的 Obsidian 效率插件，常常起手就是让你按一下 Ctrl+P 唤出命令面板，然后你只能祈祷自己还记得那个组合快捷键到底是什么。

记得住的话确实很酷炫、很有生产力，但大多数人会在 1 个小时后忘记原来自己还装过这个插件。

所以从构建 FLO.W 的第一天起，我就在思考怎样才能让整个行动流程更顺畅、更符合直觉。

最后我的答案是，把日常反复出现的操作，封装成侧边面板上一键触发的「开关按钮」，让高频操作不再依赖键盘快捷键，你只需要记住按钮大概的位置，就能形成肌肉习惯。

同时，「当前页」面板会根据文档的 FLO.W 属性自适应感知，打开任务时只呈现排期与标记完成，切到笔记时只显示专属的笔记模板，省去在一大堆无关按钮里挑拣的麻烦。

不仅如此，Obsidian 官方还有很多功能，用户用了一两年都不知道它们的存在， 比如限制行宽、堆叠标签页等，FLO.W 按钮面板会把这些实用操作全部做成直观、通用的开关，让它们更加触手可及。

当然目前的动作面板主要运行在我预先设计好的几套高频动作上，但面板已经搭好了基础框架，未来或许可以开放更多的自定义接口，让每个用户能根据自己的工作习惯，把属于自己的复杂需求也封装成专属的一键按钮。

用标准模板降低启动成本

在我看来一个人工作能力是否娴熟，很大程度可以体现在他会不会用模板来偷懒，或者更高大上一点，有没有沉淀下自己的工作 SOP。

如果每次工作都要从一张白纸开始，你很难不会有畏难情绪，即便只是要在脑子里简单过一遍标题、排版、或者思考需要填哪些字段，这些虽然简单但是繁琐的准备工作，往往会消磨掉一个人最初的工作积极性。

而且因为格式并不固定，随手写下的结构必然千奇百怪，有时会漏了状态，有时属性名会写错，就有可能导致你写完的笔记不能出现在对应的 Base 视图之中。

在原生 Obsidian 里，模板通常只是机械地贴入一段文本，想要实现动态的模板逻辑，则需要折腾复杂的第三方插件或脚本。

而在 FLO.W 中，模板由 Core 插件在底层全面接管，在文件新建的时候，就可以把动态规则一次性装配好。

这其中就包括以下 4 种基本的模板类型

• 属性模板：补齐关键字段
• 容器模板：预装过滤视图
• 提问模板：固定提示设问
• 自建模板：上架专属按钮

每一次行动的开始，你都不需要再对着空白页发呆，也不用在重复搭建框架中耗费心智，完全可以把繁琐的框架交给模板，把高频的触发交给按钮，这样就可以更快地进入执行状态，更好地利用有限的时间。

用目录高度投影行动状态

得益于自动路由这一功能，我在 Obsidian 中实现了一种极简且高效的任务管理模式。

过去文件夹让人诟病的一个地方在于，当目录太多、层级太深，只要展开几次子文件夹，就会让文件目录的高度占满整个窗格，于是你就只能来回展开、收缩、滚动目录，这实在是非常麻烦。

但其实我们也可以反过来利用这个限制，也就是用文件目录的有限高度来作为一道警戒线。

在 FLO.W 的框架里，无论是「任务」还是「项目」文件夹，暴露在根目录下的，只有 Status = Doing 的事项；而 Status = Todo 或 Status = Done 的事项，则会被自动路由分别收纳在各自的子文件夹中。

这就意味着你平时展开任务文件夹，第一眼看到的只会是你手头真正在做的那几件事。

一旦事情做完，你只需要在按钮面板里点击「完成任务」的按钮，按钮就会将 Status = Doing 改写成 Status = Done，然后自动路由就会识别到这一变化，立刻将它从根目录移入「已完成」文件夹里归档，让这条任务瞬间从你眼前消失，做完一件，目录就缩短一行。

堆积的任务会把目录拉得越来越长，当你发现目录甚至需要滚动才能看完全部的时候，你就会意识到，你的欲望已经超出了执行力承载的范畴，你的注意力带宽已经快要超载。

要么停止新建任务，专心清空眼前的 Doing，要么把囤积很久任务暂时退回待办，给注意力重新腾出空间。

通过这种简单但行之有效的即时反馈，我可以不用再把时间花在管理任务上，不需要在看板、报表之间来回切换，只有「快点把任务目录清空吧」的充足动力。

不过这种方式虽然简单够用，也只能简单反映「正在执行的事项」这一个切面。如果你想要从更多维度去观察更多细节，比如耗时太久的任务、已逾期的任务、最近 7 天完成的任务等，我们就需要用到 Base 提供的动态过滤能力。

用视图聚焦当下执行重点

与 Notion 的 Database 相比，Obsidian Base 的一个优点在于，只要符合过滤筛选条件，那么不论你的笔记被放到哪个犄角旮旯，都可以被符合条件的 Base 视图检索到。

所以只要你的字段足够规范、字段的值域足够精准收敛，你就能用 Base 从整个笔记库里切分出任何你所需要的视图。

过去文件夹分类之所以屡试屡败，是因为人们总试图用单一的物理位置去承载所有的分类维度，既想按主题存，又想按状态分，还想按时间排，但你不可能把一份文件，同时塞进三个不同的抽屉里。

而在 FLO.W 中，文件夹只负责最朴素的基本归档与状态兜底，至于在不同场景下你想怎么看、看哪些内容，全部交给视图来呈现。

以任务 Base 为例，FLO.W Core 插件将隐藏在下拉菜单中的视图平铺到侧边栏，随手点击就可以快速切换不同视图：表格视图通过公式标出放置过久的任务，方便看清哪件事一直没能推进； 看板视图把进行中的任务直观排开，拖拽卡片即可更新进度； 日历视图把带日期的任务按天呈现，一眼就能看清日程冲突。

而且在特定视图里直接新建文档，新文件会自动继承该视图的属性，并由「自动路由」送入正确的目录。

按钮负责触发，模板负责结构，目录呈现负荷，视图过滤焦点，通过这些机制的组合，FLO.W 能有效减少日常执行的琐碎摩擦，帮助你更快地进入工作状态。

校准

行动不是一件坏事，但行动本身仍然具有一定的欺骗性，你每天顺畅地勾选任务、清空目录，很容易产生一种「我很努力、事情在推进」的满足感。

但如果把时间拉长到半年或者一年，你再回头看时或许会疑惑，这段时间自己都做了什么？好像每天都很忙，但这些被消耗的精力，到底托举起了哪一个人生目标？

如果没有更高的视角来审视全局，你可能从一开始就把力气用在了错误的方向。为了解决这个问题，FLO.W 最后一个「校准」模块尝试用以下三种方式解决：

让行动与目标不脱节

前文已经讨论过，FLO.W 系统存在一条可以自上而下拆解的行动链路：

• 领域（愿景、人生主线）
  • 项目（方案、阶段规划）
    • 任务（待办、快速动作）

因此领域不会被完成，它将成为一种用于确定人生方向，并沉淀长期复利的资产账户。

在不同人生阶段、不同的人生境遇下，每个人都会有不同的追求，所以你既可以设置「身心健康」、「婚姻家庭」、「财富管理」这样人人皆需呵护的通用领域，也可以根据你的职业、志趣与追求设立专属方向，比如「内容创作」、「软件开发」或是「某项手艺」。

倘若你的行动系统内没有类似领域模块的划分，那么老板派发的任务也许就是你生活清单的 90%，每天睁开眼，无数琐碎的待办扑面而来，你变得麻木机械，只能把大部分心力消耗在这些应激反应上，不知不觉就感觉整个人生都被一份工作吞噬掉了。

但当你有意识地为人生设置更有价值的核心议题，那么它将时刻提醒你，所谓本职工作也只是你多个领域板块里的其中之一，它只是你在打的一份工而已，别让它占据你的人生全部。

在 FLO.W 中创建一个领域其实非常简单，它其实就是一个写好愿景、目标的 Markdown 文件，平时所有相关的任务、项目或笔记，都可以直接关联到这个领域文件上，就像是把某种无形的资产投资储蓄到这一个账户上。

同时每个领域在被创建的时候，都会由 FLO.W Core 插件自动新建 4 个容器页面，它们分别是：

• 领域 - 关联笔记
• 领域 - 关联任务
• 领域 - 关联项目
• 领域 - 关联剪藏

这里的每个关联文件里，都会由 Core 插件自动创建一个关联到领域本体的 Base。

利用 Base 的动态检索功能，只要你在日常记录时将文件关联到领域本体，Base 就会自动把全库所有相关的项目、任务或笔记实时抓取并呈现出来，不需要你手动去维护任何汇总列表。

如果这个领域下的 Base 堆叠着推进中的项目、做完的任务和沉淀的笔记，这说明你的长远目标正在被真实的工作填充。

如果这个领域下的 Base 寥寥无几甚至一片空白，要么是你立了一个宏大的愿景，但实际上从未为它真正立项推进过，要么是你每天忙得精疲力竭，却从不给自己的行动和思考建立归属关联，任由力气四处散落，没有为这个人生议题留下有价值的沉淀。

有了领域可以挂靠，哪怕做着被迫接下的项目，你也可以多想一步，这里踩过的坑能不能沉淀为属于自己的经验（Exp），摸索出的流程能不能提炼成未来跳槽的底牌（How）。

在「校准」视角下，领域所圈定的人生议题，可以把模糊的情绪和盲目的忙碌，转化成清晰可见的数据积累，哪个方向正在荒废，哪个方向成果丰硕，都可以在这些 Base 里看得清清楚楚。

用报表追踪长期变化

当一个人开始减肥，就会开始算计每一天、每一餐、每一次运动后的体重变化，但通常站在秤上的那一刻都会感到失望或者不解，只吃了两口饭为什么体重会增加，一个小时的有氧怎么秤一点都不带掉的？

如果你的心智不够坚定，很容易会被这些噪音影响到。

不过让人宽慰的一点是，只要你真的坚持锻炼、坚持节食，并且把时间窗口拉长，不要计较短期内的波动，就一定能看到一条清晰的、让人振奋的下降曲线。

所以报表是一个非常强大的工具，很多时候坚持下去的动力都来源于看得见，因此在 FLO.W 中几乎所有功能模块都有属于自己的报表系统。

不论是任务的推进完成、项目的阶段交付、笔记的知识沉淀，还是剪藏的消化引用，FLO.W 都为每一个核心对象建立了统一刻度的长期报表。

再往上更有看清精力分配的领域流向图、记录打卡与专注的行动看板、还原真实工作状态的活跃时段，以及把刻度拉长到一生的人生余额与人生曲线。

你不需要每天花时间去分析这些数据，它们会在后台安静地自动汇算，当你需要回顾或者感到迷茫的时候，打开看一眼就能客观地知道自己的状态。

FLO.W 希望成为你至少未来十年的一面镜子，不管生活或工作如何变迁，回头看时不会觉得自己虚度了某些时光，所有的努力和成就都有迹可循。

用复盘校正执行方向

我其实心里知道，复盘模块的使用率应该会是最低的。

认真做一次复盘太过耗费脑力，收益也很难在当下立刻显现。很多人的复盘之所以中途夭折，是因平时缺少轻量的记录，到了周末或者某个复盘节点，只能凭模糊的记忆和主观的情绪去猜想回忆，复盘就很容易退化成无意义的自我感动或自责。

复盘的好处显而易见，但它应该要有取巧的方法。我认为一套能长期运转的复盘体系，应该至少具备以下三个特点

• 低阻力
• 周期性
• 渐进式

首先在日常工作中，你完全不需要带着「我今天必须写出深度总结」的心理包袱，在 FLO.W 侧边栏的速记面板里，可以随时敲下一行字，或者用语音输入法随口说两句，记录下刚刚发生的事实、突发的灵感、或是一个悬而未决的疑问，不强求提炼，不浪费脑力。

到了周末或月末，真正需要复盘反思的时候，你也不用在几十篇散落的日记里翻箱倒柜，点击速记日历顶部的「周」或「月」按钮，新建的周期笔记会立刻通过内嵌的 Base 视图，自动将这 7 天的日笔记或这 4 周的周笔记自动、整齐地索引成一张表格摆在眼前。

然后用固定的四个预设问题，将千头万绪的随机复盘变成相对固定的填空题，在这个简单的回顾框架下，你只需要回答：

• 这一阶段推进了什么？
• 什么没有达到预期？
• 有什么可以复用的方法？
• 后续重心该往哪里倾斜？

复盘时如果有冒出新的想法，还可以直接通过侧边栏的按钮面板快速落地，点击新建任务、项目或笔记按钮，在弹出的面板里顺手勾选「关联到当前页」，系统就会自动为你完成双向关联。

发现的问题可以当场转成具体待办，提炼的心得也能顺手沉淀为 Exp 或 How 笔记，想到什么就当场记录并关联，复盘写完，下一阶段要推进的事情也就顺手铺垫好了。

人机共驾

正如本文开头所说，AI 时代已经没有任何必要继续囤积知识。

但目前市面上许多「AI ＋ 知识库」的实践，往往走入了另一种极端，全盘抛弃基本的分类体系，把所有文件塞进一个大杂烩库里，然后祈愿 RAG 和大模型能正确猜出潜在关系。

指望 AI 替你完成所有的阅读、整理和思考，就好像花钱雇人帮你健身，不流汗、不动脑、不实践，你的大脑得不到任何训练和沉淀，只能沉浸在 AI 为你编织的幻觉里，自然无法主动提出更好的问题。

因此在 FLO.W 的产品理念中，系统应当保留人类最基本的可读性和可操作性，同时用合理的字段架构、预设的标准化 Skill、透明的纯文本底座、以及确定的自动化流转规则，才能让越来越强大的 Agent 可以在安全、确定的边界内精准执行，并获得正确的结果。

为此，FLO.W 在系统内部预置了 10 个开箱即用的 Skill。

我把前文提到的所有分类规则、属性值域、模板语法与操作规则，全部写成标准化的执行规则。不管是通过外部的 Claude Code、Codex，还是直接在 Obsidian 内使用诸如 Claudian 或者 YOLO 等 AI 插件，都可以精准地读懂系统的运行逻辑。

自动路由将在后台实时接管，确保 Agent 产生的文件能自动归档到正确位置，不会在你的库里随意新建奇怪的文件夹，或者写错字段属性。

在这套框架之下，你可以对 FLO.W 的 AI 协作建立起一份合理的期待：

它无法替你决定人的去向，但可以在你选定的轨道上全速推进。无论是把脑海中粗糙的想法转化为清晰的行动规划，还是在纷繁复杂的日常工作中维护长期的笔记秩序，你都可以放心地让 AI 接管那些耗费心力的机械的重复劳动，然后把时间还给思考与行动。

写在最后

不管你是谁，如果你能从头到尾读到这里，那我真的对你太好奇了。

我的生活中找不到任何一个人与我有相同的志趣，更别提有相同的耐心会愿意看完如此长篇累牍的思考。

我有很多执念会暴露在我的文字里，也将一并呈现在这套模板的每一处细节中。所以本文结尾我就不打算再强调一遍这个系统究竟还有哪些特点了，相信你应该能感受得到。

欢迎通过下方链接加入飞书交流群，我非常期待能与你同行。

加入 FLO.W Obsidian 飞书交流群

相关阅读

• Obsidian 模板开发日志（一）：下定决心
• Obsidian 的三个问题｜模板开发日志（二）