看 pairing、看 mention、看重连，像先查门禁、点名和登录状态。
Channels 导读
先跑这5条命令，再查症状表
Channel 连上了但行为不对？别翻日志，先按顺序跑 `openclaw status` → `gateway status` → `logs --follow` → `doctor` → `channels status --probe`，确认 `Runtime: running` 和 `RPC probe: ok`。如果基础正常，直接对号入座查 WhatsApp、Telegram、Discord 的故障签名表——比如群消息被忽略，多半是 `requireMention` 或隐私模式没关。
先讲这一页到底在解决什么
先跑这5条命令，再查症状表
Channel 连上了但行为不对？别翻日志，先按顺序跑 `openclaw status` → `gateway status` → `logs --follow` → `doctor` → `channels status --probe`，确认 `Runtime: running` 和 `RPC probe: ok`。如果基础正常，直接对号入座查 WhatsApp、Telegram、Discord 的故障签名表——比如群消息被忽略，多半是 `requireMention` 或隐私模式没关。
第一站
🪜 Command ladder 其实就是“先走这 5 级楼梯，别一脚跨去猜原因”
这是整页最实用的部分。
openclaw status像先看整栋楼有没有通电，别通道还没坏就先怀疑通道。
openclaw gateway status像再看总控室门牌是不是亮着。
openclaw logs --follow像站在玻璃窗后面看它实时咳不咳嗽。
openclaw doctor + openclaw channels status --probe一个像总医生体检，一个像逐个去敲每扇门看门后有没有人。
第二站
📋 后面那些 failure signatures，不是在教新知识，而是在帮你“按症状最快分诊”
每个通道都给了一个最短排查入口。
Telegram
重点先查 bot 是否被批准、群里 privacy mode 和提及规则是否挡住了它。
Discord / Slack
先查 guild/channel allowlist、token、scope、message content intent。
iMessage / BlueBubbles / Signal
更像权限、webhook、pairing 和本地守护进程状态的组合问题。
第三站
🎯 这页的真正价值，是让你先问“最快该查哪一项”，而不是“我是不是全坏了”
把症状和最快检查项配对，排错会轻松很多。
📭 “连上了但没人回我”
先看 pairing、allowlist 和 mention gating，不要先怀疑模型。
🌐 “发消息报网络错”
先看 logs 里的 API 调用和网络环境，不要先重装整个通道。
🔁 “老是掉线重连”
先看 credentials 目录、session 健康、原始通道连接状态。
🎈 收尾一句
这页像总分诊台，先把问题分门别类，再去各通道专科深查。