在 Claude Code 里用 lark-cli 操作飞书

参考答案：不重复，两者覆盖完全不同的客户端形态。

• lark-openapi-mcp 解决的是「Cursor / Claude Desktop / VS Code 这类非终端客户端怎么调飞书」——这些客户端是图形界面，没法直接 spawn 一个 CLI 进程，必须通过 MCP 协议把工具列表预注册到客户端内部的会话上下文里。代价是工具描述要常驻在每次请求的 token 里。
• lark-cli 解决的是「Claude Code / Codex CLI / Gemini CLI 这类终端 Agent 怎么调飞书」——终端 Agent 本身就在 shell 里跑，最自然的工具调用方式就是 spawn 子进程执行 CLI 命令。代价是只能在终端环境用，但好处是工具描述不占 token、按需调用。

更深一层看，飞书做这两条路也反映了 2026 年 AI 工具集成的两种主流形态：MCP 是「客户端预先知道有哪些工具」的模式，CLI 是「按需自描述发现工具」的模式。它们各有适用场景，不存在谁替代谁。

如果你团队既有人用 Cursor 又有人用 Claude Code，两个都装、各用各的就是最优解。

参考答案：分两类场景设计，永远不要让所有人共享同一套凭证。

场景一：操作个人数据（看自己的日程、回自己的邮件、读个人能看到的文档）

• 每个人在自己机器上跑 lark-cli auth login --as user --recommend，独立 OAuth 授权
• 凭证加密存在各自的系统 Keychain，跟其他人完全隔离
• 飞书企业管理员可以在后台审计每个用户的授权范围

场景二：操作团队/应用数据（在群里发自动化通知、写公共多维表、查全员通讯录）

• 由企业管理员创建一个自建应用，配置最小必要的应用权限
• 应用凭证（app_id / app_secret）走团队的 secret manager（Vault / 1Password / SOPS），不进 git
• 每个用户的 lark-cli 用 --as bot 模式调用，但凭证从环境变量或临时下发渠道注入
• 关键操作（发群消息、改多维表）开 --dry-run 让 Agent 先预演，人工确认后再执行
• 高危操作（删数据、撤回消息）放进 Claude Code 的 permissions.deny 白名单里

进阶建议：

• 设审计日志，所有 lark-cli 调用都记录到中央日志，方便事后追溯
• 用 git worktree 给团队 Agent 工作流隔离上下文，避免不同任务共享 Token 状态
• 长期看，团队场景应该评估是否走「飞书机器人 + 后端服务」的传统方案，CLI 更适合个人/小团队的快速场景

参考答案：本质是为不同消费者优化不同的接口粒度。

• Shortcuts（+ 前缀）——目标用户是 AI Agent 和懒得查文档的人类。它把高频操作打包成一个带智能默认值的命令，参数最少、输出结构化、错误信息带「下一步建议」。例如 lark-cli calendar +agenda 默认查今天、按时间排序、人类可读输出。
• API Commands——目标用户是写脚本的开发者。它由飞书 OpenAPI 元数据自动生成，命令名、参数和官方 API 一一对应，适合需要精确控制的自动化场景。
• Raw API——目标用户是需要调用所有 2500+ 接口、含最新 beta 接口的开发者。本质是 curl 的语义封装，给你完全的控制权，但你要自己处理一切细节。

设计哲学有三点值得别的官方 CLI 借鉴：

1. 不要假设一个抽象层级能服务所有人。Agent 要的是「告诉我能做什么、参数怎么填」，开发者要的是「让我精准调任何接口」。把它们硬塞进一层，结果是 Agent 嫌复杂、开发者嫌包装太多。
2. Agent 友好层（Shortcuts）值得专门为 Agent 投入。命名、错误信息、--help 输出都按「让模型一次读懂」标准做，这部分投入会直接转化为 Agent 调用成功率。
3. API 自动生成层（API Commands）能让 CLI 始终跟得上服务端 API。手写命令的 CLI 永远落后于 API 演进，自动生成则可以做到「服务端发布新接口当天 CLI 就有」。

这套思路对 GitHub gh CLI、Notion CLI、Linear CLI 都有借鉴价值——2026 年开始，「为 Agent 重做的官方 CLI」基本都在朝这个三层结构收敛。