易歪歪eyy如何设置客服消息的敏感词过滤？

一、先厘清边界：敏感词过滤在客服消息链路里管什么

在易歪歪（下文简称 eyy）里配置客服消息的敏感词过滤，本质上是往「客服发送 → 客户接收 → 会话留存」这条链路中间插入一个可配置的文本检测环节。它解决的不是「能不能聊天」，而是「哪些内容不应该出现在可留存的聊天记录里、不应该被发送出去」。这个定位一旦确定，后面所有的取舍都会变得清晰：拦得太宽，客服效率受损；拦得太窄，合规留痕形同虚设。

除了宽窄，还有一个相邻边界容易被忽略——很多团队第一次接触这个功能时，会把它和另外三个功能混在一起。自动回复与快捷话术解决的是「回复速度」；黑名单、禁言、拉黑处理的是「账号维度」的准入；会话记录与导出解决的是「事后取证」。敏感词过滤是唯一同时具备「内容维度」与「事中干预能力」的环节——它既能在发送前阻断，也能在发送后打标留痕，这正是它在合规体系里不可替代的原因。

需要提前说明的是：不同平台的客户端版本对菜单的归类和命名并不完全一致，有的版本把它放在客服设置里，有的归入风控或合规分组。因此本文涉及的界面路径均为经验性描述，菜单文案以你本机实际安装的版本为准。

二、从指标出发：先定义「配置好了」长什么样

边界划清之后，下一步并不是急着打开设置页，而是先定义什么叫配置成功。在动手点任何开关之前，建议先写下三条可观测的验收指标。第一条是拦截时效：命中发生在发送前还是发送后——发送前阻断对客户完全不可见，发送后拦截则需要撤回或至少标记，两者对客服体验的影响完全不同。第二条是留痕完整性：一次命中是否留下了时间、会话对象、触发词、处置动作这四个要素，能不能导出。第三条是误杀成本：被错误阻断的正常消息占比有多高，客服每天需要人工放行多少次。

把这三条写下来之后，你会发现词库的宽窄并不是一个审美问题，而是一个可计算的权衡。经验性观察是：词库覆盖面越宽，误杀率上升越明显，客服需要人工介入的次数也随之增加；而误杀带来的效率损耗，往往在配置完成后的第二周才开始被团队感知到——这时候再回头精简词库，成本已经高了。所以宁可第一版保守，也不要一上来就追求「尽量全」。

作为对照，可以设想一个中等规模的电商客服团队：日均会话量在两千条上下，售后场景中确实存在客户索要私人联系方式、客服误发竞品链接的情况。如果他们把词库一次性铺到几千条、涵盖大量日常用语，那么「账号」「链接」「地址」这类高频词会持续触发误报，客服的每一次正常回复都要多一步确认；反过来，如果只配了十几条明显违规词，覆盖率又不足以支撑任何合规检查。指标先行的意义就在于，你能在配置之前就估出这个区间，而不是等系统跑起来后再被数据反向教育。

三、方案 A：前置拦截——把内容挡在发送动作之前

前置拦截的做法很直接：在客服点击发送的那一刻，系统先对文本做一次匹配，命中后阻止发送，并给出提示。落地时通常有两种呈现，一种是硬阻断，消息根本不出去；另一种是软提示，弹窗告知「该内容命中规则，是否继续」，由客服决定。

选硬阻断还是软提示，取决于你希望客服在流程中承担多少判断责任。硬阻断适合规则明确、误判代价低的场景，比如内部编号、密钥串、明显的违规广告模板；软提示适合边界模糊的场景，比如地址、订单号、座机号这类正常业务中确实需要发送的内容。经验性做法是：把词库拆成两档，一档走硬阻断，另一档走软提示，避免所有规则共用同一种处置强度。

前置拦截的边界同样需要说清楚。它作用于文本，对图片、语音、文件通常不具备同等能力；它依赖客服端的规则同步，如果客户端处于离线状态、规则尚未下发，拦截可能不会生效。因此，把前置拦截当作「唯一的合规手段」是有风险的，它更适合作为第一道阻尼，而不是全部防线。

四、方案 B：后置检测与留痕——为审计留下证据链

如果说前置拦截管的是「此刻」，后置检测管的就是「以后」。它的逻辑是：消息先发出去，系统在写入会话记录的同时做一次匹配，命中则打标记、触发告警、进入待处理队列。它不追求阻断，追求的是「查得到」。在合规与数据留存这条主线上，后置检测的价值往往高于前置拦截，因为审计要的从来不是「当时拦住了没有」，而是「三个月前那条消息还在不在、能不能拿出来」。

两者并不互斥。比较稳妥的组合是：前置拦截覆盖少数高确定性规则，后置检测覆盖全量规则，且后置检测的命中记录必须保留原始文本。如果为了「合规」把命中消息直接删除或替换成星号，反而会破坏证据链——被删掉的内容无法证明当时发生了什么，这一点在内部审计或外部检查时经常被忽略。

五、操作路径：桌面端、移动端与后台的最短入口

下面给出的是经验性路径，用于说明层级关系，具体文案请以实际界面为准。桌面端通常最快：打开客户端主界面，进入「设置」，找到客服或消息相关分组，进入消息过滤/敏感词配置页，添加词条并选择处置方式，保存后确认规则已同步。移动端的层级往往更深，多数情况下需要从「我的」进入设置，再进入客服或安全相关分组；由于移动端界面精简，部分版本可能只提供查看与启停，完整编辑仍需回到桌面端或网页后台。

如果团队是多坐席协作，更推荐走网页管理后台：管理员登录后进入管理或合规相关模块，找到敏感词/消息规则页面，在此批量导入词库、按分组分配规则、查看命中记录。后台的另一个好处是权限清晰——普通坐席只能看到提示，规则的新增与修改集中在管理员手里，减少了规则被随意改动的可能。

三条路径各有失败分支，需要提前准备回退方案。桌面端常见的失败是保存后未生效，此时先确认规则同步状态，再重启客户端；移动端的常见失败是找不到编辑入口，回退方案是转到后台操作；后台的常见失败是权限不足，回退方案是联系拥有规则管理权限的账号代为配置。把这三条回退路径写进团队的操作手册，比记住具体菜单名更有价值。

六、词库建设：分层、分词与例外怎么写

词库不是一份越长的清单越好，而应该是分层的。建议至少分成三层：第一层是硬性违规内容，命中即阻断，不需要讨论；第二层是业务敏感内容，比如竞品名称、外部联系方式，走软提示或后置告警；第三层是观察词，只做统计不做干预，用来验证你的假设是否成立——比如你怀疑某个词会被滥用，先放观察层跑一周，看命中频率再决定是否升级。

分词方式直接影响误杀。以「微信」为例，如果按整词匹配，那么「微信支付」这类正常表达也会被拦；如果只做子串匹配，「微信」又会把各种无关组合一并卷进来。经验性做法是：对短词加边界条件，对长词优先整词匹配，并且定期用真实会话样本回测。回测方法很简单——导出最近一段时间的会话文本，用当前词库离线跑一遍，统计命中条数，人工抽查其中一部分判断是否为误报。这个动作每季度做一次，比任何一次性的「精心配置」都更有效。

例外清单同样要写进词库，而不是靠记忆。比如售后场景需要发送退货地址，那么地址相关词应当进入白名单；教育行业的客服需要发送课程链接，链接类规则就应区分内部域名与外部域名。把例外写清楚的好处是，当新同事接手时，他不需要理解你当初的思考过程，只需要看规则本身。

七、例外与取舍：什么时候不该拦

敏感词过滤最容易被滥用的地方，是把它当成管理工具而非合规工具。有些团队会顺手把「投诉」「退款」「差评」也加进拦截列表，理由是「减少负面表达」。这个做法在合规视角下是有问题的：它既无法真正阻止客户在别处表达不满，又会让客服在需要正面处理售后时收不到完整信息，最终损害的是问题解决速度。

判断一个词该不该拦，可以用一个简单的问题：如果这条消息被完整保留下来，会不会对客户或公司造成实际风险？如果答案是「不会，只是看着不舒服」，那它就不属于过滤范围。信息留存的价值恰恰在于还原真实沟通过程，把不愉快的表达一并消音，会让记录失去证明力。

另一类不该拦的是高频业务词。以「订单」「发货」「物流」为例，它们在正常客服对话中的出现频率极高，一旦误拦，客服会立刻感知到流程被卡住，进而形成「这个功能不好用」的印象，最后可能被整组关闭。真正的风险不在于漏掉几个词，而在于规则被绕过后彻底失效。

八、命中之后做什么：四种处置动作的适用条件

词库决定「拦什么」，处置动作决定「拦下来之后怎么办」。可选的动作大致有四类：拦截、替换、告警、留痕。拦截适用于硬性违规；替换适用于展示层脱敏，比如把手机号中间几位替换掉；告警适用于需要人工介入的高风险情形，通知到值班负责人；留痕则应当作为所有规则的默认动作，无论前面选了哪一种。

这四种动作的组合方式决定了实际体验。举例来说，某团队对「外部联系方式」这一组规则采用「软提示 + 留痕」，客服在发送前看到提示后自行判断，系统同步记录；而对「身份证号」这类规则采用「硬拦截 + 告警 + 留痕」，一旦触发立即阻断并通知主管。前者保留了业务灵活性，后者把风险控制在前端，两种强度并存并不矛盾。

需要避免的一种组合是「拦截 + 不记录」。这在审计时会造成尴尬：你知道有条消息被拦了，但无法说明拦的是什么、谁在什么场景下发的。把留痕设为默认动作，本质上是在为将来的自己省事。

九、与机器人或第三方系统的协同

如果客服链路中接入了自动应答机器人或第三方工单系统，敏感词规则的位置就需要重新考虑：是放在机器人之前，还是之后。放在之前意味着所有上游输入先被检查一次，好处是脏数据不会流入下游；放在之后意味着机器人产生的回复也要经过同一套规则，好处是出站内容同样受控。多数团队的实践是两端都放，但规则强度不同——入站偏留痕，出站偏拦截。

与第三方协同时要坚持权限最小化：只授予规则读取与命中回传所需的最小权限，不要为了省事把管理权限一并交出去。一旦外部系统被攻破，规则被篡改的后果比单条消息泄漏更严重。可复现的验证方式是：在第三方侧确认它实际调用了哪些接口或功能，与预期清单逐条比对，多余的一律回收。

十、监控与验收：如何证明配置真的生效

配置完成不等于生效。一个可复现的验收流程是：准备一个测试账号，在客服端发送一条包含已知测试词的消息，观察三件事——消息是否被拦截或提示、会话记录里是否出现命中标记、后台是否能查到这条命中记录。三个都满足，说明链路是通的；任一环节缺失，就按顺序往前排查。

日常监控建议关注两个定性趋势：命中量是否出现异常波动，以及某条规则的命中是否长期集中在一两个客服身上。前者可能意味着词库过宽，后者通常意味着个体操作习惯问题，需要培训而非加规则。示例：假设某团队的日命中量长期稳定在两位数，某天突然跃升到四位数，更合理的解释是词库或业务场景发生了变化，而不是风险在一夜之间升高。此处只做趋势判断，不预设具体阈值——合适的水位线取决于你的业务量与合规要求，应当由团队根据自身数据确定。

验收时还要检查规则同步的时效性。经验性观察是：规则变更到全端生效之间存在一定延迟，改动后立即测试可能看不到结果。稳妥的做法是改动后等待一段时间再验证，并在变更记录里写清改动时间，便于日后回溯。

十一、故障排查：现象 → 可能原因 → 验证 → 处置

现象一：明明配了词，发送时没有任何提示。可能原因是规则未同步、词条落在未启用分组、或匹配方式与实际文本不符。验证方法是换一条明显包含该词的完整句式再试一次，同时检查规则所在分组的启用状态。处置方式是重新保存规则并等待同步，必要时重启客户端。

现象二：正常业务消息被频繁拦截。可能原因是词条粒度过粗或缺少例外。验证方法是导出近期命中记录，抽查其中若干条判断是否为误报。处置方式是把该词降级到软提示或观察层，并补充例外白名单。

现象三：后台查不到命中记录。可能原因是留痕未被设为默认动作，或查询条件的时间范围、会话范围设置过窄。验证方法是放宽查询条件后重试。处置方式是补开留痕动作，并把这项写进规则模板，避免下次再漏。

现象四：移动端与桌面端表现不一致。可能原因是两端规则版本不同步。验证方法是在同一账号下分别发送相同文本做对比。处置方式是以一端为准重新下发规则，并在团队内统一操作入口，减少多端编辑造成的分叉。

十二、适用与不适用场景清单

适合启用严格过滤的场景包括：金融、医疗、教育等受监管行业的客服沟通；涉及个人信息、支付信息的对话；有外部审计或定期合规检查要求的团队；以及对外包坐席缺乏直接管理手段的组织。这些场景的共同点是，一旦出现不当内容，后果不可逆且可被追溯。

相对不适合的场景则包括：内部沟通为主、几乎不接触外部客户的工作群；以创意讨论、情绪安抚为核心的咨询场景，过滤会明显打断表达；以及坐席规模很小、沟通内容高度可控的团队——在这种情况下，人工复核的成本可能低于维护一套词库的成本。

判断的关键不在于行业，而在于「这条消息被完整留存下来，谁会受影响」。如果答案是客户、公司或第三方中的任何一方，就值得纳入过滤与留痕体系；如果答案只是「看着不太好看」，就应该放行。

十三、上线检查表与最佳实践

上线前建议逐项确认：规则是否分层、是否区分硬阻断与软提示、留痕是否作为默认动作开启、例外白名单是否已覆盖高频业务词、是否有明确的回退路径、是否指定了规则修改的责任人。这六项里任何一项缺失，都会在后续运维中放大成问题。

运行期的最佳实践有三条。第一，词库变更留档，写清改了什么、为什么改、谁批准的，这是审计友好度的基础。第二，每季度用真实会话样本回测一次词库，不依赖感觉判断宽窄。第三，把「观察层」作为长期机制保留，新词先进观察层，用数据决定是否升级，而不是靠一次会议拍板。

还有一条容易被忽视：规则的可读性。一份只有缩写和编号的词库，半年后连原作者都看不懂。用自然语言写清楚每条规则的意图，比多写几百条词更有价值。

十四、常见问题

十五、结语与下一步

回到最初的问题：易歪歪客服消息的敏感词过滤怎么设置？答案并不只在某张设置页里，而在于你是否先想清楚它要解决什么。以合规与数据留存为主线，把它当作一条可审计的证据链来设计——前置拦截做第一道阻尼，后置留痕保证查得到，例外清单保证业务跑得动，三个部分缺一不可。

下一步建议按这个顺序推进：先用一周时间导出真实会话样本，观察哪些内容真正构成风险；据此写出第一版分层词库，控制在保守规模；配置完成后按「发一条测试消息 → 看是否命中 → 查后台是否有记录」的流程做一次验收；最后把词库变更留档和季度回测写进团队制度。这样配置出来的规则，才既挡得住风险，也经得起时间检验。