把"闹钟节奏"和"实际节奏"分开看——闹钟响得勤 ≠ 真被扫到得勤（被产能卡着）。
| 号源 | 闹钟节奏（cron） | 实际轮到节奏 | 数量/现状 |
|---|---|---|---|
| 优质号源 tier1 | 每 3 分钟（scrape-hot） | 每 ~47 分钟（被产能稀释） | 163 个 |
| 普通号源 tier0 | 每 1 小时 取最旧 150 个（scrape） | ≈ 被饿死（近期 0 覆盖） | 1019 个 |
| 视频 | 闹钟节奏 | 实际 | 现状 |
|---|---|---|---|
| 优质视频 is_vip | 每 5 分钟（vip-video-rescan） | 每 5 分钟把全部 276 个扫一遍 | ⚠️ 276 个全是 7 天前老视频＝刨老坟 |
| 最近视频 | 每 2 小时（rescan-recent-videos） | — | 受开关控制，可能没开 |
| 重新评选哪些算 VIP | 每天 04:45 一次（hot-video-rotation） | 一天一次 | 决定②里扫哪 276 个 |
| 动作 | 闹钟节奏 | 说明 |
|---|---|---|
| 抓评论 | 没有独立闹钟 | 跟着 ①号源 和 ②视频 被扫到时，把评论整片全抓回来 |
| 打标（识别高/中意向） | 每 2 分钟（analyze） | 抓回来后由 LLM 逐条分拣"高/中/低/无关" |
| 层级 | 3分钟快道挑不挑？ | 实际逻辑 |
|---|---|---|
| 优质号源 | ✅ 就挑这个 | 选 tier1 号（被证明产过高意向的 163 个号） |
| 优质视频 | ❌ 不挑 | 抓这个号主页最新的视频（tier1 取最新 20 条），按时间排，不按质量 |
| 优质评论 | ❌ 不挑 | 把视频下符合时间窗的评论全抓回来，之后再由 LLM 逐条打"高/中/低/无关"标 |
大白话：3 分钟快道做的事 =「先挑出好号，然后去它主页把最新几条视频翻出来，把这些视频底下的评论一股脑全抓回来」。
"优质评论"(高意向)不是抓的时候挑的，是抓回来之后另一个程序（analyze 打标）识别的——抓的时候不知道哪条是高意向，先全捞再分拣。
三个"优质"对应到不同程序（彻底分清）：
scrape-hot（3分钟，挑好号 → 抓它最新视频的评论）vip-video-rescan（5分钟，挑 is_vip → 复扫它新评论）← 在刨老坟、要砍的那个数据库里 source_accounts.tier 这列的官方定义（注释已于 2026-06-13 对齐真实节奏）：
| tier | 是什么 | 走哪条道 | 数量（最新） |
|---|---|---|---|
| 0 | 默认/普通号源（新加的号默认就是 0） | 1 小时慢道（scrape，priority=5） | 1019 active |
| 1 | 优质号源（被证明产高意向） | 3 分钟快道（scrape-hot，priority=1） | 163 active（101 原 + 62 升） |
实测全库 distinct 值确实只有 0 和 1。列类型 SMALLINT 无 CHECK 约束，技术上能填 2/3；快道索引用的是 WHERE tier > 0（不是 =1）——当初预留了加更多级的口子，但至今没实现。
auto-tier1 cron（每天 01:00）——非 tier1 活跃号，近 3 天高意向 ≥5 条 → 自动升。| 快道号数 | 产能 | 每个号实际多久被抓一次 |
|---|---|---|
| 101 个（之前） | ~200/h | ≈ 每 30 分钟 |
| 163 个（今天提拔后） | ~200/h | ≈ 每 47 分钟 |
多了 62 个号（+61%），同一块产能分给更多人 → 30min × 1.61 ≈ 47min。纯粹是除法。（系统还有条规矩：30 分钟内抓过就跳过，所以一个号最快也就每 30 分钟一次。）
先分清：「新鲜视频」≠「新鲜评论」。一条视频发出后，评论不是一次性来完——发出后第 2、3 天还在持续有人评论。所以"过两天再扫一次"本意是对的：捞它这两天新冒出来的评论，这些可能就是新鲜高意向 lead。
但现在的复扫方向反了 —— 这才是 06-10 时效崩盘的根。
铁证：现在被每 5 分钟反复扫的 276 个 VIP 视频，100% 是 7 天以前发的老视频。老视频评论高峰早过，再扫多半啥新评论都没有 = 空转；一扫还触发 7 天窗口，把几天前的老评论倒灌进库，把时效统计从 2h 拉到 58h。
| 该加强 | 该砍掉 |
|---|---|
| ① 快速发现新视频（现在被挤瘦了） | ❌ 老视频（7-30天）的高频复扫 |
| ② 只复扫最近 1-3 天的视频（捞正在来的新评论） | ❌ 7 天全窗回填老评论 |
现在 worker 是 1 台机器、3 个干活窗口，一小时干 ~200 个号。一条命令 fly scale count=2（约 30 秒），就是再开一台一模一样的机器：
规格：shared-cpu / 2GB / 东京。技术上安全——两台机器抢同一队列时数据库有锁（SKIP LOCKED），不会重复抓。代码注释也写明：号数超 1000 就该横向加机器。
2 台 = ~400/h。163 个快道号、每个 30 分钟抓一次 = 需要 326/h。400/h 喂得饱，还剩 ~74/h 漏给慢道（慢道终于不再是 0）。✅ 直接有效。
| 日期 | 复扫任务/天 | 发现新源/天 | 时效中位 | 中高意向/天 |
|---|---|---|---|---|
| 06-08 | 39k | 5808 | 5.5h | 705 |
| 06-09 | 39k | 5658 | 1.5h | 778 |
| 06-10 | 70k | 5051 | 58h | 551 |
| 06-11 | 96k | 4877 | 41h | 333 |
| 06-12 | 64k | 4217 | 56h | 330 |
原计划的"三条路"已选 ③ 都上 并全部落地（2026-06-13）。下面是做了什么 + 生产库实测结果。
| 动作 | 方式 | 状态 |
|---|---|---|
| ① 复扫限流（老视频退役） | vip-rescan 加视频年龄闸 ≤4天，PR #329 | 合并+部署 ✅ |
| ② 加 1 台 VM | fly scale count=2（2台/东京） | 已生效 ✅ |
| ③ 提拔金矿入快道 | 62 个证明过的号 → tier1（101→163） | 已生效 ✅ |
| ④ tier 注释对齐 | 4h/5min→1h/3min，PR #327 | 合并生效 ✅ |
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 真新鲜评论捕获（发布≤2h） | — | 中位 ~23 分钟，≤1h 96% ✅ 目标达成 |
| tier0 覆盖 | 近24h 仅 3 个源（≈饿死） | 30min 内 106 个源被采 |
| worker 吞吐 | ~207/h | ~300–460/h（2.2×） |
| vip 复扫洪水 | ~3.3k/h（7.9万/天空转） | 归零（276 老视频退役） |
| worker 积压 | 洪水期堆积 | 仅 14 条（完全追平） |