写在前面
飞书适合团队协作场景，但第一次接入时，平台侧准备通常比 Telegram 更重。
所以这一步的重点不是“尽快加很多群”，而是先确认平台应用已经准备完整，再跑通一条最小消息链路。
你现在只做三件事：
- 把飞书应用准备好；
- 把最小配置接进 OpenClaw；
- 用一次单点测试验证消息闭环。
第一步：先确认飞书应用已经准备完整
开始前先确认这些平台侧信息都已经到位：
- 飞书应用已经创建；
- 必需的凭据已经拿到；
- 相关权限已经配置；
- 需要的事件订阅或消息入口已经打开；
- 你已经知道这次要在哪个组织场景里做首次测试。
如果这些信息还有缺项，先不要急着判断是 OpenClaw 有问题。
飞书接入里，很多“没反应”其实来自平台应用还没准备完整。
第二步：在 OpenClaw 里添加飞书渠道
如果你想通过交互式方式配置，可以先运行：
openclaw configure如果你已经清楚自己要接飞书，就按当前环境要求把飞书渠道配置进去。配置完成后，先不要继续扩展场景，先检查状态和日志。
第三步：先做最小状态检查
执行：
openclaw channels status
openclaw channels status --probe你现在要确认的是：
- 飞书渠道已经出现在状态列表中；
--probe没有直接报凭据缺失、认证失败或连接错误；- Gateway 日志里没有持续性的飞书连接异常。
如果这里已经报错，就先停在当前层修平台凭据或渠道配置，不要直接去改更多组织权限。
第四步：只选一个测试入口
第一次验证时，只选一个最小场景，例如：
- 一个明确的单聊入口；
- 或一个你可控的测试群。
不要同时做这些事：
- 让应用进多个群；
- 一次开启很多组织级权限；
- 把消息接入、权限配置和高级自动化一起上线。
飞书这类平台的正确做法，是每次只改一层，然后马上验证结果。
第五步：发一条测试消息并记录日志反馈
在选定的测试入口里，发一条最简单的消息，例如：
你好现在可以收到消息吗帮我复述这句话
同时打开日志：
openclaw logs --follow判断标准：
- 飞书里收到了正常回复；
- 日志里能看到消息进入和处理记录；
- 没有持续性的权限错误、事件订阅错误或连接错误。
如果平台里没有回复，但日志里也完全看不到消息，优先回平台侧检查应用、事件和权限。
如果日志里已经有消息进入，但回复异常，再继续看 OpenClaw 侧配置和运行状态。
怎么判断飞书接入已经成立
满足下面几条，就说明这次飞书首轮接入已经跑通：
- 平台应用和凭据已经完整准备；
openclaw channels status --probe正常；- 你选定的测试入口可以发消息并收到回复；
- 日志没有持续性的阻塞错误。
如果只是应用存在、状态可读，但没有完成一次真实消息闭环，还不能算接入完成。
常见错误或风险
- 平台应用还没准备完整，就开始判断 OpenClaw 配置有问题；
- 一开始就做组织级大范围验证；
- 平台侧和 OpenClaw 侧同时大改，导致因果关系断掉；
- 只看状态页面，不看真实消息是否进入日志；
- 单点测试还没跑通，就继续叠加群组、权限和高级流程。
下一步
如果飞书已经能稳定收发消息，继续看 配置改完如何验证。
如果你还不能判断问题卡在平台侧还是 OpenClaw 侧，先去 接入失败时怎么分类。