企业官网建设流程全解析

阅读这件事，长期缺的不是“意志力”，而是“反馈”。

你买了一堆书，看完之后没过多久就忘了；你想写点什么，又觉得书里那些好句子散落在各个 App 里，真要找的时候反而一个都捞不出来。于是很多人把希望寄托在 Notion 上，搜了好几个阅读模板，导入之后发现密密麻麻的属性反而把自己劝退，最后那页数据库永远停在第一次打开的界面。

问题出在哪里？不是 Notion 不好用，而是大多数阅读模板在你还没有产生“数据习惯”前，就把结构做得太复杂。

这篇指南会换一种思路：先告诉你一个可持续维护的阅读追踪器需要哪几个库、字段之间是什么关系，然后按图书库、金句库、阅读打卡库、系列追踪、统计看板五条主线，把 Notion 的数据库、Relation、Rollup、Formula 等核心能力串起来。

这套方案的目标很清晰：让你每次打开页面时，不用思考“下一步填什么”，只需要花十几秒录完一本书、一条金句或一次阅读记录，剩下的统计会自动完成。

1. 阅读追踪器的本质是一套数据模型，不是一张收藏夹

很多人的阅读追踪做得不好，是因为把它做成了“图书馆”。

他们把输入重心放在“书名、作者、封面、ISBN、出版社”这些藏书属性上，却完全没有记录“这本书和我的阅读行为之间发生了什么”。结果就是：录入一本书之后，这个条目就永远不会再被打开。追踪变成了自欺欺人的清单，而不是帮助你决策的数据系统。

一个好的阅读追踪器，核心不是“书多”，而是“阅读关系多”。

我建议把这个系统拆成三层数据模型：

• 图书库：负责静态信息和阅读状态，解决“我有哪些书、读到哪了、读完没有”。
• 阅读打卡库：负责动态流水，解决“某天我读了多少页、花了多少时间”。
• 金句库：负责内容沉淀，解决“书里哪些话值得留下、以后怎么找回”。

三个库之间通过 Relation（关联）连接，再用 Rollup（汇总）把流水和金句自动汇聚回图书页。你不需要手动去更新一本书的总阅读页数、金句数量或最近阅读日期，因为 Notion 会替你算。

简单来说，图书库是事实表，阅读打卡库是行为表，金句库是内容表。这三者一旦打通，统计只是副产品。

2. 三张表的选择：什么时候用 Notion，而不是表格工具或读书软件

开始搭建之前，先做一次方案对比。因为阅读追踪这个需求，本身有多种解决方案，盲目上手 Notion 并不是唯一正确选项。

我推荐 Notion，是因为阅读追踪器天然有一个特征：它不像记账软件那样只关注“金额”，也不像书单工具那样只关注“书目”。

它需要在一个地方同时完成状态管理、过程记录、内容摘录和结果统计。如果不刻意设计数据关系，最先失控的一定是那些随手摘录的句子：它们散落在不同笔记里，没有和原书产生关联。

如果你还在犹豫，可以先想一个问题：你现在的记录习惯，每天能新增多少条数据？如果一周只能录入一本书，那么 Notion 的灵活性对你来说没有任何意义；但如果你的目标是持续记录一年，那么数据库关系和自动化带来的收益，会远超最初搭建那半小时成本。

3. 图书库：一个可持续维护的“Book Database”

这一节先做最核心的一步：搭建图书库。

3.1 第一步：新建页面和数据库

打开 Notion，先新建一个主页面，比如叫“阅读追踪器”。在这个页面内输入/database，选择Table - Inline（表格数据库），把它命名为“图书库”。

在 Notion 中，数据库的第一列默认是 Name，也就是“页面标题”。对一本书来说，书名就是最自然的标题。可以不用单独再建“书名”文本字段，避免一个数据库里存在两个容易重复的属性。

3.2 图书库字段设计

下面是一套兼顾“够用”和“可扩展”的字段方案，可以直接照着加：

这里有一个很容易被忽略的设计理念：把“作者”和“分类”设置成 Multi-select，而不是 Text。

原因很简单：Text 属性在筛选中不是不能分组，而是分组时会出现“同一个作者因标点、空格不同被切成两个组”的情况。Multi-select 能保证你输入“刘慈欣”后，后续所有书都可以直接从候选项里点选，统计时不会出现重复项。

3.3 新建一条书的录入步骤

在表格顶部点击“+ New”，程序会自动创建一个新页面。按顺序填写属性即可。

以一本书为例：

书名：你当像鸟飞往你的山 作者：塔拉·韦斯特弗 分类：传记 状态：在读 开始日期：2025-01-10 页数：390 阅读方式：纸质书

需要注意：开始日期和完成日期，应该代表你“当前这一遍阅读”的起止。不要写“首次出版时间”或“我决定开始想读的时间”。

3.4 用 Formula 自动计算阅读耗时

当图书库中已有“开始日期”“完成日期”“状态”三个字段后，可以添加一个 Formula 属性，命名为“阅读耗时（天）”。公式如下：

if(prop("状态") == "已读完", dateBetween(prop("完成日期"), prop("开始日期"), "days"), null)

这段公式的逻辑是：如果状态为“已读完”，就计算完成日期与开始日期相差的天数；否则返回空值。

这样做的价值在于：它只统计真正读完的书，避免“想读但一直没开始”的书干扰平均耗时。阅读耗时不是用来炫耀速度的数据，而是用来判断自己是否在长期阅读时出现“买了一堆大部头但从来没有完成”的信号。

3.5 图书库的最小视图配置

图书库创建完成后，默认只有一个表格视图。建议再添加两个视图：

• 一个视图叫“当下在读书”，过滤条件是 状态 是 “在读”。
• 一个视图叫“年度已读”，过滤条件是 完成日期 在 本年，并按 完成日期 排序。

这两个视图能让你每次打开电脑或手机，第一眼就看到“现在该读什么”和“今年已经读了什么”，而不是每次都要重新筛选。

4. 金句库：让摘录和页面产生真正的链接

很多人的摘录流程是：把一本书记录在一本笔记里，再单独开一个“好句摘抄”类笔记。这种做法的坏处是：你未来检索句子时，必须先想起来“这是哪本书里的”，然后一层层打开文件夹。

在 Notion 中，正确做法是单独建一个金句库，通过 Relation 与图书库关联。

4.1 金句库字段

在阅读追踪器主页中新建第二个数据库，命名为“金句库”。

这里面最关键的是“来源书籍”这个 Relation 属性。

4.2 如何创建 Relation

在金句库的属性列中，点击“New Property”，选择 Relation，然后在弹窗中选择“图书库”。系统会让金句库里的每一条记录都能链接到一本书上。

创建完成后，以一本“图书”数据库里的页面为例，你可以在书页底部输入/linked database，插入一个金句库的链接视图，然后给这个视图加上过滤条件：

来源书籍 contains 当前页面

这样打开一本书的专属页面时，页面下方会自动展示所有与该书链接的金句，不需要你手动整理。后续想为某本书补充金句时，直接在最下方的链路视图中点“New”，再选择“当前页面”作为来源即可。

“金句库”与“图书库”之所以用 Relation 而不是用 Select，核心原因是：Select 只是一个文本标签，无法在另一本书的页面上反向聚合。只有 Relation 才能让 Notion 知道这些数据之间的复合关系。

4.3 金句不是越多越好

金句库最大的使用误区是“每一句话都摘”。

值得摘录的句子通常满足至少一个条件：观点足够新，冲击了过去的认知；表达足够美，值得反复朗读；句意对行动有指导作用。

为了逼迫自己做减法，我给每条金句都设置了“为什么摘录”字段。这条文本字段并不需要写长篇大论，只要求一句话解释“当时为什么想保存”。如果一条金句过了三天后，你完全想不起来当初为什么摘它，那就说明它本来就不重要。

5. 阅读打卡库：把一页页的阅读变成自己的行为时间线

有时候我们会陷入一种状态：明明读过很多书，却说不清楚自己的阅读习惯。

要让阅读系统真正发挥作用，只靠图书库状态还不够。图书库只能回答“读完了没有”这个离散结果，回答不了“你的阅读节奏是快还是慢”“晚上读书多还是周末读书多”“一本书实际花了多少个小时”这些问题。

这个时候，就需要引入第三张表：阅读打卡库。

5.1 阅读打卡库字段设计

在阅读追踪器主页新建第三个数据库，命名为“阅读打卡”。

设计思路上，图书库存的是“书目档案”，阅读打卡库存的是“每一本书的年度流水”。你把“阅读打卡”当成一张流水表后，每一条记录不再需要反复编辑之前的内容，录入成本很低。

5.2 自动计算本次阅读页数

新增一个 Formula 字段，命名为“本次页数”，公式是：

prop("结束页") - prop("开始页") + 1

之所以要 +1，是因为如果你从第 20 页读到了第 30 页，实际读了 11 页，而不是 10 页。看似只是一个小细节，但在统计全年阅读总页数时会悄悄积累误差。

5.3 把打卡记录 Rollup 回图书库

在图书库中添加一个 Rollup 字段，选择来源是“阅读打卡”库中的“书籍”这个 Relation 属性，再选择统计值为“页数”的 Sum 聚合。

这样一本书的卡片上，就会自动出现一个数字：这本书累计被记录的阅读页数。

你可能会问：为什么不直接读这本书的“页数”字段？

因为“本次页数”是你在阅读打卡库通过公式计算出的实际页数，而“页数”字段是全书静态页数。对于一本 300 页的书，如果还没读完，Rollup 出的累计页数要小于 300；如果读完了，两个值应当大体接近。这个差别本身就是进度：你的阅读记录不再只是“已读/在读”两种状态，而是“已经投入了多少真实页数”。

5.4 每周复盘用视图

给阅读打卡库添加一个 Board View，按“日期”分组，或按“书籍”分组。

如果按“书籍”分组，你能直接看到每一本书的阅读流水分布，从而发现自己是不是读了 50 页就换书、然后再也回不来。如果你更关心日活状态，可以按“日期”分组，看看哪些真正读得下去。

6. 系列追踪：三种不同复杂度，三种不同选择

“系列”是阅读追踪里最容易被做坏的部分。很多新手会在图书库中单独建字段“系列名”，这没问题；但一旦你的系列横跨几十本书、还经常横向比较阅读进度，纯靠文本字段就不够了。

建议先判断自己属于哪一类，再决定用哪种方案。

6.1 常规方案：图书库 Select 字段 + 分组视图

如果你只是偶尔读系列，比如一年只读一两个系列，最简单的方法是在图书库中保留“系列”这个 Select 字段，并单独建立“卷号”的 Number 字段。

添加一个分组视图，将“系列”设为分组，然后按“卷号”排序。这样筛选与浏览完全不需要多余数据表，所有操作都发生在原有图书库内部。

优点：维护成本低，书目录入时无需先到“系列库”新建一个系列，再从列表中选择。

6.2 进阶方案：独立“系列”数据库与 Relation

如果你阅读系列频率很高，需要记录整个系列的相关信息，例如“系列总卷数”“系列起点”“系列背景”“当前看到第几卷”，那么这个需求已经超出一本书的字段范围，应该单独建库。

新建数据库“系列”，然后在这本书库中新增属性“所属系列”，类型选择 Relation，目标数据库是“系列”。

这样可以在系列页面中汇总“该系列共有多少本”“其中几本已经读完”“当前平均评分”等信息。

这里要注意：Relation 不是普通标签，而是把一本书和一系列卡片连接起来。数据入库时，需要先在系列数据库创建“三体系列”页面，然后回到图书库为对应书目选择“所属系列”。

我依然提醒：在数据习惯还没建立起来之前，优先选常规方案。普通读者最需要的不是一套可以管理 100 个系列的复杂系统，而是让自己坚持录入三到五本。

6.3 不要为了系列放弃阅读本身

系列追踪最容易引发一个问题：为了把《三体》系列整理得井井有条，你花了两小时配置数据库，却连第一部第一页都没翻。

所以实际操作中的建议是：先把常规方案跑通，等到开始阅读下一个大系列时，再来决定值不值升级为独立系列数据库。数据模型永远只是为了减少阻力。

7. 统计看板：用 Rollup 和过滤视图完成年度阅读统计

阅读系统做到这里，数据已经齐全了。接下来要把数据变成可读的统计和看板。

7.1 常见的统计字段

书籍库是天然的数据源。下面几种统计最常用：

• 年度阅读数量：对“完成日期”的本年书籍做计数。
• 读完图书的总页数：用图书库中的“页数”字段求和。
• 平均评分：用图书库中的“评分”字段求平均。
• 单本阅读耗时：用前面写过的 Formula 字段“阅读耗时（天）”。

在 Notion 表格底部，你可以直接点击表格下方的“Calculate”，选择 Count、Sum、Average 等聚合方式。如果想做按年统计，可以在表格视图上方添加过滤条件：

完成日期 is in 2025

如果你想一次性看到多年阅读量，那么可以按年份创建一个 Timeline 视图，或者用一个公式字段把完成年份提取出来。但这一层对普通用户而言并非必需，最朴素的过滤视图已经足够用于复盘。

7.2 搭建首页看板

整个“阅读追踪器”主页面，建议保留三个区域：

第一个区域是“当前在读”。插入图书库的一个链接视图，过滤条件为状态是“在读”。

第二个区域是“今年已完成”。插入图书库的另一个链接视图，过滤条件为完成日期在“今年”。

第三个区域是“最近摘录”。插入金句库的链接视图，并按时间倒序排列。

页面结构大致如下：

阅读追踪器 ├── 图书库 ├── 金句库 ├── 阅读打卡 └── 看板区域 ├── 当前在读（过滤视图） ├── 今年已完成（过滤视图） └── 最近摘录（过滤视图）

这种设计把“日常录入”和“数据浏览”统一到了同一个页面，不需要在多个 tab 之间跳来跳去。这也是 Notion 数据库“链接视图”与传统表格最大的区别：同一个数据源，可以通过多个视图以不同形态呈现在不同页面。

7.3 目标进度：推荐使用 Progress Bar 公式

如果你想给年度目标设计一个进度条，可以在一个独立的统计页中创建两个数字属性：“年度目标（本）”和“已读（本）”，然后用 Formula 字段显示百分比。公式可参考：

format(round(prop("已读（本）") / prop("年度目标（本）") * 100)) + "%"

这类字段建立起来非常容易，但同样容易被忘掉。更好的做法是把它放在“看板区域”最顶部，每次打开时只扫一眼就知道自己是否处于落后状态。

8. 快速录入与日常维护：如何避免数据中断

再优秀的数据库，如果录入成本过高，也会在第三周被放弃。

我的建议是先刻意降低频率：不要追求每一页都记录，而是每天只在固定时间进行一次“阅读打卡”。

固定使用路径可以是：

• 每天读完书后，打开 Notion 手机端，直接进入“阅读打卡”数据库，输入日期、书籍、开始页、结束页，总耗时不会超过 20 秒。
• 每周日在“阅读追踪器”看板页面复盘一次，补充“当前在读”的状态变化。
• 每月做一次金句整理：把微信读书等平台中标注的句子集中复制到 Notion，在“来源书籍”字段中选书。

“记录”这个动作必须短到不可能忘记，否则任何系统都活不下来。如果当前还没养成习惯，可以先只记录“打卡”这一张表，图书库字段只更新状态和完成日期，不着急把评分、阅读方式、阅读感受全部填完。

不要试图一次把过去五年读过的书全部补录，那种大扫除式的启动方式最容易让人疲劳。

实际目标是把“从今天开始”的数据持续记录三个月。三个月后，已经足够形成一定规模的年度数据。

9. 常见问题排查与解决思路

搭建过程中，最常见的问题几乎都集中在 Relation、Rollup、Formula 这三个环节：

其中“Formula 一直报错”是最常见，也是最容易用错全角半角的问题。Notion 的公式只支持半角字符，中文引号、中文逗号都会导致整段公式失效。

如果公式不熟悉，正确姿势是先使用简单的字段类型，比如把评分、页数、状态加好，等后续需要时再逐步添加公式字段。公式字段确实强大，但 Notion 中的大多数统计其实也可以通过基础聚合完成。

10. 阅读系统的工程化建议

当你把图书库、金句库和阅读打卡库全部搭建完后，建议进行一轮“工程化”检查，下面几条是我认为最有价值的：

第一，保持字段命名和枚举值统一。比如状态字段只用五种值：想读、在读、已读完、弃读、二刷。不要在同一天里面把“已读”和“已完成”“读完”混在一起，否则后续统计会非常困难。

第二，尽量别在文本字段里写日期。日期必须是 Date 类型，才能参与 dateBetween、过滤和日历视图。写在文本字段里的日期是死数据，无法被计算。

第三，金句库不要做成“收藏夹”。收藏夹的本质是把内容扔进去，然后不再打开。金句库应该设定一个“回看周期”，每年至少翻阅一次。

第四，把阅读过程中产生的行动项写入独立的任务清单。阅读一本书后，如果想实践书中的方法，不要把它塞进阅读打卡的备注里，建议在任务管理系统中单独生成任务。负责产出行动的是任务系统，不是阅读数据库。

第五，定期导出备份。Notion 不是本地文件系统，数据库结构再完善，仍然建议每隔一段时间通过页面右上角的“···”菜单导出备份，或者同步到云端，避免账号异常导致数据丢失。

第六，最小权限原则。如果这套系统要用于团队或家庭共享，不要给所有人“编辑整个空间”的权限，应该只共享某个数据源的特定视图权限。这种权限设计能够避免你不希望被修改的字段被误改。

这些原则的核心，不是把系统做得越发庞大，而是确保持续维护的成本低于复利收益。数据库设计只有持续被使用，才不会沦为漂亮的空模板。

11. 从这一篇开始，如何把方案真正落地

如果你面对这篇比较长的指南，不知道从哪里下手，可以直接按下面三步走：

第一步，先建“图书库”和一个“阅读打卡”数据库，录入最近在读的一本书，并尝试加一条阅读记录。

第二步，在金句库中摘录一句今天读到的文字，用 Relation 选中这本书的页面。

第三步，回到“图书库”页面，添加“当前在读”视图，把整台系统调整成日常入口，尝试坚持更新一周。

这三步一旦完成，你已经建出了一个可以统计页数、记录阅读时长、跟踪系列、沉淀金句、展示年度目标的最小闭环。后续再根据自己习惯的增加视图、添加公式、设置年度目标，是在这个闭环上生长，而不是重新推翻。

真正值得关注的不是“哪本书加入了系统”，而是“每一本书有没有在这个系统里留下新的数据”。当你坚持看到图表里季度阅读量的变化曲线，或者是年度总结时被不同时期的金句淹没，这套让数据自己生长的阅读数据库，才算真正完成了使命。