DM 高意向配速 · 怎么落地
把「当天 DM 实发里高意向占比 ≥ 80%、每号当天 ≤ 25 条」这条目标，落成拉单层一道闸 + 现成发送器不动。
完整口径见需求 docs/requirements/2026-06-23-dm-dynamic-high-intent-pacing.md；本页讲机制 + 用近 7 天真实数据回答「高意向扎堆会不会发不过来」。
✅ 已上线（在跑）：占比闸——保当天高意向占比 ≥ 80%（中意向补位 ≤ 高 ÷ 4）。已在云电脑全自动派单（cron cloud-pc-dispatch，每分钟自动守）里跑；文哥 · 小文（野荞）· 有大有小 · 饭粒（一筑）· 零星 5 个号已开 0.8（小胡未开）。明天 6/24 是第一个「全天受闸」日。
⚠️ 仍是设计 · 待建：下面 ① 画的「拉单层 planner（claim-leads.ts → pacing-plan.ts）按时段预判配速」是另一条路、还没建（评估后判对「评论→DM ≤10 分钟」目标价值小，先搁置）。
📌 通道：DM 主要走云电脑那条全自动派单，上面这道占比闸就加在它「中意向补位」前。
① 0 → 1：目标长什么样、怎么落地
先看目标这两条线长啥样，再看代码在哪一层拦。
🎯 高意向占比
≥ 80%
高意向实发 ÷ 当天实发（硬约束）
📤 当天每号上限
≤ 25条
上限不是下限；供给不够就少发
🍬 甜点（占满 25 条）
20高+5中
两条线的交点 = 25 条 @ 正好 80%
⚖️ 核心硬规则
中 ≤ 高 ÷ 4
每发 1 条中/低，得先垫够 4 条高
横轴=当天累计高意向已发、纵轴=可发中/低意向。
━ 中/低额度只能爬到「高÷4」；┅ 总量封顶 25。
绿区=允许的状态。交点 (20,5) 是唯一能把 25 条占满、又踩在 80% 上的点。
两条约束同时成立：
• 占比线：占比 ≥ 80% ⇔ 中/低 ≤ 高 ÷ 4（p=0.8 → (1−p)/p = 1/4）。
• 总量线：当天 ≤ 25。
所以「凑满 25 条」唯一的合法配比就是 20 高 + 5 中。高意向供给不够 20 时——按裁决 保占比、量可少：宁可当天发 12 高 + 3 中 = 15 条，也不灌低意向凑量。
落地点：拉单层加一道闸，发送器原样不动
新增claim 拉单层 · planner 守门（scripts/claim-leads.ts → pacing-plan.ts）
① 先算今天已发
查你今天已经发了几条：其中高意向几条（记 A）、中/低意向几条（记 B）
→
② 算这轮还能放几条
按现在几点（北京时间）+ 近 7 天高意向一般什么时段来，把 25 条预算摊到全天，算出这轮该放几条、别上午烧光
→
③ 配比闸
中/低意向只在「已发中低 B < 高 A÷4」时才放；超了这轮就只给高意向。占比目标 p 可调（回 50% 只改一个数）
↓ claim 出来的 lead 照常进现成链路
不改现成发送器（opener 备料 → WDA / 云电脑串发）
opener 备料
claim 时现生成话术
→
串行发送
每条间隔 30–90s（沿用现成限速，不重写）
→
日限护栏
单号当天 ≤ 30 条已有上限托底；配速 25 在它之内
📌 这道闸放哪、能不能全自动，看 DM 走哪条云电脑通道：
• 本机拉单 → 云电脑发（运营手动 claim 那条）：闸加在 scripts/claim-leads.ts，就是上图。半自动——还得运营每轮敲一下拉单。
• 云电脑全自动派单（cron cloud-pc-dispatch 无人值守那条）：没有手动 claim，所以同一道闸改放进派单 cron 选 lead 那步（src/lib/dispatch/shared.ts），逻辑一模一样、但跑起来全自动、不用人管。需求 v1 原本没覆盖这条，要全自动就把闸做进这里。
高意向 · 抓到即发
claim 默认就是高意向，不限速、来多少发多少（受 25 / 日限 30 封顶）。高意向是分子，发得越多，中/低的额度才越松。
中意向 · 填充阀
只在「中/低已发 < 高÷4」时才放一条进来填空。它是补量、不是主力——高意向没垫够就闸住等。
低意向 · 出池
不主动拉。和中意向共用「÷4」额度；v1 先只管「高 vs 非高」两档，不给中意向单独配额。
② 已铺到全员：5 个云电脑号（全自动派单）
占比闸已不是「饭粒一台手动流」——它跑在云电脑全自动派单（cron cloud-pc-dispatch，每分钟自动守、无人值守），已开 5 个号（2026-06-23 起）。
在跑的号（5）：文哥 · 小文（野荞）· 有大有小 · 饭粒（一筑）· 零星，均 high_intent_ratio = 0.8；小胡停用、未开。
逐账号 per-account：每号一个 accounts.high_intent_ratio 值，闸按该号当天已发的高 A / 非高 B 守「中 ≤ 高 ÷ 4」，互不干扰。占比口径与 team-journey / 日报完全一致（messaging_account_id → messages(role=ai,sent) join comments.intent_score≥80）。要给某号开/关，改这一列即可（设回 NULL 就关闸）。
复用现成限速、不重写：发送间隔、单号日限、4h claim 锁、fresh window 都是已经在跑的护栏，一行不动；闸只在派单「中意向补位前」多加一道判（在 cron 的 claim 那步）。发送侧（云电脑自驱）零改动。
仍未做（搁置）：手动 claim 流（claim-leads.ts → pacing-plan.ts）那版、以及「按时段预判配速」——见顶部 banner。① 画的「拉单层 planner」就是这条未建的设计路径。
✅ 已铺 5 号（全自动派单）
按号独立算 A/B
阈值 p 参数化 · 现 0.8
25 = 上限非下限
发送器零改动
小胡未开
③ 收盘长什么样：Good / Bad case
同一套规则，供给好 / 坏天的两种结局。
✅ Good
供给足 → 占满还达标
高意向当天来了 25+ 条，发够 20 高，闸放 5 中填到 25 条 → 占比正好 80%，量也顶满。理想日。
高意向爆量 → 全发高
高意向多到发不完，25 条全是高意向 → 占比 100%、量顶满。中意向连闸都不用开。
供给一般 → 保占比少发
只来 12 高，闸放 3 中 = 15 条收盘。没凑到 25，但占比 80% 守住——这是裁决要的结果（保占比、量可少）。
⚠️ Bad（要会读、不是 bug）
断供 → 为保占比硬压量
高意向供给真低的日子，闸会把中/低卡死、当天总量明显低于 25。
这是设计，不是故障——别误读成「配速坏了」。
单号池被薅空 → 实返 0
4h 锁 + 深扫 cap 下，高意向池见底时 claim 可能返 0（夏夏式空返）。planner 要能区分「
被闸住」vs「
池子空」并打清楚，否则看着像卡死。
NULL 漏网 → 占比对不上
意向口径必须和日报 / team-journey 完全一致（高 =
intent_score≥80；中低算分母）。漏 join、把 NULL 当高，两套数就对不上、达没达标说不清。
④ 真实数据：高意向「扎堆」其实扛得住
最大的担心是「高意向集中涌进来，单号 30–90s 串发追不上」。拿近 7 天真实分布看——扎堆极罕见。
近 7 天高意向评论
829条
按 created_at（抓到时刻）
落在多少个 10min 桶
478桶
平均每桶 ≈ 1.7 条
>10 条/10min 的桶
1个
478 桶里仅此 1 个会让单号吃紧
近 7 天高意向按北京时间每 10 分钟分一桶（一格）。291 个桶只有 1 条、107 个桶 2 条……越往右越罕见。9 条以上总共才 4 个桶、12 条仅 1 次。
结论：扎堆不是瓶颈。478 个非空桶里只有 1 个 超过 10 条/10min，绝大多数时刻每 10 分钟也就 1–3 条高意向。单号 30–90s 串发 = 每 10 分钟能发 7–20 条，远超日常到达密度。
真正限发的从来不是「一时涌入」，而是当天总供给和 25 条 / 日限 30 这两道上限——所以配速的活是「把 25 条预算摊到全天、别上午烧光」，不是「扛突发洪峰」。
数据源：scripts/_check-hi-dist-and-accounts.ts（近 7 天 · 全 org · intent_score≥80 · 按 created_at）。每次重算会动；本页快照见页脚日期。
⑤ 按时段：高意向几点来 vs 各号几点在发（近 7 天，共 839 条高意向）
左＝用户实际评论的时段分布；右＝高意向被抓到入库（变可发）的时段分布。下表「覆盖率」＝该号有在发的那些小时，覆盖了多少 % 的高意向入库时刻；「漏掉高峰」＝高意向最密的时段里该号 0 发送。小胡已停用、不列。
占比闸生效：下表 5 个号均 2026-06-23（今日下午）开启（文哥的配比方案随 PR #489 写好、今天随建列一起真生效；其余 4 号同日开，约 16:50–17:10 BJT 之间。精确分钟未入库——心跳每分钟覆盖 updated_at、无配置变更审计表，故只能标到「下午」；不影响结果，占比按自然日算）。占比按北京自然日 0 点清零，明天 6/24 起是第一个「全天受闸」日，看效果以 6/24 收盘为准。
用户评论时段（comment_time）
06121823
用户白天/晚上评论为主（8–22 点），符合作息。
高意向入库时段（created_at = 变可发时刻）
06121823
入库时刻另成形（凌晨 1–2 点一批是夜间深扫回填旧评论）。两图差距即检测延迟。
| 号 | 占比闸 | 生效 | 近7天发/其中高 | 高峰覆盖率 | 漏掉的高意向高峰 |
|---|
| 文哥 | 0.8 | 6/23 下午 | 69 / 21 | 63% | 1点 2点 |
| 饭粒（一筑·全屋定制） | 0.8 | 6/23 下午 | 41 / 4 | 74% | 21点 |
| 零星 | 0.8 | 6/23 下午 | 17 / 3 | 44% | 1点 12点 13点 11点 |
| 小文（野荞） | 0.8 | 6/23 下午 | 47 / 10 | 56% | 1点 2点 9点 |
| 有大有小 | 0.8 | 6/23 下午 | 133 / 33 | 59% | 1点 2点 9点 |
⚠️ 上表「近7天发/其中高」口径修正（2026-06-24）：原数取自 messages 表、按账号 conversation 关联，受 PostgREST 单次 1000 行上限影响，高发量号被低估——零星实际近 7 天云电脑发 71/18（非 17/3）。云电脑真实发送应以 dispatch_queue 为准：文哥 50/15、饭粒 38/4、零星 71/18、小文（野荞）34/7、有大有小 126/26（小胡 0）。覆盖率/漏掉高峰列仍为旧快照、待按真账重算；最新闸前后真账见下方 ⑥。
⑥ 占比闸 A/B：闸前 vs 闸后 vs 今天（6/24 受闸首日）
闸 = accounts.high_intent_ratio=0.8，约 6/23 17:00 BJT 5 个云电脑号同时开启。下面用两张表分开看「抓取入库」和「实际发送」，别混：抓取（入库）不受闸影响，闸只改发送里的高/中配比。窗口按北京自然日。
A · 抓取入库（全局共享池，按 created_at = 变可发时刻）
| 窗口 | 时长 | 高(≥80)入库 | 中(60–79)入库 | 高+中 | 速率 |
|---|
| 闸前 6/23 00:00–17:00 | 17h | 128 | 330 | 458 | 26.9/h |
| 闸后 6/23 17:00–6/24 00:00 | 7h | 35 | 142 | 177 | 25.3/h |
| 今天 6/24 00:00–09:00 | 9h | 41 | 164 | 205 | 22.8/h |
→ 抓取节奏闸前后基本不变（~25/h），占比闸不碰 scrape。池子一直在正常进货。
B · 实际发送（dispatch_queue = 云电脑真账，按完成时刻；5 号合计）
| 窗口 | 发送 | 高(≥80) | 中(60–79) | 高意向占比 |
|---|
| 闸前 6/23 00:00–17:00 | 54 | 11 | 43 | 20% |
| 闸后 6/23 17:00–6/24 00:00 | 6 | 6 | 0 | 100% |
| 今天 6/24 00:00–09:00 | 1 | 1 | 0 | 100% |
闸在按 0.8 配比调整——但今天发送量被「10 分钟时效墙」压住，不是被闸压住。
① 闸生效无误：闸后中意向补位被掐断（中 43→0），高意向占比 20%→100%。
② 今天受闸首日：到 09:00 仅发 1 条、全程到 09:46 共 2 条，全是高意向。低量主因不是闸，是高意向超 10min 窗过期——饭粒今天 4 次派单全被跳过（expired_at_claim(>10min) / wrong_user），零星 2 条新鲜高意向成功发出。
③ 真墙是检测延迟（评论→入库 中位 21min、≤10min 仅 30%）。占比闸只挑「发的是不是高意向」，缩不短「多久被抓到」。要提量得治 scrape 提频，不是放宽配比。
Akke · DM 高意向配速落地说明 · 数据快照 2026-06-24（发送口径已切 dispatch_queue 真账）