"No Code" is not the future

No code 生产力工具的兴起

早期的很多生产力工具都与 coding 相关, 这里当然有软件工程发展局限性的因素，毕竟很多复杂的功能与配置暂时无法找到合理优雅的人机交互方式。于是使用和开发者同样的工具——coding——来解决问题是一个通用的方式。

但学习编程始终是一件有门槛的事，在某一期《Checked FM》中，三位主播曾讨论过 power user 的界限问题，当时一种观点就是以能否 coding 作为是否是 power user 的标准。也因此有大量的工具希望通过 no code 的方式来实现之前必须写代码才能达到的效果以降低使用门槛。

比如 iOS 系统的 Shortcuts，通过提供一些既有 pipeline，将各个 App 串联起来以实现很多提升效率的动作。IFTTT 则可以通过配置连接各种不同的第三方服务。一些更复杂的工具，例如 Huginn，理论上也算某种 no code，用户可以通过网页上的简单控件完成预设模板的配置。实现复杂的自定义功能。

相比之下，Notion 的野心则更大一些，他们希望把自己变成一个 all-in-one 的生产力工具。在 Notion 社区看来，完全用 no code 的方式来完成各项生产力任务，是一个可行的目标方向。¹

No code 类工具的挑战与局限

必须承认，Notion 等工具在 UI 交互，以及这些 UI 操作背后的数据逻辑层面，做了很多创新工作。这些创新也的确使得用户可以完成很多复杂任务。

这类生产力工具一方面提供了足够的自定义能力；另一方面也都在不断更新各类模板，在新手入门与 power user 间提供平衡。例如 Trello template 和 Notion template gallery。这些模板本身有两个作用，一来作为例子，展示工具本身的表达能力；二来作为样例，或者说模块，参与到用户后续自己的组装使用中。模块化的思想倒是跟传统编程有些类似。

但即便如此，还是有大量任务是有其内在固有复杂性的。这种复杂性会让这些 no code 工具的学习曲线迅速攀升。

可以感受一下 Notion 官方文档给出的两个表格操作的例子。

Notion table add property

Notion table filter

这还只是基本操作，当在真实场景中面对更复杂数据时，这些操作会更加繁琐和不直观。这时我们不禁要问，学一下 SQL 查询语句，或者 dplyr 的数据操作语句——这些所谓的 coding 真的比上面那一堆操作更难吗？

Coding 也是工具的一种，不必自我设限

我非常能理解不会编程的人对于屏幕上显示的代码的那种天然恐惧感，这种恐惧感同样表现在对于命令行操作的茫然，也表现在对于编辑配置文件的抗拒。

但其实这些代码、命令行、配置文件，本身也都是一种文本，跟一门外语文本并没有本质的区别，都是利用一组约定的符号，按照某些规则（语法）来表达意义。只不过更多一些限制，从而保证更少歧义罢了。从这个角度说，编程其实就是在写一篇作文。

文本本身虽然朴实，但这些字符符号对于抽象概念的表达能力则是无与伦比的。在某种意义上，语言文本的表达能力等同于人类思维输出的表达上界。在通用型 AI 或者脑机接口直接传输成为现实之前，coding 这种看似简陋，在 UI 上也不那么炫酷的方式，可能已经是我们最好的 pro 工具了。

因此真的没有必要自我设限，为了追求所谓 no code 的「好体验」，而把本来能用代码简单抽象并解决的问题变得繁琐而复杂。毕竟真的 Pro 是不怕用户体验差的²。