主播导量 · 抖音账号风控应对策略

触发风控的自动识别

休息期间能做什么 / 不能做什么

✅ 已落地 · 什么场景会触发什么提示

🎯 已落地 · 运营要做的事

• 看橙牌：确认是哪个号，记一下；如果同时几个号都出橙牌，警觉一下可能要升级到红牌（见任务 3）
• 看绿牌：信息通知，无需操作；可以观察该号第二天发量是否正常
• 休息期间：该号会自动停发；运营可以做养号操作（本人浏览 feed、发 1-2 条作品、对评论区点赞回复），不要主动 DM / 关注 / 评论

⏳ 还没生效的部分

• 云电脑通道 agent 更新：每个运营需要在云电脑里更新代码 + 重启 agent（一次性操作）。配套工具 update.bat（PR #408）已经提供，运营按 PM 给的简化步骤跑即可。夏夏（零星账号）已重启完成 ✅；野荞 / 阳阳 / Gus 待跟进。

能搞定的验证码类型

技术方案

1. 检测：UIA 找到验证码弹窗节点 (关键词匹配)
2. 截图：定位验证码图片区域，保存为 PNG
3. 识别：
   - 简单字符走 ddddocr（本地）
   - 复杂场景走打码 API
4. 填写：SendInput 写入输入框
5. 确认：点提交按钮
6. 重试：失败 3 次后 HALT 走人工兜底

核心代码骨架

import ddddocr
from PIL import Image

async def auto_solve_captcha(page):
    # 1. 检测
    captcha_box = await page.query_selector('.captcha-img')
    if not captcha_box:
        return False

    # 2. 截图
    img_bytes = await captcha_box.screenshot()

    # 3. 识别
    ocr = ddddocr.DdddOcr(show_ad=False)
    code = ocr.classification(img_bytes)
    print(f"[captcha] OCR 识别: {code}")

    # 4. 填写
    input_field = await page.query_selector('input.captcha-input')
    await input_field.fill(code)

    # 5. 提交
    await page.click('button.captcha-submit')

    # 6. 等 2s 看是否过关
    await page.wait_for_timeout(2000)
    if await page.query_selector('.captcha-img'):
        return False  # 还在,说明识别错了
    return True

⛔ 卡点：最好有一个会跳验证码的号来解决

⏳ 待落地 · 拿到样本后要做的事

• 新建 worker/scripts/wuying-dm/auto_captcha_solver.py 封装识别 + 填写
• 给 douyin_dm_grounded.py / wuying_poll_agent.py 接入：弹窗预检 ➜ 命中 ➜ 调 solver ➜ 成功继续 / 失败 HALT
• 失败 3 次累计 ➜ 该号当天停 + 推 Lark 告警（不死磕；该告警会进云电脑监控群）
• 记录每条 captcha 的截图 + 识别结果 + 是否过关 ➜ 后续训练专属模型

✅ 已落地 · 什么场景会触发什么提示

🎯 红牌出现时的处理流程

1. 立刻停手：暂停所有云电脑发送（运营在云电脑里 Ctrl+C 杀 agent 或运维侧 dispatch 关闸）
2. 排查 3 件事：
   • 最近 1 小时内有没有改过 cron 时间表？
   • 云电脑 IP 段是不是变了？（无影侧 IP 偶尔会调度变更）
   • 有没有运营本人手机也在登同号？（同号多端冲突高发诱因）
3. 冷却：所有号停 1-2 小时，等告警群安静后再恢复发送

✅ 已补落地（PR #405 / #407 · 2026-06-17 下午）

• SMS / 滑块 / 人脸 modal 检测：DM 通道（PR #405）+ RC 反评通道（PR #407）都接入了截屏 + VL 识别。命中即第 1 次就停号 + 推 🚨 P0 红牌，不等累计 3 次失败。一次 VL call 同时判 rejected + modal，比拆两次省 50% 成本。

⏳ 还没生效的部分（留给后续 PR）

• 二触评论通道 modal 检测：DM + RC 已接入，二触（douyin_comment_grounded.py）同款逻辑还没复用。当前如果跑二触撞 modal 不会自动停号。优先级低（二触当前用量低），运营有需求再做。
• 升级链（3 / 6 / 10 分钟未响应升级）：DB 字段已经留了（acknowledged_at），但 cron 暂时没接超时检测。需要 Lark App 卡片交互（运营点按钮 ack），范围比较大暂缓。
• 按账号归属路由：当前所有告警都推到云电脑监控群（全员看）。一个群够看，暂不拆。
• Claude Agent SDK long-running 进程：MVP 用每分钟 cron 代替了它，已经能跑通端到端。短期不升级。

实验设计（A/B 对照）

实验周期与样本量

• 样本：每组用 3 个号，连续跑 5 天，共 15 号天/组
• 记录：每组的验证码触发率（次数 / 总发送数）、实际发送成功率
• 分析：第 6 天做汇总，输出三组的对比柱状图

实验脚本设计

scripts/_experiment-pause-strategy.ts
- --group A|B1|B2|B3 选实验组
- --account <id> 跑哪个号
- 自动按设定节奏调度,中间用 RPA 关闭抖音 PC 客户端
- 实验数据写 experiment_pause_strategy 表
- 收尾跑 _analyze-pause-experiment.ts 出对比报告

预期产出（实验后第 6 天）

• 如果 B1/B2/B3 触发率显著低于 A：把"停顿 X 分钟"加入任务 1 的节奏策略，降低整体触发率
• 如果三组都没差异：说明风控不是滑动窗口，是累积计数模型，停顿不解决问题，只能靠日限降量
• 如果 B3 显著优于 B1/B2：意味着抖音检测浏览器进程存在与否，那就把"自驱时段后期休眠云电脑"做成默认策略

⛔ 卡点：需要"已经会撞验证"的号才能跑实验

⏳ 待启动 · 拿到测试号后要做的事

• 建实验表 experiment_pause_strategy 记录每组每条发送的：时间 / 状态 / 是否撞验证
• 用 RPA 控制云电脑关 / 开浏览器（已有 wakeup-window 类似机制可复用）
• 实验严格不影响生产——用专门的 3 个测试号，不动主力号
• 每天结束推 Lark 进度卡片到云电脑监控群：今天 A/B1/B2/B3 各发了多少 / 各触发率多少