一句话结论：过去 7 天，约 25% 的取号尝试量流向了"几乎永远收不到验证码"的 service×country 组合 —— 其中 18%（2,828 次尝试）产出 0 条 SMS。这些需求主要由中文拳头博文引来的华语用户贡献（索要 telegram + 亚洲号），而我方供应链结构性供不出货。用户陷入重试循环、白烧供应商配额、毒化最大获客渠道的首单体验。
更要命的是：我们其实早就建好了一套自动隐藏死组合的 combo_health 自愈系统 —— 但它在生产从未开启（决策表为空），而且就算开启，按现有采样阈值也抓不到这种碎片化的死组合。
| 窗口 | 尝试 | 取号率 | 取号后接码率 |
|---|---|---|---|
| 过去 24h | 1,759 | 46.0% | 28.6% |
| 前 24h | 2,030 | 48.1% | 26.9% |
| 7 日其余均值 | 11,895 | 52.5% | 28.5% |
取号率连续下滑（52.5% → 48.1% → 46.0%）。但真正的漏点不在取号率本身，而在下面：大量需求集中在根本无法履约的组合上。
| 类别 | 组合数 | 7d 尝试量 | 占总量 | 产出 SMS |
|---|---|---|---|---|
| 健康 | 680 | 11,729 | 74.8% | 2,262 |
| 死组合 · 0 SMS | 15 | 2,828 | 18.0% | 0 |
| 准死 · <5% 接码 | 7 | 1,127 | 7.2% | 12 |
| 服务 · 国家 | 订单 | 取号率 | 履约率 | 病因 |
|---|---|---|---|---|
| codebuddy · HK | 81 | 1.2% | 1.2% | 无号源 |
| telegram · USV | 81 | 39.5% | 7.4% | 收不到码 |
| telegram · CA | 56 | 51.8% | 5.4% | 收不到码 |
| telegram · US | 56 | 57.1% | 5.4% | 收不到码 |
| whatsapp · QA | 31 | 0.0% | 0.0% | 无号源 |
| telegram · OM | 23 | 0.0% | 0.0% | 无号源 |
| whatsapp · IN | 19 | 47.4% | 0.0% | 收不到码 |
昨日 Top-5 高量组合里，4 个履约率 < 8%。唯一健康的是 openai · US（253 单，履约 62%）—— 这才是我们真正擅长的产品。
telegram·CN/OM/KR、alipay·CN、tiktok·CN、codebuddy·HK。→ 补供给 or 下架。telegram·NI、whatsapp·GB。→ 换池 or 下架。GA4 交叉确认：流量第一入口是中文拳头博文，把华语用户源源不断灌进漏斗。
| 落地页（7d） | Sessions |
|---|---|
| /zh-CN/blog/sms-verification-platforms-2026-guide | 2,695 |
| / （首页） | 2,063 |
| /zh-CN/dashboard | 1,060 |
| /zh-CN/login | 612 |
这些华语用户集中索要 telegram + 亚洲号（CN/HK/TW/KR/OM）—— 正是我方结构性供不出的组合。结果是重试循环：
影响：① 白烧供应商速率配额；② 取号率被持续拉低；③ 最大获客渠道的用户拿到最差的首单体验 —— 买号→收不到码→重试→还是收不到→流失。
代码交叉确认（main 分支）发现一个更深的问题：
combo_health 接码率自愈子系统（internal/service/combohealth/），设计就是自动把死组合从在售目录里隐藏。config.production.yaml 里 combo_health.enabled: false —— 生产从未开启，combo_health_decisions 表为空，零决策。(supplier, service, country)/24h 评估、min_sample_size=100。但需求碎片化到 5 家供应商 × 多国，每个三元组仅 13–39 次/24h，全部低于采样线。粒度错配。service_success_drop 规则只看环比下降 —— 一个长期稳定 0% 履约的死组合环比无变化，永远沉默。performance_aggregator（enabled: true）持续产出 56.2 万条 24h 快照，最新仅 19 分钟前。问题纯粹在决策层没接上。给经营日报补上这块盲区 —— 新增"无效需求"关注项（evalWastedDemand），看绝对水平而非环比：当日订单 ≥ 20 且履约率 < 10% → 🟡 告警，并用取号率自动区分「无可用号源」/「取号后收不到验证码」病因，多组合按订单量降序优先暴露浪费最大的。
纯观测、零业务面影响：只往日报多加一行告警，不碰 catalog、不改下单路径、不动余额 —— 隐藏/补供给的决策权留给运营。复用既有快照字段，无新增查询，6 个新单测全绿。
🔗 PR：dogesms/tuna#529
telegram·CN/OM/KR、alipay·CN、codebuddy·HK 等取号率≈0）从在售目录隐藏 / 快速失败，让用户自然分流到能履约的产品。combo_health，但先把评估粒度改到 (service,country) 聚合层 —— 否则碎片化需求仍漏过采样线。