飞书开源CLI，请立刻扔掉那坨厚重的MCP

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/b7e3a04f.html

你好，我是测试蔡坨坨。

本周飞书在 GitHub 上开源了一个命令行工具，叫 lark-cli。看到这个消息的时候，我真的很惊喜，第一反应是”早他妈出就好了”。

因为在这个工具出来之前，我已经在”让 AI 操控飞书”这件事上踩了不少坑。

踩过的坑

在聊飞书 CLI 之前，先说说我走过的弯路。

第一坑：官方标准 MCP，功能太残

最开始我用的是飞书官方提供的标准 MCP 接入方式。

配置倒是简单，接上 Claude Code 就能用。但用了一段时间之后，发现局限太多了。

比如最常见的一个需求——从飞书文档里提取内容。结果拿回来的只有纯文本，图片没了，表格结构没了，画板没了，文档排版全丢了，基本上就是把所有富文本内容打平成一段话。

并且也不支持增量更新。

第二坑：基于 OpenAPI 的 MCP，上下文直接爆炸

官方其实还提供了第二种 MCP，是基于 OpenAPI 的本地 MCP，比第一种能做的事多多了，看着功能很全。

但实际接进来用，还是有很多问题。

比如飞书文档的块类型特别多：纯文本块、标题块、图片块、表格块、画板块、文件块、代码块……每种块的处理方式都不一样，而且有些操作需要多个 API 配合才能完成，比如”更新一张图片”，你需要先上传文件、拿到 token，再去更新块内容。

另外，把所有这些工具都塞进 MCP，上下文一下就爆了。AI 每次调用之前，你还得手动告诉它”你要用哪几个工具”，不然它要么工具找不着，要么一股脑全调用，绕了一大圈才干成一件事。

第三坑：自己写脚本，需要额外开发

两条路都走不通，我就干脆自己基于飞书 OpenAPI 写了几个脚本，把常用的操作封装起来，再放到 Skills 中调用。

这条路倒是最可控，但问题也很明显：需要额外的开发成本。每增加一个功能，都要去翻 API 文档、调试接口、处理各种边界情况。

换一个场景可能就得改代码，维护起来也麻烦。

飞书 CLI 如何解决我的痛点？

功能覆盖够全

飞书 CLI 覆盖了飞书 11 个核心业务域，包括即时通讯、云文档、多维表格、电子表格、日历、邮箱、任务、视频会议、知识库、通讯录、云空间，总共提供了 200 多条命令。

几乎把飞书核心能力都包进来了。

同时它还为 AI Agent 设计了 19 个预置 Skills，相当于 19 套指令文件，AI 加载之后就知道怎么调用飞书的各项功能，不需要你来帮它选工具。

天然适合 AI 操控

CLI 的本质是命令，一行命令做一件事，结构清晰。这和 AI 的交互方式高度吻合——AI 最擅长的就是把你的自然语言翻译成一条条命令，然后顺序执行。

基于 OpenAPI 的 MCP 之所以上下文爆炸，是因为它把所有 API 都平铺出来，AI 要从几十上百个选项里挑合适的。而 CLI 是把这些 API 组合成了有意义的命令单元，一条命令背后可能封装了三四个 API 调用，AI 不需要知道细节，只需要知道用哪条命令。

不需要自己开发

以前要自己写脚本封装成 CLI 命令，现在现成的命令直接用。

安装&配置

地址：https://github.com/larksuite/cli

我的做法是直接把 README 文档链接丢给 Claude Code，让它自己读、帮我安装。

整个安装分四步：

  • 安装工具包
  • 配置应用凭证
  • 登录授权
  • 验证

除了两次需要在浏览器里点击授权之外，其他全部由 AI 自动完成。

第一步：让 AI 安装 CLI 和 Skills

把下面这句话发给你的 AI Agent（Claude Code、Codex …）：

1
帮我安装所有东西：https://github.com/larksuite/cli/blob/main/README.zh.md

AI 会自动安装 @larksuite/cli 以及 19 个 Skills。

PS：如果 Skills 没有装上，也可以手动执行以下命令

1
npx skills add larksuite/cli --all -y -g

第二步：重启你的 AI 工具

装完之后，要重启 Claude Code（或者 Cursor、Codex 等），才能加载 Skills。

第三步：配置应用

告诉 AI 开始配置，它会运行命令 lark-cli config init --new，输出一个链接，在浏览器里打开，创建飞书 CLI 应用（选头像和名字，点创建就行）。

第四步：登录授权

AI 继续运行登录命令，同样会给你一个授权链接，浏览器打开，完成权限授权。

权限列表会比较长，覆盖了消息、文档、日历、邮箱、任务等几乎所有业务域——这是功能全的代价，授权一次就好了。

场景应用

安装完成之后，我立刻上手尝试了几个场景。

Markdown ↔ 飞书文档

文档的读取和写入应该是使用最多的场景了。

例如：

  • 读取飞书文档+飞书链接
  • 将本地XX.md文件上传到飞书XX目录下

相比飞书 MCP，通过 CLI 方式读取到的文档内容 结构完整更完整，包含了图片 token、流程图、代码块等富文本内容。

支持 40+ 种块类型，Markdown 导入飞书之后再导出，内容完整保留，没有损耗。更夸张的是，文档里的 Mermaid 和 PlantUML 图表（支持 8 种图表类型），写入飞书后会自动转成飞书画板——不是截图，是可以直接在飞书里编辑的矢量图。

这对写技术文档的人来说很实用。本地写好的 markdown 文档，一条指令写进飞书，格式完整保留；反过来，飞书里已有的文档直接拉下来给 AI 读，结构也不会丢——图片、表格、画板全在，不再是打平的纯文本。

格式完整&图片保留：

飞书消息发送

例如：

  • 帮我给通讯录里所有内部联系人发一条消息：[你要发的内容]
  • 帮我给XXX发送一条消息：XXX

把多维表格做成可视化网页

例如：找到我的多维表格「[表格名称]」，用数据做一个可视化分析网页

AI 会自动定位表格、读取数据、生成 HTML 页面

自动发飞书周报

操作步骤：

  1. 拉一个飞书群，把飞书 CLI 机器人加进去
  2. 在 Claude Code 输入：每周五下午 6 点，把 [数据来源] 汇总成周报，发到「[群名称]」这个群
  3. AI 会帮你配置自动化，后续每周自动执行

综上

传统产品考核 DAU、停留时长，这些指标都要求用户打开 GUI。但飞书把 CLI 开源出来之后，AI Agent 可以直接通过命令行调用飞书，用户不需要打开飞书 APP，传统口径上的日活会掉，但用户真正从飞书获得的价值反而上去了。

这需要自上而下想清楚一件事：我们到底是在追数字，还是在追价值？

飞书选了后者。

还有一个小细节：飞书 CLI 的报错信息不是普通的 404、502，而是告诉 AI”哪个参数出问题了、错在哪里、下一步执行什么命令修复”。AI 拿到这种结构化的错误信息，可以自主重试和修正，不需要人介入。这个设计细节，我觉得是真的在为 AI 调用场景做优化，值得学习。

在我看来，飞书 CLI 的意义不只是”飞书出了个好用的工具”，而是一个信号：产品开始为 AI 设计，而不只是为人类设计了。

GUI 面向普通用户，CLI 面向 AI。我相信未来很多产品都会走这条路。

如果你现在还在靠手动操作飞书，或者 MCP，不妨把 CLI 装上试试。

安装本身只需要几分钟，剩下的事情就让 AI 去干吧。