现象日志全绿客户却一条回复都没收到做客服消息自动化的系统里有一条铁律只有名单内的联系人回复才会被自动发出。名单外的消息一律只提醒、不代发防止把话回给陌生人。这套机制跑了几个月一直相安无事。直到某天下午对账商家反馈一位老客户当天发了四条消息一条回复都没收到。我们去翻日志看到的却是另一番景象——四条消息条条都有处理记录没有报错、没有拦截、没有异常。日志是绿的客户是沉默的这说明某个环节的判断和现实完全脱节了。排查从会话归属判据开始。这套系统每轮处理前都会确认当前消息还属于名单里那个会话归属没变才继续回复。日志显示这位客户的四条消息在每一轮都被判成了会话已切换于是按流程转去了人工提醒队列——而商家当天没盯提醒四条消息就这么沉了。问题来了人没换、号没换为什么每一轮都判切走了根因一个字裂成两个身份比对会话锚点时发现了差异。名单里存的客户称呼是三个字消息里解析出来的称呼也是三个字长度相同、首尾相同中间一个字不一样——宇和文换了个位置组合成了形近字。消息来源经过一层文字识别字体小、有相位差识别引擎把真名读成了形近名置信度还不低属于典型的不对称崩坏读错的那个字识别引擎自己很自信反而不容易触发人工复核。真正的麻烦从这里开始连锁误读名与名单精确比对不命中系统认定这不是名单内的人该客户此前配置过自动回策略这条策略的语义是遇到这个人的消息就替我回——于是系统把误读名当成了新联系人写进了名单从这一刻起同一个人在系统里裂成了两个身份旧身份在名单里再也不会收到消息消息都顶着新名字进来新身份每次出现都会触发会话归属从旧锚点变成了新锚点的判断每一轮都判切走每一轮都不回复四条消息全军覆没。更糟的是这个污染会自我固化。误读不是一次性的——同样的字体、同样的小字号第二天还会读错。旧身份从此变成了僵尸条目永久留在名单里再也没有消息会顶着它进来。修复四道闸各管一段定位之后修复没有停在把那个名字改回来——改回来只是治标下一次识别抖动还会把新的形近字写进名单。我们最终落了四道闸逐一说明。闸一精确命中优先。名单精确命中的联系人原样使用名单里的名字绝不再做任何归一化处理。这条看起来是废话实际上是最容易被忽略的顺序问题归一化逻辑如果先于精确匹配执行就会把本来对的数据修坏。先查精确、后谈模糊这个顺序必须写死。闸二形近字表收敛。允许系统做形近归并的字表必须是人工审定的白名单只收真实存在的形近对。这里有个反例值得记住称呼里的性别字只差一个字但女士和先生意义上的差别比形近大得多这类差一个字的组合永远不能进归并表。字表越贪串并的风险越大——把两个真人并成一个身份比留着两个条目糟糕得多。闸三归一化下沉到身份层不进会判据层。最初一版修复把形近归一放在了会话归属判断的内部结果既有的串聊防护测试当场报红归一规则把消息尾部的杂质字符也一并宽容了导致真正切换到另一个会话时判据反而认为还是同一个会话——漏回修好了串聊打开了拆东墙补西墙。正确做法是把归一化下沉到身份识别canonical层让会话判据拿到的永远是归一之后的干净值自己不做任何模糊匹配。分层的好处在这一刻兑现每层只信上一层给的确定值。闸四写入闸基准取旧名单。污染的入口在写入所以根治必须卡在写入路径上任何要把新联系人写进名单的操作比对基准必须是写入前的旧名单而不是本次识别的结果。这样即使识别层再次读错误读名也会因为与旧名单精确不匹配且无可信形近对被拦在闸外进不了库。泛化长期记忆的污染都从写入路径进来这次事故我们内部复盘的结论其实和最近讨论很多的AI 的记忆不是数据库是同一个主题。名单、画像、偏好缓存这类长期记忆的可靠性不取决于读取端做多少聪明的模糊匹配而取决于写入端有没有闸。读取端的归一化是止损它能让已经脏了的数据继续可用但它救不了库本身——脏数据还在还会通过别的路径漏出去。写入端的闸才是根治宁可让一次识别抖动降级成人工提醒也不能让错误数据获得正式身份。另一个教训是判据的层次。模糊容错是必要之恶但它必须待在正确的层待在离数据近的身份层让上层判据拿确定值一旦把模糊逻辑塞进业务判据内部尾部情况会把判据本身变成漏斗。我们那版被测试当场打回的修复价值不在于被推翻而在于测试网兜住了它——反面护栏的测试串聊不能被误判为同一会话和正面修复同等重要它们拦住的往往不是 bug而是修复者自己。最后是可观测性。四条消息静默沉底一整天靠商家对账才发现这说明判切走这个分支当时没有计数埋点。修复时我们顺手给每个判据分支都加了计数命中、归一、拦截、转人工各多少次一眼可见。判据不可见等于判据不存在。参考文章微信自动回复怎么和人工接待配合什么情况必须转人工微信 AI 自动回复机器人怎么用关键词与 AI 理解的差别