年度征文 | 使用 Airtable 搭建科研学术知识库

编注：本文是少数派 2020 年度征文活动的入围文章。本文仅代表作者本人观点，少数派对标题和排版略作调整。

前言：今年 3 月份就要毕业了，准备把这两年半硕士生涯里为数不多的学术经验（毕竟我的主业还是工程实践，硕士除了毕业论文就没有正儿八经搞过学术🤣 ）分享出来，希望会成为留存在世上的我的读过硕士的足迹吧。

在此之前我曾经写过一篇 Airtable 如何满足我信息管理需求的文章（传送门），但是那篇文章更多是一篇概览，罗列了很多我关于 Airtable 的用法和一些思路，具体案例上都是蜻蜓点水，没有详细展开。而在这篇文章里我会详细介绍我是如何使用 Airtable 来打造我的学术知识体系，而且将这个学术领域的知识库（「学术 OneOnOne」）开源了出来（需要科学上网），供大家参考。

现状

在我接触过的很多领域（交互设计、前端、实体产品、影视 CG 等）里，学术是算得上是一个入门门槛极高的领域了。原因大致有这么四点：

知识浓度很高： 由于一篇发表的论文往往经过长达几个月乃至几年时间的摸索、实验、研究、撰写，这使得一篇论文需要承载如此长时间积累下来的经验与知识。因此大部分文章往往非常精炼，引用众多。所以最终导致文章的知识浓度非常高，往往很难懂，你需要有较多的相关领域知识储备，才可理解论文内容；
文献总量多： 和互联网上各种层次不齐的文章资料不同，学术文献一般都被妥善保管，所以你可以很轻松地找到几年前、十几年前乃至几十年上百年前的文献，从而一点点知晓一个领域的学术发展脉络。这几十年上百年积累下来的论文可能总量有几百乃至上千篇，这也带来了另外一个问题：那么多文献很难管理。我们必须使用 Zotero 这样的文献管理工具，才能 hold 几百乃至上千篇文献；
大多资料为英文：语言障碍可能是国人学术研究路上的一只巨大拦路虎。毕竟比起「每个字都认识，但是就是看不懂」的难题，「连每个字都不认识」才是最要命的。这个问题除了学好英语之外，也可通过使用辅助工具来解决（例如我自己开发了多译来帮助自己快速阅读英文文献）；
入门的资料在互联网上较少：由于本身学术研究已经就是相对小众了，互联网上关于科研入门的资料相对较少。更别说尤其是细分领域，隔行如隔山，别说入门资料，可能相关研究资料都是非常非常少的，只存在于专门研究这个领域的若干实验室中。所以大部分人往往要在实验室中磨炼若干年方能发表一篇论文。这世上野生的科研人员可能已经不太存在了。

说了这么多，我并没有想要改变这种现状的心气，只是单纯发点牢骚（没想到吧💥 ）。然后引出我的一些关于科研的一些想法（虽然想法们甚至和现状关系都不大），并顺带安利一波 Airtable 罢了。

底层思想：知识分层

上述情况大致是学术研究的一个基本盘，接下来讲讲我自己的一些思路和方法。

首先我想讲一条超脱学术领域的底层思想，为全篇定调：领域知识需要分层处理，从具象到抽象，从细粒度到粗粒度。如此一来，不同层的关注点就会是不同的。只有将关注点做好分离，才能保证在这一层关注点下达到最佳的状态。

大部分「大家」往往偏好去谈大道理，甚至会摒弃说不要浪费时间在技巧的研究上，是因为他们没有思考过知识的分层这个问题。对他们来说，经过时间积累，关于工具或者技巧早已不再构成问题，所以才会大谈特谈思想、理念。而这样的言论，无异于是给你了一碗鸡汤又没跟你汤勺。

「知识分层」的底层思想和中国哲学中的「道法术器」的概念非常匹配，是我个人特别喜欢的对「知识分层」的诠释。我认为，「道法术器」是对任何一类领域知识恰如其分的归纳：

道：核心思想、理念、本质规律。 可以理解为底层逻辑、座右铭这样的存在。譬如我非常认同的一个科研理念：「一名研究者的价值，不在于发了多少篇论文，而是在于做了多少别人做不到的事情」。
法：法律、规章、制度、方法。 是以「道」为基础制定的不可违背的原则、方法等。举个例子的话，比如在刚研究一个陌生领域时，我会有一套百试百灵的方法来快速进入这个领域。
术：行为与技巧，以「道」为原则，做出反应和选择的具体行为。在这一层面研究的核心就是各种技巧，譬如论文写作中的要点等等。
器：工具。「器」用来体现道的思想，简化问题，更快达成目标，是体现 “器以载道” 的应用。譬如使用 Airtable、Zotero 来管理学术资料等等。

本篇不会去讲具体学术研究的「道法术器」（因为在我开源的 Airtable 知识库中已经有了），更多的是介绍我是如何用 Airtable 来分层构建学术领域的知识体系。

Airtable 的基础用法

器：学术资源

在科研中，「器」的问题往往最好解决，但对大部分刚开始的小白来说可能也是最难的。

最好解决的原因是：只要找到了趁手的好工具，往往意味着一类问题直接就被解决掉了。

对大部分小白来说最难的一点是：走不出「认知的盲区」。往往他们「不知道有这个工具」、「不知道原来可以去用工具来解决」，甚至「不觉得这是个问题」。

对我来说，「器」是最容易解决的，因为「懒是第一生产力」。我往往会受不了某些糟糕的体验，然后主动会思考市面上是否存在解决这类问题的方案，进而找到相应的资源或者工具，久而久之，我就积累了不少的学术资源和工具。

但是这样一来又导致了另外一个问题：资源太多，管理不过来了。我在很长一段时间内都是用书签来保存这些工具或资源，但是书签存在的一个大问题是没法记录更多的信息元数据，譬如我希望能够补充我对它的评分、使用体会、一句话介绍、相关领域等等，这些是单纯的书签工具无法满足的。

所幸我最后遇到了 Airtable ，可以说自定义数据类型和数据表完美满足了我对上述工具资源整理的需求。

在「学术 OneOnOne」中，我建了一张「学术资源数据库」的表，专门用于保存我在学术上的「器」的经验和知识。我按照自己的偏好，总共定义了「名称」、「一句话简介」、「介绍」等 9 个维度：

名称：这个网站的官方名称；
简介：一句话介绍，用于说明这个网站的用途，供我未来快速查阅；
介绍：关于这个网站的详细介绍，我会把我自己的一些使用体会和经验写在这里以做备忘；
评分：我个人对该资源的主观评分；
网址：这个网站的网址：
类型：这个网站属于哪个类型的资源，我目前定义了「资源」、「博客」、和「工具」三类，对「器」做了更进一步的类型划分；
领域：相当于标签；
截图：我会截一张这个网站资源的图，用于视图下的展示；
创建时间：在 Airtable 中可以设定一个创建时间类型的类型，设定这个类型后，值会自动设定成该行记录创建的时间。基于这列数据配合 Airtable 的筛选视图，可以实现「周刊」、「月刊」性质的内容。譬如每到月末，就创建一个当月的新增资源视图，筛选出当月添加的学术资源。（而且这个过程可以用 Airtable 的 Automation 自动化掉）另外更棒的一点是，由于名称、介绍、评分等信息都很完善，就可以非常轻松地产出「学术研究十大神器」这一类工具推荐的文章。从而实现在自我输入的过程中，轻松完成对外输出，这也是我之前所说的「输入与输出一体化」的体现。

说了那么多，它到底长啥样，如下图所示：

当然，如果这单纯只是一张表的话，其实也没有那么值的大吹特吹的，但是结合 Airtable 的视图和筛选，就可以变成下面这样（预览地址：Airtable - 学术资源搜索引擎）：

这个「学术资源搜索引擎」页面是「学术资源数据库」表的一个视图，采用了 Airtable 的 Gallery，然后筛选了搜索资源的记录，并按评分从高到低进行了排序。

这样一个视图精准聚焦了「高质量学术搜索引擎」这个需求，并且当我将其分享出来后，不需要登录就可以直接打开上述页面，这样一来，只要把这个地址添加为书签，就能够很快地找到需要的资源。

相似的，我还做了另外一个工具视图，用于记录一些好用的学术辅助研究工具（传送门：Airtable - 学术辅助工具）。

术：论文写作技巧

我一直认为，技巧这类「术」对所有的学术研究都是能带来直接的帮助，有时候一些很小的小技巧，可能就能够节约很多时间。

但是，传统意义的笔记工具对于「术」方面的整理并不够理想，无论是语雀还是 Roam。因为想要描述好一个技巧，需要详细说明技巧的适用场景、要点，最好能够附带上反面案例和正面案例。

因此一个好的「术」的说明本质上是一个自成体系的块，简单使用线性或者树型的文本都不太符合它的展示场景。

而数据表可以自行定义表的结构，因此便可以很好地满足「术」的元数据结构。

我在「学术 OneOnOne」中创建了「论文写作要点」的一张表，用于记录我总结的一些论文写作要点（都是差点没过的论文带来的经验教训 _(:з」∠)_ ），它包含的数据类型有：

名称：这条要点的名称；
详解：关于这条要点的详细说明（其中大部分直接来自盲审专家对我论文的批判…）
板块：这条要点属于论文中的哪个部分；
反面案例：不符合这个要点的案例；
正面案例：符合这个要点的案例；

然后我针对这个表，使用了Airtable 的看板的视图，每个「板块」一列看板。（预览地址：Airtable - 论文写作要点详解）

PS：由于我的论文还在微调中，所以要点的案例部分尚未补全完整。大概会等到我最终改完论文，再把修改前后的内容分别补充到反面案例和正面案例中。

法：论文写作流程

和「术」类似，我在论文写作流程中也使用看板视图，在元数据上只包含三个：步骤、说明、阶段，如下图所示（预览地址：Airtable - 论文写作流程【从左到右】）：

从「道法器术」的角度来说，越抽象，信息会越来越精炼，信息粒度会越来越粗，因此针对论文写作流程来说，并不会有多余的元数据。譬如在「看英文文章」这一步骤：

从中文里引用的文章或者重点强调的文章开始，搜索、整理英文文章（一定要用类似于zotero之类的工具才行），不断扩展关键词，争取找到这个领域做这个的大牛，运气好的话会找到几个正在做这个的小专家（如博士生），然后看他的文章或者他的网站，可以一下子把整个领域都拎起来了。这个过程也许会扫描上上百篇文章，然后逐渐收拢。

这里提到了「一定要用类似于zotero之类的工具才行」，其实这一句话就一笔带过了「Zotero 如何使用」的「术」层面的知识。

PS：在论文写作方面，知乎上有很多相关讨论，如果感兴趣可以去找一找，我也是基于相关资料做了简单整理。

Airtable 的高阶用法

Airtable 作为 Database 类领先的老大哥，我个人认为其最棒的功能就是 App。因为 Airtable 固有的视图在很多场景下是很难完全满足我们的需求的。例如在某条记录里写大段文本，就很不方便看。而 App 则很好地解决了这个问题，是对 Airtable 视图能力的极大扩充，并且有了这个能力，Airtable 才真正具有无限的应用潜力。

同时，由于 Airtable 表格数据的处理能力已经非常好用，因此一旦将这两个能力结合起来，威力无穷。

基础 App：知识库说明

由于 Airtable 基础组织形式是数据表，因此无法将一些提纲挈领的内容放在记录里，而使用 Airtable 的 Description App 就可以嵌入一个文本编辑器，写上相关的说明。（如下图所示）

展示效果如下（传送门：Airtable - 学术 OneOnOne）

文章排版 App：期刊会议一览

在某些场景下，我们可能希望记录下一些长文，而 Airtable 的固有的表格、看板、相册等视图都满足这种需求，那么就可以使用 Airtable 的 Page Designer App 自定义呈现一条记录的布局排版。

譬如我有一张表记录了相关的期刊、会议资料，该表中包含的元数据有：

会议/期刊简称： 英文一般大家直接使用缩写；
会议全称：会议期刊的全称；
说明：关于这个会议、期刊的详细说明，只要开启「Enable rich text formatting」，就可以让该条记录支持富文本格式（同时也支持 Markdown 语法）。

CCF 分类：计算机类论文的一个分类指标；
网址：该会议/期刊的网站；
附件：相关的附件，例如写作模板等；
更新日期：该会议的更新日期。

基于这些元数据，我设计的期刊会议的展示图如下：

这样一来，在 App 中就可以非常清晰的查看相关期刊会议的信息。

这种展示方式和笔记类工具最大的区别在于，你可以自定义展示相关的元数据，进而在有限空间内展示足够丰富粒度的信息。

自定义 App：Zotero 文献管理思路

Airtable 基础的各类表格能力是对数据表结构设计和记录增删改查的高效操作能力。而 Airtable App 是基于已有数据进行自由组合关联的展示出口。如果说普通 App 是 Airtable 在自定义视图上的一大突破，那么自定义 App 开发可谓是将这种能力发挥到了极致。

我曾在上一篇文章中写过一部分关于 Mindflow 的介绍，也曾经在去年 11 月份将其发给了官方审核，但是比较可惜的，后续一直没有回音，所以 Mindflow 暂时没法给到大家完整使用的体验，等到未来能够上架官方市场，再和大家完整分享 Mindflow 的使用好了。

在「学术 OneOnOne」中，我主要使用 Mindflow 来完成「使用 Zotero 管理文献」这个大问题的梳理。详细使用就不展开了，等到以后 Mindflow 能正式发布再和大家分享吧~这里就放几张图好了：

PS：关于 Zotero 的具体使用，非常推荐关注【青柠学术】这个公众号，这里介绍了很多关于 Zotero 的使用指南和技巧，号主也是我的校友来着。

最后的一点总结

学术思路、科研精神值得每个人了解

等我毕业以后，大概率是不会再做科研了，但是我还蛮感谢研究生期间的这些科研锻炼的。虽然并不是每个人都会去做学术，但是学术的研究思路、科研精神是值得每个人去了解的。尤其是学术研究中整套的研究思路和体系，在我分析和解决很多其他问题时也提供了诸多帮助。

我自己感觉，科研一旦入门之后（即知道了科研套路），可能相对还是容易的。但是从零开始到摸到门道，这个过程往往需要花费很多时间精力。所以把自己这两年沉淀下来的学术资料开源出来，如果对你有那么一点帮助，我也就觉得值得了。

关于 Airtable 的一点随想

正如我在之前的文章里所说，Airtable 是我 2020 年遇到的最让我惊喜的产品。我觉得他的意义不仅仅局限在单纯的「知识库」使用中，而是存在于「软件民主化」的愿景中。

在以往传统的产品开发过程中，光是后端数据库设计、后端 API 开发、前端 mock、前后端联调就要搞大半天。而现在在 Airtable 这样的数据库操作能力基础之上，用户只需要聚焦数据应该如何展现（即视图界面）和数据应该如何组织（即业务模型）即可。而一旦当已有的视图无法满足需要，就可以使用 Airtable App 的形式将视图能力进行拓展。

可以说，目前的 Airtable 已经可以把「后端」负责的事情全部做了，但是在视图拓展能力上，还是需要依赖于前端开发者写出 React 代码才能完成视图。

如果未来有一天，Airtable 能够将视图的搭建 low-code 化，使得任何人经过简单学习即可完成视图的拓展。如此一来，开发者也不再仅仅只有程序员，而变成了「广义开发者」，那么这个时候就将真正实现「软件民主化」，我想这才是所有 Database 类产品的终极追求。

> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰

> 实用、好用的正版软件，少数派为你呈现 🚀