10.16—10.18 个人微信系统真实案例分析与整改报告

案例 C·fdde13（电脑 C，10-16 13:53，首触 / 新客）：窗口内唯一能证实的真新好友。首触 13:53:58 发出，电脑端回执判为送达（无截图佐证），但「好友通过」没有记录，面板「添加新人」当天为 0。另外电脑 C 有 9 个会话（10-15 14:42—15:42 一小时内建出）里一条消息都没有，也没有首触，挂着「等首触」的召回任务三天没动（见第 05 节第 9 项）。

原因（已验证）：程序只在读到好友通过提示旁边的具体时间时才上报通过；读不到就不报，也不留日志。这是 10-01 有意改的（宁可漏记，不虚增），但「漏记的要人工核对」没有落到任何人头上。C 那 9 个空会话为什么没首触：待核实（需要销售在电脑 C 的微信里看这 9 位的聊天窗口是否真的为空）。

影响：面板「添加新人」漏 1；首触照常发出，客户没有漏触达。C 那 9 位最多 3 天没有任何触达。

整改：面板已按首触日期补记通过（#2221，标注「只有日期」）；电脑端读不到时间时也要上报并留日志。

验收：下一个真新好友通过后，记录里有通过时间或日期；读不到时间的有一行明确日志。

证据：好友记录表该行通过时间为空、首触时间 13:54:01；电脑 C 日志 13:53:32 首触候选「我们加的」、13:53:58 发出，同一小时没有任何上报通过的日志。

窗口内：真送达的首触只有 C·fdde13 一条（样板房活动版，177 字，含 2 张海报），到 10-18 22:4x 已过 56 小时，没有回复。另一条 C·4a49e7 实际没送达。

对照（10-09 起全部电脑端首触 27 条）：3 条后来有回复（其中 1 条对方回了 146 条，疑似内部测试号，自然回复可能只有 2 条），10-11 以后的 20 条 0 回复。但这 20 条里有 5 条其实没送达（见下一类「没送达的首触」），剩下的样本太少，不能据此判断是客户选得不对、话术不好还是触达机制的问题。

影响：暂时无法判断是否有商机流失；可以确定的是首触回复率被没送达的首触拉低了。

整改：先把没送达的首触从统计里去掉（面板已改），再按客户来源、话术版本分组积累样本。

验收：首触回复率只按「确认送达」计算；样本满 30 条后再比较话术版本。

证据：消息表首触行之后同一会话有无客户消息。注意：客户消息只有被电脑读到才入库，这个回复率是下限。

窗口内：三天没有一条同时记有「通过时间」和「首触时间」的记录，算不出间隔。

历史样本（10-09 起 12 条）：3 条间隔 7—13 小时（B·2e7fb5 457 分钟、B·427068 773 分钟、A·87143c 541 分钟），全是夜里通过、第二天上午首触；其余 9 条在 2—144 分钟。是不是「夜里不巡检」造成的：推测，代码里没找到首触夜间开关。

相邻问题（已验证）：首触候选「没读清、15 分钟后再判」三天 14 次（A 11 次、C 3 次）。A 有 3 位客户连续 3 次读不出后 24 小时内不再判。A 涉及的是备注带「不确定 / 沟通中」的老客户，是否错过了真新好友：待核实。

影响：窗口内无法评估；历史上夜里通过的客户要等到第二天上午才收到第一条消息。整改状态：尚未处理（先修「通过时间记不上」）。

验收：通过时间能记上之后，按「通过→首触」分布每天出数，超过 2 小时的单列。

证据：好友记录表 12 条历史样本；电脑事件表「首触未确认」14 条。

B（49 条到期没发，其中 19 条超过 7 天、最老一条 09-22 到期）：这 49 位客户三天里一次也没被巡检翻到；同期电脑 B 巡检认人 2,488 次，都落在别的客户身上。

A·40b28b（电脑 A，09-23 起）：同一个召回任务尝试了 36 次，日志里可见的多是读屏超时、确认不了窗口在底部就放回，而放回没有次数上限。

C（17 条）：8 条是旧方式排的任务，电脑 C 现在只用新方式发，没有任何程序会再去领它们；其中 C·0e1697 备注里已写「已签」，本该作废却一直挂着、被算成「逾期待发」。另 9 条就是上面那 9 个空会话的「等首触」任务。

原因（已验证）：召回不是按到期时间排队，而是等巡检翻到这个人才处理；翻不到或失败放回的任务没有清理，也不告警（电脑心跳正常时，逾期任务不报）。为什么那 49 位总排在列表深处：推测。

影响：这些客户该收的召回一直没收到；C·0e1697 这类已签单的客户若被补发会被打扰。口径说明：这里数的是「排过、到期、被放回」的任务；电脑当时实际可发的人数另有统计（B 147、A 32、C 35），两者不是一回事。

整改：见第 06 节「召回积压清扫」。

验收：到期超过 3 天的召回为 0（要么发出、要么作废并写明原因）；面板显示到期天数分布。

证据：召回任务表 10-18 22:35 的待发记录；三台日志里按这些客户的编号检索命中次数；代码中新方式只领新任务、失败放回无上限。

每天发出：B 32 / 47 / 26，A 4 / 8 / 2，C 18 / 2 / 13（每台每天上限 50，三天没有一台碰到上限）。

C 10-18（已验证）：凌晨 3—8 点巡检空转点开 1,396 次，把当天的扫描额度提前用光，11:47 起不能再扫，11:18 之后召回 0 条。修复 #2212 已合并（夜里只走省额度档），电脑 C 10-18 21:31 开始装含这项修复的 1.25.15，至 23:52（心跳回读）没装完、程序没回来，还没生效。

A 低产出（已验证）：白天销售在用电脑、微信不在前台，召回为回复让路 712 次、抢不到前台 445 次。C 可发的人很少（已验证计数）：约 287 个聊天标题因为备注里没有「地区+6 位编号」而永远认不出（同一客户可能有多个写法，实际人数更少）。

估算：因掉线和额度用光少发约 50—90 条，是按每小时发送速率推的，不是实测。

影响：三天少发的召回估计 50—90 条（见上，估算）。

验收：电脑 C 装上新版后，凌晨不再出现额度耗尽；三台每天发出与可发人数对账。

证据：召回任务表按发出时间统计；电脑 C 日志 11:47:57 起「每日扫描额度用完」559 行；心跳里当天尝试次数 2,000（上限）。

三天 11 次自动重启，10 次已恢复，离线分钟数：19、36、54、59、93、163、188、360、512、806，中位 128 分钟（预期 10—15 分钟）。三天离线 10 分钟以上的掉线全部由这 11 次重启引起（C 的假活除外）。最长三次：B 10-16 18:53 → 10-17 08:19（806 分钟）；A 10-18 08:31 → 17:03（512 分钟）；B 10-18 11:03 → 17:03（360 分钟）。A 和 B 在 17:03 同一分钟恢复，相差 13 秒，像是同一个人先后去点了启动，推测。第 11 次：C 10-18 21:31 重启后至 23:52 仍未恢复。

已验证：重启指令在旧程序退出之前就记了「成功」，之后没有任何东西核对新程序起来没有；拉起新程序这一步以前不写日志，所以查不出卡在哪。监控只盯「升级」类指令，不盯「重启」类指令。11 次里有 6 次发在 08:30 或 18:50，正是上下班前后，其余在 11:00、14:40、16:20、18:00、21:30。

推测：后台拉起启动脚本在某些情况下失败（B 的程序装在一个特殊的虚拟化目录里、重启时 B 在锁屏）。但电脑 A 10-16 也在锁屏时重启，36 分钟就回来了，锁屏不能单独解释。

历史：#2207（随 1.25.14 发布）改过一次自启方式，还没有装上它之后的自动重启样本；#2216（1.25.16，10-18 21:49 出包）加了拉起步骤的日志，三台都还没装上。

影响：掉线期间不读消息、不回复、不召回；B 10-18 17:04 恢复后才读到客户 B·2dd3cb 的一条消息，最长可能晚了 6 小时。相关：电脑 C 的开机自启两次设置失败（系统拒绝写入自启项，是否安全软件拦截为推测），C 掉线后只能人工点启动；这和升级后不起来是两件事。

整改：见第 06 节 P0-1。

验收：连续 5 次自动重启都在 20 分钟内恢复，拉起日志三行齐全。

证据：指令表 11 条重启指令；电脑事件表「开始安装 / 安装完成」配对；三台日志逐行时间间隔。

客户刚说话就被召回：窗口内没有找到。三天发出 152 条召回，电脑 B、C 有 88 次发前读屏记录，读到的最后一句全是我方说的（电脑 A 的 13 次没有读屏记录，未覆盖；库里有历史聊天的会话只有 11 个）；有客户未读时程序会先让给回复（让路 7 次）。窗口外有两例：B·627019 10-13 AI 刚回完客户 2.5 分钟就发了召回；B·2dd3cb 10-11 正在谈价格，2.4 小时后被召回。

窗口内真实发生的是「召回打断人工接管」（已验证）：B·10d205 10-09 已转人工，10-16 11:12 仍收到一条召回；A·93adf9（与已转人工的 A·d3976a 备注只差省份前缀，判断为同一位客户的两条记录）10-18 17:15 被召回。原因：召回发送前只拦「已关闭」的客户，不拦「已转人工」的。

影响：销售正在人工对接的客户同时收到系统话术，客户会觉得是机器在发。

整改：见第 06 节 P0-3。

验收：已转人工的会话没有待发召回；用这两位做回归测试。

证据：会话表状态与转人工时间；召回任务表发出时间；代码中召回停发只判断「已关闭」。

C·fdde13（10-16）：真新好友，通过没记上（见第一类）。电脑 C 10-12—10-16：共 9 位只有首触、没有通过记录，从没进过「添加新人」。B·588045 与 B·e37a4c（10-12）：同一个人记了两次通过，因为备注 emoji 不同被当成两个人。

原因（已验证）：通过只在读到提示旁的时间才记，首触却不依赖这个时间，所以出现「首触发了、通过没记」。10-14 19:26 之后三台都再没写入过通过记录。历史上这一项改了 6 次（#1741、#1752、#1835、#1838、#2029、#2032），一直在「虚高」和「漏记」之间来回。

影响：「添加新人」和首触率不可信：真新好友漏记，同一人又可能记两次。

整改：见第 06 节 P1-8。

验收：每天的「添加新人」与销售实际通过的好友人数对得上（需要销售提供当天通过名单做对照）。

证据：好友记录表全表 49 行里 10 行「有首触、无通过」；同一客户两行通过时间同为 10-12 16:09。

B·d7e596 与 B·777bab：备注里「地区+6 位编号」相同，昵称和手机号都变了，被当成两个客户。老记录 10-05 到 10-16 已收到 5 轮召回，新记录 10-17 12:37 又收到第 1 天的同一条召回话术。是否确为同一人：推测（不排除编号被复用）。

C·85b86d（10-16 20:59）：备注写着「服务中心」的人被当客户自动回复了一句；是否是我方服务网点人员：待业务确认。

C 约 287 个聊天标题因编号位数不对或没有编号而永远认不出，召回发不到。备注名拼进消息气泡的问题（W-102，#2175 修复）之后没有再出现同样形态，但也没观察到一次被拦下的实例，状态仍是「已修复待验证」。

影响：同一客户 13 天内收到两遍相同的召回，召回节奏被重置；对疑似非客户发了一句自动回复。

整改：见第 06 节 P1-6。

验收：同机、同编号、昵称或手机号不同的新会话不再从第 1 天召回重新开始；用 B·777bab / B·d7e596 这组做回归。

证据：两条会话的召回记录与发送文案；电脑 B 日志 10-17 12:34 新名字出现、12:37 发出。

修复后仍出现（已验证）：#2167（1.25.10，处理折叠置顶下的未读）装上后，B 10-17 有 3 次「红点亮着却找不到是谁」告警、86 次探测落空；C 10-17 有 1 次。修复本身在生效（折叠置顶被点开过），但还有别的原因。

没有找到能确证漏回的案例：最接近的是 B·2dd3cb 10-17 17:28 红点亮，客户消息 18:09 才入库。如果客户 17:28 就发了，就是漏读 41 分钟；但微信原始发送时间我们拿不到，不能写成已漏回。而且这位客户已转人工，本来就不该自动回。

影响：三天里没有证实的漏回；风险是客户消息被晚读。

整改：见第 06 节 P2-9，落空时把截图上传，才能分清是识别漏了还是红点来自别处。

验收：每次落空都有截图；按截图归因后修复，落空次数下降。

证据：电脑事件表 7 条「未读找不到」（修后 4 条）；日志逐日计数。