* 开始阅读前，你也可以先观看这个视频来了解 Notion：

Notion - 你必须尝试的工具 - 21st Century Data Recording

引入

开始的原点是去年 10 月我在 Notion 中建立的「构建 Notion 空间」事务：

首先，必须承认的是，最初被 Notion 吸引是在于它的 UI 风格。但在深入了解后，它的内在设计理念更具价值。

关于 Notion 的基本概念以及使用，少数派已经有很多作者写过，本文就不从零开始一一介绍了。更多会转向专注于分享我的思考探索过程，以及个人工作中搭配 OKR 方法实践的经验。

对于 Notion 的特性，核心就是官方展示的这几点：

• Notes, Docs
• Knowledge Base
• Tasks, Projects
• Databases

由于年初开启了远程工作模式，希望我在数据之上的 Notion 实践经验可以为你的「规划」带来启发。

碰壁：难以维护的美观

第一阶段，初版 Notion 空间，我划分了工作、写作、学习、电影、展览、笔记等 N 多个 Pages，利用 Notion 的自带模板，并搜寻各种模板。在每个区域内精心维护了不同的样式，一切看似非常美好，非常赏心悦目。但设计了几天就支撑不住了，整个空间想「美观化」太难了，并且暴露出很多问题：

• 切换频繁：遇到事情频繁地在不同 Page 之间进行切换
• 陷入样式：追求样式投入了更多精力
• 追求细节：每个区域过分追求细节，定义很多数据库

事实上，碰壁之后我才觉得，这种「划分作法」与传统的「笔记结构」没有本质上的区别，只不过多了一些页面嵌套关系以及丰富的 Block 形式。

类比产品需求，我大概属于一上来就考虑实现，陷入细节，是不可取的。回归到目标，目标肯定是「通过 Notion 构建空间来提升效率」，但这样的开端却将整个事情复杂化了。

甚至，为了追求每个页面的样式付出了更多的时间，牵扯了更多的精力。这个现状并不理想。

第一版碰壁后，继而转向开始挖掘自身的需求。

进化：场景化 + 数据化

第二阶段，个人的使用愿景进化为：

• 追求简化的 all-in-one 
• 尽量避免重复第一阶段的问题

我期望 Notion 能替代我日常在使用的 Things3， 能够对工作任务进行管理；同时，可以替代印象笔记（已经使用了多年的印象笔记）作为笔记管理，并且，又能覆盖日常记录的需求，成为真正的 all-in-one 空间。

当然，所谓的 all-in-one 不只是在一个工具里有全面的场景覆盖，还需要通过更加简化的方式去达成这种覆盖。

毕竟，效率与空间复杂度很难成正相关性。

接下来，针对我的个人使用场景进行梳理。

使用场景

• 场景1（中高频）：任务（事务）
• 每周时间大多是在处理事情。无论是工作，还是生活，处理的事情包括临时以及近期内的。因此是中高频的。期望对工作、生活中的一切需求、问题、个人 Project 等转化为任务（或称为事务更具有普适性）进行管理。
• 即：所有的任务都是一条事务数据。
• 同时，目标先行，所有任务（事务）理论上都应该有一个目标，否则不知道为了什么做，只是盲目去做，日常可减少在没有目标的事务上的消耗。
• 场景2（中频）：记录
• 对生活中值得记录的的打卡进行记录，可包含饮食、展览、现场、电影等。
• 场景3（中低频）：收集
• 对不同地方看到的碎片化内容信息进行收集、存储（类似于印象笔记的剪藏），同时也可以收集个人的碎片想法。
• 场景4（低频）：聚合
• 关联上述不同场景，是个人的全方位画像，另外还包括旅行总结、个人简历等多方面。个人页面基本可以作为一个必要时刻可以对外展示的窗口。
• 个人沉淀需要较长的时间进行排版布置，需要花时间进行整理，其实不希望花太长时间在这个场景，因此是低频的。（事实也证明这块确实还没功夫维护起来..）

竞品参考

很显然，最专注的三个场景就是事务、记录、收集。在场景的基础上之上，我又参考了一些成熟的 Templates：

灵感来源：All-in-one Database Templates、OmniFocus in Notion、Things

Aio 通过搭建一个自定义的 all-in-one 的数据库，在不同视图内建立不同筛选逻辑，用一个数据库管理，灵活建立收集、预测、今日、标签等应用场景。

那么原先我要维护不同的页面，不同的数据库，参考上述方式，如果能按自用场景进行一定整合，便可降低维护成本。

由于自身情况导致不可能一直投入大量的精力在信息及数据化管理上，也不可能覆盖大而全，从优先级的角度，我主要聚焦在三大核心需求上，覆盖我的大多数使用场景：

• 事务管理需求（关联目标管理）
• 事务要从属于目标（对平日的临时型事务进行单独标记）
• 目标大致分为两类
• 工作目标
• 生活目标

• 日常记录需求
• 单纯记录，满足基本信息记录即可
• 碎片收集需求
• 来自外部碎片化信息以及自身碎片化思考

接下来要做的是：定义不同需求所需字段支持，抽象出数据实体进行建模，投入应用。

基本上通过建立数据库实体，以及参考 Aio 的方式，可以达到我的预期。

数据建模

在此灵感基础之上，结合自己的使用场景，开始数据建模。抽象出四大实体：

• 目标
• 事务
• 记录
• 碎片

每个数据字段的设计如上图所示。在目标和事务之间有一个简单的关联关系。

可以注意到，在目标和事务之间有一个简单的 Relation 关联关系。这个操作搭配 Rollup 可以让你拥有一种其它笔记或任务类软体难以获得的联动感。

至此，构建了一个基本的 Notion 框架。经过 120 多天的实践，在这套基础的框架之上 Notion 可以说能够将我的工作内容、部分生活进行完整的数字化呈现。

数据视图

通过 Properties(属性) + Filter(筛选) + Sort(排序) 的方式，在每个数据库中创建不同子场景的 View 视图可以说让我直达第二阶段所设想的愿景。

这个创建过程颇有一种书写 SQL 的感觉，基本实现了傻瓜式的数据操作。即：

• 通过 Properties 进行 SELECT
• 通过 Filter 进行 WHERE
• 通过 Sort 进行 ORDER BY

可以转化为这样一条通用的 SQL 语句：

SELECT 属性1,属性2,.. FROM 数据实体 WHERE Column = '维度1' ORDER BY 维度2,维度3,..

基本上所有的视图我都选择了 Table 视图模式，这样可以让我更专注于数据，而非样式。

当想在事务实体中创建一个已完成的 View 视图时，Properties 基本全选，Filter 是否完成为 True，不加 Sort ：

等价于这样一条 SQL 语句：

SELECT * FROM 事务 WHERE 是否完成 is true

将这个视图命名为 # 已完成，即得到这样一个视图：

实践：如何使用 Notion 管理需求

这里主要围绕工作上的需求内容，由于笔者负责公司的基础平台相关工作，因此在上年度 Q4 创建了 3 个主要工作目标。在图中可以看到，整体框架是利用 OKR (Objectives and Key Results) 的思想来搭建：

OKR 框架示意

Objective: Create an Awesome Customer Experience

Key Results:

• Improve Net Promoter Score from X to Y
• Increase Repurchase Rate from X to Y
• Maintain Customer Acquisition cost under Y

（这里演示一个简单的 OKR 的例子，供大家参考）

目标部分

• 创建工作目标（O）
• 如提升基础平台的转化能力
• 创建关键结果区域（KRs）
• 如图中红框第一部分所示

• 创建关键任务、相关任务区域（如上图中第二、三部分所示），需要将 KRs 拆解为一个个具体的行动和任务
• 其中，相关任务区域通过 Create Linked Database 选择「事务」数据库建立
• 同时，在事务中创建该目标的 Filter（如下图红框中所示，筛选当前目标 - 提升基础平台的转化能力），即可在目标中直观的看到，为达成该目标正在做的具体事务，同时可以直接点击进入相应的事务中

在目标部分中，我使用的 3 个核心数据项：

• 关联任务（Relation）
• 目标完成度（Rollup）
• 剩余天数（Formula）

这是关键部分，其中：

• 关联任务
• 指与目标相关的所有具体事务
• 通过 Relation 关联到「事务」数据库

• 当你尝试通过 OKR 方法论 + 数据关联操作去应用的时候，你会发现这一切变得系统化了（因为这样的设计具备理论支撑以及技术支持）。通过关联任务来关联做的好处是：
• 一方面，从目标的角度，在查看目标时，可以看到正在进行的所有与该目标相关的任务。
• 另一方面，从事务的角度，在创建事务时，强迫你去思考这个事务是否是必要的，是否是高优先级，是否是契合目标的，你需要将事务关联至对应的目标中。

• 这样可以保证在创建事务时避免盲目去做，避免让那些事务仅仅成为 to do。通过关联你设定的目标，能贴合到你目标内的关键结果。否则做了许多事情，回过头也不知道是为何而做，也不知是否能达到目标
  
• 在实际操作过程中，关于该目标内关键结果的相关任务可能是动态变更的，如果多出一些需求，这时候完成度也是在浮动的
• 目标完成度
• 指目标的完成程度
• 通过 Rollup 来计算关联数据库中，「是否完成」中的 Percent Checked（已完成的百分比），即可计算该目标完成的事务占该目标下所有事务的百分比

• 剩余天数
• 指目标的剩余实现时间
• 通过设置目标的截止时间距离今日的天数，公式如下，将预测时间的截止日期与当前时间的差值转化为字符串显示
• 具体公式如下 ：

"⏱. 剩余 " + format(dateBetween(end(prop("预测")), now(), "days")) + " 天" 

以上，通过创建目标与事务的关联，实现了数据化的目标管理。

事务部分

在需求设计阶段，已经定义清楚，在我定义的所有数据库中，事务是一个基本单位。

实操过程中，事务部分主要是指针对关键任务进行分解，拆解为具体的相关任务，通过创建事务的方式，统一进行管理。

关于事务部分，最常用的是通过创建「# 分类」并通过 Table View 视图方式进行数据展示。

除此之外，还可通过「预测」或「@ 标签」或「状态」的方式来查看数据。

（这里使用你习惯的符号进行标记，做到简洁清晰即可）

过去一段时间内，我最高频使用的还是「# 需求」视图，最简洁的 Table View（表格视图），让你对所有的需求、优先级、关联的目标、状态、加速等信息一目了然。

在一个事务数据库里几乎 Cover 了我日常工作、生活 80% 的事务处理的需求。这是非常符合我对极致简化 all-in-one 的定义的。

（每天的工作内容也在此）

这里常用的小技巧：

通过「🔥加速」标记，通过 Filter 筛选加速并创建一个「# 今日加速」分类，每天通过对「🔥加速」标记进行整理，可以快速专注在每日进行的事务中。

具体创建方式如下图所示：

此外，以下查看方式你也可以借鉴：

• 通过「🗳. 收集」，单行表格视图。快速拉起空白事务，记录事务，对事务作归类
• 通过「预测」，日历视图。快速查看事务进行的时间范围，对事务的排期作管理
• 通过「@ 标签」，表格视图。快速定位到具体需求的标签种类
• 通过「状态」，表格视图。快速查看不同状态下的事务

彩蛋：如何使用 Notion 记录

关于「记录」实体，依然秉持着追求简化的 all-in-one 的思路。

目前主要分类包括：

• 咖啡
• 展览
• 现场
• 饮食
• 电影
• 种草
• ...

同样以「# 分类」的方式，创建 Table View 进行管理，维护一套数据库即可实现大多数场景的记录。以现场为例，在此整理了一部分过去一段时间看过的现场：

基本上我的所有记录都会有「评分」，因此这个字段必不可少。

此外，更加详细的图文记录可以在每条记录的 Page 中进行。

另外值得一提的是，在对其它部门作非专业性业务培训的时候，我直接使用 Notion 来分享及呈现，效果也很棒。未来也会在 Notion 上进行更多探索。

结尾

以上是我在实践过程中的思考与实践。在过去短短几个月的使用过程中，建立了一些数据。在这个数据之上有了更多的可能性，拥有了「定制化」的数据感以及「建模化」的世界观。

通过 Notion 创建空间的过程像是对自己工作生活的数据化思考，需要对个人体系进行数据建模。

由你定义你的「个人秩序」，大概就是 Notion 的价值所在。

文中提到的我正在使用的 Notion 模板分享：

• 目标模板

• 事务模板