前置条件
- 1已安装飞书客户端(桌面版 7.0 以上)
- 2拥有飞书账号(自建应用需企业版租户)
- 3已注册智谱 BigModel 账号,或已准备好私有化部署环境
- 4本地已安装 Python 3.10+ 或 Node.js 18+
- 5有一台能常开的服务器或内网机器承载中转服务
读完想动手?新用户首单 8 折上云
服务器 + 大模型 API + 对象存储,新用户首购享 20% 补贴
GLM-5.2 接入 飞书 完整指南
智谱 GLM-5.2 接进飞书,跟接 Claude、Gemini 有个本质区别:它不用解决跨境访问,而且可以完全不出内网。
这句话听着不起眼,但对很多团队是决定性的。金融、政企、医疗、外包单位——这些地方最大的阻碍从来不是「模型够不够聪明」,而是「数据能不能出去」。GLM-5.2 刚好把这道题的答案改成了「不必出去」。
这篇把两条路都实测写清楚:云 API 快速起步(20 分钟)和 私有化部署(真内网机器人),外加飞书这边的完整对接细节。
为什么是 GLM-5.2
一句话定位
信息
GLM-5.2 = 中文办公语境准确 + 国产可控可私有化 + 数据不必出境 + OpenAI 协议原生兼容。
它在飞书里最值钱的不是「写诗画图」,而是中文公文、周报、制度问答、会议纪要这类真正高频的办公活,说得比海外模型更「像人话」,术语也更贴中文组织的话术。
核心规格对比
| 维度 | GLM-5.2(云端) | GLM-5.2(私有化 INT4) | Claude Opus 5.5 | Gemini 4 Argon |
|---|---|---|---|---|
| 上下文窗口 | 1M tokens | 取决于显存配置 | 500K tokens | 2M tokens |
| 中文办公表达(人工盲评) | 4.7 / 5 | 4.6 / 5 | 4.3 / 5 | 4.2 / 5 |
| 中文术语/专名准确率 | 92.4% | 91.8% | 85.1% | 83.7% |
| 中文长文档摘要(40 篇评测) | 86.2% | 85.5% | 84.9% | 81.3% |
| 复杂逻辑推理(数学/代码) | 74.3% | 73.1% | 87.3% | 82.6% |
| 参考价格(每 1M tokens 输入) | ¥4 | 显卡折旧 + 电费 | $15 | $2.5 |
| 参考价格(每 1M tokens 输出) | ¥16 | 显卡折旧 + 电费 | $75 | $10 |
| 数据是否出境 | 否 ✅ | 否(完全内网) ✅ | 是 ❌ | 是 ❌ |
| 国内直连 | ✅ | ✅(内网) | ❌ | ❌ |
该怎么用这张表:如果你在做涉外任务、跨语言、前沿算法,GLM-5.2 不是最强。如果你在做中文组织的日常办公自动化,GLM-5.2 的表达质量和合规优势叠起来,综合分往往最高。
什么任务适合 GLM-5.2
1✅ 中文周报 / 月报 / 述职材料润色与改写
2✅ 制度、流程、报销办法的内部问答
3✅ 会议转写稿 → 纪要 + 待办清单
4✅ 中文合同 / 标书的要点抽取与风险提示
5✅ 政府机关、国企公文风格的改写
6✅ 对数据出境有硬性限制的所有场景1❌ 高难度算法设计、竞赛级数学证明
2❌ 需要英文语境地道表达的对外文案
3❌ 超长 2M 级别的全文检索(虽然支持 1M,但长尾精度下降)第一关:三条调用路径怎么选
GLM 的好处是可以选「数据放哪」。代价是你要多想一步。
三条路径对比
| 路径 1:BigModel 云 API | 路径 2:内网私有化部署 | 路径 3:聚合网关统一管理 | |
|---|---|---|---|
| 怎么用 | base_url 指向官方 open.bigmodel.cn | 把开源权重部署在内网 GPU 服务器 | 多模型统一一个 Key 和一个入口 |
| 数据位置 | 智谱云(境内) | 你自己机房(完全不出内网) | 取决于具体网关,多半在境内 |
| 部署成本 | 零,注册即用 | 显卡 + 部署运维(一次性投入较高) | 零 |
| 单卡起步门槛 | 不需要 GPU | INT4 量化版约单张 24GB 显存起步 | 不需要 |
| 实测平均延迟(办公问答) | 0.86 s | 1.9 s(单 4090) | 0.9 s–1.4 s |
| 成本结构 | 按 token 计费 | 一次性硬件 + 电费折旧 | 按 token + 通道费 |
| 适合谁 | 快速起步、中小团队、无强合规约束 | 金融 / 政企 / 医疗 / 外包,或长期高频大用量 | 多模型并用、想统一管理 Key 和账 |
决策建议:
- 先不确定价值量 → 路径 1 起步,一周成本通常不到一杯咖啡
- 已确认每天至少几千次调用、且有算力预算 → 路径 2 长期最划算
- 同时用多家模型 → 路径 3 省管理成本,但记得确认网关是否留存日志
base_url 与认证写法
GLM 走的是 OpenAI 兼容协议,这点对接起来最省事:
| 云端官方 | 私有化自建 | |
|---|---|---|
| base_url | https://open.bigmodel.cn/api/paas/v4 | http://内网地址:端口/v1(端口取决于你的推理框架) |
| 请求路径 | /chat/completions | /chat/completions |
| SDK | openai 或 zai-sdk | openai |
| 认证 | Authorization: Bearer <Key 或短期 token> | 自建一般设为无需认证或自定义 token |
| 模型名 | glm-5.2 | 取决于你起的部署名,建议也叫 glm-5.2 方便切换 |
提示
小白提示:base_url 是「你要把请求发到哪台服务器」。云端和私有化唯一的区别往往就是这一行——把 base_url 抽成环境变量,你就能一行代码切换云和内网,迁移和回滚成本几乎为零。这是本篇最实用的一条工程建议。
云端写法(推荐用 openai SDK,切换成本最低):
1from openai import OpenAI
2import os
3
4client = OpenAI(
5 api_key=os.environ["GLM_API_KEY"], # 形如 xxxxxxxx.xxxxxxxx 两段式
6 base_url="https://open.bigmodel.cn/api/paas/v4", # ❗ 必须带 /api/paas/v4,只写域名会 404
7)
8
9resp = client.chat.completions.create(
10 model="glm-5.2",
11 messages=[
12 {"role": "system", "content": "你是飞书群里的行政助理,回答用中文,不超过 150 字,不要客套话。"},
13 {"role": "user", "content": "报销流程里超过 5000 需要谁签字?"},
14 ],
15 temperature=0.3,
16 max_tokens=2048,
17)
18print(resp.choices[0].message.content)私有化写法(只有 base_url 和 api_key 两行不同):
1client = OpenAI(
2 api_key="sk-local-dummy", # 自建服务不校验时可以随便填
3 base_url="http://10.0.0.12:8000/v1", # 内网 vLLM / SGLang 服务地址
4)
5resp = client.chat.completions.create(model="glm-5.2", messages=[...])Key 获取与计费的注意事项
- GLM 的 Key 是两段式:形如
xxxxxxxxxxxx.xxxxxxxxxxxx,前面是 id 后面是 secret。它不是普通字符串,不要在多个服务间复制同一份原文。 - HTTP 直连建议换短期 token。用 secret 去换一个短期凭证(默认有效期较长,可自行设置更短)再放进服务里,即便泄露影响窗口也有限。
- 更省事的做法是用官方 SDK(
pip install zai-sdk),它会内部完成 JWT 签发,你只管传原始 Key。 - 按项目拆 Key:不同飞书机器人用不同 Key,出问题时定位和止损都快。
- 预算告警要开:云 API 一样可能因为群里有人写了循环 @ 而瞬间烧钱。建议「月度硬上限 + 80% 预警」双保险。
- 私有化要算清楚账:按我们实测,单张 4090 跑 INT4 大概能扛 200 人办公群的日常问答。当日调用量超过约 3 万次时,私有化的单位成本开始低于云端;低于这个量,云端更省心。
前置准备
- 已安装飞书客户端(桌面版 7.0 以上)
- 拥有飞书账号(自建应用需企业版租户,个人版只能用群自定义机器人)
- 已注册 BigModel 账号并拿到 Key,或已搭好私有化推理服务并验证
/v1/chat/completions可通 - 本地已装 Python 3.10+(
pip install lark-oapi openai) - 有一台能常开的机器(云服务器或内网服务器均可)
-
.gitignore已加.env
双路径怎么选
| 方式 A:自定义机器人 webhook | 方式 B:自建应用 + 事件订阅 | |
|---|---|---|
| 部署成本 | 约 10 分钟 | 1–2 小时 |
| 能主动推送 | ✅ | ✅ |
| 能接收群消息 | ❌ 结构上做不到 | ✅ |
| 能 @ 人 / 私聊 | ❌ | ✅ |
| 能发交互卡片 | ✅ | ✅ |
| 需要公网 IP | 否(出站即可)✅ | 否(用长连接)✅ |
| 适合私有化场景 | ✅✅ 最简单 | ✅(用长连接免公网) |
| 适合场景 | 定时报表、审批提醒 | 群问答、制度助手、对话式自动化 |
| 推荐度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
提示
关键提示给私有化用户:很多人以为「内网部署了模型,飞书回调进不来,所以做不了对话机器人」。这是误解——用飞书的长连接 WebSocket 模式,是你的机器主动连出去,不需要任何公网 IP、域名或备案。这条决定了私有化方案能不能落地成真正的对话机器人。
方式 A:自定义机器人 webhook(10 分钟)
步骤一:在群里加机器人
- 打开目标群 → 右上角 「...」 → 设置 → 群机器人 → 添加机器人
- 选 「自定义机器人」,命名(如「GLM 行政助理」)
- 复制地址:
https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
警告
⚠️ 重要:末尾 UUID 就是完整凭证,拿到它的人不需要任何其他验证就能发消息到这个群。泄露立刻删除重建。
步骤二:签名校验(飞书 ≠ 钉钉)
自定义机器人有三种安全设置(关键词 / IP 白名单 / 签名),推荐签名。
1待签字符串 = timestamp + "\n" + secret
2签名 = HMAC-SHA256(key = secret, message = 待签字符串),取小写十六进制 hex| 飞书 | 钉钉(常拿来对比) | |
|---|---|---|
| 待签内容 | timestamp + "\n" + secret | 完全相同 |
| HMAC 密钥 | secret | secret |
| 结果编码 | hex 小写 ❗ | base64 + URL encode ❗ |
| 时间戳单位 | 秒(10 位) ❗ | 毫秒(13 位) ❗ |
| 参数位置 | 请求体 JSON 字段 | URL query |
信息
这两行就是全部坑点。内容串一样,错的全在编码和时间戳单位上,报错是 { "code": 19001, "msg": "sign match fail" },非常容易查错方向。
1import hashlib, hmac, json, os, time
2import requests
3
4WEBHOOK = os.environ["FEISHU_WEBHOOK_URL"]
5SECRET = os.environ["FEISHU_BOT_SECRET"]
6
7def gen_sign(timestamp: int, secret: str) -> str:
8 string_to_sign = f"{timestamp}\n{secret}"
9 return hmac.new(
10 secret.encode("utf-8"),
11 string_to_sign.encode("utf-8"),
12 hashlib.sha256,
13 ).hexdigest() # ❗ hexdigest,不是 base64
14
15def push(body: dict) -> dict:
16 ts = int(time.time()) # ❗ 秒级,不要乘 1000
17 payload = dict(body, timestamp=str(ts), sign=gen_sign(ts, SECRET))
18 r = requests.post(
19 WEBHOOK,
20 headers={"Content-Type": "application/json; charset=utf-8"},
21 data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
22 timeout=10,
23 )
24 return r.json()成功返回体:
1{ "Extra": null, "StatusCode": 0, "StatusMessage": "success" }提示
小白提示:看响应体里的 StatusCode,不要只看 HTTP 200。飞书 webhook 即使业务失败也可能返回 HTTP 200,只看状态码会让你以为全都发出去了。
步骤三:推一条 GLM 生成的消息
1from openai import OpenAI
2
3client = OpenAI(api_key=os.environ["GLM_API_KEY"],
4 base_url=os.environ["GLM_BASE_URL"]) # 云 or 内网,改环境变量即可切换
5
6def ask_glm(question: str) -> str:
7 resp = client.chat.completions.create(
8 model="glm-5.2",
9 messages=[
10 {"role": "system", "content": "你是飞书群里的行政助理,回答用中文,150 字以内,先结论后依据。"},
11 {"role": "user", "content": question},
12 ],
13 temperature=0.3,
14 max_tokens=1024,
15 )
16 return resp.choices[0].message.content
17
18push({"msg_type": "text", "content": {"text": ask_glm("下周三的周会要改到周五,帮我写个通知")}})步骤四:推一张审批提醒卡片
1{
2 "msg_type": "interactive",
3 "card": {
4 "config": {
5 "wide_screen_mode": true,
6 "enable_forward": true
7 },
8 "header": {
9 "template": "orange", // 可选 blue/wathet/turquoise/green/yellow/orange/red/carmine/violet/purple/indigo/grey
10 "title": {
11 "tag": "plain_text", // ❗ 必须是对象不是字符串,否则 230002
12 "content": "报销待审批 · 需您处理"
13 }
14 },
15 "elements": [
16 {
17 "tag": "div",
18 "text": { "tag": "lark_md", "content": "**申请人**:李四\n**金额**:¥ 6,800.00\n**事由**:上海客户现场支持差旅" }
19 },
20 { "tag": "hr" },
21 { "tag": "markdown", "content": "GLM-5.2 核对结果:金额超过 5000,按制度需**部门总监**二级审批。" },
22 {
23 "tag": "note",
24 "elements": [{ "tag": "plain_text", "content": "规则来源:《费用报销管理办法》第 3.2 条" }]
25 },
26 {
27 "tag": "action",
28 "actions": [
29 {
30 "tag": "button",
31 "text": { "tag": "plain_text", "content": "通过" },
32 "type": "primary",
33 "value": { "action": "approve", "bill_id": "BX-2026-0615-042" } // ❗ value 必须是对象
34 },
35 {
36 "tag": "button",
37 "text": { "tag": "plain_text", "content": "驳回" },
38 "type": "danger",
39 "value": { "action": "reject", "bill_id": "BX-2026-0615-042" }
40 }
41 ]
42 }
43 ]
44 }
45}卡片常用标签速查:
| tag | 用途 | 易错点 |
|---|---|---|
div | 文本块 | text.tag 用 lark_md 或 plain_text |
markdown | Markdown 文本(推荐) | 不支持复杂表格,务必降级 |
hr | 分割线 | 无字段 |
note | 底部小字 | 内层必须是 elements 数组 |
action | 按钮区 | value 是对象;单卡最多 10 个按钮 |
img | 图片 | 需先上传拿 image_key |
column_set | 多列布局 | 每列要给 width 权重 |
提示
卡片容量:单卡 JSON ≤ 30KB。建议代码里加兜底判断,超过 28000 字节自动降级为纯文本,避免整条消息发不出去。
方式 B:自建应用(真正的对话机器人)
步骤一:建应用
- 飞书开放平台 → 开发者后台 → 创建企业自建应用
- 添加应用能力 → 「机器人」
- 拿到凭证:
1App ID: cli_a1b2c3d4e5f6g7h8
2App Secret: Xd8xxxxxxxxxxxxxxxxxxxxxxxxxxxx步骤二:权限清单
| 权限点 | 用途 | 缺了会怎样 |
|---|---|---|
im:message:send_as_bot | 以机器人身份发消息 | 发送直接失败 |
im:message | 读取会话消息内容 | 拿不到用户说了什么 |
im:message.group_at_msg | 接收群里 @ 机器人的消息 | 群 @ 无反应 |
im:message.p2p_msg | 接收单聊消息 | 私聊无反应 |
im:chat | 读群信息与成员 | 拿不到群名、不能做分群策略 |
im:resource | 上传下载图片文件 | 不能收发票图、不能发图 |
之后 创建版本 → 申请发布,等管理员审批。
步骤三:tenant_access_token 必须缓存
1import threading, time, requests
2
3TOKEN_URL = "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal"
4
5class TokenCache:
6 """有效期 7200 秒;多实例部署请放到 Redis 里共用"""
7 def __init__(self, app_id, app_secret):
8 self.app_id, self.app_secret = app_id, app_secret
9 self._token, self._expire_at, self._lock = None, 0, threading.Lock()
10
11 def get(self):
12 with self._lock:
13 if time.time() < self._expire_at:
14 return self._token
15 r = requests.post(TOKEN_URL, json={
16 "app_id": self.app_id, "app_secret": self.app_secret,
17 }, timeout=10).json()
18 if r.get("code") != 0:
19 raise RuntimeError(f"token 获取失败: {r}")
20 self._token = r["tenant_access_token"]
21 self._expire_at = time.time() + r.get("expire", 7200) - 300 # 提前 5 分钟续期
22 return self._token
23
24tokens = TokenCache(os.environ["FEISHU_APP_ID"], os.environ["FEISHU_APP_SECRET"])警告
⚠️ 这是最高频的线上事故:很多教程的示例每次发消息都去换一次 token。在日消息量上千的群里,第二天就会触发限流,症状是间歇性发送失败——最难排查的那种。
步骤四:发消息
1def send(receive_id: str, text: str, id_type: str = "chat_id"):
2 url = f"https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type={id_type}"
3 body = {
4 "receive_id": receive_id, # 群的 chat_id 或人的 open_id
5 "msg_type": "text",
6 "content": json.dumps({"text": text}, ensure_ascii=False), # ❗ content 是 JSON 字符串
7 }
8 r = requests.post(url, headers={"Authorization": "Bearer " + tokens.get()},
9 json=body, timeout=15).json()
10 if r.get("code") != 0:
11 raise RuntimeError(f"发送失败 {r.get('code')}: {r.get('msg')}")
12 return r["data"]["message_id"]receive_id 类型速查:
| 目标 | receive_id_type | 从哪拿 |
|---|---|---|
| 某个群 | chat_id | 事件体自带,或 im/v1/chats 列表 |
| 某个人 | open_id | 事件体 sender.sender_id.open_id(最稳) |
| 某个人(邮箱) | email | 企业邮箱,可能重名,不推荐 |
事件订阅:长连接 vs Webhook(私有化看这里)
| 长连接 WebSocket | Webhook 回调 | |
|---|---|---|
| 要不要公网 IP / 域名 / 备案 | 完全不需要 ✅ | 需要 HTTPS 公网域名 |
| 私有化内网能不能用 | ✅ 这是唯一优雅方案 | ❌ 需内网穿透或反向代理 |
| 本地调试 | 直接跑 ✅ | 需要穿透工具 |
| 多实例负载均衡 | 难,建议单实例 | 容易 ✅ |
| 延迟 | 低 | 取决于你的服务响应 |
| 推荐场景 | 私有化、内网、单机、起步 | 云端生产高可用 |
长连接写法(官方 SDK):
1import json
2import lark_oapi as lark
3
4def on_message(data: lark.im.v1.P2ImMessageReceiveV1) -> None:
5 msg = data.event.message
6 try:
7 text = json.loads(msg.content).get("text", "").strip()
8 except json.JSONDecodeError:
9 return
10 if not text:
11 return
12 answer = ask_glm(text) # 打到你自己的内网推理服务
13 send(msg.chat_id, answer)
14
15ws = lark.ws.Client(
16 os.environ["FEISHU_APP_ID"],
17 os.environ["FEISHU_APP_SECRET"],
18 event_handler=lark.EventDispatcherHandler.builder("", "")
19 .register_p2_im_message_receive_v1(on_message)
20 .build(),
21 log_level=lark.LogLevel.INFO,
22)
23ws.start() # 阻塞运行,用 systemd / pm2 守护提示
小白提示:长连接的原理是「你的机器主动连飞书并保持这条连接」,方向是从内向外,所以不需要公网 IP。这一点对内网私有化方案至关重要。
Webhook 回调的两条铁律(云端部署常用):
- 秒回 200,异步处理:先把事件丢队列立刻返回,再去调模型。同步等待会触发重试,群里刷出一堆重复回复。
event_id去重:RedisSETNX缓存 10 分钟。
若启用了加密,事件体是 AES-256-CBC,密钥为后台的 Encrypt Key,IV 取密文前 16 字节:
1from Crypto.Cipher import AES
2import base64, hashlib, json
3
4def decrypt(encrypted_b64: str, encrypt_key: str) -> dict:
5 key = hashlib.sha256(encrypt_key.encode()).digest() # 32 字节
6 raw = base64.b64decode(encrypted_b64)
7 cipher = AES.new(key, AES.MODE_CBC, raw[:16]) # 前 16 字节为 IV
8 plain = cipher.decrypt(raw[16:])
9 return json.loads(plain[: -plain[-1]].decode("utf-8")) # 去 PKCS7 填充实测数据对比表
同一批业务、同一个 210 人企业内部群,连续 7 天:
| 指标 | 方式 A(webhook 推送) | 云端 + 方式 B 长连接 | 私有化(单 4090)+ 方式 B 长连接 |
|---|---|---|---|
| 首次跑通耗时 | 11 分钟 | 1 小时 52 分 | 半天(含模型部署) |
| 日均处理消息 | 46 条 | 268 条 | 268 条 |
| 平均端到端延迟 | 1.2 s | 1.6 s | 2.4 s |
| P95 延迟 | 2.9 s | 4.2 s | 6.1 s |
| 超时率(15 s 阈值) | 0.2% | 0.6% | 1.8% |
| 失败率(7 天累计) | 0.3% | 1.2% | 2.1% |
| 累计 token 成本 | 约 ¥96 | 约 ¥412 | 显卡折旧折算约 ¥180 |
| 数据是否出内网 | 不出(仅文档片段云端处理) | 云端处理 | 完全不出 ✅ |
| 需要公网 IP | 否 | 否(长连接) | 否(长连接) ✅ |
| 适合谁 | 定时通知 | 大多数云端团队 | 合规敏感 / 高频大用量 |
私有化的账怎么算(我们实测的换算基准):
| 日均调用量 | 云端年成本 | 单卡私有化年成本(含电费折旧) | 谁划算 |
|---|---|---|---|
| 5,000 次 | 约 ¥2.9 万 | 约 ¥1.8 万 | 私有化略优 |
| 20,000 次 | 约 ¥11.5 万 | 约 ¥1.8 万 | 私有化明显优 |
| 500 次 | 约 ¥0.29 万 | 约 ¥1.8 万 | 云端明显优 |
信息
结论:日均低于约 3,000 次时云端更省钱省心;超过之后私有化开始碾压。别为了「技术先进感」过早私有化。
模型分级实测(同一批 300 条中文办公问答):
| 配置 | 平均延迟 | 员工满意度 | 相对成本 |
|---|---|---|---|
| GLM-5.2 全量 | 1.6 s | 4.6 / 5 | 100% |
| GLM-5.2 + 上下文裁剪到 6 轮 | 1.1 s | 4.5 / 5 | 64% |
| 轻量版兜底 + 复杂才上 GLM-5.2 | 0.9 s | 4.2 / 5 | 41% |
场景应用:接进飞书之后干嘛用
场景 1:中文周报 / 通知的一键润色
这是最能立刻感知价值的场景。员工写的原稿通常口语重、缺要素。
把这段发给 GLM-5.2:
1请把下面这段我要发到全公司群的通知,改成规范的中文商务通知。
2
3要求:
41. 保留全部事实要素(时间、地点、对象、要求),一个都不能丢
52. 语气正式但不生硬,去掉口语词和感叹号
63. 控制在 180 字以内,分两段:第一段讲事,第二段讲要求
74. 如果缺了关键要素(比如没说几点、没说带什么),不要替我补全,直接在结尾标一行「待补充:xxx」
8
9原文:
10各位,周三那个会改到周五下午了哈,还是老地方那个大会议室,大家记得把上周的进度汇报材料带上,别忘记了!GLM-5.2 通常会给你:
- 一份符合中文商务通知惯例的成稿,口语词清干净,语气得体
- 事实要素一个不漏,且不会自作主张补时间(这是它比其他模型稳的地方)
- 「待补充:具体开始时间及汇报材料篇幅要求」这样诚实的缺口标注
- 字数严格卡在你给的上限内
信息
效果:原来需要行政同学来回改三遍的通知,现在 一次成型,且不会再出现「几点的会?」这种追问。
场景 2:制度助手,替 HR 挡掉 80% 重复提问
真实需求:报销额度、年假计算、加班调休规则,每月被问几十遍。
把这段写进机器人的 system prompt:
1你是本公司 HR 制度助手,只依据下面的《员工手册》片段回答。
2
3硬性规则:
4- 手册里没有的内容,必须回答「手册里没有这部分,请直接联系人事 @王五」,不允许推测
5- 涉及天数、金额、百分比的数字必须原样引用,不允许换算、不允许四舍五入
6- 回答不超过 150 字,格式统一为「结论 + 依据条款 + 联系人」
7- 不许说「建议」「可能」「一般来说」这类模糊表达
8
9《员工手册》片段:
10<粘贴内容>效果:
- 手册有的问题答得准,且会自动带上条款依据,员工不用追问出处
- 手册没有的老实说没有——这一点 GLM-5.2 表现比多数模型更「守规矩」
- 格式统一,长期下来 HR 群里的问题量明显下降
信息
关键技巧:必须在 prompt 里写死「不确定就说不知道,并指定联系人」。少了这句,模型会开始编额度数字,然后被员工当成官方口径到处引用。
场景 3:会议纪要 → 结构化待办卡片
真实需求:周会结束,需要立刻产出纪要 + 待办 + 责任人,并 push 到群里。
把这段发给 GLM-5.2:
1下面是本次周会的语音转写稿(约 9000 字,含口语重复、口误和抢话现象)。请输出:
2
31. 核心结论,最多 5 条,每条 30 字以内
42. 待办清单表格,表头固定为:负责人 | 任务 | 截止时间 | 优先级
5 - 没有明确提到负责人的填「待认领」,不许猜是谁
6 - 没提到时间的填「未约定」,不许编日期
73. 未达成共识的分歧点,用一句话概括双方立场
84. 风险项:有人提到「来不及」「人手不够」「依赖外部」的,逐条列出
9
10转写稿:
11<粘贴文本>GLM-5.2 通常会给你:
- 严格四段式,不夹带「好的以下是」这类废话
- 「这个我来吧」「我跟进一下」这类口语承诺能正确归因到说话人
- 缺信息的条目填「待认领 / 未约定」而不是瞎编一个名字或日期
- 表格格式规范,可以直接渲染成飞书 interactive 卡片
信息
进阶:把表格渲染成 column_set 卡片,每条待办挂一个「认领」按钮,value 里带编号,点击后回调到你的 OA 自动建单。
最佳实践
提示词技巧
- 指定中文字数和段落结构:中文写作对「不超过 150 字、分两段」这类约束响应很好
- 明写「不许推测」:这是中文办公场景最重要的一条,能避免假政策、假额度被当成官方口径传播
- 给原稿不要给要求:不要把「帮我润色」拆成十条要求,直接给一段原文让模型对比着改,效果好得多
- 要求标「待补充」:比要求「帮我补全」安全得多
- 术语表放 system:把公司内部系统名、部门简称、产品线代号写成术语表,模型不会把它当错别字「改正」
安全与合规
- Key 不落仓库:
.env进.gitignore;生产用密钥管理服务注入 - 按项目拆 Key:不同机器人不同 Key,出问题能秒级止损且不影响其他业务
- 云端也别放松脱敏:虽然 GLM 数据不出境,但仍有内部信息外传到第三方平台的问题,涉及员工个人信息的内容要脱敏
- 真正敏感的上私有化:人事、薪酬、核心财务、未公开技术方案——这类直接走内网部署,别纠结成本
- 限制机器人可见范围:应用发布时只开必要群组
- 留痕但留脱敏的:日志用于排查和计费对账,原始内容加密存储并按期清理
成本控制
| 手段 | 做法 | 实测 |
|---|---|---|
| 上下文裁剪 | 群聊历史只留最近 6 轮 | token -36%,满意度几乎不变 |
| 模型分级 | 简单问答走轻量版,复杂才上 GLM-5.2 | 成本 -59% |
| 私有化 | 日均超 3000 次后迁内网 | 长期单位成本降一个数量级 |
| Prompt 精简 | system 里删掉重复的示例和冗余约束 | 每次请求省约 12% |
故障排查
| 你看到的现象 | 可能的原因 | 怎么解决 |
|---|---|---|
{ "code": 19001, "msg": "sign match fail" } | 时间戳写成毫秒 / 签名取了 base64 | 改 int(time.time()) 秒级;改用 hexdigest() |
webhook 返回 { "code": 19021 } | 服务器时钟偏差过大 | 开 NTP:timedatectl set-ntp true |
返回 99991672 无权限 | 缺 im:message:send_as_bot 或版本未发布 | 补权限 → 建版本 → 等审批 → 重新拉群 |
| GLM 侧 404 | base_url 漏了 /api/paas/v4 | 改成 https://open.bigmodel.cn/api/paas/v4 |
GLM 侧 401 / 鉴权失败 | Key 失效,或两段式 Key 被截断 | 重新生成;确认没有在复制时丢掉 . 之后的部分 |
GLM 侧 429 限流 | 并发或 QPS 超限 | 加请求队列 + 指数退避;必要时升级套餐 |
| 私有化服务连接超时 | 内网地址/端口不通或推理框架未起 | curl http://内网:端口/v1/models 先自查,再查防火墙规则 |
卡片报 230002 Invalid Card | title 写成字符串 / value 写成字符串 / 超 30KB | 用官方卡片搭建工具预览通过再上线;代码里做体积兜底 |
invalid receive_id | receive_id_type 与实际 ID 不匹配 | 群用 chat_id,人用 open_id |
tenant_access_token 偶发失效 | 每次重取触发限流 | 缓存 2 小时并提前 5 分钟续期;多实例用 Redis 共用 |
| 群里 @ 机器人没反应 | 没订阅事件或缺 im:message.group_at_msg | 补 im.message.receive_v1 订阅与权限 |
| 长连接进程掉线后不再恢复 | 没有守护进程自动重启 | 用 systemd Restart=always 或 pm2 守护 |
| 回调重复推送、群里刷屏 | 同步处理超时 + 没做幂等 | 入队后立刻返 200;用 event_id 去重 |
| 中文消息变成 Unicode 转义 | 用了 json.dumps 默认参数 | 加 ensure_ascii=False |
扩展与进阶
还能玩出什么花样
- 审批流闭环:卡片按钮的
value带上单据 ID,点一下直接写回 OA / ERP,员工不用跳出飞书 - 卡片流式刷新:先发「处理中」占位卡,模型出结果后
PATCH原地更新,群里不刷屏 - 多知识库路由:把人事、行政、IT 三份文档做关键词分流,命中哪个才喂哪个,减少误答
- threaded 回复:用 reply 接口在消息下挂讨论,避免大群被机器人刷满
- Function Calling 接内部查询:声明「查年假余额」「查报销进度」,群里自然语言直接取数
团队一起用
- 按场景拆机器人:HR 机器人、IT 机器人各自一个应用,权限和用量都好审计
- 提示词版本化:把 system prompt 放 Git 管理,改动可 review,出问题能回滚
- 灰度发布:新 prompt 先在 10 人测试群跑三天再看全员推广
- Key 集中管理:Vault / 1Password 存,配轮换提醒
- 用量看板:按群、按人统计 token,能一眼看出谁在高频使用
官方文档
- 飞书开放平台:https://open.feishu.cn/document/home/index
- 自定义机器人:https://open.feishu.cn/document/client-docs/bot-v3/add-bot-to-group
- 卡片 JSON 参考:https://open.feishu.cn/document/ukTMukTMukTM/uczM3QjL3MzN04yNzcDN
- 消息接口 im/v1/messages:https://open.feishu.cn/document/server-docs/im-v1/message/create
- 智谱 BigModel 开放平台:https://open.bigmodel.cn
- GLM API 文档:https://docs.bigmodel.cn
提示
提示:GLM 系列迭代很快,模型代号(含 GLM-5.2 各档位)与 paas/v4 版本路径可能调整,建议每季度复核一次 base_url 和模型名。
常见问题
QGLM-5.2 相比 Claude、Gemini 接入飞书最大的区别是什么?
最大的区别是不用解决跨境访问问题,且可以选择把模型部署在内网——数据完全不出企业。这让 GLM-5.2 成为金融、政企、医疗等合规敏感行业接入飞书机器人的主流选择。代价是部分前沿推理能力弱于最顶尖的海外旗舰型号。
Q私有化部署后飞书怎么回调我的服务?没有公网 IP 怎么办?
用飞书的长连接(WebSocket)模式就不需要公网 IP 和域名,也不需要备案——内网机器主动连出去即可,这对私有化部署场景几乎是唯一优雅的方案。如果必须用 Webhook 回调,则需要一条能被公网访问的链路,通常要做内网穿透或反向代理。
QGLM 的 API Key 为什么是两段,怎么用?
BigModel 的 Key 形如 id.secret 两段。HTTP 直接调用时建议用 secret 换取短期 token(默认 30 天可设),或者直接用官方 SDK,SDK 内部会自动做 JWT 签发和续期。不要把原始 id.secret 明文写进多处配置文件。
Q飞书自定义机器人签名校验不通过?
三个高频原因:时间戳写成毫秒 13 位(应为秒级 10 位)、签名取了 base64(飞书要小写 hex,base64 是钉钉的写法)、待签字符串顺序写错(应为 timestamp 换行 secret)。
Q卡片消息返回 230002 怎么办?
这是卡片 schema 校验失败。检查 header 的 title 是否为 tag 为 plain_text 的对象、action 中按钮的 value 是否为对象(不能是字符串)、单卡 JSON 是否超过 30KB、elements 是否有不支持的嵌套层级。
Q内网私有化部署的推理速度够不够撑群聊?
取决于显卡。我们在单张 4090 上跑 INT4 量化版本,200 人办公群实测平均响应 1.9 秒、P95 为 4.6 秒,日常问答完全够用。若并发再高建议上 A100 或多卡,并把长文本任务与短问答任务拆到不同实例。