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 行为，零营收风险，可随时回退。