好记星.ai: 飞书cli 这种牛逼的东西，却因为飞书的技术架构，不得不让用户背负着巨大的理解成本，可以说这也是一种新旧时代交替的副作用了。 飞书的设计是经典的saas多租户的结构。要想使用飞书的api，就需要在飞书开发者后台创建一个新的应用，应用有两套权限，第一套是应用自己的，也就是应用跟员工平级，应用可以操作飞书里各种套件，比如文档啥的，操作的留痕就是应用。第二套是一种代理授权机制，也就是先让员工授权，把权限交给应用，应用去做事，但是留痕都是这个员工的。然后！这个应用有个机器人功能，可以让应用以一个机器人的面貌跟其他员工对话，那这个机器人是啥权限呢，也是应用权限。 好，以上没有任何毛病，其实真研究明白了还挺清晰的。以前这里的复杂都是程序员来消化的，普通人难以得见，也不需要为此头疼。 但是有一天飞书cli发布了，这个团队极其的勤奋，144天狂发88个版本，平均1.5天发一版，功能的开放性也是超级炸裂，什么鸡儿都往里面加。之前飞书的功能开放全靠服务端api，这个api的更新是多久一回呢，基本上以季度来做节奏。当时官方飞书cli还没有发布时，我已经利用这批api做出了自己的飞书cli，当时就发现api开放性很差，很多细节都不提供api（比如文档发/回复评论）。完事官方的cli一发布，我做的cli立刻变成了小丑，因为官方cli里的api实在是太丰富了，远超之前的api体系。 于是，以上复杂的权限体系，庞大的功能，全部塞到这个cli里。按大的功能模块分组，官方提供了一堆skill来驱动Agent使用cli，牛逼也是真牛逼，但理解成本也真的很高。 首先是每个员工都要创建一个应用，每个员工！飞书已经对这个流程做了极致的简化，会引导你一键创建一个应用，但是，公司里创建应用首先是要审批的，创建了也不能立刻用上。再就是，很多小白员工发现一次居然不行，拿起小鞭子就让Agent反复创建应用，实际创建了一大堆！小白也不知道最终用的是哪个了！管理员你就审吧～ 其次是权限，飞书的应用权限有 130 个，用户权限 139 个，你就配去吧，绝大多数人根本理解不了为什么权限会分为应用和用户，只能Agent说什么就做什么。然后还把两个权限的切换交给了cli，由Agent按需去用，实际最终的结果就是所有权限全打开了。那捏吗的还配置个der啊，直接默认全开不就好了吗？ 再就是这个机器人，飞书cli的客服群里经常有人问，我都配置好了飞书cli了，为啥我的飞书机器人还是不回复我呢？对啊，为啥呢？说实话这个问题很难一句话解释，因为经过一些骚操作，飞书cli确实也能让机器人跟员工对话。但问题在于，当你把这一大堆名词概念都推到小白前额叶的时候，大家都只能凭直觉去感受这耷拉着的AGI啊。 不过话又说回来，这可能正是卖课的空间？由于这个架构的存在，这里的理解成本总是无法被消解的。也许精通AI的代价就是成为程序员的形状。