从「夏夏拉不到 DM」一路挖到抖音 API 的 6 天延迟 + Playwright 解法 + 「终端↔Lark 远程操控」设计 · 2026-06-13
起因是运营反馈「夏夏的云电脑今天才拉到 4 条 DM」。顺着查下去，发现这不是某个号坏了，而是整条「抓取→打分→派单」链路被抖音 API 的一个平台限制卡住了喉咙。本页是这轮诊断的完整账本。
| 问题 | 真因 | 处置 |
|---|---|---|
| 野荞云电脑一直没自动发 | 账号 dispatch_paused_until 被人为静音到 6-14（不是她记的"早 9 点"那条，那条早过期了）。派单系统见到未来时刻即跳过该号，队列不灌单 | 已清空静音（7→恢复派单），并在「智能获客日常小分队」@野荞 说明 |
| 夏夏今天才拉到 4 条 | 夏夏=零星号，号没坏：每单入队几秒内就被 claim、poller 一直在拉。问题是一整天只派进来 ~10 单 | 见下文——是供给侧饿，不是她的号的问题 |
fresh_window_minutes，PM 2026-06-10「不满足时效性不发送」）/aweme/v1/web/aweme/post/ 接口对匿名调用有 ~6 天的"发布→可见"延迟| 今天 | 昨天 | 前天 | |
|---|---|---|---|
| 高/中意向 lead | 1174 | 330 | 87 |
| 可派比例（评论 ≤7min） | 1.1% | 12.1% | 20.7% |
| ≤60min | 6.2% | 28.8% | 63.2% |
| 估算可派池 | ~13 | ~40 | ~18 |
| 视频发布距今中位 | 9.8 天 | 9.9 天 | 11.1 天 |
| 视频 ≤3 天发布 | 0% | 0% | 0% |
反直觉点：今天 lead 量是昨天 3.5×，可派池反而缩水（13 vs 40）——量越灌越多，能用的越少。
| 口径（今天 1170 条高/中意向） | 值 |
|---|---|
| 用户发评论 → 我们打完分 中位延迟 | ≈ 2661 分钟（约 44 小时） |
| comment_time ≤7min（可派） | 1.0% |
| 我们自己流水线（抓到→打完分）中位 | 0.9 分钟（97.2% 在 7min 内） |
内部流水线 97% 在 7 分钟内完成——快得很。慢的不是我们，是抓进来的评论本身就老。
| 今天抓到 6666 个视频，按发布时间 | 占比 |
|---|---|
| 发布 ≤24h | 0 个（0%） |
| ≤72h（3 天） | 0 个（0%） |
| ≤7 天 | 13 个（0.2%） |
| 全库最新的视频 | 发布于 7 天前（167h） |
全库按发布时间排最新的视频全部卡在 ~167h（7 天）——这条线特别齐，是平台限制的指纹，不是号主发帖规律。
| 今天 | 昨天 | |
|---|---|---|
| 抓取视频总数 | 6666 | 150 |
| 涉及不同号源 | 961 | 90 |
| 发布 >7 天（派单无效） | 100% | 100% |
2026-05-28 实测（"小米·全屋定制"5/27 视频）：匿名签名接口 5/28 仍不返回该视频、且只给前 ~5 条；同一视频用登录身份或浏览器渲染主页都能立刻看到。
| 路径 | 响应快慢 | 数据新旧 | 代价 |
|---|---|---|---|
| 匿名 API（现在用的） | ⚡ 快（亚秒） | 🔴 旧（最新 7 天前） | — |
| 登录 cookie 打同一接口（B） | ⚡ 快（亚秒） | 🟢 新 | 暴露我们身份给竞品 |
| Playwright 渲染主页（A） | 🐢 慢（15-30s/号） | 🟢 新 | 慢 / 抢浏览器 |
好消息：discover_videos_from_profile（discoverer.py）已内置 Playwright DOM 抓取——现在是"API 失败才兜底"，所以 API 一成功就 return、永远轮不到它。改动 = 给选中的号跳过 API、直接走那段现成的 Playwright，不是新写。
source_accounts.playwright_discovery 布尔列，人工圈"最近真出可派 lead + 发帖勤"的高频号——目标 100 个（摊到抓取周期，2 台机器约 17min/轮，扛得住）。PLAYWRIGHT_DISCOVERY_ENABLED（默认关，灰度开，秒回滚）。/send cron 已停（发送搬去 ADB/WDA/云电脑），Fly worker 浏览器主要给抓取，争用低；维持每机器 1 Chromium 单例防 OOM。comment_time ≤7min 占比往上抬。/health 探活。| 项 | 状态 |
|---|---|
野荞 dispatch_paused_until 清空（恢复派单） | ✅ 已做 |
| 「智能获客日常小分队」@野荞 说明原因 | ✅ 已发 |
饭粒-一筑 DM fresh_window_minutes：7 → 10 | ✅ 已做（提醒：7→10 几乎不增量，真量靠 Playwright） |
| 反评（RC）想设 10min | 未做 RC 现在无任何时效闸（全池捞），已是最大量；加 10min 闸要改代码且会减量，与"提量"相反 → 停，等确认 |
| Fly 东京 IP Playwright 取新视频验证 | 待跑 决定"用不用 Mac"的前置 |
| 圈定 100 个高频号源名单 | 待跑 验证通过后 |
目标：fanny 人在外面 →（出站）Claude 有结果推她个人 Lark；（入站）她从 Lark 发指令 → 终端 Claude 执行。
脚本 / Claude 用 lark-cli im +messages-send --as user（或 bot）推到个人单聊/群。本轮已在用（@野荞 那条就是）。结果卡片、链接、告警都走这个，零开发。
| 路 | 怎么做 | 优点 | 缺点 |
|---|---|---|---|
| A. /loop + handle-lark-requests 最现成 | 已有 skill handle-lark-requests（拉同事 Lark 单聊、按授权自动处理、以本人身份回）。用 /loop 5m 让常驻 session 每几分钟轮询 fanny↔bot 新消息、解读成指令并执行 | 现成、零开发，今天就能用 | ① Mac 要开着 + loop 一直跑；② 轮询有 interval 延迟；③ 要 allowlist 限可自动执行的动作 |
| B. lark-event consume + headless Claude 更实时 | lark-cli event consume 把 Lark 消息当 NDJSON 实时流出；写常驻 bridge：消费 fanny→bot 消息 → 调 headless claude -p "<指令>"（Agent SDK / 无头）执行 → 结果 push 回 Lark | 实时，不靠轮询 | 要开发 bridge + 跑 bot 长连接；Mac 仍要开着 |
| C. Claude Code 手机/网页端 最省事 | Claude Code 有 claude.ai/code 网页 + 手机端，在外面直接用手机发指令 | 零开发、官方、完整工具 | 不是"在 Lark 里"，要切 App |
caffeinate 设不休眠，要么把常驻 agent 搬到已经 24h 常开的机器（无影云电脑 / Fly）。
/loop + handle-lark-requests，今天就能起）：在一台常开机器（建议无影云电脑，免 Mac 睡眠问题）上跑常驻 loop，轮询 fanny↔bot 单聊；出站继续用 --as user 推结果。跑顺、定好 allowlist 后，想要实时再升级到 路 B。本页由 Claude Code 于 2026-06-13 自动生成，归档本轮终端对话的诊断、数据与方案。数据口径：Supabase 生产库 comments / videos / accounts / source_accounts 实时查询。诊断脚本 scripts/_diag-*.ts（_ 前缀，gitignored）。