用Notion搭建阅读追踪器：数据库设计、关联公式与模板详解

最近在整理自己的读书笔记时试着用 Notion 搭了一套「阅读追踪器」。从最初只有一个表格逐步加上了阅读统计、系列追踪、金句摘录和阅读看板后面干脆把方法论复用到法律卷宗归类上意外发现这套模板迁移性很强。网上关于 Notion 的教程不少但多半是界面功能介绍能直接照着搭完整个阅读系统的并不多。所以这篇文章我会从零开始把数据库设计、字段公式、关系关联、看板视图和模板页写到具体步骤你按顺序操作就能搭建属于自己的阅读追踪器。文章适合三类读者刚接触 Notion、想在读书这件事上建立习惯的笔记新手已经在用 Notion但觉得数据库和公式门槛有点高的进阶用户以及想了解如何把「书籍管理」方法迁移到案例库、资料库、库存清单等场景的模板设计爱好者。读完你至少能掌握阅读数据库的字段设计方法、系列书籍的关联思路、金句摘录与图书的双向联动、统计公式的写法以及一个可以直接复制使用的模板结构。1. 为什么用 Notion 做阅读追踪器1.1 阅读记录的真实痛点很多人读书时都经历过几个尴尬阶段读过的书很多但问起某本书讲了什么半天说不出来。想找一句之前划过的金句翻遍纸质书找不到电子书同步又麻烦。读系列书时不知道上一本停在哪里下一本何时读。立了「一年读 50 本」的 flag但没有中间过程记录年底根本无据可查。用 Excel 能记录书名、作者、状态但缺少数据库关系和可视化看板用豆瓣能标记已读和写短评但金句和阅读过程无法精细管理。Notion 的优势在于它把数据库、编辑器、看板、公式集成在一个工具中记录一本书的同时就可以内嵌阅读笔记、关联系列书目并通过公式自动算阅读天数、阅读速度最后在看板上直观展示年度统计。这套体系不依赖纸质本也不强制绑定某个电子书生态所有书都能统一归档。1.2 阅读追踪器的功能边界在动手之前先明确这套系统要解决哪几个问题也就是功能边界功能模块要解决的问题Notion 的支撑能力书库管理管理书名、作者、分类、状态、评分Database 的属性字段阅读过程记录开始日期、读完日期、阅读天数Date Formula系列追踪同系列多本书的进度掌握Relation Rollup金句摘录摘录原文、批注感想、回链到书籍Database Relation统计看板年度统计、状态分布、类型分布视图 图表嵌入检索与复盘快速找到某本书和当时的想法属性筛选 全文检索很多教程喜欢把阅读追踪器做得非常庞大比如加入 Annotation 高亮同步、Goodreads 自动导入、碎片时间记录等。这些功能并不是每个人都需要前期做得过重反而容易放弃。所以本文的方案会遵循「轻量可运行」原则先保证建库、记录、统计三个核心链路跑通再按需扩展。1.3 为什么选用 Database Relation 而不是单独笔记页有用户会问我直接用纯文本页面写读书笔记不行吗纯文本页面对单本书的记录完全没问题但放在多本书的语境下会失效。当你需要回答「今年共读了多少本技术书」时纯文本页面无法自动汇总当你需要统计「《哈利波特》系列还剩几本没读」时纯文本只能靠肉眼对比。而 Notion Database 的行本质上是结构化记录配合视图和公式这类统计可以由工具自动完成。数据库之间的 Relation 则是为了连接两个不同维度的信息例如「书籍库」和「金句库」让一条金句既属于某个页面又可以归纳到某一本书下。这样记录一次后续查询处处可用是这套方案的核心逻辑。2. 环境准备与整体方案设计2.1 账号与运行环境Notion 不需要额外安装客户端才能使用直接在浏览器打开官网登录网页版即可。建议优先使用 Chrome 或 Edge 浏览器网络正常时体验更稳定。桌面端和移动端可以安装官方客户端用于离线缓存和随时记录但网页版足以完成本文全部操作。需要特别说明的是Notion 的界面语言、数据库公式中的字段引用方式会随版本变化而略有差异。本文中的属性名称统一使用英文例如Name、Status、Category这样在公式中最稳定。如果你使用的是中文界面可以在建表时就把属性名称设为英文避免在公式里因语言差异报错。按 Notion 一贯的更新节奏个别菜单名称、按钮位置可能与你当前版本略有出入但整体设计思路不受影响。2.2 数据库结构设计本文方案包含 4 个核心数据库外加 1 个模板页。先看整体结构数据库作用关键属性Books书库记录图书基本信息和阅读状态Name、Status、Category、Dates、Pages、Rating、SeriesSeries系列管理系列书目Name、Books关联、TotalRollupQuotes金句摘录原文与想法Name、Book关联、Page、Tags、TypeAuthors作者管理作者信息Name、Books关联、Country如果作者信息暂时不想独立管理也可以简化为 Books 库里的Author文本字段。不过作者单独建库的好处是后续可以做「读了这个作者多少本书」「哪些作者可以推荐同类书籍」的统计虽然前期会增加一点关联成本。2.3 两种视图思路Notion Database 本身支持表格视图、看板视图、日历视图、画廊视图、列表视图。阅读追踪器的多视图设计不是炫技而是对应不同使用场景视图使用场景适用状态Table快速录入、整体浏览所有书籍Board by Status查看当前读到哪一步想读 / 在读 / 已读Calendar按日期检查阅读节奏按开始日期或读完日期Gallery带封面的书本墙效果已读 / 想读的书单Board by Series系列书籍的进度总览按系列分组整个数据库视图非常多实际维护时你不需要同时打开所有视图。日常会在 Table 视图录入数据在 Board 视图跟进阅读状态最后在看板页查看年度统计。这也是 Notion 常见的「一次录入、多视图消费」的工作流。3. 核心 Book 数据库字段设计3.1 字段清单Books 数据库是整套系统的主表。先把这个表的设计定下来后面的金句和系列关联才会有依托。新建 Database 时Table 视图下字段如下属性名类型说明NameTitle书名主键AuthorRelation关联至 Authors 数据库StatusSelect想读 / 在读 / 已读 / 搁置CategorySelect小说 / 技术 / 历史 / 社科 / 传记等SeriesRelation关联至 Series 数据库DatesDate含 Start Date 和 End DatePagesNumber总页数Pages ReadNumber已读页数阅读中维护FormatSelect纸质书 / Kindle / 微信读书 / 有声书RatingRating1-5 星评分Rating CommentText一句话评价DifficultySelect入门 / 进阶 / 深入Reading DaysFormula自动计算阅读天数Reading SpeedFormula自动计算每日阅读页数ProgressFormula已读/总页数百分比初看不觉得这些字段特别但真正用起来时Progress公式能直接显示阅读进度条Reading Days能告诉你一本书从开始到读完跨度了多久这些都不需要手动维护。3.2 关键字段的作用详解Status建议使用 Select 而不是 Checkbox。Checkbox 只能表达读完 / 未读完而 Select 可以容纳「在读」「搁置」「想读」等中间状态。后续搭配 Board 视图时会非常有用。Dates必须勾选 End Date。你只需要在 Date 属性上选择一段时间范围Notion 就会记录开始和结束两个日期公式可以用dateBetween()算出阅读天数。Category我建议控制为单选 Select 而不是多选。如果在分类上使用多选按分类统计时会出现一种书在多个分类里的重复计数对年度复盘不够友好。保持一个主分类即可例如技术书里的数据库类就直接分类为「技术」不需要新建「数据库」分类。Pages和Pages Read都按实际页数填。Kindle 和微信读书上的页码通常与纸书不完全一致这没有关系记录的目的是比较「同一本书的阅读速度」不需要追求跨平台精确。3.3 演示数据准备为了后续解释公式和视图时不会空对空建议先创建几条演示数据。以下 3 本书可以手动录入 Book 库NameAuthorStatusCategoryDatesPagesFormat亲密关系罗兰·米勒想读心理学-412纸质书代码整洁之道罗伯特·C·马丁在读技术2025-01-10 ~ 2025-02-01416微信读书三体刘慈欣已读科幻2025-01-01 ~ 2025-01-15302Kindle这里要注意如果你已经在 Books 库中准备用关联字段关联作者演示数据中的作者也需要同步创建到 Authors 库。4. 关联与系列管理4.1 Relation 的底层理解Relation关系是 Notion 数据库和普通表格的最大区别。它就像数据库外键把两条记录连接起来。例如「三体」这本书归属于系列「三体系列」而「三体系列」这一条记录里又可以看到它包含的所有书籍。创建 Relation 的操作方法在 Books 库中添加属性选择 Relation。目标数据库选择 Series。此时 Series 数据库会自动反向生成一个 Relation 属性指向 Books 库。Relation 属性在实际页面中会以 Chip小圆标签展示点进去可以搜索已有记录也可以直接在当前页面快速新建系列。同一个系列如果先创建好为多本书添加关联时可以复用后续在系列页面就能看到全套书目。4.2 Series 数据库设计Series 数据库不需要太多主动录入的字段多数信息可以通过 Rollup 从 Books 库汇总。属性名类型说明NameTitle系列名称BooksRelation自动来自 Books也可以反向选择Total BooksRollup统计该系列下书籍数量CompletedRollup统计该系列下状态为「已读」的书籍数量Average RatingRollup计算该系列的平均评分Rollup 配置方法属性类型选择 Rollup。Relation 选择Books。Property 选择Status。聚合函数选择Count。如果要统计“已读数量”单个 Rollup 做不到条件计数只能统计总数。这时需要再配合一个 Formula 或额外维护一个进度字段。这里可以简化处理在 Series 库中只统计总数已读数量通过看板视图按 Status 分组查看。4.3 Series 数据库的 Rollup 配置细节更实用的 Series 字段是一个计算阅读进度的 Rollup Formula 组合。在 Series 数据库添加 Rollup 属性属性名RelationProperty聚合函数BooksBooksNameCountRead BooksBooksStatusCount 只对已读但 Rollup 不能直接对 Select 值计数。正确做法是在 Books 库中添加一个Is Read公式if(Status 已读Read, 1, 0)也就是当状态等于已读时输出 1否则输出 0。然后 Series 库用 Rollup 聚合Is Read的 Sum就能得到已读数量。这里步骤稍多看起来有点绕但本质是用公式把 Select 变成数字再用 Rollup 对数字求和。你照着操作一次就会记住这个模式它也是 Notion 中做跨库统计最常见的技巧。4.4 同一系列的书放入一个页面还是多个页面对于多卷本《平凡的世界》《三体》或系列侦探小说核心问题是有几个物理页面。如果选择为每本卷册单独创建一条 Book 记录优点是状态、日期、页数、金句可以独立跟踪。缺点是需要多建记录关联稍多。如果只建一个 Book 页内嵌多本卷册的信息优点是页面简洁适合记录总集。缺点是Pages、Status、Dates无法按分册统计系列进度无法自动化。建议采用方案一每本书独立成一条 Book。系列页只作为聚合容器真正的统计粒度保持在 Book 层。这样「三体黑暗森林」可以被标记为在读而「三体系列」页面通过 Rollup 自动知道这个系列目前有两本已读、一本在读、一本想读。5. 金句摘录数据库设计5.1 为什么要单独建金句库金句本身不是书籍的附属属性而是一个独立的记录单元。如果只在 Book 页内写金句很难跨书检索 2025 年读过的所有打动我的句子也不可能按主题维度回顾。例如把「自由」相关的句子都找出来时独立金句库 多选 Tags 是更合适的方案。金句库Quotes的核心字段属性名类型说明NameTitle金句原文首次输入建议完整摘录BookRelation反向关联 Books 库PageNumber原文所在页码电子书可用章节名TagsMulti-select主题标签如成长、效率、写作TypeSelect原文摘录 / 个人批注 / 行动清单My ThoughtsText阅读时的想法、共鸣点、应用场景Date AddedDate/Time默认生成日期5.2 快速摘录流程为了保证阅读时不被工具流程打断建议设计一个快速录入流程阅读中遇到想摘录的句子立即打开 Quotes 数据库甚至可以做成 Dash 小部件按钮。在 Name 字段粘贴原文。Book 字段选择当前正在读的书。如果暂时没时间写想法只填前 3 步即可My Thoughts 留空。一周内找一个时间统一做一次「回看」补充页码、Tags 和个人感想。这个流程的关键理念是「摘录时不思考复盘时再整理」。如果你在摘录时就要求感想完整、标签准确、页码精确阅读过程就会被频繁打断很多用户就是因为流程太繁琐而弃用模板。先保证核心信息原文 来源完整其他字段后续在表格视图里像维护 Excel 一样批量补齐即可。5.3 Quotes 与 Books 双向联动在 Quotes 库中创建Book关系属性关联 Books 库。保存后Books 库对应记录会自动多一个Quotes反向关联属性。点击 Books 库中的书名展开页面下方会显示所有关联 Quotes。使用双向联动后一本书记录的金句会自动聚合到该书的页面中不需要手动维护。打开 Books 库点击任一本书在页面底部的关联数据库区块中就能看到所有金句并可直接内嵌一个筛选过的 Quote 视图。一个小技巧Books 库内嵌的关联数据库视图可以按Date Added倒序排列方便快速看到最近摘录的内容。6. 统计公式与阅读视图6.1 阅读天数公式在 Books 库添加 Formula 属性Reading Days这里根据是否已读来计算。公式如下if(empty(prop(Dates)), , dateBetween(prop(Dates).end, prop(Dates).start, days) 1)解释一下公式逻辑empty(prop(Dates))如果日期为空则返回空字符串防止阅读中书籍没有结束日期导致计算异常。dateBetween(end, start, days)Notion 内置函数返回两个日期的间隔天数。 1因为「1 月 1 日开始1 月 1 日读完」也应该算 1 天所以需要加 1。如果一本书目前还没读完Dates 只有开始日期没有结束日期公式会返回空。你可以根据个人习惯改成对未读完书籍返回今天与开始日期的差值但那样会让所有在读图书都显示一个不断变大的数字容易产生焦虑。本文更倾向于只在闭卷后计算已读图书的跨期。注意Notion 公式中字段名称必须与你数据库实际名称完全一致如果你的字段是中文将prop(Dates)改成prop(日期)即可。6.2 阅读速度公式在 Book 库添加Reading Speed属性表示每天读了大约多少页。这会让你对一本书的实际阅读难度有直观认识你会发现《三体》每天读 30 页和《代码整洁之道》每天读 20 页背后的难度差异。if(empty(prop(Reading Days)), , round(prop(Pages) / prop(Reading Days) * 10) / 10)如果要得到整数页数也可以写成round(prop(Pages) / prop(Reading Days))。这个公式依赖Reading Days公式的结果。如果公式字段返回空字符串外部计算不可用速度字段也返回空。6.3 阅读进度公式与表情进度条Progress公式根据是否有读完日期来判断进度。if(empty(prop(Dates).end), , prop(Pages Read) / prop(Pages))如果希望以百分比显示可以进一步嵌套if(empty(prop(Dates).end), , format(round(prop(Pages Read) / prop(Pages) * 100)) %)上面的公式把数值格式化成百分比文本。但要注意这个字段一旦格式化成文本就不能用于后续聚合统计。更推荐保留数值通过视图的 Show 选项自动展示必要时再加一个Progress Text字段用于文本显示。Needless to say如果你想展示进度条效果可以这样if(prop(Status) Read, ✅, if(prop(Status) Reading, ⏳, ))每个属性名的值需要与你 Select 选项一致。如果你的状态选项是英文公式内容相应修改。6.4 统计看板与嵌入图表年度统计最简单的方式不是写一堆公式而是利用 Notion 的 Board 和 List 视图对 Book 库进行分组。新建一个页面「阅读统计」然后嵌入两个数据库视图状态看板以Status为分组字段查看所有书的状态分布。年度统计以Dates为筛选条件筛选今年内结束日期属于本年度使用 List 视图展示并开启Reading Days和Rating字段。如果你把 Book 库嵌入一个 Dashboard 页面就能一眼看到当前书架规模和阅读状态。由于数据库视图是实时更新的公式不需要手动刷新。Notion 官方也支持在页面中嵌入图表工具如 Chartbase 或 Simple Graph 实现饼图柱状图但多数依赖第三方服务我不会作为必选项推荐先用 Board/Linked database 自带的概要汇总代替。6.5 年度阅读目标年度阅读目标可以通过 Notion Formula 设置一条 Target 记录也可以简单地在 Dashboard 页面拖一个 Counter 数字。最常见的做法是给 Books 库加一个YearFormulaif(empty(prop(Dates).end), , year(prop(Dates).end))然后筛选今年 year(now()) 的记录并在总览数据库底部查看Rollup汇总或记录总数。这个方法比第三方统计工具简单且在 Notion 内部稳定可靠。7. 导航页与模板页面拆解7.1 主页面层级设计很多 Notion 页面越用越乱核心原因是顶层结构没有设计好。建议的最终页面结构如下 阅读中心 ├── 1. 阅读总览 Dashboard ├── 2. 书库 Books ├── 3. 系列 Series ├── 4. 金句 Quotes ├── 5. 作者 Authors ├── 6. 阅读方法论 / 模板第一个块用/create-linked-database创建已有关联数据库视图不要在子页面间反复跳转。7.2 单本阅读页模板当你打开一本书的记录页时它默认只是数据库的一行可以编辑成完整笔记。这个模板会应用到每一本新建的书上让你以后打开书页都自动拥有统一结构。建议模板添加下面几个区块书籍信息按钮同步展示属性表格最靠上部分可设置 2 列排版。一句话推荐语。思维导图 / 目录梳理。阅读目标。印象最深的三件事。摘抄内容通过/linked-view-of-database关联 Quotes 库并筛选 Book 当前记录。这样每本书页面既是一个数据记录也是一个独立的读书笔记以后想在主页或移动端翻看都方便。7.3 金句模板金句库的模板可以设置成书名自动关联字段已经设置了不必重复填。原文粘贴区。“当时为什么想摘它” 区。“我想尝试的行动” 区。这个模板每次在 Quotes 库点击 New 时都会加载可以大量减少复盘成本。8. 扩展实战从阅读追踪器到律所案例库8.1 场景迁移思路Notion 方法论的终极价值不在阅读本身而在于把「实体-属性-关系-状态-统计」这套数据思维迁移到其它管理场景。热搜关键词「律所案例库 notion」恰好暴露了一个典型需求很多法律从业者也想用 Notion 做案例库、判例检索、卷宗跟踪。因此这里把阅读追踪器的设计映射成一个律所案例库你会看到字段和流程几乎一脉相承。8.2 阅读追踪器到案例库的字段映射阅读追踪器案例库对应BooksCases案例库Status想读/在读/已读Stage待排查/分析中/已结案/归档Category小说/技术...Practice Area民商事/刑事/知产...Dates开始读/读完Filing Date / Judgment DatePages总页数Case Pages / Evidence CountQuotes金句Key Facts关键事实/ Citation引用法条Series系列书Client Matters客户关联案号8.3 案例库中的金句变体在阅读追踪器里金句库保存原文和感想在法律案例库中对应的就是「摘录判决书原文」和「律师个人批注」。由于判决书文本较长建议每一条 Quote 记录只保存一个争议焦点或一段关键说理用 Type 区分「裁判要旨」「法条依据」「办案灵感」「客户信息」。这样之后做类案检索时通过 Multi-select Tags 就能快速找齐相关说理。8.4 案例库统计看板案例库的统计指标比阅读库多一个「时效性」维度。适合用日历视图显示关键日期例如开庭时间、举证期限、上诉期。阅读库的Reading Days公式可以类比为「案件办理时长」在 Cases 库中用dateBetween计算从立案到结案的时间跨度。各类诉讼周期分析本质和统计阅读时长是同一个公式逻辑。8.5 这个方法还可以迁移到哪里同样的模式可以继续迁移到影音管理库电影 导演 影评 观看状态游戏进度库平台 通关状态 全成就记录项目题库题目 科目 正确率统计客户管理库客户 订单 跟进记录装备测评库设备 评价 使用时长只要抽离出核心三层结构——主实体库、关联子库、统计看板——任何领域都能用 Notion 快速搭建。这也是本文在阅读追踪器之外额外展开的原因你学的不是一个模板而是一种数据结构设计的套路。9. 常见问题与排查9.1 常见问题速查表问题现象常见原因解决思路公式报错“无法识别属性名”公式中的属性名与数据库实际名称不一致检查是否多空格、语言是否一致尽量使用英文属性名Rollup 无法统计「已读」数量Select 字段不能被 Rollup 直接条件计数先在主库添加公式转数值再被 Rollup 求和日期范围无法显示结束日期没有勾选 End Date 开关编辑 Date 属性点击弹出框右侧 End date 开关Notion 页面卡顿一个页面嵌入了太多大数据量视图开启视图的「仅查看 Load more」或者筛选必要字段关联字段显示为文字而不是标签该关系可能断开了目标数据库检查关联配置确认连接的是哪一个数据库公式日期少算了一天dateBetween 只算间隔天数在公式末尾 1金句页里找不到当前书名Book 关联未连接或筛选条件错误检查关联字段目标数据库并筛选当前记录9.2 公式检查三步法遇到公式报错时不要急着删除字段按顺序排查看字段名选中属性检查复制到公式里的名字是否一致注意大小写、空格、引号。看函数括号Notion Formula 通常只允许一个表达式确认每个函数都闭合。看返回类型文本公式不能直接参与数学运算需要先用format或转数值。9.3 性能优化建议当书库超过 500 本、金句超过 1000 条时部分 Notion 页面可能开始变慢。建议全部数据库放在独立页面主 Dashboard 只放 Linked Database 的裁剪视图。尽量筛选近一年数据或固定视图范围。不常用的视图可以关闭减少加载压力。使用/sync-block同步块会长期占用加载资源建议少用。10. 最佳实践与模板维护建议10.1 从最小闭环开始我接触过很多 Notion 模板前期一次性加了十几个字段、七八个视图结果真正坚持记录的人并不多。反而那些从最小闭环开始——先有一个 Book 库、一个 Status、一个 Quotes 库——的人更容易形成长期记录习惯。建议本周先按这 4 个数据库搭好跑通录入一本新书 摘录三条金句 查看一次统计。一周后再决定要不要增加作者库、阅读频率、年度目标等高级字段。10.2 保持属性名的可维护性在 Notion 中属性名会被公式、关联、Rollup 反复引用。一旦属性改名所有引用它的公式可能都会报错。所以设计属性名时最好遵守这些原则使用统一的英文命名或在最开始时确定中英文使用方案不要混用。避免在属性名中包含日期或版本号例如Status 2025这会让你每年都要复制一套。Select 选项名称尽量短且唯一避免出现「已读」和「已读(完)」这种视觉重复。如果确实需要中英文界面切换公式中属性名需要跟着界面语言变这个在 Notion 官方文档中有说明。为了减少不必要的麻烦非中文界面用户可以优先用英文名。10.3 定期复查与归档阅读追踪器能不能坚持直接影响这套模板的长期价值。建议设定每周一次的维护节奏每周日把本周读完的书状态改成 Read。把阅读过程中摘录的 Quotes 补上标签和想法。清理明显录入错误的书籍信息。每个月还可以抽出 10 分钟做一次复盘这个月状态分布如何哪本书花的时间最多哪本书评分最高把答案记录在 Dashboard 下方的月度复盘页面里。这些复盘数据之后会成为你调整阅读方向的依据。10.4 模板备份Notion 没有本地备份的官方一键导出整个 workspace 功能但仍然支持对页面做 Markdown / HTML / CSV 导出。建议每季度将 Books 和 Quotes 数据库定期导出防止误删或账号异常造成数据丢失。如果你创建了一套比较满意的模板也可以在 Notion 中把它做成 Template Button下次开启新领域时一键复用不用重新配置数据库结构。10.5 从阅读追踪器到知识管理阅读追踪器本质是个人知识管理系统的最小切片。完成这套模板后你其实已经掌握了关系型数据库的建模思维也理解了如何在笔记工具中沉淀可检索的知识单元。下一步可以向这三个方向延伸把 Quotes 库中的优质想法提炼成 Permanent Notes永久笔记。通过 Relation 关联书籍和主题建立自己的阅读知识图谱。结合 Notion AI 或自动同步功能把微信读书笔记、Kindle 高亮导入到统一库内。工具会更新界面会变化但「用结构化数据库管理碎片信息」的方法不随版本失效。把自己读过的每一本书、记过的每一条摘录沉淀为可复用、可检索、可统计的第二大脑资源这件事本身就值得长期投入。搭建第一版时不必追求完美哪怕只建了 Books 和 Quotes 两个库先把 3 本书录进去你就已经走在 90% 只想不做的人前面了。后续根据真实记录习惯逐步调整字段和视图它会慢慢长成真正适合你的阅读追踪器。