新客首触：10 月 15–28 日，18 位登记新客，13 位有首触，没有一条程序首触在 2 小时内发出

现象：客户26、31、38、41、42 没收到首触，收到的第一条是召回介绍，之后又按节奏收召回（客户31 一共 4 条）。客户41、42 连通过都没记上，不在新客统计里。

成因：① 「你已添加了…」灰字只有一行高，程序缩图后判它太矮直接不读，于是认不出新好友（W-126；31、41、42；客户26 日志是「客户已经说过 1 条」，被当成客户发言的是哪一行没取到画面）。② 识图偶尔没读出灰字上方的日期条，程序判「读不到日期，不首触」并 24 小时不再试（W-132；38）。③ 召回发出前要先读一遍聊天，读失败时程序按服务端的兜底话术照发；发前虽有一道「是不是新好友」检查，但它跟首触用同一套判据，①② 认不出时它也认不出（26、38）。

修复进度：①② 已修（10-27 合并，版本号 1.26.8，随 1.26.9 起的安装包发出）：一行高的灰字不再判太矮；日期条没读出改为 15 分钟后重读，连续 3 次才停 24 小时。已出包 · 未装机 · 未验收 ③ 还没修：建议加一道硬规则——这位客户还没有任何首触记录时，召回一律不发、先交首触。未修

验收：装上新版本后，新加好友 30 分钟内收到首触，第一条不再是召回；客户41、42 这类在好友记录里有通过时间。

现象：客户34、35 没有首触；34 由 AI 当普通对话接了，35 什么都没收到；36 推测同因，31 小时后销售手发。

成因：对方通过我方的好友申请时，微信会以对方的名义在聊天里显示一句通过验证的话，看起来就是一个客户气泡。程序判新好友的规则是「客户一句话都没说过」，这句话被算成了客户说的 1 条（客户35 是 2 条），于是判「不是新好友」。以前修过的 W-19、W-39 管的是灰字提示和服务端回复，没覆盖首触判断里的这一种。

修复进度：新问题，还没登记编号、没修。未修 修法：首触判断时把这句固定话术（以及紧跟着的表情）不算作客户发言。

验收：拿客户34、35 的聊天画面回放，判为新好友并发首触。

现象：能算时延的 9 位里，2 小时内发出的 4 位全是销售手发（其中 3 位的时刻是运营截图补录）；程序发的客户25 574 分钟、客户39 177 分钟、客户30 272 分钟（谁发的待定）。

成因：首触不是通过就发，而是要等电脑巡检逐行点到这一行、认出是新好友才发。夜里通过的要等早上巡检（25）；白天也可能几个小时没轮到（39，原因未查）。另外三台程序发的都是同一套活动介绍 + 海报，这两周没有一位直接回话；销售手发的提问式首触（37）客户次日回了需求。

建议：好友通过一记下就把这位排到巡检最前面立即首触，不等轮到；首触内容拿模板版和提问版各发一半，两周后按 24 小时回话率定。未开始

验收：程序首触时延中位 ≤ 30 分钟。

现象：客户35 备注开头是繁体「閩」；客户39 备注里的号码只有 7 位。

成因：程序只把地区简称 + 六位编号 + 完整手机号这种格式的备注当客户，防止把同事、商家号当客户发消息。繁体字不在地区简称名单里，号码不全也不行。

处理：客户35 现在就可以让销售把备注改成简体「闽」，改完下一圈巡检就会恢复。程序侧可以把繁体地区字自动当简体处理。未修

验收：每天列出判为非客户、但其实是新加好友的备注给运营，清零。

现象：10-21 前的 5 位只有日期或没有通过时间，是运营按截图补录的。

成因：「已添加」提示被后来的消息顶出屏幕，程序只看当前一屏（W-112）；客户32、33 可能是老联系人被当新好友（W-104，未逐个核对）。

修复进度：W-112 修复（#2331，1.25.48）10-21 起陆续装上，10-23 起登记的 7 位都有程序记下的精确通过时刻（样本小）。已装机 · 初步见效 剩下的漏记是问题一里的「认不出新好友」（41、42）。