第一次看到 lark-cli，我会先问一个很实际的问题：它和飞书开放平台 SDK、MCP、普通脚本到底有什么区别？简单说，它是飞书官方维护的命令行执行层，把文档、日历、表格、消息、邮箱、任务等对象变成终端命令，也让 Codex、Cursor、Claude Code 一类 Agent 有了可以直接调用的“手”。

先把它放在正确位置：执行层

Lark 官方把 Agent 接入拆成三层：一键创建应用解决凭据，Channel SDK 负责在会话里收发消息，Lark CLI 负责真正执行飞书业务动作。只想让机器人聊天，CLI 不是必选项；想让 AI 查日程、改文档、写表格或处理邮件，执行层才是关键。

对人

在终端里运行结构清楚、可组合的飞书命令。

对 Agent

通过配套 Skills 理解命令、身份、权限、参数与风险边界。

对开发者

快捷命令不够时，还能继续调用 API 命令或原始 OpenAPI 路径。

我的试法：先运行只读的 lark-cli calendar +agenda --as user。它能返回当天日程，就说明应用配置、用户授权和命令执行链已经连通。

它碰到的不是页面，而是飞书对象

官方中文 README 当前写明 18 个业务域、200+ 精选命令和 26 个 AI Agent Skills。这里的“覆盖”不是打开网页替你点击，而是通过飞书开放平台读写日程、文档、电子表格、多维表格、消息、云空间、邮箱、任务、会议、知识库等对象。

一条需求会落到不同粒度

• 快捷命令：calendar +agenda、docs +create，适合高频任务。
• API 命令：与开放平台资源和方法对应，便于精确控制。
• 通用调用：lark-cli api 可直达尚未封装成快捷命令的端点。

我的试法：不先背完整命令表，而是执行 lark-cli <service> --help，再用 lark-cli schema 查看参数、身份和所需 scope。这样比猜命令名可靠得多。

谁会真正从它省下时间

经常在飞书里重复整理资料、约会、汇总表格的人最容易感受到价值；正在做 Agent 工作流的开发者，也能省掉逐个封装 API 的工作。它不适合把权限一次性全开后无人看管地运行。官方明确提醒：Agent 可能产生幻觉、误执行和提示词注入风险，授权后还会在 scope 范围内以用户身份操作。

我的判断线：先选一个只读场景，确认 JSON 输出里的 ok 为 true；再尝试可预览的写操作，并保留 --dry-run 和人工确认。能把这条边界守住，lark-cli 才是生产力工具，而不是新的权限隐患。