三天里每台电脑加了多少新人、发了多少首触、召回了多少、还有多少没召回；Jade 提出的五个问题，逐项给出真实案例、原因、现在的进度和下一步。
销售 A / B / C：三位销售各自的 Windows 电脑；安卓：一台安卓手机。编号与数据看板一致，各编号对应哪位销售见飞书私聊（公开页按站点规则不写团队成员名字）。
更正：10-18 那份《真实案例分析与整改报告》初版把电脑 A、B 写反了，10-19 已改正。以本页和看板为准。
客户消息：客户在微信里发给销售、并被电脑上的程序读到存进系统的消息条数，按条算（一张图片、一段语音也算一条；「你已添加了…」这类系统提示不算；电脑掉线期间客户发的读不到，也不算）。自动回复：程序替销售回复客户、真正发出去的消息条数，不含首触和召回。销售手打：销售自己在微信里打字、被程序读回系统的消息。首触：客户通过好友后我们发的第一条消息。召回：给之前加过、后来不说话的客户再发消息，每位最多 7 轮，两轮之间至少隔 2 天。巡检：电脑空闲时从上往下翻聊天列表、逐个认人；现在三台电脑的召回都要等巡检翻到这位客户才会发。转人工：系统停止自动回复，交给销售本人。掉线：电脑上的自动回复程序没在干活（没运行，或运行着但卡住不动），期间不读消息、不回复、不召回。微信停在登录页时程序虽然在跑也干不了活，本页单列。巡检翻到：程序在聊天列表里找到这位客户并点开。
「添加新人」「首触」「召回已发」「自动回复」与看板一致（看板 10-18 晚已按 #2221 修正口径）。「应召回」是本次按召回规则新算的：截至当天，上一轮召回已满 2 天、还没发满 7 轮的客户，就算当天应召回。这一列没扣掉客户刚回过话要等 48 小时的情况，是上限。
| 日期 · 电脑 | 客户消息 | 自动回复 | 销售手打 | 添加新人 | 首触 | 召回已发 | 应召回（上限） | 其中当天已发 | 当天未召回 |
|---|---|---|---|---|---|---|---|---|---|
| 10-16 · A | 0 | 0 | 0 | 0 | 0 | 4 | 26 | 4 | 22 |
| 10-16 · B | 16 | 3 | 1 | 0 | 0 | 32 | 44 | 25 | 19 |
| 10-16 · C | 5 | 1 | 0 | 1 | 1 | 18 | 15 | 13 | 2 |
| 10-17 · A | 0 | 0 | 0 | 0 | 0 | 8 | 33 | 7 | 26 |
| 10-17 · B | 8 | 0 | 0 | 0 | 0 | 47 | 64 | 43 | 21 |
| 10-17 · C | 3 | 2 | 1 | 0 | 0 | 2 | 2 | 0 | 2 |
| 10-18 · A | 0 | 0 | 0 | 0 | 0 | 3 | 29 | 3 | 26 |
| 10-18 · B | 1 | 0 | 0 | 0 | 0 | 26 | 48 | 22 | 26 |
| 10-18 · C | 0 | 0 | 0 | 0 | 0 | 13 | 17 | 13 | 4 |
| 三天 · 安卓 | 0 | 0 | 0 | — | 0 | 38 | — | — | — |
| 三天合计 | 33 | 6 | 2 | 1 | 1 | 191 | 278 | 130 | 148 |
「召回已发」含第 1 轮；应召回、其中当天已发这两列只算第 2 轮及以后，「当天未召回」＝应召回 − 其中当天已发（这两列口径相同）；它和「召回已发」口径不同，不能互相减。同一位客户连着几天没发，每天都会再算一次，所以 148 是人次不是人数。另一个角度的数字见第 5 节：截至 10-19 07:40 系统里到期没发的召回任务 91 条；按规则该发没发的客户 168 位（有的客户系统里根本没建任务，所以比 91 多）。安卓不走这套规则，只列已发。召回已发与任务表、看板逐格对过，一致；消息记录里的召回回执比任务表少 3 条，原因见第 5 节。
A 10.0 小时、B 20.4 小时、C 33.5 小时。掉线期间不读消息、不回复、不召回，掉线期间漏了多少消息和召回没法从库里算出来。A 的召回三天只发出应发的约 16%，但 A 10-17 没掉线也只发了 7/33，主因是巡检翻不到人（见第 5 节），掉线只是放大了影响。原因拆分见第 6 节。
程序只有读到「好友通过」提示旁边的具体时间才记通过，读不到就不记（10-01 起有意这样改，宁可漏记不虚增）。10-14 19:26 以后三台再没写入过通过记录。销售实际加了多少人不在我们库里，10-19 起看板底部新增「销售加友登记」，请销售每天登记，才能核对真实通过数。
检查方法：10-09 起全部 736 条召回（电脑和安卓），逐条看发送前 48 小时内同一会话有没有客户消息或我们的非召回消息。
| 案例 | 时间 | 应该怎样 | 实际怎样 |
|---|---|---|---|
| B · 会话 627019 | 10-13 12:55 | 客户刚在聊，不发召回 | 自动回复发出 2.5 分钟后，又发了一条召回 |
| A · 会话 5d20b8 | 10-10 17:27 | 同上 | 客户对话中途隔 71 分钟，插进一条召回 |
| B · 会话 2dd3cb | 10-11 21:49 | 报价谈判中，不发召回 | 上一条消息后 2.4 小时发了召回，28 分钟后对话转人工 |
| B · 会话 10d205 | 10-16 11:12 | 已转人工的客户不再召回 | 10-09 起已由销售手打接管，仍收到第 4 轮召回 |
另有 7 条召回发在上一次互动后 21—48 小时，属于边缘情况，不算打断（其中安卓 2 条是客户有话没被回答，属于另一类问题）。10-16—10-18 三天里库里能看到的是 0 条，但销售在微信里手打、没被电脑读到的消息不在库里，所以「三天 0 条」不能证明没打断。
召回发送前只检查「客户最后一句有没有答」（第 1 轮）和客户回复后等 48 小时，没有检查「最近一次互动是多久以前」；读不到聊天内容时还会照发兜底话术；判断能不能召回时没读「已转人工」字段。电脑端那个 60 秒空闲判断是整台电脑空闲，不是这位客户空闲。
同一会话最近 24 小时内有客户消息、自动回复或销售手打，召回推迟到满 24 小时再发，不取消；已转人工的客户不派、不发召回；安卓召回同样补上。每次被拦都记原因（「最近有互动」「已转人工」），以后能统计拦了多少。还没拦住的：读不到聊天、库里也没有近期互动记录的盲发，三天有 36 条（B 11、C 25），要等电脑端读屏改好再收紧。
验收：上线后任何一条召回，发送前 24 小时内同会话在系统里都没有客户或我方消息（销售手打没被电脑读到的看不到，盲发的 36 条也还不在范围内）；转人工会话召回数为 0。上面 4 个案例已写成自动测试。
| 问题 | 答案 | 依据 |
|---|---|---|
| 代码里首触有没有时间窗 | 没有。9—22 点的限制只管召回和自动回复，不管首触 | 已验证：召回和代回的时间窗代码，首触代码里没有任何时段判断 |
| 实际夜里发过首触没有 | 基本没有。9-15 以来 44 条首触，22:30—9:00 之间 0 条（9-22 有两条 22 点多的是早期测试）；10-01 以来全部落在 9—19 点 | 已验证：消息表首触记录按小时统计 |
| 为什么夜里没发 | 服务端夜里对召回回「还没到发送时段」，电脑端收到后整个巡检停下，顺带也不找新好友了。只有巡检碰到过可召回的客户时才这样，是副作用 | 已验证到代码；「只在碰到召回客户时才停」是推测 |
| 夜里通过的好友多久才首触 | 历史上 3 位晚上或夜里通过的（凌晨 2 位、21:37 一位），都拖到次日 9:43—10:29 才首触，间隔 7.6、9.0、12.9 小时。样本只有 3 个 | 已验证：好友记录表 |
| 现在有什么新风险 | 10-18 上线的 1.25.15（目前只有 C 装了）让夜里巡检继续走，新好友行仍会被点开，凌晨通过的好友可能被立刻发首触 | 代码已核；还没有实机样本，待验证 |
首触只在北京时间 9:00—22:00 发；夜里照常发现、记录新好友，但发送推迟到早上 9 点；9 点开窗后先发首触再发召回。验收：夜里发出的首触数为 0；夜里通过的好友，早上 9:30 前收到首触。夜里通过、过了 12 小时还没首触的，推提醒卡。
排查范围：10-09 以来三台电脑上、系统认为该由我们先开口的新好友会话共 39 个，其中 22 个首触已送达，17 个没有送达的首触。Jade 10-19 早上在销售电脑上逐个搜索、截图核对了这 17 个，结果如下。Jade 看到的「9 条里 8 条缺首触」对应的是 C 10-15 下午那批，库里是 9 条全缺。
| 系统里的情况 | 个数 | 销售电脑上核对到的真实情况（Jade 10-19 截图） | 处理 |
|---|---|---|---|
| C 10-15 14:42—15:42 建的 9 个会话，0 条消息，挂着「等首触」任务 | 9 | 9 位都不是好友，在 C 的微信里搜不到。系统给不存在的好友建了会话和任务 | 不补发；任务作废；看板不再把这类算成新人 |
| 记了已发首触，实际没送达 | 5 | 津X******（5-12 加的），另 4 位备注没有编号（8-7 加的 1 位、8-15 加的 3 位）：都是几个月前加的好友，后来删了我们或开了验证；10 月发的首触全部是红色感叹号 | 撤掉 5 条首触记录；不补发 |
| 首触撤回后没再发 | 1 | 闽X******（首触发前认不出身份，自动撤回）：4-14 加的，对方已开朋友验证，不是新好友 | 老联系人，不补发 |
| 系统显示首触撤回后没再发（同一人两个会话） | 2 | 湘X******（B）：10-10 20:07 客户通过好友并主动说「你好，过些天联系你」，10-11 10:12 我们回「好的呢」。不缺首触，但这段对话系统里一条都没有 | 单独排查客户消息为什么没进系统 |
程序判断「是不是新好友」，看的是聊天窗口里有没有「你已添加了…」「我通过了你的朋友验证请求」这类提示，没有核对提示上方的日期。几个月前加的好友，只要后来没聊过，窗口里最新的就是这行老提示，于是被当成新好友发了首触。这 6 位后来都删了我们或开了朋友验证，所以发出的全被拒收。如果对方没删，客户会在加好友几个月后突然收到一条「新好友欢迎语」。
首触发出后，如果程序看不清有没有送达，一律按「可能已送达」记成已发，即使同一时刻已经认出「被对方拒收」或「对方开启了朋友验证」。所以 5 条红色感叹号的首触，系统里都算成已发，看板首触数偏高。
那 9 个会话，召回程序认为聊天是空的，算新好友，交给首触，首触程序认为没有添加提示，不算新好友，谁都不发，任务一直挂着，也没有告警。这次核对说明它们其实不是好友，所以没造成漏触达，但同样的卡死如果落在真新好友身上就是漏发。
湘X****** 客户先开口、我们也回了，但系统里这个会话 0 条消息，当天 B 的运行日志也缺失。说明「客户已回复但系统没同步」确实存在，影响回复率和召回判断（系统会以为这位客户从没说过话）。今天接着查这一位为什么没读进来、同类还有多少。
代码修复（PR #2226，已提交，跑测试中）：认出拒收或「开启了朋友验证」时撤回首触记录；空窗口读不出内容时按「读屏失败、稍后重试」处理，不再推给首触；「等首触」任务超过 6 小时没人领推告警；首触只在 9—22 点发。追加修复（根据今早截图）：添加提示必须是 3 天以内的才算新好友，日期读不到不发，看到「开启了朋友验证」直接不发。电脑端改动要出新版、装到三台电脑才生效。
历史数据：撤掉 5 条没送达的首触记录；9 个不存在的会话任务作废；不补任何「已首触」或「通过时间」记录。
还要核：已送达的 22 条首触里，有没有同样是发给几个月前的老联系人的——需要销售再看一下这 22 位的添加日期，名单随后发。
① 系统记了首触、但 30 分钟内没收到电脑端「已送达」回执的，推卡并自动撤记录；② 新会话 2 小时后仍 0 条消息的，在日报里列出（「等首触」任务超过 6 小时没人领的，实时推卡）；③ 电脑端「首触已发」的条数和库里首触记录数对不上的，报警；④ 首触已发、通过记录为空的，连续 2 天大于 0 就报警；⑤ 某台电脑某个小时有心跳却没日志的，报「日志缺口」。验收用这次 C 10 月的 6 个老联系人和 9 个空会话回放，必须都能拦下或报出。
现行规则（三台相同）：每位客户最多 7 轮，两轮之间至少隔 2 个自然日，客户回复后等 48 小时，发送时段 9:00—22:00，每台每天最多 50 条、两条之间至少 60 秒。三台电脑都要等巡检在聊天列表里翻到这位客户、认准了才会发，服务端不能主动指定客户。
| 该发没发的 168 位客户，卡在哪 | A | B | C | 合计 | 例子 |
|---|---|---|---|---|---|
| ① 任务没建：三天里巡检一次都没翻到这位客户 | 12 | 6 | 4 | 22 | A·c1a912：10-15 后再没被翻到，第 6 轮已逾期 2 天 |
| ② 调度没触发：任务在排队，但让位之后没人再去翻 | 10 | 41 | 7 | 58 | B·0f5411：第 1 轮从 9-23 排到现在，逾期 26 天；B 三天点开 2488 次，第 1 轮待发的 49 位只点开过 4 位 |
| ③ 执行失败：领到了，读屏或输入没成功 | 7 | 7 | 9 | 23 | A·40b28b：「窗口状态没核实」连续失败 36 次，一直占着发送机会 |
| ④ 发送失败或不确定（按任务另计，不在 168 内） | 0 | 8 | 4 | 12 | C·37d605 被拉黑（不该补发）；B 有 6 条「不确定是否发出」卡了 10—30 天没人看，48 小时后就不再提醒 |
| ⑤ 已发出但没记录（按任务另计，不在 168 内） | 2 | 1 | 0 | 3 | A·fb934d：Jade 截图确认已发，任务改成已发，但消息记录没补、海报也没发出 |
| ⑥ 这一轮之前被取消过，再也领不到 | 20 | 6 | 5 | 31 | A·a34e11：9-27 人工取消过第 1 轮，10-18 被翻到 7 次，每次都被拒 |
| ⑦ 翻到了，但服务端没放行 | 10 | 15 | 9 | 34 | A·04d90a：同一客户被拆成两个会话，算轮次和领任务用的不是同一个，永远领不到；C 有 12 位因备注编号不合规被拦（不全在这一类里） |
| 合计（①②③⑥⑦） | 59 | 75 | 34 | 168 |
Jade 列的五类之外，⑥⑦ 是这次新发现的两类，合计 65 位，是漏发的大头之一。另有 4 条任务本身已经不该发（备注写着已签、客户已删好友等），应该作废而不是补发。
已经召回过、但下一轮比规则晚了 2 天以上：A 24 位（晚 2—4 天 15 位、5—9 天 4 位、10 天以上 5 位），B 12 位（10 天以上 10 位），C 1 位。反方向检查过：9-28 以来没有两条召回间隔小于 2 天，没有发得过密的情况。
召回完全依赖「巡检翻到才处理」：客户在列表里排得深、电脑掉线、巡检把点击次数花在别人身上，任务就一直挂着。失败重试没有上限，会一直占着机会；被取消过的轮次永远领不回来；同一客户拆成两个会话时会被系统自己卡死。A 三天掉线 10 小时，而且巡检翻得最慢，所以该发的只发出两成。
| 项目 | 内容 |
|---|---|
| 可以补发 | 122 位：A 38 · B 68 · C 16。已排除：已转人工、已签或勿扰、48 小时内有过对话、被拒收或删好友的客户 |
| 不补发、单列 | 以前被取消过轮次的 30 位（上表 ⑥ 的 31 位里有 1 位同时被服务端拦，算在后一类）、被服务端拦下的 17 位（上表是按「为什么没发」分人，这张表是按「现在能不能补发」重新筛过，所以两边人数不一一对应）（C 13 位，多为备注编号不合规）、该作废的 4 条、B 的 6 条「不确定是否发出」——这些需要先看聊天记录再定。另有 49 位今天起正常到期，按日常节奏发，不算补发 |
| 节奏 | 和日常召回共用每台每天 50 条上限，补发每台每天另限 A 20 / B 12 / C 20 条、每小时不超过 4 条，9:40—21:20 均匀铺开、三台错开 5 分钟；先补逾期最久的，第 1 轮最后补；每位客户只补下一轮；发前再查 48 小时内有没有新对话，有就跳过。按这个节奏 A 2 天、C 1 天、B 约 6 天补完 |
| 还缺什么 | 现在服务端没法主动指定「先发这位」，只能等巡检翻到。两种做法：① 销售按名单在微信里点开这位客户的聊天（不用打字），程序认出来后会自动按规则发，所有防重、间隔检查照常生效，但占人力；② 做一个「按名单优先翻到」的功能，系统自己补。建议先用 ②，和第 7 节的 P1 是同一件事 |
| 电脑 | 升级后没起来 | 微信未登录 | 两者重叠 | 程序在跑但不干活 | 合计程序没干活（白天 9—22 点）；不含 B 微信在登录页、程序仍在跑的 4 小时 |
|---|---|---|---|---|---|
| A | 3 次：10-16 早 54 分钟、10-16 晚 36 分钟、10-18 08:31—17:03（Jade 手动开） | 无 | — | — | 10.0 小时（9.1） |
| B | 3 次（含右边重叠的 1 次）：10-16 18:53—10-17 08:19；10-18 11:03—17:03（Jade 手动开） | 10-18 04:31—约 09:33，程序在跑、看板显示在线，但微信停在登录框 | 10-18 08:33—09:33 | — | 20.4 小时（9.7） |
| C | 5 次（含右边重叠的 1 次）：10-16 下午 93 分钟、10-17 两次 19 / 188 分钟、10-18 21:30—10-19 07:16 | 10-16 08:10—约 11:15 | 10-16 08:32—11:15 | 10-16 21:54—10-17 13:52 | 33.5 小时（12.7） |
现场说法核对：B「18 号上午微信未登录」与日志吻合（04:31 起被踢回登录框）。C「17 号上午微信未登录」日志对不上：日志里看到的登录框是 10-16 上午；10-17 上午程序本身没在写日志，看不到微信状态，既不能证实也不能否定，可能是日期记混，也可能确实没登录。A、B 两台掉线前后微信进程号都没变，说明电脑没有关机重启，是我们的程序自己没起来；C 在 10-16 下午到 10-17 中午之间微信被重开过一次。
已验证：重启指令发出去就算成功，没有任何环节确认新程序起来了；1.25.15 及以前，拉起这一步不写日志；安装脚本出错时会弹窗等人点。安装本身很快（C 10-18 人工那次 28 秒）。推测、未证实：后台 PowerShell 没起来、启动锁冲突后静默退出、安装器停在弹窗。同一台电脑有时几十分钟回来、有时十几个小时（B 三次都是人工开机才恢复），看不出规律。
三台都在线：A 1.25.13、B 1.25.14、C 1.25.15（C 今早 07:16 回来）。今天早上已把 C 也加入「暂停自动升级」，三台都不会再被自动重启（检查接口回读三台都是「已排除」）。记录拉起过程的 1.25.16 已出包，但三台都没装，生产里还没有一条拉起日志。开机自启：C 远程开了两次都被拦（计划任务报错、启动文件夹无权限，疑似安全软件拦截）；A、B 还没试过。
① 找一台有人在的电脑，手动装 1.25.16，再远程重启一次，读拉起日志，定位卡在哪一步；② 修好之后再恢复自动升级，并给重启后 20 分钟没心跳加告警（现在的告警只盯升级、不盯重启）；③ C 请销售确认之前让放的「启动文件夹快捷方式」放了没有，并截图安全软件的拦截记录；④ 微信被踢回登录框时程序显示「在线」但不干活，看板要单独标红。
| 优先级 | 事项 | 状态 | 验收标准 |
|---|---|---|---|
| P0 | 三台暂停自动升级，避免再被重启后起不来 | 已完成 10-19 早 | 检查接口三台均为「已排除」（已回读） |
| P0 | 看板与加友登记按销售名字标注 | 已上线 | 看板显示「销售 A」等（已回读线上页面） |
| P0 | 召回不打断对话、不发给已转人工的客户（#2225） | 已上线 10-19 | 召回发送前 24 小时内同会话无互动；转人工会话召回数 0（今天 9 点召回开窗后看第一次真实拦截） |
| P0 | 首触：老联系人不再当新好友（添加提示须 3 天内）、没送达撤记录、空窗口不卡死、9—22 点时间窗（#2226 及追加） | 开发中 | 今早 6 位老联系人回放全部不发首触；认出拒收后记录被撤；夜里首触 0 条 |
| P0 | 湘X****** 客户消息没进系统：查原因和同类数量 | 今天排查 | 这段对话补进系统；同类会话数报出 |
| P0 | 首触每日对账告警（第 4 节五项） | 待做 | 用 C 10-16 幽灵首触和 9 个空会话回放，全部触发 |
| P1 | 升级后不自启：现场装 1.25.16 复现、定位、修复，再恢复自动升级 | 需现场 | 建议标准：连续 10 次远程重启都在 15 分钟内回来（待定） |
| P1 | 召回补发 122 位 + 服务端按名单优先派单 | 待确认 | 建议标准：逾期超过 2 天的召回清零，到期未发保持在 10 条以内（待定） |
| P1 | 召回失败重试设上限；被取消的轮次可人工复活；同一客户多会话合并 | 待做 | A·40b28b、A·a34e11、A·04d90a 三个案例回放通过 |
| P2 | 微信掉到登录框时看板标红并推卡 | 待做 | B 10-18 04:31 那种情况 10 分钟内推卡 |
| 事项 | 为什么要人定 | 不回复时的默认做法 |
|---|---|---|
| 已送达首触的 22 位：添加日期是不是在首触前 3 天内 | 判断有没有把老联系人当新好友，只能在电脑上看 | 名单随后发；不核的话按代码修复后的新规则往后执行，历史不追 |
| 补发 122 位召回 | 批量发给客户，发出去收不回 | 不发，等确认 |
| 哪台电脑找谁配合装 1.25.16 复现重启 | 需要有人看着屏幕、截图 | 先用 C（掉线最多），请销售下午空闲时开着电脑 |