飞书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的代价就是成为程序员的形状。
@aigc1024
 
 
Back to Top