同一个 RingBot AI 流程在网页渠道能用，换到别的渠道（比如企业微信、公众号、Web 挂件或某个第三方 IM 接入）就没反应，或者答非所问。这类现象通常不是模型变了，而是消息在两处之一断掉了：渠道侧到平台这一段没接通，或者消息进来了但没被路由到原流程。处理顺序建议先固定住——先确认流程本身没被改坏，再核渠道配置是否填全，然后去会话记录里区分“没进来”和“进来了但答错”，最后才看路由规则把意图分到了哪条流程。

换渠道后答不上来，先别动提示词和模型参数。按四层顺序核一遍：原渠道复现排除流程变更、渠道接入参数是否填全、会话记录里有没有新渠道的入站消息、意图路由是否指向原流程。这四步都能通过配置、日志或页面行为验证。会话记录里查不到消息，说明问题在接入层，不必继续调提示词；查得到消息但输出不对，才转向路由和流程。每一步的判定都依赖你环境的实际字段和日志格式，动手前先确认控制台里的字段名。

先在原渠道复现一次，确认问题只在切换后出现

第一步不是去改新渠道，而是回到原本正常的渠道跑一遍同样的输入。目的很直接：确认流程在这个时间点仍然可用，把“流程被谁改坏了”和“切换渠道才触发”这两种情况分开。如果原渠道这时也不回，那问题跟渠道无关，先去查流程版本、知识库更新或模型配置的变更记录。

操作上建议固定同一句输入，在两个渠道各发一次，并记下具体时间点（精确到分钟），后面查会话记录和渠道日志都要靠这个时间锚点。记录内容至少包含：输入文本、渠道标识、发出时间、是否有回复、回复内容是否与原渠道一致。这条基线在后面第四、第五步还会复用。

核对渠道侧的接入参数是否填全

渠道配置项少填一项，很多平台的表现是静默失败——不报错，也没有回复，看上去就像“答不上来”。重点核对三类：回调（消息推送）地址、渠道凭据（Token/Secret/AppID 之类）、渠道启用状态。字段名各平台不同，以你控制台实际显示为准，下表只作为核对清单的占位。

核对时注意区分“填了”和“填对”：回调地址要跟平台对外暴露的域名路径一致，凭据要注意是否区分测试与正式环境，启用状态在保存后是否真的生效。改完任何一项，都建议回到第 3 步的会话记录里确认有没有新消息进来，而不是直接看聊天窗口。

在会话记录里确认新渠道的消息有没有进来

这一步要把两种故障分开：消息根本没到平台，和消息到了但流程答错。做法是按时间检索会话记录，用第 1 步记下的时间点做过滤条件，维度优先选渠道标识加时间范围，再逐条看看有没有你刚发的那句输入。

• 会话记录里有这条消息，且能看到对应的流程或机器人：说明接入层是通的，进入第 4 步查路由。
• 会话记录里没有这条消息：先查渠道回调地址是否可达、凭据验签是否通过、渠道是否处于启用状态，再看渠道侧日志里有没有推送失败或重试记录。
• 记录里有消息但没有关联到任何流程，或关联到了一个意料之外的流程：同样进入第 4 步。

如果没有独立日志可查，退一步的办法是看渠道侧的消息推送状态或失败计数，再对照平台侧的入站记录。这个环节的结论必须基于“查到了/没查到”的事实判断，不要仅凭聊天窗口没回复就认定是模型问题。

检查路由规则：同一意图被分到了哪条流程

消息确实进来了但答非所问，最常见的原因是新渠道没有绑定到原流程，或者意图识别把同一句话分给了另一条兜底流程。核对方法通常是两步：先看渠道到流程的绑定关系，再看意图到流程的映射表，确认你那句输入命中的意图在当前渠道下指向哪条流程。

常见误配点集中在几处：新渠道默认落到通用兜底流程而不是业务流程；意图关键词或示例句只在原渠道配过，新渠道走的是另一套；多流程同名导致选错 ID；渠道级配置覆盖了全局路由。核对时建议直接对比两个渠道的绑定结果，把差异项单独列出来，一次只改一处再验证。

# 通用核对骨架，字段名以实际控制台/接口为准
渠道:      <channel_id>
绑定流程:  <flow_id>
意图:      <intent_name>
命中流程:  <resolved_flow_id>
判定:      绑定流程 == 命中流程 ? 正常 : 需检查映射

用固定三条输入在两个渠道各跑一遍并比对

改完配置或路由后，不要用随便一句话验证，固定三条输入更能看出差异：一条常规业务问句、一条带业务关键词的问句、一条边界输入（比如缺参数的追问）。在两个渠道各发一遍，把结果填进下表比对。三条输入建议在验证前就定好，后续回归沿用同一组。

比对时注意区分“措辞不同但语义一致”和“答的是另一个业务”。前者通常不算问题，后者说明仍落在错误流程上。三条输入全部与原渠道语义一致，才可以认为渠道切换这个问题处理完了；只要有一条不一致，就带着对应行的下一步动作回到第 4 步，不要直接去调提示词。