Windows 个人微信：自动回复和召回是怎么跑的

客户发来消息，电脑这边怎么回

程序一直在转圈：看红点 → 点开 → 认人 → 读消息 → 问云端 → 发出去。整个过程只有两小段要占用微信窗口，每段一两秒，其余时间销售照常用电脑。

1. 盯红点每 3 秒看一眼会话列表最上面 8 行，有红点就是有未读。一次只处理 1 个人，刚处理过的人排到最后。
2. 礼让销售销售 4 秒内动过键盘鼠标、微信又不在最前面，就先不动手。红点留着，下一圈再来。
3. 点开前先瞄一眼这一行截下这一行，让小模型读名字：像公众号的、在黑名单里的，不点。微信团队、微信安全中心来消息只报警、不点开，点开红点就没了，销售会看不到。
4. 点开会话抢到前台 → 点这一行 → 滚到最底 → 截图 → 马上把前台还给销售。
5. 认人读窗口顶部的名字，备注必须是客户格式：（抖）+ 省份简称 +（字母）+ 6 位编号 + 名字 +（手机号）。不是这个格式的就到此为止，正文都不读，同事、朋友、系统号都这样挡掉。群聊另有两道关卡单独拦。
6. 读消息用读图模型读聊天区：左边是客户，右边是我们。我们最后一句之后客户连着发的几条，就是这一轮要回答的问题。模型说是客户，像素却显示在右边的，按我们自己发的算。
7. 过规矩这几种情况不回：最后一句是我们说的；客户这句已经超过 24 小时（改去翻聊天记录，交给召回）；不在 9:00–22:00；只剩系统提示。
8. 问云端把客户名、这一轮的几句话、屏幕上最近 6 条送给云端，等它回一句话，以及要不要配图。这一步不占电脑。
9. 发之前再核一遍重新读顶部名字，确认还是这个人；确认销售没在输入框里打字。
10. 发出去，并确认真发出去了粘贴 → 确认字进了输入框 → 回车 → 看三条证据：输入框清空了、消息区变了、最新一条在右边。至少两条成立、且没有红叹号，才算发出。有图再发 1 张。最后告诉云端「发出去了」，云端这时才把这句记进聊天记录。

电脑每一圈的先后顺序：先回未读消息，其次召回，最后翻聊天记录。召回和翻记录只在没有未读、销售离开键鼠满 60 秒时才做。有一个例外会把顺序反过来，见第 6 部分第 3 条。

回什么，由云端决定

电脑只负责搬运。云端收到一轮客户消息后，依次做这几件事。

1. 认是哪个销售每台电脑绑定一个销售身份（人设），一台一个。身份被停用，就不回。
2. 判断是不是新话这一轮的话库里都已经有了，就不回。两种情况会补答：上一句客户话还没回过，或者客户已经等了 5 分钟以上。
3. 先按规矩分流有几种情况不交给模型写，见下方。
4. 出话问价、而且面积算得出：直接用算好的报价。常见问题：用模板。其余交给大模型写。
5. 写完过闸，再交回电脑见下方的闸表。

先按规矩分流

• 要找真人、投诉、施工出事、改合同，或者连续两次拒绝转人工：不回，推一张飞书卡。
• 客户明确不要了：别联系、签了别家、已经装完、不装了回一句固定的收尾话，之后不再追。
• 我们已经收尾，客户只回一句「好的」只记录，不回。
• 这个会话已经转人工不回。24 小时后客户再来、且没有负面的话，自动接回来。

大模型写回复时看了什么

• 销售人设
• 当前阶段的规则（培育期 / 决策期）
• 最相关的 3 篇知识文档
• 决策规则
• 素材库
• 甲方审定话术
• 客户画像和聊天摘要

个人微信专用要求：2–3 句，尽量不超过 50 字；先答客户这一句；一次最多问一个问题；已经知道的不再问；别每条都喊名字。模型是 qwen3-235b（2507 版），和企业微信用的是同一个。

写出来以后还要过的闸

今天（#1411）修掉了投递闸的两个误判

第二个误判：模型用「几百一平」这种口语报价，闸不认「一平」，把正确的报价也换成了问城市。现在块、一平、每平、平米、平方这几种说法都认。还在砍价的不算拒绝；这套判断只影响这一轮话术，不写库，也不停召回。

召回：给谁发、什么时候发、发什么

召回任务全部由云端挑、云端写。电脑只负责找到人、发出去（第 4 部分）。召回不经人工审稿，自动发出。

两种人会被召回

• 我们说了最后一句，客户 24 小时没回普通召回，最多 5 次（话题一到五）。
• 客户说了最后一句，超过 24 小时没人接这时不直接回旧话，先把聊天记录翻全，再排召回，最多 7 次（话题一到六，第 7 次回到话题二、换个说法）。

另有几种专项召回：按聊天历史或按备注名只发话题一（每人只发 1 次），以及人工触发一次的第二轮。它们用的是同一套名额和关卡。

节奏：拿一位客户举例

• 周一 15:00
  销售最后说了一句，客户没回
• 周二 15:00 起
  可以发第 1 次
  一句承接话 + 话题一 + 2 张图。假设 16:10 送达。
• 周三 16:10 起
  发第 2 次（话题二）
  每次都从上一次真正送达的时间往后数 24 小时，不是从计划时间数。
• 周四到周六
  依次发话题三、四、五，发完就停
• 任何一天客户回了话
  排着的召回作废，交给自动回复
  之后我们说完最后一句，再从头数 24 小时，从还没讲过的话题接着发。问过价的客户优先发话题五。
• 当天名额满了，或者过了 21 点
  顺延到第二天 9 点以后

说明书里写的 day 1 / 3 / 7 / 15 / 30 只是第几次的编号，不是间隔天数。9 月 16 日起改成了每次间隔一天。

名额

• 每台电脑每天 5 条按北京时间自然日算；普通、超过 24 小时、话题一这几类共用这 5 条（第二轮不占名额）。
• 可以临时放宽普通召回最多放到 20 条，按备注名召回最多 40 条；必须同时写一个 12 小时内的到期时间，过期自动回到 5 条。
• 同一台电脑两条之间至少隔 10 分钟；同一个客户一天最多 1 条同一时间一台电脑只发 1 条。
• 晚 9 点到早 9 点不派可以临时延长，最多延 12 小时。

发什么

每条召回 = 一句承接话（大模型写，6–40 字，不许带数字、价格、约时间；写得不合格就不加）+ 话题原文 + 可能加一句问装修进行到哪一步 + 配图（最多 2 张）。

客户已经听过的话题（包括销售用群发助手发过的），会换一版人工确认过的新说法；一版确认过的都没有，这条先不发，6 小时后再看。详见 讲过的话，换个说法再讲。

这些情况一定不发

• 群、公众号；备注不是客户格式，或带着群、客服、测试这类字
• 已成交或在售后：阶段是成交，或客户说过交了定金、签了、装好了、找了别家
• 明确拒绝（别再发、不需要了）。之后又问价、问量房的，算回心转意
• 犹豫（不要吧、先不用了）：停 30 天
• 客户正在等我们回，又不符合超过 24 小时那一类
• 聊天记录没翻全、时间对不上、认不出客户在哪个城市
• 运营把这位客户关了、这台电脑被暂停、销售身份停用
• 这位客户有一条说不清发没发出去的，在等人核对
• 今天已经给他发过

人只在三处插手：确认新说法；处理等人核对的飞书卡片；决定每台电脑是真发还是只出稿。

召回在电脑上怎么发出去

比自动回复多两道保险：发之前往上读一遍聊天记录，按回车前先向云端报备。

1. 等空档没有未读、销售离开键鼠满 60 秒才开始；中途来了新消息，立刻让路。
2. 领任务每 5 分钟问云端一次，一次领 1 条（按备注名召回时 15 秒问一次）。
3. 先筛一遍备注里写着已定、无需求、不需要、已到店、成交的，直接退回。
4. 找人点搜索框，像人一样一个字一个字打 6 位编号，不打全名；搜索结果连续两次认成同一个人才点；点开后再核顶部名字。
5. 往上读聊天记录从最底部往上一屏一屏读，读到客户说的话就停，最多 8 屏。读到的内容交给云端再判一次：云端可以改稿，也可以叫停。读完滚回最底部。
6. 打字像人一样逐字打进去，核对字真的进了输入框。
7. 按回车前先报备云端同意了才按。本机账本上记着这一轮已经发过的，绝不重发。
8. 确认发出，回报云端和自动回复一样看像素证据，还要确认没弹出需要好友验证。成功了告诉云端，云端推一张飞书回执卡；说不清发没发出去的，这位客户冻住，转为等人核对。

空闲时翻聊天记录（为召回做准备）

没有召回任务时，电脑趁销售不用的空档，把老客户往上几屏的聊天记录读出来，交给云端建客户画像。云端靠它判断这个人该不该召回、从哪个话题讲起。

• 每次只读 1 屏
• 同一个客户读满 8 屏收工，24 小时后再来
• 同一屏读两遍一致才算数
• 读完一定滚回最底部
• 不发任何消息
• 每天最多 30 屏

真发还是只出稿，两边各有开关

三台电脑现在是什么情况

9 月 18 日 15:00–15:10 从个微电脑端看板和数据库查到的状态，只是一张快照，不是结论。实时情况看 个人微信电脑端看板。

召回任务全量：已发出 105 条、排队 145、正在发 1、作废 43、等人核对 29。最后一次发出是 9 月 16 日 21:53，销售 B那台。

已知问题，还差什么

标了按代码推断的，是从代码里读出来的，还没在销售的电脑上验证过。

1. ① 召回从 9 月 16 日晚上起一条都没发出要人去查

   145 条在排队，29 条等人核对。先看等人核对的飞书卡片，再逐台对一下第 5 部分那张表：销售 A那台离线、真发开关也到期了；销售 A那台要看电脑上是不是还在预览；销售 C没就绪；销售 B放宽了名额却一条没发出。

   做完的样子每台电脑要么有当天的召回回执，要么写清楚为什么不发。

2. ② 夜里来的消息，第二天不会自己补回要改代码按代码推断

   9:00–22:00 这道判断排在点开会话、读完屏之后。所以夜里的红点照样被点掉，读屏的钱照样花，然后这条就跳过了。第二天客户如果不再说话，这条一直没人回。

   做完的样子夜里不去点红点；或者第二天早上把夜里的消息补回。

3. ③ 话题一模式开着时，这台电脑的普通自动回复不跑要改代码或改设置按代码推断

   这个模式可以由云端远程打开。打开后，电脑每一圈只管召回，根本不看未读。销售 C那台云端现在就开着这个模式。

   做完的样子要么召回和自动回复能同时跑，要么这个模式只在明确的时间段里开，到点自动关。

4. ④ 出厂只允许发 1 张图，召回大多要 2 张要改设置

   话题一、二、四、五都带 2 张图。没改过这项设置的电脑，这些召回会一律退回、不发。已经真发过召回的电脑都手动改成了 2，新装的电脑要记得改。

   做完的样子出厂默认改成 2，或者装机清单里写上这一步。

5. ⑤ 云端说不用回，电脑会白白再问 3 次要改代码

   云端把不回的原因放在一个字段里，电脑去读的是另一个字段名，读不到就当成重复请求，而重复请求被设成可以重试。不会多发给客户，但会多花几次调用，日志里也看不出真正的原因。

   做完的样子电脑读对字段，日志里能看到云端给的真实原因。

技术细节（给开发看）

代码在哪（wecom-chat 仓）

• 电脑端：cloudpc/windows-weixin/，入口 main.py，主逻辑 runner.py；召回 recall_client.py / recall_presend.py / recall_delivery.py；翻记录 idle_history.py / history_*.py。
• 请求云端：cloudpc/weixin-shared/weixin_relay.py。路径：电脑 → Fly 中转 akke-wecom-relay → /api/wecom/chat/reply。自动回复和召回共用这个入口，按 action 区分。
• 回复：src/app/api/wecom/chat/reply/route.ts、src/lib/wecom/weixin-client-context.ts（投递闸）、src/lib/wecom/churn-signals.ts（#1411 拒绝判据）、src/lib/llm.ts。
• 召回：src/lib/wecom/windows-recall-service.ts（接口）、windows-recall-policy.ts（节奏）、src/lib/wecom-recall/fixed-five.ts（话题原文和配图）、recall-bridge.ts（承接话）、recall-guard.ts（拒绝 / 成交 / 犹豫判断）。
• 领单函数 windows_recall_claim 在 supabase/wecom-ddl/，手工执行；9 月 17 日前的 Windows 相关文件都已登记在 wecom_ddl_applied。

召回接口和状态

• 电脑调：windows_recall_poll → windows_recall_context（发前读取，最多 80 条）→ windows_recall_current / windows_recall_arm → windows_recall_complete 或 windows_recall_fail；翻记录用 windows_history_import。
• 任务状态只有 6 个：pending → claimed → armed → sent，另有 cancelled、needs_review。claimed 超过 10 分钟退回 pending；armed 不会自动回收；needs_review 没有自动出口，只冻住这一位客户。
• 领单需要电脑端 1.14.54 以上（发前读取），旧版本照常轮询但领不到任务。
• #1409 只改了 src/lib/wecom-recall/dispatch.ts 的企业微信 DAILY_CAP（100→20）；Windows 的上限在 windows_recall_claim 里，默认 5。

关键数字

项	值
轮询间隔	空闲 3 秒（出厂配置；代码默认 8 秒），刚干完活 1 秒
读屏模型	正文 qwen3-vl-235b，失败换 30b；认人和列表预判先用 30b。读超时 45 秒
置信度门槛	正文 0.92 / 标题 0.85 / 列表预判 0.93 / 召回搜索结果 0.98
自动回复节奏	9-22 点；两条最少隔 8 秒（实际抖到 8–15 秒）；日 / 时 / 单客上限默认不限
请求云端超时	连接 5 秒、读 30 秒（云端最长可跑 120 秒，超过 30 秒靠重试 + 云端补答接住）
被踢下线熔断	登回来后停 30 分钟，7 天内再犯翻倍，封顶 2 小时
心跳	180 秒一次，带版本、最近结果、召回进度，不带客户名
召回重试	确定没发出：15 秒 / 45 秒 / 2 分钟，之后每 30 分钟；发前读取连续失败 3 次作废

代码和说明书对不上的地方

• 电脑端 README 的更新记录停在 v1.12.0，代码已到 1.14.55；开头还写着「真机未验」，实际 8 月 27 日起已经真发过。
• README 说超过 24 小时的尾消息召回发完即止，代码里是最多 7 次。
• README 写的演习开关名 AKKE_DRY_RUN 不对，实际是 AKKE_WEIXIN_DRY_RUN。
• 有两个 STOP 文件位置：启动日志让人在 state\STOP 建，暂停脚本建的是安装根目录下的 STOP。

其他从代码读出来的小问题（未在真机验证）

• 回执失败会写进 pending_confirms.json，但读它的 take_due 全仓没有调用：只写不读。
• 冻结名单和去重记录只在内存里，程序重启就清空。
• 程序重启后第一圈只记下当前画面，当时开着的会话里已有的客户消息不会回。
• 粘贴会覆盖销售剪贴板里的内容。
• 营销终态（客户说不要了）和选择题两条路不经过投递闸；终态判断里「已交定金」会被归成签了别家。
• 第二轮召回沿用第 1 次任务的锚点，在按备注名召回模式下可能领不到，普通模式下可能被当成客户情况变了而作废。