1. 为什么要把飞书和腾讯会议打通
很多团队现在的办公现状是：内部沟通、审批、文档全在飞书，但开会用的却是腾讯会议。两边系统各自封闭，导致一个特别常见又特别烦人的场景——明天上午十点要开周会，负责拉会的人先要去飞书拉一个日程，再跑到腾讯会议里创建一个会议，拿到会议号和密码之后，回到飞书群里复制粘贴给大家。会议开完，纪要散落在腾讯会议的云录制里，飞书文档里什么都没有，下次想搜一下上次讨论的结论，翻半天找不到。
这种“双系统割裂”的问题，本质上不是工具不好用，而是缺少一座桥。把飞书和腾讯会议对接起来，其实就是解决三件事：一是把会议信息自动送达到位，二是让飞书日程和腾讯会议互相联动，三是把会后产生的录制、转写、文档沉淀回知识库。整个过程做下来，团队可以少干大量重复劳动，管理者也能把会议资产真正留存下来。
这篇文章适合谁看？如果你是企业内部的技术负责人、IT运维、数字化专员，或者是独立开发者，想帮自己的团队或者客户解决飞书和腾讯会议的联动问题，那这篇文章刚好适合你。内容会从最简单的一条路讲起，逐步深入到应用级API对接，再讲到如何把腾讯会议的转写记录喂给AI知识库。每一条都有可以直接抄走的代码和步骤。
需要提前说明的是，飞书和腾讯会议的开放能力都在持续迭代，文中的权限名称、API地址、回调格式以官方文档为准。实操时如果遇到字段对不上，优先看官方开放平台的最新说明，思路和排查方法是一样的。
2. 先落地最轻的一条路：飞书机器人推送会议通知
不要一上来就想着把所有系统全部打通。对接的第一步，优先解决“会议通知靠人肉复制”的痛点。最轻量、成本最低的做法，就是通过飞书群机器人把会议信息自动推送到群里。
2.1 飞书机器人从这里入手
飞书群机器人本质上就是一个Webhook地址，往这个地址发POST请求，消息就会出现在群里。进入飞书群，打开群设置，找到“群机器人”，添加一个自定义机器人，飞书会给你一个形如https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxx的地址。
建议添加机器人时把“签名校验”打开。开启后，请求里需要带上根据时间戳和密钥算出来的签名，飞书那边收到之后会做同款校验，能防止别人拿你的Webhook地址乱发消息。
签名算法的原理是：取当前时间戳（秒级），拼上密钥字符串，用HMAC-SHA256算法做哈希，再把结果做Base64编码。Python实现如下：
import base64 import hashlib import hmac import time def gen_sign(timestamp: str, secret: str) -> str: string_to_sign = f"{timestamp}\n{secret}" hmac_code = hmac.new( string_to_sign.encode("utf-8"), digestmod=hashlib.sha256 ).digest() return base64.b64encode(hmac_code).decode("utf-8") timestamp = str(int(time.time())) secret = "你的加签密钥" sign = gen_sign(timestamp, secret)拿到签名后，把timestamp和sign拼进请求体里，再带上消息内容，就能成功推送到群里。
2.2 会议信息从哪来
飞书机器人只负责“把消息送出去”，会议信息本身还需要一个来源。这里有两条路：
如果公司已经开通了腾讯会议的企业版API权限，就可以通过接口自动创建会议，拿到会议号、密码、入会链接，然后拼成消息发给机器人。这样完全不需要人工干预。
如果暂时没有API权限，退而求其次，可以给团队配一个固定的个人会议号。约定好每周例会、每日站会都用这个会议号，然后把会议号、密码、入会链接写死在消息模板里。这样虽然做不到“自动创建新会议”，但也比每次开会前复制粘贴强得多。
2.3 组合起来的效果
把上面两块拼起来，一个完整的“自动会议通知”流程就出来了：某个定时任务（比如每星期一早上九点）触发脚本，脚本调用腾讯会议API创建一场新会议，或者直接读取固定会议号的配置，然后组装成飞书消息卡片，POST到群机器人的Webhook地址。
我用的是飞书的“卡片消息”格式，结构类似这样：
{ "timestamp": "1715152000", "sign": "生成的签名值", "msg_type": "interactive", "card": { "config": { "wide_screen_mode": true }, "header": { "title": { "tag": "plain_text", "content": "本周项目例会" }, "template": "blue" }, "elements": [ { "tag": "div", "text": { "tag": "lark_md", "content": "**会议时间**：2024-05-10 10:00\n**会议号**：123 456 789\n**入会链接**：[点击入会](https://meeting.tencent.com/dm/xxxx)" } }, { "tag": "hr" }, { "tag": "note", "elements": [ { "tag": "plain_text", "content": "消息由飞书-腾讯会议对接服务自动发送" } ] } ] } }消息发出后，群成员直接在卡片里点链接就能入会，不需要再在聊天记录里翻会议号。这个方案大概一个下午就能搞定，建议作为所有对接工作的起点。
3. 进阶：通过应用级API实现双向联动
群机器人解决的是“单向通知”，但真正的办公闭环需要“双向联动”：用户在飞书日程里创建一个日程，系统自动创建腾讯会议并把会议链接写回日程；会议结束时，飞书自动收到通知，把纪要归档。这一步，就需要用到飞书开放平台的应用级能力和腾讯会议的云API能力了。
3.1 准备飞书自建应用
登录飞书开放平台，创建一个企业自建应用。整个过程需要管理员权限，这也是很多人在企业内部推不动的主要原因，建议提前和IT管理员确认好权限范围。
创建应用之后，最关键的环节是申请权限。以“日程创建后触发创建会议”为例，你需要申请这些权限：
calendar:calendar：读取和写入日历信息calendar:calendar_event：读取和写入日程事件contact:user.base:readonly：读取用户基础信息，用于拿到发消息的对象im:message：发送消息到群或用户
权限申请完之后，在“事件订阅”里添加回调事件。这里要注意：飞书的事件订阅地址必须是一个公网可以访问的HTTPS接口。本地调试推荐用内网穿透工具把本地服务暴露出去，生产环境则建议部署在云函数或自己的服务器上。
以“日程创建事件”为例，飞书会在用户创建日程后，向你的回调地址推送一个事件结构，核心内容大致如下：
{ "schema": "2.0", "header": { "event_id": "xxxx", "event_type": "calendar.calendar_event.created", "token": "校验令牌" }, "event": { "calendar_id": "calendar_id_xxx", "event_id": "event_id_xxx", "summary": "产品评审会", "start_time": { "timestamp": "1715152000" }, "end_time": { "timestamp": "1715155600" }, "creator": { "user_id": "user_id_xxx" } } }你的服务收到推送后，先校验token，再解析事件类型，然后调用腾讯会议API创建会议，最后把会议信息更新回这个日程的description字段里，或者直接给创建人发一条私聊消息。
3.2 准备腾讯会议云API接入
腾讯会议的开放接口叫做“腾讯会议API”，需要在腾讯会议官网的“高级服务-API接入”里申请。申请通过后，你会拿到三类凭证：会议商户ID（app_id）、API Secret ID、API Secret Key。
调用腾讯会议API时，需要通过JWT进行认证。JWT的生成逻辑不难，但坑比较多，我在这里把完整的代码写出来：
import time import jwt import requests app_id = "你的app_id" secret_id = "你的secret_id" secret_key = "你的secret_key" def generate_jwt(): now = int(time.time()) payload = { "app_id": app_id, "iat": now, "exp": now + 600, "jti": f"{now}_{app_id}", } headers = { "alg": "HS256", "typ": "JWT" } token = jwt.encode(payload, secret_key, algorithm="HS256", headers=headers) return token def create_meeting(subject: str, start_time: int, end_time: int, user_id: str): jwt_token = generate_jwt() url = "https://api.meeting.qq.com/v1/meetings" headers = { "X-TC-Key": secret_id, "X-TC-Token": jwt_token, "Content-Type": "application/json", "X-TC-Registered-UserID": user_id, } body = { "subject": subject, "type": 0, "start_time": str(start_time), "end_time": str(end_time), } resp = requests.post(url, json=body, headers=headers) return resp.json()上面这段代码里，X-TC-Registered-UserID是操作者身份。腾讯会议的API要求每次调用都要传一个注册用户的ID，这个ID需要在腾讯会议企业里提前配置好。如果不传，很多接口会直接返回“缺少用户信息”的错误。
3.3 飞书日程一键拉起腾讯会议
当飞书日程创建事件推送到你的回调服务后（对应“飞书日程创建”事件），完整的处理逻辑是：拿到日程的标题、开始时间、结束时间、创建人信息，调用腾讯会议API创建会议，再把返回的会议号、入会链接追加到飞书日程的描述里，并且给创建人发一条私聊卡片消息，告诉他“会议已自动创建”。
伪代码逻辑如下：
def handle_calendar_event_created(event): # 1. 解析日程信息 calendar_id = event["calendar_id"] event_id = event["event_id"] summary = event["summary"] start_ts = int(event["start_time"]["timestamp"]) end_ts = int(event["end_time"]["timestamp"]) creator_user_id = event["creator"]["user_id"] # 2. 调用腾讯会议API创建会议 meeting_info = create_meeting( subject=summary, start_time=start_ts, end_time=end_ts, user_id=creator_user_id ) if meeting_info.get("Error") is not None: # 创建失败，发告警消息 send_error_message(creator_user_id, meeting_info) return meeting_id = meeting_info["meeting_info_list"][0]["meeting_id"] join_url = meeting_info["meeting_info_list"][0]["join_url"] # 3. 更新飞书日程描述 update_calendar_event(calendar_id, event_id, join_url, meeting_id) # 4. 私聊通知创建人 send_success_message(creator_user_id, summary, meeting_id, join_url)这个流程跑通之后，用户只需要在飞书里建一个日程，所有会议准备工作自动完成。这里有个小细节值得注意：调用飞书API更新日程时，需要拿到日程对应的user_access_token。如果是企业管理员场景，可以用tenant_access_token代替，但前提是应用授予了对应权限。
3.4 腾讯会议状态回调到飞书
另一层“联动”是反向的：腾讯会议发生状态变化时，把消息推回飞书。腾讯会议支持配置“Webhook回调”，可以在会议开始、会议结束、参会人入会/离会等事件发生时，向指定URL发起POST请求。
具体配置路径是：腾讯会议控制台-API接入-Webhook配置。配置时填上你自己的回调地址，再设置一个回调的验证Token。腾讯会议向这个地址发起请求时，会在Header里带一个验证字段，你需要返回对应的应答才能完成握手。
收到回调事件后，最典型的应用场景是“会议结束自动归档”：解析事件里的会议ID、会议主题、结束时间，然后去腾讯会议API拉取本次会议的转写记录和录制文件，存到飞书云文档里，再往项目群里推送一条“会议已结束，纪要和录制已归档”的消息。
这种方式特别适合例会场景，整个流程从开会到归档，全员没有一个人手动参与。
4. 会后收尾：会议纪要进飞书云文档，再喂给AI知识库
会议开完，真正的价值在于沉淀。腾讯会议的付费版提供了云录制和AI转写功能，转写结果可以导出为文本或生成智能纪要。把这些内容同步到飞书云文档，再接入AI知识库，整个会议资产就能被检索、复用、问答，这是很多团队落到一半就停住的地方，也是整个对接方案里最有价值的一步。
4.1 把转写记录转成飞书文档
腾讯会议API里有一个“获取会议转写记录”的接口，调用后会返回转写的文本内容。拿到文本后，你可以直接调用飞书的“创建文档”API，用内容创建一个新文档，并把它放进指定的知识库文件夹。
飞书创建文档的API路径是https://open.feishu.cn/open-apis/docx/v1/documents，创建之后，再通过/docx/v1/documents/{document_id}/blocks接口在文档里逐段添加内容。飞书文档的内容以block为单位，每种block类型对应不同的渲染效果，比如heading1是一级标题，paragraph是正文段落，bulletin是项目符号列表。
这块在实现时有一个比较烦的点：转写记录通常是整段对话文本，没有结构。直接塞进飞书文档里，就是一坨长文字，可读性很差。建议在写入飞书文档之前，先用简单的规则或者大模型把文本切成“议题-结论-待办”的结构，再逐段写入。这一步做得好不好，直接决定后面知识库的检索效果。
4.2 dify首次使用飞书云文档的授权凭证怎么拿
dify是一款开源的AI应用开发平台，很多团队用它做知识库问答机器人。dify支持把飞书云文档作为知识库的数据源，这也是网上提问最多的地方：首次使用飞书云文档作为数据源时，那个授权凭证到底去哪拿？
先说流程：dify不是通过账号密码直接读取飞书文档的，而是通过飞书开放平台的OAuth授权机制。你需要先在飞书开放平台创建应用（可以复用前面创建的那个应用），然后开启“云文档”相关的权限，比如docx:document（读取文档内容）、drive:drive（读取云空间文件）。
具体凭证获取步骤如下：
第一步，在飞书开放平台找到你的应用，进入“凭证与基础信息”页面，记录下App ID和App Secret。
第二步，在“安全设置”里配置重定向URL。dify的知识库数据源页面会提供一个重定向地址，通常类似https://你的dify域名/console/api/oauth/feishu/callback，把它填到飞书的重定向URL里。
第三步，在dify的知识库-数据源页面选择“飞书云文档”，页面会跳转到飞书的授权页，你用自己的飞书账号登录，确认授权。授权成功后，飞书会把一个授权码（code）通过重定向URL传给dify，dify再用这个code去换token。
第四步，拿到token后，dify会把它保存下来。之后你在dify里选择“按文档同步”或“按文件夹同步”，就能把飞书云文档里的内容拉取到知识库里了。
这个过程中最容易出错的两个地方：一是重定向URL配置不一致，浏览器地址栏里的URL和飞书后台配置的URL必须一模一样，不能有末尾斜杠的差异；二是权限范围不足，如果应用只申请了“读取文档内容”权限，没有申请“读取云空间文件列表”权限，按文件夹同步时就会报403。
4.3 搭一个基于AI大模型的全栈知识库
当会议纪要进入飞书云文档后，配合dify可以把整个知识库做成一个“会议问答机器人”。团队成员在飞书群里@机器人，问一句“上周客户评审会结论是什么”，机器人会在知识库里检索相关内容，再调用大模型生成回答。这是目前很多团队在实践的“AI大模型全栈知识库”落地方式。
实现路径很简单：在dify里创建一个知识库应用，数据源选择飞书云文档，设置好索引方式（建议开启向量索引，也就是语义检索），然后再接入一个飞书机器人作为发布渠道，把应用绑定到目标群里。
整体架构是这样的：
- 飞书云文档，作为会议纪要的统一存储层
- 腾讯会议的转写记录，作为文档内容的生产来源
- dify的“飞书云文档”数据源，定时把新增文档同步到向量数据库
- 大模型负责根据用户问题检索并生成回答
- 飞书机器人作为最终的交互入口
这里有个细节：dify的“定时同步”频率不要太低，也不要太高。文档数量多的团队，建议一小时同步一次；如果知识库只有几十份文档，可以手动触发，没必要占用系统资源。同步到dify后，会议纪要从“存放”升级为“可以回答问题”，你能直接用自然语言从历史会议里提取信息。
5. 踩坑实录：几个最常翻车的地方
对接过程中踩坑是必然的，关键是踩完之后要能总结出一套排查方法。下面这几个问题几乎每个做飞书-腾讯会议对接的团队都会遇到，建议大家先收藏。
5.1 腾讯会议不能使用电脑自带摄像头吗
这个热搜词说明很多人在用腾讯会议时都遇到过摄像头打不开的问题。对接场景下，这个问题通常出现在回调服务自动启动腾讯会议客户端时，摄像头权限没被正确授予。排查思路是这样的：先确认腾讯会议客户端本身的摄像头设置——进入设置-视频，看是否能预览到画面；如果预览正常，再看操作系统层面是否禁止了腾讯会议使用摄像头，Windows和macOS都需要检查。
如果是通过API创建的会议，与会者从入会链接进入会议后摄像头没画面，多数情况是浏览器权限问题。用Chrome入会时要确保浏览器弹窗允许使用摄像头，而且不能有别的应用程序（比如另一个会议客户端）占用了摄像头。这个排查顺序基本能覆盖大多数“摄像头打不开”的场景，如果是企业内部批量推送安装的腾讯会议，建议检查一下系统级权限策略。
5.2 飞书机器人加签消息报“签名校验失败”
这个报错的原因主要有两个。第一是时间戳不准确，飞书校验时会取服务器当前时间和你传的timestamp做对比，误差超过一定范围会直接拒绝，所以确保生成签名用的time.time()和请求发出的时间间隔不要太大。第二是密钥本身填错了，签名用的不是Webhook地址里的那串，而是加签设置里独立生成的密钥，不要搞混。
还有一个小坑：有些语言在计算HMAC-SHA256时，直接把string_to_sign传成bytes会翻车，要先编码成UTF-8。这个错误报出来的现象各不相同，Java和Go里都会出现签名不一致，但Python里很少遇到，因为hmac.new会自动处理编码。如果签名校验一直失败，先把最终发送的timestamp、sign打印出来，用官方提供的调试工具比对一下，基本五分钟内能定位。
5.3 飞书事件订阅一直收不到推送
飞书的事件订阅回调要求你的服务端必须在收到请求后的3秒内返回HTTP 200，否则飞书会认为推送失败，然后按照重试策略再次推送。如果你在回调逻辑里同步调用了腾讯会议API创建会议，而腾讯会议API响应缓慢，就可能超过3秒导致飞书判定失败。
解决办法是引入消息队列。回调接口收到事件后，先把事件内容放进队列，立刻返回200，然后由后台Worker异步处理后续业务。这样做还有个好处：即使腾讯会议API临时不可用，事件数据留在队列里，等系统恢复后还能重试，不丢消息。
另外，事件订阅里有一个“请求地址”的校验机制：配置回调地址时，飞书会发一个带有challenge字段的验证请求，你的服务端必须原样返回这个challenge，配置才能保存成功。很多人在这里就卡住了，返回了JSON但格式不对，飞书会提示“校验失败”。
5.4 腾讯会议API返回401或403
401表示认证失败，优先检查JWT是否正确。JWT的iat和exp必须覆盖当前时间，时间偏差不要超过5分钟；jti虽然是可选字段，但官方建议加上，有些接口会校验它的唯一性。403表示权限不足，常见情况是X-TC-Registered-UserID指定的用户没有购买API服务，或者没有开启某个接口对应的功能。换一个有权限的用户ID试试。
5.5 dify授权飞书云文档后仍然报错
配置好授权凭证后，dify同步飞书文档时报错的常见原因有两个。一个是按文件夹同步时，文件夹里包含了一些权限受限的文件，飞书API在遍历文件列表时会返回403，dify会把这个错误直接抛出来。解决办法是把需要同步的文档统一挪到一个权限开放的文件夹里，避免混装。另一个是文档本身是评论区的、或者其他人共享过来的，你的应用没有该文档的权限。可以在飞书云文档里右键文档，把它分享给你的应用管理员账号，再重新触发同步。
6. 几个实际操作中的经验建议
整个对接流程走下来，有几个建议值得单独说一说。第一个建议是分层推进，不要毕其功于一役。先做群机器人通知，跑通之后再做应用级API，最后再做知识库闭环。每一步都要让团队真实用起来，用出效果，再往前走下一步。很多项目失败不是因为技术方案不行，而是因为一次引入太多变化，团队接受不了。
第二个建议是权限最小化。无论是飞书应用还是腾讯会议API，给应用授予的权限越少越好。原则上只申请业务必须的权限，不要图省事直接勾选全部。权限越大，安全上的风险就越高，尤其是飞书的云文档权限，一旦泄露意味着整个知识库内容都能被外部读取，这个代价是任何团队都承受不起的。
第三个建议是幂等性设计。飞书事件订阅、腾讯会议Webhook都有重试机制，如果你的回调处理逻辑没有做幂等，可能会出现同一个日程被创建了多个腾讯会议、同一个会议被归档了两次的情况。幂等的一般做法是：在业务表里维护一个唯一键，比如飞书日程的event_id，处理前先查一下是否已经处理过，处理过就直接跳过。
第四个建议是真机上一定要测异常链路。别只测顺利流程，重点测腾讯会议API超时、飞书文档权限失效、Webhook重复推送这些边界情况。我在实际项目里遇到过一次腾讯会议API上午还好好的，下午就一直超时，原因是腾讯会议那边在升级，好在当时做了超时重试和异常消息推送，否则用户会以为自己的日程创建逻辑出了问题，实际上服务端已经降级处理了。
最后一个建议是关于文档同步频率的。飞书云文档数据源刚接入dify时，不要同步得太频繁，建议先同步全部文档，然后设置每日增量同步。如果团队每天产生的会议纪要超过几十份，还可以把同步时间放在晚上，避开办公高峰，这样也不会影响到正常使用飞书的体验。
对接飞书和腾讯会议这件事，本质上不是在写代码，而是在梳理团队的协作流程。先把“通知-开会-归档-检索”这条链路想清楚，再动手写代码，你会发现每一步其实都没有想象中那么复杂。做出来的东西哪怕只是省掉了每天复制粘贴会议号这一步，对团队来说也已经是肉眼可见的效率提升。
