upio.ai / Akke / 号源体系 × 抓取机制 · 演进与效果

号源体系 × 抓取机制 · 6/1→6/16 演进与效果

Akke 项目 · 2026-06-16 收口 · 数据窗口 2026-06-01 → 2026-06-16（北京时）
前序：号源评分方法论(6/4) · 每日扩源·tier体系(6/11) · 本地 f2 实拉方法
⚠️ 2026-07-17 口径校准：本页是 6/16 的快照，下面 ②B / ③ 写的升降档口径与抓取频率已经变了，照着做会走错。现行口径以 获客链路页 §2 为准（已逐条对过真实代码）。三处要点：① tier1 是 每 3 分钟（*/3）不是每 2 分钟——本页原「口径修正」那条反而把对的改错了，已订正；② 升 tier1 = 近 10 天「高+中意向」≥ 10 条，不再是「近 3 天高意向 ≥ 5」；③ 「只升不降 + 手动清理」已被 每天 01:00 一轮跑的自动三闸（升→降→出池）取代。本页正文只订正这些「现行机制」句，当时的叙事与判断保留原样。
📡 2026-06-21 更新：本页 ⑥ 当时标「by-day tier 曲线 / 完整流转链不可重建」、⑧#1 列「待补每日快照表」——那张表 6/16 当天即落地（daily_source_tier_stats + source_tier_change_log），数据已自动积累。续作 → 号源动态监控（实时活曲线） 已接棒：每日扩源后自动重生成，画 by-day tier0/1 号数 + 升降流水 + 快车道。本页留作 6/16 纵向叙事快照不动，下面 ⑥/⑧ 已标注「已修复」。
① 一句话 ② 号源分类体系 ③ 抓取机制 ④ 两旋钮的效果 ⑤ 新号流入与流转 ⑥ 数据缺口 ★ ⑦ 与前序两页的关系 ⑧ 下一步
01一句话

这是一份纵向文档：把「号源怎么分类（体系）」和「分类后怎么抓（机制）」两个旋钮，放到 6/1→6/16 的时间轴上，看它们各自改了什么、合起来对意向产出有什么效果。结论先放：

核心发现：tier1（热）号 ≈ 全 active 池的 1 成多（6/21: 140 / 1234 = 11%；6/16 为 176/15%），却贡献了 ~90% 的高意向评论（6/16 口径 1652 / 1826）。把抓取预算压到这一成号上、其余每小时兜底，是整个体系的杠杆点。（Pareto 比例为 6/16 effect 快照；tier 号数已刷新至 6/21，逐日见 实时监控页）
诚实前置（务必先读 ⑥）：库里从未记录 tier 变更历史（无审计列 / 无每日快照）。所以「by-day 各 tier 号数」和「号源流转链 tierX→tierX→tierX」6/11 之前完全不可重建，6/11→今也只能从回滚锚点半重建（且漏掉 auto-tier1 cron 的升档）。本页凡涉及这两项均明确标注口径，宁可缺、不杜撰。
02号源分类体系：怎么分 / 依据 / 数量现状
A. 物理只有两档（tier 0/1），命名按 canonical 五档对齐

source_accounts.tier 是个当前状态单列，物理上只落地 0 / 1 两个值。对内对外统一命名表如下；温/冷/休眠是「把未分档按近 7 天产出再细分」的目标方案（parked，未落地）。

tier 值名称含义当前是否物理落地
1热近期持续产出买家意向，吃快车道✓ 已落地（176 个）
2温有产出但不密，目标细分档✗ parked（堆在 tier0）
3冷偶有产出✗ parked（堆在 tier0）
4休眠连续多日 0 产出，待停抓✗ parked（堆在 tier0）
0未分档除热号外的全部 active 号（兜底每小时抓）✓ 已落地（1019 个）
B. 分档依据 = 近 7 天「高+中意向」产出数（不是粉丝/历史火过）

升降档只看一个量：这个号近 7 天抓到多少条高/中意向评论。粉丝多、历史爆过、评论总数大——都不算数，只认「现在评论区里还有没有人在问价」。两条落地路径：

✅ 这条裂缝已修（2026-06-21 落地）：本页当时写「auto-tier1 看「高意向≥5/3天」，会漏掉中意向多、高意向不足 5 的优质号（如某号高 5 中 35）；建议统一成「高+中」——高危改动走 PR，当前 parked」。已不再 parked，而且改得比当时的建议更彻底：升=近 10 天「高+中」≥ 10；降=tier1 近 7 天「高+中」= 0 → 回 tier0；出池=tier0 且「最新视频 30 天前」+「近 30 天 0 条高+中」→ is_active=false（可逆）。三闸都在 /api/cron/auto-tier1 每天 01:00 一轮里跑（先升→再降→再淘汰→落快照）。意向口径：每条评论 0–100 分，≥80 算高、≥60 算中。
C. 另有两套正交标签（与 tier 不是一回事，别混）

同一个号身上挂三套坐标：tier（抓取优先级）、category_v2（号是谁/9 类画像）、评分 A/B/C/D（号质量分，详见 评分方法论页）。当前 active 池（1234，数字刷新至 2026-06-21）的画像分布（构成与 6/16 基本一致，同行 peer_decoration 仍最大）：

category_v2 画像号数说明
peer_decoration 同行装修号513占比最大，多为 B2B/同行，评论区常非 C 端买家
knowledge_creator 知识号279科普装修，评论区问价密度中等
业主日记 / homeowner_diary103 + 24真实业主，C 端买家浓度高（命名未统一，见⑥）；f2 扩源持续补这一脉
designer 设计号 / 设计号72 + 3设计师个人号
brand_official 品牌官方号63官方号，评论区偏粉丝互动
factory_b2b 工厂号40同行/供应链，C 端少
material_supplier 建材供应22
local_store 本地号 / 本地号9 + 6同城门店
(未分类) + 其余旧标签90category_v2 为空或旧中文标签未迁移
合计 active1234= 当前 tier1(140) + tier0(1094)（数字 6/21；6/16 为 1195=176+1019）
D. 数量快照（数字刷新至 2026-06-21；持续变动看 实时监控页）
号池总量
3258
含已停抓（6/16: 3219）
active 在抓
1234
inactive 2024（6/16: 1195）
tier1 热（~2min 车道）
140
active 的 11%（6/16: 176/15%）
tier0 未分档（1h 兜底）
1094
active 的 89%（6/16: 1019）
📉 tier1 从 6/16 的 176 降到 140：auto-tier1 cron 每天既升也降（近 7 天高+中=0 的热号自动降回 tier0），6/17–6/21 净降——说明换血在持续淘汰衰退号。逐日升降见 实时监控页。
03抓取机制：两条轮抓车道 + 升降档现状

分类之后，抓取频率只按 tier 分两档（口径来自 vercel.json 实测，下面是 6/16 真实值）：

cron频率覆盖作用
/api/cron/scrape-hot每 3 分钟（*/3）tier1 热号（6/21: 140）买家窗口短，热号要近实时盯
/api/cron/scrape每小时（10 * * * *）tier0 全部（6/21: 1094）兜底扫，省预算；每轮取 150 个最久没抓的
/api/cron/auto-tier1每天 01:00（0 1 * * *）升档 + 降档 + 出池一轮跑完三闸（先升→再降→再淘汰→落快照）
⚠️ 订正（2026-07-17）：本页原来这条「口径修正」是错的，把对的改成了错的。它当时写「早前内部记忆写 tier1 为『每 3min』，已与 vercel.json 核对——真实为每 2min（*/2）」。事实反过来：记忆里的『每 3min』一直是对的，vercel.json 里 scrape-hot 从头到尾都是 */3。
错因：*/2 来自 src/app/api/cron/scrape-hot/route.ts 顶部一句计划注释——「2026-06-15 提速阶梯第 1 步：默认 45→30min，配合 vercel.json scrape-hot */3→*/2」。那是「跑稳 24-48h 后再推」的下一步计划，从没执行。把计划注释当成了现值。教训：核 cron 频率只认 vercel.json 的 schedule 字段，别读代码注释。
补：tier1 的「每 3 分钟」是轮次频率，不等于每个号 3 分钟被抓一次。同一个号有整号节流下限 30 分钟（SCRAPE_HOT_SOURCE_THROTTLE_MINUTES 默认 30）；其中「近 6 小时刚产过高/中意向」的号才把节流缩到最快 10 分钟一次（HOT_TIER1_INTENT_THROTTLE_MINUTES 默认 10 / HOT_TIER1_INTENT_WINDOW_HOURS 默认 6，2026-06-24 上线的 intent-aware 加密）。所以「3 分钟」是扫描轮次，「10–30 分钟」才是单号真实复抓间隔。
parked 的 4 档再切方案：按近 7 天高+中切 T1≥16 / T2 6-15 / T3 1-5 / T4 连续14天0，配每日全量再分档 job。预期抓取量降 ~70%。落地最大地雷：scrape 现是 .eq("tier",0) 精确匹配，若直接打 2/3/4 标会静默永不抓——必须先改路由 cover 所有非 tier1 档，再 retier 打标。动 cron + 可能动 migration = 高危，走 PR。
04两个旋钮一起拧的效果可精确拉
A. 意向 × 当前 tier —— 杠杆有多陡

把 6/1→今的意向评论按评论所属号的当前 tier 归类（仅 active 号）。结论是极端 Pareto：

tier高意向中意向低意向高意向占比
tier1 热（176 号）16525137519590.5%
tier0 未分档（1019 号）1746549559.5%
读法：15% 的热号产出九成高意向 → 「热号 2min / 其余 1h」这套抓取机制是对的方向。同时也说明 tier0 那 1019 个号里大量是「在抓但评论区没买家」的兜底对象，正是未来 T4 休眠档要清的。
口径：归「当前 tier」非历史归属；仅 active 号，已停抓号的历史评论不计入（故 1652+174=1826 < 下表高意向总量）。
B. 意向产出 by-day（6/1→6/15，北京日）

每天抓到并打分的评论体量。高意向日基线 ~150-170 条，是整个触达漏斗的进水口。

日期高意向中意向低意向无关备注
06-0117851241992无关异常偏低（见⑥）
06-021556866845428
06-031674335027041
06-041574034554234388 号 B2B 批量入库日
06-051504484534556
06-061724835005203
06-071553904554171
06-081665395555470
06-091666125574910
06-101174344753749
06-11772563001591tier0 采集饿死事故期(已修)
06-12672632931864同上，谷底
06-132669466987772事故修复后回补峰
06-141534204494549回到基线
06-15853023342820
6/11-6/12 高意向腰斩到 67-77，是 tier0 采集饿死事故（pri=0/1 永不枯竭、claim 严格 priority ASC → tier0 零认领）所致，6/13 修复后单日回补到 266。这段低谷是机制 bug 不是号源问题——正好佐证抓取机制对产出的直接杠杆。
05新号流入与流转（since 6/1）入库可精确 / 流转仅锚点
A. 新号 by-day 入库（566 个）+ 渠道 + 现在升到热的数量
入库日新号渠道拆分现 tier1
06-04404B2B 批=388，f2=162
06-0522f2=222
06-069f2=93
06-0716f2=162
06-0826f2=261
06-0917f2=171
06-1040f2=401
06-1110f2=102
06-129f2=96
06-137f2=77
06-145f2=53
06-151f2=11
B. 两条进号渠道，转热率天差地别
抖音搜索·本地 f2（入库前实拉验证）
30 / 178
17% 转 tier1 热
6/4 B2B 批量入库（未实拉）
1 / 388
0.3% 转 tier1 热
这是本页第二个硬结论：本地 f2 实拉验证这条渠道——入库前先拉号最新评论打分、把空号挡在门外——转热率 17%，是 6/4 那批未经验证批量进的 B2B 号（0.3%）的 ~50 倍。越近期的 f2 批转热率越高（6/12-6/13 入库的号几乎全转热），说明「入库前验证」这道闸越收越准。结论：扩源该全押 f2 实拉，B2B 批量进号是负资产。
C. tier 流转锚点（6/11→6/15，从回滚 JSON 半重建）

这是唯一能拿到的流转明细——每次手动/自动改 tier 时落的回滚锚点文件。6/11 之前无任何此类记录。

日期手动升 tier0→1自动升 0→1自动降 1→0弃用(停抓)
06-11261619
06-126———
06-137———
06-143———
06-151———
这张表对不上账，而这正是要暴露的事：6/11 清理后 tier1=95，到 6/16 已是 176，净增 +81。但上表锚点只解释 +9（升 2+6+7+3+1 − 降 16）。缺口 ~72 个升档无记录——因为 auto-tier1 cron 每天 01:00 升档但不写回滚锚点。所以即便 6/11 之后，流转链也是残缺的。详见⑥。
06数据可靠性与缺口（响亮地说清）必读

你要的几样东西里，有的库里有、有的根本没记。逐项交底，不糊弄：

你要的可靠性实情
当前各 tier 号数✓ 精确count 查询，3219/1195/176/1019 都实数
各 tier 高/中/低意向评论数✓ 精确join 当前 tier 实算（④A）；口径=归当前 tier、active 号
意向产出 by-day✓ 精确按 created_at 北京日分桶 count（④B）
新号入库 by-day + 渠道✓ 精确created_at 实算（⑤A），但见下「6/4 坑」
by-day 各 tier 号数✓ 6/16 起已修复当时不可重建（无快照）；6/16 落地 daily_source_tier_stats 每日 cron 快照，6/16 起有真曲线，见 实时监控页。6/16 前仍空白
号源流转链 tierX→tierX→…✓ 6/16 起已修复6/16 落地 source_tier_change_log，auto-tier1/降档/手动统一写流水（堵上当时 ~72 升档无痕缺口），6/16 起逐次可查，见实时监控页升降流水
三个具体的坑（都已确认，写进来）
还有个小命名债：业主日记同时存在 业主日记(87) 和 homeowner_diary(24) 两个标签、本地号同时有 本地号 和 local_store——中英标签未统一迁移，统计时需手动合并（本页已合并展示）。
07与前序两页的关系（要不要调整）

你问这页和那两张表是什么关系、要不要动它们。答案是三页正交、各管一段，老页不动：

页面管什么轴本页如何衔接
source-scoring (6/4)号质量怎么打分（5 维 A/B/C/D、筛号漏斗）方法论快照本页②C 引用其评分体系，不复述
source-mining (6/11)6/11 那天扩源实战 + tier 体系定版单日运营快照本页③继承其 tier 定版口径，作前序锚点
本页 (6/16)体系×机制随时间怎么变、对产出什么效果纵向演进新轴，链入上两页
建议：两张老页保持原样不动。 source-mining 的 slug 带 6-11 日期，是那天的运营锚点，覆盖会名实不符、也毁掉⑤C 引用的 6/11 锚点；source-scoring 是评分方法论，把「评分 A/B/C/D」和「tier 0/1」「抓取节拍」揉一页会混淆三套正交口径。本页作为「演进/效果」第三轴，定期出新日期版即可。