FEISHU DEVELOPMENT · GRANULARITY COMPARISON

同一个任务
四种打开方式

开发者在接入飞书等平台时,常纠结于用 API、CLI、MCP 还是 SKILL。用同一个真实任务走一遍四种方式,帮你建立选型直觉。

B站评论 飞书表格 群通知

最细颗粒度

每次调用只做一件事,一个 HTTP 请求 = 一个原子操作。

1创建电子表格1x API
POST /open-apis/sheets/v3/spreadsheets Authorization: Bearer t-xxx { "title": "B站视频评论 - BV1ooDyBmE6v" } → 返回 spreadsheet_token
2写入表头1x API
PUT /open-apis/sheets/v2/spreadsheets/{token}/values Range: Sheet1!A1:H1 Body: [["序号","用户名","等级","评论内容","点赞数","发布时间","回复数","是否一级"]]
3批量写入数据1x API
PUT /open-apis/sheets/v2/spreadsheets/{token}/values Range: Sheet1!A2:H51 Body: [[1,"lmpker",6,"不错",79,"2026/04/12",8,"yes"], ...]
4设置列宽1x API
PUT /open-apis/sheets/v2/spreadsheets/{token}/dimension_range Body: {"dimension": {...}, "dimensionProperties": {"fixedSize": 20}}
5获取群聊信息1x API
GET /open-apis/im/v1/chats?page_size=20&query_type=group → 返回 chat_id
6发送飞书消息1x API
POST /open-apis/im/v1/messages?receive_id_type=chat_id Body: { "receive_id": "oc_xxxx", "msg_type": "interactive", "content": "{...卡片消息 JSON...}" }
6
API CALLS
0
AI TOKEN COST
×处理 OAuth 鉴权 token 刷新
×手动管理 spreadsheet_token、sheet_id、chat_id 等中间状态
×拼接请求 URL、构造 JSON body、解析响应
×处理分页、限流、错误重试

中颗粒度

一条 CLI 命令封装了多次 API 调用 + 状态管理 + 错误处理。

1创建表格并写入数据2x CLI
# +create 内部:创建表格 API + 设置列宽 API lark-cli sheets +create \ --title "B站视频评论 - BV1ooDyBmE6v" \ --headers '["序号","用户名","等级","评论内容","点赞数","发布时间","回复数","是否一级"]' \ --data '[[1,"lmpker",6,"不错",79,"2026/04/12",8,"yes"], ...]' # +append 内部:写入值 API(自动处理分页) lark-cli sheets +append \ --spreadsheet-token "A0StsA30qh..." \ --sheet-id "eb15be" \ --range "A52:H101" \ --values '[[51,...],[52,...],...]'
2发送飞书消息1x CLI
# 内部:查找群聊 API + 发消息 API lark-cli im +send \ --chat-name "产品群" \ --msg "已采集 170 条B站评论,已写入飞书表格"
3
CLI COMMANDS
~0
AI TOKEN COST
不用关心 OAuth token 刷新(lark-cli 内置处理)
不用手动拼接 URL 和 JSON body(参数直接传)
不用管理中间状态(--spreadsheet-token 传入即可)

粗颗粒度

一个 MCP tool 封装了整个业务流程,AI 只需一次调用。

TTool 定义JSON SCHEMA
{ "name": "bilibili_comments_to_feishu", "description": "采集B站视频评论并写入飞书表格,完成后发送群通知", "parameters": { "bv_id": {"type": "string", "description": "B站视频BV号"}, "limit": {"type": "number", "default": 100}, "notify_chat": {"type": "string", "description": "飞书群名"} } }
AI 调用:一次搞定1x MCP
{ "tool": "bilibili_comments_to_feishu", "input": { "bv_id": "BV1ooDyBmE6v", "limit": 100, "notify_chat": "产品群" } }
1
MCP CALL
5K–30K+
TOKENS / ROUND
Token 隐性成本
MCP 协议要求每轮对话都注入所有已注册 tool 的完整 schema
单个 tool
~200
1 个 MCP Server
20–50 tools
5K–15K tokens
多个 MCP Server
飞书+GitHub+Slack
30,000+ tokens
普通对话上下文
4K–8K tokens
每轮都要重复发送,无论本轮是否调用任何 tool,直接推高 API 费用

编排层

SKILL 不是接口,不是协议,而是一份操作手册。告诉 AI 如何组合 CLI / MCP / API 完成任务。

SKILL: bilibili-comment-crawler ├── SKILL.md (操作手册) │ ├── 采集:python3 scripts/bilibili_comments.py --cookie ... │ ├── 创建表格:lark-cli sheets +create --title "..." --headers ... │ └── 通知群聊:lark-cli im +send --chat-name "..." --msg "..." ├── scripts/bilibili_comments.py (Python 采集脚本) │ └── 内部调用 curl → B站 API (3–6 次 HTTP 请求) └── cookie.json (配置文件)
0
IDLE TOKEN COST
~2K
LOADED ONCE
未触发时不消耗 Token,只在匹配任务时加载 SKILL.md 到上下文
!依赖 AI 的理解和执行能力,复杂编排可能执行出错或漏步骤
!SKILL.md 需要人工维护,底层 CLI/API 接口变了 SKILL 也要更新

总览

以"B站评论 → 飞书表格"这个任务为例

方式 调用次数 AI 开销 灵活性 安全性 稳定性 开发成本
API 6 次 0 最高 最低 最低
CLI 3 条 ~0
MCP 1 次 5K–30K+ 最高 最高
SKILL 1 次 ~2K 最高 取决于底层 取决于底层

SKILL 的组合模式

SKILL 是编排层,它组合底层的能力。同一个任务可以用不同的底层实现。

SKILL = 多个 API
人工写每个 curl 调用,最灵活最累
SKILL = API × N
SKILL = 1 个 MCP
直接调一个 MCP tool,最省事
SKILL = MCP
混合模式
灵活操作走 CLI,权限操作走 MCP
SKILL = CLI + MCP
嵌套编排
高级 SKILL 编排多个子 SKILL
SKILL = SKILL + SKILL

如何选择

一句话:默认从 SKILL + CLI 开始,除非有明确理由选其他。

默认推荐:SKILL + CLI — SKILL 编排,CLI 执行。
场景推荐原因
AI 需要自由组合工具CLI管道符组合,非预置流程
企业部署,权限控制MCPtool 白名单,预置流程
多步复杂工作流SKILL + CLISKILL 编排,CLI 执行
偶尔调用一个固定能力MCP一次调用搞定
共享给团队使用SKILL一份文档 + 脚本 = 完整能力包
CORE METAPHOR
🧱
API
砖块
🏗
CLI
预制板
🏠
MCP
精装房
📋
SKILL
施工方案
砖块最灵活但最累,精装房最省事但最难改。
施工方案指挥用哪些材料、按什么顺序组装——可以同时用砖块和预制板。