combo_health)在生产里 enabled=false,从未开启,决策表为空。更要命的是:就算现在打开它也几乎没用 —— 当前流量下 404 个供应商组合里只有 2 个能越过它「100 样本/24h」的评估门槛,1% 的下架阈值也太松。GA4 显示 CA 根本不在流量 top-12(流量被中国 3923 / 美国 2069 / 日本 1026 占据),说明 CA 订单不是真实需求,而是 catalog 摆出来的「陷阱库存」。
过去一个月订单量从 6 月初 2000–2800/日 滑到现在 1000–1500/日,端到端完成率(completed/总单)从 ~32% 跌到 ~22%,营收同步从 ~$1,000–1,500/日 降到 ~$500/日。这与已知的「单篇拳头博文 organic 流量下滑」一致——属于流量端问题。
但完成率的下滑主要是 mix-shift(结构性假象),不是供应链变差:按服务拆周环比,主力 openai 接码稳定甚至微升(46.1% → 48.0%),下滑全部集中在本就低接码的服务放量:
| 服务 | 上周单量 | 上周完成率 | 本周单量 | 本周完成率 | 判读 |
|---|---|---|---|---|---|
| openai | 2592 | 46.1% | 2587 | 48.0% | 稳,健康 |
| telegram | 2459 | 4.8% | 2097 | 6.3% | 大盘低接码 |
| 646 | 8.2% | 1208 | 4.6% | 放量翻倍 + 接码腰斩 | |
| 400 | 12.0% | 671 | 12.8% | 稳 | |
| codebuddy | 60 | 46.7% | 303 | 19.5% | 放量 5x + 接码崩(仅 4 用户,疑 API 刷) |
把订单按国家拆开,CA(加拿大)是一个跨服务的系统性黑洞——它在每一个主力服务上都几乎收不到码:
| 服务/国家 | 单量(7d) | 完成率 | 取消 | 过期(到点无码) | 取号失败 |
|---|---|---|---|---|---|
| whatsapp/CA | 409 | 4.4% | 241 | 144 | 6 |
| telegram/CA | 329 | 7.0% | 175 | 131 | 0 |
| openai/CA | 107 | 1.9% | 43 | 29 | 33 |
| google/CA | 49 | 0.0% | 42 | 7 | 0 |
对比之下 openai/US 完成率 58.7%。这不是某一家供应商的问题——把 CA 订单按供应商拆,每一家都很差,说明是 CA 号码本身(号段/落地能力)无法承接这些 OTP:
| 供应商(CA, 7d) | 单量 | 完成率 | 性质 |
|---|---|---|---|
| durianrcs.com | 355 | 10.4% | 第三方聚合 |
| grizzlysms.com | 233 | 0.9% | 第三方聚合 |
| sms-bus.com | 196 | 5.6% | 第三方聚合 |
| 5sim.net | 115 | 2.6% | 第三方聚合 |
| isptelecom | 52 | 0.0% | 自营号池 |
过去 7 天 GA4 活跃用户分布:中国 3923、美国 2069、日本 1026、香港 687、新加坡 546、台湾 292、俄罗斯 146……加拿大根本进不了 top-12。但 CA 却是第 2 大订单国(951 单)。结论:CA 订单并非加拿大访客的真实需求,而是用户在国家选择器里看到 CA「有货、价格中等」就点了,然后必然失败。Catalog 把一个收不到码的国家摆在货架上卖。
evalWastedDemand,每日在 A 卡暴露高需求低履约的组合)。本条不重复那个结论,而是补三个它没覆盖的角度:① CA 是最大的单一死库存桶且是跨服务的「地理」失败(非单供应商);② GA4 证明 CA 不是真实需求;③ worker 层的空转盲点(报告告警管不到「combo_health 开了却空转」)—— 见下方配套 PR。
代码里其实有一套设计完整的「P2 接码率自愈」机制(combohealth service + worker + admin UI + 大量 review 修复),逻辑是:某 (供应商,服务,国家) 三元组 24h 接码率 < 1% 且样本 ≥ 100 → 自动下架(hidden)。但它有两层失效:
config.production.yaml 里 combo_health.enabled: false(注释「灰度上线开关,默认关」)。cmd/worker/main.go:789 用 if cfg.ComboHealth.Enabled 把整个 worker 门住——生产日志是「combo health worker disabled by config」。combo_health_decisions 表 0 行,印证它从没跑过。
| 评估粒度 / 窗口 | 组合总数 | 能达 100 样本 | 占比 |
|---|---|---|---|
| (供应商,服务,国家) · 24h(现状) | 404 | 2 | 0.5% |
| (服务,国家) 跨供应商池化 · 24h | 197 | 3 | 1.5% |
| (供应商,服务,国家) · 7d | 1252 | 19 | 1.5% |
| (服务,国家) 跨供应商池化 · 7d | 624 | 28 | 4.5% |
即便放宽到 7d + 池化,覆盖率也只有 4.5%。说明 min_sample_size=100 是按一个不存在的流量规模标定的,本质是参数与现实错配。
除了 CA,还有一批接码率≈0 的组合在正常售卖:telegram/OM·SG·CN·KR·TW、whatsapp/QA·EC·PE、openai/SG(50 单 @ $1.02/单,0% 完成)。其中部分 telegram 免费组合($0)疑似 bot 探测,但付费的(如 openai/SG)是真金白银的差体验。
combo_health(需先重标定,否则等于没开)。把 enabled 置 true 前,至少调整:① min_sample_size 100 → 20–30,匹配真实流量;② 把评估粒度从 (供应商,服务,国家) 升到 (服务,国家) 跨供应商池化(用户只在意服务+国家能不能收码);③ hide_threshold 1% → 视情况升向 3–5%(1% 太松,5% 完成率仍是糟糕体验)。这是有营收影响的决策,建议 3 人小队碰一下再灰度。assessable 计数 + 「评估了组合但一个都没越过样本门」时打 WARN。这样一旦开启 combo_health,运营能立刻看出它是真在防护、还是 enabled=true 的空转——避免「以为开了防护,死库存照卖」的隐性失效再次发生。纯加日志/指标,不改任何 hide/unhide 行为,零营收风险,可随时回退。