编注：本文是少数派 2020 年度征文活动 的入围文章。本文仅代表作者本人观点，少数派对标题和排版略作调整。
前言：今年 3 月份就要毕业了，准备把这两年半硕士生涯里为数不多的学术经验（毕竟我的主业还是工程实践，硕士除了毕业论文就没有正儿八经搞过学术🤣 ）分享出来，希望会成为留存在世上的我的读过硕士的足迹吧。
在此之前我曾经写过一篇 Airtable 如何满足我信息管理需求的文章（传送门），但是那篇文章更多是一篇概览，罗列了很多我关于 Airtable 的用法和一些思路，具体案例上都是蜻蜓点水，没有详细展开。而在这篇文章里我会详细介绍我是如何使用 Airtable 来打造我的学术知识体系，而且将这个学术领域的知识库（「学术 OneOnOne」）开源了出来（需要科学上网），供大家参考。
在我接触过的很多领域（交互设计、前端、实体产品、影视 CG 等）里，学术是算得上是一个入门门槛极高的领域了。原因大致有这么四点：
说了这么多，我并没有想要改变这种现状的心气，只是单纯发点牢骚（没想到吧💥 ）。然后引出我的一些关于科研的一些想法（虽然想法们甚至和现状关系都不大），并顺带安利一波 Airtable 罢了。
上述情况大致是学术研究的一个基本盘，接下来讲讲我自己的一些思路和方法。
首先我想讲一条超脱学术领域的底层思想，为全篇定调：领域知识需要分层处理，从具象到抽象，从细粒度到粗粒度。如此一来，不同层的关注点就会是不同的。只有将关注点做好分离，才能保证在这一层关注点下达到最佳的状态。
大部分「大家」往往偏好去谈大道理，甚至会摒弃说不要浪费时间在技巧的研究上，是因为他们没有思考过知识的分层这个问题。对他们来说，经过时间积累，关于工具或者技巧早已不再构成问题，所以才会大谈特谈思想、理念。而这样的言论，无异于是给你了一碗鸡汤又没跟你汤勺。
「知识分层」的底层思想和中国哲学中的「道法术器」的概念非常匹配，是我个人特别喜欢的对「知识分层」的诠释。我认为，「道法术器」是对任何一类领域知识恰如其分的归纳：
本篇不会去讲具体学术研究的「道法术器」（因为在我开源的 Airtable 知识库中已经有了），更多的是介绍我是如何用 Airtable 来分层构建学术领域的知识体系。
在科研中，「器」的问题往往最好解决，但对大部分刚开始的小白来说可能也是最难的。
最好解决的原因是：只要找到了趁手的好工具，往往意味着一类问题直接就被解决掉了。
对大部分小白来说最难的一点是：走不出「认知的盲区」。往往他们「不知道有这个工具」、「不知道原来可以去用工具来解决」，甚至「不觉得这是个问题」。
对我来说，「器」是最容易解决的，因为「懒是第一生产力」。我往往会受不了某些糟糕的体验，然后主动会思考市面上是否存在解决这类问题的方案，进而找到相应的资源或者工具，久而久之，我就积累了不少的学术资源和工具。
但是这样一来又导致了另外一个问题：资源太多，管理不过来了。我在很长一段时间内都是用书签来保存这些工具或资源，但是书签存在的一个大问题是没法记录更多的信息元数据，譬如我希望能够补充我对它的评分、使用体会、一句话介绍、相关领域等等，这些是单纯的书签工具无法满足的。
所幸我最后遇到了 Airtable ，可以说自定义数据类型和数据表完美满足了我对上述工具资源整理的需求。
在「学术 OneOnOne」中，我建了一张「学术资源数据库」的表，专门用于保存我在学术上的「器」的经验和知识。我按照自己的偏好，总共定义了「名称」、「一句话简介」、「介绍」等 9 个维度：
说了那么多，它到底长啥样，如下图所示：
当然，如果这单纯只是一张表的话，其实也没有那么值的大吹特吹的，但是结合 Airtable 的视图和筛选，就可以变成下面这样（预览地址：Airtable - 学术资源搜索引擎）：
这个「学术资源搜索引擎」页面是「学术资源数据库」表的一个视图，采用了 Airtable 的 Gallery，然后筛选了搜索资源的记录，并按评分从高到低进行了排序。
这样一个视图精准聚焦了「高质量学术搜索引擎」这个需求，并且当我将其分享出来后，不需要登录就可以直接打开上述页面，这样一来，只要把这个地址添加为书签，就能够很快地找到需要的资源。
相似的，我还做了另外一个工具视图，用于记录一些好用的学术辅助研究工具（传送门：Airtable - 学术辅助工具）。
我一直认为，技巧这类「术」对所有的学术研究都是能带来直接的帮助，有时候一些很小的小技巧，可能就能够节约很多时间。
但是，传统意义的笔记工具对于「术」方面的整理并不够理想，无论是语雀还是 Roam。因为想要描述好一个技巧，需要详细说明技巧的适用场景、要点，最好能够附带上反面案例和正面案例。
因此一个好的「术」的说明本质上是一个自成体系的块，简单使用线性或者树型的文本都不太符合它的展示场景。
而数据表可以自行定义表的结构，因此便可以很好地满足「术」的元数据结构。
我在「学术 OneOnOne」中创建了「论文写作要点」的一张表，用于记录我总结的一些论文写作要点（都是差点没过的论文带来的经验教训 _(:з」∠)_ ），它包含的数据类型有：
然后我针对这个表，使用了Airtable 的看板的视图，每个「板块」一列看板。（预览地址：Airtable - 论文写作要点详解）
PS：由于我的论文还在微调中，所以要点的案例部分尚未补全完整。大概会等到我最终改完论文，再把修改前后的内容分别补充到反面案例和正面案例中。
和「术」类似，我在论文写作流程中也使用看板视图，在元数据上只包含三个：步骤、说明、阶段，如下图所示（预览地址：Airtable - 论文写作流程【从左到右】）：
从「道法器术」的角度来说，越抽象，信息会越来越精炼，信息粒度会越来越粗，因此针对论文写作流程来说，并不会有多余的元数据。譬如在「看英文文章」这一步骤：
从中文里引用的文章或者重点强调的文章开始，搜索、整理英文文章（一定要用类似于zotero之类的工具才行），不断扩展关键词，争取找到这个领域做这个的大牛，运气好的话会找到几个正在做这个的小专家（如博士生），然后看他的文章或者他的网站，可以一下子把整个领域都拎起来了。这个过程也许会扫描上上百篇文章，然后逐渐收拢。
这里提到了「一定要用类似于zotero之类的工具才行」，其实这一句话就一笔带过了「Zotero 如何使用」的「术」层面的知识。
PS：在论文写作方面，知乎上有很多相关讨论，如果感兴趣可以去找一找，我也是基于相关资料做了简单整理。
Airtable 作为 Database 类领先的老大哥，我个人认为其最棒的功能就是 App。因为 Airtable 固有的视图在很多场景下是很难完全满足我们的需求的。例如在某条记录里写大段文本，就很不方便看。而 App 则很好地解决了这个问题，是对 Airtable 视图能力的极大扩充，并且有了这个能力，Airtable 才真正具有无限的应用潜力。
同时，由于 Airtable 表格数据的处理能力已经非常好用，因此一旦将这两个能力结合起来，威力无穷。
由于 Airtable 基础组织形式是数据表，因此无法将一些提纲挈领的内容放在记录里，而使用 Airtable 的 Description App 就可以嵌入一个文本编辑器，写上相关的说明。（如下图所示）
展示效果如下（传送门：Airtable - 学术 OneOnOne）
在某些场景下，我们可能希望记录下一些长文，而 Airtable 的固有的表格、看板、相册等视图都满足这种需求，那么就可以使用 Airtable 的 Page Designer App 自定义呈现一条记录的布局排版。
譬如我有一张表记录了相关的期刊、会议资料，该表中包含的元数据有：
基于这些元数据，我设计的期刊会议的展示图如下：
这样一来，在 App 中就可以非常清晰的查看相关期刊会议的信息。
这种展示方式和笔记类工具最大的区别在于，你可以自定义展示相关的元数据，进而在有限空间内展示足够丰富粒度的信息。
Airtable 基础的各类表格能力是对数据表结构设计和记录增删改查的高效操作能力。而 Airtable App 是基于已有数据进行自由组合关联的展示出口。如果说普通 App 是 Airtable 在自定义视图上的一大突破，那么自定义 App 开发可谓是将这种能力发挥到了极致。
我曾在上一篇文章中写过一部分关于 Mindflow 的介绍，也曾经在去年 11 月份将其发给了官方审核，但是比较可惜的，后续一直没有回音，所以 Mindflow 暂时没法给到大家完整使用的体验，等到未来能够上架官方市场，再和大家完整分享 Mindflow 的使用好了。
在「学术 OneOnOne」中，我主要使用 Mindflow 来完成「使用 Zotero 管理文献」这个大问题的梳理。详细使用就不展开了，等到以后 Mindflow 能正式发布再和大家分享吧~这里就放几张图好了：
PS：关于 Zotero 的具体使用，非常推荐关注【青柠学术】这个公众号，这里介绍了很多关于 Zotero 的使用指南和技巧，号主也是我的校友来着。
等我毕业以后，大概率是不会再做科研了，但是我还蛮感谢研究生期间的这些科研锻炼的。虽然并不是每个人都会去做学术，但是学术的研究思路、科研精神是值得每个人去了解的。尤其是学术研究中整套的研究思路和体系，在我分析和解决很多其他问题时也提供了诸多帮助。
我自己感觉，科研一旦入门之后（即知道了科研套路），可能相对还是容易的。但是从零开始到摸到门道，这个过程往往需要花费很多时间精力。所以把自己这两年沉淀下来的学术资料开源出来，如果对你有那么一点帮助，我也就觉得值得了。
正如我在之前的文章里所说，Airtable 是我 2020 年遇到的最让我惊喜的产品。我觉得他的意义不仅仅局限在单纯的「知识库」使用中，而是存在于「软件民主化」的愿景中。
在以往传统的产品开发过程中，光是后端数据库设计、后端 API 开发、前端 mock、前后端联调就要搞大半天。而现在在 Airtable 这样的数据库操作能力基础之上，用户只需要聚焦数据应该如何展现（即视图界面）和数据应该如何组织（即业务模型）即可。而一旦当已有的视图无法满足需要，就可以使用 Airtable App 的形式将视图能力进行拓展。
可以说，目前的 Airtable 已经可以把「后端」负责的事情全部做了，但是在视图拓展能力上，还是需要依赖于前端开发者写出 React 代码才能完成视图。
如果未来有一天，Airtable 能够将视图的搭建 low-code 化，使得任何人经过简单学习即可完成视图的拓展。如此一来，开发者也不再仅仅只有程序员，而变成了「广义开发者」，那么这个时候就将真正实现「软件民主化」，我想这才是所有 Database 类产品的终极追求。
> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰
> 实用、好用的正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。