首触
普通新好友没有红点也要扫描。服务群必须核验完整群名、3 人、2 位外部联系人和唯一客户。
纯 @ 成员只作为新群激活信号，不当成客户问题回答。
WECOM CUSTOMER ENGAGEMENT SYSTEM · 2026-08-12
夏伟企微客户承接系统
从云电脑感知到服务端大脑，把新客户首触、客户消息自动回复、沉默客户召回放进同一张完整框架图；同时展示统一触达状态机、8 月 10—12 日近期 Bug，以及下一阶段 P0—P2 优化路线。
当前评估：局部回归稳定 · P0 身份闭环未完成 · 尚未执行本页优化
夏伟当前完整框架
三条业务链路共享同一套 GUI 感知、会话身份、发送确认和监控底座。
企业微信 PC夏伟云电脑 · Windows GUI
→
感知层主窗口、红点、标题、气泡、群成员
→
统一调度自动回复 ＞ 首触 ＞ 召回
→
服务端大脑身份、历史、画像、LLM、物料
→
发送确认草稿校验 → 点击 → confirm
① 新客户首触
发现新好友 / 服务群
→身份与成员门
→生成首触 + 资料
→发送确认
② 自动化回复
客户未读 / 画面变化
→发言人 + 新鲜度门
→生成回复 / 物料
→发送确认
③ 沉默召回
服务端派单
→搜索与身份复核
→召回前历史检查
→发送回执
公共底座
统一 conversationId
·三态感知
·限流 / 幂等 / 重试
·心跳 / 监控 / 版本
自动回复
服务群必须确认最新发言人是画像客户；我方消息、系统提示、撤回提示和旧历史均不可触发。
读取不确定时不发送、不推进基线。
召回
必须等客户未读和首触明确清空。每轮只领一条，发送前再次复查客户未读。
召回后的旧客户气泡有 2 分钟隔离窗口。
当前最大结构缺口
服务群首触已按完整群标题生成独立身份，但自动回复和人工补录仍可能按“xiawei:客户昵称”查会话，导致一个群分裂成两条历史。客户昵称只能负责称呼，完整群标题负责定位，conversationId 才能负责最终数据归属。
P0 · 建立统一触达状态机
首触、自动回复、召回共用一套发送生命周期，不再各自解释“成功”。
Detected发现任务，不代表可发送
Validated身份、优先级、内容通过
Drafted已生成并持久暂存
Send Attempted草稿校验后点击发送
Confirmed可视证据 + confirm 才成功
发送前失败 · Retryable
失焦、身份门失败、草稿未形成：保留 pending delivery，有限重试；达到阈值后停止自动重试。
发送后不确定 · Manual Review
发送键已经按下但拿不到成功证据：禁止自动重发，暂停主动召回，交人工核对。
感知不确定 · Unknown
不推进已读基线；前两次保护客户任务，第三次暂时让出调度，避免首触和召回永久饿死。
六条跨链路硬规则
1
同一服务群从首触到召回，全生命周期只有一个 conversationId。
2
没有 confirm，不得记录“已发送成功”。
3
unknown 读取不得推进像素或业务基线。
4
客户未读未清空时，首触和召回不得抢占 GUI。
5
召回前历史不得触发召回后的自动回复。
6
云电脑和服务端版本不兼容时必须安全拒绝并告警。
最近三天 Bug 总结
时间范围：2026-08-10 至 2026-08-12。重点不是补丁数量，而是这些问题共同暴露出的系统性缺口。
8 月 10 日 · 红点与调度单位数未读角标因宽高比阈值漏检；前台停在一个会话时另一会话红点被饿死；7 位服务群号和纯 @ 成员激活补齐。根因是视觉规则只基于有限样本、调度复用旧列表快照。
8 月 10 日 · 窗口与草稿清草稿动作可能点中通知卡片并弹浏览器，Ctrl+A 进入错误窗口。修复增加点击前标题门和点击后前台复核。
8 月 11 日 · FULL 读取吞消息红点点掉后，FULL 读取失败却提交像素基线，客户消息永久消失。现改为失败不提交；连续第三次仅让出调度，不消费失败画面。
8 月 11 日 · 主窗口误选Chrome 页面标题含“企业微信”且面积略大，导致选错窗口。现改为优先认窗口类，不认标题子串。
8 月 11 日 · 恒亮红块抑制失效首次修复按列表 y 位置抑制；企微列表换序后同一红块换行，48 次打开只抑制 1 次。现改按红块签名、双重确认和 TTL。
8 月 11—12 日 · 服务群会话分裂风险首触已按完整群标题哈希隔离，但自动回复和人工补录仍可能按昵称查会话。局部测试全部通过，端到端身份契约 0/4，是当前最大 P0 缺口。
共同根因 1 · 证据不足却推进状态
单一标题、红点、位置或气泡方向被直接当成业务事实；一旦 UI 换序、漏读或窗口相似，就会吞消息、误发或重复发送。
共同根因 2 · 修复只覆盖事故入口
首触、自动回复、人工补发、召回各自有测试，但缺少“同一客户全生命周期”的统一不变量和集成回归。
共同根因 3 · 性能优化缺反向证明
缓存、抑制、减少 OCR 的优化只证明“少点了”，却没有同时证明“不会漏接真实客户”。
共同根因 4 · 版本分时更新
云电脑脚本和服务端可能在不同时间更新；缺少兼容握手时，新旧身份或状态语义会静默混跑。
当前回归证据
Python 主循环 771/771；窗口与红点专项 22/22；TypeScript 全量 2,399/2,399。局部修复总体稳定，但服务群端到端身份契约仍为 0/4，因此不能把“测试全绿”等同于“整体可上线”。
接下来优化方案
先修身份和状态，再做调度与监控；不直接重构整条主循环。
| 优先级 | 优化项 | 具体动作 | 上线验收门 |
|---|---|---|---|
| P0 | 统一服务群身份 | resolve_group 返回 conversationId；generate、record_manual、召回全部使用权威会话；服务群禁止退回昵称键。 | 建群→首触→回复→人工补发→召回→确认始终只有一个 conversationId；两个“王辉”跨群不串历史。 |
| P0 | 统一触达状态机 | 三条链路统一 detected / validated / drafted / send_attempted / confirmed；失败分发送前可重试与发送后人工核对。 | 无 confirm 不记成功；发送后不确定不自动重发；进程重启后 pending delivery 可恢复。 |
| P0 | 三态感知 | 窗口、红点、标题、气泡结果统一为 actionable / clear / unknown。 | unknown 不推进基线、不误发；有限重试后也不永久阻塞首触与召回。 |
| P1 | 真实 UI 回放库 | 保存脱敏事故样本：20×29、33×30、44×30 红点，恒亮头像、列表换序、浏览器冒充、草稿假发送。 | 每个 Bug 都能复现；所有性能优化必须同时通过“不得漏接”的反向测试。 |
| P1 | 统一调度器 | 自动回复 ＞ 首触 ＞ 召回；每轮最多一次真实发送，发送后重新扫描，不复用旧列表快照。 | 有客户未读时首触/召回不执行；读取长期失败也不会让主动任务永久饥饿。 |
| P1 | 版本兼容门 | 请求携带 host、loop version、build channel、persona、配置指纹；服务端声明最低兼容版本。 | 版本不兼容时安全拒绝并告警，不静默退回旧身份逻辑。 |
| P1 | 影子模式 | 新逻辑只记录目标、conversationId、证据、决策和原因，不点击发送；与旧逻辑逐条比对。 | 身份差异、优先级逆转、unknown 下发送、重复发送意图均为零。 |
| P2 | 统一监控时间线 | 按客户或群串起发现、生成、发送尝试、确认、重试、召回及失败原因。 | 无需拼接 Python 日志和数据库即可回答“为什么没首触、没回复、没召回”。 |
1. 身份闭环先解决 P0
→
2. 集成测试三链路同一生命周期
→
3. 影子运行只记录，不发送
→
4. 夏伟单机灰度限量，可急停
→
5. 扩大范围指标通过后执行
当前部署门禁
不通过。应停在“身份闭环与跨链路集成测试”阶段。本页是架构评估和优化方案，不代表这些优化已经执行或部署。