先上结论，Notion 是一款具备 低代码数据库 特性的效率工具。

相信大家都认识 Notion，可能也使用了很长时间。很多人将它作为笔记软件，也有人做了各种模版，实现了记账系统、个人管理系统。看起来，Notion 似乎是一款很复杂，学习门槛很高的应用。这次，我想带你重新认识一下 Notion。

设计思想

Notion 支持的功能过于繁杂。要认识 Notion，我们不如先观察一下其它的 app。

大家可能都知道，大部份的 app 都是客户端/服务器架构（简称 C/S，client/server）。运行在我们手机上的 app 是客户端，它会通过网络与远方的服务器通信。比如小红书，知乎，b 站。我们都是用 app 发布自己创作的笔记、文章、视频到服务器，并从服务器下载其他人创作的内容。更简单来说，就像是班级中的学委，负责收集所有同学的作业，老师批改完后同学再从学委处取回。这是一种典型的 中心化 架构。

而我想说的是，Notion 可以帮助你以 极小的成本开发一个这样的应用，因为它的设计思想就是基于 C/S 架构的抽象。

试想一下，如果你是经营者，想要用工具来为自己的业务赋能。具体一点，就拿用户维护场景举例。首先考虑的肯定是节约成本，如果有现成的工具可以用那是再好不过了，开发一个新的应用，招聘程序员那得多贵呀。经过调研，你很可能会发现：有很多候选工具，但它们都差点意思。用微信吧，用户信息基本都只能写在备注里。用社交账号吧，向用户的推送就比较弱。很多时候，人们会选择配合使用多个工具，虽然满足了需求，但操作链不可避免地加长了，多了很多并不需要的功能，也就多了额外的成本。

既然天底下的效率工具基本都大同小异，那么我们是不是可以将它们相同的地方抽象出来，再做一些小的更改，就能得到最适合自己的工具了呢？于是，Notion 诞生了。

Notion 的解决方案

Notion 同时提供了抽象后的客户端与服务器两者的功能。客户端的主要功能是提供友好的用户界面，让不具备专业知识的用户也能够操作数据以及浏览数据。服务器的主要功能是存储、整理数据，给用户所需要的数据。Notion 模糊了这两者的界限，让我们直接在 用户友好的界面 里完成对数据的一切存储、操作、整理。

听起来，这样的解决方案似乎打败了所有的 app，它们都没有存在的必要了。但我们要知道，抽象的代价就是 无法具体。比如我们对 Notion 的界面操作十分有限，只能够改变元素在界面中的位置，无法彻底改变操作逻辑。而对于数据的操作也受到限制，例如无法进行精细的权限管理。Notion 所做的就是尽量提高短板，让用户在不写或者少写代码的情况下开发出最适合的应用。

顶层抽象

现在，我们可以从一个最笼统的角度来概括 Notion 的功能。它的适用场景有：

• 内容协作。可以轻松地在用户之间协作处理数据。
• 数据展示。Notion 可以用直观的界面向用户展示图标、文档等数据。将页面发布到互联网的功能可以最大化增加内容的曝光。

而它不擅长的点在于：

• 个性化操作逻辑与界面。我们无法用 Notion 做出像 app 一样自由的操作逻辑。
• 数据收集。受限于用户界面，我们收集数据的方式有限，主要通过手动输入。这一点可以通过 Notion API 来改善。

借助这些结论，我们可以对自己的需求做个简单的评估，来判断 Notion 是不是你要的。首先，你认为市面上没有最适合你需求的 app。其次，你的需求与协作或数据展示有关，如：

• 项目管理。项目成员之间协作操作数据，Notion 可以整合这些数据并提供整体直观的数据分析图。具体来说，单人/多人记账，进度管理等都算这一类。
• 共享文档。类似于知识库、wiki，多名贡献者一起贡献词条。
• 日程管理。由于新的 Notion calendar 的推出，Notion 在时间管理的能力上得到了进一步的强化。

特别的，对于个人笔记的需求来说，我不推荐 Notion，原因是对该需求来说，你应当对功能做一些减法。最后，如果你确信 Notion 是你需要的，那么就可以着手于开发。

结语

这次，我们从一个软件工程师和一个经营者的角度重新认识了 Notion，这有助于我们重新评估自己是否需要这款应用。在后续的文章中，我会分享更多使用 Notion 的教程，与这篇文章一样，同样是 基于需求 的角度展开，目标是帮助读者提高使用 Notion 实现需求的能力。