案例一|销售 A · 闽X******-海-不确定
2026/9/16 · wx_pc_abb51f811d


客户消息 → 回复发出:18.105 秒 设备 salespc-desktop-ehf2mjt-xiaoyu;版本 1.14.15+05d72cc。
只看 Windows 电脑端“客户发来消息后,系统自动理解、生成并把回复真正发出去”的速度。
代码基线:wecom-chat / origin/main / 833c124f;生产数据核对时间:2026-09-16。
为什么要看 30 秒、而不是只看 18 秒:18.1 秒是中位数——它的意思是一半的客户比这快、另一半比这慢,不是每次都能做到。更能代表体感的是分布的右边:2026-09-01 至今 15 次有效问答里,14 次在 30 秒内完成(四分之三在 25.7 秒内,最慢的常规样本 28.1 秒)。
18 秒那一档往往还占了一个便宜:客户消息到达时,程序正好停在这位客户的聊天窗口,于是扫会话列表、判断该点开哪一行、点开会话这几步全都省掉——线上分段里这两步分别约 2.1–2.2 秒和 2.6–4.2 秒。换成需要先找到并打开会话的常规情况,同一条消息就会往 25–30 秒那一档走。所以 18 秒可以拿来说“最快能多快”,不能拿来承诺“每次多快”。
51.3 秒来自 2026-08-27 一条带完整五段耗时的成功实机案例。本段数字由生产库 conversations / messages 现算:取 channel=wecom_chat 且 wecom_external_userid 以 wx_pc_ 开头(个人微信 Windows 端)的会话,按“客户消息 → 同会话下一条 AI 回复”配对。样本 15 次仍小,属“最新表现”,不等同于全机队长期平均。
15 次有效问答里 14 次做到,约 93%。
一半的问答快于此。多发生在正好停在该客户会话时。
下方是两条较快样本的完整时间轴(18.1 秒、18.7 秒),两条都发生在程序已停在该客户会话时。上方的口径按 9 月以来全部 15 次问答计算,不只这两条。
2026/9/16 · wx_pc_abb51f811d


客户消息 → 回复发出:18.105 秒 设备 salespc-desktop-ehf2mjt-xiaoyu;版本 1.14.15+05d72cc。
2026/9/15 · wx_pc_54335e50cd


客户消息 → 回复发出:18.652 秒 设备 salespc-desktop-ehf2mjt-gaoyi;版本 1.14.22+40d4a32。
先看体验结论:客户消息进入当前微信对话框后,系统直接在这个对话框内完成读取、生成、认人、输入和发送,日常沟通已经达到“即时回复”的可用水平。
再看铺开结论:这套流程具备复制到多台 Windows 设备和多个销售人设的基础,Top 3 改动也都属于通用链路优化。当前能确认的是“速度已经够用、流程可以铺开”;长期大范围稳定性仍要靠每台设备的发送成功率、慢尾和错发记录持续监控,不能只用最快的一条案例作结论。
服务号、群聊、黑名单等已核实的非客户行记录画面特征;下一轮特征不变就直接跳过,只有红点、头像或内容变化才重新确认。
证据:v1.9.13 现场修复,服务号过滤不再消耗回复预算、缓存命中不再调用视觉模型;每命中一次,避开一次约 5–25 秒的无效打开与读屏。
以前点击发送后,还要再调用一次视觉模型判断“是否真的发出”;现在直接比较输入框清空、消息区出现新气泡等本机画面变化。
证据:改动说明记的收益是“省一次 2~10 秒的大模型往返”。曾出现过的“18.5 秒 → 1.8 秒”是两个不同案例的分段相减,中间混着网络与卡顿,不作为本项收益。
发送前确认对象时不再读大块聊天画面,只读窗口顶部的客户名称,并改用更小的视觉模型;看不清仍然停止发送,防错发的闸没有放松。
证据:该环节实机分段样本约 1.7–3.7 秒;改动说明记的收益同样是“省一次 2~10 秒的大模型往返”。
| 归因层级 | 原因 | 具体做法(通俗说明) | 收益口径 |
|---|---|---|---|
| TOP 1 | 看过的无关窗口不再重复打开 | 已经确认是群聊、服务号或黑名单的窗口先记住;下一轮没有变化就跳过,有新消息才重新看。 | 每命中一次少等约 5–25 秒;命中与否取决于列表里有多少无关会话。 |
| TOP 2 | 发出去后自己确认,不再问模型 | 以前发完还要再问一次“到底发没发”;现在直接看输入框是否清空、聊天气泡是否出现,看到就算发送成功。 | 省一次 2–10 秒的大模型往返。 |
| TOP 3 | 认人只看标题条,并换成小模型 | 发送前只读窗口顶部的客户名称确认对象,不再读大块聊天画面;看不清就停下不发。 | 省一次 2–10 秒的大模型往返;该环节实机 1.7–3.7 秒。 |
| 其他原因 |
| ||
最终口径:当前速度已经足够支撑日常自动回复,18–20 秒左右可以让客户感知为“很快就回了”。大范围持续运行的基础流程已经具备;后续要盯的是生成阶段慢尾、不同设备的成功率和异常停发,确保扩到更多设备后仍保持同样体验。