云电脑评论批量化 · 0→1 复盘历史记录 · 已正名「潜在用户二次触达」并改接 second_touch_state

上游：云电脑反向评论手动版（单条已跑通，见 触达机制 0→1）
本篇：把单发工具变成 可安全批量、可重复跑、多人不撞车 的闭环 · 实测机 野荞 2560×1600 · 记录日期 2026-06-04
四个部分
  1. 第一个案例：批量闭环的第一条「如嫣」
  2. 完成 0→1 的逻辑原理图
  3. 批量化执行的统计数据 · badcase · 每类优化及进展
  4. 下一步待做的优化列表
⚠️ 本页是历史复盘（2026-06-04 首批）。当时按「反向评论首触 + reverse_comment 去重账本」记录， 下文的设计结论（「别造第二套表、复用 reverse_comment 账本」）已被推翻。 2026-06-05 该通道正名「潜在用户二次触达」：对象改为「已 DM、≥3 天没回的高/中意向」， 去重从 reverse_comment 账本改为 second_touch_state 节奏阶梯（PR #119）。 当前操作以 部署 + 操作指南 为准； 下文命令（export-leads-csv / import-comment-log）已停用，仅作历史留存。
口径诚实：本篇是闭环打通 + 小批验证的复盘，实测真发 3 条评论（如嫣 / 沈园外 / 罗洛）， 全部验证去重生效。尚未大批量放量，规模数据待回填。

一、第一个案例：批量闭环的第一条「如嫣」

背景：手动版能发，但不敢批量

手动版已经能在抖音 PC 真发出评论。但「批量化」的拦路虎不是技术，是去重：工具读 CSV 直发、不写库， 同一个人这批塞了下批又被拉进来、A 评过 B 还会评，对方体感被群发。所以批量化的第一性问题是—— 每发一条，怎么让这个人立刻从所有人的候选池里消失。「如嫣」就是验证这条闭环的第一个真实案例。

如嫣这条怎么跑完全程

① 本机备料 · export-leads-csv

claim_leads_batch 锁住如嫣（4h）→ 反查到抖音号 hongyan96488 → Langfuse 最新话术生成评论文案 → 出 CSV，带去重命门 _comment_id=7d214d26… / _sec_uid=MS4w…N-BaEm6c。

「你好，如嫣姐。刷到你新房开工视频了，开工必备清单里水电瓷砖防水这些大项，我们全屋装修都包在 568 一平里，硬装+柜体+软装不用跑断腿。你家装修到哪步了？」
↓ gzip+base64 剪贴板传无影
② 无影自动发 · douyin_comment_grounded.py

搜「鸿雁」→ OCR 身份门 match=True conf=0.98 → 开第一条视频 (645,484) → 空格暂停 → 评论 tab (2496,945) → 点评论框 (2042,1518) → SendInput 打字 → VL 定位红色「发送」(2534,1542) → ✅ 已点发送。

↓ comment_log 拷回本机
③ 本机写回 · import-comment-log

status=sent → 写 outreach_events(channel=reverse_comment) + 消费 claim。

关键一刻：她从此「全员可见地已联系」

写回后查 outreach_account_for_sec_uid(如嫣) → 返回 小文（野荞）。 意味着任何同事再 claim-leads 都不会拿到她（私信 + 评论统一去重）。 这一步是手动版做不到的——批量「安全」的开关，就是这条写回。如嫣验证了它真的合上。

二、完成 0→1 的逻辑原理图

核心原理：去重账本早已存在，别造第二套

差点要新建 reverse_comment_queue 集成 + claim/mark RPC。翻代码才发现去重账本早就建好在跑：

get_ranked_leads / claim-leads 的「已触达」判定，2026-05-27 起就 UNION 了 outreach_events.channel='reverse_comment'。即私信 + 反向评论任一触达，都算该 sec_uid 已联系。

所以云电脑评论批量化不需要新表 / 新队列 / 新 RPC——发完写一条 outreach_events， 整套去重 / 归因 / 池子热力全部自动生效。最小改动接现成基建（简洁 + 惯例优先）。

0
新建表 / 队列 / RPC
1
新脚本 import-comment-log.ts
0
改动云电脑发送工具
（log 已够 import 用）

完整数据流——本机备料 → 无影发 → 本机写回去重，三段各司其职：

① 本机 Mac · 备料（复用 DM 通道 builder）
export-leads-csvclaim_leads_batch 锁 4h
→
生成 openerLangfuse 最新话术 = 评论文案
→
出 CSV带 _comment_id / _sec_uid（去重命门）
↓ gzip+base64 剪贴板传无影（China 网络够不到我们的服务）
② 无影 Windows · 抖音 PC GUI 自动发
搜人 + 身份门OCR 核昵称，防错评
→
开视频→暂停防播完跳下一条
→
评论区→打字→发送SendInput + VL 定位发送键
→
返回键回主页VL (65,65)，给下一条腾干净状态
产出 comment_log_日期.csv（每条 status：sent / wrong_user / no_works…）
↓ comment_log 拷回本机
③ 本机 Mac · 写回去重账本
import-comment-log只取 status=sent 行
→
写 outreach_eventschannel=reverse_comment，幂等
→
消费 lead_claim释放 4h 锁
→
全员去重get_ranked_leads / claim-leads UNION 即生效
为什么写回放在本机而不是无影：无影那台在国内，网络够不到 Supabase / Anthropic。 所以「无影只负责发 + 产日志，本机负责备料 + 写库」——这也是脚本本身不查重、去重完全靠 import 这步的原因。漏跑 import = 4h 后被重新 claim 重发。

三、批量化执行的统计数据 · badcase · 每类优化及进展

大致统计（小批验证，规模待回填）

3
真实反向评论发出
如嫣 / 沈园外 / 罗洛
3 / 3
写回 outreach_events 成功
212
prod RC 事件总数
（209 + 本会话 3）
✓
去重判定
= 已触达（全员可见）
no-op
prod schema migration
DO 块守卫，数据未动
1~2/6
单批有效产出率
（detector 剔坏后）

遇到的 badcase · 每类对应优化方式 · 进展

现象 / Badcase根因优化方式进展
发送时跳出逐条 y/n 确认 无影上是旧版脚本（默认逐条确认），仓库版早已默认自动 重新部署最新版覆盖；默认自动发，--confirm 才逐条 已修
第 2 条搜到的还是上一个人
身份门 seen='上一个昵称' match=False，整批串发垮		 发完用 Esc 退不出视频浮层（评论框/视频层吃焦点，连按 4 次仍卡在视频页），下一条搜索点击落空 改点视频页左上角「返回」按钮（VL 定位 region(0,0,.3,.22)，实测落 px(65,65)）+ ocr_verify 确认回主页；可 pin AKKE_C_BACK 固定坐标 已修 · 实测一次回主页
罗洛（花体名）在 nav 坏时被判 wrong_user 上一条没复位，罗洛的搜索停在了如嫣页 → OCR seen='@鸿雁' 无需改——身份门正确拦下、没误评给罗洛，证明它是有效兜底；nav 修好后罗洛重跑即正常发出 符合预期
opener 自检剔除率偏高
海艳「吉林」未授权省 / 朦胧的雨「雨姐」自加后缀 / 开心是福 非橱柜信号		 话术质量门（detector + 自检）在 claim 阶段就剔坏文案，单批 6 claim 仅 1~2 有效 这是质量保护不是 bug；备料时多 claim 一些覆盖损耗。后续可调 detector 严格度 关注 · 备料多拉
export 一度返回 0 条（"池子空"） 不带 --intent-label 走浅扫（cap 60），top 60 全是已触达 backlog；底下其实有 70 可抢 加 --intent-label=高意向 触发深扫（cap 500）。另发现账号握 35 个未消费 claim 触发 over-claim 防护 绕过 · 待默认深扫
短名 / 大众名可能评错人 身份门 0.95 阈值对 ≤3 字短昵称可能模糊放行不同人（实测「小嘟→嘟妹」） 短名/大众名走 --confirm 逐条确认，别塞自动批；放量前收紧短名身份门（见第四部分） 待收紧

去重真生效的链路实证

以如嫣为例：发完写 outreach_events(channel=reverse_comment, status=sent) 后， outreach_account_for_sec_uid(如嫣) 立刻返回 小文（野荞）—— 她从此在所有同事的 leads 池里算「已联系」，任何人再 claim-leads 都不会拿到她。三条均已逐条验证。

四、下一步待做的优化列表