我去年到现在的工作一直在研究表格，以及学些低成本的写代码方式，写一些我需要的和工作相关的工具。
独立完成，不依靠程序员或者设计师，于是我选择了纯后端方向的东西，而把前端操作和一些逻辑交给表格去。
我使用了飞书多维表格和飞书 anycros ， 多维表格是一个像 Airtable 的东西，anycross 是一个像 tray.io 的东西。
二者都给我了自由度，在飞书框架下做一些自由的事情。
比如多维表格，存储服务的日志，本身就是交互容器，本身替代运营后台，本身又可以作为一个配置的规则容器等
比如飞书 anycross ，虽然画布不是我希望的编程方式，但是在部署成本上提供的便利性让我转移了阵地。
这里不得不说，起初我大量依赖 FaaS 服务，写了很多胶水代码，很多在字节跳动已死亡的轻服务这个工具里面。
在飞书中用各种低代码工具写了很多小工具之后感受到几点
- 原则：聊胜于无，能力要覆盖而不是办不到 。特别对于不会写代码的人来说，缺一个能力导致放弃挫伤积极性
- 业务或者 API 尽量原子化
- 得有 FaaS 模块
- 普通人的拦路虎是各种 API 的鉴权，和 JSON 数据的处理
- 表格才是这类工具的UI，我是非画布派
话不多说，说回我做的实践。
早期在介绍 monday 这个产品那期的时候，我非常惊讶与他们对各个模块清晰的定义。
基本的模块中我的注解
- 人们往往理解dashboard为仪表盘，关注的是图表，殊不知本末倒置，仪表盘最重要的是系统的动态，关注的是系统的 feed，feed 之前，可视化的图表在后。dashboard：feed>图表。
- views 视图是消费数据的，所以表单并不是个视图，它不是来消费数据的，可以理解 airtable 等把表单作为一个视图来处理，是一个偷懒的行为。
- 从任何地方获取数据，这一行为就分化了2条线，一条是从人的角度出发 forms 这是所有表单问卷类产品的基本场景，一条是从任何应用处获取数据，这却缺少产品去做。这种一体两用的理解很优美。
- 对于自动化 RPA 场景，首先考虑的是能原子化的重复场景，无外乎业务读写数据的增删改查等逻辑，世界上的业务千千万万，自然造成了自动化 zapier 的生态。Automations：重复>人工>出错。
其中我核心关注的是 dashboard：feed>图表 这一点，它应该是你工作企业中最新动态的合集，是一个 feed 优于图表的模块，于是我有下面的一些想法。
基于以上的想法，于是做了几个在飞书里面使用的小工具，载体都是多维表格。
文档访客捕手
你自己是所有者，是 owner 的飞书的文档（有权限看到访客是谁），想知道都有哪些，点赞浏览等数据是多少，每天都有谁看了。看看什么放文档在短时间内有人大量浏览，或许就是一个你工作内容的捕捉时机。
签名捕手
在任意一个工作或者聊天软件中，只要有签名的地方，往往都暗藏着一些暗线。比如关键研发和设计的休假出差，某人某篇得意的文章，或者找人指南等。团队那么大，并不是每天都能沟通上，公司那么多人并不都认识得完毕。下图提供的就是一种每天获取你有权限能看到的你关心同事的签名在一起，并将新签名推送给你的小工具。
就像 Spoonbill 你可以看到你关注的 Twitter 账号修改个人简介的历史记录，Spoonbill 的开发者说，我们把自己的身份当作是一种软件（We treat our identities like software），这是一个很有意思的说法，软件也可以迭代更新，并以此更好的和别的软件产生连接（通常是以数据交换的形式），身份也是如此。签名捕手有类似的效用在里面。
OKR 捕手
其实 OKR 这个工具，不如用表格来写，但是当你公司在使用OKR工具的时候，往往落地的时候把 KR 拆解到细分的任务的时候，缺少一个甘特图。缺少一个全局的视角把团队的人的 OKR 放在一张表格中，下面的截图提供的就是一种集合你同事 OKR 在一起的工具同时也能拆解出任务出来，将飞书 OKR 导入到多维表格。
消息捕手
你一天中接受到有效工作消息的数量是多少，你一天的繁忙程度是怎么样的，大概多少条消息可以让你没空去关注微信或者微博，你有没自主分析你工作中消息数据的想法。
消息捕手就是这样的一个东西，它是基于飞书捷径中提供的监听与你单聊以及群中@你的捷径做的，只是飞书捷径不支持多维表格，通过飞书的 anycross 工具自己实现了这部分。
微博/豆瓣捕手
把你关注的人的微博和豆瓣关键动态，写到一个表格中，集中推送给你，而不是你主动去刷。
如果你也是使用飞书，以上的 demo 可以邮箱交流获取，flowercold@gmail.com
推荐：