飞书多维表格 使用方式与典型场景
四、使用方式与典型场景
示例一:用 Python 把外部系统的数据同步进多维表格
import os, time, requests
BASE = "https://open.feishu.cn/open-apis"
APP_ID = os.environ["FEISHU_APP_ID"]
APP_SECRET = os.environ["FEISHU_APP_SECRET"]
APP_TOKEN = "bascnxxxxxxxxxxxx" # 多维表格文件的 app_token
TABLE_ID = "tblxxxxxxxxxxxx" # 数据表 id
def tenant_token() -> str:
r = requests.post(f"{BASE}/auth/v3/tenant_access_token/internal",
json={"app_id": APP_ID, "app_secret": APP_SECRET}, timeout=10)
r.raise_for_status()
return r.json()["tenant_access_token"]
def batch_create(token: str, rows: list):
url = f"{BASE}/bitable/v1/apps/{APP_TOKEN}/tables/{TABLE_ID}/records/batch_create"
headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
# 每批控制在 500 条以内,具体上限以官方文档为准
for i in range(0, len(rows), 500):
payload = {"records": [{"fields": f} for f in rows[i:i + 500]]}
resp = requests.post(url, headers=headers, json=payload, timeout=20)
if resp.status_code != 200:
raise RuntimeError(f"batch_create failed: {resp.status_code} {resp.text}")
print("written", i + len(payload["records"]))
time.sleep(0.3) # 主动限速,避免触发限流
if __name__ == "__main__":
tok = tenant_token()
rows = [
# 字段名必须与表里的字段名逐字一致
{"工单号": "T-20260101-001", "状态": "待处理", "负责人": [{"id": "ou_xxxxxxxx"}], "数量": 3},
{"工单号": "T-20260101-002", "状态": "已关闭", "负责人": [{"id": "ou_yyyyyyyy"}], "数量": 1},
]
batch_create(tok, rows)
这段代码里最容易出问题的是 fields 的结构:文本字段直接给字符串,人员字段是对象数组(内部用 open_id),单选字段给字符串,多选给字符串数组。结构不对不会报「格式错误」这种友好提示,而是整条记录被拒或字段被清空。
示例二:把店铺售后工单做成「填写 → 处理 → 统计」闭环
配置结构(四张表 + 一个仪表盘)
1) 客户表 字段:客户ID(自动编号) 昵称(文本) 手机号(文本) 等级(单选) 首次成交日期(日期)
2) 工单表 字段:工单号(自动编号) 客户(关联 → 客户表) 类型(单选) 状态(单选)
负责人(人员) 创建时间(创建时间) 处理时长(公式)
3) 处理日志表 字段:工单(关联 → 工单表) 动作(单选) 备注(文本) 操作人(创建人)
4) 知识库表 字段:问题关键词(文本) 标准话术(文本) 命中次数(数字)
视图与自动化
- 视图「待我处理」:筛选 状态 != 已关闭 且 负责人 = 当前用户,分组按 类型
- 视图「超时预警」:筛选 处理时长 > 24 小时 且 状态 != 已关闭,按看板展示
- 自动化 A:工单表新增记录 → 给负责人发飞书消息(含工单号与客户昵称)
- 自动化 B:状态改为「已关闭」→ 在群里发一条汇总,并回写客户表「最近服务时间」
- 仪表盘:按类型统计工单量、按负责人统计平均处理时长、超时工单占比
适合与不适合的场景
适合:需要快速搭起一套「有约束、可协作、可统计」的内部流程,比如工单、内容排期、客户跟进、库存盘点、招聘进度;需要让非技术同事自己改字段和视图的场景;需要与飞书群、审批、机器人联动的场景。
不适合:单表记录量特别大且持续增长的场景(应把明细放外部数据库,多维表格只放汇总与看板);需要复杂事务与强一致约束的场景;需要对外开放高并发读写的线上业务库。判断方法很简单:如果这张表需要「每秒几十次写入」,它就不该放在这里。

