本地 f2 实拉号源新方法

找到一个新号源、判断它值不值得抓，过去要「先入库 → 等 7 天抓取 → 看产出」才知道好坏；这套在 6/04 翻过车——把刚入库、评论还没抓进来的活号，误判成「0 评论死号」给停了。

新方法把这道判断闸门往前挪：入库之前就用本地 f2（国内 IP 直连抖音）实拉候选号最新视频的真实评论，分钟级看清「现在还能不能挖到新评论 / 评论里有没有装修意向」，再决定入不入、入了之后优先抓谁。

这套方法 6/05 又跑了一整轮（第二批），结果比首批（5/30）更猛，也暴露了几条运营必知的坑，记在这里：

这 22 个号的评论池有多大（avgC = 平均每条视频多少评论）：一口的装修日记 40198 · 100个中国女孩的家 16500 · 小陈同学装修vlog 11927 · 玉妈装修日记 5185 · 追同学装修日记 5075……光 avgC>1000 的就 15 个，比首批整批才 16 条可触达 leads 强得多。「个人装修日记」这条脉选对了——这型号评论区清一色「哪家定制 / 多少钱 / 能联系吗」，全是真买家。

本页出现的专业词，都在这用人话解释一遍，例子全用我们今天真跑出来的号。看正文遇到不懂的词回这查。

原来的扩源链路是：搜到号 → 按名字打分 → 入库 → 挂进 7 天抓取队列 → 用「我们 DB 里近 7d 抓到的评论数」判好坏。6/04 这套连环踩了三个坑，把活号判成死号：

新方法不改打分/分类/tier 那套系统，只把「先入库再验」改成「入库前先用本地 f2 实拉看真数据」。两个关键技术点：

方法论 v2 · 阶段 0–3 闭环：

已拉批次 · 各自什么时候 check 结果（每批入库即自动排 T+7 提醒，满 7 天查）：

查的时候跑 TAG=<批次> python3 scripts/source-cohort-yield.py。脚本已加宽限期：入库不满 9 天的号即使暂时 0 产出也只推「🆕新号观察中」，不推死号——避免 worker 还没抓够就误杀活号。

按日进度 · 上周 → 本周（连续日志，每日扩源后更新）
上周＝6/04–6/07（周四–周日）· 本周＝6/08（周一）起；5/30 为前情。「产出」列= cohort-yield 近 7d 实时数，未到 T+7（入库满 7 天）都是中途数；最近回流快照 2026-06-07 晚。

📊 累计效果快照（截至 2026-06-14 · 全部 douyin-search-* 批次 · DB 实查）
不是 7d 滚动窗口，是每批入库以来的累计真实下游产出（视频/评论/高意向/转化）。复现：worker/.venv/bin/python scripts/_source-mining-effect-cumulative.py。

口径：高意向＝评论 intent_score≥80（去重到唯一用户）；可触达＝高意向用户中 status≠contacted（还没发触达）；已联系＝其中已 contacted。6/13、6/14 数低是因仍在 GRACE_DAYS=9 宽限期、worker 还没抓够，不代表号差。

🆕 新方法（6/07 晚定型）·「高评论动态 → 主页评估」法

老路是「搜用户→按名字筛号」；新路反过来：「搜动态（视频）→挑评论爆的→顺着进作者主页评估」。逻辑很朴素：评论多的装修动态，评论区本身就是买家聚集地——尤其「花费清单 / 装修全流程 / 硬装预算」这类钱字头主题，围观的全是正在做装修决策的人。

首战成绩（6/07 晚 · 双 track 同晚对照）：

① 我们 6 月新批 · 早期意向四档（2026-06-06 快照，高/中意向占比已拆开；三批都没到 T+7，是未成熟中途数）：

② 基准对比 · 按 tier/来源（互斥 cohort · 全量·按高意向% 降序） · 完整方法论/取数路径见 repo docs/analysis/source-intent-baseline-2026-06-06.md

③ 类别细分 · 更新频率 + 近7d 意向（全量 active 号 · 按高意向% 降序）

读：本地号高意向 4.1% 最高（平台号 1 个号样本太小忽略），知识号/工厂号次之；全屋定制类别高意向只 2.8%（商家自卖稀释，故扩源该维度走加严过滤剔商家）；业主日记高意向 1.9% 暂垫底但人均发片最低(7d 0.1)——个人号更新慢、多数才入库 1 天未成熟。
⚠️ 全部 T+7 前快照，满 7 天（6/11–6/13）的数才作准，别据此判废。

① 名字分 vs 真实评论量：强反差（f2 富化 23 号，按 avg_comments 排序，节选）—— 名字带「设计师」分高的评论垫底，名字分 -5 的反而是矿：

读法：名字分高的「设计师·华生 / 想想 / 老李」avgC 只有 5~1891；名字分 -5（搜索源缺 aweme_count 被 zombie 误杀）的拾点 / 咕噜苗反而是评论巨矿。金矿号「一只芋圆仔」名字分也是 -5，avgC 仅 736 不算高，却是后面意向产出最高的号 → 评论量是入池信号，但真好坏还得看意向。

② 筛选漏斗：从 25 候选到 16 条可触达 leads：

③ 16 条可触达 leads 明细（高 / 中意向，按分排序）：

5 个验证号的产出对比：一只芋圆仔 41 评论 / 10 leads（命中率最高）· 李小冷不冷 53 / 3 · 土豆饼 18 / 1 · 二首灵感大王 52 / 1 · 居里富人 12 / 1。「一只芋圆仔」是装修日记号（J 人懒人全屋装修），评论区清一色「哪家定制 / 多少钱 / 能联系吗」——这正是最值钱的潜客信号，故升 tier1。

这次翻车的根因是「用错指标判死活」。固化下来的验证口径：

全程本地跑（.venv 里 f2 0.0.1.7 + httpx 0.27.2；cookie 从 accounts.cookie_data 取任一 active 号）。按阶段 0→3：

阶段 0 · 搜索候选 → 名字分

# CDP Chrome 手动搜词（Enter 不触发，必须点搜索按钮），监听作者列表
python3 scripts/chanmama/_douyin-search-score.py
# → outputs/douyin-search-scored-{date}.json（每条带 sec_uid / nickname / _score）

阶段 1 · 本地 f2 富化（看更新频率 + 转赞评）

cd worker
.venv/bin/python -u _enrich-candidates.py
# → outputs/douyin-search-enriched-{date}.json
#   字段：last_pub / days_since_last / posts_30d / posts_90d / avg_comments / avg_digg

阶段 2 · 实拉验证（拉在题号新鲜评论 → 意向打分）

# ① worker 端 f2 实拉评论 → /tmp/_leads_raw.json（KEEP 集合 = 在题号白名单）
cd worker && .venv/bin/python -u _pull-leads-for-scoring.py
# ② 喂 production 意向分类器（deepseek-v4-flash + Langfuse prompt）
pnpm tsx scripts/_score-leads-f2.ts
# → outputs/douyin-search-{date}-leads-scored.json（高/中/低/无关 + type + reason）

阶段 3 · 入库 + 触发抓取

# dry-run 先看会入哪些（默认最新 scored json）
python3 scripts/chanmama/import-douyin-search.py --min-comments 150
# 真入库：写 source_accounts（org_id 必填 / category_legacy 打标 / is_active=true）
python3 scripts/chanmama/import-douyin-search.py --min-comments 150 --no-dry-run
# → outputs/douyin-search-{date}-trigger-list.json 给 worker fan-out enqueue

入库后 · 队列效果检查（6/11 routine 同款，stdlib only）

cd /Users/fanny/Akke # 先 load .env.local
TAG=douyin-search-20260530 python3 scripts/source-cohort-yield.py
# 按 category_legacy 批次拉近 7d：总评论 / 高意向 / 占比 / 可触达 / tier1 候选

① 和现有号源机制：同一套表 / 同一套打分 / 同一套 tier，只是闸门前移

② 和视频机制：入库后照常进抓取流水线，富化数据反哺复扫优先级

以 6/05 第二批为例（一轮干净跑 = 从搜索到 22 个号入库），各阶段的用时和花费：

注：以上是「干净跑」的理论用时。6/05 当天因调试并发限流多耗了额外时间，那是操作失误不是方法成本——按串行老老实实跑就是上表的数。

① 每天产出有上下限，且会衰减——「产出」= 当天入库的活跃金矿号数。三批实测：

② 关键词怎么选：目前按经验挑——锚定「个人装修日记 / 晒家」这条出过金矿（一只芋圆仔）的脉，选装修相邻、能勾出个人晒家评论的词，每天换新角度避免去重。诚实说：还没有系统化选词机制，是已知缺口（更严谨该配抖音指数验词热度）。

③ 去重：每次打分时实时拉全量号源库的 sec_uid + 名称比对，命中的标记 dup、不入库。6/6 实测 344 作者 → 331 新 / 13 已在库。sec_uid 去重很硬，入库的号不会重复；历史捞过但没入库的号可能被再捞一次，但不入库、无害。

⑤ 入库的号有「类型」和「来源」标签（号源页可见）：

注：早期入库脚本曾把所有号硬标「全屋定制」（一刀切、不准），已修正为按名字分类并回填历史批次。例：6/6 入库 9 个 = 3 业主日记（入住毛坯房/小于的家…）+ 6 本地号（城市+旧房改造服务号）。