7 天召回 · 部署与验证指南

① 谁会被召回：入池 4 个条件，全满足才进

这四条每天扫一遍自动判定。他一旦回复，「最后一条」就变成他发的 → 第 2 条自动不成立 → 当天起不再召回（自清场，不用人管）。

② 发什么：7 个话题怎么挑、怎么排

客户首次进池那一刻，系统让 AI 看他的抖音+企微对话和画像，从下面这个话题库（甲方话术 9 类 + 4 个画像钩子，共 13 项）里挑出 7 个最可能戳中他的、排好顺序、一次冻结（后面 6 天都照这份走，不天天重挑）。

AI 选中话题的 3 条标准：

1. 贴他的实际诉求和画像——他最初求什么、聊到过什么（户型 / 面积 / 城市 / 风格 / 预算 / 顾虑），就优先选相关话题。
2. 画像钩子只在画像真有对应信息时才选——比如没读到城市/户型就不选「同小区实拍」，防止 AI 脑补穿帮。
3. 由浅入深排序——先勾兴趣、再谈价值、后推行动，不会第 1 天就硬推报价或催名额。

选好后，每天取当天那个话题，结合他的画像写成一条自然的、主动勾回的话，不是干巴巴甩海报——实测里客户就是被「重复自我介绍 + 重问已知信息」这种话问沉默的。

③ 发几次、隔多久：节奏时间线

前 3 次每天一条；连推 3 次他都没回应 = 暂时不想聊，系统自动放慢到隔天一条，把剩下 4 次摊开——既保持节奏、又压低骚扰/拉黑/封号风险。7 个话题走完约 1.5 周。（这就是你定的「连推 7 天、遇信号退避」。）

④ 随时可能提前出库：三个停止条件

1. ✅ 建企微销售号的账号行 —— 已由我建好（每个操作员一行）

   召回按各自账号走、按人设隔离（只发自己的客户）。已建好这两行，阶段 B 填你自己那行的 id：

   操作员	persona	AKKE_ACCOUNT_ID（阶段 B 用）
   野荞（小文）	xiaowen	0242b7ff-e003-44df-b929-ce71722e6853
   饭粒（小范）	xiaofan	a78b96e9-5acb-4946-ae5a-f365e0854acb
   夏夏（小夏）	xiaoxia	e494e462-21dd-445b-b1b5-1327861c12ed
   Gus（小武）	xiaowu	297b50a4-6ade-4070-b934-18d456ba0941
   子扬（小杨）新	xiaoyang	89aff532-3657-4f7a-a2f3-149f4182d2fb

   加新人要做两件事，别只做一件：
   ① 建账号行：channel_pref='wecom' + wecom_persona=<key>，零代码。
   ② 确认这个 persona key 在代码里存在（SALES_PERSONAS，src/lib/llm.ts）。这步不是零代码 —— key 不在注册表里不会报错，而是静默回退成小艳（抖音 DM 的默认人设），企微那套价格口径、风格块、召回专属块全都不生效，人却照发。小杨（xiaoyang）是 2026-07-21 新加的第 5 个壳，已在代码里。

2. ✅ persona 已随账号设好 —— 不用再动 Vercel

   人设现在设在账号行上（accounts.wecom_persona=xiaowen），已建好。每个操作员的账号带各自人设、只发各自客户，互不串。全局 WECOM_RECALL_PERSONA 只在账号没填时兜底 —— 各操作员不用设。
   真发总开关已于 2026-07-21 打开（改的是代码默认值，Vercel 那边不用设也设不了），细节见阶段 D。

Select-String -Path C:\akke-wecom\.env -Pattern "AKKE_WECOM_CROP_RATIO"

1. 停当前正在跑的 loop

   ni C:\akke-wecom\wecom_reply_STOP
   Get-CimInstance Win32_Process | ? {$_.CommandLine -like '*wecom_reply_loop*'} | % { Stop-Process -Id $_.ProcessId -Force }

2. 把两个脚本更新到新版（wecom_reply_loop.py + measure_wecom_coords.py）
   🟢 2026-07-21 起：所有机器统一走这一条，不用管有没有 git 仓库

   upio.ai 上那份分发脚本以前一直没人维护、冻在 v2026-07-02.11，现在已同步到最新并会持续更新，直接拉就行：

   cd C:\akke-wecom
   copy wecom_reply_loop.py wecom_reply_loop.py.bak-$(Get-Date -f yyyyMMdd)   # 先备份，回滚用
   iwr https://upio.ai/akke/wecom-chat/wecom_reply_loop.py -OutFile wecom_reply_loop.py

   核对版本号，必须是 v2026-07-20.redblue-test-22 或更新：

   Select-String -Path wecom_reply_loop.py -Pattern '^VERSION'

   ⛔ 别从 jsDelivr 镜像拉 —— 那个冻在 v2026-07-02.11（旧版、没召回）。
   有 git 仓库的机器（C:\Users 下能搜到 .git）也可以照旧 git pull 后 copy，两种都行；measure_wecom_coords.py（量坐标用，只有初次部署/换分辨率才需要）仍走 git 或人工传。

3. .env 加召回 4 变量（RECALL 先关，AKKE_ACCOUNT_ID 填你自己那行）

   把 <你的账号id> 换成阶段 A 表里你自己那行（野荞 0242b7ff… / 饭粒 a78b96e9… / 夏夏 e494e462… / Gus 297b50a4…）：

   Add-Content C:\akke-wecom\.env "`nAKKE_WECOM_RECALL_ENABLED=0`nAKKE_ACCOUNT_ID=<你的账号id>`nAKKE_WECOM_C_SEARCH=`nAKKE_WECOM_RECALL_CLAIM_LIMIT=2"

4. 量搜索框坐标 → 填进 .env

   cd C:\akke-wecom
   python measure_wecom_coords.py

   鼠标悬停在企微左上角搜索框上，它打印 AKKE_WECOM_C_SEARCH=x,y；把这行填进 .env 的 AKKE_WECOM_C_SEARCH=（纯读坐标，不点击不发消息）。

5. 删 STOP + 重启，确认没搞坏现有功能

   del C:\akke-wecom\wecom_reply_STOP
   cd C:\akke-wecom
   .\start-wecom-reply.bat

   黑窗第一行的版本号带 recall-b3（或更新的 recall-bN）就对 —— 说明拉到的是含召回的新版；要是还是旧的没 recall 字样的版本，说明 git pull/copy 没成功，回上一步重来。此时召回还关着，原来的被动自动回复应照常工作。

1. ✅ 本机 dry-run —— dev 机器（有 repo）上跑，已由我跑过

   这步在有代码仓库的电脑上跑、不是云电脑，同事不用管。已跑过，结果：选出 5 个候选、话题/话术正常。需要重跑时：

   # 务必带 eval key，不烧生产额度
   AKKE_USE_EVAL_KEY=1 AKKE_ORG_ID=00000000-0000-0000-0000-000000000001 \
     pnpm tsx scripts/_wecom-recall-dryrun.ts --max=10

   ⚠️ 候选里可能混着测试/误加的联系人（实测见到 fanny、某工程师号）。真上线前扫一眼那几个候选是不是真客户，不是的把会话标 handed_off 排除。

2. 云电脑 DRY_RUN：空跑验召回腿（野荞做）

   用记事本打开 C:\akke-wecom\.env，把这两行改成：

   AKKE_WECOM_RECALL_ENABLED=1    # 打开召回腿
   AKKE_WECOM_DRY_RUN=1          # 只空跑不真发

   存盘后重启（建 wecom_reply_STOP → 删 → 跑 start-wecom-reply.bat）。看黑窗日志走完一整条但不真发：

   [recall] claim 到 N 条待召回  →  搜人  →  身份门读标题  →  点开  →  [DRY_RUN] 不真发

   重点验三件事点得准：搜到人 · 身份门读对标题 · 点开对话，顺便看红点探测。坐标偏就回上一步重量搜索框。

   ⚠ DRY_RUN=1 是全局的

   这期间被动自动回复也会暂时只空跑不真发（同一个开关管整个 loop）。所以别在 DRY_RUN=1 状态停太久；验完召回腿点得准，就进阶段 D 把 DRY_RUN 改回 0，被动回复 + 召回一起真发。

1. 云电脑侧开腿，日限压到 5

   确认阶段 C 都点得准后，在自己那台的 .env 里：

   # 云电脑 .env  AKKE_WECOM_RECALL_ENABLED = 1
   # 云电脑 .env  AKKE_WECOM_DRY_RUN = 0
   # 云电脑 .env  AKKE_ACCOUNT_ID = <阶段 A 表里你那行>

   重启，盯账号状态没异常再慢慢往上爬。任何异常先建 wecom_reply_STOP 急停（见下方急停回滚）。

   服务端日限默认 WECOM_RECALL_DAILY_CAP=5（每号每天最多 5 条），云电脑侧还有一层独立日限 AKKE_WECOM_RECALL_DAILY_LIMIT=5，两层都在，取严的那层。

2. 第一批盯什么

   队列里出现 pending 新行 + 云电脑日志出现 [recall] claim 到 N 条待召回 = 通了。然后看三件事：

   ① 发出去的话像不像你本人说的（人设对不对）；② 有没有 身份门不匹配 的日志（搜到人但开错会话，不发是对的，多了就要查名字）；③ 发完有没有红色感叹号（被删 → 那人自动出库）。

Vercel 环境变量（服务端大脑）

云电脑 .env（发送端，C:\akke-wecom\.env）

对齐企微平台规则 · 调研 2026-07-16

企微给客户发消息分三条通道、规则各不同——我们的召回只走第三条「好友单聊」，运营听到的「只能连续发 7 天」是另一条通道（群发）的事，不约束我们。

好友单聊没有硬性条数上限，真正的约束是风控（触发 → 限流停 24h 甚至封号）。上面那两块护栏，正是对着风控每条红线做的：

# 1. 自己那台停消费     .env 设 AKKE_WECOM_RECALL_ENABLED=0  ← 最快，派了也没人取
# 2. 全局停派单        有 Vercel 权限的人设 WECOM_RECALL_AUTOSEND_ENABLED=false，或 revert 5aa5e294
# 3. 云电脑一键急停     在 C:\akke-wecom\ 建空文件 wecom_reply_STOP

数据库要回退整套表：跑 supabase/migrations-rollback/20260716120432_wecom_recall_rollback.sql（drop 新表/RPC，无数据依赖）。