企业官网建设流程全解析

1. 为什么非要把飞书和腾讯会议打通：日常办公里的割裂感

前阵子公司内部做了一套小工具：在飞书群里@机器人，填写会议主题和时间，机器人自动调用腾讯会议API创建线上会议，再把入会链接、会议号、密码全部推回群里。会议结束之后，腾讯会议的录制文件和转写纪要也会自动出现在飞书群里。这套飞书与腾讯会议的对接方案不复杂，但跑通之后，行政和跨部门协作的效率提升是肉眼可见的。今天我把对接过程中的关键细节、凭证获取、API调用逻辑和踩过的坑整理出来，给正在做类似事情的朋友一个参考。

1.1 两套系统并存的真实痛点：人肉转发与日程割裂

大多数公司里，日常办公用的是飞书，视频会议用的是腾讯会议。这两套系统本身都很成熟，但它们之间没有天然的联动通道。于是出现了很典型的场景：

运营同学要在上午10点开一个跨部门需求对齐会，他得先去腾讯会议客户端手动发起会议，等会议创建成功，把入会链接复制出来，再切到飞书群里粘贴发送。如果参会的还有其他部门的人，还要挨个提醒“记得点链接”“密码在群里”。这个流程看着不复杂，但每天都做，就是在消耗大家的精力。

更麻烦的是日程割裂。飞书日历里标记了“10:00-11:00 需求对齐”，但腾讯会议里的会议日程和飞书日历完全是两套体系。上午十点的会，下午两点又有一个，撞车、忘记参会、找不到入会链接的情况非常普遍。日常办公的核心信息散落在不同系统里，本质上是因为“发起会议”和“通知参会”这两个动作被拆开了。

1.2 打通之后的一天：自动化会议全流程是什么样的

对接之后，整个流程变成了这样：

早上9点30分，运营同学在飞书群里@自动会议机器人，机器人回复一张交互卡片。卡片上有会议主题、开始时间、时长、参会人这些输入项。填完提交，机器人后端调用腾讯会议的创建会议接口，拿到会议号、入会链接和密码，然后直接在群里发一条带操作按钮的卡片消息。其他同事点开卡片，一键就能把会议加到自己的飞书日历里。

下午两点，会议结束。腾讯会议的服务端触发一个Webhook事件，回调服务收到消息后，通过API拉取这场会议的录制文件和智能转写纪要，再把“录制已生成，点击查看”的卡片推到飞书群里。全程没有任何人手动复制链接。

这套流程跑通之后，群里所有会议信息都是结构化、可检索的。哪天有人问“昨天的评审会链接还有吗”，在飞书群里搜一下就出来了，不用再去翻聊天记录。

1.3 谁适合参考这套对接方案

如果你符合下面任一情况，这篇文章应该对你有帮助：

• 公司同时使用飞书和腾讯会议，日常需要反复在两个系统之间切换。
• 你是公司飞书管理员或IT，想用低成本方式打通两个平台的会议场景。
• 你在做企业内部自动化，比如用飞书机器人对接第三方SaaS，需要对开放平台API、Token、Webhook有完整的认知。
• 你想了解腾讯会议开放平台的API调用方式，包括签名算法、权限申请、事件回调这些基础能力。

如果公司只用飞书的视频会议，或者只用腾讯会议自己的日历体系，那这套方案就不太需要。但只要是两套系统并存，这个对接的投入产出比非常高。接下来我从两侧开放平台的环境准备开始，一步步展开。

2. 对接前夜：两侧开放平台的账号体系、凭证与权限清单

做这类对接，最耗时间的往往不是写代码，而是把两个开放平台的“地基”摸清楚。腾讯会议侧和飞书侧各有一套账号体系、应用体系、权限体系和凭证体系，任何一环漏了，调试的时候都会非常痛苦。

2.1 腾讯会议开放平台：企业资质、自建应用与三组关键凭证

先说腾讯会议。

腾讯会议的API能力是跟企业版、商业版绑定的，个人免费版没有开放平台入口。先在腾讯会议开放平台（meeting.tencent.com）用企业管理员账号登录，进入“企业管理”或“应用管理”，创建一个“企业自建应用”。

创建完成之后，你会拿到几组关键信息，后面写代码全都要用：

有些接口还会用到企业里的userid，这个userid不是邮箱也不是手机号，而是企业管理员在腾讯会议后台给成员设置的账号ID，调用创建会议接口时要用它来标识“由谁发起会议”。

接下来是权限。腾讯会议的API权限是按接口维度申请的，比如创建会议、查询会议、获取录制文件这些，各自是独立的权限项。在应用详情页里找到“接口权限”，按需申请。这里建议一次把会用到的都申请了，不然后面开发到一半发现某个接口403，又得等管理员审批，很耽误事。

2.2 飞书开放平台：自建应用、机器人能力与事件订阅配置

再看飞书。

飞书的开放平台入口是open.feishu.cn，同样用企业管理员账号登录，创建一个“企业自建应用”。创建后拿到App ID和App Secret，这组凭证对应飞书的应用身份。跟腾讯会议不同的是，飞书的应用默认是没有机器人的，需要手动开启“机器人”能力，并发布应用版本，让企业管理员审核通过。

飞书侧的权限也是按scope管理的。比如要给群里发消息，需要申请im:message相关权限；要接收用户@机器人的消息，需要申请im:message.receive_v1事件权限；如果要读用户信息做展示，还要申请contact:user.base:readonly。

这里有个容易忽略的点：飞书应用开发完成后，必须“创建版本并发布”，发布审核通过后，新权限才会真正生效。我第一次对接时，代码里权限都写好了，但接口一直报“permission denied”，排查半天才发现是应用没有发布新版本，旧版本的权限列表里根本没有我新加的那些scope。

2.3 双端凭证管理：Token的获取方式与安全存放

两侧的凭证加起来，一共四组：腾讯会议的Client ID、Client Secret，飞书的App ID、App Secret。

这些密钥绝对不能写在前端代码、配置文件或Git仓库里。企业内部工具虽然不像对外SaaS那么严格，但如果被有心人拿走，对方可以冒充你的应用去调API、发消息、拉取会议信息。我在项目里直接放到环境变量里，生产环境用密钥管理系统托管，本地开发用一个独立的.env文件，并且这个文件已经加进了.gitignore。

Token获取方式也简单说一句。飞书侧通过POST /open-apis/auth/v3/tenant_access_token/internal接口，用App ID和App Secret换tenant_access_token，有效期2小时。腾讯会议侧的实现方式不太一样，不同API版本用的鉴权方式也有区别，有的用JWT，有的用签名头。我下面讲的都是基于当前主流API版本的签名方式，新项目建议以腾讯会议开放平台最新的“签名鉴权”文档为准。

3. 飞书侧发起会议：机器人指令、交互卡片与腾讯会议API调用

环境准备好之后，进入正题：用户在飞书群里@机器人，机器人拉起一个交互卡片，用户填完信息，后端调用腾讯会议API创建会议，再把会议信息推回飞书群。这一条链路是整个项目的核心。

3.1 事件订阅选长连接还是WebHook：没有公网服务器时的选择

飞书支持两种事件订阅方式：长连接（WebSocket）和WebHook。

长连接模式是飞书专门为没有公网IP的开发者设计的。你的服务主动向飞书的长连接服务发起一个WebSocket连接，飞书把事件通过这个连接推给你。好处是不需要公网回调地址，也不用操心端口暴露，企业内部服务器如果在内网，非常合适。

WebHook模式则需要你提供一个公网可访问的HTTPS回调地址，飞书通过POST方式把事件推过来。两种方式各有利弊：

我这次用的是长连接，因为公司服务器在内网，没有单独暴露公网端口。飞书官方提供了Python、Go、Node的SDK，直接用SDK里的长连接模式，比自己去维护WebSocket连接省心很多。

3.2 交互卡片让“@机器人开会”成为可能

用户在群里@机器人之后，飞书会推送一条im.message.receive_v1事件。事件体里包含消息内容、发送者、以及mentions数组。我们在后端判断：如果消息内容里包含“开会”或“创建会议”之类的关键词，就给用户发一张交互卡片。

卡片的本质是一段JSON，里面可以放输入框、时间选择器、下拉框、按钮。飞书交互卡片的字段体系很成熟，我这里只列一个精简的思路：

• 卡片上放一个“会议主题”输入框、一个“开始时间”时间选择器、一个“会议时长”下拉框、一个“参会人”人员选择器。
• 用户填完后点击“提交”，飞书会向你的服务端推一个card.action.trigger事件，事件体里有用户填写的内容和卡片上定义的value。
• 后端收到提交事件后，把参数整理好，去调腾讯会议创建会议的API。

这里有一个细节：卡片的交互是异步的，用户点完按钮之后，飞书会等你的服务返回一个响应。如果你需要临时更新卡片内容，可以返回一个{"toast": "会议创建中"}，让用户有反馈。真正创建成功之后，再用机器人主动发一条消息到群里。不要试图在按钮回调的同步响应里等腾讯会议API返回，那样很可能导致请求超时。

3.3 创建腾讯会议的核心调用：签名、请求体与响应解析

腾讯会议的API鉴权和大多数开放平台不一样，不是简单的Bearer Token，而是用Client ID和Client Secret对请求做HMAC-SHA256签名。头部需要带：

签名串的拼法以腾讯会议开放平台文档为准。我踩过的坑是：签名时拼的字符串包含请求方法、请求路径、请求体、nonce、timestamp，顺序一点都不能乱。下面是一个简化的Python示例（具体字段以最新文档为准）：

import hashlib import hmac import json import time import uuid import requests CLIENT_ID = "your_client_id" CLIENT_SECRET = "your_client_secret" def build_signature(method, path, body, nonce, timestamp): # 这里以腾讯会议文档约定的拼接顺序为准 message = f"{method}\n{path}\n{body}\n{nonce}\n{CLIENT_ID}\n{timestamp}" signature = hmac.new( CLIENT_SECRET.encode("utf-8"), message.encode("utf-8"), hashlib.sha256 ).hexdigest() return signature def create_meeting(subject, start_time, duration): path = "/v1/meetings" body = { "userid": "your_meeting_userid", "instanceid": 1, "subject": subject, "type": 0, "start_time": start_time, # UTC时间戳（秒） "end_time": start_time + duration * 60, "settings": { "mute_enable": 1 } } body_str = json.dumps(body) nonce = uuid.uuid4().hex timestamp = str(int(time.time())) signature = build_signature("POST", path, body_str, nonce, timestamp) headers = { "X-TC-Key": CLIENT_ID, "X-TC-Nonce": nonce, "X-TC-Timestamp": timestamp, "X-TC-Signature": signature, "Content-Type": "application/json" } resp = requests.post( f"https://api.meeting.qq.com{path}", headers=headers, data=body_str ) return resp.json()

响应里最核心的是meeting_code（会议号）和join_url（入会链接）。这两个字段会用来生成飞书卡片消息。注意meeting_id和meeting_code是两个不同的字段，meeting_id是系统内部的数字ID，meeting_code才是用户在腾讯会议客户端输入的9位会议号，后续查录制、查会议详情时用的是meeting_id，用错的话接口会一直报错。

还有一个容易忽略的点：start_time要求是UTC时间戳，不是本地时间戳。飞书卡片提交上来的时间通常是东八区的本地时间，转成UTC时间戳时要加上8小时的偏移，或者直接用带时区的时间解析。我第一次没注意，创建的会议总是“对不上点”，排查了好久才找到问题。

3.4 会议链接回流：用飞书机器人发一条带操作按钮的消息

腾讯会议创建成功后，后端拿到会议号和入会链接，接下来就是把它变成飞书群里的一条卡片消息。

飞书发消息的API是POST /open-apis/im/v1/messages，receive_id_type可以填chat_id，表示发给群。请求体里的content是一个JSON字符串，不是JSON对象，这个很多新手会踩。下面是一个交互卡片的示例：

{ "msg_type": "interactive", "receive_id": "oc_xxx", "content": "{\"config\":{\"wide_screen_mode\":true},\"header\":{\"title\":{\"tag\":\"plain_text\",\"content\":\"会议已创建\"}},\"elements\":[{\"tag\":\"div\",\"text\":{\"tag\":\"lark_md\",\"content\":\"**会议主题**：需求对齐会\\n**会议号**：123456789\\n**入会链接**：[点击入会](https://meeting.tencent.com/xxx)\"}},{\"tag\":\"action\",\"actions\":[{\"tag\":\"button\",\"text\":{\"tag\":\"plain_text\",\"content\":\"添加到日历\"},\"type\":\"primary\",\"value\":{\"action\":\"add_to_calendar\",\"meeting_id\":\"756311\"}}]}]}" }

卡片里我加了一个“添加到日历”按钮，点击后可以回调到后端，通过飞书日历API创建日程。这样用户在群里看到会议信息，点一下就能把会议同步到自己的日历里，不用再手动复制。

发消息前还要确认一件事：机器人必须已经被拉进目标群。如果机器人不在群里，飞书接口会报错。这个权限不是开放平台的scope，而是群维度的一种“应用成员关系”，拉机器人进群的操作本身在企业版飞书里需要有群管理权限。

4. 腾讯会议回调与飞书推送：会议结束后自动归档的闭环

发消息、创建会议只是整个链路的前半段。真正让这套对接产生价值的是后半段：会议结束后，录制文件和转写纪要自动回流到飞书群。要实现这个效果，靠的是腾讯会议的Webhook能力。

4.1 腾讯会议Webhook：会议生命周期里的关键事件

腾讯会议开放平台支持配置事件回调，企业自建应用创建好后，在应用配置里可以填一个回调URL。事件类型大致有这些：

对我们这个场景，recording.available是最关键的。它会在会议录制转写处理完成后触发，事件体里包含会议ID、录制文件列表等信息。收到这个事件后，后端再调腾讯会议的录制查询接口，获取录制文件的播放地址或下载地址。

配置回调URL的一个前置条件是：你的服务必须能公网访问。如果服务器在内网，可以用内网穿透或者直接把回调服务部署到一台有公网IP的机器上，再通过API网关转发到内网。没有公网环境的话，就只能轮询查询会议状态，但那会对腾讯会议API产生额外请求量，对账也麻烦，不如Webhook来得干净。

4.2 回调服务端验签与事件分发：一个FastAPI最小实现

接收Webhook的代码不复杂，难的是把验签、幂等、重试这些边界情况处理好。

腾讯会议会以POST方式把事件JSON推送到你的回调地址。为了确认请求确实来自腾讯会议，回调请求里通常会带签名校验字段，具体以文档为准。我在服务端用FastAPI写了这样一个最小实现：

from fastapi import FastAPI, Request import json app = FastAPI() @app.post("/webhook/tencent-meeting") async def tencent_meeting_webhook(request: Request): body = await request.body() # 1. 验签，校验请求头中的签名，防止伪造请求 # if not verify_signature(request.headers, body): # return {"code": 401} payload = json.loads(body) event_type = payload.get("event_type", "") # 2. 事件分发 if event_type == "recording.available": await handle_recording_available(payload) elif event_type == "meeting.ended": await handle_meeting_ended(payload) # 3. 返回成功，腾讯会议侧停止重试 return {"code": 0}

事件处理函数要做到幂等。什么意思？腾讯会议的Webhook可能会重试，比如你的服务在处理过程中超时了，它会再次推送同一个事件。如果处理逻辑里没有幂等校验，就可能出现重复推送、重复发消息的情况。我的做法是维护一张processed_events表，事件ID作为唯一索引，处理前先查一下有没有处理过。

还有一个细节：Webhook处理函数里尽量不要做耗时太久的操作。比如拉录制文件、生成卡片、发飞书消息，这些操作如果在同一个请求里串行执行，接口响应会变慢，腾讯会议侧可能认为超时从而重试。我的做法是在回调里把事件先落库，然后立刻返回成功，再由后台异步任务去拉录制、推消息。这样既快又稳。

4.3 录制文件与会议纪要如何自动推到飞书群

收到recording.available事件后，要做的事情有两步：获取录制文件信息，推送飞书消息。

获取录制文件信息需要调腾讯会议的查询录制接口，传入meeting_id和会议发起人的userid。返回结果里通常包含多个录制文件，有视频文件、有转写文本、有纪要文件。我们挑选需要的格式，组装成飞书消息卡片。

推送的卡片内容可以这样设计：

• 标题：会议已结束，录制已生成
• 正文：会议主题、会议时间、录制文件播放链接、转写纪要链接
• 按钮：查看录制、查看纪要

卡片里的链接指向腾讯会议提供的临时播放地址。注意这个地址是有有效期的，不是永久地址。如果公司有对象存储，更稳的做法是把录制文件下载到本地或云存储里转存一份，然后把内部存储的永久链接推送到飞书群。否则过了有效期，群里的人点开就404了，体验很差。

这里牵出一个新的问题：回调服务怎么知道这个录制文件属于哪个飞书群？答案是在创建会议的时候，把群的chat_id保存在自己维护的一张映射表里，meeting_id -> chat_id。腾讯会议回调只告诉你会议ID，不直接告诉你是哪个飞书群创建的。建表关联这个动作看起来不起眼，但没有它，后半段闭环根本做不起来。

5. 鉴权失败、Token过期与权限静默丢失：我把这些坑趟了一遍

对接过程中，真正让我花时间的不是功能实现，而是各种鉴权和权限问题。这些小问题看着不复杂，但每踩一个都要花不少时间排查，我把它们集中列出来，帮你提前避雷。

5.1 腾讯会议侧鉴权失败：签名算法与权限边界

腾讯会议API调用报错，最常见的是这几类：

签名这个坑我印象最深。腾讯会议的签名算法要求把HTTP方法、请求路径、请求体、随机串、时间戳这些内容组合成一个字符串，再用HMAC-SHA256加密。拼接顺序一旦错，签名必然校验失败。而且不同的接口，签名串可能还不一样，有的版本还需要把请求体做MD5后再拼进去。我在调试时把签名生成过程单独抽成一个函数，加了日志输出，才一点点把顺序捋清楚。

还有一个坑是权限边界。腾讯会议的某些API要求应用有特定权限，但权限申请和审核是放在不同的地方，有时候开发者在代码里写了权限，后台却还没审核通过。遇到403时不要第一时间怀疑签名，先打开开放平台的应用详情页，把接口权限列表截图看一遍。我至少有一次是因为同事帮我申请了权限但没同步给我，导致我一直以为是自己权限不足。

5.2 飞书token刷新：缓存、过期与并发限流

飞书的tenant_access_token有效期是2小时，获取接口有频率限制。最不推荐的做法是每次调用飞书API之前都重新去获取一次。一旦业务量上来，并发请求一多，飞书侧的频率控制器就会直接拒绝你的token请求，导致全链路报错。

我的做法是在服务里做一个简单的缓存：

cache = {} def get_tenant_access_token(): now = time.time() if cache.get("token") and cache.get("expire_at", 0) > now - 60: return cache["token"] # 调用飞书API获取新token ... cache["token"] = new_token cache["expire_at"] = now + 7200 - 60 return new_token

注意我在过期时间上减了60秒，提前刷新，避免刚好卡在过期边界上导致鉴权失败。如果服务是多实例部署的，建议把token缓存放到Redis，而不是每个实例各自缓存。各实例自己缓存会出现一种诡异情况：A实例的token已经刷新了，B实例还在用旧token，结果部分请求成功、部分失败，排查起来特别费劲。

5.3 权限申请遗漏造成的“静默失败”

比报错更坑的是“静默失败”——接口返回200，但功能没生效。

我遇到过一种情况：飞书机器人发交互卡片时，content字段传成了JSON对象而不是字符串，飞书接口返回成功，但群里就是收不到消息。日志里看着一切正常，其实是格式问题。

另一种情况是事件订阅权限没配好。飞书的事件和权限是两套体系：你既要在“权限管理”里勾选im:message.receive_v1，还要在“事件订阅”里订阅这个事件类型。只配权限、不订阅事件，代码里收不到任何消息；只订阅事件、不配权限，订阅配置会保存失败。我当时就是只配了权限，忘了订阅事件，结果@机器人完全没反应。

还有一个细节：飞书的消息卡片支持很多字段，但卡片schema版本不同，支持的字段会有差异。生产环境里建议固定使用飞书官方文档中推荐的最新schema版本，避免线上对不上schema导致消息展示异常。

6. 从能用到好用：钉住日历、知识库与大模型入口的进阶玩法

跑通“创建会议-推送链接-自动归档”这个闭环之后，这套对接的价值已经很清晰了。但如果想让它真正融入办公流程，还可以往三个方向扩展。

6.1 与飞书日历打通：把腾讯会议日程写进日历年

前面提到卡片上有“添加到日历”按钮，它的背后是飞书日历API。飞书开放平台提供了calendar/v4/calendars/{calendar_id}/events这样的接口，可以在指定日历下创建日程，日程的title填会议主题，description里放腾讯会议的入会链接，start和end时间填会议的起止时间。

这里要注意：创建日程需要指定calendar_id。企业自建应用如果要给某个用户的日历写日程，需要用户授权；如果用服务账号创建，则会把日程归到服务账号的默认日历里，不会直接出现在用户的个人日历上。实际项目中，我建议让用户点击按钮后通过OAuth授权流程把日程写到用户自己的日历里。飞书的OAuth授权流程比较标准，前端拉起授权页，后端换token，然后调日历API。这个体验做出来之后，用户再也不用手动把会议时间敲进日历了。

6.2 接入知识库与AI大模型：从“查会议”到“问会议”

会议纪要是企业里最有价值的非结构化数据之一。腾讯会议转写出纪要文本之后，我们现在只是把它推送到飞书群。如果能把这份纪要自动写入飞书云文档，再接入知识库，就能解锁更多玩法。

具体链路是：收到recording.available事件后，后台调用腾讯会议的转写查询接口拿文本，用飞书云文档API（文档位置在open-apis/docx）创建一篇新文档，把纪要内容写入文档，然后把文档链接推送到飞书群。

文档建好之后，云文档的链接可以直接作为知识库素材导入到dify这类工具里，或者通过飞书机器人做一个简单的问答入口。同事在群里问“上个月的用户调研会结论是什么”，AI就能去文档里检索并回答。这里涉及飞书云文档的授权凭证：你需要在飞书开放平台申请云文档相关权限，并在创建文档时用应用身份访问或用户授权访问。dify首次接入飞书云文档时，要求填的就是这个授权凭证，可以选择OAuth方式拿到用户级token。这套链路做下来，会议纪要从“躺在角落里没人看”变成了“可以被检索、被提问”的企业资产。

6.3 生产环境的最后一道防线：失败重试、监控告警与多群隔离

功能都开发完了，最后一公里是让它在生产环境稳定跑起来。我梳理了几个关键点：

• 失败重试。腾讯会议API偶尔会有偶发5xx错误，飞书发消息也可能因为网络抖动失败。建议对关键操作做指数退避重试，例如第一次失败后等1秒重试，第二次等2秒，最多重试3次。但注意Webhook事件处理本身要幂等，重试不会造成重复推送。
• 监控告警。给回调处理函数加日志和指标，如果某个步骤失败率达到阈值，往专门的运维告警群里推一条消息。这样出了问题不用等用户反馈，系统自己会“喊”。
• 多群隔离。不同部门如果用同一个机器人，指令最好带上部门前缀，比如“/ops 开会”“/hr 开会”，避免不同群的消息互相干扰。
• 映射表与元数据。前面提到的meeting_id -> chat_id映射，建议用Redis或数据库存，并加上会议主题、创建人等字段。后续排查问题的时候，这张表就是整个系统的“账本”。

跑完这一整套，我最深的体会是：这种双平台对接，真正花时间的不是调用几个API，而是把权限体系、鉴权细节、事件生命周期、异常路径都考虑清楚。很多问题看起来是“代码bug”，实际上是“对平台规则的认知盲区”。

最后分享一个我在生产环境里验证过的小技巧：给每个关键外部请求都加上唯一请求ID的日志，无论是腾讯会议API调用还是飞书发消息。出了问题，通过请求ID能一次性把整条链路的执行日志拉出来，不用在多个服务之间来回翻，排查效率会高很多。希望这套飞书与腾讯会议的对接实践能帮你少踩几个坑，也欢迎有类似经验的朋友一起交流。